Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:

Peter,

> Yes, it is different.  It’s different because the future network
> upgrade to larger blocks includes a loosening of the consensus
> ruleset whereas previous upgrades have included a tightening of the
> rule set.  (BTW—this is not my proposal, I am describing what I
> have recently learned through my work with Bitcoin Unlimited and
> discussions with miners and businesses).

The repeated use of the term "network upgrade" in place of the
accepted technical term (hard fork) is misleading. This and the
presupposition that the hard fork is coming, and the claims that it's
not your proposal, make me feel like I'm shopping for a used car...
It's not used it's pre-owned, everyone's getting the warranty, let me
see what my manager has to say about the price - it's not my decision.

This is a development list. Avoidance of standardized terminology and
use of the presumptive close diminishes your message.

> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.

"tightening of the rule set" == soft fork

This implies that the minority hash power is producing blocks that are
valid according to rules in existence prior to the soft fork. You are
referring to these as invalid, but because this has already confused
one commentator, let's be clear. The blocks you are referring to are
valid blocks being orphaned because the majority hash power is
rejecting them because of soft fork activation. This of course
produces a minority chain, so this statement is incorrect.

> With a loosening of the consensus rule set, the situation is
> different: a hash power minority that has not upgraded will produce
> a minority branch, that will also drag along non-upgraded node
> operators, leading to potential confusion.

"loosening of the consensus rule set" == hard fork

This is also incorrect. In the case of a hard fork old nodes reject
the new blocks that are invalid according to old rules and continue to
accept other old blocks. This produces a second distinct chain. It is
neither a majority nor a minority chain with respect to the original.
It is simply a new coin that happens to share history with the old
coin. This doesn't imply confusion, since both chains continue to
operate under the rules of their nodes. The only confusion arises from
people wanting to transaction across *both* chains. It is only in this
context that replay becomes an issue.

> The idea behind orphaning the blocks of non-upgraded miners was to
> serve as a wake-up call to upgrade, to reduce the chances of a
> minority chain emerging in the first place, similar to what happens
> automatically with a soft-forking change.  If one's worry is a
> chain split, then this seems like a reasonable way to reduce the 
> chances of that worry materializing.  The Level 3 anti-split
> protection takes this idea one step further to ensure that if a
> minority branch does emerge, that transactions cannot be confirmed
> on that branch.

Stopping people from transacting on the old chain due to an ongoing
51% attack (again, using proper terminology) is one way to make it
hard for people to transact on both chains. But if you don't care that
people are able to transact on both chains, there's no reason to spend
the money on the attack.

So let me point to the elephant in the room. The proposed 51% attack
is more obviously an attempt to transfer economic activity from BTC to
BTU, not a benevolent measure to prevent confusion. It can clearly be
viewed as elimination of competition through an electronic attack on
BTC operations. Given that they are all regulated entities, I'm not
sure how the envisioned large miner collaborators (or others who might
fund it) will feel about participation in the scheme.

> This is not a fight about “Core vs. BU”; Bitcoin’s future is one
> of “genetic diversity” with multiple implementations, so that a bug
> in one doesn’t threaten the network as a whole

You are right that this is not about Core and BU. These are
implementations, not protocols. However, please do not presume that
other implementations are enlisted in your scheme, or that this is
about making the network more bug-resistant.

> To me it seems this is largely a fight about whether node operators
> should be easily able to adjust the size of blocks their nodes
> accept.  BU makes it easy for node operators to accept larger
> blocks; Core doesn’t believe users should have this power (outside
> of recompiling from source, which few users can do).

I feel like making the block size a configuration option in Libbitcoin
just to emphasize the gross error of this idea. It has never been
about the inability of users to compile the code. It's about the
purposeful difficulty in changing the rules when everyone ha

[bitcoin-dev] Bandwidth limits and LN w/ node relay network topography

[praxeology_guy via bitcoin-dev]

Bandwidth limits:
Would be nice to specify global and per node up/down bandwidth limits.
Communicate limits to peers.
Monitor actual bandwidth with peers.
Adjust connections accordingly to attain bandwidth goals/limits.

With Lightning Network:
Prepay for bandwidth/data. Continue paying nodes who continue to send new 
useful data. Potentially pay different amounts for different kinds of data.
Request refunds when a node sends useless/duplicate/invalid/spam data. 
Discontinue connection w/ nodes that don't refund. Hence LN payment channel 
network topography becomes somewhat correlated w/ bitcoin node relay network 
topography.

Should help nodes get better data faster, improve spam/DDoS resiliance. 
Incentivizes relay of unconfirmed txs and new blocks, when currently there is 
only a utilitarian marginal self benefit via helping everyone in general.

Maybe relay advertisements of available bandwidth and prices, etc.

To identify network splits:
Nodes could find hash of "nonce + pub key + tip blockhash" beating a difficulty 
threshold. Sign, broadcast. Prove their existence and connectedness. History 
can be maintained and monitored for disruption. Could be made part of the 
messages that advertise available network bandwidth.

Cheers,
Praxeology Guy___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Tom Harding via bitcoin-dev]

On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
>  > wrote:
>
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
>
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told miners
> otherwise, let me know.
>

A reasonable miner automatically checks every transaction seen, to see
if it might be valid with his own outputs substituted.

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

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/26/2017 01:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev 
>  > wrote:
> 
> With a tightening of the rule set, a hash power minority that has 
> not upgraded will not produce a minority branch; instead they will 
> simply have any invalid blocks they produce orphaned, serving as a 
> wake-up call to upgrade.
> 
> False. With bip9-based soft-fork-based activation of segwit, miner 
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told
> miners otherwise, let me know.

Given the protocol requirements of the segwit proposal this is not the
case. A miner running pre-segwit code will produce blocks that no
segwit node will ever receive. It matters not whether these blocks
contain transactions that are invalidated by the soft fork. Despite
being valid to other pre-segwit nodes they will never be built upon by
the majority hash power once segwit activates.

At the same time, Peter's comment above is also incorrect. A "minority
branch" *is* a set of blocks that have been orphaned (the term orphan
being a misnomer, since these blocks of course have an ancestry all
the way to the genesis block). That's precisely what is implied by the
word "minority". So his description contradicts itself.

e
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY2C6pAAoJEDzYwH8LXOFOf4gH/2e/euZ9bQxPKZyC7DN8us6T
R1R9f+JFFsU3Vo8HkcU028Ib4aF0IAELvAWrhpZfH6ixZV2c3CJoi53rMbPmJ/+H
Rlj0Qjc58mYpqosxyNoi0qPFZ2e3yCv+R5v9PQEeOdcGwXIr77Tij8lI1yu4uqHU
bqJ3BXJLFpvL5iXOLhbakeu2qVIHqJnb1/hQMNh6eNM794n+UT2T8You52xUkuTm
zJ+5CTQUiMNFE/HBWsbk8Vf3BTrM0sqMRTJzdr4VT1l+uOZn58BJJPFzLr2WeZww
klAB/wK5oExMNlKQVy6Rw9+uFx88qRTl5s7LwFASOxEZYJIjd36bBaoTdqfaB5U=
=pvlp
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Trevin Hofmann via bitcoin-dev]

>> With a tightening of the rule set, a hash power minority that has not
upgraded will not produce a minority branch; instead they will simply have
any invalid blocks they produce orphaned, serving as a wake-up call t>o
upgrade.

> False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.

He stated that "any invalid blocks they produce" will be orphaned. This is
not false. If non-upgraded miners do not produce blocks that are invalid
per the new rules, their blocks will not be orphaned. This is consistent
with Peter's comment.

-Trevin

On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> With a tightening of the rule set, a hash power minority that has not
>> upgraded will not produce a minority branch; instead they will simply have
>> any invalid blocks they produce orphaned, serving as a wake-up call to
>> upgrade.
>>
>
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
> will not be orphaned unless they are intentionally segwit-invalid (which
> they currently are not). If you have told miners otherwise, let me know.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> ___
> 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] Defending against empty or near empty blocks from malicious miner takeover?

[Bryan Bishop via bitcoin-dev]

On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann 
wrote:

> He stated that "any invalid blocks they produce" will be orphaned. This is
> not false. If non-upgraded miners do not produce blocks that are invalid
> per the new rules, their blocks will not be orphaned. This is consistent
> with Peter's comment.


It's the other part of the statement- the "wakeup call to upgrade" from
producing invalid blocks? They aren't producing invalid blocks.
Additionally, if they want to be even more sure about this, they can run
the so-called "border nodes". No wakeup calls needed the point of a
soft-fork is to reduce incompatibility.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Bryan Bishop via bitcoin-dev]

On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>

False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Alphonse Pace via bitcoin-dev]

As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem.  Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would.  If you wish to fork off, please do so responsibly.

-Alphonse

On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different.  It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set.  (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion.  The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change.  If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing.  The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners.  The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well.  I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well.  All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created.  The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade.  Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy.  But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different.  I still have never talked with a person
> in real life who doesn’t want the block size limit to increase.  Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth.  For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole.  To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept.  BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find i

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Peter R via bitcoin-dev]

Hello Alex,

Thank you for the thoughtful reply.  

> Surely you are aware that what you are proposing is vastly different from the 
> way soft forks have historically worked. 

Yes, it is different.  It’s different because the future network upgrade to 
larger blocks includes a loosening of the consensus ruleset whereas previous 
upgrades have included a tightening of the rule set.  (BTW—this is not my 
proposal, I am describing what I have recently learned through my work with 
Bitcoin Unlimited and discussions with miners and businesses).  

With a tightening of the rule set, a hash power minority that has not upgraded 
will not produce a minority branch; instead they will simply have any invalid 
blocks they produce orphaned, serving as a wake-up call to upgrade.  

With a loosening of the consensus rule set, the situation is different: a hash 
power minority that has not upgraded will produce a minority branch, that will 
also drag along non-upgraded node operators, leading to potential confusion.  
The idea behind orphaning the blocks of non-upgraded miners was to serve as a 
wake-up call to upgrade, to reduce the chances of a minority chain emerging in 
the first place, similar to what happens automatically with a soft-forking 
change.  If one's worry is a chain split, then this seems like a reasonable way 
to reduce the chances of that worry materializing.  The Level 3 anti-split 
protection takes this idea one step further to ensure that if a minority branch 
does emerge, that transactions cannot be confirmed on that branch.

> First of all, the bar for miners being on the new chain is extremely high, 
> 95%.

I’m very confident that most people do NOT want a split, especially the miners. 
 The upgrade to larger blocks will not happen until miners are confident that 
no minority chain will survive.  

> Second of all, soft forks make rule restrictions on classes of transactions 
> that are already non-standard so that any non-upgraded miners are unlikely to 
> be including txs in their blocks which would violate the new rules and should 
> not have their blocks orphaned even after the fork.

I agree that the soft-fork mechanism usually works well.  I believe this 
mechanism (or perhaps a modified version of it) to increase the block size 
limit will likewise work well.  All transactions types that are currently valid 
will be valid after the upgrade, and no new types of transactions are being 
created.  The “block-size-limit gene" of network nodes is simply evolving to 
allow the network to continue to grow in the way it has always grown. (If 
you’re interested, here is my talk at Coinbase where I discuss this: 
https://www.youtube.com/watch?v=pWnFDocAmfg 
)

> Finally, soft forks are designed to only be used when there is a very wide 
> community consensus and the intention is not to overrule anyone's choice to 
> remain on the old rules but to ensure the security of nodes that may have 
> neglected to upgrade.  Obviously it is impossible to draw a bright line 
> between users who intentionally are not upgrading due to opposition and users 
> that are just being lazy.  But in the case of a proposed BU hard fork it is 
> abundantly clear that there is a very significant fraction, in fact likely a 
> majority of users who intentionally want to remain on the old rules.

My read is completely different.  I still have never talked with a person in 
real life who doesn’t want the block size limit to increase.  Indeed, I have 
met people who worry that Bitcoin Unlimited is “trying to take over”—and thus 
they are worried for other reasons—but this couldn’t be further from the truth. 
 For example, what most people within BU would love to see is a simple patch to 
Bitcoin Core 0.14 that allows node operators to adjust the size of blocks their 
nodes will accept, so that these node operators can follow consensus through 
the upgrade if they choose to.  

This is not a fight about “Core vs. BU”; Bitcoin’s future is one of “genetic 
diversity” with multiple implementations, so that a bug in one doesn’t threaten 
the network as a whole.  To me it seems this is largely a fight about whether 
node operators should be easily able to adjust the size of blocks their nodes 
accept.  BU makes it easy for node operators to accept larger blocks; Core 
doesn’t believe users should have this power (outside of recompiling from 
source, which few users can do).  

> As a Bitcoin user I find it abhorrent the way you are proposing to 
> intentionally cripple the chain and rules I want to use instead of just 
> peacefully splitting.

Once again, this is not my proposal.  I am writing about what I have come to 
learn over the past several weeks.  When I first heard about these ideas, I was 
initially against them too.  They seemed harsh and merciless.  It wasn’t until 
I got out their and started talking to more people in the community that the 
rationale started to make sense to 

Re: [bitcoin-dev] Fraud proofs for block size/weight

[Chris Pacia via bitcoin-dev]

On Mar 25, 2017 12:17 AM, "Luke Dashjr via bitcoin-dev"  wrote:

 Any ideas? :/


Can't the size be aggregated up the tree such that each midstate hash is
the hash of branches below plus the agreegate of the sizes below.

This would make the root  hash(left + right + size/weight) and the proof
would just be the preimage.
___
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

[praxeology_guy via bitcoin-dev]

"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 
2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is 
signaling readiness, segwit will be activated in the retarget cycle after the 
next one"

Just change BIP9 and the code to say "if in a full retarget cycle at least 1 
out of 2016 blocks" and call it done. Or something very similar to this that 
effectively does the exact same thing. :) Wasting too much time on this. 15 Nov 
2017 is plenty of time to be ready for SegWit, and if a participant is not 
ready by then they are either unreasonably lazy, a manipulator, or manipluted, 
and we don't need them.

If non-upgrading miners refuse to build on segwit blocks, or build on malicious 
invalid segwit blocks, then so be it. We fork. We have spent enough time trying 
to convince people who don't think for themselves... if they are still 
manipulated now then its time for us to give up on helping them see the light 
and instead let them learn the hard way.

Cheers,
Praxeology Guy

 Original Message 
Subject: Re: [bitcoin-dev] Flag day activation of segwit
Local Time: March 13, 2017 5:18 PM
UTC Time: March 13, 2017 10:18 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: shaolinfry , Bitcoin Protocol Discussion 


>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() 
><= 1510704000 ...

Thanks,
--Nick

On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev 
 wrote:
From: l...@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.

___
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] Defending against empty or near empty blocks from malicious miner takeover?

[Alex Morcos via bitcoin-dev]

No I actually agree with a lot of what you said.

I feel there has been a lack of precision and consistency in talking about
these things in the past.  This is not intentional, but its just what
happens when a lot of different people are all giving their own arguments.

I tried to be a bit more clear by talking about how soft forks have
historically been done.  But certainly the technical definition of a soft
fork is a slippery slope.  I completely disagree with the idea that miners
have any right to enforce a soft fork.  Even more strongly, I don't think
they have the ability.  Censoring a certain class of transactions (such as
those invalid under a soft fork) is something they can unilaterally do, but
it is not the same thing as a soft fork.  It is necessarily transient. It
requires nodes to enforce the rules to make it a permanent soft fork.

I do think there are differences between soft forks and hard forks and
consensus requirements and safety for rolling them out.  But as mentioned
in my email, I think soft forks should still have a very high bar for
consensus.  It's an open question as to whether Core misjudged this for
segwit, although if so, I think it was a close call.  The intention is not
to let 95% of miners make the rules (although again, note that it is 95%, a
very high bar, vastly different than 75% of miners).   It seems to me that
the vast majority of the community is in favor of segwit.  I'm not sure
about your comment that it is obvious to an observer than a sizable portion
of the community is opposed.  It is certainly some, and perhaps more than
expected.  But this is exactly why the new version bits soft fork roll out
mechanism allows proposals to expire. We did do an extensive job assessing
support for segwit before roll out, and although we knew of a few loud
voices against we judged them to be a very small minority.  No business we
contacted was opposed.  If it turns out we got it wrong then the proposal
will expire harmlessly.  I for one am certainly opposed to forcing segwit
or any other fork of any kind on a significant minority that is opposed.

Despite saying that, I think you will hear some other responses about how
soft forks are opt-in and if you don't like the new features don't use
them.  There is some logic behind this idea.  But these are all subtleties
which are hard to make strong right and wrong statements about.  See some
of the past discussion on this list.




On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia  wrote:

>
>
> On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> I just want to point out what appears to be doublespeak going on here.
>
> First, I think it would seem obvious to an observer that a sizable portion
> of the community (certainly greater than 5%) view segwit as preventing
> "rules I want to use instead of just peacefully splitting" but no
> consideration was given to these people when designing segwit as a
> softfork. I believe it was Luke who went as far as saying consensus does
> not matter when it comes softforks.
>
> Furthermore, when segwit was first introduced it kicked off a round of
> softfork/hardfork debate which I participated in. The primary concern that
> I and other raised was precisely what is going on now.. that miners could
> unilaterally impose an unpopular change to the protocol rules.
>
> At the time I told, rather forcefully, by multiple people that miners have
> an "absolute right" to softfork in whatever rules they want. Which, of
> course, is absurd on it's face.
>
> But I don't see how people can make such claims on the one hand, and then
> complain when this process is used against them.
>
> It amounts to nothing more than "When it's rules I like we get to impose
> them on non-consenting users. When it's rules I don't like it's an attack
> on the network".
>
> It was completely obvious this entire time that softforks were a very
> slippery slope, now we are indeed sliding down that slope.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Chris Pacia via bitcoin-dev]

On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:


As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.


I just want to point out what appears to be doublespeak going on here.

First, I think it would seem obvious to an observer that a sizable portion
of the community (certainly greater than 5%) view segwit as preventing
"rules I want to use instead of just peacefully splitting" but no
consideration was given to these people when designing segwit as a
softfork. I believe it was Luke who went as far as saying consensus does
not matter when it comes softforks.

Furthermore, when segwit was first introduced it kicked off a round of
softfork/hardfork debate which I participated in. The primary concern that
I and other raised was precisely what is going on now.. that miners could
unilaterally impose an unpopular change to the protocol rules.

At the time I told, rather forcefully, by multiple people that miners have
an "absolute right" to softfork in whatever rules they want. Which, of
course, is absurd on it's face.

But I don't see how people can make such claims on the one hand, and then
complain when this process is used against them.

It amounts to nothing more than "When it's rules I like we get to impose
them on non-consenting users. When it's rules I don't like it's an attack
on the network".

It was completely obvious this entire time that softforks were a very
slippery slope, now we are indeed sliding down that slope.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev