note: after #10387 (or some way to identify a node as full but pruned) we should stop accepting requests to fast-relay compact blocks pre-validation from non-full nodes. Its a drastic reduction in their security model and unlikely to be worth the tiny change in relay time. I'm especially concerned that some of the spv clients are going to implement compact blocks and then someone who had set up bitcoin core as a border/firewall node
bitcoin core supports non-segwit capable mining software; it just won't include any segwit txn for them
gmaxwell: I have been running the following for a few days, after reading your tip to sdaftuar about listing segwit transactions on top of the mempool: while sleep 10; do bitcoin-cli getblocktemplate | jq '.transactions | . | select(.hash != .txid) | .txid' >> swtxlog; done
Hello. I was testing the development of some ideas using the BitcoinCore wallet and the CLI's commands, and I came across the move command. Unfortunately the Docs states that "move will be removed in a later version of Bitcoin Core. " Does another command fulfils its duty? I've read the documentation on the official webpage and came out with empty hands. I don't want to develop an architecture around a command that will be e
morcos: things that work are what people do, this is the lesson from history -- in bitcoin but also in every internet protocol. If we make it work we need to be ready to support it.
We could take a position that we'll always do dual p2sh embedded and native (at least for the forseeable future) in parallel... but that will still be a risk for every wallet that isn't us, and for bitcoin core users with explicitly imported keys, when something thinks it can convert.
instagibbs: yeah thanks, i'm fine with you tweeting whatever you want obviously, just not from Bitcoin Core Fee Bot. Sounds official.
if it's a good idea that survives rigorous peer review we should implement it in a Bitcoin Core tool or bitcoind and then we can tweet out the result
that is never something we would add to Bitcoin Core without a whole lot of complication to determine that that is a fee rate that would have legitimately been selected for the last block
[bitcoin] maaku opened pull request #11196: Switch memory_cleanse implementation to BoringSSL's to ensure memory clearing even with -lto (master...fix-memory-clense) https://github.com/bitcoin/bitcoin/pull/11196
not sure if this is offtopic for the channel. is there a discussion anywhere surrounding why bitcoin uses bdb 4.8? it seems to me that the only real concern with using 5.x is that users would not then be able to downgrade wallet software, but how likely/useful is that anyway (and also, providing recompiled binaries for older releases with 5.x seems possible now?)
[bitcoin] jnewbery closed pull request #10882: [Do not merge] Stop advancing best block and shutdown node if keypool drops below critical threshold (master...keypool_topup) https://github.com/bitcoin/bitcoin/pull/10882
[bitcoin] practicalswift opened pull request #11193: Terminate string *pszExePath after readlink and before passing to operator << (master...null-terminate-after-readlink) https://github.com/bitcoin/bitcoin/pull/11193
Can someone who understands twitter better explain to me what blocking someone does there... what would blocking someone on the bitcoin core account accomplish?
15,999 stars on bitcoin repo, so close to 16k lol
#bitcoin or bitcoin.stackexchange.com