[bitcoin] NicolasDorier opened pull request #10202: [Wallet] FundRawTransaction can fund a transaction with preset inputs found in the CoinView (master...fundrawtransaction) https://github.com/bitcoin/bitcoin/pull/10202
gmaxwell, i think i started this line of thinking in #bitcoin, my version was only slightly different, where the coins become redeemable by anyone (i.e. probably a miner) if SW should fail to be active
[bitcoin] TheBlueMatt opened pull request #10179: Give CValidationInterface Support for calling notifications on the CScheduler Thread (master...2017-01-wallet-cache-inmempool-3) https://github.com/bitcoin/bitcoin/pull/10179
I rebased https://github.com/bitcoin/bitcoin/pull/9728 I would be happy if Hardware wallets people can review. I ate my own dog food, and it seems this PR would really help helping bitcoin core wore seemlessly with hardware wallet and normal wallet without code modification.
patience is a virtue well-honed by participation in the bitcoin world :-)
An UASF would need support from a supermajority of exchanges and payment processors, and preferably as many merchants as possible dealing with bitcoin directly.
It's really for #bitcoin discussion not #bitcoin-core-dev
but perhaps this particular thing should stay in #bitcoin, sorry guys
jcorgan: "FairHeader" has gained a following already in #bitcoin. "forward compatible" might stir up big blockers.
In the future, you don't want some regulator charging in requesting feature changes to disable a "covert" bitcoin feature
I think we need to be very careful with how we brand any changes happening. The reason we would like to ban it is *NOT* because it is covert. It is because it is incomaptible with Bitcoin's incentive systems (e.g., transaction selection to maximiuze fees) and it interferes with protocol development.
let's move the discussion to #bitcoin ?
well it's fine to mention it. I'm sure we want the BIP implemented in bitcoin core?
if it shouldn't be used for the good of bitcoin, your BIP is exactly what they should adopt too
saying they don't use it 'for the sake of bitcoin' can't be jived with saying it's a valuable optimization though
Yes, the proposal is specifically designed to have minimal impact and only interfear with covert asicboost and only to the extent that it gums up protocol extensions (like segwit, utxo commitments, bloom filter commitments, etc.) But in their response they claim that I am trying to harm bitcoin by blocking a valuable optimization. :-/
E.g. they helpfully confim their hardware implements asicboost, they loudly say they have the right to use it. They claim that they haven't used it on mainnet 'for the good of bitcoin' (how that jives with their claims that they'll make all the empty blocks they want because the protocol allows it, I dunno)
i think i've learned how to force a tag in the bitcoin repo, though. it seems to be a sure thing as soon as i leave for a few days :)
The third option is that bitcoin will fail due to it, which I don't think we'll accept as a community. But eventually could be a fair while.
Though there are clear reasons for wanting such optimizations disabled, Bitcoin resists contentious changes, and I think the miners would be able to put up enough of a fight to prevent the change