* [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution @ 2013-04-10 2:53 Gregory Maxwell 2013-04-10 3:03 ` Peter Todd 2013-04-10 3:52 ` Robert Backhaus 0 siblings, 2 replies; 10+ messages in thread From: Gregory Maxwell @ 2013-04-10 2:53 UTC (permalink / raw) To: Bitcoin Development (1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by hashing it. (2a) If we find that miners mine P2SH^2 addresses where the P2SH wasn't relayed (e.g. they want the fees) we introduce a block discouragement rule where a block is discouraged if you receive it without receiving the P2SH^2 pre-images for it. With this minor change there is _no_ non-prunable location for users to cram data into except values. (and the inefficiency of cramming data into values is a strong deterrent in any case) The same thing could also be done for OP_RETURN PUSH value outputs used to link transactions to data. Make the data be a hash, outside of the txn include the preimage of the hash. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 2:53 [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution Gregory Maxwell @ 2013-04-10 3:03 ` Peter Todd 2013-04-10 3:08 ` Peter Todd 2013-04-10 6:53 ` Peter Todd 2013-04-10 3:52 ` Robert Backhaus 1 sibling, 2 replies; 10+ messages in thread From: Peter Todd @ 2013-04-10 3:03 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 2167 bytes --] On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote: Note how we can already do this: P2SH uses Hash160, which is RIPE160(SHA256(d)) We still need a new P2SH *address* type, that provides the full 256 bits, but no-one uses P2SH addresses yet anyway. This will restrict data stuffing to brute forcing hash collisions. It'd be interesting working out the math for how effective that is, but it'll certainely be expensive in terms of time hashing power that could solve shares instead. > (1) Define a new address type, P2SH^2 like P2SH but is instead > H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is > a hash of a P2SH address. > > (2) Make a relay rule so that to relay a P2SH^2 you must include > along the inner P2SH address. All nodes can trivially verify it by > hashing it. > > (2a) If we find that miners mine P2SH^2 addresses where the P2SH > wasn't relayed (e.g. they want the fees) we introduce a block > discouragement rule where a block is discouraged if you receive it > without receiving the P2SH^2 pre-images for it. > > With this minor change there is _no_ non-prunable location for users > to cram data into except values. (and the inefficiency of cramming > data into values is a strong deterrent in any case) > > The same thing could also be done for OP_RETURN PUSH value outputs > used to link transactions to data. Make the data be a hash, outside of > the txn include the preimage of the hash. > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 3:03 ` Peter Todd @ 2013-04-10 3:08 ` Peter Todd 2013-04-10 15:58 ` Jorge Timón 2013-04-10 6:53 ` Peter Todd 1 sibling, 1 reply; 10+ messages in thread From: Peter Todd @ 2013-04-10 3:08 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1191 bytes --] On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote: > On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote: > > Note how we can already do this: P2SH uses Hash160, which is > RIPE160(SHA256(d)) We still need a new P2SH *address* type, that > provides the full 256 bits, but no-one uses P2SH addresses yet anyway. > > This will restrict data stuffing to brute forcing hash collisions. It'd > be interesting working out the math for how effective that is, but it'll > certainely be expensive in terms of time hashing power that could solve > shares instead. Oh, and while we're at it, long-term (hard-fork) it'd be good to change the tx hash algorithm to extend the merkle tree into the txouts/txins itself, which means that to prove a given txout exists you only need to provide it, rather than the full tx. Currently pruning can't prune a whole tx until every output is spent. Make that change and we can prune tx's bit by bit, and still be able to serve nodes requesting proof of their UTXO without making life difficult for anyone trying to spent old UTXO's. The idea is also part of UTXO proof stuff anyway. -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 3:08 ` Peter Todd @ 2013-04-10 15:58 ` Jorge Timón 2013-04-11 11:27 ` Peter Todd 0 siblings, 1 reply; 10+ messages in thread From: Jorge Timón @ 2013-04-10 15:58 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development On 4/10/13, Peter Todd <pete@petertodd•org> wrote: > Oh, and while we're at it, long-term (hard-fork) it'd be good to change > the tx hash algorithm to extend the merkle tree into the txouts/txins > itself, which means that to prove a given txout exists you only need to > provide it, rather than the full tx. > > Currently pruning can't prune a whole tx until every output is spent. > Make that change and we can prune tx's bit by bit, and still be able to > serve nodes requesting proof of their UTXO without making life difficult > for anyone trying to spent old UTXO's. The idea is also part of UTXO > proof stuff anyway. I thought about this before, I like the idea very much. Would such a fork be controversial for anyone? Would anyone oppose to this for some reason I'm missing? -- Jorge Timón http://freico.in/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 15:58 ` Jorge Timón @ 2013-04-11 11:27 ` Peter Todd 0 siblings, 0 replies; 10+ messages in thread From: Peter Todd @ 2013-04-11 11:27 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1316 bytes --] On Wed, Apr 10, 2013 at 05:58:10PM +0200, Jorge Timón wrote: > On 4/10/13, Peter Todd <pete@petertodd•org> wrote: > > Oh, and while we're at it, long-term (hard-fork) it'd be good to change > > the tx hash algorithm to extend the merkle tree into the txouts/txins > > itself, which means that to prove a given txout exists you only need to > > provide it, rather than the full tx. > > > > Currently pruning can't prune a whole tx until every output is spent. > > Make that change and we can prune tx's bit by bit, and still be able to > > serve nodes requesting proof of their UTXO without making life difficult > > for anyone trying to spent old UTXO's. The idea is also part of UTXO > > proof stuff anyway. > > I thought about this before, I like the idea very much. > Would such a fork be controversial for anyone? > Would anyone oppose to this for some reason I'm missing? You mean https://bitcointalk.org/index.php?topic=137933.0 ? I would oppose it, and I wrote the above proposal. The code required to implement UTXO fraud proofs is more complex than the entire Bitcoin code base; obviously that much new fork-critical code opens up huge technical risks. As an example, can you think of how UTXO fraud proofs can cause an arbitrarily deep re-org? -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 3:03 ` Peter Todd 2013-04-10 3:08 ` Peter Todd @ 2013-04-10 6:53 ` Peter Todd 2013-04-10 7:15 ` Gregory Maxwell 1 sibling, 1 reply; 10+ messages in thread From: Peter Todd @ 2013-04-10 6:53 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1019 bytes --] On Tue, Apr 09, 2013 at 11:03:01PM -0400, Peter Todd wrote: > On Tue, Apr 09, 2013 at 07:53:38PM -0700, Gregory Maxwell wrote: > > Note how we can already do this: P2SH uses Hash160, which is > RIPE160(SHA256(d)) We still need a new P2SH *address* type, that > provides the full 256 bits, but no-one uses P2SH addresses yet anyway. We can keep the length 160bits: scriptPubKey: OP_HASH160 OP_HASH160 <Hash160(P2SHv2 address)> OP_EQUALVERIFY You don't need to change the address type at all if new software is written to check for both forms of txout in the actual blockchain/transaction code at the deeper level. Basically now a P2SH address could actually mean one of two scriptPubKey forms, must like a normal address can mean either the hashed or bare OP_CHECKSIG form. Of course, either way you have the odd side-effect that it's now difficult to pay further funds to a random txout seen on the blockchain... strange, although possibly not a bad thing. -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 6:53 ` Peter Todd @ 2013-04-10 7:15 ` Gregory Maxwell 2013-04-10 7:29 ` Peter Todd 0 siblings, 1 reply; 10+ messages in thread From: Gregory Maxwell @ 2013-04-10 7:15 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd <pete@petertodd•org> wrote: > Of course, either way you have the odd side-effect that it's now > difficult to pay further funds to a random txout seen on the > blockchain... strange, although possibly not a bad thing. Oh wow, thats actually a quite good thing— it's a property I know I've lamented before that I didn't know how to get. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 7:15 ` Gregory Maxwell @ 2013-04-10 7:29 ` Peter Todd 0 siblings, 0 replies; 10+ messages in thread From: Peter Todd @ 2013-04-10 7:29 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 642 bytes --] On Wed, Apr 10, 2013 at 12:15:26AM -0700, Gregory Maxwell wrote: > On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd <pete@petertodd•org> wrote: > > Of course, either way you have the odd side-effect that it's now > > difficult to pay further funds to a random txout seen on the > > blockchain... strange, although possibly not a bad thing. > > Oh wow, thats actually a quite good thing— it's a property I know I've > lamented before that I didn't know how to get. Don't get your hopes up - I fully expect blockchain.info to keep a publicly accessible database of inner-digest -> P2SH addresses... -- 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 2:53 [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution Gregory Maxwell 2013-04-10 3:03 ` Peter Todd @ 2013-04-10 3:52 ` Robert Backhaus 2013-04-10 3:58 ` Gregory Maxwell 1 sibling, 1 reply; 10+ messages in thread From: Robert Backhaus @ 2013-04-10 3:52 UTC (permalink / raw) To: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 1957 bytes --] That sounds workable. I take it that the P2SH address is not stored? I like it that this denies the possibility of storing data in the block chain, but does not block interesting uses like creating date stamps - You can still store the 'fake P2SH' value whose checksum is secured by the blockchain. On 10 April 2013 12:53, Gregory Maxwell <gmaxwell@gmail•com> wrote: > (1) Define a new address type, P2SH^2 like P2SH but is instead > H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is > a hash of a P2SH address. > > (2) Make a relay rule so that to relay a P2SH^2 you must include > along the inner P2SH address. All nodes can trivially verify it by > hashing it. > > (2a) If we find that miners mine P2SH^2 addresses where the P2SH > wasn't relayed (e.g. they want the fees) we introduce a block > discouragement rule where a block is discouraged if you receive it > without receiving the P2SH^2 pre-images for it. > > With this minor change there is _no_ non-prunable location for users > to cram data into except values. (and the inefficiency of cramming > data into values is a strong deterrent in any case) > > The same thing could also be done for OP_RETURN PUSH value outputs > used to link transactions to data. Make the data be a hash, outside of > the txn include the preimage of the hash. > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2681 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution 2013-04-10 3:52 ` Robert Backhaus @ 2013-04-10 3:58 ` Gregory Maxwell 0 siblings, 0 replies; 10+ messages in thread From: Gregory Maxwell @ 2013-04-10 3:58 UTC (permalink / raw) To: Robert Backhaus; +Cc: Bitcoin Development On Tue, Apr 9, 2013 at 8:52 PM, Robert Backhaus <robbak@robbak•com> wrote: > That sounds workable. I take it that the P2SH address is not stored? I like > it that this denies the possibility of storing data in the block chain, but > does not block interesting uses like creating date stamps - You can still > store the 'fake P2SH' value whose checksum is secured by the blockchain. Correct. It doesn't prevent value commitment (which is actually what we need for our currency use), just data storage. And as Peter points out— you could try to store a little data, but that has a computational cost which is exponential in the amount of data stored per output. ... like storing data in values, thats awkward enough to not be especially problematic, I expect. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-11 11:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-10 2:53 [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution Gregory Maxwell 2013-04-10 3:03 ` Peter Todd 2013-04-10 3:08 ` Peter Todd 2013-04-10 15:58 ` Jorge Timón 2013-04-11 11:27 ` Peter Todd 2013-04-10 6:53 ` Peter Todd 2013-04-10 7:15 ` Gregory Maxwell 2013-04-10 7:29 ` Peter Todd 2013-04-10 3:52 ` Robert Backhaus 2013-04-10 3:58 ` Gregory Maxwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox