luke-jr

--- 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;

luke-jr

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, "",
+                {

luke-jr

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
 

luke-jr

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

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

[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 

luke-jr

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

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)));
+
+    {

luke-jr

	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

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>