export SIGNER="hebasto"
export GUIX_SIGS_REPO="/home/hebasto/guix.sigs"
export DETACHED_SIGS_REPO="/home/hebasto/bitcoin-detached-sigs"
--- a/src/script/interpreter.cpp | |
+++ b/src/script/interpreter.cpp | |
@@ -504,6 +504,14 @@ bool EvalScript(std::vector<std::vector<unsigned char> >& stack, const CScript& | |
return set_error(serror, SCRIPT_ERR_MINIMALDATA); | |
} | |
stack.push_back(vchPushValue); | |
+ if ((flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) && opcode == OP_FALSE) { | |
+ auto pc_tmp = pc; | |
+ opcodetype next_opcode; | |
+ valtype dummy_data; |
What do you think of just generalising feature negotiation so it's comprehensive?
Suppose "VERSION 80000+" specifies:
initiator sends a VERSION message responder sends a VERSION message
after having both send and received a VERSION message specifying a version >= 80000, both nodes must specify FEATURE support by
This is not an exhaustive list. This is mostly from looking at PRs or IRC meetings. Any mistakes are my own.
- [MERGED] 0.19: Add txids with non-standard inputs to reject filter #19681
- [MERGED] 0.20: Add txids with non-standard inputs to reject filter #19680
- 0.20: Backport wtxid relay #19606
- bitcoin/bitcoin#19569 (comment) (to be opened by jnewbery) with #19610
- [MERGED] Transaction overhaul (#19184 - sipa) (Review by sdaftuar, ajtowns, ariard)
Project: https://github.com/bitcoin/bitcoin/projects/15
A user plugs in their hardware wallet and creates a new wallet. It automatigically detects the device and imports the keys:
The user can verify a receive address on their device with just a click:
The Bitcoin P2P network is fundamental to the strength of Bitcoin itself. However, as it stands we know very little about the peers we connect to. This makes it difficult to have data-driven conversations about making changes to the P2P protocol. Additionally, we connect and disconnect from peers in a naïve fashion, simply because we are lacking in the information we would need to make better decisions.
We need more data.
To remedy this problem, I propose the following extensions to Bitcoin Core's per-peer logging abilities.
- Message Capture
jonatack: | |
U2FsdGVkX18XDMZfMBvtOjbdzP9FglsfNI1IkmfUsmjhUJc1x8YghQL9jjBRA22G | |
LMC9KLt7L/7sFJfVm7rEW+yeoWXL6S/K1NWdOvoy6O5pfQF2NMltA6Mzb1q4huVM | |
x+BW7DNEBF9nDknRwFiAD079WOvLyLbWvPHk1FJp9hW5qRgU/629/XQ0pQX1eqdf | |
OLVS5AGuTxBgc8AE6tp4i+x7mC037bTBuI9c6X4mngfYpfu9PkSK+DzQx6pXqgTh | |
uvEprusb8PzsWmUSNbFN4umr9bAbUeezWig7mWNbIEbpBR/jD4YSeTXaBXfP2fvB | |
BJU/38DWll06Ki46CE/tkTMSjuUg2E5T2hTDppSAC9j6OuhLtt8+ZKLtt2X2tCm8 | |
vdERbOHFdZu/Npsj6vLg8SWsKoen5LvGbRWfuXTWEa9FlTu9t7PMbcc5Zbk/5DKr | |
yY3jW/4u/bWuZlYca3U8dSZEjGZod+paht4acXoJRUy58RWl3Lg72FZXCuzw7Ph2 |
Consider a system on the heterogeneous computing ARM big.LITTLE
architecture, e.g., ODROID-HC1 powered by Samsung Exynos 5 Octa 5422.
As the Bitcoin Core is a highly computationally intensive application, the usage of ultra-low power and slower LITTLE
cores could lead to a substantial lagging and errors (see: bitcoin/bitcoin#16008).
Also there are report about other flaws in LITTLE
cores design.
The suggested solution of the described problem is to force the CPU core affinity of the Bitcoin Core processes. On Linux this could be achieved by the [taskset
](https://linux.die.net/man/1/t
wallet/db.c -> table schemas + migrations | |
wallet/wallet.c -> SQL statements | |
table: outputs | |
question: what are the values for 'status' | |
output_state_available= 0, | |
output_state_reserved = 1, | |
output_state_spent = 2, | |
/* Output has been included in a signed funding tx that we've shared | |
* with a peer; not yet mempooled. Eligible for burning */ |