<unnamed>

Public Key

npub12ykxgdg6sh5ny0p54ufmfh70xgrptwktpyfj4ek6nnn8rdu59qjscvwd8g

Profile Code

nprofile1qqs9ztryx5dgt6fj8s627ya5ml8nyps4ht9sjye2umdfeen3k72zsfgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds9369xu

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:59:31 CEST

- reply

📅 Original date posted:2017-04-06
📝 Original message:After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds allowing user activated soft forks that can be activated early by the hash power.
Specification: https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki
Previous discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
<pre>
BIP: ?
Title: Version bits extension with guaranteed lock-in
Author: Shaolin Fry <shaolinfry at protonmail.ch>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2017-02-01
License: BSD-3-Clause
CC0-1.0
</pre>
==Abstract==
This document specifies an extension to BIP9 that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").
==Motivation==
BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.
This specification provides a way to optionally guarantee lock-in at the end of the BIP9 timeout, and therefore activation.
==Specification==
This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows:
# The '''lockinontimeout''' boolean if set to true, will transition state to LOCKED_IN at timeout if not already ACTIVE.
===State transitions===
<img src="bip-uaversionbits/states.png" align="middle"></img>
The state transition workflow is exactly the same as in BIP9 with an additional rule: During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached.
case STARTED:
// BIP9 specification follows
if (GetMedianTimePast(block.parent) >= timeout) {
return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;
=== Reference implementation ===
https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits
==Deployments==
A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]].
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/f7781921/attachment-0001.html>

2023-06-07 19:57:14 CEST

- reply

📅 Original date posted:2017-03-13
📝 Original message:From: luke at dashjr.org
On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:
> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017
> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&
> pindex->GetMedianTimePast() <= 1510704000 &&
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,
> Consensus::DEPLOYMENT_SEGWIT)) != 0) {
> return state.DoS(2, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID,
> "bad-no-segwit");
> }
> }
I don't think this is actually BIP 9 compatible. Once activated, the bit loses
its meaning and should not be set. So you need to check that it hasn't locked-
in already...
I believe that is handled.
time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
Signalling is only required from October 1st until the BIP9 timeout, or, until segwit is activated. The bit becomes free after activation/timeout as per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the LOCKED_IN period - it would be trivial to add a condition to not require mandatory signalling during LOCKED_IN but since miners signal by default during this period, I figured I would leave it.
I thought about 5% tolerance. but I don't think it makes sense since miners will already have plenty of warning this is coming up and the intent of the mandatory signalling period is quite clear. It also seems a bit weird to say "it's mandatory but not for 5%". If miners are required to signal, they need to signal. It also adds unnecessary complexity to an otherwise simple patch.
That said, I have no strong feelings either way on both counts, but I chose to present the simplest option first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/236ddda6/attachment-0001.html>

2023-06-07 19:57:13 CEST

- reply

📅 Original date posted:2017-03-12
📝 Original message:Before setting a flag day, I think we should get written cooperation agreements from the largest economic players in Bitcoin. This would include:
There isn't a flag day to set. If the major economic organs like exchanges run the BIP, non-signalling miners simply wont get paid (starting October 1st) and their blocks will be rejected. Miners will have the choice to signal, or find something else profitable to mine. In turn, this will trigger the existing segwit deployment for everyone who has already upgraded to segwit compatible node software (currently Bitcoin Core 0.13.1, 0.13.2, 0.14.0, Bitcoin Knots 0.13.1+, and bcoin) regardless of whether they run this BIP or not.
But yes, it goes without saying that this BIP would need to have buy-in from major economic organs, especially fiat egress points, before being deployed. Failing that, a second deployment of segwit with a flag day, or preferably using the bip-uaversionbits-strong BIP9/flagday hybrid would be required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/26c0106f/attachment.html>