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
Messaging and blockchain data storage
Haposhi
Member Posts: 14 ✭
Hi Vitalik/all,
I am interested in the native support for secure communications for ethereum, which I discovered on reddit while trying to find support for my own project. I have a few questions before I give you all my Bitcoins.
reddit.com/r/CryptoCurrency/comments/1uyvif/textcoin_development_thread_secure_communication/
I'm not sure I understand about contracts. Is it correct that they are added to the blockchain, and miners execute the code they contain if a transaction is sent to the contract address? It seems that for lots of contract programs, you would need to send data inputs in addition to the balance transferred and the sender address. Does this mean that it will be possible to send data as part of an transaction?
If so, it should be very simple to add the ability to send messages to other users as part of a transaction that is added to the blockchain. As the wallet addresses are not the entire public key, is there a list of addresses with their public keys in the blockchain? I think this would be required to encrypt with someone's private key so that only they can read a message that has been sent to them.
This would also make it possible to publish or securely store data in the blockchain.
I also have some questions about fees. They all scale with x, which depends on the difficulty, which appears to be the overall PoW difficulty, and depends only on the network hashrate. It seems that some of them should have additional modifiers based on their apparent rationale.
I'll look at each of them in turn here. Sorry if I'm missing the point, and please forgive my presumptuousness.
TXFEE (100x) - fee for sending a transaction
This could be proportional to the amount of data added to the blockchain, to disincentive storage and network bloat.
NEWCONTRACTFEE (100x) - fee for creating a new contract, not including the memory fee for each item in script code
This could also be proportional to the contract filesize. Modifying the contract should incur the same fee.
STEPFEE (x) - fee for every computational step after than first sixteen in contract execution
No problems here.
MEMORYFEE (100x) - fee for adding a new item to a contract's memory, including when first creating a contract. The memory fee is the only fee that is not paid to a miner, and is refunded when memory from a contract is removed.
Wouldn't it make sense to make the memory fee for a contract proportional to the amount of memory the contract takes up when loaded (+ a constant)?
Is memory allocated for all contracts for all miners, or just when the contract is activated by a transaction? In the latter case, I don't see why the fee should be refunded.
DATAFEE (20x) - fee for accessing or setting a contract's memory from inside that contract
Is contract memory data stored on the blockchain in the miner's hard drive? If it's the local miner instance, they will be accessing their own memory, and I believe this will need to be done for every computational step from the contract code.
EXTROFEE (40x) - fee for accessing memory from another contract inside a contract
Same as above. If this is looking up data from the blockchain, it shouldn't matter which contract is being read from, and I don't see why the fee should be higher.
CRYPTOFEE (20x) - fee for using any of the cryptographic operations
No problems here.
I'm going to write about some ideas for contracts/templates I have now.
Exciting stuff, there's so much potential here.
H
I am interested in the native support for secure communications for ethereum, which I discovered on reddit while trying to find support for my own project. I have a few questions before I give you all my Bitcoins.
reddit.com/r/CryptoCurrency/comments/1uyvif/textcoin_development_thread_secure_communication/
I'm not sure I understand about contracts. Is it correct that they are added to the blockchain, and miners execute the code they contain if a transaction is sent to the contract address? It seems that for lots of contract programs, you would need to send data inputs in addition to the balance transferred and the sender address. Does this mean that it will be possible to send data as part of an transaction?
If so, it should be very simple to add the ability to send messages to other users as part of a transaction that is added to the blockchain. As the wallet addresses are not the entire public key, is there a list of addresses with their public keys in the blockchain? I think this would be required to encrypt with someone's private key so that only they can read a message that has been sent to them.
This would also make it possible to publish or securely store data in the blockchain.
I also have some questions about fees. They all scale with x, which depends on the difficulty, which appears to be the overall PoW difficulty, and depends only on the network hashrate. It seems that some of them should have additional modifiers based on their apparent rationale.
I'll look at each of them in turn here. Sorry if I'm missing the point, and please forgive my presumptuousness.
TXFEE (100x) - fee for sending a transaction
This could be proportional to the amount of data added to the blockchain, to disincentive storage and network bloat.
NEWCONTRACTFEE (100x) - fee for creating a new contract, not including the memory fee for each item in script code
This could also be proportional to the contract filesize. Modifying the contract should incur the same fee.
STEPFEE (x) - fee for every computational step after than first sixteen in contract execution
No problems here.
MEMORYFEE (100x) - fee for adding a new item to a contract's memory, including when first creating a contract. The memory fee is the only fee that is not paid to a miner, and is refunded when memory from a contract is removed.
Wouldn't it make sense to make the memory fee for a contract proportional to the amount of memory the contract takes up when loaded (+ a constant)?
Is memory allocated for all contracts for all miners, or just when the contract is activated by a transaction? In the latter case, I don't see why the fee should be refunded.
DATAFEE (20x) - fee for accessing or setting a contract's memory from inside that contract
Is contract memory data stored on the blockchain in the miner's hard drive? If it's the local miner instance, they will be accessing their own memory, and I believe this will need to be done for every computational step from the contract code.
EXTROFEE (40x) - fee for accessing memory from another contract inside a contract
Same as above. If this is looking up data from the blockchain, it shouldn't matter which contract is being read from, and I don't see why the fee should be higher.
CRYPTOFEE (20x) - fee for using any of the cryptographic operations
No problems here.
I'm going to write about some ideas for contracts/templates I have now.
Exciting stuff, there's so much potential here.
H
Comments
Yes, although that's not really the intent; recovering data from the data fields is not SPV-friendly, so I don't really expect applications to use the transaction data fields to store messages. But you can come up with whatever setup you want using forwarding contracts. So sending transactions with embedded data will definitely be not hard to do.
> This could also be proportional to the contract filesize. Modifying the contract should incur the same fee.
Actually, you need to pay a MEMORYFEE and a DATAFEE for every instruction that you add into the contract. So that essentially already exists.
> Is contract memory data stored on the blockchain in the miner's hard drive? If it's the local miner instance, they will be accessing their own memory, and I believe this will need to be done for every computational step from the contract code.
Yes, it's stored on the hard drive. But the idea is that looking up data would require a database access, which is much more expensive than just computing some stuff.
> Same as above. If this is looking up data from the blockchain, it shouldn't matter which contract is being read from, and I don't see why the fee should be higher.
We might remove the EXTROFEE, haven't decided yet.
I'm not sure what you mean about the data fields. As the transaction does not know what input variables the contract will accept, the 'message' or data sent as part of a transaction will have to be in a general format, presumably a text field.
This way, you can send any data inputs as text, separated by commas so that it matches the contract inputs.
This should mean that it is very easy to extract the data, as it is just plaintext (unless the whole thing is encrypted).
Maybe I'm confused about how this special blockchain works. If transactions aren't stored in the form they are received in by the miners, then they cannot be used for long-term storage. In this case, the only places to store data are in contract 'memory', and in the balance sheet, which will only store ether balances I assume.
An array to be precise.
> This should mean that it is very easy to extract the data, as it is just plaintext (unless the whole thing is encrypted).
The data is extractable. I'm just saying that the data is not extractable by light clients efficiently the same way state data is (ie. if you care about verification you have to download the transaction list of an entire block). That's why I don't advocate doing it that way.
> In this case, the only places to store data are in contract 'memory', and in the balance sheet, which will only store ether balances I assume.
Contract memory is optimal IMO. It's there to store stuff!
Also, you might be interested in this; we are thinking of contacting and cooperating with BitMessage so Ethereum provides a Namecoin-like contract so you can send BitMessages to human-friendly names like "george" instead of "BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash". So there are a lot of ways these different ideas can interact.