xmready, why do you keep posting that image?
Excited to see how many nodes are running 0.21.0
Topic: Taproot proposal - page 18. (Read 11253 times)
Excited to see how many nodes are running 0.21.0
xmready, why do you keep posting that image?
I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance.
1. BIP8 uses blockheight, as opposed to timestamp. This is so that the fork can still go ahead if:
- an activation is at the "locked-in" stage (i.e. block signalling is above the threshold)
- ...but the _overall_ hashrate is falling (i.e. the necessary 2016 blocks of lock-in won't occur before the timestamp when the 12 month activation period expires)
BIP8 solves that problem by not using 12 timestamped months, but 12 months of blocks (which comes with a different trade-off: it's unlikely to be 12 actual months, and for the taproot softfork, will likely be faster, due to continuing hashrate growth). The 12 months part is just a convention, it could've been more or less (and may be in future), I think 12 was chosen simply because the segwit and CSV softforks also aloted 12 months.
2. BIP8 has a "lock-in on timeout" parameter
This means that the fork activates regardless of miner signalling level at the point the activation period expires (12 months in this case).
The continuing discussion on activation for the taproot fork revolves around whether Bitcoin 0.21.1 should be released with auto lock-in (or "LOT") set as true or false, but also whether LOT can be set as user configurable (like an enforcing version of people putting "uasf" in their user agent string during segwit activation). IMO, 0.21.1 should be shipped with LOT=true, but I understand the arguments against also. At the least, it should be possible to set in the config file.
Here’s a good Bitcoin Magazine explanation about BIP9 and BIP8, the differences, and why BIP8 COULD be better for soft fork protocol upgrades. It’s written by respected Bitcoiner, Aaron Van Wirdum.
Read it, before believing the trolls who say that it’s the miners that enforce the rules.
https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next
BIP 8 was an early alternative for BIP 9, proposed by BIP 148 author Shaolinfry and Bitcoin Knots and Bitcoin Core contributor Luke-jr. It initially resembled BIP 9, but with one crucial difference: instead of the upgrade failing after a year of insufficient hash power support, it would do the exact opposite and activate the soft fork at that point in time. Similar to a flag day, all upgraded nodes would from then on start enforcing the new rules. Miners who’d still have failed to upgrade would risk mining blocks that upgraded miners and users would reject.
The main idea behind BIP 8 is that — assuming of course that users upgrade — miners can’t block the soft fork and therefore can’t use this leverage to their benefit. They can speed activation up and help coordinate a smooth protocol upgrade, but the upgrade will eventually happen even if they don’t activate it themselves.
Read it, before believing the trolls who say that it’s the miners that enforce the rules.
https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next
Quote
BIP 8 was an early alternative for BIP 9, proposed by BIP 148 author Shaolinfry and Bitcoin Knots and Bitcoin Core contributor Luke-jr. It initially resembled BIP 9, but with one crucial difference: instead of the upgrade failing after a year of insufficient hash power support, it would do the exact opposite and activate the soft fork at that point in time. Similar to a flag day, all upgraded nodes would from then on start enforcing the new rules. Miners who’d still have failed to upgrade would risk mining blocks that upgraded miners and users would reject.
The main idea behind BIP 8 is that — assuming of course that users upgrade — miners can’t block the soft fork and therefore can’t use this leverage to their benefit. They can speed activation up and help coordinate a smooth protocol upgrade, but the upgrade will eventually happen even if they don’t activate it themselves.
Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.
BIP8 is for activating changes by block height, so that the new rules apply only after a specific block has been mined. It is better than using BIP9 which also activates some delay after a specific block number but the version bit for it expires and can be reused some time, usually a year, after its activation where they assume everyone has moved to that fork.
The problem related to segwit's activation were that there were a bunch of miners/nodes who did not follow through this activation so this bit might have expired and be used for something else without everyone fully following it. There were special BIPs made for segwit activation just to address this problem (BIP91).
Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
Quote
The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.
This part was the most interesting and I do hope we will not have to see such a detrimental scenario. Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.
During 2017, miner-signalling for activation was used as a political tool to hostage/stop the network from doing an upgrade that the community wanted. BIP8/UASF is a method of activation wherein the full nodes decide, not the miners. The miners simply follow.
Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
Quote
The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.
This part was the most interesting and I do hope we will not have to see such a detrimental scenario. Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.
Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
Quote
The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.
This part was the most interesting and I do hope we will not have to see such a detrimental scenario. 
Quote
This is the first in a series of posts about about covenants in Bitcoin using Taproot and a (hypothetical) CAT opcode. Historically, and as has been implemented in Elements, CAT has been considered to be a covenant opcode only in conjunction with CHECKSIGFROMSTACK. In this post, which will be much mathier than later ones, we'll talk about how to abuse the math of Schnorr signatures to emulate the functionality of CHECKSIGFROMSTACK.
https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298Quote
are these sighash-templating covenants powerful enough to actually do anything, given the consensus limits of Script?
After reading that article I remember a discussion I read on that specific matter on the bitcoin dev mailing list that can be found herehttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016996.html
Would be interested to read a few comments on this by some of you guys.
Quote
This is the first in a series of posts about about covenants in Bitcoin using Taproot and a (hypothetical) CAT opcode. Historically, and as has been implemented in Elements, CAT has been considered to be a covenant opcode only in conjunction with CHECKSIGFROMSTACK. In this post, which will be much mathier than later ones, we'll talk about how to abuse the math of Schnorr signatures to emulate the functionality of CHECKSIGFROMSTACK.
https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 
But there's another way. We could encourage them to use wallet/software which generate Taproot address by default, they could enjoy the benefit without even realizing it.
Running wallet software on their daily driver is a solution, but risky. This type of user runs a major hacking risk by storing large amounts on an online wallet capable of generating new addresses. For an example, lets use the parents of a friend I help with computer stuff. They have been phished multiple times, not learning from their mistakes. Even though they understand Bitcoin is freedom, banks are bad, and custodial risk is real, it doesn't make them better at computers or evaluating attack vectors.
They could use a linux USB to generate new wallets/addresses offline and have a watch only wallet on their daily driver. But they would need someone to help them every time there is an upgrade that requires user action. Doing it on their own is as unreasonable as asking them not to get hacked or figuring out a hardware wallet.
This is the biggest problem I see with protocol upgrades that require user action. Non power users will either fall behind without consistent help from someone, or their coins will fall subject to hacker/custodial risk.
I agree with you, but this problem apply to technological change/development in general.
Maybe this is unsolvable or maybe in the future it will be easier for them to generate new addresses from their online computer without risk.
Risk always exist, but it could be mitigated if future OS is designed with very strict security. Android already take first step by enforce sandboxing and permission.
But there's another way. We could encourage them to use wallet/software which generate Taproot address by default, they could enjoy the benefit without even realizing it.
Running wallet software on their daily driver is a solution, but risky. This type of user runs a major hacking risk by storing large amounts on an online wallet capable of generating new addresses. For an example, lets use the parents of a friend I help with computer stuff. They have been phished multiple times, not learning from their mistakes. Even though they understand Bitcoin is freedom, banks are bad, and custodial risk is real, it doesn't make them better at computers or evaluating attack vectors.
They could use a linux USB to generate new wallets/addresses offline and have a watch only wallet on their daily driver. But they would need someone to help them every time there is an upgrade that requires user action. Doing it on their own is as unreasonable as asking them not to get hacked or figuring out a hardware wallet.
This is the biggest problem I see with protocol upgrades that require user action. Non power users will either fall behind without consistent help from someone, or their coins will fall subject to hacker/custodial risk. Maybe this is unsolvable or maybe in the future it will be easier for them to generate new addresses from their online computer without risk. Am I missing something?
0.21.0 it's at 8th place (about 2.9% of nodes):
2.9% of nodes listed on bitnodes.io which they claim are "reachable nodes" not all full nodes. Also a lot of their 0.20 nodes are fake.According to https://luke.dashjr.org/programs/bitcoin/files/charts/software.html there are 6776 nodes running 0.21 out of 83327 core nodes (8.1%). Although it doesn't provide any IP list so it can not be validated.
There is also an increase in number of existing nodes (near 2x rise) in January from around 46k to 85k which seems interesting.
if they want to send an amount that's bigger than the largest unspent utxo, then it's more expensive to do so, because they need more than one tx input to do so. and there are also the obvious privacy issues (which harm everyone's privacy to a lesser extent).
If they are sweeping the entire balance from the exchange with no utxo, would this be irrelevant?
Ideally, custodial services (e.g. exchanges) would permit BIP79 transactions for client withdrawals (and also use them for client deposits). This would save transaction fees, as well as defeat passive analysis of the blockchain to track utxo ownership. A few (not many) custodial services support BIP79 (aka P2EP/Payjoin), hopefully more will in future. Wallet support is also lacking, so it's a chicken & egg problem
Even if the paper withdrawal address doesn't change, as long as it's segwit, can these types of users benefit from BIP79 transactions without taproot+schnorr? I don't see it as a requirement on the pull request.
the incentives of such a user (who presumably is only interested in the value of their BTC savings)
I think these users can share an interest in value alongside an interest in BTC being good for the world. They can remember banks=bad and freedom=good, but not protocol details. They can remember how to use a hot wallet on their phone, but not how to re-setup their cold storage.
Are there significant downsides to these users using the same address every time they buy from an exchange since the exchange already has their KYC info? Hopefully this last question isn't too off topic here.
one significant downside should perfectly align with the incentives of such a user (who presumably is only interested in the value of their BTC savings): if they want to send an amount that's bigger than the largest unspent utxo, then it's more expensive to do so, because they need more than one tx input to do so. and there are also the obvious privacy issues (which harm everyone's privacy to a lesser extent).
Ideally, custodial services (e.g. exchanges) would permit BIP79 transactions for client withdrawals (and also use them for client deposits). This would save transaction fees, as well as defeat passive analysis of the blockchain to track utxo ownership. A few (not many) custodial services support BIP79 (aka P2EP/Payjoin), hopefully more will in future. Wallet support is also lacking, so it's a chicken & egg problem
For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.
After your wallet supports it, new addresses will use it. Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).
Unrelated, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html
After your wallet supports it, new addresses will use it. Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).
Unrelated, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html
Appreciate the insight, thank you.
For power users of Bitcoin I understand that creating a new address for every txn is common sense, thus new upgrades will apply to them. Can you expand on how these upgrades affect people who required assistance making a paper wallet and only use one address as a "savings account"? These types of users don't follow or understand fully the protocol and it's relevant upgrades. All they know is they have a QR code to load the address whenever they buy and a private key or seed under lock and key. Even if you explain protocol to them, they tend to forget. If I'm interpreting your response correctly, these users won't benefit from upgrades like this when they spend their coin unless they transfer their savings to a new address first.
Are there significant downsides to these users using the same address every time they buy from an exchange since the exchange already has their KYC info? Hopefully this last question isn't too off topic here.
When Taproot+Schnorr becomes activated, will we need to create new addresses to benefit from the privacy? Will old addresses that broadcast transactions benefit? Will using the features provided by the upgrade be automatic or will we have to specify when creating transactions?
For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.After your wallet supports it, new addresses will use it. Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).
Unrelated, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html
When Taproot+Schnorr becomes activated, will we need to create new addresses to benefit from the privacy? Will old addresses that broadcast transactions benefit? Will using the features provided by the upgrade be automatic or will we have to specify when creating transactions?
Am i missing your point? 0.20.1 is older version and doesn't have schnorr/taproot code. 0.21.0 have schnorr/taproot code, but don't have activation signal/logic.
oops, my fault, I read "News: Latest Bitcoin Core release: 0.20.1 [Torrent]" in the header and I tough it was the most recent version.
0.21.0 it's at 8th place (about 2.9% of nodes):
Jump to: