{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-11-04\n📝 Original message:At the first Scaling Bitcoin workshop in Montreal I presented on the topic\nof \"bad blocks\" that take an excessive amount of time to validate. You can\nread a transcript of this talk here:\n\nhttp://diyhpl.us/wiki/transcripts/scalingbitcoin/alternatives-to-block-size-as-aggregate-resource-limits/\n\nThe core message was that the assumption made by the design parameters of\nthe system, namely that validation costs scale linearly with transaction or\nblock size, is wrong. In particular, in certain kinds of transactions there\nare validation costs which scale quadraticly with size. For example, the\nconstruction of SIGHASH_ALL results in each input signing a different\nmessage digest, meaning that the entire transaction (minus the scriptSigs)\nis rehashed for each input. As another example, the number of signature\noperation performed during block validation is unlimited if the validations\nare contained within the scriptPubKey (this scales linearly but with a very\nlarge constant factor). The severity of these issues increase as the\naggregate limits in place on maximum transaction and block size increase.\n\nThere have been various solutions suggested, and I would like to start a\npublic discussion to see if consensus can be reached over a viable approach.\n\nGavin, for example, has written code that tracks the number of bytes hashed\nand enforces a separate limit for a block over this aggregate value. Other\ncosts could be constrained in a similar whack-a-mole way. I have two\nconcerns with this approach:\n\n1. There would still exist a gap between the average-case validation cost\nof a full block and the worst case validation cost of a block that was\nspecifically constructed to hit every limit.\n\n2. Transaction selection and by extension fee determination would become\nmuch more complicated multi-dimensional optimization problems. Since fee\nmanagement in particular is code replicated in a lot of infrastructure, I\nwould be very concerned over making optimal behavior greatly more difficult.\n\nMy own suggestion, which I submit for consideration, is to use a linear\nfunction of the various costs involved (signatures verified, bytes hashed,\ninputs consumed, script opcodes executed, etc.). The various algorithms\nused for transaction selection and fee determination can then be reused,\nusing the output of this new linear function as the \"size\" of the\ntransaction.\n\nSeparately, many others including Greg Maxwell have advocated for a\n\"net-UTXO\" metric instead of, or in combination with a validation-cost\nmetric. In the pure form the block size limit would be replaced with a\nmaximum UTXO set increase, thereby applying a cost in extra fee required to\ncreate unspent outputs. This has the distinct advantage of making dust\noutputs considerably more expensive than regular spend outputs.\n\nFor myself, I remain open to the possibility of adding a UTXO set size\ncorrective factor to a chiefly validation-cost metric. It would be nice to\nreward users for cleaning up scattered small output, reward miners for\nincluding dust-be-gone outputs, and make spam attacks more costly. But\ndoing so requires setting aside some unused validation resources in order\nto reward miners who clean up the UTXO, which means it widens the gap\nbetween average and worst case block validation times. Also, worry over the\nsize of the UTXO database is only a concern for how Bitcoin Core is\ncurrently structured -- with e.g. UTXO or STXO commitments it could be the\ncase that in the future full nodes do not store the UTXO and instead carry\nproofs of their inputs as prunable witness data. If we choose a net-UTXO\nmetric however, we will be stuck with it for some time.\n\nI will be submitting a talk proposal for Scaling Bitcoin on this topic, but\nI would like to get some feedback from the developer community first.\nAnyone have any thoughts to add?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151104/036ee438/attachment.html\u003e"}