Skip to content

Instantly share code, notes, and snippets.

View pr24539-suggestion.patch
diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
index d82e596e60e..396c18c5bf8 100644
--- a/src/rpc/blockchain.cpp
+++ b/src/rpc/blockchain.cpp
@@ -1416,6 +1416,11 @@ static RPCHelpMan gettxspendingprevout()
},
},
},
+ {"options", RPCArg::Type::OBJ, RPCArg::Optional::OMITTED_NAMED_ARG, "",
+ {
View bitcoin-pr23607-fix.patch
diff --git a/configure.ac b/configure.ac
index f969e707293..1c33cbc3a38 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1372,14 +1372,24 @@ if test x$build_bitcoin_cli$build_bitcoind$bitcoin_enable_qt$use_tests$use_bench
if test x$TARGET_OS != xwindows; then
PKG_CHECK_MODULES([EVENT_PTHREADS], [libevent_pthreads >= 2.0.21],, [AC_MSG_ERROR([libevent_pthreads version 2.0.21 or greater not found.])])
fi
-fi
View 20211104-transifex-announcement.md

With v22.0, we changed a few parts referencing a number of gigabytes, with the assumption that anything referring to "0 GB", "1 GB", "2 GB", "10 GB", "1000 GB", and so on are always translated the same in every language. Specifically, the strings affected at this time are "%n GB of free space available", "(of %n GB needed)", and "(%n GB needed for full chain)"

Reviewing actual translations prior to the change, however, it appears that may not be the case. In some languages, "1 GB" was preferred to use a non-digit number (eg, "one", "un", or such), and others appear to use different words around the amount. Not being familiar with any of these languages, I am not sure if these were intentional differences, or translator mistakes.

Please contact me if you are aware of any language(s) that would benefit from being able to translate these or similar messages differently based on the number of GB referenced. Even if there is an inferior "count-neutral" translation possible, if being able to have it count-specifi

View 20211104-transifex-announcement.txt
With v22.0, we changed a few parts referencing a number of gigabytes, with the assumption that anything referring to "0 GB", "1 GB", "2 GB", "10 GB", "1000 GB", and so on are always translated the same in every language. Specifically, the strings affected at this time are "%n GB of free space available", "(of %n GB needed)", and "(%n GB needed for full chain)"
Reviewing actual translations prior to the change, however, it appears that may not be the case. In some languages, "1 GB" was preferred to use a non-digit number (eg, "one", "un", or such), and others appear to use different words around the amount. Not being familiar with any of these languages, I am not sure if these were intentional differences, or translator mistakes.
Please contact me if you are aware of any language(s) that would benefit from being able to translate these or similar messages differently based on the number of GB referenced. Even if there is an inferior "count-neutral" translation possible, if being able to have it count-specifi
@luke-jr
luke-jr / pluggable-softforks.txt
Created Aug 8, 2017
Making Bitcoin softforks pluggable
View pluggable-softforks.txt
[bitcoin-dev] Making soft forks pluggable
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011487.html
[Friday, October 09, 2015] [8:50:48 AM] <Luke-Jr> CodeShark: btw, I was thinking of the softfork plugin thing a bit ago also, so sounds good to me :P
[Friday, October 09, 2015] [8:50:57 AM] <CodeShark> :)
[Friday, October 09, 2015] [8:51:14 AM] <Luke-Jr> maybe harder than it seems though in practice
[Friday, October 09, 2015] [8:52:04 AM] <CodeShark> I have some ideas for how to do it...but if we're going to be doing a bunch of refactors after 0.12 is released, I figure this is a good area on which to focus :)
[Friday, October 09, 2015] [8:53:24 AM] <CodeShark> we don't want to have to backport each individual soft fork perpetually...and it might actually be easier to backport the plugin thing
[Friday, October 09, 2015] [8:53:57 AM] <aj> be easier to backport pluggable soft forks once the plugin thing exists too, presumably
[Friday, October 09, 2015] [8:54:14 AM] <CodeShark> yes, of
View size_statistics.py
import sys
sizes = []
count = 0
for line in sys.stdin:
fields = line.split()
tx_count = int(fields[3])
if tx_count < 16:
continue
@luke-jr
luke-jr / segwit_equiv_hack.diff
Created May 5, 2017
Include segwit equivalent max size in RPC getblock
View segwit_equiv_hack.diff
diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
index a1cb89c..63fe757 100644
--- a/src/rpc/blockchain.cpp
+++ b/src/rpc/blockchain.cpp
@@ -102,6 +102,26 @@ UniValue blockToJSON(const CBlock& block, const CBlockIndex* blockindex, bool tx
result.push_back(Pair("strippedsize", (int)::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS)));
result.push_back(Pair("size", (int)::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION)));
result.push_back(Pair("weight", (int)::GetBlockWeight(block)));
+
+ {
View ljr 0.12 feature plans
5872 subdir_incl_compat ccb99ec
2241 sys_leveldb 588aaa1
5416 sys_libsecp256k1 799461d
5618 separate_utils e49de13
7339 opt_libevent
7349 sys_univalue_opt
~7142 travis_qt4_nolibevent
BRANDING:
7192 single_prodname
? svgs
@luke-jr
luke-jr / bip-n2
Created Apr 24, 2015
*Dead* BIP idea: Growing Nonce2 in Header
View bip-n2
DISCLAIMER: I do not intend to submit this as a BIP, nor do I consider it a good idea at this time. Please note hardforks are not something miners have any particular say in, despite any implication in this dead writeup. I am posting the gist here only because someone wanted to see it.
<pre>
BIP: ?
Title: Growing Nonce2 in Header
Author: Luke Dashjr <luke_bip-n2@dashjr.org>
Status: Draft
Type: Standards Track
Created: 2015-02-12
</pre>
View release_notes.md