Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2015-05-19 š Original message:On Mon, May 18, 2015 at ...
š
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>;
š 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>;