From 650daa75a6475bbf2a073b96fdd227eec48b7902 Mon Sep 17 00:00:00 2001 From: jrakibi Date: Mon, 18 Aug 2025 14:17:42 +0100 Subject: [PATCH 1/3] trigger build --- .../a-bevy-of-block-size-proposals-bip100-bip102-and-more.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md index fc66a8e..49a89c9 100644 --- a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md +++ b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md @@ -103,7 +103,7 @@ A: No. I want to maintain backwards-compatibility if at all possible. Not all wa Q: Do you think increasing on-chain bandwidth will interfere with the value of bitcoin? -A: It will increase the value of bitcoin. It will signal that we are willing to enhance the system. +A: It will increase the value of bitcoin. It will signal that we are willing to enhance the system bip100 From 57a67f08702aa6122ab9154b81e8e9ce82293c02 Mon Sep 17 00:00:00 2001 From: jrakibi Date: Mon, 18 Aug 2025 15:49:45 +0100 Subject: [PATCH 2/3] trigger build --- .../a-bevy-of-block-size-proposals-bip100-bip102-and-more.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md index 49a89c9..44358b6 100644 --- a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md +++ b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md @@ -95,7 +95,7 @@ A: That's why we're leaning towards flag day with non-binding miner voting. It's Q: Would you break SPV clients in a hard-fork? -A: Potentially, if that needs to be done. +A: Potentially, if that needs to be done Q: Would you deliberately do it? From ee2ea4f6e6c5e14e29302f6c72ac708cd2e31bf3 Mon Sep 17 00:00:00 2001 From: jrakibi Date: Mon, 18 Aug 2025 16:36:51 +0100 Subject: [PATCH 3/3] trigger build 3 --- .../a-bevy-of-block-size-proposals-bip100-bip102-and-more.md | 1 + 1 file changed, 1 insertion(+) diff --git a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md index 44358b6..bc7dd54 100644 --- a/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md +++ b/scalingbitcoin/hong-kong-2015/a-bevy-of-block-size-proposals-bip100-bip102-and-more.md @@ -91,6 +91,7 @@ A: That's reasonable. You are going to be rolling out a patch, which says 6 mont Q: In one of those slides, you said 75% levels, so 750 out of 1000 blocks. That was bip101. What is your optimal choice for that? Is it 75% 80% 90%? + A: That's why we're leaning towards flag day with non-binding miner voting. It's to avoid picking a specific number. You want to have a clear majority of hashpower on the fork that users prefer. I don't want to pick a number. I don't have a number. It's just a supermajority of the hashpower. That's step 2. But step 1 is the users agreeing by running the new software. Q: Would you break SPV clients in a hard-fork?