*snip* How easy is it to include a small chunk of text with a transaction? *snip*
As long as it's less than about 256 bytes, you could include it in a txout or txin script. 
Topic: Private/PGP key verified by bitcoin blocks (Question) (Read 854 times)
Just had an idea about this. Could someone verify?
How easy is it to include a small chunk of text with a transaction? I am thinking it may be possible to send such a transaction to create the small chunk of text in a block, then after waiting a certain number of blocks, create a PGP key pair, sign the original chunk of text with the private key, and include the signature in a transaction in the second block. This would create proof that your PGP key pair was created between the time of the first and second blocks, right?
Now the question is, how can you ensure that the random bit of text embedded in the first block was created by the same person creating the PGP key pair, and isn't just someone scanning prior block history for such texts and creating a new key on the spot.
Just thought maybe you could do this with three blocks. Block (X) has some data in it, even if it was there previously, Block (X+1) has a copy of the signed text (maybe even with a unique mining fee amount), and finally Block (X+Y) has a copy of the Block (X) signature signed again. Of course it's easy enough to just register your PGP key with a third party and just wait a while to prove that your key is old enough, so maybe this isn't even needed other than for decentralization purposes...
The reason I'm trying to figure this out is because I would like to create difficult to generate PGP-type keys that rely more on time than hashing power. For example, BitMessage has an option to generate a private key that will shorten your BM address, using extra processing power to come up with a few extra 0's in the address. Same idea works in bitcoin mining. And I'm sure the same idea could be applied to PGP addresses, as well, where the PGP address could require to have some number of repeating characters at the beginning, to show that it took some brute-forcing to generate. Such a key would have some value to it, if only because of the difficulty in generating it (scarcity + used up resources). Problem is, those with more powerful hardware will be able to generate such keys much easier, and as processing power increases, what used to be difficult to generate keys will become simple to make. So I am trying to figure out how to pigyback onto the Bitcoin blockchain's computing power, which is already automatically adjusted for changes in hashing power, and create PGP keys that are based on Proof-of-Time spent generating them, as opposed to simple Proof-of-Work. This time to generate a key could be anywhere from 24 hours to a few months or years.
The idea is to have verifiable PGP keys that prove that whoever generated them put a lot of resources into it, such as "time spent waiting to create it." This would let others easily distinguish valued key-based identities from instantly created sockpuppet types.
How easy is it to include a small chunk of text with a transaction? I am thinking it may be possible to send such a transaction to create the small chunk of text in a block, then after waiting a certain number of blocks, create a PGP key pair, sign the original chunk of text with the private key, and include the signature in a transaction in the second block. This would create proof that your PGP key pair was created between the time of the first and second blocks, right?
Now the question is, how can you ensure that the random bit of text embedded in the first block was created by the same person creating the PGP key pair, and isn't just someone scanning prior block history for such texts and creating a new key on the spot.
Just thought maybe you could do this with three blocks. Block (X) has some data in it, even if it was there previously, Block (X+1) has a copy of the signed text (maybe even with a unique mining fee amount), and finally Block (X+Y) has a copy of the Block (X) signature signed again. Of course it's easy enough to just register your PGP key with a third party and just wait a while to prove that your key is old enough, so maybe this isn't even needed other than for decentralization purposes...
The reason I'm trying to figure this out is because I would like to create difficult to generate PGP-type keys that rely more on time than hashing power. For example, BitMessage has an option to generate a private key that will shorten your BM address, using extra processing power to come up with a few extra 0's in the address. Same idea works in bitcoin mining. And I'm sure the same idea could be applied to PGP addresses, as well, where the PGP address could require to have some number of repeating characters at the beginning, to show that it took some brute-forcing to generate. Such a key would have some value to it, if only because of the difficulty in generating it (scarcity + used up resources). Problem is, those with more powerful hardware will be able to generate such keys much easier, and as processing power increases, what used to be difficult to generate keys will become simple to make. So I am trying to figure out how to pigyback onto the Bitcoin blockchain's computing power, which is already automatically adjusted for changes in hashing power, and create PGP keys that are based on Proof-of-Time spent generating them, as opposed to simple Proof-of-Work. This time to generate a key could be anywhere from 24 hours to a few months or years.
The idea is to have verifiable PGP keys that prove that whoever generated them put a lot of resources into it, such as "time spent waiting to create it." This would let others easily distinguish valued key-based identities from instantly created sockpuppet types.
No method springs to mind.
Then again, PGP doesn't really verify keys much. You can sign your pubkey using your privkey, but that just proves that there really is a privkey corresponding to that pubkey. It doesn't tell anyone anything about the composition of that privkey.
On the other hand, if your nonce range is small enough, everyone would be able to just brute force it. But that isn't likely to be useful, unless you want people to verify your key by reconstructing the whole thing.
Then again, PGP doesn't really verify keys much. You can sign your pubkey using your privkey, but that just proves that there really is a privkey corresponding to that pubkey. It doesn't tell anyone anything about the composition of that privkey.
On the other hand, if your nonce range is small enough, everyone would be able to just brute force it. But that isn't likely to be useful, unless you want people to verify your key by reconstructing the whole thing.
It is possible to generate a PGP key pair, where the private key is generated from hashes of two separate Bitcoin blocks and a private nonce, and still have it be possible for a third party to verify that the public key is indeed generated from those two block hashes without needing to know the private key?
Jump to: