On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson <andr...@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. ------------------------------------------------------------------------------ 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
