Bitcoin Forum
December 14, 2017, 02:47:52 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Declarative smart contracts in Byteball  (Read 17290 times)
tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
September 15, 2016, 03:00:01 PM
 #1

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Money in Byteball are stored on addresses.  Address is just a hash (plus checksum) of an address definition, and the address definition is an expression in the Byteball smart contract language that evaluates to either true or false.

Here is an example of the simplest address definition that defines an address controlled by a single private key:

["sig",{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]

The pubkey above is base64-encoded public key.  The expression evaluates to true if the signature provided with the transaction is valid and produced by the private key that corresponds to the above public key.  The address (checksummed hash in base32) corresponding to this definition is A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.

All expressions in this language evaluate to a boolean value, and multiple boolean subexpressions can be combined using boolean operators.  For example, this is a definition that requires two signatures:

["and", [
  ["sig", {pubkey: "one pubkey in base64"}],
  ["sig", {pubkey: "another pubkey in base64"}]
]]

To spend funds from the address equal to the hash of the above definition, one would need to provide two signatures.

As you noticed, we use JSON to construct the language expressions.  This is an unusual choice but allows to use existing well-debugged, well-supported, and well-optimized JSON parsers rather than invent our own.

"Or" condition can be used to require signatures by any one of the listed public keys:

["or", [
  ["sig", {pubkey: "laptop pubkey"}],
  ["sig", {pubkey: "smartphone pubkey"}],
  ["sig", {pubkey: "tablet pubkey"}]
]]

The above is useful when you want to control the same address from any of the 3 devices: your laptop, your phone, and your tablet.

The conditions can be nested:

["and", [
  ["or", [
    ["sig", {pubkey: "laptop pubkey"}],
    ["sig", {pubkey: "tablet pubkey"}]
  ]],
  ["sig", {pubkey: "smartphone pubkey"}]
]]

A definition can require a minimum number of conditions to be true out of a larger set, for example, a 2-of-3 signature:

["r of set", {
  required: 2,
  set: [
    ["sig", {pubkey: "laptop pubkey"}],
    ["sig", {pubkey: "smartphone pubkey"}],
    ["sig", {pubkey: "tablet pubkey"}]
  ]
}]

("r" stands for "required") which features both the security of two mandatory signatures and the reliability, so that in case one of the keys is lost, the address is still usable and can be used to change its definition and replace the lost 3rd key with a new one.

Also, different conditions can be given different weights, of which a minimum is required:

["weighted and", {
  required: 50,
  set: [
    {weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },
    {weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }
  ]
}]

A definition can contain reference to another address:

["and", [
  ["address", "ADDRESS 1 IN BASE32"],
  ["address", "ADDRESS 2 IN BASE32"]
]]

which delegates signing to another address and is useful for building shared control addresses (addresses controlled by several users).  This syntax gives the users the flexibility to change definitions of their own component addresses whenever they like, without bothering the other user.

A subdefinition may require that the transaction be cosigned by another address:

["cosigned by", "ANOTHER ADDRESS IN BASE32"]

One very useful condition can be used to make queries about data previously stored in Byteball:

["in data feed", [
  ["ADDRESS1", "ADDRESS2", …],
  "data feed name",
  "=",
  "expected value"
]]

This condition evaluates to true if there is at least one previous message stored in Byteball database that has "data feed name" equal to "expected value".  The data feed must be posted to Byteball decentralized database by one of the oracles whose addresses are "ADDRESS1", "ADDRESS2", ...  Since oracles post to the common database, we call them on-chain oracles.

On-chain oracles are a very powerful thing indeed.  For example, this address definition represents a binary option:

["or", [
  ["and", [
    ["address", "ADDRESS 1"],
    ["in data feed", [["EXCHANGE ADDRESS"], "EURUSD", ">", "1.1500"]]
  ]],
  ["and", [
    ["address", "ADDRESS 2"],
    ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]
  ]]
]]

It relies on two oracles, one is posting EUR/USD exchange rate, the other is posting the current time.  Initially, the two parties fund the address defined by this definition by sending their respective stakes to the address.  Then if the EUR/USD exchange rate published by the exchange address ever exceeds 1.1500, the first party can sweep the funds.  If this doesn’t happen before Oct 1, 2016 and the timestamping oracle posts any later date, the second party can sweep all the funds stored on this address.

Another example would be a customer who buys goods from a merchant but he doesn’t quite trust that merchant and wants his money back in case the goods are not delivered.  The customer pays to a shared address defined by:

["or", [
  ["and", [
    ["address", "MERCHANT ADDRESS"],
    ["in data feed", [["FEDEX ADDRESS"], "tracking", "=", "123456"]]
  ]],
  ["and", [
    ["address", "BUYER ADDRESS"],
    ["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">", "2016-10-01 00:00:00"]]
  ]]
]]

The definition depends on the FedEx oracle that posts tracking numbers of all successfully delivered shipments.  If the shipment is delivered, the merchant will be able to unlock the money using the first condition.  If it is not delivered before the specified date, the customer can take his money back.  This example is somewhat crazy because it requires FedEx to post each and every shipment.  See the white paper for a more practical way to achieve the same result.

A definition can also include queries about the transaction itself, which can be used for example to code limit orders on a decentralized exchange.  Assume that a user wants to buy 1,200 units of some asset for which he is willing to pay no more than 1,000 bytes (the native currency of Byteball).  Also, he is not willing to stay online all the time while he is waiting for a seller.  He would rather just post an order at an exchange and let it execute when a matching seller comes along.  He can create a limit order by sending 1,000 bytes to an address defined by this definition:

["or", [
  ["address", "USER ADDRESS"],
  ["and", [
    ["address", "EXCHANGE ADDRESS"],
    ["has", {
      what: "output",
      asset: "ID of alternative asset",
      amount_at_least: 1200,
      address: "USER ADDRESS"
    }]
  ]]
]]

The first or-alternative lets the user take back his bytes whenever he likes, thus cancelling the order.  The second alternative delegates the exchange the right to spend the funds, provided that another output on the same transaction pays at least 1,200 units of the other asset to the user’s address.  The exchange would publicly list the order, a seller would find it, compose a transaction that exchanges assets, and sign it together with the exchange.  Note that the exchange does not receive arbitrary control over the user's funds, it can spend them only if it simultaneously pays the alternative asset to the user, while the user retains full control over his funds and can withdraw them from the contract when he likes.

You can combine the above and a few other boolean constructs (see the white paper) to encode many of the clauses you are likely to see in real-life legal contracts.  And the language is clear, straightforward, and it directly expresses the intent of the contract parties.

This language is already used in Byteball, you can view the source code and create tools that make use of the language.





Simplicity is beauty
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513219672
Hero Member
*
Offline Offline

Posts: 1513219672

View Profile Personal Message (Offline)

Ignore
1513219672
Reply with quote  #2

1513219672
Report to moderator
str4wm4n
Legendary
*
Offline Offline

Activity: 1602


View Profile
January 29, 2017, 10:18:28 PM
 #2

I am really interested in seeing some Byteball smart contracts in action.

"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!

Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?

There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.
tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
January 30, 2017, 12:21:15 PM
 #3

I am really interested in seeing some Byteball smart contracts in action.

"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!

Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?

There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.

Smart contracts are already in action on the trustless exchange on testnet https://byteball.org/testnet.html.

It is possible to implement a better contract than Double Deposit Escrow, see the fedex example above.

Simplicity is beauty
Arvydas77
Hero Member
*****
Offline Offline

Activity: 588



View Profile WWW
January 30, 2017, 12:50:04 PM
 #4

In my opinion, Byteball is one of the most revolutionary projects after Bitcoin was launched. It solves Bitcoin scalability limits and gives many advantages to Byteball users. I hope to see more use cases with Byteball in the future but start is really promising.   

█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
.
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
.
█ █
█ █
█ █
█ █
█ █
█ █
█ █
█ █
dzimbeck
Legendary
*
Offline Offline

Activity: 1316


View Profile
January 31, 2017, 03:26:14 AM
 #5

I am really interested in seeing some Byteball smart contracts in action.

"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!

Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?

There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.

Smart contracts are already in action on the trustless exchange on testnet https://byteball.org/testnet.html.

It is possible to implement a better contract than Double Deposit Escrow, see the fedex example above.

It's not "better" than double deposit escrow! Thats crazy talk. The fedex example doesn't work because fedex doesn't know the CONTENTS of the box. Double deposit escrow is meant to stop deception forever. This means only the two parties involved know about the truth of the deal. A tracking number system can be gamed by filling boxes with incorrect items or making them empty. It can harm buyer on purchases and seller on returns (depending on who the platform favors). Double deposit is superior to all escrow systems and it always will be due to its purity. There is no middleman in DDE, thats the point. It forces both parties to put a deposit and only they can sign off on it. Oracles are no different from judges and juries. Biased third parties that have no knowledge of the truth beyond superficial guesses.

WITH THAT SAID,
Byteball is doing something new and amazing. They are enhancing the p2sh multisig accounts by making them much more legible. Instead of n of m keys they can give different keys weight which eliminates the need for redundant keys. So its basically better multisig.

Byteball can do double deposit escrow pretty easily with this in a couple transactions using a Halo protocol. If they have locktimes they can even do it in one elegant transactions (not sure what codebase supports but would highly recommend locktimes)
tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
February 02, 2017, 10:33:45 PM
 #6

I am really interested in seeing some Byteball smart contracts in action.

"This language is already used in Byteball, you can view the source code and create tools that make use of the language."
A guide for this would be really useful!

Specifically I would like to know if it is possible to implement a Double Deposit Escrow contract
using Blackbytes?

There's really TONS of potential here and I'm really surprised this thread hasn't gotten much love.

Smart contracts are already in action on the trustless exchange on testnet https://byteball.org/testnet.html.

It is possible to implement a better contract than Double Deposit Escrow, see the fedex example above.

It's not "better" than double deposit escrow! Thats crazy talk. The fedex example doesn't work because fedex doesn't know the CONTENTS of the box. Double deposit escrow is meant to stop deception forever. This means only the two parties involved know about the truth of the deal. A tracking number system can be gamed by filling boxes with incorrect items or making them empty. It can harm buyer on purchases and seller on returns (depending on who the platform favors). Double deposit is superior to all escrow systems and it always will be due to its purity. There is no middleman in DDE, thats the point. It forces both parties to put a deposit and only they can sign off on it. Oracles are no different from judges and juries. Biased third parties that have no knowledge of the truth beyond superficial guesses.

WITH THAT SAID,
Byteball is doing something new and amazing. They are enhancing the p2sh multisig accounts by making them much more legible. Instead of n of m keys they can give different keys weight which eliminates the need for redundant keys. So its basically better multisig.

Byteball can do double deposit escrow pretty easily with this in a couple transactions using a Halo protocol. If they have locktimes they can even do it in one elegant transactions (not sure what codebase supports but would highly recommend locktimes)

Correct, this fedex example is not ideal because the contents of the box are not guaranteed.  However, a similar contract can be applied to other transactions where the contents of the "box" are known in advance and not gameable.  For example, a cryptocurrency exchange transaction wherein transaction output serves the same role as tracking number.

DDE, while also possible with Byteball, is not ideal either: it is more complex because requires two coordinated steps, it is more capital intensive because it requires deposits, and it fails to admit that the two parties might have different perceived value of money, hence the party that needs money more and faster is more willing to unlock the deposits ASAP, therefore more vulnerable.

Legibility of smart contracts is of utmost importance indeed.  It empowers the users to actually use the smart contracts and move money in ways that were not available to them before crypto, reduce the requirement of trust (and therefore regulation) without making the developer of the contract a new trust anchor.

Simplicity is beauty
superresistant
Legendary
*
Offline Offline

Activity: 1680



View Profile
March 07, 2017, 11:45:28 AM
 #7

 
I just did a smart contract in Byteball : mind blow.



Here's my bag so you don't ask : Bitcoin, tenX, iexec, byteball and pepecash
iamnotback
Sr. Member
****
Offline Offline

Activity: 336



View Profile
March 07, 2017, 07:22:27 PM
 #8

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks.

Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also.

So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply.
tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
March 08, 2017, 12:16:33 AM
 #9

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks.

Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also.

So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply.

There is a limit on the number of operations per smart contract, data feed lookups included.

It is not a panacea.  It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows. 

If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context).  When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation.

Simplicity is beauty
iamnotback
Sr. Member
****
Offline Offline

Activity: 336



View Profile
March 08, 2017, 03:03:49 AM
 #10

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks.

Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also.

So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply.

There is a limit on the number of operations per smart contract, data feed lookups included.

It is not a panacea.  It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows.  

If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context).  When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation.

But my point is you can't prevent in the wild people from creating convoluted smart contracts even with your intended to be simple declarative language. Do you really expect users to give a damn and look at the source code of the smart contract? Users demand features such as DAOs. So I don't think you can stop the developers from bastardizing yours as well. Preventing Turing-completeness is very difficult. This is why Bitcoin is very cautious to add new opcodes.
tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
March 08, 2017, 10:52:18 AM
 #11

When you entrust your money to a smart contract, you want to be absolutely sure that the contract operates as you expect (remember TheDAO?).  One way to achieve this is by having a smart contract language that is designed to express what the contract expects, rather than how it accomplishes its goals.  This is exactly what declarative languages do.

The purpose of this post is to introduce the declarative smart contract language I chose for Byteball, the cryptocurrency I recently launched.  The language is designed to be as easy to understand as possible, so that even non-developer can immediately see what a contract means by just looking at its code.  The language values clarity over power and it is not as powerful as Ethereum's Solidity.  It is not turing-complete, and you cannot write even 'Hello world' program in this language.  But it is able to solve many practical business tasks.

Although each executed instance of your language is not Turing-complete in isolation, the system of instances is Turing-complete because you have the ability to reference global memory in the form of the data feed. Thus you can still have scenarios of unbounded recursion and even live or dead locks.

Craig Wright had schooled Nick Szabo and Gregory Maxwell on this point also.

So you have not prevented hacks. And you have somewhat crippled the language compared to Solidarity. You may argue you've made the intent clearer, but when people write convoluted systems with this in order to achieve complex smart contracts by simulating Turing completeness, then it may end up more obfuscated than Solidarity. I really don't see your design strategy as the absolute panacea you seem to claim or imply.

There is a limit on the number of operations per smart contract, data feed lookups included.

It is not a panacea.  It is designed to meet the demands of regular users, and they are not convoluted, as the recent superresistant's example shows.  

If you need convoluted, go with Solidity, but be extremely careful when you expose complex systems to regular users (unaccredited investors, if we consider investments context).  When users are exposed to complex systems that they don't fully understand and that can potentially harm them, the governments will want to "protect the consumer" -- by regulation.

But my point is you can't prevent in the wild people from creating convoluted smart contracts even with your intended to be simple declarative language. Do you really expect users to give a damn and look at the source code of the smart contract? Users demand features such as DAOs. So I don't think you can stop the developers from bastardizing yours as well. Preventing Turing-completeness is very difficult. This is why Bitcoin is very cautious to add new opcodes.

I can't stop them but hopefully most developers are smart enough to find the best tool for the purpose, and there is no lack of choice.  Even if they do create something convoluted against all odds, let's see if they find many users.

Quote
Do you really expect users to give a damn and look at the source code of the smart contract?

I dare say yes, if we speak the user's language.  The nice thing about Byteball smart contracts is that they can be easily presented in user readable form:



This example is from my article https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.3k1a7f5yo

Simplicity is beauty
iamnotback
Sr. Member
****
Offline Offline

Activity: 336



View Profile
March 09, 2017, 12:15:37 AM
 #12

But my point is you can't prevent in the wild people from creating convoluted smart contracts even with your intended to be simple declarative language. Do you really expect users to give a damn and look at the source code of the smart contract? Users demand features such as DAOs. So I don't think you can stop the developers from bastardizing yours as well. Preventing Turing-completeness is very difficult. This is why Bitcoin is very cautious to add new opcodes.

I can't stop them but hopefully most developers are smart enough to find the best tool for the purpose, and there is no lack of choice.  Even if they do create something convoluted against all odds, let's see if they find many users.

Quote
Do you really expect users to give a damn and look at the source code of the smart contract?

I dare say yes, if we speak the user's language.  The nice thing about Byteball smart contracts is that they can be easily presented in user readable form:



This example is from my article https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.3k1a7f5yo

That is nice and intriguing. I don't fault you for coming up with interesting ideas.

But the masses are trending to chatbots, i.e. more hand-holding not less.

Some astute investors and those who have a fiduciary responsibility (even to only themselves) may care to study that, but IMO most won't.

For your near-term speculation markets or expert-level financial markets adoption, that is a feature. For real-world mass adoption, I don't know how much so. I think the more important feature for mass adoption is making sure the masses are never hacked en mass a la the DAO.
Limx Dev
Legendary
*
Offline Offline

Activity: 1162


bitsend.info | bitcore.cc


View Profile
March 12, 2017, 09:52:59 AM
 #13

Smart Conract easy to use. Great Work!

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Segwit | Core 0.14 | Masternodes
XEVAN | DK3 | Electrum soon
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
Litebit.eu | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
testerx
Hero Member
*****
Offline Offline

Activity: 591



View Profile
March 12, 2017, 04:24:36 PM
 #14

I dare say yes, if we speak the user's language.  The nice thing about Byteball smart contracts is that they can be easily presented in user readable form:



This example is from my article https://medium.com/byteball/making-p2p-great-again-fe9e20546a4a#.3k1a7f5yo

I really have to say that so far the byteball UX is very well thought out and implemented, especially considering that it just launched so recently.  You've obviously put years of effort into it before showing it to the world.  I've been testing it out and so far it's honestly the best implementation for actual end users I've seen so far.  I was honestly shocked at how polished it all is, since most projects don't really put much effort into being user friendly at launch, but byteball is already easier to use than even Bitcoin. Pity I didn't find out before the first round, the actual usability of byteball is already above pretty much everything else.


tonych
Hero Member
*****
Offline Offline

Activity: 588


View Profile WWW
March 19, 2017, 09:44:28 AM
 #15

Now payments can be bound to real world events:
https://medium.com/byteball/making-p2p-great-again-episode-ii-bitcoin-exchange-d98adfbde2a5

Simplicity is beauty
dfd1
Full Member
***
Offline Offline

Activity: 126


View Profile
March 19, 2017, 10:18:49 AM
 #16

Byteball is a javascript toy and people take it too seriously. This nonsense should be ended before people realize there is no real technology, no real witnesses, no ability to scale or process any significant ammount of transactions, no proofs dev can't generate billions of coins out of his ass because he own all the master keys, no ability to block hardfork then someone (a "hacker") put wrong wallet on website. A javascript toy. Three month old coin already ask you to download blockchain separately, because wallet can't sinc. Wallet can only chat with you and crash.
SatoNatomato
Sr. Member
****
Offline Offline

Activity: 322


View Profile
March 19, 2017, 09:49:46 PM
 #17

...
Lol.

Looks like Byteball attracted its own trolls. Probably Come-from-Beyonds sockpuppets.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1792

Newbie


View Profile
March 19, 2017, 10:45:17 PM
 #18

...
Lol.

Looks like Byteball attracted its own trolls. Probably Come-from-Beyonds sockpuppets.

Interesting coincidence. I was playing with writing style analyzer yesterday and found another account of Qora developer. You could use this technique to compare my style and style of dfd1...
dfd1
Full Member
***
Offline Offline

Activity: 126


View Profile
March 19, 2017, 11:24:42 PM
 #19

...
Lol.

Looks like Byteball attracted its own trolls. Probably Come-from-Beyonds sockpuppets.
I want to know dev opinion on this. He know for sure how genesis block was generated and how new coins can or can not be made. And dev comes here sometimes.
Also I'm somehow sure big transaction flow can't pass through WebSocket, but there is probably some tests around to debunk it, will wait to see how I'm proved wrong. Also there is probably something wrong on my side, because wallet I downloaded today can't sinc and crashes? I'm sure there is no problem like this appear for other users. And who are these mysterious witnesses we trust so much? I'm sure it's not dev nodes. They changed rapidly to some trusted guys list over three months.  Anyway, would like to see dev opinion.
But who I am and who dev is? Silly me, he probably above it all and don't have time for "trolls" and "Come-from-Beyonds sockpuppets"
yvv
Legendary
*
Offline Offline

Activity: 1330

Moirai Pre-ICO starts on 28.10.2017


View Profile WWW
March 19, 2017, 11:33:55 PM
 #20

...
Lol.

Looks like Byteball attracted its own trolls. Probably Come-from-Beyonds sockpuppets.
I want to know dev opinion on this. He know for sure how genesis block was generated and how new coins can or can not be made. And dev comes here sometimes.

Yeah, right. If you want to know dev opinion, good way to start is to write in his thread that what he does is a shit toy and nonsense. Nice try. Don't give up, keep trying.

         ▀█████▀
▀▄         ███         ▄▀
  █▄       ███       ▄█
   ██      ███      ██
    ██     ███     ██
    ▀██▄▄  ███  ▄▄██▀
      ▀███████████▀
         ▀▀███▀▀
           ███
           ███
           ███
           ███
         ▄█████▄
.MOIRAI.
  ██████
██████
█████
███
███
███
███
███
███
███
███

██████
██████
  █████
      ███
      ███
      ███
      ███
      ███
      ███
      ███
        ███

    ▄█████
    ██████
    ███▀
    ███
███████
███████
    ███
    ███
    ███
    ███
    ███

█▄                ▄████▄
██▄             ███████▄▄▄
▀███▄▄      █████████▄
  ▀███████████████▀
▀████████████████
    ▀█████████████
  ▀█████████████
      ▀▀█████████
    ▄▄████████▀
██████████▀
    ▀▀▀▀▀

                              ▄▄██
                        ▄██████
                  ▄████▀▀███
            ▄█████▀  ▄████
      ▄██████▀  ▄██████
▄███████▀  ▄████████
  ▀▀▀▀███    █████████
            ██    █████████
            ▀█  ▄█▀    ▀████
              ██▀            ▀██
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!