{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-19\n📝 Original message:On Mon, May 18, 2015 at 2:42 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e OK.  Be nice if these were cleaned up, but I guess it's a sunk cost.\n\u003e\n\nYeah.\n\nOn the plus side, as people spend their money, old UTXOs would be used up\nand then they would be included in the cost function.  It is only people\nwho are storing their money long term that wouldn't.\n\nThey are unlikely to have consumed their UTXOs anyway, unless miners\nstarted paying for UTXOs.\n\nWe could make it a range.\n\nUTXOs from below 355,000 and above 375,000 are included.  That can create\nincentive problems for the next similar change, I think a future threshold\nis better.\n\n\n\u003e  He said \"utxo_created_size\" not \"utxo_created\" so I assumed scriptlen?\n\u003e\n\nMaybe I mis-read.\n\n\n\u003e But you made that number up?  The soft cap and hard byte limit are\n\u003e different beasts, so there's no need for soft cost cap \u003c hard byte\n\u003e limit.\n\u003e\n\nI was thinking about it being a soft-fork.\n\nIf it was combined with the 20MB limit change, then it can be anything.\n\nI made a suggestion somewhere (her or forums not sure), that transactions\nshould be allowed to store bytes.\n\nFor example, a new opcode could be added, \u003cbyte_count\u003e OP_LOCK_BYTES.\n\nThis makes the transaction seem \u003cbyte_count\u003e larger.  However, when\nspending the UTXO, that transaction counts as \u003cbyte_count\u003e smaller, even\nagainst the hard-cap.\n\nThis would be useful for channels.  If channels were 100-1000X the\nblockchain volume and someone caused lots of channels to close, there\nmightn't be enough space for all the close channel transactions.  Some\npeople might be able to get their refund transactions included in the\nblockchain because the timeout expires.\n\nIf transactions could store enough space to be spent, then a mass channel\nclose would cause some very large blocks, but then they would have to be\nfollowed by lots of tiny blocks.\n\nThe block limit would be an average not fixed per block.  There would be 3\nlimits\n\nAbsolute hard limit (max bytes no matter what): 100MB\nHard limit (max bytes after stored bytes offset): 30MB\nSoft limit (max bytes equivalents): 10MB\n\nBlocks lager than ~32MB require a new network protocol, which makes the\nhard fork even \"harder\".  The protocol change could be \"messages can now be\n150MB max\" though, so maybe not so complex.\n\n\n\u003e\n\u003e \u003e This requires that transactions include scriptPubKey information when\n\u003e \u003e broadcasting them.\n\u003e\n\u003e Brilliant!  I completely missed that possibility...\n\u003e\n\nI have written a BIP about it.  It is still in the draft stage.  I had a\nlook into writing up the code for the protocol change.\n\nhttps://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki\nhttps://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/32dabf8f/attachment.html\u003e"}