Re: [bitcoin-dev] Flag day activation of segwit

[Nick ODell via bitcoin-dev]

The problem with modifying Bitcoin to work around community norms is that
it's a two-way street. Other people can do it too.

Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
1506812400. It enforces every rule that UASF enforces, plus one additional
rule. If 60% of blocks in any retargeting period signal for Double UASF,
any descendant block that creates or spends a segregated witness output is
invalid.

Double UASF signaling never coincides with UASF signaling, because the
signaling periods don't overlap. Full nodes happily validate the chain,
because Double UASF doesn't break any rules; it just adds new ones. Miners
who adopt Double UASF don't need to understand segwit, because all segwit
transactions are banned. Miners don't need to commit to a wtxid structure,
either. Per BIP 141, "If all transactions in a block do not have witness
data, the commitment is optional." Segwit is activated, but useless. Miners
who *do* adopt segwit will lose money, as their blocks are orphaned.

Thanks,
--Nick

On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I recently posted about so called "user activated soft forks" and received
> a lot of feedback. Much of this was how such methodologies could be applied
> to segwit which appears to have fallen under the miner veto category I
> explained in my original proposal, where there is apparently a lot of
> support for the proposal from the economy, but a few mining pools are
> vetoing the activation.
>
> It turns out Bitcoin already used flag day activation for P2SH[1
> ],
> a soft fork which is remarkably similar to segwit. The disadvantage of a
> UASF for segwit is there is an existing deployment. A UASF would require
> another wide upgrade cycle (from what I can see, around 80% of existing
> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
> ][3
> ].
> While absolute node count is meaningless, the uprgrade trend from version
> to version seems significant.
>
> Also it is quite clear a substantial portion of the ecosystem industry has
> put in time and resources into segwit adoption, in the form of upgrading
> wallet code, updating libraries and various other integration work that
> requires significant time and money. Further more, others have built
> systems that rely on segwit, having put significant engineering resources
> into developing systems that require segwit - such as several lightning
> network system. This is much more significant social proof than running a
> node.
>
> The delayed activation of segwit is also holding back a raft protocol of
> innovations such as MAST, Covenants, Schnorr signature schemes and
> signature aggregation and other script innovations of which, much of the
> development work is already done.
>
> A better option would be to release code that causes the existing segwit
> deployment to activate without requiring a completely new deployment nor
> subject to hash power veto. This could be achieved if the economic majority
> agree to run code that rejects non-signalling segwit blocks. Then from the
> perspective of all existing witness nodes, miners trigger the BIP9
> activation. Such a rule could come into effect 4-6 weeks before the BIP9
> timeout. If a large part of the economic majority publicly say that they
> will adopt this new client, miners will have to signal bip9 segwit
> activation in order for their blocks to be valid.
>
> I have drafted a BIP proposal so the community may discuss
> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
> text below).
>
> References:
> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/
> src/main.cpp#L1281-L1283
> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/
> evidence_of_widespread_segwit_support_near50_of/
>
> Proposal text:
>
> 
>   BIP: bip-segwit-flagday
>   Title: Flag day activation for segwit deployment
>   Author: Shaolin Fry 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Informational
>   Created: 2017-03-12
>   License: BSD-3-Clause
>CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a BIP16 like soft fork flag day activation of the 
> segregated witness BIP9 deployment known as "segwit".
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 
> 1, between November 15th 2016 and November 15th 2017 to activate BIP141, 
> BIP143 and BIP147.
>
> ==Motivation==
>
> Cause the mandatory activation of the existing segwit d

Re: [bitcoin-dev] Flag day activation of segwit

[Luke Dashjr via bitcoin-dev]

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...

Also, IMO this should tolerate as many as 5% minus one non-signalling blocks.

Disclaimer: This are technical suggestions, and do not imply endorsement of 
the idea.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

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.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

[Bram Cohen via bitcoin-dev]

Shouldn't there be a FAQ about this? All the blocksize increase proposals
going back to the Bitcoin Classic have the same problems and having
repeated proposals which move the details around a bit doesn't add anything
to the discussion.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Flag day activation of segwit

[shaolinfry via bitcoin-dev]

I recently posted about so called "user activated soft forks" and received a 
lot of feedback. Much of this was how such methodologies could be applied to 
segwit which appears to have fallen under the miner veto category I explained 
in my original proposal, where there is apparently a lot of support for the 
proposal from the economy, but a few mining pools are vetoing the activation.

It turns out Bitcoin already used flag day activation for 
P2SH[[1](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283)],
 a soft fork which is remarkably similar to segwit. The disadvantage of a UASF 
for segwit is there is an existing deployment. A UASF would require another 
wide upgrade cycle (from what I can see, around 80% of existing nodes have 
upgraded from pre-witness, to NODE_WITNESS 
capability[[2](http://luke.dashjr.org/programs/bitcoin/files/charts/services.html)][[3](https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/)].
 While absolute node count is meaningless, the uprgrade trend from version to 
version seems significant.

Also it is quite clear a substantial portion of the ecosystem industry has put 
in time and resources into segwit adoption, in the form of upgrading wallet 
code, updating libraries and various other integration work that requires 
significant time and money. Further more, others have built systems that rely 
on segwit, having put significant engineering resources into developing systems 
that require segwit - such as several lightning network system. This is much 
more significant social proof than running a node.

The delayed activation of segwit is also holding back a raft protocol of 
innovations such as MAST, Covenants, Schnorr signature schemes and signature 
aggregation and other script innovations of which, much of the development work 
is already done.

A better option would be to release code that causes the existing segwit 
deployment to activate without requiring a completely new deployment nor 
subject to hash power veto. This could be achieved if the economic majority 
agree to run code that rejects non-signalling segwit blocks. Then from the 
perspective of all existing witness nodes, miners trigger the BIP9 activation. 
Such a rule could come into effect 4-6 weeks before the BIP9 timeout. If a 
large part of the economic majority publicly say that they will adopt this new 
client, miners will have to signal bip9 segwit activation in order for their 
blocks to be valid.

I have drafted a BIP proposal so the community may discuss 
https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full text 
below).

References:
[1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
[2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
[3]: 
https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/

Proposal text:

 BIP: bip-segwit-flagday Title: Flag day activation for segwit deployment 
Author: Shaolin Fry  Comments-Summary: No comments 
yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP- 
Status: Draft Type: Informational Created: 2017-03-12 License: BSD-3-Clause 
CC0-1.0  ==Abstract== This document specifies a BIP16 like soft fork flag 
day activation of the segregated witness BIP9 deployment known as "segwit". 
==Definitions== "existing segwit deployment" refer to the BIP9 "segwit" 
deployment using bit 1, between November 15th 2016 and November 15th 2017 to 
activate BIP141, BIP143 and BIP147. ==Motivation== Cause the mandatory 
activation of the existing segwit deployment before the end of midnight 
November 15th 2017. ==Specification== All times are specified according to 
median past time. This BIP will be activate between midnight October 1st 2017 
(epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) 
if the existing segwit deployment is not activated before epoch time 
1538352000. This BIP will cease to be active when the existing segwit 
deployment activates. While this BIP is active, all blocks must set the 
nVersion header top 3 bits to 001 together with bit field (1<<1) (according to 
the existing segwit deployment). Blocks that do not signal as required will be 
rejected. === Reference implementation ===  // 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"); } }  
==Backwards Compatibility== This deployment is compatible with the existing 
"segwit" bit 1 deployment scheduled between midnigh

Re: [bitcoin-dev] Moving towards user activated soft fork activation

[shaolinfry via bitcoin-dev]

Thank you all for the insightful feedback, on list, in private and on various 
social media platforms. I have extended the generalized proposal which extends 
BIP9. This basically introduces an extra workflow state if activationtime > 
starttime and < timeout - 1 month. It allows extra business logic to be added, 
such as requiring mandatory signalling.

Please find the draft here:

https://gist.github.com/shaolinfry/70d0582db7de958b7d5b6422cfef4e22

 BIP: bip-uaversionbits-strong Title: Version bits extension with 
mandatory activation Author: Shaolin Fry  
Comments-Summary: No comments yet. Comments-URI: 
https://github.com/bitcoin/bips/wiki/Comments:BIP- Status: Draft Type: 
Informational Created: 2017-03-09 License: BSD-3-Clause CC0-1.0  
==Abstract== This document specifies an extension to BIP9 that introduces an 
additional activation parameter to deploy backward-compatible changes (further 
called "soft forks") to be activated by a deadline. ==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 an way 
for full nodes to coordinate syncronized activation based on a median past time 
using the BIP9 state machine. Hashrate may optionally trigger activation before 
the user defined activation sequence triggers. ==Specification== This 
specification adds a new per-chain deployment parameter to the existing BIP9 
specification as follows: # The '''activationtime''' specifies a minimum median 
time past of a block at which the deployment should transition to the locked-in 
state. This specification adds a new workflow state, '''PRE_LOCK_IN''' to the 
BIP9 state machine if the deployment '''activationtime''' is greater than zero 
when the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' 
-> '''LOCKED_IN''' -> '''ACTIVE'''. The '''PRE_LOCK_IN''' phase allows optional 
per deployment processing, e.g. mandatory signalling. ===Selection 
guidelines=== The following guidelines are suggested for selecting these 
parameters for a soft fork: # '''activationtime''' should be set to some date 
in the future and must be less than the BIP9 '''timeout'''. It is recommended 
to have an activation time of 1 year minus 30 days (28944000 seconds). The 
'''activationtime''' cannot be less than 30 days before the '''timeout'''. 
===State transitions=== The state transition workflow is exactly the same as in 
BIP9 except when '''activationtime''' is greater than zero. Then the workflow 
will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' 
-> '''ACTIVE'''. When in the STARTED state if the median time past is greater 
than or equal to the '''activationtime''' then the state will transition to 
PRE_LOCK_IN on the next retarget after '''activationtime'''. case STARTED: // 
Transition to THRESHOLD_PRE_LOCK_IN if mandatory activation is set if 
((nActivationTime != 0) && pindexPrev->GetMedianTimePast() >= nActivationTime) 
{ stateNext = THRESHOLD_PRE_LOCK_IN; break; } // BIP9 specification follows if 
(GetMedianTimePast(block.parent) >= timeout) { return FAILED; } int count = 0; 
walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; if 
(walk.nVersion & 0xE000 == 0x2000 && (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-strong
  Optional mandatory signalling   /** * Return true if nVersion 
BIP9 deployment is signalling during * mandatory periods. */ bool 
IsMandatorySignalling(int32_t nVersion, Consensus::DeploymentPos pos, const 
CBlockIndex* pindexPrev, const Consensus::Params& params) { // Check the 
deployment is in the correct state for this check to apply. if 
(!((VersionBitsState(pindexPrev, params, pos, versionbitscache) == 
THRESHOLD_PRE_LOCK_IN) || (VersionBitsState(pindexPrev, params, pos, 
versionbitscache) == THRESHOLD_LOCKED_IN))) return true; // return signalling 
state return (((nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && 
(nVersion & VersionBitsMask(params, pos)) != 0); } // segwit signalling is 
mandatory during PRE_LOCK_IN and LOCKED_IN phase if 
(!IsMandatorySignalling(block.nVersion, Consensus::DEPLOYMENT_EXAMPLE, 
pindexPrev, consensusParams)) return state.Invalid(false, REJECT_OBSOLETE, 
strprintf("bad-version(0x%08x)", block.nVersion), strprintf("rejected 
nVersion=0x%08x block, must upgrade", block.nVersion));  ==Deployments== 
A living list of deployment proposals can be found 
[[bip-0009/assignments.mediawiki|here]]. ==Copyright== This document is placed 
in the public domain.___
bitcoin-dev mailing list
bitcoin-dev@lists.lin

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

[Dionysis Zindros via bitcoin-dev]

Are you aware of Washington Sanchez's BIP 107? It is a proposal
similar to yours:

https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki

On Sun, Mar 12, 2017 at 4:44 PM, David Vorick via bitcoin-dev
 wrote:
> What, in your appraisal, is the purpose of the block size limit? I think we
> will be more able to have a productive discussion around this proposal if we
> clear that up first.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

[David Vorick via bitcoin-dev]

What, in your appraisal, is the purpose of the block size limit? I think we
will be more able to have a productive discussion around this proposal if
we clear that up first.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

[ashish khandekar via bitcoin-dev]

BLOCKCHAIN CONGESTION – A SOLUTION AND PRE-EMPTIVE MEASURES FOR THE FUTURE



This document is an idea for helping the bitcoin block chain get
uncongested, provide enough space for transactions to get included in
blocks easily, and give the bitcoin network the power to defend itself
against any stress tests or spam attacks in the future.



The current maximum size of a block in the bitcoin protocol is 1mb.This has
created a “fee market” allowing those who can send high transaction fees
only to use bitcoin easily, making those who use even a slight lower fee to
wait for transactions to get confirmed by miners, sometimes it take hours
but sometimes it can scale up to a few days, this creates a difficulty for
merchants who use bitcoin to operate with ease, new people who are adapting
to bitcoin, and those unaware of the developments in the bitcoin community
confused in why transactions aren’t getting confirmed as they used to.



Bitcoin is a highly versatile. From its price being directly influenced by
its demand and supply to the amount of work done to keep the network safe
a.k.a. mining. Over the years both have changed dramatically but one thing
which has stayed constant is the size of the block, which is 1mb. The limit
of 1mb creates only a finite number of transactions to get confirmed even
if used to the brim, leaving out other transactions and creating a backlog
of transaction to be carried forward indefinitely.



Bitcoin’s verification system, mining, has a dynamic difficulty calculation
rate, which means every 2016 blocks or 2 weeks the difficulty changes
making mining little bit easy or a bit difficult, but keeping the same
maximum output of 1mb per block, so this means every 2 weeks on 2016mb
worth of transactions can get verified assuming all blocks are filled to
the brim, any amount of excess transactions would not get verified due to
lack of space and would get carried over to the next cycle, over a period
of time this becomes a massive amount and has led to the current blockchain
congestion.



A unique solution is to let the bitcoin network change the maximum block
size as per the prevailing network conditions, this solution borrows some
aspects of both the demand and supply factor and dynamic change of network
difficulty (amount of work done to verify transactions).



This would be achieved by tracking the volume of the total size of
transactions done between 2 consecutive network difficulty changes and
dividing it by 2016, the number of blocks mined between 2 consecutive
network difficulty changes. The resulting answer would be rounded up to the
nearest kb and then compared to the previous block size, the higher between
the two would be taken as the new maximum block size. The extra space would
be helpful if a malicious attacker tries to create a lot of small dust
transactions and flood the network. Let us take a look at a  example of how
it would affect the bitcoin network in a real life scenario.



Dynamic block size calculation (B) = Total size of transactions from
previous network difficulty change(ST) / 2016

We compare this with the current block size and the higher is accepted as
new block size.



For example purposes the block numbers have been changed for easy
understanding.

If during cycle 1, block number 1 to block number 2016 the total size of
transactions is 1608mb,recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) = ST/2016

1608/2016=0.79761905   which is 797kb

We compare this with the current block size which is 1mb (current block
size in real life) and the higher of the two becomes the block size for the
next cycle.

During cycle 2, block number 2017 to block number 4032 the total size of
transactions is 2260mb, recalculating it with the dynamic block size
algorithm would give the following result:

Dynamic block size calculation (B) = ST/2016

2260/2016=1.12103175   which is 1.2mb

We compare this with the current block size which is 1mb and the higher of
the two becomes the block size for the next cycle, in this case 1.2 mb
blocks would be new block size.



The above examples can be repeated indefinitely allowing the network to
adjust the block size automatically. The dynamic block size is to be
calculated at the same time as the network difficulty is changed.

To avoid orphaning of blocks and very small blocks a minimum block size
should also be taken into effect, the minimum size of the block should be
in the range of 30-60% of the maximum block size; this measure would also
stop the propagation of very small blocks which aren’t verifying
transactions and helping the network grow.



THE END

Any questions ?

Mail me at: contash...@gmail.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev