Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2015-09-16 š Original message:During Scaling Bitcoin, ...
š
Original date posted:2015-09-16
š Original message:During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.
- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set. Fee is then
evaluated after the delta is applied. This aligns user incentives with
UTXO resource usage/cost. Original idea by gmaxwell (and others??).
- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit. 2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.
- Hard fork method: Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future. Set high bit in version, resulting in a
negative number, to more cleanly fork away. "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.
- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.
Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.
For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin. Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/b53805a1/attachment.html>;
š Original message:During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be. The following is a without-attribution (Chatham House)
summary. This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.
- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set. Fee is then
evaluated after the delta is applied. This aligns user incentives with
UTXO resource usage/cost. Original idea by gmaxwell (and others??).
- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit. 2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.
- Hard fork method: Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future. Set high bit in version, resulting in a
negative number, to more cleanly fork away. "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.
- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.
Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.
For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin. Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/b53805a1/attachment.html>;