pull down to refresh
I thought that libbitcoin needed more storage than Bitcoin Core?
Covenants being used to create a whitelist-coin was a big concern when the covenant debate restarted a few years ago. After it was debated for months, the general sentiment settled on the concern being unsubstantiated. About to go to bed, I’m gonna try to write up an example for a covenant tomorrow after the Optech Recap.
In Bitcoin, the recipient picks the address (i.e., the output script) that they expect to be paid to. Usage of a covenant construction would be self-selected, it generally cannot be imposed by the sender. If the sender unilaterally decides to send funds to a different output script than indicated by the receiver, the receiver would likely not even notice the payment, and has grounds to not honor the payment.
I can’t help but feel that you are interpreting this situation unnecessarily fatalistic. In contrast to frequent talking points among BIP 110 supporters, essentially all Bitcoiners believe Bitcoin is for money. I firmly believe that Bitcoin will continue on that journey after BIP 110 fails to garner significant interest tomorrow.
There is one notable caveat to this scenario as well, however. If the BIP110 chain were to overtake the original chain in length later on (due to miners moving to the BIP110 chain), all nodes — Core and Knots alike — would accept the BIP110 chain as the only chain. The original chain would in this case be discarded, or wiped out.
Nit: wipeout occurs of course when the total work of one chaintip exceeds the other, not when it is longer.
Your poll should distinguish between Knots and BIP110 clients.
According to bitnod.es:
About 18.3% of listening nodes run Knots 29.3.
12.2% of listening nodes are on the latest Knots release.
14.6% of listening nodes advertise the NODE_KNOTS_BIP110_UASF peer service.
It seems to me that:
- Not all Knots nodes support BIP110.
- Some of the BIP110 nodes are on old versions which may predate the February upgrade that added the P2A consensus rule.
Anyway, your poll conflates Knots and RDTS nodes. Those overlap but their distinction matters in this context.
Summary of Situation as of this TimeSummary of Situation as of this Time
ACTION RECOMMENDATION: PLEASE CAREFULLY MOVE FUNDS STORED ON COLDCARD WALLETS CREATED FROM DEVICE-GENERATED ENTROPY TO UNAFFECTED WALLETS ASAP.
Any funds on a COLDCARD Mk3 using a firmware from version 4.0.1 (March 2021) to 4.1.9 (latest version until July 30th), where the entropy was only generated by the device, should be considered compromised. COLDCARD Mk4, Mk5, and Q are affected by the same issue to a lesser degree. Wallets generated by those devices are at risk of theft. Wallets created with externally generated entropy with at least 50 dice throws should not be exposed. Wallets that pair the device entropy with a passphrase are only as secure as the passphrase. If you used a weak passphrase (less than 25 random characters or fewer than seven BIP39 words) and did not provide external entropy (at least fifty dice throws), your funds are at risk.
Coinkite has released firmware updates for COLDCARD Mk3, Mk4, Mk5, and Q. Wallets generated with the new firmware should be secure. Updating to the new firmware does not make affected wallets secure. Only new wallets generated with the new firmware are unaffected. Coinkite put out a security advisory. The security advisory has been updated to include more devices, more details about the issue, and migration advice.
Block security researchers reports that the COLDCARD Mk2 is affected the same way as the Mk3.
Anyone with access to a frontier AI model is capable of reproducing the attack. Especially if you have funds on a COLDCARD single-sig wallet created with wallet-generated entropy, please carefully move your funds to an unaffected wallet ASAP. Single-sig wallets with a weak passphrase, or multisig wallets that can be spent by a quorum of COLDCARD wallets or composed only of COLDCARD wallets created with device-generated entropy should be considered at risk and funds should also be moved.
The point of the fork is to punish Bitcoin Core developers for not listening to the pitchfork mob. Don’t mind them cutting off their own noses to spite their faces.
Given that any transactions submitted to either chaintip will be valid for both chaintips at first, I expect that their mempool will be growing substantially and their minimum block feerates will be significantly higher than those of the standard chaintip. Which would mean that any transactions sent to compete for inclusion on the BIP 110 chaintip would also pay exorbitant fees on the standard chaintip. Probably most BIP 110 proponents will hold back transaction activity and wait for the dust to settle. I wouldn’t be surprised if support for the minority chaintip folds in less than 24h.
Not sure about spam transactions. Yes, most should be priced out, but there might be some attempts to get data into the first signaling block just for sport.
Either way, I expect a lot of people to be watching closely and discussing what’s happening on Saturday.
They are still faking confidence and claiming that there is no opposition. Unfortunately, they cannot publicly talk about all the glaring issues you listed, while they pretend that the entire Bitcoin network will go along with BIP 110.
Car bloat has made cars more dangerous to accident opponents and pedestrians. The increased height of hoods has drastically reduced visibility in front of those cars. Higher and heavier cars are more dangerous to smaller cars, and the higher hoods make accidents much more dangerous for pedestrians, because they are not just swept off their legs onto the hood but hit in their torso and run over.