Categories
- 17.3K All Categories
- 9.5K Mining
- 574 Pool Discussion
- 378 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 811 Protocol and Client discussion
- 170 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 471 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 226 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 185 Russian
- 231 Spanish
- 47 Turkish
- 125 Watercooler
Is MKTX broken?
mode80
Member Posts: 64 ✭✭
I'm trying to get a first smart contract working. I started more ambitions but now I've retreated to the simplest thing I can think of:
In LLL, this contract just receives an amount and refunds it to the sender.
(mktx (txsender) (txvalue) 0)
It produces this EVM which looks fine:
PUSH 0x0 TXVALUE TXSENDER MKTX
Using OSX AlethZero, I send 1000 finney to an empty address with the above code as the data. After the next block is mined, I see my contract is created at 929ec83f.. and is has a balance of 1000finney as expected. Checking it's contents in the contracts pane, I see my code. So far so good.
Now to test it, I send 100finney to the 929ec83f.. contract (data field left empty). After the next block is mined, I see that transaction. The contract's new balance is 980finney. This suggests that the contract received the finney, sent it back, and consumed another 20finney in execution fees. I expect to see a transaction refunding 100finney back to my sending address on the next block. However, this doesn't appear.
What went wrong?
In LLL, this contract just receives an amount and refunds it to the sender.
(mktx (txsender) (txvalue) 0)
It produces this EVM which looks fine:
PUSH 0x0 TXVALUE TXSENDER MKTX
Using OSX AlethZero, I send 1000 finney to an empty address with the above code as the data. After the next block is mined, I see my contract is created at 929ec83f.. and is has a balance of 1000finney as expected. Checking it's contents in the contracts pane, I see my code. So far so good.
Now to test it, I send 100finney to the 929ec83f.. contract (data field left empty). After the next block is mined, I see that transaction. The contract's new balance is 980finney. This suggests that the contract received the finney, sent it back, and consumed another 20finney in execution fees. I expect to see a transaction refunding 100finney back to my sending address on the next block. However, this doesn't appear.
What went wrong?
Comments
But wait. This raises an important question. No generated transaction would mean that ethereum's design foils any kind of basic accounting best practices. To a human, contracts would be these black boxes where money goes in and balances "magically" change without any clear evidence of how.
Ethereum is the accounting system to end all accounting systems, but it has no ledger? Please let this be wrong.
The contract execution already implies that there is this additional transaction, and it can be calculated from the facts that this transaction existed. An explorer could whip up those transactions. (Given balances, i dont think you can easy run contracts backwards though? So you'd need info older than what you want to look at, oldest being the genesis block)
If something can easily be determined from the record, it might aswel *be* on the record. Saving things on hard disks doesnt make continguous files on the disk; it may be spread around where there is space. Cutting paper into pieces and reassembling when you need it are also not 'basic accounting best practices', but that is how it sometimes works on your harddisk. If you dont care about that, you shouldnt care about this either. Just exploring the bytes on your harddisk, you will be hard-pressed to find your files even if they were whole.
Say you want to create a contract that runs a small-scale lottery. The contract is programmed to accept .001 ether, and up on reaching 1 ether, send the full amount to a lucky winner. Because the ether is sent by the contract (using MKTX) there is no record of the transfer. Nobody will have any idea where the ether was sent and no ready way to find out.
Even if this does not bother you, it is still an uncomfortable inconsistency that one method of sending funds (via the client) creates a record of the transfer, and the other method (via MKTX) does not.
The blockchain, often described as a global ledger, would instead be a series of balance snapshots with nothing to connect the state of one to the next.
Only by running every single contract's code under absolutely identical conditions could we link one set of balances to the next. Meanwhile, we strive to make this impossible. (See http://blog.ethereum.org/2014/02/08/cryptographic-code-obfuscation-decentralized-autonomous-organizations-are-about-to-take-a-huge-leap-forward/)
We talk about Ethereum in a future where corporation bylaws exist on the blockchain as DAOs. No serious business will use it for this purpose if its infeasible to determine how money got where it is. The accounting profession has exists for thousands of years because people have a real-world need for that.
I fear this could be a fatal design flaw.
My C++ is rusty, but from my look at the code it appears my fears are correct. I would be grateful if someone else could confirm.
The blockchain is not a set of snapshots. A full node cant even know the balances without running all the code in all the contracts, as initiated by transactions.(a lightweight node can almost trustlessly ask full nodes)
You misunderstand the article you linked. That will not be build into ethereum at all. It is about the potential that people use that technology to create contracts that contain secrets.
But not all contracts will be made that way, and even for the ones that do, every full node neccesarilly still runs the code everyone still sees them run `mktx`, you know *that* the contract did that transaction. That is exactly what is surprising about that technology, you run the whole thing and know all the data, yet it contains a secret.
And even if the technology is used, it may still be for the mere hiding of a private key for instance.
If you gave me an address and I sent you funds with MKTX, could you tell me where the funds came from?
If you cannot, I would suggest this is a big problem.
1) full node sees the transaction on the block, it is signed by some address, and it says it sends it to me. So i know both from, to and the amount.
2) Full node sees a transaction sends to a contract. It executes the script. The script uses mktx, which sends it to me. I can tell that it came from the script, and who triggered it.
3) The contract may have been used earlier, and the new contract just triggers the send but the full node can see the earlier transaction that set that up too. And scripts can call scripts. But it is all perfectly visible, people could make software that indicates all the amounts and messages that came into the script.
You should also realize, if you put it in a pot together, ethers arent idenfiable. If i and you have a pot of 1kg gold dust, and put it together, mix it, then pay 0.1kg to alice, and then i take 0.9kg and you 1kg.. Well you'd probably say it came from me.
I suppose the link about the obfuscation might allow mixing in scripts, without knowing what coin came from whom. But, actually i dont really think there would even be a problem if it wasnt decidable where it came from. All that matters is that the guy that sent them has that amount less and i have that amount-fee more. Law enforcement might be annoyed, but really, if the bastards at the NSA want *all* bank data from *everyone* *always*. I'd rather have them have nothing.
Infact zerocoin and darkcoin were created for that purpose exactly.
The perfect case gives law enforcement some information, but they have to go around with warrants. It would also have a mechanism where nothing is tracable if they piss people off with abuse.
Does that transaction get saved on the blockchain, even when using MKTX? If it does then you're right and none of this is a problem. But from what I can tell it does not.
I don't think the current system is nearly as bad as you think, though. A transaction browsing software could simply display the input tx, and all the output txs (actually balance adjustments) as one transaction, obviating the contract but still making it available to you for further inspection. It might look like this:
my_addr(100eth) -> your_addr (10eth)
..........................-> thatguys_addr (60eth)
If the transaction was triggering a larger payout from the existing contract balance it could be included as an input, so it might just look like this:
my_addr(1 wei) ............-> your_addr(500eth)
contract_addr(500eth)
I do understand that this is still exotic from the POV of classic double entry accounting, but it's not as if it can't be clearly audited. You will know the block # of any balance adjustment against an account, and then you can evaluate the block, which includes running its contracts, to see exactly which transactions sent how much.
That does seem like an ugly way to get at the most basic kind of information a blockchain exists to preserve.
You're right that cash does not create a history but witness the lengths we go to compensating for that deficiency. Every time you buy a stick of gum, a dedicated piece of equipment (cash register) must exist to print out a receipt so that can be accounted for.
If this issue is not fixed directly, the most useful client software -will- allow people to see where their money came from. And the way it'll do that is to re-run all the code that the ethereum network already ran to come to a number that the network already knew. Then it will cache that result in a proprietary database locally so that the user won't have to wait so long to get an answer next time.
I don't have a philosophical problem with private transactions. But this aspect of Ethereum's design is not creating any privacy. It's only making it inefficient and difficult for users to get basic information about their own transactions.
See: https://github.com/ethereum/cpp-ethereum/wiki/LLL-Examples-for-PoC-4
It's less of a show-stopper than I first worried. Client software will work around it by keeping a database of money movement outcomes for each block. This will serve as something of an index for fast access, without re-running all the blockchain scripts. I think this will be so prevalent that it might as well be in the blockchain, but as of now, it is not.