* [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
@ 2014-02-24 16:03 Jeff Garzik
2014-02-24 16:16 ` Pieter Wuille
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Jeff Garzik @ 2014-02-24 16:03 UTC (permalink / raw)
To: Bitcoin Dev
An update in forthcoming 0.9 release includes a change to make
OP_RETURN standard, permitted a small amount of metadata to be
attached to a transaction:
https://github.com/bitcoin/bitcoin/pull/2738
There was always going to be some level of controversy attached to
this. However, some issues, perceptions and questions are bubbling
up, and it seemed fair to cover them on the list, not just IRC.
1) FAQ: Why 80 bytes of data? This is the leading programmer
question, and it was not really documented well at all. Simple
answer: 2x SHA256 or 1x SHA512, plus some tiny bit of metadata. Some
schemes are of the nature "BOND<hash>" rather than just plain hash.
A common IRC proposal seems to lean towards reducing that from 80.
I'll leave it to the crowd to argue about size from there. I do think
regular transactions should have the ability to include some metadata.
2) Endorsement of chain data storage. Listening to bitcoin conference
corridor discussions, reading forum posts and the occasional article
have over-simplified the situation to "core devs endorse data storage
over blockchain! let me start uploading my naughty movie collection!
IM over blockchain, woo hoo!"
Nothing could be further from the truth. It's a way to make data
/less damaging/, not an endorsement of data storage in chain as a good
idea. MasterCoin and other projects were doing -even worse- things,
such as storing data in forever-unspendable TX outputs, bloating the
UTXO for eternity.
It seems reasonable to have a release note to this effect in the 0.9
release announcement, IMO.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:03 [Bitcoin-development] On OP_RETURN in upcoming 0.9 release Jeff Garzik @ 2014-02-24 16:16 ` Pieter Wuille 2014-02-24 16:32 ` Jeff Garzik 2014-02-24 16:33 ` Jeff Garzik 2014-02-24 16:39 ` Wladimir ` (2 subsequent siblings) 3 siblings, 2 replies; 19+ messages in thread From: Pieter Wuille @ 2014-02-24 16:16 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > I do think > regular transactions should have the ability to include some metadata. and > 2) Endorsement of chain data storage. > > Nothing could be further from the truth. These two statements are in direct contradiction with each other. -- Pieter ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:16 ` Pieter Wuille @ 2014-02-24 16:32 ` Jeff Garzik 2014-02-24 16:33 ` Jeff Garzik 1 sibling, 0 replies; 19+ messages in thread From: Jeff Garzik @ 2014-02-24 16:32 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev Not really -- a MasterCoin transaction or JPEG On Mon, Feb 24, 2014 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > >> I do think >> regular transactions should have the ability to include some metadata. > > and > >> 2) Endorsement of chain data storage. >> >> Nothing could be further from the truth. > > These two statements are in direct contradiction with each other. > > -- > Pieter -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:16 ` Pieter Wuille 2014-02-24 16:32 ` Jeff Garzik @ 2014-02-24 16:33 ` Jeff Garzik 1 sibling, 0 replies; 19+ messages in thread From: Jeff Garzik @ 2014-02-24 16:33 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev (fscking 'send' hotkey in GMail) Not really - a MasterCoin or JPEG image transaction is not a "regular" transaction. On Mon, Feb 24, 2014 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > >> I do think >> regular transactions should have the ability to include some metadata. > > and > >> 2) Endorsement of chain data storage. >> >> Nothing could be further from the truth. > > These two statements are in direct contradiction with each other. > > -- > Pieter -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:03 [Bitcoin-development] On OP_RETURN in upcoming 0.9 release Jeff Garzik 2014-02-24 16:16 ` Pieter Wuille @ 2014-02-24 16:39 ` Wladimir 2014-02-24 16:45 ` Gavin Andresen 2014-02-24 17:23 ` Mark Friedenbach 2014-02-24 17:10 ` Jeff Garzik 2014-02-24 22:12 ` Jeremy Spilman 3 siblings, 2 replies; 19+ messages in thread From: Wladimir @ 2014-02-24 16:39 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 815 bytes --] On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > A common IRC proposal seems to lean towards reducing that from 80. > I'll leave it to the crowd to argue about size from there. I do think > regular transactions should have the ability to include some metadata. > I'd be in favor of bringing it down to 40 for 0.9. That'd be enough for <8 byte header/identifier><32 byte hash>. 80, as the standard line length, is almost asking for "insert your graffiti message here". I also see no need for 64 bytes hashes such as SHA512 in the context of bitcoin, as that only offers 256-bit security (at most) in the first place. And if this is not abused, these kind of transactions become popular, and more space is really needed, the limit can always be increased in a future version. Wladimir [-- Attachment #2: Type: text/html, Size: 1252 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:39 ` Wladimir @ 2014-02-24 16:45 ` Gavin Andresen 2014-02-24 16:50 ` Pavol Rusnak 2014-02-24 17:23 ` Mark Friedenbach 1 sibling, 1 reply; 19+ messages in thread From: Gavin Andresen @ 2014-02-24 16:45 UTC (permalink / raw) To: Wladimir; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1075 bytes --] 40 bytes is small enough to never require an OP_PUSHDATA1, too, which will make writing the OP_RETURN-as-standard BIP simpler. On Mon, Feb 24, 2014 at 11:39 AM, Wladimir <laanwj@gmail•com> wrote: > > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > >> A common IRC proposal seems to lean towards reducing that from 80. >> I'll leave it to the crowd to argue about size from there. I do think >> regular transactions should have the ability to include some metadata. >> > > I'd be in favor of bringing it down to 40 for 0.9. > > That'd be enough for <8 byte header/identifier><32 byte hash>. > > 80, as the standard line length, is almost asking for "insert your > graffiti message here". I also see no need for 64 bytes hashes such as > SHA512 in the context of bitcoin, as that only offers 256-bit security (at > most) in the first place. > > And if this is not abused, these kind of transactions become popular, and > more space is really needed, the limit can always be increased in a future > version. > > Wladimir > -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1991 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:45 ` Gavin Andresen @ 2014-02-24 16:50 ` Pavol Rusnak 0 siblings, 0 replies; 19+ messages in thread From: Pavol Rusnak @ 2014-02-24 16:50 UTC (permalink / raw) To: Bitcoin Dev On 02/24/2014 05:45 PM, Gavin Andresen wrote: > 40 bytes is small enough to never require an OP_PUSHDATA1, too So are 75 bytes. (I'm not trying to push anything. Just saying ...) -- Best Regards / S pozdravom, Pavol Rusnak <stick@gk2•sk> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:39 ` Wladimir 2014-02-24 16:45 ` Gavin Andresen @ 2014-02-24 17:23 ` Mark Friedenbach 2014-02-24 23:06 ` Andreas Petersson 2014-02-28 5:25 ` Troy Benjegerdes 1 sibling, 2 replies; 19+ messages in thread From: Mark Friedenbach @ 2014-02-24 17:23 UTC (permalink / raw) To: bitcoin-development Given our standardization on 128-bit security / 256-bit primitives, I can't think of any crypto related data payload which requires more than 40 bytes. Even DER encoded compressed public keys will fit in there. A signature won't fit, but why would you need one in there? There's no need to design for 64-byte hashes, and the 80-char line length comparison is a good point. As an Engineer I'd want to have a little more room as a 32-byte hash or EC point + 8 bytes identifying prefix data is the bare minimum, but it is also very important that we send a message: This is for payment related applications like stealth addresses only. Don't burden everybody by putting your junk on the block chain. On 02/24/2014 08:39 AM, Wladimir wrote: > > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com > <mailto:jgarzik@bitpay•com>> wrote: > > A common IRC proposal seems to lean towards reducing that from 80. > I'll leave it to the crowd to argue about size from there. I do think > regular transactions should have the ability to include some metadata. > > > I'd be in favor of bringing it down to 40 for 0.9. > > That'd be enough for <8 byte header/identifier><32 byte hash>. > > 80, as the standard line length, is almost asking for "insert your > graffiti message here". I also see no need for 64 bytes hashes such as > SHA512 in the context of bitcoin, as that only offers 256-bit security > (at most) in the first place. > > And if this is not abused, these kind of transactions become popular, > and more space is really needed, the limit can always be increased in a > future version. > > Wladimir > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 17:23 ` Mark Friedenbach @ 2014-02-24 23:06 ` Andreas Petersson 2014-02-24 23:13 ` Gregory Maxwell 2014-02-24 23:13 ` Luke-Jr 2014-02-28 5:25 ` Troy Benjegerdes 1 sibling, 2 replies; 19+ messages in thread From: Andreas Petersson @ 2014-02-24 23:06 UTC (permalink / raw) To: bitcoin-development Regarding 80 bytes vs smaller: The objectives should be that if you are determined to put some extra data in the blockchain, OP_RETURN should be the superior alternative. if a user can include more data with less fees using a multisig TX, then this will happen. eventually dust-limit rules will not be the deciding factor here, since i suspect block propagation times will have a stronger effect on effective fees. therefore a slightly larger payload than the biggest multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes. (this is my understanding of how large a 3-of-3 multisig tx can be, plus 1.5 bits encoded in the "n" parameter) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 23:06 ` Andreas Petersson @ 2014-02-24 23:13 ` Gregory Maxwell 2014-02-24 23:13 ` Luke-Jr 1 sibling, 0 replies; 19+ messages in thread From: Gregory Maxwell @ 2014-02-24 23:13 UTC (permalink / raw) To: Andreas Petersson; +Cc: Bitcoin Development On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson <andreas@petersson•at> wrote: > Regarding 80 bytes vs smaller: The objectives should be that if you are > determined to put some extra data in the blockchain, OP_RETURN should be > the superior alternative. if a user can include more data with less fees > using a multisig TX, then this will happen. > > eventually dust-limit rules will not be the deciding factor here, since > i suspect block propagation times will have a stronger effect on > effective fees. therefore a slightly larger payload than the biggest > multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes. > (this is my understanding of how large a 3-of-3 multisig tx can be, plus > 1.5 bits encoded in the "n" parameter) At least there is no ambiguity that such usage is abusive. Adoption of the practices matters too. Right now I've seen a lot of people promoting data storage as a virtuous use, and gearing up to directly store data when a commitment would work. If it turns out that encouraging people to use hashes is a lost cause it can always be further relaxed in the future, going the other way is much harder. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 23:06 ` Andreas Petersson 2014-02-24 23:13 ` Gregory Maxwell @ 2014-02-24 23:13 ` Luke-Jr 1 sibling, 0 replies; 19+ messages in thread From: Luke-Jr @ 2014-02-24 23:13 UTC (permalink / raw) To: bitcoin-development On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote: > Regarding 80 bytes vs smaller: The objectives should be that if you are > determined to put some extra data in the blockchain, OP_RETURN should be > the superior alternative. if a user can include more data with less fees > using a multisig TX, then this will happen. > > eventually dust-limit rules will not be the deciding factor here, since > i suspect block propagation times will have a stronger effect on > effective fees. therefore a slightly larger payload than the biggest > multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes. > (this is my understanding of how large a 3-of-3 multisig tx can be, plus > 1.5 bits encoded in the "n" parameter) Perhaps I ought to redo my data carrier configuration option as a max size? Luke ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 17:23 ` Mark Friedenbach 2014-02-24 23:06 ` Andreas Petersson @ 2014-02-28 5:25 ` Troy Benjegerdes 2014-02-28 14:42 ` Warren Togami Jr. 1 sibling, 1 reply; 19+ messages in thread From: Troy Benjegerdes @ 2014-02-28 5:25 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-development To each his own, but if I say "Please don't charge me for YOUR privacy by putting junk like stealth addresses in the blockchain", I think I'd get laughed out of most rooms. Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. On Mon, Feb 24, 2014 at 09:23:12AM -0800, Mark Friedenbach wrote: > Given our standardization on 128-bit security / 256-bit primitives, I > can't think of any crypto related data payload which requires more than > 40 bytes. Even DER encoded compressed public keys will fit in there. A > signature won't fit, but why would you need one in there? > > There's no need to design for 64-byte hashes, and the 80-char line > length comparison is a good point. As an Engineer I'd want to have a > little more room as a 32-byte hash or EC point + 8 bytes identifying > prefix data is the bare minimum, but it is also very important that we > send a message: This is for payment related applications like stealth > addresses only. Don't burden everybody by putting your junk on the block > chain. > > On 02/24/2014 08:39 AM, Wladimir wrote: > > > > On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik <jgarzik@bitpay•com > > <mailto:jgarzik@bitpay•com>> wrote: > > > > A common IRC proposal seems to lean towards reducing that from 80. > > I'll leave it to the crowd to argue about size from there. I do think > > regular transactions should have the ability to include some metadata. > > > > > > I'd be in favor of bringing it down to 40 for 0.9. > > > > That'd be enough for <8 byte header/identifier><32 byte hash>. > > > > 80, as the standard line length, is almost asking for "insert your > > graffiti message here". I also see no need for 64 bytes hashes such as > > SHA512 in the context of bitcoin, as that only offers 256-bit security > > (at most) in the first place. > > > > And if this is not abused, these kind of transactions become popular, > > and more space is really needed, the limit can always be increased in a > > future version. > > > > Wladimir > > > > > > ------------------------------------------------------------------------------ > > Flow-based real-time traffic analytics software. Cisco certified tool. > > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > > Customize your own dashboards, set traffic alerts and generate reports. > > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-28 5:25 ` Troy Benjegerdes @ 2014-02-28 14:42 ` Warren Togami Jr. 2014-02-28 19:25 ` Mark Friedenbach 2014-02-28 20:10 ` Drak 0 siblings, 2 replies; 19+ messages in thread From: Warren Togami Jr. @ 2014-02-28 14:42 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 957 bytes --] On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes <hozer@hozed•org> wrote: > > Either the transaction fees are sufficient to pay the cost for whatever > random junk anyone wants to put there, or they are not, and if they are > not, then I suggest you re-think the fee structure rather than trying > to pre-regulate me putting 80 character pithy quotes in the blockhain. > > https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. As much as I personally hate the idea of data storage in the blockchain, this at least discourages the creation of permanent UTXO. Warren Togami [-- Attachment #2: Type: text/html, Size: 1576 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-28 14:42 ` Warren Togami Jr. @ 2014-02-28 19:25 ` Mark Friedenbach 2014-02-28 19:36 ` Justus Ranvier 2014-02-28 20:10 ` Drak 1 sibling, 1 reply; 19+ messages in thread From: Mark Friedenbach @ 2014-02-28 19:25 UTC (permalink / raw) To: bitcoin-development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is completely unpaid for. When I add a 1Kb transaction to the blockchain, there is an attached fee which probabilistically goes to one of the miners. But every other full node on the network also receives this transaction, processes it, and adds it to local storage. From now until the heat death of the universe that 1Kb of data will be redundantly stored and transmitted to every single person who validates the block chain. None of these countless people are reimbursed for their storage, bandwidth, and processing costs. Not even a single satoshi. Yes, transaction fees are broken. But it is their very nature which is broken (sending coins to the miners, not the greater validator set), and no little tweak like the one Warren links to will fix this. But, in the absence of a reformed fee regime - which it is not clear is even possible - one could at least make the hand-wavey argument that people who validate the block chain receive benefit from it as a payment network. Therefore processing of the block chain is "paid for" by the utility it provides once fully synced. However even this weak argument does not extend to general data storage. If you want to put all of wikileaks or whatever in the block chain, then you are extracting a rent from every full node which is forced to process and store this data for eternity without compensation or derived utility. You are extorting users of the payment network into providing a storage service at no cost, because the alternative (losing bitcoin as a payment network) would cost them more. That is not ethical behavior. That is not behavior which responsible developers should allow in the reference client. Mark On 02/28/2014 06:42 AM, Warren Togami Jr. wrote: > On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes <hozer@hozed•org > <mailto:hozer@hozed•org>> wrote: > > > Either the transaction fees are sufficient to pay the cost for > whatever random junk anyone wants to put there, or they are not, > and if they are not, then I suggest you re-think the fee structure > rather than trying to pre-regulate me putting 80 character pithy > quotes in the blockhain. > > > https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d > > In one way in particular, the transaction fees per kilobyte > completely failed to account for the actual cost to the network. > If Bitcoin had adopted a common-sense rule like this, I would have > had no reason to join Litecoin development last year. This is one > of the few economic design flaws that Satoshi overlooked in the > original design. > > As much as I personally hate the idea of data storage in the > blockchain, this at least discourages the creation of permanent > UTXO. > > Warren Togami > > > ------------------------------------------------------------------------------ > > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow > Analyzer Customize your own dashboards, set traffic alerts and > generate reports. Network behavioral analysis & security > monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTEOKjAAoJEAdzVfsmodw4vGIQAJ9OQvHl1+dIaDelrf03lGIf kQsiuB4JG1rRghsZZiW4NixPbB/Bdm4+m4pep01eiVOPXa+/32AgWVzSYyyMVRYB oTu24ITgtCu5vkjiHyzSavFnqsi+zMxVpscUekA6l6Tkr3RBNnrIssMiazYc+Bkx fP2vZehmPHQtp09WkapZ3DMqbMzQ7qPTGlKd1V+9X4S5uUNTdfT6JkC0HIqUSdVQ PHjjbuulgkdz4b7A6C2dE5kwXVKF9YFHL3zEtObfWDCiyY8wf2XHYI6nVGLbyQeN nrYCsMH99lUy+zmnbccqSPKhe0p5IaBLauk75zcLxEfzxuKVTvVg2LCaCXQaworv vBoAURdrB2pCfK8dZ7mllVLLLcNk+iOG0NDZHYE9e884OBfeuaG/zNgmgOD8GC1H FaDkIpm79x/i3ti3h8vdZPeY0fWdI8yuD9aCQZtvONM9hXdd7Qb07eHqIk7tY/In 7h6zdq27GQUdWN37yslxtDENY2q3yQ39+fjMGQEKVIE6rNwDyjurMCNHAWJp0hZO 7S/rDe2W2tHGPYakscHQh1g/uMAEEb4mGGc5yrfWxyOn5eb9OZiZb8RVXlnDwwH9 qr8qwLJ1b0Uxo981lyEmnLZSpCpAZvDLpjmocqirycNZpvyPnJJbE809vS/koD3d OutJkMja4TBuqaMSdKEI =KbW/ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-28 19:25 ` Mark Friedenbach @ 2014-02-28 19:36 ` Justus Ranvier 0 siblings, 0 replies; 19+ messages in thread From: Justus Ranvier @ 2014-02-28 19:36 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 798 bytes --] On 02/28/2014 07:25 PM, Mark Friedenbach wrote: > Transaction fees are a DoS mitigating cost to the person making the > transaction, but they are generally not paid to the people who > actually incur costs in validating the blockchain. Actual transaction > processing costs are an externality that is completely unpaid for. What that means is the network layer is broken and needs to be fixed. Bitcoin is the blockchain, not the P2P network. If the existing network is not incentive compatible, then that's the root cause which should be addressed. There's no reason to enshrine the broken behavior and use it as a roadblock to stop progress. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k [-- Attachment #1.2: 0x1B438BF4.asc --] [-- Type: application/pgp-keys, Size: 21521 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 555 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-28 14:42 ` Warren Togami Jr. 2014-02-28 19:25 ` Mark Friedenbach @ 2014-02-28 20:10 ` Drak 1 sibling, 0 replies; 19+ messages in thread From: Drak @ 2014-02-28 20:10 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 619 bytes --] On 28 February 2014 14:42, Warren Togami Jr. <wtogami@gmail•com> wrote: > > https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d > > In one way in particular, the transaction fees per kilobyte completely > failed to account for the actual cost to the network. If Bitcoin had > adopted a common-sense rule like this, I would have had no reason to join > Litecoin development last year. This is one of the few economic design > flaws that Satoshi overlooked in the original design. > Is there any particular reason that patch would not make it into bitcoin if submitted? Drak [-- Attachment #2: Type: text/html, Size: 1207 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:03 [Bitcoin-development] On OP_RETURN in upcoming 0.9 release Jeff Garzik 2014-02-24 16:16 ` Pieter Wuille 2014-02-24 16:39 ` Wladimir @ 2014-02-24 17:10 ` Jeff Garzik 2014-02-24 22:12 ` Jeremy Spilman 3 siblings, 0 replies; 19+ messages in thread From: Jeff Garzik @ 2014-02-24 17:10 UTC (permalink / raw) To: Bitcoin Dev This PR reduces the size to 40 bytes: https://github.com/bitcoin/bitcoin/pull/3737 (Note - this is not intended to close the discussion... please do keep sending in feedback) On Mon, Feb 24, 2014 at 11:03 AM, Jeff Garzik <jgarzik@bitpay•com> wrote: > An update in forthcoming 0.9 release includes a change to make > OP_RETURN standard, permitted a small amount of metadata to be > attached to a transaction: > https://github.com/bitcoin/bitcoin/pull/2738 > > There was always going to be some level of controversy attached to > this. However, some issues, perceptions and questions are bubbling > up, and it seemed fair to cover them on the list, not just IRC. > > 1) FAQ: Why 80 bytes of data? This is the leading programmer > question, and it was not really documented well at all. Simple > answer: 2x SHA256 or 1x SHA512, plus some tiny bit of metadata. Some > schemes are of the nature "BOND<hash>" rather than just plain hash. > A common IRC proposal seems to lean towards reducing that from 80. > I'll leave it to the crowd to argue about size from there. I do think > regular transactions should have the ability to include some metadata. > > 2) Endorsement of chain data storage. Listening to bitcoin conference > corridor discussions, reading forum posts and the occasional article > have over-simplified the situation to "core devs endorse data storage > over blockchain! let me start uploading my naughty movie collection! > IM over blockchain, woo hoo!" > > Nothing could be further from the truth. It's a way to make data > /less damaging/, not an endorsement of data storage in chain as a good > idea. MasterCoin and other projects were doing -even worse- things, > such as storing data in forever-unspendable TX outputs, bloating the > UTXO for eternity. > > It seems reasonable to have a release note to this effect in the 0.9 > release announcement, IMO. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 16:03 [Bitcoin-development] On OP_RETURN in upcoming 0.9 release Jeff Garzik ` (2 preceding siblings ...) 2014-02-24 17:10 ` Jeff Garzik @ 2014-02-24 22:12 ` Jeremy Spilman 2014-02-24 22:50 ` Jeff Garzik 3 siblings, 1 reply; 19+ messages in thread From: Jeremy Spilman @ 2014-02-24 22:12 UTC (permalink / raw) To: Bitcoin Dev, Jeff Garzik On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik <jgarzik@bitpay•com> wrote: > This PR reduces the size to 40 bytes: > https://github.com/bitcoin/bitcoin/pull/3737 Just quickly GLANCED at it, but if I understand correctly how the template matching code works, that will change max size of the <data> to 40 bytes but does not do anything to enforce most-efficient encoding. else if (opcode2 == OP_SMALLDATA) { // small pushdata, <= MAX_OP_RETURN_RELAY bytes if (vch1.size() > MAX_OP_RETURN_RELAY) break; } This code was a bit hard for me to parse since it's not actually requiring any data, just disallowing more than a certain number of bytes of data. So a bare OP_RETURN would be allowed as well, for whatever good that will do. If you want to strictly require no PUSHDATA, perhaps you could do: else if (opcode2 == OP_SMALLDATA) { // small pushdata, <= MAX_OP_RETURN_RELAY bytes if (opcode1 >= OP_PUSHDATA1 || vch1.size() > MAX_OP_RETURN_RELAY) break; } Thanks, Jeremy ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release 2014-02-24 22:12 ` Jeremy Spilman @ 2014-02-24 22:50 ` Jeff Garzik 0 siblings, 0 replies; 19+ messages in thread From: Jeff Garzik @ 2014-02-24 22:50 UTC (permalink / raw) To: Jeremy Spilman; +Cc: Bitcoin Dev Sure, no objection to that. On Mon, Feb 24, 2014 at 5:12 PM, Jeremy Spilman <jeremy@taplink•co> wrote: > On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik <jgarzik@bitpay•com> wrote: >> >> This PR reduces the size to 40 bytes: >> https://github.com/bitcoin/bitcoin/pull/3737 > > > Just quickly GLANCED at it, but if I understand correctly how the template > matching code works, that will change max size of the <data> to 40 bytes but > does not do anything to enforce most-efficient encoding. > > else if (opcode2 == OP_SMALLDATA) > { > // small pushdata, <= MAX_OP_RETURN_RELAY bytes > if (vch1.size() > MAX_OP_RETURN_RELAY) > break; > } > > This code was a bit hard for me to parse since it's not actually requiring > any data, just disallowing more than a certain number of bytes of data. So a > bare OP_RETURN would be allowed as well, for whatever good that will do. > > If you want to strictly require no PUSHDATA, perhaps you could do: > > else if (opcode2 == OP_SMALLDATA) > { > // small pushdata, <= MAX_OP_RETURN_RELAY bytes > if (opcode1 >= OP_PUSHDATA1 || vch1.size() > MAX_OP_RETURN_RELAY) > break; > } > > Thanks, > Jeremy > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-02-28 20:17 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-24 16:03 [Bitcoin-development] On OP_RETURN in upcoming 0.9 release Jeff Garzik 2014-02-24 16:16 ` Pieter Wuille 2014-02-24 16:32 ` Jeff Garzik 2014-02-24 16:33 ` Jeff Garzik 2014-02-24 16:39 ` Wladimir 2014-02-24 16:45 ` Gavin Andresen 2014-02-24 16:50 ` Pavol Rusnak 2014-02-24 17:23 ` Mark Friedenbach 2014-02-24 23:06 ` Andreas Petersson 2014-02-24 23:13 ` Gregory Maxwell 2014-02-24 23:13 ` Luke-Jr 2014-02-28 5:25 ` Troy Benjegerdes 2014-02-28 14:42 ` Warren Togami Jr. 2014-02-28 19:25 ` Mark Friedenbach 2014-02-28 19:36 ` Justus Ranvier 2014-02-28 20:10 ` Drak 2014-02-24 17:10 ` Jeff Garzik 2014-02-24 22:12 ` Jeremy Spilman 2014-02-24 22:50 ` Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox