rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2015-05-19 📝 Original message:On Mon, May 18, 2015 at 2:42 AM, Rusty Russell <rusty at rustcorp.com.au> wrote: > OK. Be nice if these were cleaned up, but I guess it's a sunk cost. > Yeah. On the plus side, as people spend their money, old UTXOs would be used up and then they would be included in the cost function. It is only people who are storing their money long term that wouldn't. They are unlikely to have consumed their UTXOs anyway, unless miners started paying for UTXOs. We could make it a range. UTXOs from below 355,000 and above 375,000 are included. That can create incentive problems for the next similar change, I think a future threshold is better. > He said "utxo_created_size" not "utxo_created" so I assumed scriptlen? > Maybe I mis-read. > But you made that number up? The soft cap and hard byte limit are > different beasts, so there's no need for soft cost cap < hard byte > limit. > I was thinking about it being a soft-fork. If it was combined with the 20MB limit change, then it can be anything. I made a suggestion somewhere (her or forums not sure), that transactions should be allowed to store bytes. For example, a new opcode could be added, <byte_count> OP_LOCK_BYTES. This makes the transaction seem <byte_count> larger. However, when spending the UTXO, that transaction counts as <byte_count> smaller, even against the hard-cap. This would be useful for channels. If channels were 100-1000X the blockchain volume and someone caused lots of channels to close, there mightn't be enough space for all the close channel transactions. Some people might be able to get their refund transactions included in the blockchain because the timeout expires. If transactions could store enough space to be spent, then a mass channel close would cause some very large blocks, but then they would have to be followed by lots of tiny blocks. The block limit would be an average not fixed per block. There would be 3 limits Absolute hard limit (max bytes no matter what): 100MB Hard limit (max bytes after stored bytes offset): 30MB Soft limit (max bytes equivalents): 10MB Blocks lager than ~32MB require a new network protocol, which makes the hard fork even "harder". The protocol change could be "messages can now be 150MB max" though, so maybe not so complex. > > > This requires that transactions include scriptPubKey information when > > broadcasting them. > > Brilliant! I completely missed that possibility... > I have written a BIP about it. It is still in the draft stage. I had a look into writing up the code for the protocol change. https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx.mediawiki https://github.com/TierNolan/bips/blob/extended_transactions/bip-etx-fork.mediawiki -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150519/32dabf8f/attachment.html>