Re: [bitcoin-dev] Height based vs block time based thresholds

[Hampus Sjöberg via bitcoin-dev]

>From the PR change:

> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period

Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.

Hampus

2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
> to
> ensure they upgrade in time. Not having a mandatory signal turned out to
> be a
> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
> problem
> for BIP 149 as-is). Additionally, it makes the activation decisive and
> unambiguous: once the lock-in period is complete, there remains no
> question as
> to what the correct protocol rules are.
>
> It also enables deploying softforks as a MASF, and only upgrading them to
> UASF
> on an as-needed basis.
>
> Luke
>
>
> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
> > Luke,
> > I previously explored an extra state to require signalling before
> > activation in an earlier draft of BIP8, but the overall impression I got
> > was that gratuitous orphaning was undesirable, so I dropped it. I
> > understand the motivation behind it (to ensure miners are upgraded), but
> > it's also rather pointless when miners can just fake signal. A properly
> > constructed soft fork is generally such that miners have to deliberately
> > do something invalid - they cannot be tricked into it... and miners can
> > always chose to do something invalid anyway.
> >
> > >  Original Message 
> > > From: l...@dashjr.org
> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
> > >  I"ve already opened a PR almost 2 weeks ago
> > > to do this and fix the other issues BIP 9 has.
> > > https://github.com/bitcoin/bips/pull/550
> > > It just needs your ACK to merge.
> > >
> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
> > >> they are confusing (the first retarget after threshold). It is also
> > >> vulnerable to miners fiddling with timestamps in a way that could
> > >> prevent or delay activation - for example by only advancing the block
> > >> timestamp by 1 second you would never meet the threshold (although
> this
> > >> would come a the penalty of hiking the difficulty dramatically). On
> the
> > >> other hand, the exact date of a height based thresholds is hard to
> > >> predict a long time in advance due to difficulty fluctuations.
> However,
> > >> there is certainty at a given block height and it"s easy to monitor.
> If
> > >> there is sufficient interest, I would be happy to amend BIP8 to be
> > >> height based. I originally omitted height based thresholds in the
> > >> interests of simplicity of review - but now that the proposal has been
> > >> widely reviewed it would be a trivial amendment.
> ___
> 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] difficulty adjustment (was: The Nuclear Option: BIP148 + MR POWA)

[Henning Kopp via bitcoin-dev]

Hi,

> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.

I also thought about this some time ago. But note that this implies
that forks grow with the same block frequency as the main chain. Thus
the longest chain rule becomes irrelevant, since all chains will have
the same length (in expectancy). Rather, the chain with most work is
the true one.

Best
Henning


On Wed, Jul 05, 2017 at 02:02:08PM +, Troy Benjegerdes via bitcoin-dev 
wrote:
> The fastest way to triple Bitcoin capacity is to split the network into
> two or three different blockchains. We encourage forks of software, why
> are blockchains somehow different?
> 
> Yes, this is risky, and probably volatile.
> 
> I honestly don't expect lots of people with large amounts of money 
> invested (exchanges, financial institutions, etc) to go along with 
> something like this, and that say 90% of the wealth with stay concentrated
> in whatever chain has the majority SHA256 hashpower.
> 
> But as a game-theory excercise to see who's theories actually work?
> 
> I highly encourage a real-world test of all these theories.
> 
> I would also highly advise finding a simple and robust difficulty adjustment
> that occurs every block instead of bitcoin/litecoin's 2016 block use.
> 
> On Wed, Jul 05, 2017 at 09:18:36AM +, John Hardy via bitcoin-dev wrote:
> > This idea is highly contentious as it would guarantee a viable chain of 
> > Bitcoin with SegWit activated whether BIP148 gained sufficient support or 
> > not. I am not necessarily advocating it - just putting it out for 
> > discussion. While the downside is that it could permanently split the 
> > network, the upside is that it could heap additional pressure on miners to 
> > follow the BIP148 chain and ensure a minimally disruptive upgrade. This is 
> > pure game theory.
> > 
> > 
> > 
> > MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce 
> > an additional proof of work to a blockchain in response to a detected 
> > mining behaviour.
> > 
> > 
> > 
> > In the case of BIP148, the criteria for activation could be when the 
> > software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) 
> > ahead of a BIP148 compliant chain.
> > 
> > 
> > 
> > At this stage the software would change its consensus rules (hard fork) to 
> > do two things:
> > 
> >   *   Lower the difficulty for existing PoW method (SHA256).
> > 
> >   *   Introduce a second POW method, such as Scrypt or Ethash, that is 
> > incompatible with SHA256 hardware but already has an established mining 
> > industry for altcoins.
> > 
> > 
> > 
> > The difficulty should be low, and blocks will initially be found much more 
> > quickly than every 10 minutes until the difficulty adjusts. Each method 
> > would have its own difficulty. It could be a requirement that POW methods 
> > alternate to neutralise attacks from the other chain.
> > 
> > 
> > 
> > This would guarantee SegWit activation. Anybody who is already running a 
> > BIP148 node could just as easily run a BIP148 + MR POWA node. This could 
> > not realistically be supported by Core and would have to be implemented in 
> > a grassroots movement, similar to BIP148.
> > 
> > 
> > 
> > Ideally, it would just force the miners to follow the BIP148 chain (or risk 
> > the value of their hardware being hurt) and the code would never be 
> > activated. MR POWA would mean BIP148 miners would no longer need to ?hold 
> > their nerve? as they would be guaranteed a viable chain and rewarded for 
> > their early support.
> > 
> > 
> > Regards,
> > 
> > 
> > John Hardy
> > 
> > j...@seebitcoin.com
> > 
> > 
> 
> > ___
> > 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
> 

-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp
___
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

[Rhavar via bitcoin-dev]

Thanks Andreas, that's actually a pretty good use-case I didn't think of.
Perhaps you could make the rule: "To spend from an unconfirmed BIP125 output, 
the transaction feerate needs to be higher than its unconfirmed parent's 
effective feerate."
It doesn't totally solve the problem, but I think in practice would do a good 
job (most of the problematic descendants tends to be low feerate sweeps). It 
would also preserve the ability for receivers to use CPFP if they wish.

-Ryan

>  Original Message 
> Subject: Re: [bitcoin-dev] BIP proposal: No chaining off replaceable 
> transactions
> Local Time: July 4, 2017 6:50 AM
> UTC Time: July 4, 2017 11:50 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
> Your BIP would take away the only way the *receiver* has to raise the
> fee: CPFP. And the receiver is arguably the more important party in this
> question. After all the sender has no real incentive for his payment to
> be confirmed; it"s receiver who has.
> On 07/02/2017 10:35 PM, Rhavar via bitcoin-dev wrote:
>> ==Abstract==
>>
>> BIP125 allows transactions to opt into replaceability with a primary use
>> case
>> of allowing users to increase the fees of unconfirming transactions,
>> helping create
>> a more efficient fee market place.
>>
>> However this goal is hindered when the receiver of a transaction spends
>> from the
>> unconfirmed output, which exposes the sender to the awkward position of
>> needing
>> to pick between needing to pay an effectively unbounded amount of money
>> as per the BIP125 rules, or not fee bump at all.
>>
>> This is especially problematic in the case of batched sends in which
>> there are
>> multiple independent receivers. In practice this means wallets and
>> services can not effectively low ball the fee of transactions, with the
>> intention of fee bumping due to the risk of the receiver spending or
>> sweeping it before it confirms.
>>
>> In order to support a healthy fee marketplace, this proposal aims to
>> increase
>> the utility of bip125 by making transactions that spend an unconfirmed
>> BIP125
>> output non-standard.
>>
>>
>> ==Summary==
>>
>> This policy specifies a max chain depth of 1 for any BIP125 transactions.
>>
>> ==Impact==
>>
>> Receivers of BIP125 transactions will need to wait until the transaction
>> has confirmed before spending from it. This will not be significantly
>> different
>> than it is currently as they receivers need to be monitoring for
>> replacements.
>>
>> If senders want to make further transactions before the BIP125
>> transaction confirms,
>> and need to utilize the change of the transaction: they will need to
>> replace the
>> transaction with a one that makes the other send in "pass through" style
>> or first
>> finalize the BIP125 transaction and then chain from the spend normally.
>>
>>
>> -Ryan
>>
>>
>>
>>
>> ___
>> 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] The Nuclear Option: BIP148 + MR POWA

[Troy Benjegerdes via bitcoin-dev]

The fastest way to triple Bitcoin capacity is to split the network into
two or three different blockchains. We encourage forks of software, why
are blockchains somehow different?

Yes, this is risky, and probably volatile.

I honestly don't expect lots of people with large amounts of money 
invested (exchanges, financial institutions, etc) to go along with 
something like this, and that say 90% of the wealth with stay concentrated
in whatever chain has the majority SHA256 hashpower.

But as a game-theory excercise to see who's theories actually work?

I highly encourage a real-world test of all these theories.

I would also highly advise finding a simple and robust difficulty adjustment
that occurs every block instead of bitcoin/litecoin's 2016 block use.

On Wed, Jul 05, 2017 at 09:18:36AM +, John Hardy via bitcoin-dev wrote:
> This idea is highly contentious as it would guarantee a viable chain of 
> Bitcoin with SegWit activated whether BIP148 gained sufficient support or 
> not. I am not necessarily advocating it - just putting it out for discussion. 
> While the downside is that it could permanently split the network, the upside 
> is that it could heap additional pressure on miners to follow the BIP148 
> chain and ensure a minimally disruptive upgrade. This is pure game theory.
> 
> 
> 
> MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an 
> additional proof of work to a blockchain in response to a detected mining 
> behaviour.
> 
> 
> 
> In the case of BIP148, the criteria for activation could be when the software 
> detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a 
> BIP148 compliant chain.
> 
> 
> 
> At this stage the software would change its consensus rules (hard fork) to do 
> two things:
> 
>   *   Lower the difficulty for existing PoW method (SHA256).
> 
>   *   Introduce a second POW method, such as Scrypt or Ethash, that is 
> incompatible with SHA256 hardware but already has an established mining 
> industry for altcoins.
> 
> 
> 
> The difficulty should be low, and blocks will initially be found much more 
> quickly than every 10 minutes until the difficulty adjusts. Each method would 
> have its own difficulty. It could be a requirement that POW methods alternate 
> to neutralise attacks from the other chain.
> 
> 
> 
> This would guarantee SegWit activation. Anybody who is already running a 
> BIP148 node could just as easily run a BIP148 + MR POWA node. This could not 
> realistically be supported by Core and would have to be implemented in a 
> grassroots movement, similar to BIP148.
> 
> 
> 
> Ideally, it would just force the miners to follow the BIP148 chain (or risk 
> the value of their hardware being hurt) and the code would never be 
> activated. MR POWA would mean BIP148 miners would no longer need to ?hold 
> their nerve? as they would be guaranteed a viable chain and rewarded for 
> their early support.
> 
> 
> Regards,
> 
> 
> John Hardy
> 
> j...@seebitcoin.com
> 
> 

> ___
> 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] The Nuclear Option: BIP148 + MR POWA

[John Hardy via bitcoin-dev]

This idea is highly contentious as it would guarantee a viable chain of Bitcoin 
with SegWit activated whether BIP148 gained sufficient support or not. I am not 
necessarily advocating it - just putting it out for discussion. While the 
downside is that it could permanently split the network, the upside is that it 
could heap additional pressure on miners to follow the BIP148 chain and ensure 
a minimally disruptive upgrade. This is pure game theory.



MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an 
additional proof of work to a blockchain in response to a detected mining 
behaviour.



In the case of BIP148, the criteria for activation could be when the software 
detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a 
BIP148 compliant chain.



At this stage the software would change its consensus rules (hard fork) to do 
two things:

  *   Lower the difficulty for existing PoW method (SHA256).

  *   Introduce a second POW method, such as Scrypt or Ethash, that is 
incompatible with SHA256 hardware but already has an established mining 
industry for altcoins.



The difficulty should be low, and blocks will initially be found much more 
quickly than every 10 minutes until the difficulty adjusts. Each method would 
have its own difficulty. It could be a requirement that POW methods alternate 
to neutralise attacks from the other chain.



This would guarantee SegWit activation. Anybody who is already running a BIP148 
node could just as easily run a BIP148 + MR POWA node. This could not 
realistically be supported by Core and would have to be implemented in a 
grassroots movement, similar to BIP148.



Ideally, it would just force the miners to follow the BIP148 chain (or risk the 
value of their hardware being hurt) and the code would never be activated. MR 
POWA would mean BIP148 miners would no longer need to “hold their nerve” as 
they would be guaranteed a viable chain and rewarded for their early support.


Regards,


John Hardy

j...@seebitcoin.com


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

Re: [bitcoin-dev] Height based vs block time based thresholds

[Kekcoin via bitcoin-dev]

Luke's proposed changes to BIP8 (specifically, the FAILING state) seem designed 
to address the regression compared to BIP9 that there is no way to avoid 
activating a softfork that is shown to be suboptimal or flawed in some (serious 
enough) way - after deployment is well underway - without hardforking.
I agree with your principle but we should also look at the circumstances in 
which this mechanism would be beneficial vs. when it would cause harm (compared 
to BIP8 without this mechanism). The scenario this was designed for is "miners 
refusing to activate, on non-technical grounds, a widely desired upgrade" - in 
which case the "wakeup call" would be in users' hands, not anyone in particular.
Is there a hypothetical scenario in which the orphan risk outweighs the 
benefits of having this kind of upgrade mechanism that can (at deploy-time) be 
chosen to be optional by default with a deferred mechanism to make it 
mandatory? If so, is there any thought on how to realize the latter without the 
former?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
> Local Time: July 5, 2017 8:06 AM
> UTC Time: July 5, 2017 8:06 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Dev 
> On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
>  wrote:
>> I"ve already opened a PR almost 2 weeks ago to do this and fix the other
>> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>>
>> It just needs your ACK to merge.
> These proposals for gratuitous orphaning are reckless and coersive.
> We have a professional obligation to first do no harm, and amplifying
> orphaning which can otherwise easily be avoided violates it.
> It is not anyones position to decide who does and doesn"t need to be
> "woken up" with avoidable finical harm, nor is it any of our right to
> do so at the risk of monetary losses by any and all users users from
> the resulting network instability.
> It"s one thing to argue that some disruption is strictly needed for
> the sake of advancement, it"s another to see yourself fit as judge,
> jury, and executioner to any that does not jump at your command.
> (which is exactly the tone I and at least some others extract from
> your advocacy of these changes and similar activity around BIP148).
> I for one oppose those changes strongly.
>> Not having a mandatory signal turned out to be a serious bug in BIP 9,
> I have seen no evidence or case for this.
> ___
> 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] Height based vs block time based thresholds

[Gregory Maxwell via bitcoin-dev]

On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
 wrote:
> I've already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>
> It just needs your ACK to merge.

These proposals for gratuitous orphaning are reckless and coersive.
We have a professional obligation to first do no harm, and amplifying
orphaning which can otherwise easily be avoided violates it.

It is not anyones position to decide who does and doesn't need to be
"woken up" with avoidable finical harm, nor is it any of our right to
do so at the risk of monetary losses by any and all users users from
the resulting network instability.

It's one thing to argue that some disruption is strictly needed for
the sake of advancement, it's another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).

I for one oppose those changes strongly.

> Not having a mandatory signal turned out to be a serious bug in BIP 9,

I have seen no evidence or case for this.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev