Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

[Eric Voskuil via bitcoin-dev]

On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote:
> I define a buried deployment as a consensus rule change that affects
> validity of blocks that are buried by a sufficiently large number of
> blocks in the current valid most-work chain,

Sufficient for what, specifically?

> but the current block (and all its parents) remain valid.

Remain valid in the case where the depth assumption is "sufficient" to
ensure that a chain split is not possible?

If this was true (which it is not), it would imply that there is no
reason to validate any block deeper than the most recent 25,000.
Presumably this means that people may continuously rely on some
authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000.

> BIP 123 suggests that BIPs in the consensus layer should be assigned a
> label "soft fork" or "hard fork". However, I think the differentiation
> into soft fork or hard fork should not be made for BIPs that document
> buried deployments. In contrast to soft forks and hard forks, buried
> deployments do not require community and miner coordination for a safe
> deployment.

They can only avoid this requirement based on the assumption that the
hard fork cannot result in a chain split. This is not the case.

> For a chain fork to happen due to a buried deployment, a massive chain
> reorganization must be produced off of a block in the very past.

In other words a "buried deployment" is a hard fork that is not likely
to cause a chain split. This is a subjective subcategory of hard fork,
not an independent category - unless maybe you can show that there is
the 25,000 blocks number is an objective threshold.

> In the extremely unlikely event of such a large chain reorganization,
> Bitcoin's general security assumptions would be violated regardless of
> the presence of a buried deployment.

This is untrue. The "security assumptions" of Bitcoin do not preclude
deep reorganizations.

e



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

[Gregory Maxwell via bitcoin-dev]

On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev
 wrote:
> On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
>> BIP 123 suggests that BIPs in the consensus layer should be assigned a
>> label "soft fork" or "hard fork". However, I think the differentiation
>> into soft fork or hard fork should not be made for BIPs that document
>> buried deployments. In contrast to soft forks and hard forks, buried
>> deployments do not require community and miner coordination for a safe
>> deployment.
>
> They also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs

In that sense, no but they help people understand the system (e.g. so
they don't go look at implementations and confuse that the activations
they expect are simply not there); and they aid other implementations
in understanding what other people have already analyzed and concluded
was safe. You could certainly get an analysis wrong for one of these
things.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Amend the BIP 123 process to include buried deployments

[Luke Dashjr via bitcoin-dev]

On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
> BIP 123 suggests that BIPs in the consensus layer should be assigned a
> label "soft fork" or "hard fork". However, I think the differentiation
> into soft fork or hard fork should not be made for BIPs that document
> buried deployments. In contrast to soft forks and hard forks, buried
> deployments do not require community and miner coordination for a safe
> deployment.

They also do not require software coordination. Therefore, why should there be 
BIPs at all? Seems to me that we should instead add these documents to 
https://github.com/bitcoin-core/docs

That being said, I'm also okay with just adding an Annex to the original 
softfork/hardfork BIP describing each shortcut. It just seems annoying to have 
two BIPs for every protocol change: one for the change itself, and then 
another for implementation-specific shortcuts taken.

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

[bitcoin-dev] Amend the BIP 123 process to include buried deployments

[Marco Falke via bitcoin-dev]

I define a buried deployment as a consensus rule change that affects
validity of blocks that are buried by a sufficiently large number of
blocks in the current valid most-work chain, but the current block
(and all its parents) remain valid.

BIP 123 suggests that BIPs in the consensus layer should be assigned a
label "soft fork" or "hard fork". However, I think the differentiation
into soft fork or hard fork should not be made for BIPs that document
buried deployments. In contrast to soft forks and hard forks, buried
deployments do not require community and miner coordination for a safe
deployment.

For a chain fork to happen due to a buried deployment, a massive chain
reorganization must be produced off of a block in the very past. In
the extremely unlikely event of such a large chain reorganization,
Bitcoin's general security assumptions would be violated regardless of
the presence of a buried deployment.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Possible change to the MIT license

[Damian Williamson via bitcoin-dev]

I do not know that Bitcoin's position is any weaker because of the terms that 
the software is licenced under.


Cory Fields said:

>Let other projects faff about with copyright litigation and trademark dilution 
>concerns


I disagree completely with any licence change. As well as allowing for the use 
of a software, a licence is also a disclaimer for those responsible for the 
release. Changing a single word can have drastic implications should there ever 
be any action considered against any involved party or group. The current MIT 
licence is IMHO the right fit.


Regards,

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

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

[Greg Sanders via bitcoin-dev]

Yes.

On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd  wrote:
>
>> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
>> > Surely CPFP is already computing the package-fee rates of mempool
>> > transactions.  That is the value we need to compute.
>>
>> True, maybe we can just reuse the CPFP calculation now. That said, AFAIK
>> that's
>> only done in the miner code, not the mempool, so that may not be trivial
>> to
>> actually do.
>>
>
> Do you (or anyone else) know if the package fee rate is considered when
> ejecting transactions from the bottom of the mempool when the mempool gets
> too large?
>
> ___
> 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] Revisiting BIP 125 RBF policy.

[Russell O'Connor via bitcoin-dev]

On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd  wrote:

> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > Surely CPFP is already computing the package-fee rates of mempool
> > transactions.  That is the value we need to compute.
>
> True, maybe we can just reuse the CPFP calculation now. That said, AFAIK
> that's
> only done in the miner code, not the mempool, so that may not be trivial to
> actually do.
>

Do you (or anyone else) know if the package fee rate is considered when
ejecting transactions from the bottom of the mempool when the mempool gets
too large?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev