Topic: Purchasing fidelity bonds by provably throwing away bitcoins - page 2. (Read 9073 times)
Burning banknotes for reputation? No way.....
EDIT: changed title
So what I've done in the above is created a transaction that embeds a different transaction within it using OP_DROP. The inner transaction is as follows:
The inner transaction is fully signed and valid, sending 0.1BTC to 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH(1) and spending a hefty 0.4BTC in fees. However since nLockTime is set to be a bit over 2000 blocks in the future it'll be some time before anyone can spend it. On the other hand since the first transaction is public, and will be embedded into the blockchain once someone mines it, provided the second transaction is mined after the first the existence of both transactions proves I threw away 0.4BTC in fees to the miners as once the transaction is made public the sender has no control what-so-ever over who mines it. Basically this is a more sophisticated mechanism to achieve the "trusted identities through value destruction" I proposed earlier (https://bitcointalksearch.org/topic/m.1007449), with the advantages that this implementation requires just two transactions and as long as nLockTime is set reasonably far into the future the value destruction will always be valid.
The maximum value you can destroy in this manner, assuming the mechanism is known and there are miners watching the blockchain for these special transactions, is then a function of the number of blocks between the two special transactions. Basically a miner could work on getting mining successive blocks, then publishing the whole chain, however that becomes exponentially more difficult and expensive in terms of opportunity cost. 10 or 100 blocks should be plenty. Of course the expected value lost is proportional to the mining power you control, but mining power is pretty well distributed.
An actual implementation can do better than just a simple OP_DROP. For one thing the message should go in the scriptSig to aid pruning. Secondly the inner transaction doesn't need to be provided in full; much of it can be snipped out if a template it used. Even the whole scriptPubKey can be left out if the output always goes to a known address. The minimum required length is just the ~80 byte signature and the 32byte tx id for the input, and at that point you can probably stuff the whole thing into one of the "isStandard OP_DROP" type proposals or similar. Either way, what's important is to agree on a standard so the value destruction is valid.
EDIT: Just to make things clear, double-spending the inner tx isn't a problem. Remember that the whole point of this is to prove after the fact that you threw away bitcoins. If you double-spend the inner tx, you have no proof.
EDIT2: Miners don't have a disincentive to mine the outer. After all, the inner can be published separately and put into the mempool whether or not the outer tx exists. The decision to mine the outer is orthogonal and subject to the same logic as any other transaction.
1) ...which is really throwing away another 0.1BTC...
Code:
0100000001d1b311d665b94ad270007deeaa696d487ea0bcd2d11e2c9a5407e7d25097f0ed000000006c493046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce60121028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacdffffffff01009f240000000000dc4cc0010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc5003007576a914fb99bed1a4ea8d1d01d879581fce07b27ab5357f88ac00000000
{
"txid" : "2bf4ff04b40d03ff71570877d8267aed91d3595d172737d096241d08277135e2",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "edf09750d2e707549a2c1ed1d2bca07e486d69aaee7d0070d24ab965d611b3d1",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce601 028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacd",
"hex" : "493046022100a940f6147a70b98fa7f5bd0e76156ca71347207fca0336c93ce1b5165d653011022100ef0cc31be261178074e1cd854d4ea47e2b62d7ac5add4f1ae50474d841b60ce60121028f2bb71ec2c796cab46d5b61c28ad6cde73dacacf60f18943788053d6040eacd"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.02400000,
"n" : 0,
"scriptPubKey" : {
"asm" : "010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc500300 OP_DROP OP_DUP OP_HASH160 fb99bed1a4ea8d1d01d879581fce07b27ab5357f OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "4cc0010000000127478b07dae63322d1999419115cf287c69ff0f11de3f96d46df6926de61143c010000006b483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52000000000180969800000000001976a914751e76e8199196d454941c45d1b3a323f1433bd688accc5003007576a914fb99bed1a4ea8d1d01d879581fce07b27ab5357f88ac",
"type" : "nonstandard"
}
}
]
}
So what I've done in the above is created a transaction that embeds a different transaction within it using OP_DROP. The inner transaction is as follows:
Code:
{
"txid" : "8608a914d3e217ebfaa5cf04974a657d5b80b940fd46b9efee823feed43102ef",
"version" : 1,
"locktime" : 217292,
"vin" : [
{
"txid" : "3c1461de2669df466df9e31df1f09fc687f25c11199499d12233e6da078b4727",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f01 02ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52",
"hex" : "483045022100cca50bfed991240a7603eea19340f6e24102b29db2dfcc56fdfe549dacddcc6402207eefe2688670d349615ed184d1f84ac54365afd258524e55266c992ce2d68b7f012102ff9d6e0c33fb3cfc677857d2cd654db91fe051811433654d25442ee0182dac52"
},
"sequence" : 0
}
],
"vout" : [
{
"value" : 0.10000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914751e76e8199196d454941c45d1b3a323f1433bd688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH"
]
}
}
]
}
The inner transaction is fully signed and valid, sending 0.1BTC to 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH(1) and spending a hefty 0.4BTC in fees. However since nLockTime is set to be a bit over 2000 blocks in the future it'll be some time before anyone can spend it. On the other hand since the first transaction is public, and will be embedded into the blockchain once someone mines it, provided the second transaction is mined after the first the existence of both transactions proves I threw away 0.4BTC in fees to the miners as once the transaction is made public the sender has no control what-so-ever over who mines it. Basically this is a more sophisticated mechanism to achieve the "trusted identities through value destruction" I proposed earlier (https://bitcointalksearch.org/topic/m.1007449), with the advantages that this implementation requires just two transactions and as long as nLockTime is set reasonably far into the future the value destruction will always be valid.
The maximum value you can destroy in this manner, assuming the mechanism is known and there are miners watching the blockchain for these special transactions, is then a function of the number of blocks between the two special transactions. Basically a miner could work on getting mining successive blocks, then publishing the whole chain, however that becomes exponentially more difficult and expensive in terms of opportunity cost. 10 or 100 blocks should be plenty. Of course the expected value lost is proportional to the mining power you control, but mining power is pretty well distributed.
An actual implementation can do better than just a simple OP_DROP. For one thing the message should go in the scriptSig to aid pruning. Secondly the inner transaction doesn't need to be provided in full; much of it can be snipped out if a template it used. Even the whole scriptPubKey can be left out if the output always goes to a known address. The minimum required length is just the ~80 byte signature and the 32byte tx id for the input, and at that point you can probably stuff the whole thing into one of the "isStandard OP_DROP" type proposals or similar. Either way, what's important is to agree on a standard so the value destruction is valid.
EDIT: Just to make things clear, double-spending the inner tx isn't a problem. Remember that the whole point of this is to prove after the fact that you threw away bitcoins. If you double-spend the inner tx, you have no proof.
EDIT2: Miners don't have a disincentive to mine the outer. After all, the inner can be published separately and put into the mempool whether or not the outer tx exists. The decision to mine the outer is orthogonal and subject to the same logic as any other transaction.
1) ...which is really throwing away another 0.1BTC...
Jump to: