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

2021-03-01 Thread 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 private

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

2021-03-01 Thread 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 lib

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

2021-03-01 Thread 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

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

2021-03-01 Thread 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 w

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

2021-03-01 Thread 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* success

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

2021-03-01 Thread 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 'e

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

2021-03-01 Thread 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 LO

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

2021-03-01 Thread 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

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

2021-03-01 Thread 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 (

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

2021-03-01 Thread 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 i

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

2021-03-01 Thread 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 t

Re: [bitcoin-dev] Taproot NACK

2021-03-01 Thread 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,

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

2021-03-01 Thread 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 rel

Re: [bitcoin-dev] Taproot NACK

2021-03-01 Thread 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,

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

2021-03-01 Thread 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-d