Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[James Hilliard via bitcoin-dev]

On Mon, Jun 28, 2021 at 3:52 AM  wrote:
>
>
> Hi James,
> Sorry for not responding in detail.
> So, lets jump in the critiques.
>
> > You're making the assumption that miners won't build on top of a block
> with transactions they have not seen before or transactions that may
> contain double spends of unconfirmed inputs
> No, it is a wish. I hope in future miners consider this rule as well.

There's only one practical approach I'm aware of for miners to actually
do this, and that would be to effectively make mining centralized.
So I would highly discourage this sort of policy when it comes to mining.

> But for now, I absolutely do not count on this restriction. So, miner
> can/will accept a valid block which contains some valid transactions
> which they didn’t aware of those transactions in advance.

Mempools among miners are generally not fully in sync with each other,
rejecting valid blocks due to disagreements over which transactions were
broadcast would destabilize the network as you'd get a bunch of network
forks.

> In order to explain how economically this won’t happened, I have to
> refer you to the fact that a conspiracy between a miner(mining pool) and
> a group of issuers to mine a block full of cheating transaction will
> makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
> now). The 1.2 is coming from average(max) 6,000 transaction per block *
> max 20K Satoshi cheating benefit for each promised used UTXO in a
> debt-doc(transaction).

But there's no risk really for a miner to choose the most profitable
transactions to mine as long as they are valid per the network rules,
that is unless you make mining fully centralized.

> In order to achieve this conspiracy, the mining pool has to mine the
> block in stealth, lonely and without broadcasting any of transactions to
> Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
> they have to change the block header and restart again. After all, if
> they succeed, they have to divide this extra dirty 1.2 BTC in between. I

Miners regularly change block headers, and if they don't broadcast the
transactions there wouldn't really be a time limit, so even a relatively small
miner would be able to stealthily mine the transactions given enough time.

>
>
> I am not expert in mining pool calculations; you may help me to answer
> these questions?
>
> Consider these given facts:
>
> More hashrate = more success chance.
> More hashrate = more electric cost = less profit per each participator
> There is a minimum hashrate to have a minimum chance to solve the puzzle
> in next 10 minutes, otherwise it doesn't make sense to participate in an
> activity that doesn't fit the minimum hope.

Why would they need to solve the block within 10 minutes?

> How much is this minimum hashrate?

I don't think there is a minimum.

> How much costs this hashrate?

Miners just use pools to reduce variance, there isn't a set minimum size to
solo mine, only how much variance the miner can tolerate.

> Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
> be economically cost effective (risk to reward) to dedicate your
> hashrate to mine this block? I am not sure. But if you show me the
> opposite by facts and numbers, I will highly appreciate you.

All that matters is if that extra is more than they would otherwise get.

>
> > What would this BIP look like?
> > We suppose the miners always control transactions with doc-watchers
> As I told before, these assumptions are my wishes and I never relayed on
> these wishes. These are for future. For now, I just count on the
> calculation that asked you to help.

The reason I ask is because I don't think this is possible to do
without massively
centralizing mining.

>
> > there can be significant latency between the time a transaction is
> actually broadcast and hits the miners mempool and the time the miners
> actually switch to mining on top it
>
> It is great. Although this latency could be lesser (in case of empty
> mempools), but Sabu likes this latency. Because the creditors will have
> more time to be aware of a fraudulent activity from issuer and existence
> of a cheating transaction in mempool, so they have more time to send and
> broad cast the GT to network. More latency, more chance in batch update.
> So more chance for miners to face two or three transactions which are
> using same UTXO but sending to different addresses and paying different
> fees.
> More latency increases the chance of putting the higher-fee-payer
> transaction in next block.

Actually it's the opposite, if pools updated their templates every second
the GT transaction could almost immediately replace the fraudulent transaction,
however due to the batch updating if the fraudulent transaction ended up
in a template it could take a significant amount of time for it to be purged
from all the mining pool templates, no matter the fee difference.

Ultimately this means that one should always expect miners to 

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[James Hilliard via bitcoin-dev]

On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
 wrote:
>
> Hi ZmnSCPxj,
>
> Why you get the signal “trust the Gazin wallet”?
> Sabu is a protocol and the Gazin wallet will be an implementation of
> that protocol. We will implement it in react-native language to support
> both Android and iPhone. Of course it will be open source and GPL3.
> Here is the repository and yet is empty :)
> https://github.com/raymaot/Gazin
>
> I wonder why you do not look carefully into the proposal! IMHO the Sabu
> will be far better than Lightning.
> Can’t you see the fact that in Sabu you do not need open and close
> channels ever? Can you imagine only this feature how dramatically
> decrease the transactions cost and how increase the distribution of
> nodes and improve privacy level? it makes every mobile wallet act like a
> lightning network.
> Did you note the fact that in Sabu protocol there is no routing? And the
> only people knew about a transaction are issuer and creditor? No one
> else won’t be aware of transactions and million transactions per second
> can be sent and received and repeal dynamically without any footprint on
> any DLT?
>
> The English is not my mother language and probably my paper is not a
> smooth and easy to read paper, but these are not good excuse to not even
> reading a technical paper carefully and before understanding it or at
> least trying to understanding it start to complaining.

Considering that you have not effectively addressed any of the inaccurate
assumptions made regarding how mining works that I pointed out earlier
I assume your proposal is not viable in practice.

See:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html

>
> > All the benefits your scheme claims, are derived from the trust assumption
> No, All the benefits my scheme claims, are derived from economically
> rational decision of both issuer and creditors.
>
> Regards
> Raymo
>
>
>
> On 2021-06-28 05:20, ZmnSCPxj wrote:
> > Good morning Raymo,
> >
> >>
> >> It looks you already missed the entire design of Sabu and its
> >> restrictions. First of all, the Gazin wallet always controls the Sabu
> >> restrictions for every transaction in order to consider it as a valid
> >> transaction in a valid deal. That is, the creditor wallet controls the
> >> MT and GT in first place.
> >
> > Stop right there.
> >
> > From the above, what I get is, "trust the Gazin wallet".
> > Thus, the suggestion to just use Coinbase.
> > At least it has existed longer and has more current users that trust
> > it, rather than this Gazin thing.
> >
> >
> > Is Gazin open-source?
> >
> > * If Gazin is open-source, I could download the source code, make a
> > local copy that gives me a separate copy of the keys, and use the keys
> > to sign any transaction I want.
> > * If Gazin is not open-source, then why should I trust the Gazin
> > wallet until my incoming funds to an open-source wallet I control have
> > been confirmed deeply?
> >
> > Lightning is still superior because:
> >
> > * It can be open-sourced completely and even though I have keys to my
> > onchain funds, I *still* cannot steal the funds of my counterparty.
> > * Even if I connect my open-source node to a node with a closed-source
> > implementation, I know I can rely on receives from that node without
> > waiting for the transaction to be confirmed deeply.
> >
> >
> > All the benefits your scheme claims, are derived from the trust
> > assumption, which is uninteresting, we already have those, they are
> > called custodial wallets.
> > Lightning allows for non-custodiality while achieving high global TPS
> > and low fees.
> > And a central idea of Lightning is the requirement to use an n-of-n to
> > form smaller sub-moneys from the global money.
> >
> > Regards,
> > ZmnSCPxj
> ___
> 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] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[James Hilliard via bitcoin-dev]

I think you're making a number of assumptions about mining that are
not accurate.

> First of all, how much chance in finding next block the corrupted miners 
> have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10? The 
> cheaters must come up in dividing that 1.2 Bitcoin between. After all the 
> risk/reward must fit them. They can not be a big mining pool since there is 
> no benefit, so they will be small miners with low hash rate. If they solve 
> the puzzle and broadcast the block, no one in the entire Bitcoin network has 
> block transactions or seen it before in their mempool!

You're making the assumption that miners won't build on top of a block
with transactions they have not seen before or transactions that may
contain double spends of unconfirmed inputs, this is not how mining
works, as long as the block passes the consensus rules effectively all
miners will mine on top of it by default, this behavior is fundamental
to how mining currently works and is fairly deeply baked into the
current mining infrastructure.

> Will they accept this block? In theory it is possible and have 0.01 percent 
> chance but we can eliminate this small possibilities by a simple BIP for 
> miners.

What would this BIP look like? I don't see how this could work in a
decentralized way as you would need another way of reaching consensus
on what defines a valid block. Right now the chance is nearly 100
percent that a miner will mine on top of the latest valid block, many
pools(most last I checked) will even mine on the next block before
they validate the latest block fully(ie validationless mining) to
reduce their orphan rates.

> We suppose the miners always control transactions with doc-watchers and avoid 
> accepting transaction with same UTXO but different output.

Miners have different mempool policy/rules for what transactions they
themselves mine but all miners must mine on the most work chain of
valid blocks otherwise they risk their own blocks being orphaned, any
miner that does not do this is effectively guaranteed to have their
block orphaned right now.

> Because of high Bitcoin transaction fee, this guarantee transaction will take 
> place in next block, even if other transaction which are using the same UTXO 
> as input existed in mempool.

When a new transaction is broadcast miners do not immediately start
mining on a block template that includes that transaction, the
template won't even be generated immediately when it enters a miners
mempool in practice, for bandwidth/network efficiency reasons mining
pools batch update the stratum templates/jobs they mine against so
there can be significant latency between the time a transaction is
actually broadcast and hits the miners mempool and the time the miners
actually switch to mining on top it, these batched updates are
essentially like point in time snapshots of the mempool and typically
remain valid(as in the pool will accept shares submitted against that
job as valid) until the bitcoin network finds the next block. I don't
think these batch updates are done more often than every 30 seconds
typically, while often it is on the order of multiple minutes
depending on the pool.

Regards,
James

On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
 wrote:
>
> Hi,
> I have a proposal for improve Bitcoin TPS and privacy, here is the post.
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
> https://bitcointalk.org/index.php?topic=5344020.0
> Can you please read it and share your idea about it.
>
> Cheers
> Raymo
> ___
> 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

[bitcoin-dev] Decoupling BIP70 Payment Protocol from Wallets

[James Hilliard via bitcoin-dev]

Recently a large merchant payment processor has decided to drop
support for BIP21 payment URI's in favor of accepting exclusively
BIP70 payments which has brought to light a number of problems with
BIP70:

1. Many wallets do not support BIP70 and have no near term intention
of doing so.
2. BIP70 requires large complex PKI dependencies such as X.509 and TLS
support(usually via openssl) which have a large attack surface and
poor track record when it comes to vulnerabilities.
3. Signing transactions with keys resident in the same application as
that which handles TLS greatly increases the possibility of keys being
leaked due to vulnerabilities in TLS libraries such as
openssl(heartbleed etc).
4. Sending payments first to a BIP70 compatible wallet before sending
to the merchant increases fees and uses more block space than sending
directly since it is often not feasible for users to fully migrate
funds to a BIP70 compatible wallet.
5. Paying a BIP70 invoice with an incompatible wallet currently
requires manual non-user-friendly workarounds such as
https://github.com/achow101/payment-proto-interface

I propose that we move the BIP70 protocol implementation into a
browser extension that can communicate with wallets over a simple IPC
mechanism such as
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Native_messaging
in addition to acting as a translation layer that can convert BIP70
URL's into standard BIP21 URI's for wallets that do not wish to
support BIP70 or other custom schemes.

This will provide a number of advantages over the current method of
implementing BIP70 directly within wallets:

1. It removes complex/risky dependencies from wallets and moves them
into the browser which already has to implement full PKI support.
2. It re-enables payment support for wallets that only support
BIP21/normal addresses.
3. It makes offline/custom signing schemes easier to use with BIP70.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution may solve Block Withholding Attack

[James Hilliard via bitcoin-dev]

There have been some other proposals to deal with this such as
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html
that may be possible to implement in existing miners.

On Tue, Oct 3, 2017 at 9:52 AM, 潘志彪 via bitcoin-dev
 wrote:
> Here is a solution may solve Block Withholding Attack. The general idea is
> came from Aviv Zohar(av...@cs.huji.ac.il), I made it work for Bitcoin.
> Anyway, thanks Aviv.
>
> =
>
> DIFF_1 = 0x;
>
> Diff = DIFF_1 / target
>
> this is equal to
>
> Diff = DIFF_1 / (target - 0) or Diff = DIFF_1 / abs(target - 0)
>
> now, we change diff algo to below:
>
> New_Diff = DIFF_1 / abs(target - offset)
>
> Offset is 32 bytes, like uint256 in Bitcoin, range is [0, 2^256),
> define: offset_hash = DSHA256(offset).
>
> we need to do a little change to the merkle root hash algo, put the
> offset_hash as a tx hash in the front of tx hashes.
>
> [offset_hash, coinbase_tx_hash, tx01_hash, tx02_hash, … , tx_n_hash]
>
> Actually could put offset_hash in any place in the array of hashes.
>
> network_hash_range = network_hash_end - network_hash_begin
>
> miner_hash_range = miner_hash_end - miner_hash_begin
>
> The offset value MUST between network_hash_begin/end or
> miner_hash_begin/end.
>
> https://user-images.githubusercontent.com/514951/31133378-e00d9ca2-a891-11e7-8c61-73325f59f6ed.JPG
>
> When mining pool send a job to miners, put the PoW hash range
> (miner_hash_begin/end) in the job. So if the miners find a hash which value
> is between [miner_hash_begin, miner_hash_end], means it's SHOULD be a
> valid share, could submit the share to the pool. If the hash value is
> between [network_hash_begin, network_hash_end] means find a valid block.
>
> The network_diff is much much high than the miner's diff, means the
> network_hash_range is much much smaller than miner_hash_range. By now,
> a typical miner's pool diff is around 16K, network diff is 1123863285132,
> so miner_hash_range is at least million times bigger than
> network_hash_range.
> The miners only know miner_hash_range, it's impossible for cheat miners
> to find out which share could make a valid block or not.
>
> Problems:
> 1. it's a hard fork.
> 2. will make existed asic dsha256 chips useless, but I think it's only a
> small change to make new asic chips based on existed tech.
>
> ___
> 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] BIP proposal: No chaining off replaceable transactions

[James Hilliard via bitcoin-dev]

This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement. Basically you allow the fee bumped replacement
to evict the sweep transaction+parent if there is more than 1MB of
transactions(or whatever the block size/weight limit is) of
transactions between the sweep transaction+parent feerate and bumped
fee replacement feerate. This way the sweep transaction parent only
gets replaced if it is unlikely that miners would ever produce a block
template with transactions at the sweep transaction+parent feerate at
the same time as the replacement transaction feerate. From the miners
point of view this give a higher fee block template overall since it
would be unlikely that one would see transactions with the feerate of
both the CPFP sweep and the replacement parent in the same block
template.

On Sun, Jul 2, 2017 at 10:02 PM, Rhavar via bitcoin-dev
 wrote:
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
> It actually doesn't really matter much.
>
> Let's say I want to pay Alice and Bob (unrelated entities), so I send it to
> them (together) with a low-fee transaction of paying 50 sat/byte. After an
> hour it's obvious that it's not confirmed (maybe there was a big backlog, or
> no blocks mined), so I want to replace my small transaction with one that
> pays 70 sat/byte.
>
> But in the mean time, Alice has swept her wallet (or used a service that has
> done so) and generated 50KB of descendant transactions paying 40 sat/byte
> (i.e. total fees of 0.02 BTC or $50).
>
> According to the BIP125 rules, I would need to pay for the cost of
> invalidating all the transactions (an absolute higher amount of fee) along
> with the replay cost of the descendant transactions.
>
> So in this case, for me to fee bump the transaction I'm looking at throwing
> away $50 because of descendant transactions that were totally out of my
> control.  If I don't fee bump, I violate my promise to Bob to pay in a
> timely manner (and also probably Alice, as it wasn't in her control she was
> using an exchange that did this).
>
> If I guarantee to fee bump, the amount I risk is effectively unbounded. And
> even if the descendant transactions have a higher fee rate, and are
> assisting by CPFP boosting my transaction -- it very well might not be
> enough.
>
> --
>
> The idea of this proposal comes from the problems *in practice* of trying to
> low-ball fee estimation with scheduled continuous fee bumps until it
> confirms. At the moment it's not viable, but if this proposal was adopted
> then it would be.
>
> Personally I think it's of critical piece of having a stable fee market. Fee
> estimation is a fools game, even the new and improved fee estimation in
> master today was suggesting x30 fees to what was required (and I
> successfully made transactions with). People (and especially services) being
> able to be able to dynamically increase their fees sanely when dealing with
> withdrawals (and especially batched ones) will go a long way to helping the
> overall ecosystem.
>
>
> -Ryan
>
>
>  Original Message 
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable
> transactions
> Local Time: July 2, 2017 9:28 PM
> UTC Time: July 3, 2017 2:28 AM
> From: g...@xiph.org
> To: Rhavar 
> bitcoin-dev@lists.linuxfoundation.org
> 
>
> On Sun, Jul 2, 2017 at 9:01 PM, Rhavar  wrote:
>> That"s not really realistic. In practice some receivers do big sweeps and
>> include unconfirmed inputs. Replacing the transaction means you need to
>> pay
>> the cost of the sweep, which you probably don"t want to do (can be in the
>> order of $100s of dollars).
>
> Perhaps I am not following what you"re saying here.
>
> If the receiver is paying a higher feerate than your replacement,
> he"ll get it confirmed as fast or faster than your replacement in any
> case.
>
>
>
> ___
> 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] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 2:35 PM, Jared Lee Richardson
<jared...@gmail.com> wrote:
>> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.
>
> What you're describing is effectively the same as BU.

BU by default uses an "Accept Depth" parameter which effectively lets
miners decide block size rules and allows for resource requirements
that are too high for many users to validate. The block size settings
there are effectively placebo controls.

>
> Nodes follow chains, they do not decide the victor.  The average user
> follows the default of the software, which is to follow the longest valid
> chain.  Forcing the average user to decide which software to run is far more
> valuable than allowing "the software" to decide things, when in fact all it
> will do is decide the previous default.

That's largely true that they typically don't decide the victor in
soft forks unless they are the ones to activate the rules
changes(satoshi did this a few times in the early days), however they
make it very difficult for a hard fork to be activated without
consent. Yes, I'm not advocating for having runtime consensus settings
for nodes either, I'm advocating that resource requirements be low
enough that full validation remains possible for a large percentage of
the economy.

>
>> One would not want to
>> use this method to try and activate a controversial hard fork since
>> it's trivial for miners to false signal. The orphaning period
>> effectively forces miners to make a decision but does not necessarily
>> force them to make a particular decision
>
> This is true and a good point.  A false signal from miners could trick the
> honest miners into forking off prematurely with a minority.

More likely the false signal would be used during the orphaning period
to prevent blocks from being orphaned for miners that don't want to
follow the fork.

>
>>  it only lets
>> you see the nversion of the current stratum job since you don't get a
>> full bock header. There's always a risk here that miners build on top
>> of invalid blocks when SPV mining.
>
> This is the job of the stratum server and the pool operator.  These are
> distinct responsibilities; Miners should choose a pool operator in line with
> their desires.  Solo mining is basically dead, as it will never again be
> practical(and has not been for at least 2 years) for the same hardware that
> does the mining to also do full node operation.
>
> If the pool operator/stratum server also does not do validation, then any
> number of problems could occur.

Yes, there is a good amount of risk with validationless mining right
now here since it's well known that over half of mining pools use
validationless mining to some degree. This may not be too bad though
due to fallbacks but the risk is probably fairly implementation
specific.

>
>
>
>
> On Mon, Jun 12, 2017 at 10:44 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > The BIP is described using Chinese and English. If any part is missing
>> > or need more specific, please reply. Forgive for my poor English.
>> >
>> > This method will incorporate any upgrade that affects non-mining nodes.
>> > They should beware that the rule has been changed.
>> >
>> > TLDR: Major miners activate and orphan the minor. That ensures all
>> > miners upgrades. Then invalid the tx from not upgrading nodes. Nodes must
>> > upgrade (with other protocol upgrade codes) in order to work. Then the 
>> > final
>> > miner vote over protocol upgrade, with all nodes has the same upgraded
>> > codes.
>> >
>> > 
>> > BIP: ???
>> > Title: Demonstration of Phase in Full Network Upgrade Activated by
>> > Miners
>> > Author: LIN Zheming
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2017-06-12
>> > 
>> >
>> > ==Summary==
>> >
>> > 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
>> > This idea was not created by an individual but is a product of
>> > collaboration in the Chinese bitcoin community between different interest
>> > groups.
>> >
>> > 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
>> > This method is put forth to incentivize and to protect mining nodes and
>> > non-mining nodes during protocol upgrading. With this incentive mechanism,
>> > the non-mining nodes will not suffer monetary loss from cha

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 3:24 AM, Zheming Lin via bitcoin-dev
 wrote:
> Hi all the developers:
>
> I must clarify that despite the general ideas comes from discussions with 
> others. The opinion in replies are only limited to my self.
>
> The old TXs can be re-enable after the fourth stage and just like **nothing 
> happened** with the grace periods. The code can be provided with the protocol 
> upgrade voting. At the end of the vote, either success or failed, we can have 
> old TXs work again. It’s like after a long time that the block jammed. I 
> think nobody get harmed (Is there? I’m not so sure about that), that’s the 
> purpose.

I think that would cause problems with systems like lightning network
that rely on reliable confirmations of transactions as part of their
security models.

>
> Thank you for your time and kindly replies. Your opinions are more than 
> welcome.
>
> LIN Zheming
>
>> 在 2017年6月13日，10:23，Zheming Lin  写道：
>>
>> The BIP is described using Chinese and English. If any part is missing or 
>> need more specific, please reply. Forgive for my poor English.
>>
>> This method will incorporate any upgrade that affects non-mining nodes. They 
>> should beware that the rule has been changed.
>>
>> TLDR: Major miners activate and orphan the minor. That ensures all miners 
>> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade 
>> (with other protocol upgrade codes) in order to work. Then the final miner 
>> vote over protocol upgrade, with all nodes has the same upgraded codes.
>>
>> 
>> BIP: ???
>> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
>> Author: LIN Zheming
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-06-12
>> 
>>
>> ==Summary==
>>
>> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
>> This idea was not created by an individual but is a product of collaboration 
>> in the Chinese bitcoin community between different interest groups.
>>
>> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
>> This method is put forth to incentivize and to protect mining nodes and 
>> non-mining nodes during protocol upgrading. With this incentive mechanism, 
>> the non-mining nodes will not suffer monetary loss from chain splitting.
>>
>> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
>>
>> After the activation condition is met, majority miners will set a new block 
>> versionbits after the first grace period(a difficulty change of 2016 
>> blocks). The blocks with lower versionbits will be orphaned. In terms of the 
>> Nakamoto Consensus, the end of the first grace period will force all mining 
>> nodes upgraded to signal a new version of consensus. After the second grace 
>> period ( a difficulty change of 2016 blocks), mining nodes will only accept 
>> transactions with new versionbits. Transactions from nodes not upgrading 
>> will not be relayed nor included in blocks with new versionbits. This will 
>> protect funds of non-mining nodes from utilizing replay attack and will 
>> function as a notification for them to upgrade. Codes dealing with protocol 
>> upgrade could be included in the upgrade. After the non-mining node 
>> upgrades, mining nodes will vote to activate the protocol upgrade and this 
>> will achieve the broad/widespread deployment of the protocol upgrade.
>>
>> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。
>> The protocol upgrade depends on its activate condition independently even 
>> after the change deployed among nodes.
>>
>> ==Motivation==
>>
>> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
>> In view of the fact that the original Bitcoin consensus did not consider the 
>> non-mining wallet nodes(as mentioned above), the result is that upgrading 
>> the consensus of these wallet nodes is passive and lazy. When there is 
>> disagreement in the direction of the upgrade, the miners have no mechanism 
>> to ensure that the chain being extended is the chain widely accepted by the 
>> wallet nodes. This also adversely affects the security of the wallet 
>> nodes.
>>
>> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>>
>> Apart from ensuring the asset security of wallet nodes, this method can be 
>> used to provide additional incentives to upgrade the protocol for the wallet 
>> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can 
>> be guaranteed to work - not only on the longest chain, but also on the 
>> longest chain used by other wallet nodes in the broader bitcoin sphere. 
>> Under the Nakamoto Consensus, there will be no persistent forks as protocol 
>> upgrades can be phased in.
>>
>> ==Specification==
>>
>> 1. 

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 3:13 AM, Zheming Lin  wrote:
> Hi James:
>
> 在 2017年6月13日，15:19，James Hilliard  写道：
>
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin  wrote:
>
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard  写道：
>
>
> 1. The activation only requires majority miners signal. As described in the
> paper by Satoshi Nakamoto, 55% miners will be in the longest chain after 340
> blocks, with 99.9% certainty. This will minimize the possibility of delaying
> network upgrades by controlling a small number of hashing power. We can
> foresee that after 51% signalling, all miners will upgrade within the first
> grace period. 
>
> Technically soft forks can be implemented at 55% hashpower already
> without an orphaning period(like BIP16). Those that don't upgrade
> would just be at risk of mining invalid blocks. One would not want to
> use this method to try and activate a controversial hard fork since
> it's trivial for miners to false signal. The orphaning period
> effectively forces miners to make a decision but does not necessarily
> force them to make a particular decision since they can simply choose
> to reject the fork and false signal.
>
>
> 假信号的问题在我看来无法解决。但如果多数不同意这个改变，为什么他们还要欺骗？如果多数如中本聪共识中描述的那样是诚实可信的，那就不会有任何问题。通过算力总能分出胜负。
> False signal can’t be solved in my opinion. If the majority part just don’t
> agree with the change, why they cheat? If the majority part is honest as
> described in nakamoto consensus, I think that won’t be a problem. CPU power
> always decides.
>
>
> Nakamoto consensus is used to determine the longest chain among
> multiple valid chains, it's not enough to determine validity by
> itself. For example in a hard fork if a minority of hashpower decided
> not to fork then they would simply consider the forked chain invalid
> and ignore it, even if that majority chain had significantly more
> work.
>
>
> 节点需要自主决定是否跟随协议升级。但是他们不能被动的什么都不做。他们总是存在有多种的选择。
> The node should decide to follow the protocol upgrade or not. But they can’t
> just be passive and do nothing. The choice is always provided.
>
> 如果他们并不相信大多数的矿工，他们可以选择一些没有矿工角色的替代币。
> If they don’t trust the choice of majority miners, they can use some alt
> coin that don’t including miners’ part.

They generally don't have to switch to an altcoin when they get to
choose which blocks they accept ultimately. This is a key component of
Bitcoin's incentive model since it makes it so miners are unlikely to
do a hard fork if their blocks would not be accepted by nodes/users.
For example if 55% of miners wanted to hard fork and change the block
reward back to 50 BTC the minority side would not need to switch to an
altcoin, they would just need to ignore those 50 BTC block reward
blocks.

>
>
>
> 2. During the first two grace periods, non-mining nodes will not be
> affected. They have enough time to upgrade their software. 
> 3. Versionbits included in block header, not influencing the SPY mining.
> 
>
> The widely deployed stratum based SPV mining does not really provide a
> proper way to validate nversion of the previous block, it only lets
> you see the nversion of the current stratum job since you don't get a
> full bock header. There's always a risk here that miners build on top
> of invalid blocks when SPV mining.
>
>
> 也许我是错的我并不肯定。请对如何让这个方法兼容 SPY 挖矿提出建设性意见。
> Maybe I’m wrong. Please give some advice that how to make it compatible with
> SPY mining.
>
>
> It's just problematic in general and I'm not sure there's a good way
> around it other than putting as many safety nets as possible in place
> to limit the amount of time miners mine on invalid work. For example
> when an invalid BU blocks was mined on the network more than 50% of
> hashpower mined on top of it for a short period of time.
>
>
> 我们应当引入区块校验，但如何为不验证进行 SPY 挖矿的矿工提供激励是另外一个问题了。
> We should introduce block validation in the code, but how to provide
> incentive to no-validating SPY miner is another problem.
>
>
>
> 4. After two grace periods, all nodes must be upgraded. Otherwise they
> cannot send transactions or get any confirmations. Compared with forming new
> consensus among nodes, the situation is not worse than before. 
>
> Previous consensus changes have largely been done in backwards
> compatible ways which lets users opt-in to new features. In general
> backwards compatibility is considered a good thing, this seems to make
> that worse.
>
>
> 这并没有强制我们的节点作出任何改变共识的表示。仅仅让这些节点为接下来可能的改变做好准备。
> It would not force our nodes to do anything that changes the consensus. But
> they should be prepared for the **maybe** upcoming changes.
> 协议的改变将通过矿工投票产生，但是这个过程应该被所有节点所知晓并承认。
> Protocol upgrades could be done using miners vote. but the progress of
> voting should be acknowledged by all nodes.
>
>
> I'm not seeing how it could be considered backwards compatible if
> "they 

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin  wrote:
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard  写道：
>
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
>  wrote:
>
> The BIP is described using Chinese and English. If any part is missing or
> need more specific, please reply. Forgive for my poor English.
>
> This method will incorporate any upgrade that affects non-mining nodes. They
> should beware that the rule has been changed.
>
> TLDR: Major miners activate and orphan the minor. That ensures all miners
> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade
> (with other protocol upgrade codes) in order to work. Then the final miner
> vote over protocol upgrade, with all nodes has the same upgraded codes.
>
> ==Motivation==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
> In view of the fact that the original Bitcoin consensus did not consider the
> non-mining wallet nodes(as mentioned above), the result is that upgrading
> the consensus of these wallet nodes is passive and lazy. When there is
> disagreement in the direction of the upgrade, the miners have no mechanism
> to ensure that the chain being extended is the chain widely accepted by the
> wallet nodes. This also adversely affects the security of the wallet
> nodes.
>
> Wallet nodes being able to fully validate and choose whether or not to
> accept a particular chain is an important part of bitcoins security
> model.
>
>
> 是的我认为这些节点非常重要，因此不愿意看到这些节点因为无法预见到网络上可能发生的改变而蒙受损失。这些节点依然拥有选择的权利，比如通过类似于 BIP148
> 的方法。
>
> I admitted that these nodes a very important. so we don’t want these nodes
> suffer financial loss by undetectable network change. These nodes always
> have choice like BIP148.
>
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>
> Apart from ensuring the asset security of wallet nodes, this method can be
> used to provide additional incentives to upgrade the protocol for the wallet
> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can
> be guaranteed to work - not only on the longest chain, but also on the
> longest chain used by other wallet nodes in the broader bitcoin sphere.
> Under the Nakamoto Consensus, there will be no persistent forks as protocol
> upgrades can be phased in.
>
> There is no way to guarantee a wallet node will accept a particular
> block since that is always up to the user.
>
>
> 我们无法对此进行保证。但是我们能够提供一种让这些节点了解并参与部署改变的激励。
> We can not have any guarantee. but we can have incentives that they
> participate and be aware about the change happening.
> 用户总是可以进行选择。
> Users always have choice.
>
>
> ==Specification==
>
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active,
> all blocks must set the chosen nVersion.
> 2. Mining nodes will use tx version to define current version transactions.
> Current tx version is 1, and tx version 2 will be allowed. After the second
> grace period, tx version 1 will be regarded as invalid.
>
> Sounds like this would cause issues with pre-signed time locked
> transactions.
>
>
> 我们可以在第四阶段中重新允许这些交易。无论升级是否成功激活，他们都需要为此做好准备。他们并不能被丢下甚至被欺骗为什么都没有发生。
> They can be re-enable in the successful or unsuccessful activation of the
> fourth stage. Whether or not, what they need is to be prepared for the
> future coming. But they can’t be left behind or be cheated like nothing
> happened.
>
>
>
> ==Deployment==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。
>
> Protocol upgrading will phase in over three stages. We can have an optional
> fourth stage to integrate codes of protocol upgrade.
>
> 1. 信号阶段。挖矿节点使用 versionbits 发送支持信号。挖矿节点在监测到 55% 的区块即前 1109/2016
> 个区块均发送了相同的支持信号，进入下一阶段。
> 2. 矿工节点升级。经过了第一个宽限期 2016 的区块后，且总信号区块超过了
> 2218/4032，就开始使用新的区块版本打包区块，并同时开始孤立旧版本。此时所有节点和钱包，将可以使用新版本号发送交易，同时兼容旧版本号交易。
> 3. 钱包节点升级。在挖矿节点监测到第二个宽限期 4032
> 个连续的新版本的区块后，开始拒绝旧版本号的交易，只打包／转播新版本号的交易。同时将从内存池中删除旧版本号的交易。
> 4.
> （可选的）协议升级。在第三阶段中包含有第四阶段的升级代码。当我们确保钱包节点升级到支持新版本交易后，必然包含了第四阶段的升级代码。则此时可以通过矿工节点投票的方式完成全网络的协议升级。
>
> 1. Signal stage: Mining nodes signal using BIP9. The next stage will be
> activated after 55% (1109) of 2016 blocks has the signal.
>
> 2. Mining nodes upgrade stage: After a first grace period of 2016 blocks and
> total signalling blocks passed 2218 of 4032 blocks, miners broadcasting
> blocks with new versionbits in block headers will orphan blocks with old
> versionbits. At this stage all nodes can send transactions with new
> versionbits, and transactions with old versionbits will be compatible.
>
> 

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

[James Hilliard via bitcoin-dev]

On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
 wrote:
> The BIP is described using Chinese and English. If any part is missing or 
> need more specific, please reply. Forgive for my poor English.
>
> This method will incorporate any upgrade that affects non-mining nodes. They 
> should beware that the rule has been changed.
>
> TLDR: Major miners activate and orphan the minor. That ensures all miners 
> upgrades. Then invalid the tx from not upgrading nodes. Nodes must upgrade 
> (with other protocol upgrade codes) in order to work. Then the final miner 
> vote over protocol upgrade, with all nodes has the same upgraded codes.
>
> 
> BIP: ???
> Title: Demonstration of Phase in Full Network Upgrade Activated by Miners
> Author: LIN Zheming
> Status: Draft
> Type: Standards Track
> Created: 2017-06-12
> 
>
> ==Summary==
>
> 本方法并不是来源于个人，而是中文比特币社区中集体智慧的结果。
> This idea was not created by an individual but is a product of collaboration 
> in the Chinese bitcoin community between different interest groups.
>
> 这是一种在协议升级时，对全网挖矿和非挖矿节点进行保护和激励的方法，避免不参与挖矿的节点没有升级的动力而受到损失。
> This method is put forth to incentivize and to protect mining nodes and 
> non-mining nodes during protocol upgrading. With this incentive mechanism, 
> the non-mining nodes will not suffer monetary loss from chain splitting.
>
> 发信号的多数矿工在达到激活条件后第一个宽限期（一个难度周期）后设置新区块版本号，孤立未升级矿工的低版本号的块。通过最初的中本聪共识，在第一个宽限期结束后，所有矿工将升级至最新版本或使用最新版本。在第二个宽限期（一个难度周期）后，矿工将仅接受新版本的交易，未升级的客户端发送的旧版本交易将无法得到新节点的转播也无法进入新版本区块。这将在保护用户资产的同时，提醒不挖矿的钱包节点升级。并在升级代码中加入对协议进行改动的部分。钱包升级后将由挖矿节点投票实施该项改动，以达成协议改动的广泛部署。
>
> After the activation condition is met, majority miners will set a new block 
> versionbits after the first grace period(a difficulty change of 2016 blocks). 
> The blocks with lower versionbits will be orphaned. In terms of the Nakamoto 
> Consensus, the end of the first grace period will force all mining nodes 
> upgraded to signal a new version of consensus. After the second grace period 
> ( a difficulty change of 2016 blocks), mining nodes will only accept 
> transactions with new versionbits. Transactions from nodes not upgrading will 
> not be relayed nor included in blocks with new versionbits. This will protect 
> funds of non-mining nodes from utilizing replay attack and will function as a 
> notification for them to upgrade. Codes dealing with protocol upgrade could 
> be included in the upgrade. After the non-mining node upgrades, mining nodes 
> will vote to activate the protocol upgrade and this will achieve the 
> broad/widespread deployment of the protocol upgrade.
>
> 在该项改动广泛部署至客户端之后，依然由其激活条件控制。
> The protocol upgrade depends on its activate condition independently even 
> after the change deployed among nodes.
>
> ==Motivation==
>
> 鉴于最初的比特币协议并未考虑不参与挖矿的钱包节点，导致这些钱包节点的协议升级是被动的，懒惰的。当在升级方向上出现分歧时，矿工也不愿意在错误的链上挖矿，但矿工又没有任何方法可以确保正在延长的链是被钱包节点广泛接受的链。这将影响钱包节点的安全。
> In view of the fact that the original Bitcoin consensus did not consider the 
> non-mining wallet nodes(as mentioned above), the result is that upgrading the 
> consensus of these wallet nodes is passive and lazy. When there is 
> disagreement in the direction of the upgrade, the miners have no mechanism to 
> ensure that the chain being extended is the chain widely accepted by the 
> wallet nodes. This also adversely affects the security of the wallet 
> nodes.
Wallet nodes being able to fully validate and choose whether or not to
accept a particular chain is an important part of bitcoins security
model.
>
> 使用该方法可以在保证钱包节点资产安全的情况下，且通过增加激励让钱包节点升级协议。一旦钱包节点升级协议，保证矿工节点不仅工作在算力最长链上，还工作在比特币生态环境中其他钱包节点所使用的最长链上。在中本聪共识下不会出现分叉，以实现渐进式的协议升级。
>
> Apart from ensuring the asset security of wallet nodes, this method can be 
> used to provide additional incentives to upgrade the protocol for the wallet 
> nodes. Once the wallet nodes upgrade their protocol, the miners' nodes can be 
> guaranteed to work - not only on the longest chain, but also on the longest 
> chain used by other wallet nodes in the broader bitcoin sphere. Under the 
> Nakamoto Consensus, there will be no persistent forks as protocol upgrades 
> can be phased in.
There is no way to guarantee a wallet node will accept a particular
block since that is always up to the user.
>
> ==Specification==
>
> 1. 挖矿节点将使用 versionbits 版本位来定义支持信号。BIP 生效时，所有区块需要使用制定的 nVersion 来发送信号
> 2. 挖矿节点将使用 tx version 来定义当前的交易版本。当前的 tx version 是 1，将允许 tx version 为 2 
> 的交易，并在第二个宽限期之后，使 tx version 为 1 的交易非法。
>
> 1. Mining nodes signal by setting a version bit. While this BIP is active, 
> all blocks must set the chosen nVersion.
> 2. Mining nodes will use tx version to define current version transactions. 
> Current tx version is 1, and tx version 2 will be allowed. After the second 
> grace period, tx version 1 will be regarded as invalid.
Sounds like this would cause issues with pre-signed time locked transactions.
>
>
> ==Deployment==
> 协议升级，将分成三步逐步实施。并有一个可选的第四步来集成协议升级代码。
>
> Protocol upgrading will phase in over three stages. We can 

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

gt;> >> >> > cannot
>> >> >> >> > take place in time, it would be preferable for miners to have a
>> >> >> >> > more
>> >> >> >> > standard approach to activation that requires stronger
>> >> >> >> > consensus
>> >> >> >> > and
>> >> >> >> > may be more forgiving than BIP148.  If the segwit2x activation
>> >> >> >> > is
>> >> >> >> > on
>> >> >> >> > time to cooperate with BIP148, it could be signaled through the
>> >> >> >> > non-bit4 approach and everything could go smoothly.  Thoughts
>> >> >> >> > on
>> >> >> >> > that
>> >> >> >> > idea?  It may add more complexity and more developer time, but
>> >> >> >> > may
>> >> >> >> > also address your concerns among others.
>> >> >> >> This does give miners another approach to activate segwit ahead
>> >> >> >> of
>> >> >> >> BIP148, if segwit2x activation is rolled out and activated
>> >> >> >> immediately
>> >> >> >> then this would not be needed however based on the timeline here
>> >> >> >> https://segwit2x.github.io/ it would not be possible for BIP91 to
>> >> >> >> enforce mandatory signalling ahead of BIP148. Maybe that can be
>> >> >> >> changed though, I've suggested an immediate rollout with a
>> >> >> >> placeholder
>> >> >> >> client timeout instead of the HF code initially in order to
>> >> >> >> accelerate
>> >> >> >> that.
>> >> >> >> >
>> >> >> >> >> Since this BIP
>> >> >> >> >> only activates with a clear miner majority it should not
>> >> >> >> >> increase
>> >> >> >> >> the
>> >> >> >> >> risk of an extended chain split.
>> >> >> >> >
>> >> >> >> > The concern I'm raising is more about the psychology of giving
>> >> >> >> > BIP148
>> >> >> >> > a sense of safety that may not be valid.  Without several more
>> >> >> >> > steps,
>> >> >> >> > BIP148 is definitely on track to be a risky chainsplit, and
>> >> >> >> > without
>> >> >> >> > segwit2x it will almost certainly be a small minority chain.
>> >> >> >> > (Unless
>> >> >> >> > the segwit2x compromise falls apart before then, and even in
>> >> >> >> > that
>> >> >> >> > case
>> >> >> >> > it is likely to be a minority chain)
>> >> >> >> There are 2 primary factors involved here, economic support and
>> >> >> >> hashpower either of which is enough to make a permanent chain
>> >> >> >> split
>> >> >> >> unlikely, miners will mine whichever chain is most profitable(see
>> >> >> >> ETH/ETC hashpower profitability equilibrium for an example of how
>> >> >> >> this
>> >> >> >> works in practice) however there may be lag time immediately
>> >> >> >> after
>> >> >> >> the
>> >> >> >> split if there is an economic majority but not a hashpower
>> >> >> >> majority
>> >> >> >> initially. This is risk mitigation that only requires miners
>> >> >> >> support
>> >> >> >> however. The main issue is just one of activation timelines,
>> >> >> >> BIP91
>> >> >> >> as
>> >> >> >> is takes too long to activate unless started ahead of the
>> >> >> >> existing
>> >> >> >> segwit2x schedule and it's unlikely that BIP148 will get pushed
>> >> >> >> back
>> >> >> >> any further.
>> >> >> >> >
>> >> >> >> > Jared
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Wed, Jun 7, 2017 at 2:42 P

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

it, and
>> >> >> > without
>> >> >> > segwit2x it will almost certainly be a small minority chain.
>> >> >> > (Unless
>> >> >> > the segwit2x compromise falls apart before then, and even in that
>> >> >> > case
>> >> >> > it is likely to be a minority chain)
>> >> >> There are 2 primary factors involved here, economic support and
>> >> >> hashpower either of which is enough to make a permanent chain split
>> >> >> unlikely, miners will mine whichever chain is most profitable(see
>> >> >> ETH/ETC hashpower profitability equilibrium for an example of how
>> >> >> this
>> >> >> works in practice) however there may be lag time immediately after
>> >> >> the
>> >> >> split if there is an economic majority but not a hashpower majority
>> >> >> initially. This is risk mitigation that only requires miners support
>> >> >> however. The main issue is just one of activation timelines, BIP91
>> >> >> as
>> >> >> is takes too long to activate unless started ahead of the existing
>> >> >> segwit2x schedule and it's unlikely that BIP148 will get pushed back
>> >> >> any further.
>> >> >> >
>> >> >> > Jared
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Jun 7, 2017 at 2:42 PM, James Hilliard
>> >> >> > <james.hillia...@gmail.com> wrote:
>> >> >> >> I don't really see how this would increase the likelihood of an
>> >> >> >> extended chain split assuming BIP148 is going to have
>> >> >> >> non-insignificant economic backing. This BIP is designed to
>> >> >> >> provide
>> >> >> >> a
>> >> >> >> risk mitigation measure that miners can safely deploy. Since this
>> >> >> >> BIP
>> >> >> >> only activates with a clear miner majority it should not increase
>> >> >> >> the
>> >> >> >> risk of an extended chain split. At this point it is not
>> >> >> >> completely
>> >> >> >> clear how much economic support there is for BIP148 but support
>> >> >> >> certainly seems to be growing and we have nearly 2 months until
>> >> >> >> BIP148
>> >> >> >> activation. I intentionally used a shorter activation period here
>> >> >> >> so
>> >> >> >> that decisions by miners can be made close to the BIP148
>> >> >> >> activation
>> >> >> >> date.
>> >> >> >>
>> >> >> >> On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson
>> >> >> >> <jared...@gmail.com> wrote:
>> >> >> >>> I think this BIP represents a gamble, and the gamble may not be
>> >> >> >>> a
>> >> >> >>> good
>> >> >> >>> one.  The gamble here is that if the segwit2x changes are rolled
>> >> >> >>> out
>> >> >> >>> on time, and if the signatories accept the bit4 + bit1 signaling
>> >> >> >>> proposals within BIP91, the launch will go smoother, as
>> >> >> >>> intended.
>> >> >> >>> But
>> >> >> >>> conversely, if either the segwit2x signatories balk about the
>> >> >> >>> Bit1
>> >> >> >>> signaling OR if the timelines for segwit2mb are missed even by a
>> >> >> >>> bit,
>> >> >> >>> it may cause the BIP148 chainsplit to be worse than it would be
>> >> >> >>> without.  Given the frequent concerns raised in multiple places
>> >> >> >>> about
>> >> >> >>> the aggressiveness of the segwit2x timelines, including the
>> >> >> >>> non-hardfork timelines, this does not seem like a great gamble
>> >> >> >>> to
>> >> >> >>> be
>> >> >> >>> making.
>> >> >> >>>
>> >> >> >>> The reason I say it may make the chainsplit be worse than it
>> >> >> >

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

; activation. I intentionally used a shorter activation period here so
>> >> >> that decisions by miners can be made close to the BIP148 activation
>> >> >> date.
>> >> >>
>> >> >> On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson
>> >> >> <jared...@gmail.com> wrote:
>> >> >>> I think this BIP represents a gamble, and the gamble may not be a
>> >> >>> good
>> >> >>> one.  The gamble here is that if the segwit2x changes are rolled
>> >> >>> out
>> >> >>> on time, and if the signatories accept the bit4 + bit1 signaling
>> >> >>> proposals within BIP91, the launch will go smoother, as intended.
>> >> >>> But
>> >> >>> conversely, if either the segwit2x signatories balk about the Bit1
>> >> >>> signaling OR if the timelines for segwit2mb are missed even by a
>> >> >>> bit,
>> >> >>> it may cause the BIP148 chainsplit to be worse than it would be
>> >> >>> without.  Given the frequent concerns raised in multiple places
>> >> >>> about
>> >> >>> the aggressiveness of the segwit2x timelines, including the
>> >> >>> non-hardfork timelines, this does not seem like a great gamble to
>> >> >>> be
>> >> >>> making.
>> >> >>>
>> >> >>> The reason I say it may make the chainsplit be worse than it would
>> >> >>> otherwise be is that it may provide a false sense of safety for
>> >> >>> BIP148
>> >> >>> that currently does not currently exist(and should not, as it is a
>> >> >>> chainsplit).  That sense of safety would only be legitimate if the
>> >> >>> segwit2x signatories were on board, and the segwit2x code
>> >> >>> effectively
>> >> >>> enforced BIP148 simultaneously, neither of which are guaranteed.
>> >> >>> If
>> >> >>> users and more miners had a false sense that BIP148 was *not* going
>> >> >>> to
>> >> >>> chainsplit from default / segwit2x, they might not follow the news
>> >> >>> if
>> >> >>> suddenly the segwit2x plan were delayed for a few days.  While any
>> >> >>> additional support would definitely be cheered on by BIP148
>> >> >>> supporters, the practical reality might be that this proposal would
>> >> >>> take BIP148 from the "unlikely to have any viable chain after flag
>> >> >>> day
>> >> >>> without segwit2x" category into the "small but viable minority
>> >> >>> chain"
>> >> >>> category, and even worse, it might strengthen the chainsplit just
>> >> >>> days
>> >> >>> before segwit is activated on BOTH chains, putting the BIP148
>> >> >>> supporters on the wrong pro-segwit, but still-viable chain.
>> >> >>>
>> >> >>> If Core had taken a strong stance to include BIP148 into the
>> >> >>> client,
>> >> >>> and if BIP148 support were much much broader, I would feel
>> >> >>> differently
>> >> >>> as the gamble would be more likely to discourage a chainsplit (By
>> >> >>> forcing the acceleration of segwit2x) rather than encourage it (by
>> >> >>> strengthening an extreme minority chainsplit that may wind up on
>> >> >>> the
>> >> >>> wrong side of two segwit-activated chains).  As it stands now, this
>> >> >>> seems like a very dangerous attempt to compromise with a small but
>> >> >>> vocal group that are the ones creating the threat to begin with.
>> >> >>>
>> >> >>> Jared
>> >> >>>
>> >> >>> On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev
>> >> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> >>>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> >> >>>> SegWit2x agreement being too slow to activate SegWit mandatory
>> >> >>>> signalling ahead of BIP148 using BIP91 I would like to propose
>> >> >>>> another
>>

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

at currently does not currently exist(and should not, as it is a
>> >>> chainsplit).  That sense of safety would only be legitimate if the
>> >>> segwit2x signatories were on board, and the segwit2x code effectively
>> >>> enforced BIP148 simultaneously, neither of which are guaranteed.  If
>> >>> users and more miners had a false sense that BIP148 was *not* going to
>> >>> chainsplit from default / segwit2x, they might not follow the news if
>> >>> suddenly the segwit2x plan were delayed for a few days.  While any
>> >>> additional support would definitely be cheered on by BIP148
>> >>> supporters, the practical reality might be that this proposal would
>> >>> take BIP148 from the "unlikely to have any viable chain after flag day
>> >>> without segwit2x" category into the "small but viable minority chain"
>> >>> category, and even worse, it might strengthen the chainsplit just days
>> >>> before segwit is activated on BOTH chains, putting the BIP148
>> >>> supporters on the wrong pro-segwit, but still-viable chain.
>> >>>
>> >>> If Core had taken a strong stance to include BIP148 into the client,
>> >>> and if BIP148 support were much much broader, I would feel differently
>> >>> as the gamble would be more likely to discourage a chainsplit (By
>> >>> forcing the acceleration of segwit2x) rather than encourage it (by
>> >>> strengthening an extreme minority chainsplit that may wind up on the
>> >>> wrong side of two segwit-activated chains).  As it stands now, this
>> >>> seems like a very dangerous attempt to compromise with a small but
>> >>> vocal group that are the ones creating the threat to begin with.
>> >>>
>> >>> Jared
>> >>>
>> >>> On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev
>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> >>>> SegWit2x agreement being too slow to activate SegWit mandatory
>> >>>> signalling ahead of BIP148 using BIP91 I would like to propose
>> >>>> another
>> >>>> option that miners can use to prevent a chain split ahead of the Aug
>> >>>> 1st BIP148 activation date.
>> >>>>
>> >>>> The splitprotection soft fork is essentially BIP91 but using BIP8
>> >>>> instead of BIP9 with a lower activation threshold and immediate
>> >>>> mandatory signalling lock-in. This allows for a majority of miners to
>> >>>> activate mandatory SegWit signalling and prevent a potential chain
>> >>>> split ahead of BIP148 activation.
>> >>>>
>> >>>> This BIP allows for miners to respond to market forces quickly ahead
>> >>>> of BIP148 activation by signalling for splitprotection. Any miners
>> >>>> already running BIP148 should be encouraged to use splitprotection.
>> >>>>
>> >>>> 
>> >>>>   BIP: splitprotection
>> >>>>   Layer: Consensus (soft fork)
>> >>>>   Title: User Activated Soft Fork Split Protection
>> >>>>   Author: James Hilliard <james.hillia...@gmail.com>
>> >>>>   Comments-Summary: No comments yet.
>> >>>>   Comments-URI:
>> >>>>   Status: Draft
>> >>>>   Type: Standards Track
>> >>>>   Created: 2017-05-22
>> >>>>   License: BSD-3-Clause
>> >>>>CC0-1.0
>> >>>> 
>> >>>>
>> >>>> ==Abstract==
>> >>>>
>> >>>> This document specifies a coordination mechanism for a simple
>> >>>> majority
>> >>>> of miners to prevent a chain split ahead of BIP148 activation.
>> >>>>
>> >>>> ==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==
>> >>>>
>> >>>> The biggest risk of BIP148 is an extended chain split, this BIP
>> >>>&

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

Yes, this is the same as BIP148, there is no mandatory signalling
after segwit is locked in.

On Wed, Jun 7, 2017 at 4:43 PM, Jared Lee Richardson <jared...@gmail.com> wrote:
>> Keep in mind that this is only temporary until segwit has locked in,
> after that happens it becomes optional for miners again.
>
> I missed that, that does effectively address that concern.  It appears
> that BIP148 implements the same rule as would be required to prevent a
> later chainsplit as well, no?
>
> This comment did bring to mind another concern about BIP148/91 though,
> which I'll raise in the pull request discussion.  Feel free to respond
> to it there.
>
> Jared
>
> On Wed, Jun 7, 2017 at 2:21 PM, James Hilliard
> <james.hillia...@gmail.com> wrote:
>> Keep in mind that this is only temporary until segwit has locked in,
>> after that happens it becomes optional for miners again.
>>
>> On Wed, Jun 7, 2017 at 4:09 PM, Jared Lee Richardson <jared...@gmail.com> 
>> wrote:
>>>> This is, by far, the safest way for miners to quickly defend against a 
>>>> chain split, much better than a -bip148 option.   This allows miners to 
>>>> defend themselves, with very little risk, since the defense is only 
>>>> activated if the majority of miners do so. I would move for a very rapid 
>>>> deployment.   Only miners would need to upgrade.   Regular users would not 
>>>> have to concern themselves with this release.
>>>
>>> FYI, even if very successful, this deployment and change may have a
>>> severe negative impact on a small group of miners.  Any miners/pools
>>> who are not actively following the forums, news, or these discussions
>>> may be difficult to reach and communicate with in time, particularly
>>> with language barriers.  Of those, any who are also either not
>>> signaling segwit currently or are running an older software version
>>> will have their blocks continuously and constantly orphaned, but may
>>> not have any alarms or notifications set up for such an unexpected
>>> failure.  That may or may not be a worthy consideration, but it is
>>> definitely brusque and a harsh price to pay.  Considering the
>>> opposition mentioned against transaction limits for the rare cases
>>> where a very large transaction has already been signed, it seems that
>>> this would be worthy of consideration.  For the few miners in that
>>> situation, it does turn segwit from an optional softfork into a
>>> punishing hardfork.
>>>
>>> I don't think that's a sufficient reason alone to kill the idea, but
>>> it should be a concern.
>>>
>>> Jared
>>>
>>> On Wed, Jun 7, 2017 at 7:10 AM, Erik Aronesty via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> This is, by far, the safest way for miners to quickly defend against a 
>>>> chain
>>>> split, much better than a -bip148 option.   This allows miners to defend
>>>> themselves, with very little risk, since the defense is only activated if
>>>> the majority of miners do so. I would move for a very rapid deployment.
>>>> Only miners would need to upgrade.   Regular users would not have to 
>>>> concern
>>>> themselves with this release.
>>>>
>>>> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>> I think even 55% would probably work out fine simply due to incentive
>>>>> structures, once signalling is over 51% it's then clear to miners that
>>>>> non-signalling blocks will be orphaned and the rest will rapidly
>>>>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
>>>>> chain split risk for BIP148 since it's looking like BIP148 is going to
>>>>> be run by a non-insignificant percentage of the economy at a minimum.
>>>>>
>>>>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <cont...@taoeffect.com> wrote:
>>>>> > See thread on replay attacks for why activating regardless of threshold
>>>>> > is a
>>>>> > bad idea [1].
>>>>> >
>>>>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
>>>>> > difficult for miners to hold together in opposition to Core. It gives
>>>>> > Core
>>>>> > more leverage in negotiations.
>>>>> >
>>>>> &g

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

I don't really see how this would increase the likelihood of an
extended chain split assuming BIP148 is going to have
non-insignificant economic backing. This BIP is designed to provide a
risk mitigation measure that miners can safely deploy. Since this BIP
only activates with a clear miner majority it should not increase the
risk of an extended chain split. At this point it is not completely
clear how much economic support there is for BIP148 but support
certainly seems to be growing and we have nearly 2 months until BIP148
activation. I intentionally used a shorter activation period here so
that decisions by miners can be made close to the BIP148 activation
date.

On Wed, Jun 7, 2017 at 4:29 PM, Jared Lee Richardson <jared...@gmail.com> wrote:
> I think this BIP represents a gamble, and the gamble may not be a good
> one.  The gamble here is that if the segwit2x changes are rolled out
> on time, and if the signatories accept the bit4 + bit1 signaling
> proposals within BIP91, the launch will go smoother, as intended.  But
> conversely, if either the segwit2x signatories balk about the Bit1
> signaling OR if the timelines for segwit2mb are missed even by a bit,
> it may cause the BIP148 chainsplit to be worse than it would be
> without.  Given the frequent concerns raised in multiple places about
> the aggressiveness of the segwit2x timelines, including the
> non-hardfork timelines, this does not seem like a great gamble to be
> making.
>
> The reason I say it may make the chainsplit be worse than it would
> otherwise be is that it may provide a false sense of safety for BIP148
> that currently does not currently exist(and should not, as it is a
> chainsplit).  That sense of safety would only be legitimate if the
> segwit2x signatories were on board, and the segwit2x code effectively
> enforced BIP148 simultaneously, neither of which are guaranteed.  If
> users and more miners had a false sense that BIP148 was *not* going to
> chainsplit from default / segwit2x, they might not follow the news if
> suddenly the segwit2x plan were delayed for a few days.  While any
> additional support would definitely be cheered on by BIP148
> supporters, the practical reality might be that this proposal would
> take BIP148 from the "unlikely to have any viable chain after flag day
> without segwit2x" category into the "small but viable minority chain"
> category, and even worse, it might strengthen the chainsplit just days
> before segwit is activated on BOTH chains, putting the BIP148
> supporters on the wrong pro-segwit, but still-viable chain.
>
> If Core had taken a strong stance to include BIP148 into the client,
> and if BIP148 support were much much broader, I would feel differently
> as the gamble would be more likely to discourage a chainsplit (By
> forcing the acceleration of segwit2x) rather than encourage it (by
> strengthening an extreme minority chainsplit that may wind up on the
> wrong side of two segwit-activated chains).  As it stands now, this
> seems like a very dangerous attempt to compromise with a small but
> vocal group that are the ones creating the threat to begin with.
>
> Jared
>
> On Tue, Jun 6, 2017 at 5:56 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> SegWit2x agreement being too slow to activate SegWit mandatory
>> signalling ahead of BIP148 using BIP91 I would like to propose another
>> option that miners can use to prevent a chain split ahead of the Aug
>> 1st BIP148 activation date.
>>
>> The splitprotection soft fork is essentially BIP91 but using BIP8
>> instead of BIP9 with a lower activation threshold and immediate
>> mandatory signalling lock-in. This allows for a majority of miners to
>> activate mandatory SegWit signalling and prevent a potential chain
>> split ahead of BIP148 activation.
>>
>> This BIP allows for miners to respond to market forces quickly ahead
>> of BIP148 activation by signalling for splitprotection. Any miners
>> already running BIP148 should be encouraged to use splitprotection.
>>
>> 
>>   BIP: splitprotection
>>   Layer: Consensus (soft fork)
>>   Title: User Activated Soft Fork Split Protection
>>   Author: James Hilliard <james.hillia...@gmail.com>
>>   Comments-Summary: No comments yet.
>>   Comments-URI:
>>   Status: Draft
>>   Type: Standards Track
>>   Created: 2017-05-22
>>   License: BSD-3-Clause
>>CC0-1.0
>> 
>>
>> ==Abstract==
>>
>> This document specifies a coordination mechanism for a simple majority
>> of miners to prevent a chain split ahead of BIP148 activation

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

Keep in mind that this is only temporary until segwit has locked in,
after that happens it becomes optional for miners again.

On Wed, Jun 7, 2017 at 4:09 PM, Jared Lee Richardson <jared...@gmail.com> wrote:
>> This is, by far, the safest way for miners to quickly defend against a chain 
>> split, much better than a -bip148 option.   This allows miners to defend 
>> themselves, with very little risk, since the defense is only activated if 
>> the majority of miners do so. I would move for a very rapid deployment.   
>> Only miners would need to upgrade.   Regular users would not have to concern 
>> themselves with this release.
>
> FYI, even if very successful, this deployment and change may have a
> severe negative impact on a small group of miners.  Any miners/pools
> who are not actively following the forums, news, or these discussions
> may be difficult to reach and communicate with in time, particularly
> with language barriers.  Of those, any who are also either not
> signaling segwit currently or are running an older software version
> will have their blocks continuously and constantly orphaned, but may
> not have any alarms or notifications set up for such an unexpected
> failure.  That may or may not be a worthy consideration, but it is
> definitely brusque and a harsh price to pay.  Considering the
> opposition mentioned against transaction limits for the rare cases
> where a very large transaction has already been signed, it seems that
> this would be worthy of consideration.  For the few miners in that
> situation, it does turn segwit from an optional softfork into a
> punishing hardfork.
>
> I don't think that's a sufficient reason alone to kill the idea, but
> it should be a concern.
>
> Jared
>
> On Wed, Jun 7, 2017 at 7:10 AM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> This is, by far, the safest way for miners to quickly defend against a chain
>> split, much better than a -bip148 option.   This allows miners to defend
>> themselves, with very little risk, since the defense is only activated if
>> the majority of miners do so. I would move for a very rapid deployment.
>> Only miners would need to upgrade.   Regular users would not have to concern
>> themselves with this release.
>>
>> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> I think even 55% would probably work out fine simply due to incentive
>>> structures, once signalling is over 51% it's then clear to miners that
>>> non-signalling blocks will be orphaned and the rest will rapidly
>>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
>>> chain split risk for BIP148 since it's looking like BIP148 is going to
>>> be run by a non-insignificant percentage of the economy at a minimum.
>>>
>>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <cont...@taoeffect.com> wrote:
>>> > See thread on replay attacks for why activating regardless of threshold
>>> > is a
>>> > bad idea [1].
>>> >
>>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
>>> > difficult for miners to hold together in opposition to Core. It gives
>>> > Core
>>> > more leverage in negotiations.
>>> >
>>> > If they don't activate with 80%, Core can release another BIP to reduce
>>> > it
>>> > to 75%.
>>> >
>>> > Each threshold reduction makes it both more likely to succeed, but also
>>> > increases the likelihood of harm to the ecosystem.
>>> >
>>> > Cheers,
>>> > Greg
>>> >
>>> > [1]
>>> >
>>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html
>>> >
>>> > --
>>> > Please do not email me anything that you are not comfortable also
>>> > sharing
>>> > with the NSA.
>>> >
>>> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hillia...@gmail.com>
>>> > wrote:
>>> >
>>> > This is a BIP8 style soft fork so mandatory signalling will be active
>>> > after Aug 1st regardless.
>>> >
>>> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <cont...@taoeffect.com>
>>> > wrote:
>>> >
>>> > What is the probability that a 65% threshold is too low and can allow a
>>> > "surprise miner attack", whereby miners are kept offline before the
>>> > deadline, a

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

I think even 55% would probably work out fine simply due to incentive
structures, once signalling is over 51% it's then clear to miners that
non-signalling blocks will be orphaned and the rest will rapidly
update to splitprotection/BIP148. The purpose of this BIP is to reduce
chain split risk for BIP148 since it's looking like BIP148 is going to
be run by a non-insignificant percentage of the economy at a minimum.

On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <cont...@taoeffect.com> wrote:
> See thread on replay attacks for why activating regardless of threshold is a
> bad idea [1].
>
> BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
> difficult for miners to hold together in opposition to Core. It gives Core
> more leverage in negotiations.
>
> If they don't activate with 80%, Core can release another BIP to reduce it
> to 75%.
>
> Each threshold reduction makes it both more likely to succeed, but also
> increases the likelihood of harm to the ecosystem.
>
> Cheers,
> Greg
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hillia...@gmail.com>
> wrote:
>
> This is a BIP8 style soft fork so mandatory signalling will be active
> after Aug 1st regardless.
>
> On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <cont...@taoeffect.com> wrote:
>
> What is the probability that a 65% threshold is too low and can allow a
> "surprise miner attack", whereby miners are kept offline before the
> deadline, and brought online immediately after, creating potential havoc?
>
> (Nit: "simple majority" usually refers to >50%, I think, might cause
> confusion.)
>
> -Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> 
> BIP: splitprotection
> Layer: Consensus (soft fork)
> Title: User Activated Soft Fork Split Protection
> Author: James Hilliard <james.hillia...@gmail.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
>  CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==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==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 tog

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

This is a BIP8 style soft fork so mandatory signalling will be active
after Aug 1st regardless.

On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <cont...@taoeffect.com> wrote:
> What is the probability that a 65% threshold is too low and can allow a
> "surprise miner attack", whereby miners are kept offline before the
> deadline, and brought online immediately after, creating potential havoc?
>
> (Nit: "simple majority" usually refers to >50%, I think, might cause
> confusion.)
>
> -Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> 
>  BIP: splitprotection
>  Layer: Consensus (soft fork)
>  Title: User Activated Soft Fork Split Protection
>  Author: James Hilliard <james.hillia...@gmail.com>
>  Comments-Summary: No comments yet.
>  Comments-URI:
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>   CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==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==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==Specification==
>
> 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.
>
> ==Deployment==
>
> This BIP will be deployed by "version bits" with a 65%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "splitprotecion" and using bit 2.
>
> This BIP starts immediately and is a BIP8 style soft fork since
> mandatory signalling will start on midnight August 1st 2017 (epoch
> time 1501545600) regardless of whether or not this BIP has reached its
> own signalling threshold. This BIP will cease to be active when segwit
> is locked-in.
>
> === Reference implementation ===
>
> 
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> THRESHOLD_LOCKED_IN &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> 

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

You need a majority of miners enforcing BIP148 upon BIP148 activation
to prevent a split, not just a majority signalling segwit. This
provides a miner coordination mechanism for BIP148 mandatory
signalling enforcement.

On Tue, Jun 6, 2017 at 8:11 PM, Karl Johan Alm
<karljohan-...@garage.co.jp> wrote:
> One thing about BIP148 activation that may be affected by this is the
> fact that segwit signalling non-BIP148 miners + BIP148 miners may hold
> majority hash power and prevent a chain split. With this SF, that will
> no longer be the case, right? Or am I completely confused on the
> subject?
>
> On Wed, Jun 7, 2017 at 9:56 AM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> SegWit2x agreement being too slow to activate SegWit mandatory
>> signalling ahead of BIP148 using BIP91 I would like to propose another
>> option that miners can use to prevent a chain split ahead of the Aug
>> 1st BIP148 activation date.
>>
>> The splitprotection soft fork is essentially BIP91 but using BIP8
>> instead of BIP9 with a lower activation threshold and immediate
>> mandatory signalling lock-in. This allows for a majority of miners to
>> activate mandatory SegWit signalling and prevent a potential chain
>> split ahead of BIP148 activation.
>>
>> This BIP allows for miners to respond to market forces quickly ahead
>> of BIP148 activation by signalling for splitprotection. Any miners
>> already running BIP148 should be encouraged to use splitprotection.
>>
>> 
>>   BIP: splitprotection
>>   Layer: Consensus (soft fork)
>>   Title: User Activated Soft Fork Split Protection
>>   Author: James Hilliard <james.hillia...@gmail.com>
>>   Comments-Summary: No comments yet.
>>   Comments-URI:
>>   Status: Draft
>>   Type: Standards Track
>>   Created: 2017-05-22
>>   License: BSD-3-Clause
>>CC0-1.0
>> 
>>
>> ==Abstract==
>>
>> This document specifies a coordination mechanism for a simple majority
>> of miners to prevent a chain split ahead of BIP148 activation.
>>
>> ==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==
>>
>> The biggest risk of BIP148 is an extended chain split, this BIP
>> provides a way for a simple majority of miners to eliminate that risk.
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower before BIP148 activation. Due to time constraints unless
>> immediately deployed BIP91 will likely not be able to enforce
>> mandatory signalling of segwit before the Aug 1st activation of
>> BIP148. This BIP provides a method for rapid miner activation of
>> SegWit mandatory signalling ahead of the BIP148 activation date. Since
>> the primary goal of this BIP is to reduce the chance of an extended
>> chain split as much as possible we activate using a simple miner
>> majority of 65% over a 504 block interval rather than a higher
>> percentage. This BIP also allows miners to signal their intention to
>> run BIP148 in order to prevent a chain split.
>>
>> ==Specification==
>>
>> 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.
>>
>> ==Deployment==
>>
>> This BIP will be deployed by "version bits" with a 65%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "splitprotecion" and using bit 2.
>>
>> This BIP starts immediately and is a BIP8 style soft fork since
>> mandatory signalling will start on midnight August 1st 2017 (epoch
>> time 1501545600) regardless of whether or not this BIP has reached its
>> own signalling threshold. This BIP will cease to be active when segwit
>> is locked-in.
>>
>> === Reference implementation ===
>>
>> 
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>> LOCK(cs_main);
>> return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> THRESHOLD_LOCK

[bitcoin-dev] User Activated Soft Fork Split Protection

[James Hilliard via bitcoin-dev]

Due to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to propose another
option that miners can use to prevent a chain split ahead of the Aug
1st BIP148 activation date.

The splitprotection soft fork is essentially BIP91 but using BIP8
instead of BIP9 with a lower activation threshold and immediate
mandatory signalling lock-in. This allows for a majority of miners to
activate mandatory SegWit signalling and prevent a potential chain
split ahead of BIP148 activation.

This BIP allows for miners to respond to market forces quickly ahead
of BIP148 activation by signalling for splitprotection. Any miners
already running BIP148 should be encouraged to use splitprotection.


  BIP: splitprotection
  Layer: Consensus (soft fork)
  Title: User Activated Soft Fork Split Protection
  Author: James Hilliard 
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Draft
  Type: Standards Track
  Created: 2017-05-22
  License: BSD-3-Clause
   CC0-1.0


==Abstract==

This document specifies a coordination mechanism for a simple majority
of miners to prevent a chain split ahead of BIP148 activation.

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

The biggest risk of BIP148 is an extended chain split, this BIP
provides a way for a simple majority of miners to eliminate that risk.

This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower before BIP148 activation. Due to time constraints unless
immediately deployed BIP91 will likely not be able to enforce
mandatory signalling of segwit before the Aug 1st activation of
BIP148. This BIP provides a method for rapid miner activation of
SegWit mandatory signalling ahead of the BIP148 activation date. Since
the primary goal of this BIP is to reduce the chance of an extended
chain split as much as possible we activate using a simple miner
majority of 65% over a 504 block interval rather than a higher
percentage. This BIP also allows miners to signal their intention to
run BIP148 in order to prevent a chain split.

==Specification==

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.

==Deployment==

This BIP will be deployed by "version bits" with a 65%(this can be
adjusted if desired) activation threshold BIP9 with the name
"splitprotecion" and using bit 2.

This BIP starts immediately and is a BIP8 style soft fork since
mandatory signalling will start on midnight August 1st 2017 (epoch
time 1501545600) regardless of whether or not this BIP has reached its
own signalling threshold. This BIP will cease to be active when segwit
is locked-in.

=== Reference implementation ===


// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}

// SPLITPROTECTION mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
THRESHOLD_LOCKED_IN &&
 !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
 !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}

// BIP148 mandatory segwit signalling.
int64_t nMedianTimePast = pindex->GetMedianTimePast();
if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
 (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
 (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
 // Segwit is not locked in
  !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
 // and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, 

Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

[James Hilliard via bitcoin-dev]

For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.

The biggest issue is that a safe HF is very unlikely to be able to be
coded and tested within 6 months.

On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
 wrote:
> This proposal is written under the assumption that the signatories to the
> Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of
> the agreement, and intend to enact the updates described therein. As such,
> criticisms pertaining to the chosen deployment timeline or hard fork upgrade
> path should be treated as out-of-scope during the initial discussion of this
> proposal.
>
> Because it includes the activation of a hard fork for which community
> consensus does not yet exist, this proposal is not likely to be merged into
> Bitcoin Core in the immediate future, and must instead be maintained and
> reviewed in a separate downstream repository. However, it is written with
> the intent to remain cleanly compatible with future network updates and
> changes, to allow for the option of a straightforward upstream merge if
> community consensus for the proposal is successfully achieved in the
> following months.
>
>
> 
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner 
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
> 
>
>
> ===Abstract===
>
> This document describes a virtuous combination of James Hilliard’s “Reduced
> signalling threshold activation of existing segwit deployment”[2], Shaolin
> Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s
> “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size
> hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s
> “Spoonnet”[6][7] into a single omnibus proposal and patchset.
>
>
> ===Motivation===
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> • Activate Segregated Witness at an 80% threshold, signaling at bit 4
> • Activate a 2 MB hard fork within six months
>
> This proposal seeks to fulfill these criteria while retaining maximum
> compatibility with existing deployment approaches, thereby minimizing the
> risks of a destructive chain split. Additionally, subsequent indications of
> implied criteria and expectations of the Agreement[8][9] are satisfied.
>
> The proposed hard fork incorporates a legacy witness discount and 2MB
> blocksize limit along with the enactment of Spoonnet-derived protectionary
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> ===Rationale===
>
> To the extent possible, this represents an effort at a best-of-all-worlds
> proposal, intended to provide a common foundation from which all
> mutually-inclusive goals can be achieved while risks are minimized.
>
> The individual constituent proposals include the following respective
> rationales:
>
> James Hilliard’s “Reduced signalling threshold activation of existing segwit
> deployment”[2] explains:
>
>> The goal here is to minimize chain split risk and network disruption while
>> maximizing backwards compatibility and still providing for rapid activation
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
>
>> cause the existing "segwit" deployment to activate without needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (“fast-activation” and
> “flag-day activation”) serve to prevent unnecessary delays in the network
> upgrade process, addressing a common criticism of the Scaling Agreement and
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind
> linking SegWit’s activation with that of a later hard fork block size
> increase:
>
>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
>> size hard-fork activated ONLY if segwit activates (95% of miners signaling
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
>
> Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are
> included to reduce the marginal risks that such an increase in the block
> size might introduce:
>
>> if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legacy
>> Bitcoin transactions are given the witness discount, and a block size limit
>> of 2 MB is imposed.
>
> Johnson Lau’s anti-replay and network version updates[6][7] are included as
> general hard fork safety measures:
>
>> In a 

Re: [bitcoin-dev] Barry Silbert segwit agreement

[James Hilliard via bitcoin-dev]

On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev
 wrote:
> On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
>> > why?
>>
>> the main
>> issue is due to 0.13.1+ having many segwit related features active
>> already, including all the P2P components, the new network service
>> flag, the witness-tx and block messages, compact blocks v2 and
>> preferential peering.
>
> Hmm, the flags are identical in 0.13 and 0.14 clients.
>
> Either way, this is rather trivial to solve. If bugs in older clients mean
> they can’t operate properly when SW is activated (via bit 4) but they don’t
> know its activated (since they only look at bit1), then just ban them when
> they misbehave.
> And tell people to upgrade to a version where SegWit is less buggy.
That would partition off those clients, which is not something we
would want to happen.
>
>> You would have to then have multiple activation
>> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF
>> etc. By doing BIP141 first you then only have the BIP141(active)->HF
>> activation codepath to test for, and you also can't be sure you can
>> rely on BIP141(inactive)->HF activation codepath being the only one
>> until segwit activation expires.
>
> Heh, well, this is rather simple to solve by not having all those activation
> codepaths and just picking **one**.
This isn't possible until either BIP141 segwit is active or BIP141
segwit has expired.
>
> You can safely replace the bit1 activation code with a bit4 activation
> logic, which is based on 80% and has no end-date.
> We both know that the bip9 (bit1) based activation will not trigger before
> the expiration date anyway.
We don't know that since bip9 bit1 only needs 55% hashpower to be
triggered(see BIP91 activation method for how this can be done)
>
> These worries are rather trivial to solve if you do a little bit of proper
> architecture of the solution.  This honestly can’t be a reason for saying NO
> to the majority of the mining hash power giving you a break and offering a
> better SegWit activation.
BIP91 activation is clearly superior than trying to fully redeploy, it
is far simpler and can be done almost immediately with only miners
needing to upgrade.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] Barry Silbert segwit agreement

[James Hilliard via bitcoin-dev]

Mandatory signalling is the only way to lock in segwit with less than
95% hashpower without a full redeployment(which for a number of
technical reasons isn't feasible until after the existing segwit
deployment expires). There's no reason not to signal BIP141 bit 1
while also signalling bit 4, but you would want to use bit 4 to
coordinate bit 1 mandatory signalling.

It would not be feasible to schedule any HF until one can be
completely sure BIP141 is active(at least not without waiting for the
timeout and doing a redeployment) due to activation/p2p codepath
complexity. This is why the mandatory signalling period is needed.

Since it is likely a HF will take months of development and testing I
see this or something similar as the fastest safe path forward:
1. Use BIP91 or similar to activate BIP141 via mandatory signalling
ASAP(likely using bit 4)
2. Develop HF code based on assumption that BIP141 is active so that
you only have to test the BIP141->HF upgrade/activation codepath.
3. Deploy HF after BIP141 lock in(bit 4 can be reused again here since
this will be after BIP91 expiration)

When rolling out some features it often makes sense to combine them
into a single fork for example BIP's 68, 112, 113 were rolled out at
the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF
has required features that would conflict with with features in the
segwit rollout which is why attempting to simultaneously deploy them
would cause major complexity/testing issues(you would have to deal
with feature conflict resolution for multiple potential activation
scenarios). By doing a staged rollout of segwit and then a HF you get
a single testable upgrade path.

Based on past development experiences I wouldn't expect a 6 month
timeline to be realistic for a properly tested HF, but this proposed
upgrade path should be the fastest available for both SegWit and a HF
regardless.

On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev
 wrote:
> Just to clarify one thing, what I described differs from BIP91 in that
> there's no orphaning.  Just when Segwit2MB support reaches 80%, those 80%
> join everyone else in signaling for BIP141.  BIP91 orphaning is an optional
> addition but my guess is it wouldn't be needed.
>
>
> On May 26, 2017 4:02 PM, "Matt Corallo"  wrote:
>>
>> Your proposal seems to be simply BIP 91 tied to the
>> as-yet-entirely-undefined hard fork Barry et al proposed.
>>
>> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
>> you propose, would make the deployment on the incredibly short timeline
>> Barry et al proposed slightly more realistic, though I would expect to
>> see hard fork code readily available and well-tested at this point in
>> order to meet that timeline.
>>
>> Ultimately, due to their aggressive timeline, the Barry et al proposal
>> is incredibly unlikely to meet the requirements of a
>> multi-billion-dollar system, and continued research into meeting the
>> spirit, not the text, of their agreement seems warranted.
>>
>> Matt
>>
>> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
>> > Forgive me if this is a dumb question.  Suppose that rather than
>> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in
>> > just triggered BIP141 signaling (plus later HF).  Would that avoid
>> > incompatibility with existing BIP141 nodes, and get segwit activated
>> > sooner?  Eg:
>> >
>> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support
>> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
>> > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF
>> > (conditional on segwit), and *immediately* turning on bit 1 (BIP141
>> > support)
>> >
>> > I realize this would still leave problems like the aggressive HF
>> > schedule, possible chain split at the HF date between Segwit2MB nodes
>> > and any remaining BIP141 nodes, etc.  My focus here is how
>> > incompatibility with existing nodes could be minimized.
>> >
>> > (BIP91 could also be used if BIP141 support still fell short of 95%.
>> > But if Segwit2MB support reaches 80%, it seems likely that an additional
>> > 15% will support BIP141-without-HF.)
>> >
>> >
>> > ___
>> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

[James Hilliard via bitcoin-dev]

That is incorrect, it is compatible with the current segwit
implementation because it triggers a mandatory signalling period that
will activate segwit on existing nodes.

On Tue, May 23, 2017 at 4:39 PM, Andrew Chow via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi James,
>
> From what I understand, this proposal is incompatible with the current
> segwit implementation with regards to the NODE_WITNESS service bit. I
> believe it could cause network partitioning if the service bit is not
> changed.
>
> Andrew
>
>
> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wrote:
>> I would like to propose an implementation that accomplishes the first
>> part of the Barry Silbert proposal independently from the second:
>>
>> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>> in a way that
>>
>> The goal here is to minimize chain split risk and network disruption
>> while maximizing backwards compatibility and still providing for rapid
>> activation of segwit at the 80% threshold using bit 4.
>>
>> By activating segwit immediately and separately from any HF we can
>> scale quickly without risking a rushed combined segwit+HF that would
>> almost certainly cause widespread issues.
>>
>> Draft proposal:
>> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>>
>> Proposal text:
>> 
>>   BIP: segsignal
>>   Layer: Consensus (soft fork)
>>   Title: Reduced signalling threshold activation of existing segwit 
>> deployment
>>   Author: James Hilliard <james.hillia...@gmail.com>
>>   Status: Draft
>>   Type: Standards Track
>>   Created: 2017-05-22
>>   License: BSD-3-Clause
>>CC0-1.0
>> 
>>
>> ==Abstract==
>>
>> This document specifies a method to activate the existing BIP9 segwit
>> deployment with a majority hashpower less than 95%.
>>
>> ==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==
>>
>> Segwit increases the blocksize, fixes transaction malleability, and
>> makes scripting easier to upgrade as well as bringing many other
>> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower. For a number of reasons a complete redeployment of segwit
>> is difficulty to do until the existing deployment expires. This is due
>> to 0.13.1+ having many segwit related features active already,
>> including all the P2P components, the new network service flag, the
>> witness-tx and block messages, compact blocks v2 and preferential
>> peering. A redeployment of segwit will need to redefine all these
>> things and doing so before expiry would greatly complicate testing.
>>
>> ==Specification==
>>
>> 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.
>>
>> ==Deployment==
>>
>> This BIP will be deployed by a "version bits" with an 80%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "segsignal" and using bit 4.
>>
>> This BIP will have a start time of midnight June 1st, 2017 (epoch time
>> 1496275200) and timeout on midnight November 15th 2017 (epoch time
>> 1510704000). This BIP will cease to be active when segwit is
>> locked-in.
>>
>> === Reference implementation ===
>>
>> 
>> // Check if Segregated Witness is Locked In
>> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> Consensus::Params& params)
>> {
>> LOCK(cs_main);
>> return (VersionBitsState(pindexPrev, params,
>> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> THRESHOLD_LOCKED_IN);
>> }
>>
>> // SEGSIGNAL mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>> &&
>>  !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> // Segwit is not locked in
>>  !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()

Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

[James Hilliard via bitcoin-dev]

On Tue, May 23, 2017 at 5:51 AM, Kekcoin  wrote:
> I think there may be merit to this idea, allowing for political compromise
> without sacrificing the technological integrity of Bitcoin. There are a few
> mechanical problems I see with it, though.
>
> 1. It should change its activation logic from BIP9-style to BIP8-style with
> a flagday of August 1. This to maintain backwards compatibility with the
> current deployment of BIP148 nodes. This proposal seems to be a measure to
> prevent a chainsplit, so it must make sure to avoid triggering one.
That can be done as a separate proposal, it's not mutually exclusive
to this one for those who intend to run BIP148.
>
> 2. This should be for miners only; non-miners should not enforce this. It
> severely weakens the block-signalling activation mechanism in several ways
> (lowered threshold, short deployment timeframe, no "locked in" delay before
> activation) and by doing so opens up attack vectors for
> consensus-partitioning attacks using malicious false signalling. For
> non-miners that seek to take their fate into their own hands, enforcing
> BIP148 is enough.
I disagree that it should be only run by miners, enforcement of
segsignal mandatory signalling by economic nodes strongly discourages
any false signaling.
>
> 3. Even for miners this is more risky than usual; only 31% of hashrate is
> required to false-signal the activation to fork-off honest miners. This
> attack vector is magnified by the lack of "locked in" delay that would allow
> laggards to upgrade before activation. I suggest adding in at least a 1-week
> lock-in period (given the shorter timeframes 2 weeks may eat up too much of
> the available voting time before the brick wall of BIP148 activation on
> August 1).
Those who can should still upgrade for segsignal, the more that
upgrade ahead of activation the more secure it is. Those who don't
upgrade would want to wait for more confirmations anyways. I didn't
think a lock in period was all that good an idea here due to the
fairly short deployment timeline.
>
> Under the assumption that this is indeed compatible with the terms of the
> Silbert agreement, we can presume the involved miners are willing to trust
> eachother more than usual so such a short lock-in period should be
> acceptable.
>
>  Original Message 
> Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
> segwit deployment
> Local Time: May 23, 2017 1:40 AM
> UTC Time: May 22, 2017 10:40 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Dev 
>
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> The goal here is to minimize chain split risk and network disruption
> while maximizing backwards compatibility and still providing for rapid
> activation of segwit at the 80% threshold using bit 4.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
> 
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit deployment
> Author: James Hilliard 
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> 
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==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==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> 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 

[bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment

[James Hilliard via bitcoin-dev]

I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:

"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that

The goal here is to minimize chain split risk and network disruption
while maximizing backwards compatibility and still providing for rapid
activation of segwit at the 80% threshold using bit 4.

By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.

Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki

Proposal text:

  BIP: segsignal
  Layer: Consensus (soft fork)
  Title: Reduced signalling threshold activation of existing segwit deployment
  Author: James Hilliard 
  Status: Draft
  Type: Standards Track
  Created: 2017-05-22
  License: BSD-3-Clause
   CC0-1.0


==Abstract==

This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.

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

Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].

This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.

==Specification==

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.

==Deployment==

This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.

This BIP will have a start time of midnight June 1st, 2017 (epoch time
1496275200) and timeout on midnight November 15th 2017 (epoch time
1510704000). This BIP will cease to be active when segwit is
locked-in.

=== Reference implementation ===


// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}

// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
 !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
 !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}


https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1

==Backwards Compatibility==

This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. Miners will need to upgrade their nodes to
support segsignal otherwise they may build on top of an invalid block.
While this bip is active users should either upgrade to segsignal or
wait for additional confirmations when accepting payments.

==Rationale==

Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way.

By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment.

==References==

Re: [bitcoin-dev] Treating ‘ASICBOOST’ as a Security Vulnerability

[James Hilliard via bitcoin-dev]

Locking the lower bits on the timestamp will likely break existing
hardware that relies on being able to roll ntime.

On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev
 wrote:
> Hello Bitcoin Development Mailing List,
>
> I wish to explain why the current approach to ‘ASICBOOST’ dose not comply 
> with our established best practices for security vulnerabilities and suggest 
> what I consider to be an approach closer matching established industry best 
> practices.
>
>
> 1. Significant deviations from the Bitcoin Security Model have been 
> acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work 
> function should have the same difficulty of producing a desired output.
>
>
> 2. General ASIC optimisation cannot be considered a Security 
> Vulnerabilities.
>
> Quickly being able to check inputs is not a vulnerability. However, being 
> able to craft inputs that are significantly easier to check than alternative 
> inputs is a vulnerability.
>
>
> 3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.
>
> ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be 
> considered an exploit of the Bitcoin Proof-of-Work Function.
>
> For a more detailed look at ‘ASICBOOST’, please have a look at this excellent 
> document by Jeremy Rubin:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> The Bitcoin Community should be able to track the progress of restoring the 
> quality of the Bitcoin Proof-of-Work function to its original assumptions.
>
>
> 4. Work should be taken to prudently and swiftly restore Bitcoins 
> Security Properties.
>
> I recommend the Bitcoin Community fix this vulnerability with expediency.
>
>
>
> Cameron.
>
> PS:
>
> With a soft-fork it probably is possible to completely fix this Proof-of-Work 
> vulnerability.
>
> (Here is my working list of things to do):
>
> 1. Include extra data in the Coinbase Transaction, such as the Witness 
> Root.
>
> 2. Lock the Version. (Use a space in the Coinbase Transaction for 
> signalling future upgrades).
>
> 3. Lock the lower-bits on the Timestamp: Block timestamps only need 
> ~1minute granularity.
>
> 4.  Make a deterministic ordering of transaction chains within a block. 
> (However, I believe this option is more difficult).
>
> Of course, if we have a hard-fork, we should consider the Proof-of-Work 
> internal merkle structure directly.
> ___
> 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] Some real-world results about the current Segwit Discount

[James Hilliard via bitcoin-dev]

Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transactions/second in practice, the exact amount depends
on the real world usage of course though.

On Tue, May 9, 2017 at 11:19 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Thanks Johnson and Hampus for the clarifications.
> However, I would rather do the opposite: soft-fork to 50% now, and soft-fork
> again to 75% discount later if needed, because it doesn't affect the max
> transactions/second.
>
> Segwit as it is today should be activated. However if it is not before
> November, then for the next Segwit attempt I would choose a more
> conservative 50% discount.
>
>
>
> On Tue, May 9, 2017 at 12:45 PM, Johnson Lau  wrote:
>>
>>
>> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev
>> >  wrote:
>> >
>> >
>> > So it seems the 75% discount has been chosen with the idea that in the
>> > future the current transaction pattern will shift towards multisigs. This 
>> > is
>> > not a bad idea, as it's the only direction Bitcoin can scale without a HF.
>> > But it's a bad idea if we end up doing, for example, a 2X blocksize
>> > increase HF in the future. In that case it's much better to use a 50%
>> > witness discount, and do not make scaling risky by making the worse case
>> > block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>> >
>>
>> As we could change any parameter in a hardfork, I don’t think this has any
>> relation with the current BIP141 proposal. We could just use 75% in a
>> softfork, and change that to a different value (or completely redefine the
>> definition of weight) with a hardfork later.
>>
>>
>
>
> ___
> 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] Some real-world results about the current Segwit Discount

[James Hilliard via bitcoin-dev]

The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very little impact on the UTXO size compared with 1MB
non-witness blocks. UTXO size is a bigger issue than blockchain size
since full nodes can't prune the UTXO set.

The discount of 75% for the SegWit softfork doesn't really have any
effect on future hard forks as it can always be adjusted as needed
later on as part of a HF.

On Tue, May 9, 2017 at 8:49 AM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> This [1] article says the current discount prevents witness spam. Witness
> spam is free space in the witness part of the block that can be filled by
> miners to create bigger blocks with almost no cost for the benefit a cluster
> of miners with low latency, increasing centralization.
>
> The 75% discount does not prevent it, but on the contrary leaves a lot of
> extra witness space for spam.
>
> If the maximum block weight is set to 2.7M, each byte of non-witness block
> costs 1.7, and each byte of witness costs 1, then a normal filled block
> would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
> Mbyte block. The worst case would be the average case, and the transaction
> rate would be the maximum possible.
>
> The current 75% discount can only achieve more transactions per second if
> the type of transactions change. Therefore the current 75% discount only
> makes the block size worst case worse (4 Mbytes when it should be 2.7
> Mbytes).
>
> 80% of all inputs/outputs are P2PKH. The only way to make use of the extra
> witness
> space If most P2PKH transactions are replaced by multisigs (typically for
> LN).
>
> So it seems the 75% discount has been chosen with the idea that in the
> future the current transaction pattern will shift towards multisigs. This is
> not a bad idea, as it's the only direction Bitcoin can scale without a HF.
> But it's a bad idea if we end up doing, for example, a 2X blocksize increase
> HF in the future. In that case it's much better to use a 50% witness
> discount, and do not make scaling risky by making the worse case block size
> 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
>
> I've uploaded the code here:
> https://github.com/SergioDemianLerner/SegwitStats
>
>  [1]
> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
>
> On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev
>  wrote:
>>
>> Sergio,
>>
>> I'm not sure what the data you present has to do with the discount.  A 75%
>> discount prevents witness spam precisely because it is 75%, nothing more.
>> The current usage simply gives a guideline on how much capacity is gained
>> through a particular discount.  With the data you show, it would imply that
>> those blocks, with SegWit used where possible, would result in blocks of
>> ~1.8MB.
>>
>>
>>
>> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev
>>  wrote:
>>>
>>> I have processed 1000 blocks starting from Block #461653.
>>>
>>> I computed several metrics, including the supposed size of witness data
>>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>>
>>> This takes into account that other types of transactions will not be
>>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>>> take into account that LN transactions may affect the current state,
>>> increasing the segwit/nosegwit ratio.
>>>
>>> Among a lot of information, I've got the following real world results...
>>>
>>> acMainChainSpace =352608924
>>> acSegwitSpace =599400403
>>> Ratio segwit/nosegwit=1.6999
>>>
>>> This implies that the 75% that discount is not the best option to prevent
>>> witness spam in a block of 4 MB, as stated in
>>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>>>
>>> The non-witness data weight factor should not be 4 but 2.35. The closest
>>> integer value is 2, which leads to a 50% witness discount.
>>>
>>> The Bitcoinj source code is available for anyone to review. I encourage
>>> anyone to re-compute this with another utility to cross-check. Maybe Antoine
>>> Le Calvez (p2sh.info) would like to double-check.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] I do not support the BIP 148 UASF

[James Hilliard via bitcoin-dev]

On Fri, Apr 14, 2017 at 3:58 PM, Tom Zander via bitcoin-dev
 wrote:
> On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
>> This doesn't remove the need for consensus rule enforcement of course.
>
> Thanks for confirming my point.
>
> This means that Gregory was incorrect saying that there is no risk to a non-
> upgraded node on a SegWit network mining a new invalid block. That risk is
> most definitely there for any miners "left behind" operating on a different
> set of consensus rules than the majority.
Greg is correct. There is effectively no risk to a non-upgrade
accidentally mining a new invalid block itself, the only risk is that
a non-upgraded miner could itself mine on top of an invalid block. You
would have to intentionally modify the code to mine an invalid block
which is not something that would be likely to happen accidentally.
>
> Kind of obvious, when you think about it.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] I do not support the BIP 148 UASF

[James Hilliard via bitcoin-dev]

On Fri, Apr 14, 2017 at 3:34 PM, Tom Zander  wrote:
> On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
>> This is false,
>>
>> Those "everyone can spend" transactions are prohibited from being
>> mined due to policy rules.
>
> I expected you to know this, but ok, I'll explain.
>
> A policy rule is not a protocol rule, a mining node is certainly not
> guarenteet to have it, and those that do typically make it configurable.
Yes one can override policy rules and mine invalid SW transactions,
but that's not something that's likely to happen accidentally.
>
> If you depend on one implementation and user configuration for the avoidance
> of chain forks, you are going to have a hard time.
We don't depend on policy to avoid chain forks, policy however is
quite useful for making forks smoother since it can prevent miners
from accidentally mining invalid blocks and prevents users from
accepting invalid transactions accidentally.
This doesn't remove the need for consensus rule enforcement of course.
>
> Thanks for your thoughtful reply, though.
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

[James Hilliard via bitcoin-dev]

It is a consensus rule
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
 wrote:
> On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> wrote:
>>  Someone told me a while back that it would be more natural if we move the
>> nHeight from the coinbase script to the coinbase locktime.  Have you
>> considered doing this?
>
> That change would not be a consensus change and thus free to make any day.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> 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] Issolated Bitcoin Nodes

[James Hilliard via bitcoin-dev]

There were bridge nodes being run on testnet at one point to prevent
forks 
https://github.com/jl2012/bitcoin/commit/9717d856e72baa939d4b273f0a56e6009978e11b

On Thu, Mar 23, 2017 at 7:20 PM, Pieter Wuille via bitcoin-dev
 wrote:
> On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
>  wrote:
>> Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is
>> ok, and those blocks propagate to older nodes with no issues. But when a
>> block tries to be propagated from bitcoind 0.12.+ to newer ones those blocks
>> are NOT being propagated to the peers with newer versions while these newer
>> blocks are being propagated to peers with older versions with no issues.
>>
>> My conclusion is that we have a backward compatibility issue between 0.13.X+
>> and older versions.
>
> Hello Juan,
>
> this is expected behaviour. Nodes with segwit active only download
> blocks from other segwit peers, as old peers cannot provide the
> witness data they need to verify the blocks.
>
> --
> Pieter
> ___
> 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] Managing block size the same way we do difficulty (aka Block75)

[James Hilliard via bitcoin-dev]

What's most likely to happen is miners will max out the blocks they
mine simply to try and get as many transaction fees as possible like
they are doing right now(there will be a backlog of transactions at
any block size). Having the block size double every year would likely
cause major problems and this proposal allows over a 7x increase it
seems.

The main problem with this proposal I think is that users effectively
have no way to stop the miners from increasing block size
continuously.

On Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev
 wrote:
>
> On Sun, Dec 11, 2016 at 12:11 PM, s7r  wrote:
>>
>>
>> This is an incentive, if few miners agree to create a large conglomerate
>> that will ultimately control the network.
>>
>> You miss something obvious that makes this attack actually free of cost.
>> Nothing will "cost them more in transaction fees". A miner can create
>> thousands of transactions paying to himself, and not broadcast them to
>> the network, but hold them and include them in the blocks he mines. The
>> fees are collected by him because transactions are included in a block
>> that he mined and the left amount is in another wallet of the same
>> person. Repeat this continuously to fill blocks.
>
>
> No, that wasn't overlooked. Miners could indeed stuff their own blocks for
> free, but they can't stuff blocks mined by others for free.
>
> In the hypothetical scenario where there is a single mining pool which mines
> most (if not all) of the blocks, we would have much larger problems than
> their ability to raise the max block size gradually. Even if they were able
> to fill 100% of the blocks for an entire year, the max block size for that
> 2016 block period would be 7.25MB (not accounting for SegWit). After the
> whole year they would have made no extra profit vs doing nothing. And as
> soon as they stopped this scheme, block size would spring back to it's
> natural level.
>
> The good news is, this scenario has never happened and even when we've come
> remotely close (when ASICs first shipped), the situation was temporary. The
> odds of this happening in the future and persisting long enough to have any
> major effect with Block75 are very close to zero.
>
>>
>> Topology and bandwidth speed / hash rate of the network cannot be
>> controlled - if we make assumptions about these it might have terrible
>> consequences.
>>
>> Even if we take in consideration that bandwidth will only grow and disk
>> space will only cost less (which is not something we can safely assume,
>> by the way) the hard limit max. block size cannot grow to unlimited
>> value (even if the growth happens over time). There is also a validation
>> cost in time for each block, for the health of the network any node
>> should be able to download _and_ validate a block, before next block
>> gets mined.
>>
>> You said in another post that a permanent solution is preferred, rather
>> than kicking the can down the road. I fully agree, as well as many
>> others reading this list, but the permanent solution doesn't necessarily
>> have to be increasing the max block size dynamically.
>
>
> Increasing *and* decreasing max block size dynamically. Block75 is
> self-correcting, whereas any solution with hardcoded limits can't correct
> without human intervention and would rely on our ability to predict the
> future (which as you pointed out, we can't do). Therefore, any solution
> that's not dynamic cannot be permanent.
>
> Additionally, the frequent and gradual changes in max block size would allow
> us to see any consequences well in advance (years probably).
>
>>
>> If you think about it the other way around, dynamically growing the max
>> block size is also kicking the can down the road ... just without having
>> to touch it and get dust on the boot ;)
>
>
> Not having to touch it again = permanent solution. ;)
>
> It would be helpful if some others would run the numbers on how Block75
> would adjust the block size over time:
>
> new max block size = 1000kb + (average block size over last 2016 blocks -
> 750kb)
>
> -t.k.
>
>
> ___
> 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] Managing block size the same way we do difficulty (aka Block75)

[James Hilliard via bitcoin-dev]

Miners in general are naturally incentivized to always mine max size
blocks to maximize transaction fees simply because there is very
little marginal cost to including extra transactions(there will always
be a transaction backlog of some sort available to mine since demand
for block space is effectively unbounded as fees approach 0 and they
can even mine their own transactions without any fees). This proposal
would almost certainly cause runaway block size growth and encourage
much more miner centralization.

On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev
 wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the Block75
> system. Even if it were attempted and assuming the goal was to create bigger
> blocks, the maximum possible increase would be 25% over the previous block
> size. And, that size would only last for two weeks before readjusting down.
> It would cost them more in transaction fees to stuff the network than they
> could ever make up. To game the system, they'd have to game it forever with
> no possibility of profit.
>
> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly more
> orphaned blocks.
>
> The frequent and small adjustments made by Block75 have the added benefit of
> being more easily adapted to, both psychologically and technologically, with
> regards to miners/node operators.
>
> -t.k
>
> On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev
>  wrote:
>>
>> t. khan via bitcoin-dev wrote:
>> > BIP Proposal - Managing Bitcoin’s block size the same way we do
>> > difficulty (aka Block75)
>> >
>> > The every two-week adjustment of difficulty has proven to be a
>> > reasonably effective and predictable way of managing how quickly blocks
>> > are mined. Bitcoin needs a reasonably effective and predictable way of
>> > managing the maximum block size.
>> >
>> > It’s clear at this point that human beings should not be involved in the
>> > determination of max block size, just as they’re not involved in
>> > deciding the difficulty.
>> >
>> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
>> > passing the decision to miners/pool operators, the max block size should
>> > be adjusted every two weeks (2016 blocks) using a system similar to how
>> > difficulty is calculated.
>> >
>> > Put another way: let’s stop thinking about what the max block size
>> > should be and start thinking about how full we want the average block to
>> > be regardless of size. Over the last year, we’ve had averages of 75% or
>> > higher, so aiming for 75% full seems reasonable, hence naming this
>> > concept ‘Block75’.
>> >
>> > The target capacity over 2016 blocks would be 75%. If the last 2016
>> > blocks are more than 75% full, add the difference to the max block size.
>> > Like this:
>> >
>> > MAX_BLOCK_BASE_SIZE = 100
>> > TARGET_CAPACITY = 75
>> > AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
>> > TARGET_CAPACITY
>> >
>> > To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
>> >
>> > For example, if the last 2016 blocks are 85% full (average block is 850
>> > KB), add 10% to the max block size. The new max block size would be
>> > 1,100 KB until the next 2016 blocks are mined, then reset and
>> > recalculate. The 1,000,000 byte limit that exists currently would
>> > remain, but would effectively be the minimum max block size.
>> >
>> > Another two weeks goes by, the last 2016 blocks are again 85% full, but
>> > now that means they average 935 KB out of the 1,100 KB max block size.
>> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
>> > that to make the new max block size of 1,185 KB.
>> >
>> > Another two weeks passes. This time, the average block is 1,050 KB. The
>> > new max block size is calculated to 1,300 KB (as blocks were 105% full,
>> > minus the 75% capacity target, so 30% added to max block size).
>> >
>> > Repeat every 2016 blocks, forever.
>> >
>> > If Block75 had been applied at the difficulty adjustment on November
>> > 18th, the max block size would have been 1,080KB, as the average block
>> > during that period was 83% full, so 8% is added to the 1,000KB limit.
>> > The current size, after the December 2nd adjustment would be 1,150K.
>> >
>> > Block75 would allow the max block size to grow (or shrink) in response
>> > to transaction volume, and does so predictably, reasonably quickly, and
>> > in a method that prevents wild swings in block size or transaction fees.
>> > It attempts to keep blocks at 75% total capacity over each two week
>> > period, the same way difficulty tries to keep blocks mined 

Re: [bitcoin-dev] Making AsicBoost irrelevant

[James Hilliard via bitcoin-dev]

I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=en

On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
 wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that they are not using AsicBoost (with the exception
> of the 21 Inc Bitcoin computer).
>
> The fact that the optimization was patented is what has required that we
> work to hardfork it out, not that people might have such private
> optimizations. The fact that AsicBoost was independently discovered by
> at least two (if not three) organizations seems to lend credence to the
> idea that private optimizations will only provide a temporary win over
> competitors.
>
> Matt
>
> On 05/11/16 03:14, Timo Hanke via bitcoin-dev wrote:
>> There is no way to tell from a block if it was mined with AsicBoost or
>> not. So you don’t know what percentage of the hashrate uses AsicBoost at
>> any point in time. How can you risk forking that percentage out? Note
>> that this would be a GUARANTEED chain fork. Meaning that after you
>> change the block mining algorithm some percentage of hardware will no
>> longer be able to produce valid blocks. That hardware cannot “switch
>> over” to the majority chain even if it wanted to. Hence you are
>> guaranteed to have two co-existing bitcoin blockchains afterwards.
>>
>> Again: this is unlike the hypothetical persistence of two chains after a
>> hardfork that is only contentious but doesn’t change the mining
>> algorithm, the kind of hardfork you are proposing would guarantee the
>> persistence of two chains.
>>
>> Note that “AsicBoost” above is replaceable with “optimization X”. It’s
>> simply a logical argument: If you want to make optimization X impossible
>> and someone is already using optimization X you end up with two chains.
>> So unless you know exactly which optimizations are in use (and therefore
>> also know which ones are not in use) you can’t make these kind of
>> changes. AsicBoost is known at least since middle of 2013.
>>
>> To be more precise, if you change the block validation ruleset R to
>> block validation ruleset S you have to make sure that every hardware
>> that was capable of mining R-valid blocks is also capable of mining
>> S-valid blocks.
>>
>> The problem is that chip manufacturers will not tell you which
>> optimizations they use. You would have to threaten to irreversibly fork
>> their hardware out by a rule change, only then would they start shouting
>> and reveal their optimization. It seems extremely dangerous to set the
>> precedence of a hardfork that irreversibly forks out a certain type of
>> mining hardware.
>>
>> The part "Also the fix should be compatible with existing mining
>> hardware." is impossible to achieve because it's unclear what "existing
>> mining hardware" is. There has never been a specification of what mining
>> hardware should do. There are only acceptance rules.
>>
>> The only way out is to go the exact opposite way and to embrace as many
>> optimizations as possible to the point where there are no more
>> optimizations left to do, or hopefully getting very close to that point.
>>
>> Timo
>>
>>
>>
>> On Tue, May 10, 2016 at 11:57 AM, Peter Todd via bitcoin-dev
>> > > wrote:
>>
>> As part of the hard-fork proposed in the HK agreement(1) we'd like
>> to make the
>> patented AsicBoost optimisation useless, and hopefully make further
>> similar
>> optimizations useless as well.
>>
>> What's the best way to do this? Ideally this would be SPV
>> compatible, but if it
>> requires changes from SPV clients that's ok too. Also the fix this
>> should be
>> compatible with existing mining hardware.
>>
>>
>> 1)
>> 
>> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
>>
>> 2)
>> 
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org 
>>
>> ___
>> 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
>>
> ___
> 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

Re: [bitcoin-dev] Multi-Stage Merge-Mine Headers Hard-Fork BIP

[James Hilliard via bitcoin-dev]

I've updated the BIP with your suggestions, would it make sense to
just move the activation condition to the 42 week boundary instead of
repeating the last header? Would that be at block 6048 from the start
of the timewarp?

https://github.com/jameshilliard/bips/blob/bip-msmmhhf/bip-msmmhhf.mediawiki

On Wed, Feb 24, 2016 at 4:58 AM, Tier Nolan via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> You need more detail for it to be a BIP.
>
> New Header
>
> new_header.prev = hash of previous header's bitcoin header
> new_header.small_nonce = 4 byte nonce
> new_header.big_nonce = 8 byte nonce
>
> new_header (Can contain any new fields desired)
>
> Fake Block
>
> block.version = 4
> block.prev = new_header.prev
> block.merkle = calculate_merkle(coinbase)
> block.timestamp = block.getPreviousBlock().median_time_past + 1
> block.bits = calculate_bits()
> block.nonce = new_header.small_nonce
> block.tx_count = 1
>
> Coinbase
>
> coinbase.version = 1
> coinbase.tx_in_count = 0
> coinbase.tx_out_count = 1
> coinbase.tx_out[0].value = 0
> coinbase.tx_out[0].pk_script = "OP_RETURN"
>
> This is a "nuclear option" attack that knocks out the main chain.  The
> median time past will increase very slowly.  It only needs to increase by 1
> every 6th blocks.  That gives an increase of 336 seconds for every
> difficulty update.  This will cap the update rate, so give an increase of 4X
> every doubling.
>
> The new headers will end up not meeting the difficulty, so they will
> presumably just repeat the last header?
>
> If the bitcoin chain stays at constant difficulty, then each quadrupling
> will take more time.
>
> After 2 weeks: 4XDiff   (2 weeks per diff period)
> After 10 weeks: 16XDiff (8 weeks per diff period)
> After 42 weeks: 256XDiff (32 weeks per diff period)
>
>
> On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> https://github.com/bitcoin/bips/pull/340
>>
>> BIP: ?
>> Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
>> Author: James Hilliard <james.hillia...@gmail.com>
>> Status: Draft
>> Type: Standards Track
>> Created: 2016-02-23
>>
>> ==Abstract==
>>
>> Use a staged hard fork to implement a headers format change that is
>> merge mine incompatible along with a timewarp to kill the previous
>> chain.
>>
>> ==Specification==
>>
>> We use a block version flag to activate this fork when 3900 out of the
>> previous 4032 blocks have this the version flag set. This flag locks
>> in both of the below stages at the same time.
>>
>> Merge Mine Stage: The initial hard fork is implemented using a merge
>> mine which requires that the original pre-fork chain be mined with a
>> generation transaction that creates no new coins in addition to not
>> containing any transactions. Additionally we have a consensus rule
>> that requires that ntime be manipulated on the original chain to
>> artificially increase difficulty and hold back the original chain so
>> that all non-upgraded clients can never catch up with current time.
>> The artificial ntime is implemented as a consensus rule for blocks in
>> the new chain.
>>
>> Headers Change Stage: This is the final stage of the hard fork where
>> the header format is made incompatible with merge mining, this is
>> activated ~50,000 blocks after the Merge Mine Stage and only at the
>> start of the 2016 block difficulty boundary.
>>
>> ==Motivation==
>>
>> There are serious issues with pooled mining such as block withhold
>> attacks that can only be fixed by making major changes to the headers
>> format.
>>
>> There are a number of other desirable header format changes that can
>> only be made in a non-merge mine compatible way.
>>
>> There is a high risk of there being two viable chains if we don't have
>> a way to permanently disable the original chain.
>>
>> ==Rationale==
>>
>> Our solution is to use a two stage hard fork with a single lock in period.
>>
>> The first stage is designed to kill off the previous chain by holding
>> back ntime to artificially increase network difficulty on the original
>> chain to the point where it would be extremely difficult to mine the
>> 2016 blocks needed to trigger a difficulty adjustment. This also makes
>> it obvious to unupgraded clients that they are not syncing properly
>> and need to upgrade.
>>
>> By locking in both stages at the same time we ensure that any clients
>> merge mining are also locked in for

[bitcoin-dev] Multi-Stage Merge-Mine Headers Hard-Fork BIP

[James Hilliard via bitcoin-dev]

https://github.com/bitcoin/bips/pull/340

BIP: ?
Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
Author: James Hilliard 
Status: Draft
Type: Standards Track
Created: 2016-02-23

==Abstract==

Use a staged hard fork to implement a headers format change that is
merge mine incompatible along with a timewarp to kill the previous
chain.

==Specification==

We use a block version flag to activate this fork when 3900 out of the
previous 4032 blocks have this the version flag set. This flag locks
in both of the below stages at the same time.

Merge Mine Stage: The initial hard fork is implemented using a merge
mine which requires that the original pre-fork chain be mined with a
generation transaction that creates no new coins in addition to not
containing any transactions. Additionally we have a consensus rule
that requires that ntime be manipulated on the original chain to
artificially increase difficulty and hold back the original chain so
that all non-upgraded clients can never catch up with current time.
The artificial ntime is implemented as a consensus rule for blocks in
the new chain.

Headers Change Stage: This is the final stage of the hard fork where
the header format is made incompatible with merge mining, this is
activated ~50,000 blocks after the Merge Mine Stage and only at the
start of the 2016 block difficulty boundary.

==Motivation==

There are serious issues with pooled mining such as block withhold
attacks that can only be fixed by making major changes to the headers
format.

There are a number of other desirable header format changes that can
only be made in a non-merge mine compatible way.

There is a high risk of there being two viable chains if we don't have
a way to permanently disable the original chain.

==Rationale==

Our solution is to use a two stage hard fork with a single lock in period.

The first stage is designed to kill off the previous chain by holding
back ntime to artificially increase network difficulty on the original
chain to the point where it would be extremely difficult to mine the
2016 blocks needed to trigger a difficulty adjustment. This also makes
it obvious to unupgraded clients that they are not syncing properly
and need to upgrade.

By locking in both stages at the same time we ensure that any clients
merge mining are also locked in for the headers change stage so that
the original chain is dead by the time the headers change takes place.

We timewarp over a year of merge mining to massively increase the
difficulty on the original chain to the point that it would be
incredibly expensive to reduce the difficulty enough that the chain
would be able to get caught up to current time.

==Backward Compatibility==

This hardfork will permanently disable all nodes, both full and light,
which do not explicitly add support for it.
However, their security will not be compromised due to the implementation.
To migrate, all nodes must choose to upgrade, and miners must express
supermajority support.

==Reference Implementation==

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

Re: [bitcoin-dev] Blockchain verification flag (BIP draft)

[James Hilliard via bitcoin-dev]

I think something that anyone who isn't validating should be aware of is
that cgminer(which powers the vast majority of the current mining network)
doesn't allow for a pool to revert to mining on the previous block due to
the way chain tracking is implemented.

https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727

On Fri, Dec 4, 2015 at 4:43 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Gavin Andresen via bitcoin-dev 
> writes:
> > Overall, good idea.
> >
> > Is there a write-up somewhere describing in detail the 'accidental
> selfish
> > mining' problem that this mitigates? I think a link in the BIP to a
> fuller
> > description of the problem and how validation-skipping makes it go away
> > would be helpful.
> >
> > RE: which bit to use:  the draft versionbits BIP and BIP101 use bit 30;
> to
> > avoid confusion, I think it would be better to use bit 0.
>
> Yes, BIP9 need to be adjusted (setting bit 30 means BIP9 counts it as a
> vote against all softforks).  BIP101 uses bits 0,1,2 AFAICT, so perhaps
> start from the other end and use bit 29?  We can bikeshed that later
> though...
>
> > I agree with Jannes Faber, behavior with respect to SPV clients should be
> > to only tell them about fully validated headers.
>
> A delicate balance.  If we penalize these blocks too much, it's
> disincentive to set the bit.  Fortunately it's easy for SPV clients to
> decide for themselves, I think?
>
> Cheers,
> Rusty.
> ___
> 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] AT has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box

[James Hilliard via bitcoin-dev]

You should tell AT that you want the DVR/cable box put into what is
usually referred to as "bridge mode" or sometimes "true bridge mode"
depending on your ISP and then use your own router, look under
"Bridged Mode" at the bottom of this page for AT
http://www.att.com/gen/general?pid=23697 . You want your own router to
have the external IP, if it does not it is not configured correctly.
In general one should never use a router provided by their ISP for
anything other than modem functionality since it is typically only the
ISP that can change the firmware on it, it also makes troubleshooting
problems like this more difficult.

On Mon, Aug 31, 2015 at 7:26 PM, Zach G via bitcoin-dev
 wrote:
> I have been struggling to get port 8333 open all year, I gave up and was
> using blockchain for months despite a strong desire to stay on Bitcoin Core,
> but now the issue has reached critical mass since I'm using the python
> Bitcoin server module. I have literally spent my entire day trying to open
> 8333, I thoroughly made sure it was open on the router and computer and it's
> still closed. Strangely enough I got it open for 30 seconds once today but
> something closed it immediately.
>
> After hours of phone calls and messaging AT finally told me the truth of
> what was going on, and only because I noticed it myself and demanded an
> answer. The internet is being routed through a DVR/cable box, and they
> confirmed the DVR also has a firewall. To make this even more absurd they
> refused to turn the firewall off because it is their equipment. So
> effectively they can firewall any port they want even if the customer asks
> them not to, in the unlikely event the customer figures it out.
>
> Perhaps this is the driving force behind the inexplicable and massive
> decline in Bitcoin nodes. Bitcoin is being censored by the ISPs themselves,
> and they won't even tell you that. I had to get in touch with headquarters
> and threaten to rip it out of the wall to get a proper answer.
>
> ___
> 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