Took a brief look at the last minute bug that forced a .0.1 release, and it would have been caught by:
2) Testing on mainnet/making mainnet and testnet code paths identical even in the binary.
#2 isn't easy to achieve, esp in Bitcoin Core, but it's IMO a good principal. https://t.co/gh1LKnIXSU
A new wallet flag avoid_reuse has been added (default off). When enabled, a wallet will distinguish between used and unused addresses, and default to not use the former in coin selection. When setting this flag on an existing wallet, rescanning the blockchain is required to correctly mark previously used destinations. Together with “avoid partial spends” (added in Bitcoin Core v0.17.0), this can eliminate a serious privacy issue where a malicious user can track spends by sending small payments to a previously-paid address that would then be included with unrelated inputs in future payments.
I'm wondering whether the wallet is smart enough to notice that different addresses can have the same public key. For instance, an attacker could send dust to the bech32 version of every p2sh-wrapped segwit address which has been spent from (and to the p2sh-wrapped segwit address version of every bech32 address which has been spent from). If the wallet doesn't notice that the bech32 address and the p2sh-wrapped segwit addresses have the same public keys it wouldn't mark the dust utxo as address reuse.
Edit: I posted an issue in the Bitcoin github about this: https://github.com/bitcoin/bitcoin/issues/17605 - it turns out the wallet doesn't notice when a pubkey is used to create a same-but-different address, and so the chain-analysis people won't be slowed down by this "avoid_reuse" feature at all.
Bitcoin Core, as a matter of policy, does not rely on any trusted third parties. As there is no way to obtain exchange rate information without those, it's unfortunately not possible to give a USD balance.
If all we use bitcoin for is to replace international wires (way more expensive and time consuming with banks) it's doing what I need it to do.
If you need it to do something else then go value something else.
The Bitcoin stack can already handle effectively infinite transactions per second, but in order to preserve and strengthen its fundamental value proposition, the Bitcoin community prioritizes validability over throughput on the base layer. This is borne of an understanding of what it is that makes Bitcoin special and valuable.
We do not want to sacrifice ability to check blocks on commodity hardware (run full node in the background without big issue) for some speed.
For speed people have thousands of tools, and Bitcoin can do it too in form of Lightning Network.
If only another coin, which has been around for a very long time, represented by honest and serious people who care more about Bitcoin than this coin, was faster but still secure enough, and close enough to Bitcoin's source code, existed...
Oh wait, there is one, Litecoin, but somehow Bitcoin so-called maximalists like to spit on it and label one of the only (if not the only) serious altcoins out there a "shitcoin". Litecoin for example helped a lot for the testing and implementation of Segwit. It was on Litecoin blockchain that there was a 1 million dollar bounty for any hackerwho would be able to crack it. Maybe without that, segwit would have never been seen as secure enough?
Litecoin for everyday transactions. Bitcoin for wealth storage. This is the most logical approach for now as long as the Lightning Network is not further improved. If you wish to disagree, please do so, but then please give arguments. I've never seen real arguments except "litecoin is a copy and paste of bitcoin" which is not really an argument against it to be fair.
From the release notes:
> If you want to compile Bitcoin Core with BIP70 support in the GUI, you can pass `--enable-bip70` to `./configure`
So you can still pay Bitpay invoices, you just need to compile Core differently (or ask someone competent to do it for you if you need help doing it).
Correct, users of 0.19 can no longer pay using BitPay's BIP70 implementation. Note that BitPay themselves were planning to make their implementation of BIP70 incompatible with Bitcoin Core and their CEO (Steven Pair) recommended Bitcoin Core drop its BIP70 implementation:
> While we currently do allow a transaction to be sent only over p2p (and not posted back to the server), this is not something we want to support forever. We allow it for temporary backward compatibility (on the Bitcoin chain only) with a number of wallets that don't fully implement BIP70. **I agree that bitcoind should remove BIP70.** (emphasis added, [source](https://github.com/bitcoin/bitcoin/pull/14451#issuecomment-431496319))
Because i heard Bitpay would be affected by 0.19. This debitpay thing is annoying and many shops/sites (i think those who wanna stay "official") still use bitpay only... so i hoped bitpay was forced to change stuff.
Bitpay is dead and people should not use it in any way.
[Bitpay is the fucking enemy of Bitcoin, wake the fuck up people! They are the main supporters and promoters of S2X attack against Bitcoin!](https://redd.it/74wejs)
Why might that be? If your thought is related to bech32 addresses, the answer would be no. Release 0.19.0.1 generates bech32 addresses as the default, but you can choose to generate another type of address in the GUI, or you can specify -addresstype in the boitcoin.conf file if you want your implementation to have some other default.
Wow, catch-up syncing now goes much faster - coincidence, or due to this change?
By default, Bitcoin Core will now make two additional outbound connections that are exclusively used for block-relay. No transactions or addr messages will be processed on these connections. These connections are designed to add little additional memory or bandwidth resource requirements but should make some partitioning attacks more difficult to carry out.
Sample size of one 24-hour catch-up may not be representative of course, would be interesting to hear others' experience.
> Thanks that was great, but didn't really answer my question
Well, for real - I guess they might name Bitcoin as 1.0 when it is realy reaaaly good and excellent for mass use in every way. That is my guess.
For anyone wondering what happened to Release 0.19.0, just after 0.19.0 was tagged a bug was found and it was decided to delay the release until the fix could be tested and incorporated. The new version is labelled 0.19.0.1.