Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Erik Aronesty via bitcoin-dev]

This is the declining percentage of signaling activation.

It has all the benefits of both.

Eventually it becomes a LOT=true, so any argument for LOT=true holds

And all of the arguments for LOT=false are satisfied by the cool down
period.



On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> How about a compromise?
>
> With LOT=false, taproot will be activated if at least 95% of the miners
> vote yes.
> With LOT=true, taproot will be activated if at least 0% of the miners
> vote yes.
> ...with LOT=maybe, taproot will be activated if at least ~some% of the
> miners vote yes?
>
> If you want the 'emergency cancel' feature without binding yourself to
> it, couldn't you have some middle-of-the-road solution? "Taproot will be
> enabled if miner support ever goes above 95%, or on flag day if miner
> support is >20% then". That would prevent obstreperous miners from doing
> too much damage, while still hopefully making it possible to bail out of
> a disaster.
>
> On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
> > On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via bitcoin-dev
> > wrote:
> >> As we saw in 2017 with BIP 9, coordinating activation by miner signal
> >> alone,
> >> despite its potential benefits, also leaves open the door to a miner
> >> veto.
> >
> > To the contrary, we saw in 2017 that miners could *not* successfully
> > veto a BIP 9 activation. It was certainly more effort and risk than was
> > desirable to override the attempted veto, but the attempt at vetoing
> > nevertheless failed.
> >
> >> It wouldn't be much different than adding back the inflation bug
> >> (CVE-2018-17144) and trusting miners not to exploit it.
> >
> > That is ridiculous FUD.
> >
> >> With LOT=False in the picture, however, things can get messy:
> >
> > LOT=false is always in the picture if we are talking about a soft-fork:
> > the defining feature of a soft-fork is that old node software continues
> > to work, and old node software will be entirely indifferent to whether
> > activation is signalled or not.
> >
> >> some users will
> >> enforce Taproot(eg) (those running LOT=True), while others will not
> >> (those
> >> with LOT=False)
> >
> > If you are following bip8 with lockinontimeout=false, you will enforce
> > taproot rules if activation occurs, you will simply not reject blocks
> > if
> > activation does not occur.
> >
> >> Users with LOT=True will still get all the safety thereof,
> >> but those with LOT=False will (in the event of miners deciding to
> >> produce a
> >> chain split) face an unreliable chain, being replaced by the LOT=True
> >> chain
> >> every time it overtakes the LOT=False chain in work.
> >
> > This assumes anyone mining the chain where taproot does not activate is
> > not able to avoid a reorg, despite having majority hashpower (as
> > implied
> > by the lot=true chain having to overtake them repeatedly). That's
> > absurd;
> > avoiding a reorg is trivially achieved via running "invalidateblock",
> > or
> > via pool software examining block headers, or via a patch along the
> > lines
> > of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> > here's a sketch of such a patch:
> >
> >
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f
> >
> >> For 2 weeks, users with LOT=False would not have a usable network.
> >
> > That's also ridiculous FUD.
> >
> > If it were true, it would mean the activation mechanism was not
> > acceptable, as non-upgraded nodes would also not have a usable network
> > for the same reason.
> >
> > Fortunately, it's not true.
> >
> > More generally, if miners are willing to lose significant amounts of
> > money mining orphan blocks, they can do that at any time. If they're
> > not inclined to do so, it's incredibly straightforward for them to
> > avoid
> > doing so, whatever a minority of other miners might do.
> >
> >> The overall risk is maximally reduced by LOT=True being the only
> >> deployed
> >> parameter, and any introduction of LOT=False only increases risk
> >> probability
> >> and severity.
> >
> > LOT=false is the default behaviour of everything single piece of node
> > software out there. That behaviour doesn't need to be introduced, it's
> > already universal.
> >
> > Cheers,
> > aj
> >
> > ___
> > 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] Taproot NACK

[Daniel Edgecumbe via bitcoin-dev]

Any "transparency" in the blockchain, beyond that required for a participant to 
determine valid ownership, can only reasonably be thought of as a bug.

Today I spent approximately $5 at a chip shop in North London in cash. Besides 
the fact that I have voluntarily chosen to share this information, it is 
absolutely no concern of yourself or any other party that this transaction has 
occured.

Bitcoin is digital cash.

Daniel Edgecumbe | esotericnonsense
em...@esotericnonsense.com | https://esotericnonsense.com

On Mon, Mar 1, 2021, at 22:37, Eric Voskuil via bitcoin-dev wrote:
> To be clear, is this a NACK because Taproot reduces “transparency” 
> (increases privacy) on the chain (“maintaining consensus” is obviously 
> an argument against any protocol change, so that’s a red herring)? 
> 
> And is it your theory that only an “honest” (statute abiding) person 
> should have privacy, and not against the state, and/or that mixers are 
> sufficient privacy?
> 
> Personally, I’m not moved by such an argument. What do you think is the 
> value proposition of Bitcoin?
> 
> e
> 
> > On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 
> >  wrote:
> > 
> >  
> > Good Afternoon,
> > 
> > I am going to take tough terms with much of your reply and do appreciate a 
> > courteous practice. Having previously made public disclosure of my 
> > affiliation with Jambler.io it seems sufficient to disclose my affiliation 
> > through the link in my email signature block.
> > 
> > My concern is not increased privacy it is maintaining consensus values and 
> > the transparency of the blockchain wherein all transactions are published 
> > in an immutable record and that forbids the redaction of information by any 
> > obfuscation. A separate concern is the availability of a privacy suitable 
> > for cash should a Bitcoin user desire and especially without disturbing the 
> > existing consensus.
> > 
> > The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you 
> > may experience yourself, you do not allow people to follow you around 
> > looking in your purse, suppose you are dealing entirely with cash, and to 
> > see where and how much you fill it up, and where you spend. Nonetheless, 
> > for an honest person, their wallet is available for government audit as are 
> > their financial affairs. This is consistent with the existing operation of 
> > consensus.
> > 
> > My full email signature block is a disclosure where I have some affiliation 
> > with the referenced website being that it carries at least some information 
> > that I have provided or that in some way I am associated perhaps only 
> > making use of their services. For example, I hardly make a profit from 
> > LinkedIn just my information is there. Also, I have made previous public 
> > disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by 
> > Jambler.io wherein I receive a service referral fee and am not in receipt 
> > of any part of the process transaction. The operation block diagram 
> > provided by Jambler.io is provided here and attached.
> > 
> > 
> > [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> > https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png=622=gTi7r1cfh-yynw
> > from this thread  https://bitcointalk.org/index.php?topic=5267588
> > 
> > 
> > The installation script provided by Jambler.io that is the basis of my 
> > referral website is also publicly published,
> > https://github.com/jambler-io/bitcoin-mixer
> > 
> > The disclosure for the partner program is available from Jambler.io however 
> > and is made prominently on my referral website. While it may seem lucrative 
> > at first I insist all partner profits are reportable on your personal 
> > income.
> > https://jambler.io/become-partner.php
> > 
> > I am certainly better than confident that you appreciate the difference 
> > between an open and transparent blockchain and the ability of the user to 
> > not reveal details of the content of their wallet publicly.
> > 
> > If further clarification is required may I suggest you pay a token and mix 
> > some Bitcoin wherein our discussion may then have some point of reference.
> > 
> > KING JAMES HRMH
> > Great British Empire
> > 
> > Regards,
> > The Australian
> > LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> > of Hougun Manor & Glencoe & British Empire
> > MR. Damian A. James Williamson
> > Wills
> > 
> > et al.
> > 
> >  
> > Willtech
> > www.willtech.com.au
> > www.go-overt.com
> > and other projects
> >  
> > earn.com/willtech
> > linkedin.com/in/damianwilliamson
> > 
> > 
> > m. 0487135719
> > f. +61261470192
> > 
> > 
> > This email does not constitute a general advice. Please disregard this 
> > email if misdelivered.
> > *From:* Ariel Lorenzo-Luaces 
> > *Sent:* Monday, 1 March 2021 12:07 AM
> > *To:* LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin 
> > Protocol Discussion 
> > *Subject:* Re: [bitcoin-dev] Taproot NACK 
> >  
> > Hello 

Re: [bitcoin-dev] Proposal for new "disabletx" p2p message

[Antoine Riard via bitcoin-dev]

Hi John,

> I think a good counter-argument against simply using `fRelay` for this
> purpose is that we shouldn't reuse a protocol feature designed for one
> function to achieve a totally different aim. However, we know that nodes
> on the network have been using `fRelay` to disable transaction relay
> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that
> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or
> later (when block-relay-only connections were introduced), so using
> `fRelay` to disable transaction relay is now de facto part of the p2p
> protocol.


I don't think this is good practice ecosystem-wise. To understand tx-relay
opt-out from peers correctly, a _non_ Bitcoin Core client has to implement
the `fRelay` subset of BIP37, but ignore the wider part around FILTER*
messages. Or implement those messages, only to disconnect peers sending
them, thus following BIP111 requirements.

Thus, future developers of bitcoin software have the choice between
implementing a standard in a non-compliant way or implementing p2p messages
for a light client protocol in a way of deprecation ? Even further, an
interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until
the filter is set prevents a client being flooded with traffic in the brief
window of time") would make it okay to send TX messages to your inbound
block-relay-only peers. And that your client shouldn't be disconnected for
such behavior.

On the long-term, IMHO, better to have a well-defined standard with a clean
negotiation mechanism rather than relying on code specifics of a given
Bitcoin client. If we don't want to introduce a new message and
corresponding code changes, it would be wise at least to extract VERSION's
`fRelay` and how Core handles it in its own BIP.

> I think a better approach would be for Bitcoin Core to only relay addr
> records to an inbound peer if it has previously received an `addr` or
> `addrv2` message from that peer, since that indicates definitively that
> the peer actively gossips `addr` records. This approach was first
> suggested by AJ in the original block-relay-only PR[15].

If a node is willingly to opt-out from addr-relay from one of its inbound
peers, how is it supposed to do ? Of course, you can drop such messages on
the floor, your peer is just going to waste bandwidth for nothing. IIRC
from past irc p2p meetings, we're really unclear about what a
good-propagation-and-privacy-preserving addr-relay strategy should look
like. Note, that distrusting your inbound peers with your addr-relay might
be a sane direction. Explicit addr-relay negotiation will offer more
flexibility (and more hygienic code paths rather than triggering data
structures initialization in few different locations).

> - update the inbound eviction logic to protect more inbound peers which
> do not have transaction relay data structures.

Given inbound connections might be attacker-controlled and tx-relay opt-out
signaling is also attacker-controlled, wouldn't this give a bias toward an
attacker in occupying our inbound slots ? Compared to honest inbound peers,
which in average are going to be full-relay.

Cheers,
Antoine



Le lun. 1 mars 2021 à 16:07, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi Suhas,
>
> Thank you for this proposal. I agree with your aims, but I think a new
> P2P message isn't necessary to achieve them.
>
> # Motivation
>
> There are two distinct (but interacting) motivations:
>
> 1. Allow a node to accept more incoming connections which will only be
>used for block propagation (no transaction relay or addr gossip),
>while minimizing resource requirements.
>
> 2. Prevent `addr` gossip messages from being sent to peers which will
>'black hole' those addrs (i.e. not relay them further).
>
> These motivations interact because if we simply increase the number of
> block-relay-only connections that nodes make without making any
> allowance for the fact those connections won't gossip addr records, then
> we'll increase the number of addr black holes and worsen addr gossip.
>
> # Using fRelay=false to signal no transaction relay.
>
> `fRelay` is an optional field in the `version` message. There are three
> BIPs concerned with `fRelay`:
>
> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient
>   that they must not relay transactions over the connection until a
>   `filteradd` message has been received.
>
> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
>   how widely this BIP has been adopted by implementations.
>
> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
>   bloom filters are served by this node. According to this BIP, "If a
>   node does not support bloom filters but receives a "filterload",
>   "filteradd", or "filterclear" message from a peer the node should
>   disconnect that peer immediately."
>
> Within Bitcoin Core:
>
> - PR 1795[4] (merged in January 

Re: [bitcoin-dev] Taproot NACK

[Eric Voskuil via bitcoin-dev]

To be clear, is this a NACK because Taproot reduces “transparency” (increases 
privacy) on the chain (“maintaining consensus” is obviously an argument against 
any protocol change, so that’s a red herring)? 

And is it your theory that only an “honest” (statute abiding) person should 
have privacy, and not against the state, and/or that mixers are sufficient 
privacy?

Personally, I’m not moved by such an argument. What do you think is the value 
proposition of Bitcoin?

e

> On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 
>  wrote:
> 
> 
> Good Afternoon,
> 
> I am going to take tough terms with much of your reply and do appreciate a 
> courteous practice. Having previously made public disclosure of my 
> affiliation with Jambler.io it seems sufficient to disclose my affiliation 
> through the link in my email signature block.
> 
> My concern is not increased privacy it is maintaining consensus values and 
> the transparency of the blockchain wherein all transactions are published in 
> an immutable record and that forbids the redaction of information by any 
> obfuscation. A separate concern is the availability of a privacy suitable for 
> cash should a Bitcoin user desire and especially without disturbing the 
> existing consensus.
> 
> The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you 
> may experience yourself, you do not allow people to follow you around looking 
> in your purse, suppose you are dealing entirely with cash, and to see where 
> and how much you fill it up, and where you spend. Nonetheless, for an honest 
> person, their wallet is available for government audit as are their financial 
> affairs. This is consistent with the existing operation of consensus.
> 
> My full email signature block is a disclosure where I have some affiliation 
> with the referenced website being that it carries at least some information 
> that I have provided or that in some way I am associated perhaps only making 
> use of their services. For example, I hardly make a profit from LinkedIn just 
> my information is there. Also, I have made previous public disclosure of the 
> affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I 
> receive a service referral fee and am not in receipt of any part of the 
> process transaction. The operation block diagram provided by Jambler.io is 
> provided here and attached.
> 
> 
> [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
> https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png=622=gTi7r1cfh-yynw
> from this thread  https://bitcointalk.org/index.php?topic=5267588
> 
> 
> The installation script provided by Jambler.io that is the basis of my 
> referral website is also publicly published,
> https://github.com/jambler-io/bitcoin-mixer
> 
> The disclosure for the partner program is available from Jambler.io however 
> and is made prominently on my referral website. While it may seem lucrative 
> at first I insist all partner profits are reportable on your personal income.
> https://jambler.io/become-partner.php
> 
> I am certainly better than confident that you appreciate the difference 
> between an open and transparent blockchain and the ability of the user to not 
> reveal details of the content of their wallet publicly.
> 
> If further clarification is required may I suggest you pay a token and mix 
> some Bitcoin wherein our discussion may then have some point of reference.
> 
> KING JAMES HRMH
> Great British Empire
> 
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
> 
> et al.
> 
>  
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>  
> earn.com/willtech
> linkedin.com/in/damianwilliamson
> 
> 
> m. 0487135719
> f. +61261470192
> 
> 
> This email does not constitute a general advice. Please disregard this email 
> if misdelivered.
> From: Ariel Lorenzo-Luaces 
> Sent: Monday, 1 March 2021 12:07 AM
> To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin Protocol 
> Discussion 
> Subject: Re: [bitcoin-dev] Taproot NACK
>  
> Hello LORD HIS EXCELLENCY JAMES HRMH
> 
> I find a striking dichotomy between your concern of increased privacy in 
> bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
> 
> At first your concerns seemed genuine but after seeing your promotion of a 
> bitcoin mixer I'm thinking your concerns may be more profit motivated? I 
> can't tell since you failed to disclose your relationship with the mixer.
> 
> Could you please clarify your association with the bitcoin mixer and moving 
> forward could you please always do proper disclosure any time you're 
> publically talking about bitcoin transaction privacy. It's only fair to do so 
> as to not mislead people in an attempt to manipulate at worst and just a 
> courteous practice at best.
> 
> Cheers
> Ariel Lorenzo-Luaces
> On Feb 28, 2021, 

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[Emil Pfeffer via bitcoin-dev]

On Tue, Mar 02, 2021 at 01:06:14AM +1000, Anthony Towns via bitcoin-dev wrote:
> On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via bitcoin-dev wrote:
> > As we saw in 2017 with BIP 9, coordinating activation by miner signal 
> > alone, 
> > despite its potential benefits, also leaves open the door to a miner veto. 
> 
> To the contrary, we saw in 2017 that miners could *not* successfully
> veto a BIP 9 activation. It was certainly more effort and risk than was
> desirable to override the attempted veto, but the attempt at vetoing
> nevertheless failed.

You cannot prove a statement to be false by making another statement.

> 
> > It wouldn't be much different than adding back the inflation bug 
> > (CVE-2018-17144) and trusting miners not to exploit it.
> 
> That is ridiculous FUD.

That is an analogy not FUD. A strong one nevertheless but still an analogy.

> 
> > With LOT=False in the picture, however, things can get messy:
> 
> LOT=false is always in the picture if we are talking about a soft-fork:
> the defining feature of a soft-fork is that old node software continues
> to work, and old node software will be entirely indifferent to whether
> activation is signalled or not.
> 

That is the correct description of how soft-forks should work in principle.

> > some users will 
> > enforce Taproot(eg) (those running LOT=True), while others will not (those 
> > with LOT=False)
> 
> If you are following bip8 with lockinontimeout=false, you will enforce
> taproot rules if activation occurs, you will simply not reject blocks if
> activation does not occur.

Also correct in principle.


> > Users with LOT=True will still get all the safety thereof, 
> > but those with LOT=False will (in the event of miners deciding to produce a 
> > chain split) face an unreliable chain, being replaced by the LOT=True chain 
> > every time it overtakes the LOT=False chain in work.
> 
> This assumes anyone mining the chain where taproot does not activate is
> not able to avoid a reorg, despite having majority hashpower (as implied
> by the lot=true chain having to overtake them repeatedly). That's absurd;
> avoiding a reorg is trivially achieved via running "invalidateblock", or
> via pool software examining block headers, or via a patch along the lines
> of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
> here's a sketch of such a patch:
> 
> https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f

If lot=true has majority of hashpower it wins.
Having to overtake them repeatedly assumes a 50/50 split one chain taking
over the other repeatedly.
In which case OP's statement that the LOT=True chain is safer holds true.

> 
> > For 2 weeks, users with LOT=False would not have a usable network.
> 
> That's also ridiculous FUD.

In context thats not FUD and most certainly it's not ridiculous FUD.
Assuming a 50/50 hashpower split the Lot=False chain has no stability
till difficulty re-adjustment. 

> 
> If it were true, it would mean the activation mechanism was not
> acceptable, as non-upgraded nodes would also not have a usable network
> for the same reason.
> 
> Fortunately, it's not true.

In the split scenario non-upgraded nodes don't play, right? aka they're part of
both chains.

> 
> More generally, if miners are willing to lose significant amounts of
> money mining orphan blocks, they can do that at any time. If they're
> not inclined to do so, it's incredibly straightforward for them to avoid
> doing so, whatever a minority of other miners might do.

Except that when incentives change so does miner behavior.

> 
> > The overall risk is maximally reduced by LOT=True being the only deployed 
> > parameter, and any introduction of LOT=False only increases risk 
> > probability 
> > and severity.
> 
> LOT=false is the default behaviour of everything single piece of node
> software out there. That behaviour doesn't need to be introduced, it's
> already universal.

You are again making an "in principle" statement.

> 
> Cheers,
> aj

If you meant this to be a rebuttal, it is not.
It is mostly blanket statements and attacking OP.

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

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

[Keagan McClelland via bitcoin-dev]

> Personally I consider this counterproductive. Apart from the complexity,
it’s not healthy. And the chain grows linearly with storage cost falling
exponentially, leading to a straightforward conclusion.

The motivation for this change is not to encourage full archival nodes to
prune, but to make it possible for pruned nodes to beef up what kind of
archive they retain. Personally I think using the falling storage costs as
a means of providing access to more users is more important than using it
to justify requiring higher node requirements.

> Something to consider adding to this proposal is to keep the idea of
pruning - i.e. retain a sequentially uninterrupted number of the most
recent blocks.
>
> Many users do not run a node for entirely altruistic reasons - they do
so, at least in part, because it allows them to use their wallets
privately. Without this ability, I think the number of users willing to run
their node in this configuration might be reduced.
>
> Another related thought is to have a decreasing density over blocks over
time as you go backwards towards genesis, in order for the data density of
the storage to match the actual usage of the network, in which (I would
imagine) more recent blocks are more heavily requested than early ones.

Per my above comments, this change is actually capitalizing primarily upon
those who wish to do it for more altruistic reasons. Furthermore, doing
linear block scans when you need to query blocks that you don't keep does
not leak privacy details in the same way that bloom filters do. You are not
signaling to the peer that there is something specific in that block that
you care about, because you don't actually know. You are signalling only
that you do not have that block right now, which from the other parts of
the design you are already leaking. In light of this, I don't think that it
is necessary for the blocks to be in sequential sets at all. If there is no
requirement on them being sequential, uniform randomness will take care of
the density problem automatically.

Keagan


On Mon, Mar 1, 2021 at 4:20 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> > Only headers need to be downloaded sequentially so downloading relevant
> blocks from one node is totally possible with gaps in between.
>
>
>
> In fact this is exactly how libbitcoin v4 works. We download and store
> blocks in parallel. In the case of a restart block gaps are repopulated.
> Given that headers are validated, we go after the most responsive nodes.
> Based on standard deviation, we drop the slowest peers and rebalance load
> to new/empty channels. We make ordered but not necessarily sequential
> requests. There is no distinction between “initial” block download, a
> restart, or a single or few blocks at the top. So it’s referred to as
> continuous parallel block download.
>
>
>
> But we don’t prune. Personally I consider this counterproductive. Apart
> from the complexity, it’s not healthy. And the chain grows linearly with
> storage cost falling exponentially, leading to a straightforward conclusion.
>
>
>
> e
> ___
> 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 for new "disabletx" p2p message

[John Newbery via bitcoin-dev]

Hi Suhas,

Thank you for this proposal. I agree with your aims, but I think a new
P2P message isn't necessary to achieve them.

# Motivation

There are two distinct (but interacting) motivations:

1. Allow a node to accept more incoming connections which will only be
   used for block propagation (no transaction relay or addr gossip),
   while minimizing resource requirements.

2. Prevent `addr` gossip messages from being sent to peers which will
   'black hole' those addrs (i.e. not relay them further).

These motivations interact because if we simply increase the number of
block-relay-only connections that nodes make without making any
allowance for the fact those connections won't gossip addr records, then
we'll increase the number of addr black holes and worsen addr gossip.

# Using fRelay=false to signal no transaction relay.

`fRelay` is an optional field in the `version` message. There are three
BIPs concerned with `fRelay`:

- BIP 37[1] introduced the `fRelay` field to indicate to the recipient
  that they must not relay transactions over the connection until a
  `filteradd` message has been received.

- BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
  how widely this BIP has been adopted by implementations.

- BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that
  bloom filters are served by this node. According to this BIP, "If a
  node does not support bloom filters but receives a "filterload",
  "filteradd", or "filterclear" message from a peer the node should
  disconnect that peer immediately."

Within Bitcoin Core:

- PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom
  filters.

- Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_
  include the `fRelay` flag in `version` messages that it sends. Bitcoin
  Core will tolerate the `fRelay` field being present or absent in any
  `version` message that it receives[6].

- PR 6579[7] (merged in August 2015) implemented BIP 111. From that
  point on, a Bitcoin Core node would disconnect peers that sent it
  `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the
  peer's version was >= 70011. In PR 7708[8] (merged in March 2016) this
  was extended to disconnect any peer that sends a `filter*` message,
  regardless of its version (in general, a 'polite disconnect' for any
  peer that requests an unsupported service is probably the best
  behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
  filters was disabled by default, due to potential denial-of-service
  attacks being possible against nodes which serve bloom filters on
  public connections.

- PR 6993[10] (merged in November 2015) started reusing the `fRelay`
  field for the new `-blocksonly` mode. If Bitcoin Core is started with
  `-blocksonly` configured, then it includes `fRelay=false` in all of
  the `version` messages it sends. In PR 15759[11] (merged  in September
  2019), this usage of `fRelay` to permanently disable tx relay was
  extended for use by the new block-relay only connection type.

The net effect is that `fRelay` is already being used to indicate that
transactions should not be relayed over a connection. In the motivation
for your BIP, you write:

> The low-bandwidth / minimal-resource nature of these connections is
> currently known only by the initiator of the connection; this is
> because the transaction relay field in the version message is not a
> permanent setting for the lifetime of the connection.  Consequently, a
> node receiving an inbound connection with transaction relay disabled
> cannot distinguish between a peer that will never enable transaction
> relay (as described in BIP 37) and one that will...

However, as AJ points out in his response [12], the Bitcoin Core node
_does_ know whether transaction relay can be supported as soon as the
`version` message is received:

> [...] you either set m_tx_relay->fRelayTxes to true via the VERSION
> message (either explicitly or by not setting fRelay), or you enable it
> later with FILTERLOAD or FILTERCLEAR, both of which will cause a
> disconnect if bloom filters aren't supported. Bloom filter support is
> (optionally?) indicated via a service bit (BIP 111), so you could
> assume you know whether they're supported as soon as you receive the
> VERSION line.

i.e. if Bitcoin Core node is running under normal configuration with
bloom filters disabled for public connections (which is both the default
setting and highly recommended due to DoS concerns), then as soon as it
receives a `version` message with `fRelay=false`, it can be sure that
there will never be any transaction relay with that peer. If the peer
later tries to enable transaction relay by sending a `filterload`
message, then the node will disconnect that peer immediately.

In summary, we can continue using the `fRelay` field to indicate that
no transaction relay can happen for the entire lifetime of the
connection.  Bitcoin Core can postpone allocating resources for

[bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel

[Michael Folkson via bitcoin-dev]

It is approximately 8 months since Steve Lee formally kicked off the
Taproot activation discussion by setting up the ##taproot-activation
IRC channel. Obviously there was discussion that considerably predates
that but that was the first recognition that there needed to be a
focus towards a solution rather than endless circular debates.

Eight months on it appears there are some who think there is a
philosopher’s stone still out there that will garner 100 percent
consensus and contain zero chain split risk in the worst case
scenario. A philosopher’s stone that us mere mortals have failed to
find in these 8 months.

While I would be delighted if this philosopher’s stone is found (and
all are free to continue looking) I think it is prudent at this point
to step away from the circular arguments and build on the progress we
have made in these last 8 months. We have effectively achieved
overwhelming consensus on the activation mechanism (BIP 8) and all of
the parameters apart from one (lockinontimeout or LOT). Again I’d like
to thank the people who have put hours of work into getting to this
point. It is thankless work and it is probably the last thing any of
us want to be doing.

At this point it is unclear whether Bitcoin Core will be able to
release any activation code whatsoever due to disagreement logjams.
Personally I hope they do but again it is prudent to prepare for the
scenario where Core is unable to. Hence I and others have assessed
that our energies are better spent working on a community release
implementing LOT=true in a similar spirit to 2017’s UASF effort. I say
similar as this time there really is no need for any antagonism.
Approximately 90 percent of mining pools (taprootactivation.com) have
declared support and there is overwhelming community consensus to
activate Taproot. In the absence of a Core release with activation
code I hope and expect all users (including miners) to consider
supporting this UASF release and consider running it to activate
Taproot.

TL;DR Tomorrow (Tuesday) we are holding a kick off meeting for this
UASF (LOT=true) effort on the ##uasf IRC channel at 19:00 UTC. Please
consider attending and supporting this effort to get Taproot
activated. It would be great to get users from the 2017 effort
involved in addition to recent Taproot proponents from all parts of
our community. The future of Bitcoin’s scalability and privacy depends
on, as it always has, on you the user.

-- 
Michael Folkson
Email: michaelfolk...@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] In defense of a configurable LOT if LOT=false is released

[Jeremy via bitcoin-dev]

The short script* below could function as a cross platform (need only have
python 2 and curl) way to make a LOT=False function like a LOT=true node.
This sort of script was mentioned recently in the ##taproot-activation IRC
channel.

It is unclear to me with this sort of script what happens if a LOT=false
but running this script announces a to-be-marked-bad block to a similar
peer that has already marked that block invalid. It could lead to nodes
partitioning themselves from one another, but I am uncertain of the
particulars of invalidate block's relationship to DoS rules.

Therefore it may be a harm reduction, should core release with LOT=false,
to have opt-in configurability natively. Configurability is superior to a
situation where, near to the timeout with LOT=true seeming more likely,
users unable to switch binaries reach for such a convenience script.

The counterargument would be that running a script is still a hoop to jump
through more difficult than a config flag and we don't want user's choosing
consensus rules via config flags. However, it seems more in the spirit of
user choice to make the core release suitable for either preference.

*completely untested, unverified, never even run mind you -- obviously needs
review before actually running it

1 import sys, json, subprocess
 2 from time import sleep
 3 LOTHEIGHT=60
 4 LOTSTOP= LOTHEIGHT + 2016
 5 FORK="taproot"
 6 credential="blah:blah"
 7 host = "http://127.0.0.1:8332;
 8 contenttype ='content-type:text/plain;'
 9 def make_command(command, args):
10 return json.dumps({"jsonrpc": "1.0",
11 "id":"curltext",
12 "method": command,
13 "params": args})
14 def call(command, args):
15 res = subprocess.run("curl", ["--user", credential,
"--data-binary", make_command(command, args), "-H", contenttype, host])
16 return res.stdout
17
18 should_sleep = False
19 while True:
20 if should_sleep: sleep(10)
21 should_sleep = True
22 try:
23 data = json.load(call("getblockchaininfo", []))
24 possible = True
25 if data['blocks']  >= LOTHEIGHT and data['blocks'] <
LOTSTOP:
26 if not
data['softforks'][FORK]['statistics']['possible']:
27 call("invalidateblock", [data["bestblockhash"]])
28 should_sleep = False
29 except: pass
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] LOT=False is dangerous and shouldn't be used

[yanmaani--- via bitcoin-dev]

How about a compromise?

With LOT=false, taproot will be activated if at least 95% of the miners 
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners 
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the 
miners vote yes?


If you want the 'emergency cancel' feature without binding yourself to 
it, couldn't you have some middle-of-the-road solution? "Taproot will be 
enabled if miner support ever goes above 95%, or on flag day if miner 
support is >20% then". That would prevent obstreperous miners from doing 
too much damage, while still hopefully making it possible to bail out of 
a disaster.


On 2021-03-01 15:06, Anthony Towns via bitcoin-dev wrote:
On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via bitcoin-dev 
wrote:
As we saw in 2017 with BIP 9, coordinating activation by miner signal 
alone,
despite its potential benefits, also leaves open the door to a miner 
veto.


To the contrary, we saw in 2017 that miners could *not* successfully
veto a BIP 9 activation. It was certainly more effort and risk than was
desirable to override the attempted veto, but the attempt at vetoing
nevertheless failed.


It wouldn't be much different than adding back the inflation bug
(CVE-2018-17144) and trusting miners not to exploit it.


That is ridiculous FUD.


With LOT=False in the picture, however, things can get messy:


LOT=false is always in the picture if we are talking about a soft-fork:
the defining feature of a soft-fork is that old node software continues
to work, and old node software will be entirely indifferent to whether
activation is signalled or not.


some users will
enforce Taproot(eg) (those running LOT=True), while others will not 
(those

with LOT=False)


If you are following bip8 with lockinontimeout=false, you will enforce
taproot rules if activation occurs, you will simply not reject blocks 
if

activation does not occur.


Users with LOT=True will still get all the safety thereof,
but those with LOT=False will (in the event of miners deciding to 
produce a
chain split) face an unreliable chain, being replaced by the LOT=True 
chain

every time it overtakes the LOT=False chain in work.


This assumes anyone mining the chain where taproot does not activate is
not able to avoid a reorg, despite having majority hashpower (as 
implied
by the lot=true chain having to overtake them repeatedly). That's 
absurd;
avoiding a reorg is trivially achieved via running "invalidateblock", 
or
via pool software examining block headers, or via a patch along the 
lines

of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
here's a sketch of such a patch:

https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f


For 2 weeks, users with LOT=False would not have a usable network.


That's also ridiculous FUD.

If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable network
for the same reason.

Fortunately, it's not true.

More generally, if miners are willing to lose significant amounts of
money mining orphan blocks, they can do that at any time. If they're
not inclined to do so, it's incredibly straightforward for them to 
avoid

doing so, whatever a minority of other miners might do.

The overall risk is maximally reduced by LOT=True being the only 
deployed
parameter, and any introduction of LOT=False only increases risk 
probability

and severity.


LOT=false is the default behaviour of everything single piece of node
software out there. That behaviour doesn't need to be introduced, it's
already universal.

Cheers,
aj

___
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] LOT=False is dangerous and shouldn't be used

[Anthony Towns via bitcoin-dev]

On Sun, Feb 28, 2021 at 07:33:30PM +, Luke Dashjr via bitcoin-dev wrote:
> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone, 
> despite its potential benefits, also leaves open the door to a miner veto. 

To the contrary, we saw in 2017 that miners could *not* successfully
veto a BIP 9 activation. It was certainly more effort and risk than was
desirable to override the attempted veto, but the attempt at vetoing
nevertheless failed.

> It wouldn't be much different than adding back the inflation bug 
> (CVE-2018-17144) and trusting miners not to exploit it.

That is ridiculous FUD.

> With LOT=False in the picture, however, things can get messy:

LOT=false is always in the picture if we are talking about a soft-fork:
the defining feature of a soft-fork is that old node software continues
to work, and old node software will be entirely indifferent to whether
activation is signalled or not.

> some users will 
> enforce Taproot(eg) (those running LOT=True), while others will not (those 
> with LOT=False)

If you are following bip8 with lockinontimeout=false, you will enforce
taproot rules if activation occurs, you will simply not reject blocks if
activation does not occur.

> Users with LOT=True will still get all the safety thereof, 
> but those with LOT=False will (in the event of miners deciding to produce a 
> chain split) face an unreliable chain, being replaced by the LOT=True chain 
> every time it overtakes the LOT=False chain in work.

This assumes anyone mining the chain where taproot does not activate is
not able to avoid a reorg, despite having majority hashpower (as implied
by the lot=true chain having to overtake them repeatedly). That's absurd;
avoiding a reorg is trivially achieved via running "invalidateblock", or
via pool software examining block headers, or via a patch along the lines
of MUST_SIGNAL enforcement, but doing the opposite. For concreteness,
here's a sketch of such a patch:

https://github.com/ajtowns/bitcoin/commit/f195688bd1eff3780f200e7a049e23b30ca4fe2f

> For 2 weeks, users with LOT=False would not have a usable network.

That's also ridiculous FUD.

If it were true, it would mean the activation mechanism was not
acceptable, as non-upgraded nodes would also not have a usable network
for the same reason.

Fortunately, it's not true.

More generally, if miners are willing to lose significant amounts of
money mining orphan blocks, they can do that at any time. If they're
not inclined to do so, it's incredibly straightforward for them to avoid
doing so, whatever a minority of other miners might do.

> The overall risk is maximally reduced by LOT=True being the only deployed 
> parameter, and any introduction of LOT=False only increases risk probability 
> and severity.

LOT=false is the default behaviour of everything single piece of node
software out there. That behaviour doesn't need to be introduced, it's
already universal.

Cheers,
aj

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

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

[Anthony Towns via bitcoin-dev]

On Sat, Feb 27, 2021 at 05:55:00PM +, Luke Dashjr via bitcoin-dev wrote:

[on the topic of non-signalled activation; ie "it doesn't matter what
miners do or signal, the rules are active as of height X"]

> This has the same problems BIP149 did: since there is no signalling, it is 
> ambiguous whether the softfork has activated at all. Both anti-SF and pro-SF 
> nodes will remain on the same chain, with conflicting perceptions of the 
> rules, and resolution (if ever) will be chaotic. Absent resolution, however, 
> there is a strong incentive not to rely on the rules, and thus it may never 
> get used, and therefore also never resolved.

I think this might be a bit abstract, and less convincing than it might
otherwise be.

To give a more explicit hypothetical: imagine that instead of making it
impossible to use an optimisation when mining (as segwit did to ASICBoost,
for which a patent had been applied for), a future soft-fork made it
possible/easier to use some mining optimisation, and further that the
optimisation is already patented, and that the patent wasn't widely known,
and the owners of the patent have put everyone that they can under NDA.

Obviously mining optimisations are great for manufacturers -- it means
a new generation of hardware is more efficient, which means miners
want to upgrade to it; but patented mining optimisations are bad for
decentralisation, because the're no competition in who can sell the new
generation of mining hardware, so the patent holder is able to choose
who is able to mine, and because miners control transaction selection,
they could insist that the only people they'll sell to must censor
transactions, and attempt to render miners that don't censor
uncompetitive.

So the incentives there are:

 - the patent holder wants the soft-fork to activate ASAP, and
   does not want to reveal the patent until after it's permanently
   locked in

 - people who want decentralisation/competition and know about the
   patent want to stop the soft-fork from activation, or hard-fork it
   out after it's activated; but they can't talk about the patent because
   of NDA (or other bribes/threats intended to keep them silent)

Suppose further that the anti-patent folks either directly control 20%
of hashpower, or are otherwise able to block the easy consensus path,
and that the patent holder isn't able to get over 50% of hashpower to
commit to orphaning non-signalling blocks to ensure early activation
despite that. (Or, alternatively, that an approach like Matt suggests in
"Straight Flag Day (Height)" is used, and there is no early-activation
via hashpower supermajority option)

So under that scenario you reach the timeout, but without activation
occurring. You also don't have any "reasonable, directed objection":
everyone who could provide a reasonable objection is under NDA.

What's the scenario look like if you say "signalling doesn't matter,
the software enforces the consensus rules"?

I think it'll be obvious there'll be two sets of software out there and
supported and following a single chain; one set that enforces the new
rules, and one set that doesn't, just as we had Bitcoin Unlimited back
in the day. For at least a while, it will be safe to do spends protected
by the new rules, because one set of nodes will enforce them, and any
miners running the other software won't want see it in their mempool,
and won't want to risk manually mining non-compliant transactions in case
it turns out they're in the minority -- just as Bitcoin Unlimited miners
didn't actually attempt to mine big blocks on mainnet back in the day.

So for a while, we have two divergent sets of maintained node software
following the same chain, with advocates of both claiming that they're the
majority. Some people will beleive the people claiming the new rules are
safe, and commit funds to them, and as those funds are demonstrably not
stolen, the number of people thinking it's safe will gradually increase
-- presumably the new rules have some benefit other than to the patent
holder, after all.

Eventually the patent gets revealed, though, just as covert ASICBoost
did. Either NDA's expire, something violates them, someone rediscovers
or reverse-engineers the idea, or the patent holder decides it's time
to start either suing competitors or advertising.

What happens at that point? We have two sets of node software that both
claim to have been in the majority, and one of which is clearly better
for decentralisation.

But if we all just switch to that two things happen: we allow miners to
steal the funds that users entrusted to the new rules, and anyone who
was enforcing the new rules but is not following the day-to-day drama
has a hard-fork event and can no longer follow the main chain until the
find new software to run.

Alternatively, do we all switch to software that protects users funds
and avoids hard-fork events, even though that software is bad for
decentralisation, and do we do that precisely when the people 

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Erik Aronesty via bitcoin-dev]

> Today users should start cooperating again to continue using the
> optimal strategy.

the "gradual" method of reducing the % of miners required for lock-in
as time goes on seems to encode this optimal strategy.

On Thu, Feb 25, 2021 at 6:43 AM Ariel Luaces via bitcoin-dev
 wrote:
>
> On Tue, Feb 23, 2021 at 12:09 PM Keagan McClelland via bitcoin-dev
>  wrote:
> >
> > If social consensus is what drives technical consensus and not the other 
> > way around it seems as if there cannot exist a valid (rational?) reason to 
> > oppose Taproot itself, and then by extension with the arguments laid out 
> > above, LOT=true seems to be the logical conclusion of all of this, even if 
> > Core ships LOT=false at the outset.
> >
> > Where am I wrong here?
> >
> > Keagan
> >
> > On Mon, Feb 22, 2021 at 7:11 PM Jeremy via bitcoin-dev 
> >  wrote:
> >>
> >> Personally, I think with either plan the ultimate risk of forking is low 
> >> given probability to activate before timeout, so we should just pick 
> >> something and move on, accepting that we aren't setting a precedent by 
> >> which all future forks should abide. Given my understanding of the 
> >> tradeoffs, I believe that the safest choice is LOT=true, but I wouldn't 
> >> move to hold back a plan of LOT=false (but would probably take mitigative 
> >> steps on community advocacy if it looks like there is non majority but non 
> >> negligible LOT=true uptake).
> >>
> >> Cheers,
> >>
> >> Jeremy
> >>
> >>
> >> ___
> >> 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
>
> To favor LOT=true because it seems like the inevitable result is like
> playing the prisoner's dilemma and never cooperating instead of using
> the most optimal strategy which is tit-for-tat (cooperating at first
> and then cheating once for every time your counterparty cheats).
>
> During segwit users started by cooperating (BIP9, or "LOT=false"),
> then a minority of
> miners didn't cooperate (small veto but remember the majority of
> miners cooperated), then users stopped cooperating in response (UASF),
> then miners
> reverted to cooperating (MASF while intolerant miners forked off).
> Today users should start cooperating again to continue using the
> optimal strategy.
>
> Cheers
> Ariel Lorenzo-Luaces
> ___
> 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] A design for Probabilistic Partial Pruning

[Eric Voskuil via bitcoin-dev]

On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:

 

> Only headers need to be downloaded sequentially so downloading relevant 
> blocks from one node is totally possible with gaps in between.

 

In fact this is exactly how libbitcoin v4 works. We download and store blocks 
in parallel. In the case of a restart block gaps are repopulated. Given that 
headers are validated, we go after the most responsive nodes. Based on standard 
deviation, we drop the slowest peers and rebalance load to new/empty channels. 
We make ordered but not necessarily sequential requests. There is no 
distinction between “initial” block download, a restart, or a single or few 
blocks at the top. So it’s referred to as continuous parallel block download.

 

But we don’t prune. Personally I consider this counterproductive. Apart from 
the complexity, it’s not healthy. And the chain grows linearly with storage 
cost falling exponentially, leading to a straightforward conclusion.

 

e

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

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

[Craig Raw via bitcoin-dev]

Something to consider adding to this proposal is to keep the idea of
pruning - i.e. retain a sequentially uninterrupted number of the most
recent blocks.

Many users do not run a node for entirely altruistic reasons - they do so,
at least in part, because it allows them to use their wallets privately.
Without this ability, I think the number of users willing to run their node
in this configuration might be reduced.

Another related thought is to have a decreasing density over blocks over
time as you go backwards towards genesis, in order for the data density of
the storage to match the actual usage of the network, in which (I would
imagine) more recent blocks are more heavily requested than early ones.

Craig

On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Only headers need to be downloaded sequentially so downloading relevant
> blocks
> from one node is totally possible with gaps in between.
>
> On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote:
> > Hi Keagan,
> >
> > I had a very similar idea. The only difference being for the node to
> decide on
> > a range of blocks to keep beforehand, rather than making the decision
> > block-by-block like you suggest.
> >
> > I felt the other nodes would be better served by ranges due to the
> sequential
> > nature of IBD. Perhaps this would be computationally lighter as well.
> >
> > I also encourage you to read Ryosuke Abe's paper [1] that proposes a DHT
> > scheme to solve this same problem.
> >
> > Cheers,
> > Igor
> >
> > [1] https://arxiv.org/abs/1902.02174
> >
> > On Fri, 26 Feb 2021 at 21:57, Keagan McClelland via bitcoin-dev
> >  > > wrote:
> >
> > Hi all,
> >
> > I've been thinking for quite some time about the problem of pruned
> nodes
> > and ongoing storage costs for full nodes. One of the things that
> strikes
> > me as odd is that we only really have two settings.
> >
> > A. Prune everything except the most recent blocks, down to the cache
> size
> > B. Keep everything since genesis
> >
> > From my observations and conversations with various folks in the
> > community, they would like to be able to run a "partially" pruned
> node to
> > help bear the load of bootstrapping other nodes and helping with data
> > redundancy in the network, but would prefer to not dedicate hundreds
> of
> > Gigabytes of storage space to the cause.
> >
> > This led me to the idea that a node could randomly prune some of the
> > blocks from history if it passed some predicate. A rough sketch of
> this
> > would look as follows.
> >
> > 1. At node startup, it would generate a random seed, this would be
> unique
> > to the node but not necessary that it be cryptographically secure.
> > 2. In the node configuration it would also carry a "threshold"
> expressed
> > as some percentage of blocks it wanted to keep.
> > 3. As IBD occurs, based off of the threshold, the block hash, and the
> > node's unique seed, the node would either decide to prune the data
> or keep
> > it. The uniqueness of the node's hash should ensure that no block is
> > systematically overrepresented in the set of nodes choosing this
> storage
> > scheme.
> > 4. Once the node's IBD is complete it would advertise this as a peer
> > service, advertising its seed and threshold, so that nodes could
> > deterministically deduce which of its peers had which blocks.
> >
> > The goals are to increase data redundancy in a way that more
> uniformly
> > shares the load across nodes, alleviating some of the pressure of
> full
> > archive nodes on the IBD problem. I am working on a draft BIP for
> this
> > proposal but figured I would submit it as a high level idea in case
> anyone
> > had any feedback on the initial design before I go into specification
> > levels of detail.
> >
> > If you have thoughts on
> >
> > A. The protocol design itself
> > B. The barriers to put this kind of functionality into Core
> >
> > I would love to hear from you,
> >
> > Cheers,
> > Keagan
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> > --
> > *Igor Cota*
> > Codex Apertus d.o.o.
> >
> > ___
> > 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