We contend that the human race needs a service which provides randomness or entropy in a decentralized and trustless manner. Quality entropy has many applications including in scientific research/simulations and cryptology (very important as Random Number Generators [RNGs] are often the weak link in an otherwise strong security implementation).
True Random Number Generation is a difficult task. It may be possible to utilize the Counterparty and Bitcoin Networks to generate quality randomness (not necessarily just by including an RNG in the Counterparty Protocol but by utilizing market behavior, particularly of carefully constructed purpose built prediction markets for example). Distribution of the randomness to a group of people is also a difficult task (but could be made easier by utilizing a Common Knowledge System like the Bitcoin Blockchain).
We call this endeavour The Anesidora Project. Some of the goals of the project are outlined and reiterated as follows:
[1] Provide True Randomness as a service to everyone
[2] Provide both public randomness and randomness for individuals and groups of individuals (as anonymously as possible)
[3] Develop an ecosystem around the entropy provision allowing computers, operating systems and applications to retrieve entropy as needed
To get your head around this idea, imagine a decentralized version of the following: http://www.nist.gov/itl/csd/ct/nist_beacon.cfm. But imagine if it was sufficient for use in cryptology applications and if the entropy could be shared with groups of individuals privately. Another useful resource - http://www.rsaconference.com/writable/presentations/file_upload/asec-t07b-the-nist-randomness-beacon_final.pdf.
The Counterparty Broadcast feature could be used as a randomness beacon for any Entropy Provider as it would allow for 3rd party analysis of the quality of the random numbers generated.
One approach that we imagine this project could take is as a fork of or additional feature to the Vennd.io project.
Example:
[1] User sends XCP to the Vennd Entropy address. Say, 1 XCP for 1024 bits of entropy.
[2] User specifies the receiving Public Key address(es).
[3] Vennd webpage or vending machine provides you with an order number.
[4] Vennd generates the required entropy
[5] Vennd encrypts the entropy with each of the public keys provided
[6] Vennd embeds the encrypted entropy in the Bitcoin Blockchain (possibly via OP Return so that it is prunable) with the order number appended
[7] Receivers search the blockchain for data embedded by Vennd and the specific order number of interest
[8] Receivers decrypt the entropy so that they have pseudonymously received a shared secret chunk of truly random data
While this idea is rough we feel it is better to engage the community with it as quickly as possible. Please discuss and critique.
[quote author=Equality 7-2521 link=topic=381.msg2584#msg2584 date=1402304005]
We contend that the human race needs a service which provides randomness or entropy in a decentralized and trustless manner. Quality entropy has many applications including in scientific research/simulations and cryptology (very important as Random Number Generators [RNGs] are often the weak link in an otherwise strong security implementation).
[…]
One approach that we imagine this project could take is as a fork of or additional feature to the Vennd.io project.
Example:
[1] User sends XCP to the Vennd Entropy address. Say, 1 XCP for 1024 bits of entropy.
[2] User specifies the receiving Public Key address(es).
[3] Vennd webpage or vending machine provides you with an order number.
[4] Vennd generates the required entropy
[5] Vennd encrypts the entropy with each of the public keys provided
[6] Vennd embeds the encrypted entropy in the Bitcoin Blockchain (possibly via OP Return so that it is prunable) with the order number appended
[7] Receivers search the blockchain for data embedded by Vennd and the specific order number of interest
[8] Receivers decrypt the entropy so that they have pseudonymously received a shared secret chunk of truly random data
While this idea is rough we feel it is better to engage the community with it as quickly as possible. Please discuss and critique.
[/quote]
Pretty darned interesting idea and a novel use of Vennd! As you indicated, it would require quite some customizations in Vennd to achieve. Some feedback on the technical aspects of the process.
* If the person creating the send to Vennd had very good control over unspent output addresses to be included in a TX, then it would be possible for Vennd to simply use all the input addresses to a TX as the addresses for encryption.
* Unfortunately, most people won’t have such control such that a web page would be necessary
* The current maximum size of OP_RETURN is 40 bytes. Many people would be against storing the payload in the blockchain (though I’m neutral - if you pay, then you should be able to use it).
* If you don’t store the payload into the blockchain, you could store some kind of pointer to an external location
* If you wish to store the payload into the blockchain, you will need to split the data and store it across multiple transactions as OP_RETURN is probably not large enough. It would be easier if there was a small utility that could join the data back together.
* If you needed to create a small utility that joins data back together, you could consider a small utility which specially crafts the TX to Vennd with specific addresses.
* It would be slightly less efficient but you could consider using a Counterparty broadcast message as part of the process
Regards,
Jeremy.
[quote author=Global_trade_repo link=topic=381.msg2585#msg2585 date=1402309793]
Pretty darned interesting idea and a novel use of Vennd! As you indicated, it would require quite some customizations in Vennd to achieve. Some feedback on the technical aspects of the process.
* If the person creating the send to Vennd had very good control over unspent output addresses to be included in a TX, then it would be possible for Vennd to simply use all the input addresses to a TX as the addresses for encryption.
* Unfortunately, most people won’t have such control such that a web page would be necessary
* The current maximum size of OP_RETURN is 40 bytes. Many people would be against storing the payload in the blockchain (though I’m neutral - if you pay, then you should be able to use it).
* If you don’t store the payload into the blockchain, you could store some kind of pointer to an external location
* If you wish to store the payload into the blockchain, you will need to split the data and store it across multiple transactions as OP_RETURN is probably not large enough. It would be easier if there was a small utility that could join the data back together.
* If you needed to create a small utility that joins data back together, you could consider a small utility which specially crafts the TX to Vennd with specific addresses.
* It would be slightly less efficient but you could consider using a Counterparty broadcast message as part of the process
Regards,
Jeremy.
[/quote]
Thank you. This is just the type and quality of feedback and discussion that we desire. There are certain applications where the point you make about the unspent outputs is nice because the entire service request and provision is kept within the blockchain. Is including the data in OP_RETURN not the optimal way to include data in the blockchain as it doesn’t have to lead to blockchain bloat? We can imagine distributing entropy in 128 bit (16 byte) chunks which would fit nicely in an OP_RETURN.
Indeed, storing or pointing to a torrent file or magnet link (for example) for larger batches of entropy would be good practice for certain applications.
We do like the idea of a small utility/app/plugin that could handle the various input and output scenarios.
However, we are envisaging the most difficult scenario where a group of pseudonymous individuals wish to communicate in secret and so need to share a secret seed/key (quality random data). This surely should require some off-chain activity, something that a Vennding machine can provide. And the shared secret seed ought to be stored in the common knowledge blockchain as any other point to point communication channel could be vulnerable to a man-in-the-middle attack. The individual in charge of the Entropy Vennding machine in question needn’t be trusted to keep logs or not in this case as the public-key/private-key pairs involved in the encryption/decryption will only be used once (best practice, like the way one must use a one-time pad only once or it defeats the purpose).
[quote author=Equality 7-2521 link=topic=381.msg2596#msg2596 date=1402389346]
Thank you. This is just the type and quality of feedback and discussion that we desire. There are certain applications where the point you make about the unspent outputs is nice because the entire service request and provision is kept within the blockchain. Is including the data in OP_RETURN not the optimal way to include data in the blockchain as it doesn’t have to lead to blockchain bloat? We can imagine distributing entropy in 128 bit (16 byte) chunks which would fit nicely in an OP_RETURN.
Indeed, storing or pointing to a torrent file or magnet link (for example) for larger batches of entropy would be good practice for certain applications.
We do like the idea of a small utility/app/plugin that could handle the various input and output scenarios.
However, we are envisaging the most difficult scenario where a group of pseudonymous individuals wish to communicate in secret and so need to share a secret seed/key (quality random data). This surely should require some off-chain activity, something that a Vennding machine can provide. And the shared secret seed ought to be stored in the common knowledge blockchain as any other point to point communication channel could be vulnerable to a man-in-the-middle attack. The individual in charge of the Entropy Vennding machine in question needn’t be trusted to keep logs or not in this case as the public-key/private-key pairs involved in the encryption/decryption will only be used once (best practice, like the way one must use a one-time pad only once or it defeats the purpose).
[/quote]
From Bitcoin purist point of view, OP_RETURN isn’t completely optimal to store arbitrary data. Nodes which don’t prune OP_RETURN would still need to carry this data forever.
I’m of a neutral position whether arbitrary information should be stored in the block chain. My personal opinion is that since it is possible, then it should be allowed and mechanisms put in place to avoid abuse. i.e. pay to use.
Have you considered the use of Bitmessage https://bitmessage.org/wiki/Main_Page as a communications channel? One word of caution is that I don’t believe bitmessage has undergone an official security audit.