Pieter Wuille [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-17 to 2023-04-10
💬 Posted a total of 500 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15, ANN, coredump backtrace, RFC, BIP proposal, softfork proposal, BIP, bitcoin-dev, BIP Draft, BIP Proposal, Lightning-dev, Opt-in full-RBF
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r

Profile Code

nprofile1qqs9evsm7htlyk5ag6rewy7t6vjr8w7ppeqwlqf68s50uu647jv9f4sltdvs8

Author Public Key

npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r

Show more details

Last Notes

2023-09-07 11:52:36

- reply

📅 Original date posted:2023-09-04
🗒️ Summary of this message: Version 0.4.0 of libsecp256k1 has been released, featuring the addition of the ellswift module for ElligatorSwift encoding. See release notes for details.
📝 Original message:
Hello,
Today we'd like to announce the release of version 0.4.0 of libsecp256k1:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.4.0
The highlight is the addition of the ellswift module, which implements ElligatorSwift encoding. For the full release notes of 0.4.0 (and earlier releases) see:
https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md
--
Pieter

2023-06-09 12:44:35

- reply

📅 Original date posted:2015-09-25
📝 Original message:
On Sep 25, 2015 3:09 AM, "Rusty Russell" wrote:
> >> You can squeze some more bytes out of you want:
> >> 1) Signature should be 64 bytes (never DER encode).
> >> 2) Pubkey can be hashed bitcoin-address style, and recovered from sig.
> >
> > You can recover the pubkey from the hash and the sig? Why are we
putting the pubkey in the scriptSig then? ;)
>
> Because crypto is hard :(
>
> TBH I only learned a few months ago that you can do this.
>
> It helps if you have the (two-bit) recovery id, but you can brute force
> it AFAICT. You then check if the pubkey matches the hash you're given.
You can indeed do public key recovery om ECDSA, and you can brute force the
recovery id. In all non-pathological cases, the recovery id will be 0 or 1;
only one in about 2^128 randomly generated signatures need 2 or 3.
I don't have much context here, but is there a need for this to be ECDSA?
If not, the EC-Schnorr scheme in libsecp256k1 produces 64-byte
non-malleable signatures that support pubkey recovery without an additional
recovery id, and are compatible with the same private/public keys. The
scheme is certainly non-standard and experimental at this point, but it's
an instance of a well researched mechanism.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150925/02de7137/attachment.html>

2023-06-07 23:16:42

- reply

📅 Original date posted:2022-11-12
📝 Original message:Another idea...
On Thursday, November 10th, 2022 at 4:23 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
>
> > From what I understand we'll have about 35 message types on the network
> > with the addition of BIP324. 256 possible IDs sounds like plenty room to
> > grow, but perhaps we can be a bit more conservative:
> >
> > We could use the first bit to signal a 2-byte message ID. That allows us
> > to express 128 IDs with 1 byte, but if we need more, we get a total of
> > 2^15 IDs across 2 bytes.
>
> Yeah, effectively treating the first 1 or 2 bytes as a simple variable
> length integer is a nice way of increasing the space at low cost.
The above would really result in having two separate variable-length encodings:
* First byte 1-12 to signify length of alphabetic command
* Otherwise first bit to signify length of short command
I think we can just merge the two and have a single variable-length command structure that can be used for both: command encodings are 1 to 12 bytes, each byte's top bit indicating whether another byte follows (the top bit of byte 11 has no special meaning).
This means:
* Every alphabetic command of L characters becomes L bytes.
* 102 non-alphabetic 1-byte commands can be assigned.
* 15708 non-alphabetic 2-byte commands can be assigned.
* etc
So this gives a uniform space which commands can be assigned from, and there is no strict need for thinking of the short-binary and long-alphabetic commands as distinct. In v2, some short ones would be treated as aliases for old long-alphabetic ones. But new commands could also just be introduced as short ones only (even in v1).
WDYT?
Cheers,
--
Pieter

2023-06-07 23:16:41

- reply

📅 Original date posted:2022-11-10
📝 Original message:Hi,
Thanks for the comments so far. I think these are all reasonable ideas.
Comments inline below.
On Thursday, November 3rd, 2022 at 1:53 PM, Murch wrote:
> From what I understand we'll have about 35 message types on the network
> with the addition of BIP324. 256 possible IDs sounds like plenty room to
> grow, but perhaps we can be a bit more conservative:
>
> We could use the first bit to signal a 2-byte message ID. That allows us
> to express 128 IDs with 1 byte, but if we need more, we get a total of
> 2^15 IDs across 2 bytes.
Yeah, effectively treating the first 1 or 2 bytes as a simple variable
length integer is a nice way of increasing the space at low cost.
This also doesn't need to be decided now. The initial approach could just
be avoiding allocating bytes in the 128-255 range until the need for more
space arises. If and when that is the case, the choice could be to:
* Just continue treating the first byte as the command.
* Start treating the first upper bit as a sign that another command byte
follows.
* Switch to some form of explicit signalling (option 3 is my earlier
mail).
On Thursday, November 3rd, 2022 at 6:26 PM, Jonas Schnelli wrote:
> There would be an alternative to preserve more 1 byte IDs on the cost
> of a (much) smaller 2 byte ID space: Reserve the short ID 0xFF as an
> indication for a 2 bytes short ID (additional 256 short IDs with 2 bytes).
I don't think this is needed, because we arguably already have that! If the
first byte is 0x01, then 1 more command byte follows in the current BIP324
draft. That mechanism is designed for alphabetic 1-character commands, but
nothing prevents it from also being used for other things (by using a
non-alphabetic byte there).
> Maybe the BIP should state that only frequent sent messages should reserve
> a short ID, though, the BIP itself assigns short IDs to all(?) message
> types (including low frequent messages like SENDHEADERS).
>
> Maybe exclude message types that expected to be only sent once from
> assigning a short ID?
I think that makes sense. Especially in combination with the idea avoiding
bytes with the upper bit set there is a bit more pressure on the 1-byte
space. Rarely-sent or at-most-once-sent commands don't really provide much
benefit. I'd suggest scrapping from the list:
* Version messages: version, verack
* Negotiation messages: sendaddrv2, sendheaders, sendcmpct, wtxidrelay
* Rarely-sent messages: mempool
I'm not sure to what extent filteradd/filterload/filterclear/merkleblock
are still actually used; perhaps they could be removed too?
On Monday, November 7th, 2022 at 10:20 PM, Anthony Towns wrote:
> I guess I think it would make sense to not start using a novel 1-byte
> message unless you've done something to introduce that message first;
> whether that's via approach (3) ("I'm going to use 0xE9 to mean pkgtxns")
> or via a multibyte feature support message ("I sent sendaddrv3 as a
> 10-byte message, that implies 0xA3 means addrv3 from now on").
That's fair, but I don't think it matters too much for allocation purposes;
protocol designs should still not assign overlapping values, unless the
protocols are known to never be used simultaneously?
Unless... the assignment works like "whenever the sendaddrv3 is sent, the
next available byte in range 48..127 gets allocated for addrv3". That means
no explicit mapping is needed, as long as the total number of messages from
simultaneously-active extensions isn't too large.
> I do still think it'd be better to recommend against reserving a byte for
> one-shot messages, and not do it for existing one-shot messages though.
Agree.
FWIW, if anyone was wondering about how much is actually saved by having
1-byte commands vs 12-byte commands, I've gathered statistics from two nodes
(one with many inbound connections, one only outbound) for two weeks. This is
obviously very dependent on network topology and local implementation choices,
but it may still give an idea:
* Outbound-only node:
* Around 4.5% of sent bytes are bytes 2-12 of the command.
* Sent 979.98 MiB in total.
* Outbound and inbound node:
* Around 1.6% of sent bytes are bytes 2-12 of the command.
* Sent 124.14 GiB in total.
Cheers,
--
Pieter

2023-06-07 23:15:02

- reply

📅 Original date posted:2022-10-26
📝 Original message:Hi all,
On Saturday, October 8th, 2022 at 8:59 AM, Dhruv M <dhruv at bip324.com> wrote:
> We have refreshed the proposal for BIP324, a new bitcoin P2P protocol
> featuring opportunistic encryption, a mild bandwidth reduction, and the
> ability
> to negotiate upgrades before exchanging application messages. We'd like
> to invite community members to review the BIP[1] and the related Bitcoin
> Core
> code[2].
One open question we have regarding BIP324's design is how to deal with the
coordination of assigning the message type IDs.
For context, the current BIP324 draft introduces a notion of 1-byte message
type IDs, which take the place of the 12-byte command strings (in a backward
compatible way; it's still possible to send full strings). This offers a
mild bandwidth reduction (3 bytes per message overall), especially since many
messages on the network are fairly small.
However, it obviously raises the question of how the mapping table between the
1-byte IDs and the commands they represent should be maintained:
1. The most straightforward solution is using the BIP process as-is: let BIP324
introduce a fixed initial table, and future BIPs which introduce new
messages can introduce new mapping entries for it. In theory, this is no
worse than the current coordination difficulty about command strings, but
in practice the risk of collisions due to competing proposals is of course
significantly larger with 1-byte IDs vs. 12-byte strings.
2. An alternative approach is not using 1-byte IDs but slightly longer ones;
for example 3-byte IDs, each consisting of a 2-byte BIP number and a 1-byte
message index introduced by that BIP, at the cost of a smaller bandwidth
improvement. This significantly reduces collision risks, but doesn't remove
the coordination process concerns entirely (e.g. revisions changing what a
BIP introduces need to be taken into account and probably still mean BIPs
need to explicitly list which assignments they introduce).
3. Yet another possibility is not having a fixed table at all, and negotiate
the mapping dynamically. E.g. either side could send a message at
connection time with an explicit table of entries "when I send byte X, I
mean command Y".
4. Lastly, the whole feature could just be dropped from BIP324 (sticking with
command strings), and left for a follow-up (or independent) protocol
improvement. Since arguably this is purely an application-layer concern and
not a transport-layer one, it could even be added as an optional feature to
the (pre-BIP324) protocol today. That would however very likely mean that
BIP324 if adopted as-is isn't actually an (albeit small) bandwidth
reduction compared to today, and forego a possibility to fix a fairly
gratuitous inefficiency in the protocol from day one.
Our idea is to start out with approach (1), with a mapping table effectively
managed by the BIP process directly, but if and when collisions become a
concern (maybe due to many parallel proposals, maybe because the number of
messages just grows too big), switch to approach (3), possibly even
differentially (the sent mappings are just additions/overwrites of the
BIP-defined table mappings, rather than a full mapping).
That said, we're not all that convinced this is the best approach, and feel
this more a community/process question than a technical one, so it would be
good to see more opinions on the topic.
Cheers,
--
Dhruv, Pieter, Tim

2023-06-07 23:12:19

- reply

📅 Original date posted:2022-07-28
📝 Original message:------- Original Message -------
On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Essentially, zero-knowledge proofs such as Schnorr are not compatible with address message signing - the public key cannot be retrieved from the address or the signature, so the address does not actually prove the authenticity of a Schnorr signature. That's why the public key is required as an input in the first place.
Yes, that's an intentional design choice in BIP340, see note 5: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. The choice is either batch verifiability or public key recovery.
I regret ever using public key recovery when introducing the old legacy message signing scheme. It should just have used script signatures like BIP322 proposes.
> In order to make it compatible with the address signing mechanism, the zero-knowledge part would have to be sacrificed in my BIP, or else a completely separate message signing format just for Taproot would be required
You can avoid relying on public key recovery, and include the public key + BIP340 signature in the encoded signature.
> (which, in my view, is redundant - there is already the draft BIP322 which can verify anything and everything, but nobody is implementing that
I think it would be much better if people would cooperate to get BIP322 to move forward than to keep inventing other formats. It's the obvious solution in my opinion: not restricted to single-key policies, compatible with every script type, and trivially extensible to future schemes.
> , just like BIP340).
How so? Every taproot compatible wallet has a BIP340 implementation.
Cheers,
--
Pieter

2023-06-07 23:00:15

- reply

📅 Original date posted:2021-10-20
📝 Original message:On Wednesday, October 20th, 2021 at 3:20 PM, Owen Gunden via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> I also notice that, as of 22.0, Wladimir is no longer signing the
> releases, and I have no trust in my gpg network of the people who seem
> to have replaced him.
This is not correct. Here are Wladimir's attestations on the 22.0 release: https://github.com/bitcoin-core/guix.sigs/tree/main/22.0/laanwj
There is no separate special release key anymore though. Instead, the build attestations (by anyone) can be used as your trust basis.
> Given the level of security at stake here, my eyebrows are raised at
> this combination of items changing (new website + new gpg signers at the
> same time).
There is no new website. The Bitcoin Core project website has been https://bitcoincore.org for years. I don't know why https://bitcoin.org hasn't updated to list the 22.0 release, though; that's up to them.
Cheers,
--
Pieter

2023-06-07 22:59:58

- reply

📅 Original date posted:2021-10-09
📝 Original message:On Oct 9, 2021, 11:36, Andreas Schildbach via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm trying to finish off bitcoinj's implementation for sending to
taproot addresses. For this, I'd like to test against a wallet that can
receive to P2TR and spend back.
> I've been trying to get a taproot address from Bitcoin Core 22.0 and
spent many hours, but in vain. Can someone please simply send my a
testnet wallet that has at least one taproot address? (I don't care
about anyone stealing my testnet coins, so don't worry about the
compromised private key.)
Hi Andreas,
You can construct a taproot-capable wallet in Bitcoin Core as follows:
* Have or create a descriptor wallet (createwallet RPC, with descriptors=true).
* Import a taproot descriptor (of the form "tr(KEY)"), as active descriptor (with active=true), where KEY can be a tprv.../* or any other supported key expression.
* Get a new address with addresstype=bech32m
I've also created one myself for testing: tb1p84x2ryuyfevgnlpnxt9f39gm7r68gwtvllxqe5w2n5ru00s9aquslzggwq
If you send testnet coins there email me an address, I'll return them.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211009/ce17a6fa/attachment-0001.html>

2023-06-07 22:59:33

- reply

📅 Original date posted:2021-09-16
📝 Original message:On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
> recently I have worked on a python implementation of bitcoin signature messages, and I have found that there was way better documentation about Segwit signature message than Taproot.
>
> 1) Segwit signature message got its own BIP, completed with test cases regarding only that specific function; Taproot on the other hand has the signature message function defined in BIP 341 and the test vectors in a different BIP (341). This is confusing. Shouldn't we create a different BIP only for Taproot signature message exactly like Segwit?
I'm not entirely sure what you mean; you're saying BIP 341 twice.
Still, you're right overall - there is no separate BIP for the signature message function. The reason is that the message function is different for BIP341 and BIP342. BIP 341 defines a basic common message function, which is then built up for BIP 341 key path spending, and for BIP 342 tapscript spending. This common part could have been a separate BIP, but that'd still not be a very clean separation. I'm not very inclined to support changing that at this point, given the state of deployment the BIPs have, but that doesn't mean the documentation/vectors can't be improved in the existing documents.
> 2) The test vectors for Taproot have no documentation and, most importantly, they are not atomic, in the sense that they do not target a specific part of the taproot code but all of it. This may not be a very big problem, but for signature verification it is. Because there are hashes involved, we can't really debug why a signature message doesn't pass validation, either it is valid or it is not. BIP 143 in this case is really good, because it provides hash preimages, so it is possible to debug the function and see where something went wrong. Because of this, writing the Segwit signature hash function took a fraction of the time compared to Taproot.
You're right. The existing tests are really intended for verifying an implementation against (and for making sure future code changes don't break anything). They have much higher coverage than the segwit tests had. But they aren't useful as documentation; the code that generates them (https://github.com/bitcoin/bitcoin/blob/v22.0/test/functional/feature_taproot.py#L605L1122) is probably better at that even, but still pretty dense.
> If this idea is accepted I will be more than happy to write the test cases for Taproot.
If you're interested in writing test vectors that are more aimed at helping debugging issues, by all means, do. You've already brought up the sighash code as an example. Another idea, primarily aimed at developers of signing code, is test vectors for certain P2TR scriptPubKeys, derived from certain internal keys and script trees. I'm happy to help to integrate such in Bitcoin Core and the BIP(s).
Thanks!
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210916/75d36938/attachment.html>

2023-06-07 22:58:11

- reply

📅 Original date posted:2021-08-29
📝 Original message:On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Following up on my original proposal, I would like to get some more feedback of the community
>
> to see if this could be realized at some point. Also, any recommendations as to who to contact
>
> to get things rolling?
I honestly don't understand the point of what you're suggesting.
* If you're concerned about random typos, this is something already automatically protected against through the checksum (both base58check or bech32/bech32m).
* If you're concerned about accidentally entering the wrong - but honestly created - address, comparing any few characters of the address is just as good as any other. It doesn't even require the presence of a checksum. Looking at the last N characters, or the middle N, or anything except the first few, will do, and is just as good as an "external" checksum added at the end. For randomly-generated addresses (as honest ones are), each of those has exactly as much entropy.
* If you're concerned about maliciously constructed addresses, which are designed to look similar in specific places, an attacker can just as easily make the external checksum collide (and having one might even worsen this, as now the attacker can focus on exactly that, rather than needing to focus on every other character).
Things would be different if you'd suggest a checksum in another medium than text (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an additional text-based checksum when addresses are already text themselves. This is even disregarding the difficulty of getting the ecosystem to adopt such changes.
Cheers,
--
Pieter

2023-06-07 22:58:09

- reply

📅 Original date posted:2021-08-29
📝 Original message:On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?
Side note: it's actually the last six characters.
>
> Well, because
>
> a) most people don't know that
>
> b) it is specific to bech32
>
> c) it is not easily readable being the last digits of a long address (although this could be
I think this is a misconception. For the purpose of verifying that you have the *right* address (rather than just a valid one), the checksum, or even the knowledge that a checksum is present, is completely irrelevant.
In honestly-generated addresses, every character except the prefix (the ~2 first characters for P2PKH and P2SH, and the ~4 first characters for BIP173/BIP350 native segwit addresses) has exactly the same amount of entropy. Instead of adding say a 4 character code, just tell people to compare any 4 characters of their choosing. Or more - I would hope people are already comparing (much) more than 4 characters already.
It doesn't matter if the characters being compared are checksum characters or data characters. In honestly-generated addresses, both are equally random.
Adding a special 4 character "external" checksum IMO would instead encourage people to perhaps just compare those 4 characters instead of the rest (or at least, focus mostly on those). That could easily worsen how well comparisons are done in practice...
Cheers,
--
Pieter

2023-06-07 18:28:29

- reply

📅 Original date posted:2021-02-11
📝 Original message:‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky <orlovsky at protonmail.com> wrote:
> Thank you very much for all the clarifications; it’s good to have them sorted out and clearly structured. From what you wrote it follows that we still need to reserve a dedicated purpose (with new BIP) for BIP340 signatures to avoid key reuse, am I right?
Maybe, but it would be for a particular way of using keys (presumably: single-key pay-to-taproot), not just the signature scheme itself. If you go down this path you'll also want dedicated branches for multisig participation, and presumably several interesting new policies that become possible with Taproot.
The only thing ECDSA/Schnorr specific about this is that - if you want to maintain provable security - the keys used for ECDSA and BIP340 should be separated by a hardened step. It seems however that all approaches people actually use to prevent reuse do that already.
And as I said, dedicated branches only help for the simple case. For example, it doesn't address the more general problem of preventing reuse of keys in multiple distinct groups of multisig sets you participate in. If you want to solve that you need to keep track of index is for participating in what - and once you have something like that you don't need dedicated purpose based derivation at all anymore.
So I'm not sure I'd state it as us *needing* a dedicated purpose/branch for single-key P2TR (and probably many other useful ways of using taproot based spending policies...). But perhaps it's useful to have.
Greg Maxwell pointed out to me that there may be another reason to want non-reuse across ECDSA and BIP340 keys: if someone were to do all of these wrong:
* not follow BIP340 and re-use RFC6979 for BIP340 nonce generation
* reuse the same keys for both
* sign the same message with both
... you would actually leak your private key. This isn't a concern for Bitcoin transaction signing however, as the sighash (message) indirectly commits to BIP341 or not, and thus it'd be impossible to construct colliding messages. Still, it's a consideration to factor in.
Cheers,
--
Pieter

2023-06-07 18:28:28

- reply

📅 Original date posted:2021-02-05
📝 Original message:On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> Background
>
> ====================
>
> Had a discussion last night in Bitcoin Core IRC with Peter Wuille on different topics regarding key derivations, security, key tweaks in context of Schnorr signatures & Taproot. Would like to share some action points and plans that emerged from there:
>
> 1. There is a real need for BIP-43 based new BIP with a new purpose field for keys used in Schnorr signatures. Peter will not do it (he is not very much interested in spending his time on wallet-level stuff), so someone else should.
> 2. Keys used in Schnorr signatures MUST NEVER BE used in ECDSA signatures, otherwise there is a risk of private key leak via correlation attack. This is rationale behind N1.
Hi Maxim,
thanks for bringing up this discussion here. I'd like to clarify a few things though, as I think the above is formulated far too strongly.
There are two issues here: (1) reasons to avoid reusing the same key for privacy reasons, and (2) reasons to avoid using related keys for cryptographic reasons. And in practice, solutions to the first (which we already need, unrelated to Taproot/Schnorr) mean the second is largely moot.
# Don't reuse keys for privacy/organizational reasons.
Reusing the same key in Bitcoin scripts - for use in distinct signature schemes or not - should always be avoided. It has obvious privacy implications; I don't think this is controversial, and it's a problem that exists today, unrelated to Taproot. E.g. you don't want to reuse the same keys as both single-sig and participation in multisig.
My personal view here is that distinct standard derivation paths help with this in the simple cases, but they're not a full solution in the most general case. E.g. if you want to use one seed/root to participate in multiple sets of multisig policies, you'll need some kind of index to assign to each anyway. For this reason in general I prefer solutions that explicitly track what path is used for what.
# Don't use related keys for cryptographic reasons
There are some concerns to address here, but I want to make it clear there are no known attacks against usage of related keys across ECDSA and Schnorr, and I don't expect there will be. However, there is probably no proof for this, and creating one may be tricky. On the other hand, the ecosystem (Bitcoin, but also many other applications) has accepted ECDSA long ago, while it had no security proofs whatsoever (and even the ones that exist now rely on fairly unusual assumption; a proof for security of mixed Schnorr/ECDSA usage would inherently need equally unusual assumptions too).
Now, as soon as a hardened derivation separates different uses there is no concern at all. So any solution for avoiding key reuse (section above) that works by assigning (implicitly or explicitly) different hardened derivation paths (as BIP43 etc. do) to different uses implies there is never any concern about related keys across Schnorr/ECDSA.
If the keys are not separated by a hardened step, it's more complicated. Looking at the different cases:
(1) Signing with related ECDSA keys (e.g. two unhardened child keys from the same xpub)
- This is very common on BIP32 usage today, so hopefully it is secure! Tim Ruffing pointed me today to https://link.springer.com/chapter/10.1007/978-3-030-36938-5_8 whose abstract seems to indicate they prove this is actually secure, but I don't know under what assumptions. Note that the comment there about Schnorr not having this property does not apply to BIP340, because it uses key-prefixed Schnorr.
(2) Signing with related Schnorr keys.
- I believe this is secure simply because BIP340 challenges commit to the pubkey (key prefixing), and thus a signature on one shouldn't teach you anything about others. A formal proof is probably a bit longer, but still trivial to construct.
(3) The real question: signing with a Schnorr key that is related to an ECDSA key.
- I don't expect that this is easy to prove, but I have a very hard time imagining how it could be exploitable, given the use of domain-separated hashes. Aspects such as BIP340's key prefixing and the fact that Bitcoin sighashes indirectly commit to the (set of) signing pubkeys make it even harder.
# TL;DR
* For privacy reasons, you should use separate keys/derivation branches for different uses in all circumstances (duh).
* To stay within the realm of provably security it's advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps.
* Even if you don't, you're really just back to the level of assurance we had about unhardened BIP32 ECDSA keys before a proof was known (which I think most people aren't even aware of).
Cheers,
--
Pieter

2023-06-07 18:27:52

- reply

📅 Original date posted:2020-12-21
📝 Original message:On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks a lot for taking the time to brush up the BIP. For what it's
> worth, I am all for these changes, and I see them as clear
> improvements all around.
>
> IIRC Pieter was the one who originally suggested the two-checks
> approach (invalid, inconclusive, valid) which is being modified here,
> so would be good if you chimed in (or not -- which I'll assume means
> you don't mind).
I agree with the idea of permitting incomplete validators to return inconclusive as well. That doesn't really reduce the functionality (given that "inconclusive" was already a potential result), and it obviously makes it much more accessible to a variety of software.
This suggestion breaks the original use of inconclusive though: the ability to detect that future features are used in the signature. The idea was to use divergence between "consensus valid" and "standardness valid" as a proxy for future extensions to be detected (e.g. OP_NOPn, future witness versions, ...). I think it's undesirable that these things now become unconditionally invalid (until the BIP is updated, but once that happens old validators will give a different result than new ones).
Since the BIP no longer relies on a nebulous concept of standardness, and instead specifically defines which standardness features are to be considered, this seems easy to fix: whenever validation fails due to any of those, require reporting inconclusive instead of invalid (unless of course something actually invalid also happens). In practice I guess you'd implement that (in capable validators) by still doing validation twice, once with all features enabled that distinguish between valid/invalid, and if valid, again but now with the features enabled that distinguish between valid and (invalid or inconclusive).
Cheers,
--
Pieter

2023-06-07 18:27:52

- reply

📅 Original date posted:2020-12-21
📝 Original message:On Monday, December 21, 2020 2:57 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
> > Thanks a lot for taking the time to brush up the BIP. For what it's
> > worth, I am all for these changes, and I see them as clear
> > improvements all around.
> > IIRC Pieter was the one who originally suggested the two-checks
> > approach (invalid, inconclusive, valid) which is being modified here,
> > so would be good if you chimed in (or not -- which I'll assume means
> > you don't mind).
>
> I agree with the idea of permitting incomplete validators to return inconclusive as well. That doesn't really reduce the functionality (given that "inconclusive" was already a potential result), and it obviously makes it much more accessible to a variety of software.
>
> This suggestion breaks the original use of inconclusive though: the ability to detect that future features are used in the signature. The idea was to use divergence between "consensus valid" and "standardness valid" as a proxy for future extensions to be detected (e.g. OP_NOPn, future witness versions, ...). I think it's undesirable that these things now become unconditionally invalid (until the BIP is updated, but once that happens old validators will give a different result than new ones).
>
> Since the BIP no longer relies on a nebulous concept of standardness, and instead specifically defines which standardness features are to be considered, this seems easy to fix: whenever validation fails due to any of those, require reporting inconclusive instead of invalid (unless of course something actually invalid also happens). In practice I guess you'd implement that (in capable validators) by still doing validation twice, once with all features enabled that distinguish between valid/invalid, and if valid, again but now with the features enabled that distinguish between valid and (invalid or inconclusive).
Re-reading your proposed text, I'm wondering if the "consensus-only validation" extension is intended to replace the inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't think it does, and regardless it doesn't seem very useful.
What I'm suggestion could be specified this way:
* If validator understands the script:
* If signature is consensus valid (as far as the validator knows):
* If signature is not known to trigger standardness rules intended for future extension (well-defined set of rules listed in BIP, and revisable): return valid
* Otherwise: return inconclusive
* Otherwise: return invalid
* Otherwise: return inconclusive
Or in other words: every signature has a well-defined result (valid, invalid, inconclusive) + validators may choose to report inconclusive for anything they don't understand.
This has the property that as long as new consensus rules only change things that were covered under for-future-extension standardness rules, no two validators will ever claim valid and invalid for the same signature. Only valid+inconclusive or invalid+inconclusive.
Cheers,
--
Pieter

2023-06-07 18:27:41

- reply

📅 Original date posted:2020-12-05
📝 Original message:On Friday, November 6, 2020 11:49 AM, Mike Schmidt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Well I sure picked a bad couple weeks to volunteer to send a bunch of Bitcoin test transactions...
>
> While I tested less than I would have liked, there are some notable results:
I think these results really show there is no reason to try to maintain the old-software-can-send-to-future-segwit-versions property, given that more than one not just didn't support it, but actually sent coins into a black hole.
Thus, I agree with Rusty that we should change the checksum for v1+ unconditionally. That also means that old senders are protected from the insertion issue (by failing, as we can guarantee that new-checksum addresses, even after a few errors, are invalid to old software).
I've sent another mail in this thread with details, but the TL;DR is that we should use the constant M=0x2bc830a3 rather than 0x3fffffff as previous suggested. More information on https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e.
Absent objections, I'll write up a BIP soon.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201205/32d286a4/attachment.html>

2023-06-07 18:27:41

- reply

📅 Original date posted:2020-12-06
📝 Original message:‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 6, 2020 5:04 AM, David A. Harding <dave at dtrt.org> wrote:
> On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > I think these results really show there is no reason to try to
> > maintain the old-software-can-send-to-future-segwit-versions property,
> > given that more than one not just didn't support it, but actually sent
> > coins into a black hole.
>
> I don't think this is a good criteria to use for making a decision. We
> shouldn't deny users of working implementations the benefit of a feature
> because some other developers didn't implement it correctly.
>
> > Thus, I agree with Rusty that we should change the checksum for v1+
> > unconditionally.
>
> I disagreed with Rusty previously and he proposed we check to see how
> disruptive an address format change would be by seeing how many wallets
> already provide forward compatibility and how many would need to be
> updated for taproot no matter what address format is used. I think that
> instead is a good criteria for making a decision.
>
> I understand the results of that survey to be that only two wallets
> correctly handled v1+ BIP173 addresses. One of those wallets is Bitcoin
> Core, which I personally believe will unhesitatingly update to a new
> address format that's technically sound and which has widespread support
> (doubly so if it's just a tweak to an already-implemented checksum
> algorithm).
Hi Dave,
You're right to point out there is nuance I skipped over.
Let's look at the behavior of different classes of software/services that exist today when trying to send to v1+ addresses:
(A) Supports sending to v1+ today
* Old proposal: works, but subject to bech32 insertion issue
* New proposal: fails
(B) Fails to send to v1+ today
* Old proposal: fails
* New proposal: fails
(C) Incorrectly sends to v1+ today
* Old proposal: lost funds
* New proposal: fails
So the question is how the support for sending to v1+ in (a) software weighs up against protecting both (a) from the insertion issue, and (c) from lost funds. I do think (c) matters in this equation - people may choose to avoid adopting v1+ witnesses if it were to be known that some senders out there would misdirect funds. But the fact that (a) is small also means there is very little to gain from the old proposal.
So perhaps I should have formulated it as: the small number of v1+ compatible senders today (regardless of the reasons for that) shows how futile the attempt to have one address type for all witness versions was, and the fact that there are even some who misdirect(ed) funds is the final nail in the coffin. Changing the checksum unconditionally gives us a new attempt at that.
> Given that, I also now agree with changing the checksum for v1+.
Great.
Cheers,
--
Pieter

2023-06-07 18:27:40

- reply

📅 Original date posted:2020-12-05
📝 Original message:> On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
> > I propose an alternative to length restrictions suggested by
> > Russell in https://github.com/bitcoin/bips/pull/945: use the
> > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant,
> > unless the first byte is 0.
>
> Hi all,
>
> starting a slight side-thread here.
Another update, and a longer write-up.
Introduction
------------
Bech32's checksum algorithm was designed to be strong against substitution
errors, but it also provides some protection against more general classes of
errors. The final constant M that is XOR'ed into the checksum influences that
protection. BIP173 today uses M=1, but it is now known that this has a
weakness: if the final character is a "p", any number of "q" characters can be
inserted or erased right before it, without invalidating the checksum.
As it was recognized that other constants do not have this issue, the obvious
question is whether this is the only possible type of weakness, and if not, if
there is an optimal constant to use that minimizes the largest number of
weaknesses.
Since my last mail I've realized that it is actually possible to analyse the
behavior of these final constants under a wide variety of error classes
(substitutions, deletions, insertions, swaps, duplications) programatically.
Greg Maxwell and I have used this to perform an exhaustive analysis of certain
error patterns for all 2^30 possible M values, selected a number of criteria
to optimize for, and conclude that we should use as constant:
M = 0x2bc830a3
The code used to do this analysis, as well as the code used to verify some
expected properties of the final result, and more, can be found on
https://gist.github.com/sipa/14c248c288c3880a3b191f978a34508e
See results_final.txt to see how this constant compares with the previously
suggested constants 1, 0x3fffffff, and 0x3fefffff.
Properties
----------
If we define an error as a deletion of one position, a swap of adjacent
positions, a substitution in a specific position with a random character, an
insertion of one random character in a specific position, or a duplication of
the character in a specific position, then this M constant above gives us the
following properties:
* For generic HRPs and errors that don't affect the first 6 data characters,
or alternatively averaged over all HRPs (see details futher):
* Always detected:
* (P) Up to 4 substitution errors (true for any constant).
* (Q) Any valid code with the new constant, fed without modification to
software that uses the old constant 1 (true for any constant).
* Any error pattern has failure to detect probability <= 2^-30:
* (L) Any number of errors restricted to a single window of up to 4
characters.
* (B) Up to two errors restricted to a window of up to 68 characters.
* (D) Any one error made to a valid code with the new constant, and fed to
software that uses the old constant 1
* Most error patterns have probability <= 2^-30:
* (C) Up to two errors in general: out of 23926796 such error patterns,
0.0040% have probability 2^-25.
* (N) Up to three errors restricted to a window of up to 69 characters:
out of 284708444 such patterns, 0.033% have probability 2^-25.
* (O) Up to three errors in general: out of 295744442 such error patterns,
0.034% have probability 2^-25; 0.000065% have probability 2^-20.
* (G) Up to two errors made to a valid code with the new constant, and fed
to software that uses the old constant 1: out of 2831622 such error
patterns, 0.048% have probability 2^-25.
* Specifically for the bc1 HRP, with the BIP173 length restrictions:
* Always detected:
* (R) Up to 4 substitution errors (true for any constant).
* (A) Up to 3 substitution errors made to a valid code with the new
constant, and fed to software that uses the old constant 1.
* Any error pattern has failure to detect probability <= 2^-30:
* (E) Any one error.
* (F) Any one error made to a valid code with the new constant, and fed to
software that uses the old constant 1.
* (H) Up to two errors restricted to a window of 28 characters.
* Most error patterns have probability <= 2^-30:
* (J) Up to two errors in general: out of 455916 such error patterns,
0.039% have probability 2^-25; 0.0053% have 2^-20.
* (K) Any number of errors restricted to a window of 4 characters: out of
5813139 such error patterns, 0.0016% have probability 2^-25.
* (M) Up to three errors: out of 50713466 such error patterns, 0.078% have
probability 2^-25; 0.00063% have 2^-20.
* (I) Up to two errors made to a valid code with the new constant, and fed
to software that uses the old constant 1: out of 610683 such error
patterns, 0.092% have probability 2^-25; 0.00049% have probability
2^-20.
To give an idea of what these probabilities mean, consider the known BIP173
insertion issue. It admits an error pattern of 1 error (insertion in
penultimate position) that has a failure to detect probability of 2^-10:
it requires the final character to be 'p', and the inserted character to be
'q'. Assuming those are both random, we have a chance of 1 in 32*32 to hit it.
Note that the choice of *what* the error pattern is (whether it's insertion,
and where) isn't part of our probabilities: we try to make sure that *every*
pattern behaves well, not just randomly chosen ones, because presumably humans
make some kinds of errors more than others, and we don't know which ones.
All the analyzed patterns above are guaranteed to be detected with probability
2^-20 or better (and most are 2^-30). Of course, if we'd search for even
larger classes of errors, say any 4 independent errors of any type, we would
probably discover patterns with worse probabilities, but at that point the
probability of the pattern itself being hit should be taken into account.
The selection was made based on these same properties:
* Start with the set of all 2^30 constants.
* The generic properties (L), (B), (D), (C), (N), (O), and (G) were selected
for by rejecting all constants that left any worse error patterns (e.g.
all codes for which patterns matching (N) existed with failure probability
above 2^-25 were removed). All these restrictions are as strong as they
can be: making them over longer strings, wider windows, or more errors with
the same restrictions removes all remaining constants. This leaves us with
just 12054 acceptable constants.
* The same was then done for the bc1/BIP173 specific properties (A), (E), (J),
(F), (H), (K), (M), and (I). This reduces the set further to 79 acceptable
constants. The full analysis output for all of these can be found in
output.txt.
* Finally, the constant with the minimal number of worst-probability patterns
was chosen for the generic property (N). The single constant 0x2bc830a3
remains.
* This solution and a few of its expected properties were then validated using
a simple program that makes random errors (see the monte_carlo.py file).
Technical details
-----------------
For the purpose of this analysis, define an "error pattern" as a starting
length (of a valid string consisting of otherwise randomly chosen characters)
combined with a sequence of the following (in this order):
* 0 or more deletions of characters at specific positions (without
constraining what those characters are)
* 0 or more swaps of characters at specific positions with the character
following it
* 0 or more substitutions of characters at specific positions with a uniformly
randomly selected character
* 0 or more insertions of uniformly randomly selected characters at specific
positions
* 0 or more duplications of characters at specific positions (including
duplications of characters inserted/substituted in the previous steps)
Examples:
* "Start with a random valid 58 character string, remove the 17th character,
swap the 11th character with the 12th character, and insert a random
character in the 24th position" is an error pattern.
* "Replace the 17th through 24th characters in a 78 character string with
'aardvark'" is not an error pattern, because substituted characters have to
be random, and can't be specific values.
Given such a pattern, assign variable names to every input character, and to
every inserted/substituted character. For example, the pattern "Start with
a 6 character string, delete the 1st character, swap the 2nd and 3rd
character, and insert a random character between those" would be represented
as [v0 v1 v2 v3 v4 v5] and [v1 v3 v6 v2 v4 v5]. Treat these variables as
elements of GF(32), and write out the equations that both the first and second
list have a valid checksum. Due to the fact that BCH codes are linear, this is
just a linear set of equations over GF(32), and we can use Gaussian
elimination to find the size of the solution space. If the input and output
are the same length, we need to subtract the number of solutions for which the
input and output are exactly the same, which is easy to find with another set
of equations. Now compute the ratio of this number divided by (32^numvars /
32^6), where the 32^6 is due to the precondition that the input string is
valid. This gives us the probability of failure, assuming input and output are
random, apart from the known relation between the two, and the fact that both
are valid.
This technique has an important limitation: it can only reason about randomly-
chosen input strings, and the presence of the HRP and version numbers at the
start violates that assumption. These are not random, and we're forced to
make one of these concessions:
1) Ignore the problem, and treat the HRP as random. This lets us derive
properties that hold over all potential HRPs on average, but will thus fail
to account for the possibility that for a small numbers of potential HRPs
some error patterns may exist that behave worse. For technical reasons,
this averaging makes all constants behave identically for error patterns
that don't change the length of the string. Given that substitution/swap
only errors are already dealt with well due to the BCH design this is
perhaps not too important. One exception is frame-shifting errors (a
deletion in one place compensated with an insertion in another place).
2) Restrict analysis to error patterns that don't affect the first 6 actual
characters. Doing so "masks" the effect of the HRP completely.
3) Do analysis for specific HRPs only, allowing much more accurate statements,
but HRP-specific ones that may not hold for every HRP.
Our final selection primarily optimizes for 1) and 2) as those benefit all
potential uses of the encoding, but do optimize for 3) the "bc1" prefix
specifically (and the BIP173 length restriction) as a tiebreaker.
The code for this can be found under the link above, in const_analysis.cpp.
Cheers,
--
Pieter

2023-06-07 18:27:27

- reply

📅 Original date posted:2020-10-07
📝 Original message:On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> But first of all, I'd like to say that the idea for FPNC came out of a conversation with ZmnSCPxj's in regards to re-org stability. When I had proposed blockchain pointers with the PubRef opcode, he took the time to explain to me concerns around re-orgs and why it is a bigger problem than I initially had thought — and I greatly appreciate this detail. After touching base with ZmnSCPxj and Greg Maxwell there is an overwhelming view that the current problems that face the network outweigh any theoretical ones.
Greg Maxwell isn't on this list, but assuming this is about the conversion you've had on Bitcoin Core's security disclosure list, I believe this is a misrepresentation. The discussion has been mostly around a DoS attack report which turned out to be a mistake.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201008/25f3733d/attachment.html>

2023-06-07 18:27:24

- reply

📅 Original date posted:2020-10-20
📝 Original message:On Tuesday, October 20, 2020 3:29 AM, David A. Harding <dave at dtrt.org> wrote:
> I would guess that some of the failures / stuck transactions might now be successes if the backend infrastructure has upgraded to Bitcoin Core > = 0.19.
Yeah, it would be good to re-test them since a ~year has passed since the 0.19.0 release.
Cheers,
--
Pieter

2023-06-07 18:27:23

- reply

📅 Original date posted:2020-10-19
📝 Original message:On Sunday, October 18, 2020 5:49 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Pieter Wuille bitcoin-dev at wuille.net writes:
>
> > Today, no witness v1 receivers exist. So it seems to me the only question
> > is what software/infrastructure exist that supports sending to witness v1,
> > and whether they (and their userbase) are more or less likely to upgrade
> > before receivers appear than those that don't.
> > Clearly if only actively developed software currently supports sending to
> > v1 right now, then the question of forward compatibility is moot, and I'd
> > agree the cleanliness of option 2 is preferable.
>
> If software supports v1 today and doesn't get upgraded, and we persue
> option 1 then a trailing typo can make trouble. Not directly lose money
> (since the tx won't get propagated), but for most systems (e.g. hosted
> wallets) someone has to go in and figure out the error and fix it up.
It depends. As is, they'd be relayed even as sending to future witness versions
or lengths is standard. If option 1 is chosen there may be reasons to add
safeguards using relay policy, though.
> Option 2 means they're likely to fix their systems the first time
> someone tries a v1 send, not the first time someone makes a trailing
> typo (which might be years).
Possibly, but it's also possible that it won't get fixed at all, and instead
receiver software just has to wait a few years longer before being able to start
giving out v1 addresses and have a reasonable chance the sender supports it.
You're right though that protecting old sender software from being protected
against the insertion bug is a good argument in favor of Option 2.
Strictly speaking it also has an issue, as the error detection properties aren't
guaranteed for new-scheme-address + intended-detected-error interpreted as
old-scheme-address (in particular, you can make 4 substitution errors in
a new-scheme address and have it be a valid old-scheme address). This is much
less of an issue than the insertion bug that remains present with Option 1 in
old senders.
> > As for how long: new witness version/length combinations are only rarely needed,
> > and there are 14 length=32 ones left to pick. We'll likely want to use those
> > first anyway, as it's the cheapest option with 128-bit collision resistance.
> > Assuming future constructions have something like BIP341's leaf versioning, new
> > witness version/length combinations are only required for:
> >
> > - Changes to the commitment structure of script execution (e.g. Graftroot,
> > different hash function for Merkle trees, ...)
> >
> > - Upgrades to new signing cryptography (EC curve change, PQC, ...).
> > - Changes to signatures outside of a commitment structure (e.g. new sighash
> > modes for the keypath in BIP341, or cross-input aggregation for them).
> >
> >
> > and in general, not for things like new script opcodes, or even for fairly
> > invasive redesigns of the script language itself.
>
> Hmm, good point. These can all be done with version bumps.
>
> The only use for extra bytes I can see is per-UTXO flags, but even then
> I can't see why you'd need to know them until their spent (in which case
> you stash the flag in the input, not the output).
>
> And fewer bytes seems bad for fungibility, since multisig would be
> dangerous.
>
> But the future keeps surprising me, so I'm still hesitant.
Of course, our thinking here may change significantly over time - still, I expect
it'll be years before something other than 32-byte addresses is desired.
> > TL;DR: what codebases/services/infrastructure exists today that supports
> > sending to witness v1 BIP173 addresses?
>
> OK, time to waste some money!
>
> Can you provide a mainnet v1 address, and I'll try to spam it from as
> many things as I can find. If we're really lucky, you can collect it
> post-fork and donate it to charity. Or a miner can steal it pre-fork :)
Here is a BIP341 witness v1 address, corresponding to just the generator as
inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP):
bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY ptwy6lm87hf5ss52r5n8
Cheers,
--
Pieter

2023-06-07 18:27:22

- reply

📅 Original date posted:2020-10-16
📝 Original message:Hi Rusty,
thanks for starting this thread. We definitely should make a decision around
this soon.
On Wednesday, October 14, 2020 6:40 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > > Here's a summary of each proposal:
> > > Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 29,
> > > 32, 36, or 40 bytes)
> > >
> > > 1. Backwards compatible for v1 etc; old code it still works.
> > > 2. Restricts future segwit versions, may require new encoding if we
> > > want a diff length (or waste chainspace if we need to have a padded
> > > version for compat).
> > >
> > > Checksum change based on first byte:
> > >
> > > 1. Backwards incompatible for v1 etc; only succeeds 1 in a billion.
> > > 2. Weakens guarantees against typos in first two data-part letters to
> > > 1 in a billion.[1]
> > >
> If we go for option 2, v1 (generated from bitcoin core) will simply fail
> the first time you try test it. So it will force an upgrade. There
> are fewer places generating addresses than accepting them, so this
> seems the most likely scenario.
>
> OTOH, with option 1, anyone accepting v1 addresses today is going to
> become a liability once v1 addresses start being generated.
Today, no witness v1 receivers exist. So it seems to me the only question
is what software/infrastructure exist that supports sending to witness v1,
and whether they (and their userbase) are more or less likely to upgrade
before receivers appear than those that don't.
Clearly if only actively developed software currently supports sending to
v1 right now, then the question of forward compatibility is moot, and I'd
agree the cleanliness of option 2 is preferable.
Does anyone have an up-to-date overview of where to-future-witness sending
is supported? I know Bitcoin Core does.
> > It took a lot of community effort to get widespread support for bech32
> > addresses. Rather than go through that again, I'd prefer we use the
> > backwards compatible proposal from BIPs PR#945 and, if we want to
> > maximize safety, consensus restrict v1 witness program size, e.g. reject
> > transactions with scriptPubKeys paying v1 witness programs that aren't
> > exactly 32 bytes.
>
> Yes, I too wish we weren't here. :(
>
> Deferring a hard decision is not useful unless we expect things to be
> easier in future, and I only see it getting harder as time passes and
> userbases grow.
Possibly, but in the past I think there has existed a pattern where adoption
of new technology is at least partially based on certain infrastructure
and codebases going out of business and/or being replaced with newer ones,
rather than improvements to existing ones.
If that effect is significant, option 1 may be preferable: it means less
compatibility issues in the short term, and longer term all that may be
required is fixing the spec, and waiting long enough for old/unmaintained code
to be replaced.
As for how long: new witness version/length combinations are only rarely needed,
and there are 14 length=32 ones left to pick. We'll likely want to use those
first anyway, as it's the cheapest option with 128-bit collision resistance.
Assuming future constructions have something like BIP341's leaf versioning, new
witness version/length combinations are only required for:
* Changes to the commitment structure of script execution (e.g. Graftroot,
different hash function for Merkle trees, ...)
* Upgrades to new signing cryptography (EC curve change, PQC, ...).
* Changes to signatures outside of a commitment structure (e.g. new sighash
modes for the keypath in BIP341, or cross-input aggregation for them).
and in general, not for things like new script opcodes, or even for fairly
invasive redesigns of the script language itself.
> The good news it that the change is fairly simple and the reference
> implementations are widely used so change is not actually that hard
> once the decision is made.
Indeed. Whatever observations we had about adoption of base58 -> bech32 may not
apply because the change to a different checksum is fairly trivial compared to
that. Still, presence of production codebases that just don't update at all
may complicate this.
> > Hopefully by the time we want to use segwit v2, most software will have
> > implemented length limits and so we won't need any additional consensus
> > restrictions from then on forward.
>
> If we are prepared to commit to restrictions on future addresses.
>
> We don't know enough to do that, however, so I'm reluctant; I worry that
> a future scheme where we could save (e.g.) 2 bytes will impractical due
> to our encoding restrictions, resulting in unnecessary onchain bloat.
I'm opposed to consensus-invalidating certain length/version combinations, if
that's what you're suggesting, and I don't think there is a need for it.
TL;DR: what codebases/services/infrastructure exists today that supports
sending to witness v1 BIP173 addresses?
Cheers,
--
Pieter

2023-06-07 18:27:20

- reply

📅 Original date posted:2020-10-16
📝 Original message:On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> BIP32 [1] says: "In order to prevent these from depending solely on the key
> itself, we extend both private and public keys first with an extra 256 bits of
> entropy. This extension, called the chain code...".
>
> My argument is that the chain code is not needed.
> To support such claim, I'll show a schematic of BIP32 operations to be compared
> with an alternative proposal and discuss the differences.
>
> I have two main questions:
> - Is this claim false?
> - Has anyone shared this idea before?
Hi Leonardo,
It's been a while but I can comment on the history of how the chaincode ended up being in there.
The most direct reason is that BIP32 was inspired by Alan Reiner's Armory software, which had
a different homomorphic key derivation scheme, but included something called a chaincode to
enable multiple "chains" of keys to be derived from the same keypair. More information about
that scheme is here: https://bitcointalk.org/index.php?topic=205999.msg2155696#msg2155696
BIP32 made two improvements to this:
* Allow efficient random access into the derived keys (Armory's scheme required iterating the
derivation function to get consecutive subkeys - which is probably where the name "chain"
in chaincode comes from)
* Permit hierarchical derivation, by also constructing a sub-"chaincode" along with every subkey.
If I recall correctly, there was at least one argument at the time about whether the chaincode was
necessary at all. My rationale for keeping it was:
* xpubs are not as secret as private keys, but they do demand more protection than just public keys
(for both privacy reasons, and due to the fact that revealing an xpub + child xprv is ReallyBad(tm)).
For that reason, it seems nice that an xpub consists of more than just a public key, as revealing
the public key in it means the protection above remains. I don't think there is anything fundamental
here; just a distinct encoding for xpubs and pubkeys might have accomplished the same, but this
felt safer.
* Repeated hashing "felt" dangerous, as it reduces entropy at every step, so it'd go below 256 bits.
With a chaincode to maintain extra entropy this is prevented. In retrospect, this is a bogus
argument, as it's only a relevant point for information-theoretical security (which means we wouldn't
be able to use ECC in the first place), and even then, it's only a minimal effect.
So in short, from a cryptographic point of view, I think that indeed, the chaincode is not needed. It
probably has some qualitative advantage in practice, but not very much.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201016/ebd8144d/attachment.html>

2023-06-07 18:26:19

- reply

📅 Original date posted:2020-08-12
📝 Original message:Hello all,
The current BIP340 draft[1] uses two different tiebreakers for conveying the Y coordinate of points: for the R point inside signatures squaredness is used, while for public keys evenness is used. Originally both used squaredness, but it was changed[2] for public keys after observing this results in additional complexity for compatibility with existing systems.
The reason for choosing squaredness as tiebreaker was performance: in non-batch signature validation, the recomputed R point must be verified to have the correct sign, to guarantee consistency with batch validation. Whether the Y coordinate is square can be computed directly in Jacobian coordinates, while determining evenness requires a conversion to affine coordinates first.
This argument of course relies on the assumption that determining whether the Y coordinate is square can be done more efficiently than a conversion to affine coordinates. It appears now that this assumption is incorrect, and the justification for picking the squaredness tiebreaking doesn't really exist. As it comes with other trade-offs (it slows down signing, and is a less conventional choice), it would seem that we should reconsider the option of having the R point use the evenness tiebreaker (like public keys).
It is late in the process, but I feel I owe this explanation so that at least the possibility of changing can be discussed with all information. On the upside, this was discovered in the context of looking into a cool improvement to libsecp256k1[5], which makes things faster in general, but specifically benefits the evenness variant.
# 1. What happened?
Computing squaredness is done through the Jacobi symbol (same inventor, but unrelated to Jacobian coordinates). Computing evenness requires converting points to affine coordinates first, and that needs a modular inverse. The assumption that Jacobi symbols are faster to compute than inverses was based on:
* A (possibly) mistaken belief about the theory: fast algorithms for both Jacobi symbols and inverses are internally based on variants of the same extended GCD algorithm[3]. Since an inverse needs to extract a full big integer out of the transition steps made in the extgcd algorithm, while the Jacobi symbol just extracts a single bit, it had seemed that any advances applicable to one would be applicable to the other, but inverses would always need additional work on top. It appears however that a class of extgcd algorithms exists (LSB based ones) that cannot be used for Jacobi calculations without losing efficiency. Recent developments[4] and a proposed implementation in libsecp256k1[5] by Peter Dettman show that using this, inverses in some cases can in fact be faster than Jacobi symbols.
* A broken benchmark. This belief was incorrectly confirmed by a broken benchmark[6] in libsecp256k1 for the libgmp-based Jacobi symbol calculation and modular inverse. The benchmark was repeatedly testing the same constant input, which apparently was around 2.5x faster than the average speed. It is a variable-time algorithm, so a good variation of inputs matters. This mistake had me (and probably others) convinced for years that Jacobi symbols were amazingly fast, while in reality they were always very close in performance to inverses.
# 2. What is the actual impact of picking evenness instead?
It is hard to make very generic statements here, as BIP340 will hopefully be used for a long time, and hardware advancements and algorithmic improvements may change the balance. That said, performance on current hardware with optimized algorithms is the best approximation we have.
The numbers below give the expected performance change from squareness to evenness, for single BIP340 validation, and for signing. Positive numbers mean evenness is faster. Batch validation is not impacted at all.
In the short term, for block validation in Bitcoin Core, the numbers for master-nogmp are probably the most relevant (as Bitcoin Core uses libsecp256k1 without libgmp, to reduce consensus-critical dependencies). If/when [5] gets merged, safegcd-nogmp will be what matters. On a longer time scale, the gmp numbers may be more relevant, as the Jacobi implementation there is certainly closer to the state of the art.
* i7-7820HQ: (verify) (sign)
- master-nogmp: -0.3% +16.1%
- safegcd-nogmp: +6.7% +17.1%
- master-gmp: +0.6% +7.7%
- safegcd-gmp: +1.6% +8.6%
* Cortex-A53: (verify) (sign)
- master-nogmp: -0.3% +15.7%
- safegcd-nogmp: +7.5% +16.9%
- master-gmp: +0.3% +4.1%
- safegcd-gmp: 0.0% +3.5%
* EPYC 7742: (verify) (sign)
- master-nogmp: -0.3% +16.8%
- safegcd-nogmp: +8.6% +18.4%
- master-gmp: 0.0% +7.4%
- safegcd-gmp: +2.3% +7.8%
In well optimized cryptographic code speedups as large as a couple percent are difficult to come by, so we would usually consider changes of this magnitude relevant. Note however that while the percentages for signing speed are larger, they are not what is unexpected here. The choice for the square tiebreaker was intended to improve verification speed at the cost of signing speed. As it turns out that it doesn't actually benefit verification speed, this is a bad trade-off.
# 3. How big a change is it
* In the BIP:
- Changing both invocations of `has_square_y` to `has_even_y`.
- Changing the `lift_x_square_y` invocation to `lift_x_even_y`.
- Applying the same change to the test vector generation code, and the resulting test vectors.
* In the libsecp256k1:
- An 8-line patch to the proposed BIP340 implementation[7]: see [8]
* In Bitcoin Core:
- Similarly small changes to the Python test reimplementation[9]
* Duplicating these changes in other draft implementations that may already exist.
* Review for all the above.
# 4. Conclusion
We discovered that the justification for using squaredness tiebreakers in BIP340 is based on a misunderstanding, and recent developments show that it may in fact be a somewhat worse choice than the alternative. It is a relatively simple change to address this, but that has be weighed against the impact of changing the standard at this stage.
Thoughts?
# 5. References
[1] https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017639.html
[3] https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm
[4] https://gcd.cr.yp.to/safegcd-20190413.pdf
[5] https://github.com/bitcoin-core/secp256k1/pull/767
[6] https://github.com/bitcoin-core/secp256k1/pull/797
[7] https://github.com/bitcoin-core/secp256k1/pull/558
[8] https://github.com/sipa/secp256k1/commit/822311ca230a48d2c373f3e48b91b2a59e1371d6
[9] https://github.com/bitcoin/bitcoin/pull/17977
Cheers,
--
Pieter

2023-06-07 18:23:02

- reply

📅 Original date posted:2020-02-24
📝 Original message:Hello list,
Despite saying earlier that I expected no further semantical changes
to BIP 340-342, I've just opened
https://github.com/bitcoin/bips/pull/893 to make a number of small
changes that I believe are still worth making.
1. Even public keys
Only one change affects the validation rules: the Y coordinate of
32-byte public keys is changed from implicitly square to implicitly
even. This makes signing slightly faster (in the microsecond range),
though also verification negligibly slower (in the nanosecond range).
It also simplifies integration with existing key generation
infrastructure. For example BIP32 produces public keys with known
even/oddness, but squaredness would need to be computed separately.
Similar arguments hold for PSBT and probably many other things.
Note that the Y coordinate of the internal R point in the signature
remains implicitly square: for R the squaredness gives an actual
performance gain at validation time, but this is not true for public
keys. Conversely, for public keys integration with existing
infrastructure matters, but R points are purely internal.
This affects BIP 340 and 341.
2. Nonce generation
All other semantical changes are around more secure nonce generation
in BIP 340, dealing with various failure cases:
* Since the public key signed for is included in the signature
challenge hash, implementers will likely be eager to use precomputed
values for these (otherwise an additional EC multiplication is
necessary at signing time). If that public key data happens to be
gathered from untrusted sources, it can lead to trivial leakage of the
private key - something that Greg Maxwell started a discussion about
on the moderncrypto curves list:
https://moderncrypto.org/mail-archive/curves/2020/001012.html. We
believe it should therefore be best practice to include the public key
also in the nonce generation, which largely mitigates this problem.
* To protect against fault injection attacks it is recommended to
include actual signing-time randomness into the nonce generation
process. This was mentioned already, but the update elaborates much
more about this, and integrates this randomness into the standard
signing process.
* To protect against differential power analysis, a different way of
mixing in this randomness is used (masking the private key completely
with randomness before continuing, rather than hashing them together,
which is known in the literature to be vulnerable to DPA in some
scenarios).
3. New tagged hash tags
To make sure that any code written for the earlier BIP text fails
consistently, the tags used in the tagged hashes in BIP 340 are
changed as well.
What do people think?
--
Pieter

2023-06-07 18:20:23

- reply

📅 Original date posted:2019-08-19
📝 Original message:Hi all,
Miniscript is a project we've been working on for the past year or so,
and is now at a stage where I'd like to get it some more attention. It is joint
work with Andrew Poelstra and Sanket Sanjalkar.
It's a language for writing (a subset of) Bitcoin Scripts in a structured way,
enabling analysis, composition, generic signing and more.
For example the script
<A> OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 <hash160(B)>
OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF
in Miniscript notation would be
or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))
making it human (engineer?) readable that this is a script that permits A to
take the coins at any time, and B after 1 day. A full description of the
language can be found on the project website http://bitcoin.sipa.be/miniscript
Using Miniscript it's possible to:
* Write descriptors for addresses for scripts that implement things more
complicated than multisig.
* Make software that can deal with composition of policies (e.g. have funds
in a 2-of-3 setup where one of the 3 "keys" is itself a policy that involves
perhaps multiple devices and timeouts).
* Compile complex spending policies to efficient scripts.
* Figure out under what necessary and/or sufficient conditions a script can be
satisfied.
* Given signatures for a sufficient set of keys (and hash preimages, if needed),
generically construct a witness for arbitrary scripts, without metadata
apart from the script itself and public keys appearing in it. This means
generic PSBT signers are possible for this class of scripts.
* Compute the bounds on the size of a witness for arbitrary scripts.
* Perform static analysis to see if any of Script's resource limitations
(ops limit, stack size, ...) might interfere with the ability to spend.
* Who knows what else...
We have two implementations:
* a C++ one (https://github.com/sipa/miniscript)
* a Rust library (https://github.com/apoelstra/rust-miniscript).
The implementations are a work in progress, but through large scale randomized
tests we have confidence that the language design and associated witnesses are
compatible with the existing consensus and standardness rules.
To be clear: Miniscript is designed for Bitcoin as it exists today (primarily
P2WSH), and does not need any consensus changes. That said, we plan to extend
the design to support future script changes Bitcoin may include.
Cheers,
--
Pieter

2023-06-07 18:20:17

- reply

📅 Original date posted:2019-08-09
📝 Original message:Hello all,
It has been suggested [1] to drop the Y oddness bit in the witness
program for Taproot outputs. This seems like a worthwhile change, as:
* The bit doesn't actually contribute to security.
* It avoids Taproot outputs from being more expensive to create than v0 P2WSH.
* It doesn't preclude future changes that would still need the
additional byte anyway.
In exploring that option, Jonas Nick found that it seems cleanest [2]
to actually introduce a type of 32-byte public keys (which implicitly
have an even Y coordinate) in bip-schnorr, with associated signing and
verification logic that are distinct from the 33-byte variant.
This makes me wonder if we need 33-byte public keys at all.
So I'd like to hear opinions about modifying bip-schnorr to only
define 32-byte public keys. The implications of that would be:
* bip-schnorr public keys wouldn't be exactly the same as ECDSA public
keys, however all derivation logic would still apply (BIP32,
mnemonics, xpubs, ... would still exist and be compatible - just the
first pubkey byte would be dropped at the end).
* The Q point in bip-taproot (the one going in the scriptPubKey) would
just follow the 32-byte pubkey encoding, rather than needing a 33rd
byte.
* The P point in bip-taproot (the internal key revealed during script
path) would become just a 32-byte public key (and we can drop the one
bit in the control block to transmit the oddness of the Y coordinate
of P).
* In order to permit batch verification of the P to Q tweaking for
script-path spending, another control block bit is now needed, namely
one that indicates whether a negation was needed to make P+H(P||m)*G's
Y coordinate even.
* All public keys inside bip-tapscript would also become 32-bytes. If
desired, the "upgradable public key" construction in bip-tapscript can
be kept, by triggering based on the length of public keys (rather than
based on their first byte).
One question is whether it's worth such a change to bip-schnorr at
this point. We've purposefully never progressed it past draft since
publishing [3], but it has been a while. If necessary, it's possible
to keep verification compatible by still hashing the implied "even"
byte inside the scheme (which commits to the pubkey), but if we're
going to change things, it's perhaps best to do it as cleanly as
possible and also drop that byte.
Opinions?
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html
[2] https://github.com/sipa/bips/pull/52
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
Cheers,
--
Pieter

2023-06-07 18:19:30

- reply

📅 Original date posted:2019-07-19
📝 Original message:On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hello Mike,
>
> Mike Brooks via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
>
> > Motivation
> >
> > Giving scripts the ability to refer to data on the blockchain will reduce
> > transaction sizes because key material does not have to be repeated in
> > every Script. Users of the network are rewarded with smaller transaction
> > sizes, and miners are able to fit more transactions into new blocks.
> > Pointers are a common feature and it felt like this was missing from
> > Bitcoin Script.
>
> This would incentivize address re-use which would be bad for
> fungibility. It appears you're trying to optimize a use case which is
> already discouraged :(
>
Furthermore, right now block validation does not require access to the
whole historical chain (only to the set of unspent outputs), so a change
like this would massively increase storage requirements for validation.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190719/a14353cf/attachment-0001.html>

2023-06-07 18:18:23

- reply

📅 Original date posted:2019-05-26
📝 Original message:On Sun, May 26, 2019, 07:07 Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I realized recently that my segwit implementation was not correct,
> basically some time ago, wrongly reading the specs (and misleaded by
> what follows), I thought that scriptsig would go into witness data as it
> was, but that's not the case, op_pushdata is replaced by varlen
>
> Now reading correctly the specs, they seem to be not totally correct,
> then the first question is: why OP_0 is 00 in witness data and not 0100?
> Does this apply to other op_codes? This does not look logical at all
>
> The second question is: why for non segwit inputs there is a 00 length
> in segwit data, what is the rational for that? It should just be nothing
> since you don't need this to reconciliate things
>
This is a question that belongs on https://bitcoin.stackexchange.com, not
this list.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190526/7df58353/attachment.html>

2023-06-07 18:18:14

- reply

📅 Original date posted:2019-05-23
📝 Original message:On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in block height, such that it is valid after the difficulty adjusted block in the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into.
> The output script may then decide comparing that value with a strike which key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered the bet.
> The winner would broadcast.
If the difficulty can be directly observed by the script language, you
would need to re-evaluate all scripts in unconfirmed transactions
whenever the difficulty changes. This complicates implementation of
mempools, but it also makes reasoning about validity of (chains of)
unconfirmed transactions harder, as an unconfirmed predecessor may
have conditions that change over time.
For things like block time/height, this is solved by not having the
script itself observe the context state directly, but instead having
an assertion on the state outside of script (nLockTime for absolute
time/height and nSequence for relative), and then having opcodes
inside script that observe the assertion (OP_CLTV and OP_CSV). By
doing so, script validity is a single context-free yes or not that can
be evaluated once, and the variable part is just transaction-level
reasoning that doesn't involve a full script interpreter.
Additionally, the supported assertions are restricted in such a way
that if they are true within a particular block, they're also true in
any descendant, removing the complexity of reasoning about validity
(apart from the inevitable reasoning about possible double-spend
before confirmation).
I feel a similar construction is needed for observing block
difficulty. This can be done by either having an opcode that as a side
effect of execution "posts" an assertion (e.g. "difficulty at block
height X is at least Y"), instead of putting the difficulty on the
stack. An alternative is having the assertion be part of the
transaction structure (for example in the annex we propose in
bip-taproot), and having an opcode that observes the difficulty
assertion inside script.
I don't have a strong opinion either way on the usefulness of having
difficulty-dependent transaction/scripts.
Cheers,
--
Pieter

2023-06-07 18:15:20

- reply

📅 Original date posted:2018-11-28
📝 Original message:On Mon, 19 Nov 2018 at 14:37, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Here is a combined proposal:
> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and SIGHASH_SCRIPTMASK.
> * A new opcode OP_MASK is added, which acts as a NOP during execution.
> * The sighash is computed like in BIP143, but:
> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode the subsequent opcode/push is removed.
> * The scriptPubKey being spent is added to the sighash, unless SIGHASH_SCRIPTMASK is set.
> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is set.
> * hashPrevouts, hashSequence, and outpoint are set to null when SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
Thanks for all the input so far. Going over the suggestions and other ideas:
* OP_MASK should be required to be followed by a push, as suggested by
Anthony Towns. The alternative would permit substituting arbitrary
opcodes for masked pushes, which is at least very hard to reason
about. This would effectively turn it into a multi-byte OP_MASKEDPUSH
opcode.
* It's probably better to sign the amounts of all inputs, as suggested
by Johnson Lau. As that would cause default sighashes to sign all
input and output amounts, is there still a need to sign the tx fee
explicitly? Or in other words, are there situations where changing the
set of inputs or outputs after signing is desired, but the net
difference between them cannot change? If not, that would remove the
need for NOFEE.
* Do we need to keep the rule that sequence values of other inputs are
only signed with default sighash? It feels cleaner to always sign the
sequence values of all inputs that are included in the sighash anyway
(so all of them, unless ANYONECANPAY or NOINPUT, which would make it
sign only the current input's sequence value). If NOINPUT also blanks
the sequence values (as currently specified by BIP118), and all input
amounts are signed, that would make amounts/sequence values always be
treated identically.
* If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of
them can be encoded in just 2 bits using the
PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns
suggested.
* Regarding the discussion about preventing signatures from being
rebound to a different script(path)/checksig:
* With MAST there is indeed less need for this, but at least
single-tree MAST constructions cannot replace all script branches (a
script with 40 IF/THEN/ELSE constructions may have 2^40 different
execution paths, for which computing a Merkle tree is intractable).
* Just signing the opcode position of the CHECKSIG operator isn't
enough for all cases either. For example, you could have a complex
nested set of branches that puts a number of pubkeys on the stack, and
then a CHECKMULTISIG after the last ENDIF to verify all of them. In
such a situation, if the same key can occur in multiple combinations,
you still may want to prevent a signature generated for one
combination from being rebindable to the same key in another
combination. I believe that signing the opcode position plus the
true/false condition of all previous(?) IF statements is probably
sufficient to achieve that, but it would also introduce unnecessary
complexity for signers in most cases (see next point).
* Thinking about signing code, adding these sort of execution trace
commitments to the sighash means they need to know which checksig
operator etc. they are signing for. I believe that in practice for
example HW devices will just whatever position the wallet indicated,
rather than verifying it corresponds with a particular intended code
path. Preventing rebinding isn't very useful if an attacker can make
you bind to the wrong thing regardless, so I'm not convinced this is
even worth having by default.
* An alternative (not sure who suggested it) is to simply make every
CHECKSIG sign the opcode position of the last executed CODESEPARATOR
(and remove the earlier cut-of-scriptCode effect of CODESEPARATOR).
This gives a simple (but somewhat limited) way for scripts that need
to prevent certain kinds of cross-execution-trace rebinding.
A few misc ideas:
* (Taken from https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki)
For a default sign-everything sighash, the sighash byte can be
dropped.
* For the commitments to the scriptPubKey and scriptCode, an
intermediary hash should be used (so the data included in the sighash
includes a hash of those, rather than the script directly). This
prevents a blow up in hashing time for large scripts with many
different sighash types in its signatures.
* When masking the scriptCode, the push opcode immediately following
OP_MASKEDPUSH can be replaced by OP_VERIF (which will never collide
with any real script, as OP_VERIF makes a script invalid even when
occurring in an unexecuted branch).
* Sighashes (and really all new hashes that are introduced) should be
prefixed with a fixed 64-byte array as "tag", chosen to not collide
with any existing use of SHA256 in Bitcoin, to prevent signatures from
being re-interpretable as something else. Picking 64 bytes as tag size
means it can be efficiently implemented as just a modified SHA256 IV.
So a combined proposal:
* All existing sighash flags, plus NOINPUT and MASK
(ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
* A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
failing if not immediately followed by a push, or when appearing as
last opcode in the script.
* Signatures are 64 plus an optional sighash byte. A missing sighash
byte implies ALL, and ALL cannot be specified explicitly.
* The sighash is computed from the following:
* A 64-byte constant tag
* Data about the spending transaction:
* The transaction version number
* The hash of txins' prevouts+amounts+sequences (or nothing if ANYONECANPAY)
* The hash of all txouts (or just the corresponding txout if
SINGLE; nothing if NONE)
* The transaction locktime
* Data about the output being spent:
* The prevout (or nothing if NOINPUT)
* The amount
* The sequence number
* The hash of the scriptPubKey (or nothing if MASK)
* Data about the script being executed:
* The hash of the scriptCode (after masking out, if MASK is set)
* The opcode number of the last executed OP_CODESEPARATOR (or
0xFFFFFFFF if none)
* The sighash mode
Cheers,
--
Pieter

2023-06-07 18:13:32

- reply

📅 Original date posted:2018-07-04
📝 Original message:On Wed, Jul 4, 2018 at 6:19 AM, matejcik <jan.matejek at satoshilabs.com> wrote:
> hello,
>
> we still have some concerns about the BIP as currently proposed - not
> about the format or data contents, but more about strictness and
> security properties. I have raised some in the previous e-mails, but
> they might have been lost in the overall talk about format.
>
> * Choosing from duplicate keys when combining.
> We believe that "choose whichever value it wishes" is not a good
> resolution strategy. We propose to either change this to "in case of
> conflicts, software MUST reject the conflicting PSBTs", or explain in
> more detail why picking at random is a safe choice.
Outlawing conflicting values would imply forcing all Signers to
implement fixed deterministic nonce generation, which I don't think it
very desirable. Otherwise PSBTs that got copied and signed and
combined again may fail. So I think we should see it the other way: we
choose the keys in such a way that picking arbitrarily is safe. If
there really is a future extension for which it would not be the case
that picking arbitrarily is acceptable, more data can be moved to the
keys, and leave the actual resolution strategy to the Finalizer. That
way Combiners can remain dumb and not need script-specific logic in
every interaction.
An alternative would be to have a fixed resolution strategy (for
example, when combining multiple PSBTs, pick the value from the first
one that has a particular key set), but I don't think this adds very
much - if picking the first is fine, picking a arbitrary one should be
fine too.
> * Signing records with unknown keys.
> There's been some talk about this at start, but there should be a clear
> strategy for Signers when unknown fields are encountered. We intend to
> implement the rule: "will not sign an input with any unknown fields
> present".
> Maybe it is worth codifying this behavior in the standard, or maybe
> there should be a way to mark a field as "optional" so that strict
> Signers know they can _safely_ ignore the unknown field.
Can you envision a situation in which this is needed? In every
scenario I can come up with, the worst that can happen is that the
resulting signature is just invalid. For example, if PSBT existed
before segwit, and then was later extended to support it, a pre-segwit
signer would not recognize that BIP143 would need to be used for
segwit inputs, and produce signatures using the old sighashing
algorithm. The result is just an invalid signature.
I believe that what you're trying to accomplish is preventing signing
something you don't understand, but that's an independent issue.
Signers generally will want to inspect the transaction they're
signing, or ask for confirmation w.r.t. fees or payment destinations
involved. The case where unknown fields are present for a reason you'd
want to withhold signing for will generally also just be the situation
where you don't understand the transaction you're signing.
Here is (perhaps far fetched) example of why it may not be desirable
to reject unknown fields when signing. Imagine an extension is defined
which adds pay-to-contract derivation for keys (Q = P + H(Q||C)G);
this would be a field similar to the current BIP32 derivation one, but
instead give a base key P and a contract C. Now say there is a 2-of-2
multisig in which you're one signer, and the other signer is (unknown
to you) using P2C. After the other party Updating, the input would
contain a P2C field which you don't understand - but it also isn't
something you care about or affects you.
I would not be opposed to having fields with an explicit flag bit that
says "Don't sign if you don't understand this", but I expect that that
can also be left for future extensions.
> * Fields with empty keys.
> This might be inferred from the definition, but is probably worth
> spelling out explicitly: If a field definition states that the key data
> is empty, an implementation MUST enforce this and reject PSBTs that
> contain non-empty data.
> We suggest adding something to the effect of:
> "If a key or value data in a field doesn't match the specified format,
> the PSBT is invalid. In particular, if key data is specified as "none"
> but the key contains data beyond the type specifier, implementation MUST
> reject the PSBT."
> (not sure about the languge, this should of course allow processing
> unknown fields)
Completely agree here. Any implementation that understands a
particular field must enforce whatever structure the field is known to
have.
> * "Combiner can detect inconsistencies"
> Added in response to this comment [1], the current wording looks like
> it's describing what the Combiner is _capable of_, as opposed to
> prescribing what the combiner is _allowed to_ do.
> We suggest changing to something like:
> "For every field type that the Combiner understands, it MAY also refuse
> to combine PSBTs that have inconsistencies in that field, or cause a
> conflict when combined."
Agree, just because Combiners are expected to work correctly on
unknown fields doesn't mean they can't enforce extra consistency
checks on known fields.
Cheers,
--
Pieter

2023-06-07 18:13:14

- reply

📅 Original date posted:2018-06-27
📝 Original message:On Wed, Jun 27, 2018, 07:04 matejcik <jan.matejek at satoshilabs.com> wrote:
> hello,
>
> On 26.6.2018 22:30, Pieter Wuille wrote:
> >> (Moreover, as I wrote previously, the Combiner seems like a weirdly
> >> placed role. I still don't see its significance and why is it important
> >> to correctly combine PSBTs by agents that don't understand them. If you
> >> have a usecase in mind, please explain.
> >
> > Forward compatibility with new script types. A transaction may spend
> > inputs from different outputs, with different script types. Perhaps
> > some of these are highly specialized things only implemented by some
> > software (say HTLCs of a particular structure), in non-overlapping
> > ways where no piece of software can handle all scripts involved in a
> > single transaction. If Combiners cannot deal with unknown fields, they
> > won't be able to deal with unknown scripts.
>
> Record-based Combiners *can* deal with unknown fields. Either by
> including both versions, or by including one selected at random. This is
> the same in k-v model.
>
Yes, I wasn't claiming otherwise. This was just a response to your question
why it is important that Combiners can process unknown fields. It is not an
argument in favor of one model or the other.
> combining must be done independently by Combiner implementations for
> > each script type involved. As this is easily avoided by adding a
> > slight bit of structure (parts of the fields that need to be unique -
> > "keys"), this seems the preferable option.
>
> IIUC, you're proposing a "semi-smart Combiner" that understands and
> processes some fields but not others? That doesn't seem to change
> things. Either the "dumb" combiner throws data away before the "smart"
> one sees it, or it needs to include all of it anyway.
>
No, I'm exactly arguing against smartness in the Combiner. It should always
be possible to implement a Combiner without any script specific logic.
> No, a Combiner can pick any of the values in case different PSBTs have
> > different values for the same key. That's the point: by having a
> > key-value structure the choice of fields can be made such that
> > Combiners don't need to care about the contents. Finalizers do need to
> > understand the contents, but they only operate once at the end.
> > Combiners may be involved in any PSBT passing from one entity to
> > another.
>
> Yes. Combiners don't need to care about the contents.
> So why is it important that a Combiner properly de-duplicates the case
> where keys are the same but values are different? This is a job that,
> AFAICT so far, can be safely left to someone along the chain who
> understands that particular record.
>
That's because PSBTs can be copied, signed, and combined back together. A
Combiner which does not deduplicate (at all) would end up having every
original record present N times, one for each copy, a possibly large blowup.
For all fields I can think of right now, that type of deduplication can be
done through whole-record uniqueness.
The question whether you need whole-record uniqueness or specified-length
uniqueness (=what is offered by a key-value model) is a philosophical one
(as I mentioned before). I have a preference for stronger invariants on the
file format, so that it becomes illegal for a PSBT to contain multiple
signatures for the same key for example, and implementations do not need to
deal with the case where multiple are present.
It seems that you consider the latter PSBT "invalid". But it is well
> formed and doesn't contain duplicate records. A Finalizer, or a
> different Combiner that understands field F, can as well have the rule
> "throw away all but one" for this case.
>
It's not about considering. We're writing a specification. Either it is
made invalid, or not.
In a key-value model you can have dumb combiners that must pick one of the
keys in case of duplication, and remove the necessity of dealing with
duplication from all other implementations (which I consider to be a good
thing). In a record-based model you cannot guarantee deduplication of
records that permit repetition per type, because a dumb combiner cannot
understand what part is supposed to be unique. As a result, a record-based
model forces you to let all implementations deal with e.g. multiple partial
signatures for a single key. This is a minor issue, but in my view shows
how records are a less than perfect match for the problem at hand.
To repeat and restate my central question:
> Why is it important, that an agent which doesn't understand a particular
> field structure, can nevertheless make decisions about its inclusion or
> omission from the result (based on a repeated prefix)?
>
Again, because otherwise you may need a separate Combiner for each type of
script involved. That would be unfortunate, and is very easily avoided.
Actually, I can imagine the opposite: having fields with same "key"
> (identifying data), and wanting to combine their "values" intelligently
> without losing any of the data. Say, two Signers producing separate
> parts of a combined-signature under the same common public key?
>
That can always be avoided by using different identifying information as
key for these fields. In your example, assuming you're talking about some
form of threshold signature scheme, every party has their own "shard" of
the key, which still uniquely identifies the participant. If they have no
data that is unique to the participant, they are clones, and don't need to
interact regardless.
> In case of BIP32 derivation, computing the pubkeys is possibly
> > expensive. A simple signer can choose to just sign with whatever keys
> > are present, but they're not the only way to implement a signer, and
> > even less the only software interacting with this format. Others may
> > want to use a matching approach to find keys that are relevant;
> > without pubkeys in the format, they're forced to perform derivations
> > for all keys present.
>
> I'm going to search for relevant keys by comparing master fingerprint; I
> would expect HWWs generally don't have index based on leaf pubkeys.
> OTOH, Signers with lots of keys probably aren't resource-constrained and
> can do the derivations in case of collisions.
>
Perhaps you want to avoid signing with keys that are already signed with?
If you need to derive all the keys before even knowing what was already
signed with, you've already performed 80% of the work.
> If you take the records model, and then additionally drop the
> > whole-record uniqueness constraint, yes, though that seems pushing it
> > a bit by moving even more guarantees from the file format to
> > application level code.
>
> The "file format" makes no guarantees, because the parsing code and
> application code is the same anyway. You could say I'm proposing to
> separate these concerns ;)
>
Of course a file format can make guarantees. If certain combinations of
data in it do not satsify the specification, the file is illegal, and
implementations do not need to deal with it. Stricter file formats are
easier to deal with, because there are less edge cases to consider.
To your point: proto v2 afaik has no way to declare "whole record
uniqueness", so either you drop that (which I think is unacceptable - see
the copy/sign/combine argument above), or you deal with it in your
application code.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180627/fecd0346/attachment-0001.html>

2023-06-07 18:13:13

- reply

📅 Original date posted:2018-06-26
📝 Original message:On Tue, Jun 26, 2018 at 8:33 AM, matejcik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm still going to argue against the key-value model though.
>
> It's true that this is not significant in terms of space. But I'm more
> concerned about human readability, i.e., confusing future implementers.
> At this point, the key-value model is there "for historical reasons",
> except these aren't valid even before finalizing the format. The
> original rationale for using key-values seems to be gone (no key-based
> lookups are necessary). As for combining and deduplication, whether key
> data is present or not is now purely a stand-in for a "repeatable" flag.
> We could just as easily say, e.g., that the high bit of "type" specifies
> whether this record can be repeated.
I understand this is a philosophical point, but to me it's the
opposite. The file conveys "the script is X", "the signature for key X
is Y", "the derivation for key X is Y" - all extra metadata added to
inputs of the form "the X is Y". In a typed record model, you still
have Xes, but they are restricted to a single number (the record
type). In cases where that is insufficient, your solution is adding a
repeatable flag to switch from "the first byte needs to be unique" to
"the entire record needs to be unique". Why just those two? It seems
much more natural to have a length that directly tells you how many of
the first bytes need to be unique (which brings you back to the
key-value model).
Since the redundant script hashes were removed by making the scripts
per-input, I think the most compelling reason (size advantages) for a
record based model is gone.
> (Moreover, as I wrote previously, the Combiner seems like a weirdly
> placed role. I still don't see its significance and why is it important
> to correctly combine PSBTs by agents that don't understand them. If you
> have a usecase in mind, please explain.
Forward compatibility with new script types. A transaction may spend
inputs from different outputs, with different script types. Perhaps
some of these are highly specialized things only implemented by some
software (say HTLCs of a particular structure), in non-overlapping
ways where no piece of software can handle all scripts involved in a
single transaction. If Combiners cannot deal with unknown fields, they
won't be able to deal with unknown scripts. That would mean that
combining must be done independently by Combiner implementations for
each script type involved. As this is easily avoided by adding a
slight bit of structure (parts of the fields that need to be unique -
"keys"), this seems the preferable option.
> ISTM a Combiner could just as well combine based on whole-record
> uniqueness, and leave the duplicate detection to the Finalizer. In case
> the incoming PSBTs have incompatible unique fields, the Combiner would
> have to fail anyway, so the Finalizer might as well do it. Perhaps it
> would be good to leave out the Combiner role entirely?)
No, a Combiner can pick any of the values in case different PSBTs have
different values for the same key. That's the point: by having a
key-value structure the choice of fields can be made such that
Combiners don't need to care about the contents. Finalizers do need to
understand the contents, but they only operate once at the end.
Combiners may be involved in any PSBT passing from one entity to
another.
> There's two remaining types where key data is used: BIP32 derivations
> and partial signatures. In case of BIP32 derivation, the key data is
> redundant ( pubkey = derive(value) ), so I'd argue we should leave that
> out and save space. In case of partial signatures, it's simple enough to
> make the pubkey part of the value.
In case of BIP32 derivation, computing the pubkeys is possibly
expensive. A simple signer can choose to just sign with whatever keys
are present, but they're not the only way to implement a signer, and
even less the only software interacting with this format. Others may
want to use a matching approach to find keys that are relevant;
without pubkeys in the format, they're forced to perform derivations
for all keys present.
And yes, it's simple enough to make the key part of the value
everywhere, but in that case it becomes legal for a PSBT to contain
multiple signatures for a key, for example, and all software needs to
deal with that possibility. With a stronger uniqueness constraint,
only Combiners need to deal with repetitions.
> Thing is: BIP174 *is basically protobuf* (v2) as it stands. If I'm
> succesful in convincing you to switch to a record set model, it's going
> to be "protobuf with different varint".
If you take the records model, and then additionally drop the
whole-record uniqueness constraint, yes, though that seems pushing it
a bit by moving even more guarantees from the file format to
application level code. I'd like to hear opinions of other people who
have worked on implementations about changing this.
Cheers,
--
Pieter

2023-06-07 18:13:09

- reply

📅 Original date posted:2018-06-22
📝 Original message:On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have personally implemented this spec on an embedded micro, as
> the signer and finalizer roles, and written multiple parsers for
> it as well. There is nothing wrong with it, and it perfectly meets
> my needs as a hardware wallet.
This is awesome to hear. We need to hear from people who have comments
or issues they encounter while implementing, but also cases where
things are fine as is.
> So, there is a good proposal already spec'ed and implemented by
> multiple parties. Andrew has been very patiently shepherding the PR
> for over six months already.
>
> PSBT is something we need, and has been missing from the ecosystem
> for a long time. Let's push this out and start talking about future
> versions after we learn from this one.
I understand you find the suggestions being brought up in this thread
to be bikeshedding over details, and I certainly agree that "changing
X will gratuitously cause us more work" is a good reason not to make
breaking changes to minutiae. However, at least abstractly speaking,
it would be highly unfortunate if the fact that someone implemented a
draft specification results in a vested interest against changes which
may materially improve the standard.
In practice, the process surrounding BIPs' production readiness is not
nearly as clear as it could be, and there are plenty of BIPs actually
deployed in production which are still marked as draft. So in reality,
truth is that this thread is "late", and also why I started the
discussion by asking what the state of implementations was. As a
result, the discussion should be "which changes are worth the hassle",
and not "what other ideas can we throw in" - and some of the things
brought up are certainly the latter.
So to get back to the question what changes are worth the hassle - I
believe the per-input derivation paths suggested by matejcik may be
one. As is written right now, I believe BIP174 requires Signers to
pretty much always parse or template match the scripts involved. This
means it is relatively hard to implement a Signer which is compatible
with many types of scripts - including ones that haven't been
considered yet. However, if derivation paths are per-input, a signer
can just produce partial signatures for all keys it has the master
for. As long as the Finalizer understands the script type, this would
mean that Signers will work with any script. My guess is that this
would be especially relevant to devices where the Signer
implementation is hard to change, like when it is implemented in a
hardware signer directly.
What do you think?
Cheers,
--
Pieter

2023-06-07 18:13:06

- reply

📅 Original date posted:2018-06-21
📝 Original message:On Thu, Jun 21, 2018 at 4:29 AM, matejcik <jan.matejek at satoshilabs.com> wrote:
> In the case of everything per-input, the naive Signer can do this:
> 1. (in the global section) pre-serialize the transaction
> 2. (in each input) find and fill out scriptPubKey from the provided UTXO
> 3. (for a given BIP32 path) check if the master fingerprint matches
> mine, if yes, derive secret key, output pubkey, signature
> 4. goto 3 (more keys per input), goto 2 (next input)
>
> Note that this flow works perfectly for multisig; it’s going to be the
> job of a Finalizer to build the final scriptSig, but each input can have
> multiple partial signatures -- and, interestingly, the naive Signer
> doesn’t even need to know about multisig.
Ah, you're thinking of an even simpler signer than I was imagining. I
don't think this works in general, because the hash being signed
depends on the structure of the script. For example, if it is P2SH, it
is the redeemscript that goes into the scriptCode serialization rather
than the scriptPubKey. If it is segwit, BIP143 serialization needs to
be used, etc. It may work if your signing is restricted to just one of
those structures, though.
> A less naive Signer will want to check things, maybe derive a scriptSig
> itself and check if it matches the given hash, etc., but it can do this
> all in place. You go linearly through the signing flow and place a
> couple strategic assertions along the way.
Right - but I think anything but the simplest signer must do this,
just to be able to distinguish between different kinds of signature
hashing.
But you're right, having per-input redeemscript/witnessscript
simplifies things still - instead of needing to look a script hash in
a map, you can just compare it with *the* redeemscript/witnessscript.
> However, if the data is global, as is now, it gets more complicated:
> 1. (in the global section) pre-serialize the transaction, prefill lookup
> tables
> 2. (for a given BIP32 path) check if mine, then derive public key and
> store in a dictionary
> 3. (for each input) find _and parse_ scriptPubKey, extract (PK or)
> script hash
> 4. lookup redeem script based on script-hash; if not found, goto 2; if
> found, parse out public key
> 5. lookup public key in the BIP32 dictionary; if not found, goto 2
> 6. output pubkey, signature
I understand your point now. I hadn't considered the possibility of
just signing with all BIP32 derivation paths given for which the
master matches, instead of extracting pubkeys/pkhs from the script.
That's a major simplification for signers indeed. I do think you need
some conditions before to determine the script structure (see above),
but this is a good point in favour of making the derivation paths
per-input.
> In general, you seem to focus a lot on the role of Combiners, esp.
> simple Combiners. To me, that doesn’t look like a significant role. As I
> envision it, a Combiner really doesn’t need to do anything more
> complicated than merge and deduplicate records, simply based on the
> uniqueness of the whole record.
It's more a side-effect of focusing on forward compatibility. I expect
that we will have transactions with inputs spending different kinds of
outputs, and some signers may not be able to understand all of them.
However, as long as the design goal of having Combiners function
correctly for things they don't understand, everything should be able
to work together fine.
> It’s the Finalizer’s job to reconstruct and validate the result. Also
> ISTM if something messes up the PSBT (such as including multiple
> conflicting fields anywhere), it’s OK to leave it to Finalizer to fail.
Agree.
> An aside to this in particular, I’ve been thinking about the requirement
> to share derivation paths and public keys with the Creator. The spec
> assumes that this will happen; you’re talking about providing full
> xpub+chaincode too. At least, the Creator must prefill BIP32 paths and
> master key fingerprints. Possibly also prefill public keys in the redeem
> scripts?
>
> This might not be an improvement proposal, but a point worth being
> raised and maybe explained in the spec. Perhaps the original Creator
> doesn’t have access to this data, and delegates this to some
> “sub-Creators” - I imagine a coordinator sending a PSBT to signing
> parties, each of which acts as a sub-Creator (fills out derivation paths
> and public keys) and a Signer (forwarding to a HWW). Some of the
> discussion even suggests some sort of generic “key derivation field”
> with arbitrary contents - fingerprint + bip32 path? xpub + chain code?
> derivation points? encrypted xprv?
That makes sense - I think we've already touched this when discussing
the requirement for UTXOs to be added. Perhaps those aren't added by
the Creator, but by some index server. The same could be true for the
scripts or derivations paths.
And indeed, most of the information in the derivation paths is
effectively opaque to the Creator - it's just some data given out by
the Signer about its keys that gets passed back to it so it can
identify the key. There is benefit in keeping it in a fixed structure
(like xpub/chaincode, or fingerprint + derivation indexes), to
guarantee compatibility between multiple signer implementations with
access to the same key.
On Tue, Jun 19, 2018 at 5:39 PM, Jason Les via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>>Hex encoding?
>
> I was hoping for some standard here was well and I agree using something
> more compact than hex is important. My understanding is Z85 is better for
> use with JSON than Base64, which is probably a good benefit to have here.
Both Base64 and Z85 can be stored in JSON strings without quoting
(neither uses quotation characters or backslashes), but Z85 is
slightly more compact (Z85 is 5 characters for 4 bytes, Base64 is 4
characters for 3 bytes). Both use non-alphanumeric characters, so I
don't think there is much difference w.r.t. copy-pastability either.
Z85 is far less common though.
On Thu, Jun 21, 2018 at 4:44 AM, Tomas Susanka via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I think here it makes sense because there can actually only be (up to)
>> one redeemscript and (up to) one witnessscript. So if we made those
>> per-input and per-output, it may simplify signers as they don't need a
>> table lookup to find the correct one. That would also mean we can drop
>> their hashes, even if we keep a key-value model.
> Yes, indeed. Just to clarify: in the first sentence you mean "per
> output", right? There can actually only be (up to) one redeemscript and
> (up to) one witnessscript *per output*.
Up to one per output, and up to one per input - indeed.
On Thu, Jun 21, 2018 at 7:32 AM, Tomas Susanka via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> A question to consider is,
>>> will there be more per-output data? If yes, it might make sense to have
>>> an output section.
>> I think it is unlikely that there would be anymore per-output data.
>
> Hmm, upon further reflection, maybe it's not even worth including *any*
> per-output data, aside from what the original transaction contains.
>
> The output redeem script is either:
> - unknown, because we have received only an address from the receiver
> - or it is known, because it is ours and in that case it doesn’t make
> sense to include it in PSBT
>
> We got stuck on the idea of the Creator providing future (output)
> redeem/witness scripts. But that seems to be a minority use case and can
> be solved efficiently via the same channels that coordinate the PSBT
> creation. Sorry to change opinions so quickly on this one.
Perhaps you're missing the reason for having output scripts? It is so
that signers that wish to known the amounts transferred can be told
which outputs of the to-be transaction are change, and thus shouldn't
be counted towards the balance. By providing the scripts and
derivation paths in a PSBT, the Creator can prove to the Signer that
certain outputs do not actually move funds to some other entity.
Based on the points before, my preference is having everything
per-input and per-output except the transaction (with empty
scriptSig/witness) itself, and having exactly one set/map per input
and output (which may include a "finalized scriptSig/witness field"
for finalized inputs). The overhead of having at least one separator
byte for every input and output in the transaction is at most a few
percent compared to the data in the transaction itself. If size is
really an issue (but I think we've already established that small size
gains aren't worth much extra complexity), we could also serialize the
transaction without scriptSigs/witnesses (which are at least one byte
each, and guaranteed to be empty).
I'm unsure about typed record vs. key-value model. If we'd go with a
per-input script approach, the key would just be a single byte ("the
redeemscript" and "the witnessscript"), so the advantage of being able
to drop the script hashes applies equally to both models. After that,
it seems the only difference seems to be that a well-defined prefix of
the records is enforced to be unique as opposed to the entire record
being enforced to be unique. I don't think there is much difference in
complexity, as Combiners and Signers still need to enforce some kind
of uniqueness even in a typed records model.
Cheers,
--
Pieter

2023-06-07 18:13:04

- reply

📅 Original date posted:2018-06-19
📝 Original message:On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
Thanks for your comments so far. I'm very happy to see people dig into
the details, and consider alternative approaches.
> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we
> know, which BIP-32 path goes to which input? The only idea that comes to
> my mind is that we should match the input's scriptPubKey's pubkey to
> this 0x03's key (the public key).
> If our understanding is correct, the BIP-32 path is global to save space
> in case two inputs share the same BIP-32 path? How often does that
> happen? And in case it does, doesn't it mean an address reuse which is
> discouraged?
Yes, the reason is address reuse. It may be discouraged, but it still
happens in practice (and unfortunately it's very hard to prevent
people from sending to the same address twice).
It's certainly possible to make them per-input (and even per-output as
suggested below), but I don't think it gains you much. At least when a
signer supports any kind of multisig, it needs to match up public keys
with derivation paths. If several can be provided, looking them up
from a global table or a per-input table shouldn't fundamentally
change anything.
However, perhaps it makes sense to get rid of the global section
entirely, and make the whole format a transaction plus per-input and
per-output extra fields. This would result in duplication in case of
key reuse, but perhaps that's worth the complexity reduction.
> 2) The global items 0x01 (redeem script) and 0x02 (witness script) are
> somewhat confusing. Let's consider only the redeem script (0x01) to make
> it simple. The value description says: "A redeem script that will be
> needed to sign a Pay-To-Script-Hash input or is spent to by an output.".
> Does this mean that the record includes both input's redeem script
> (because we need to sign it), but also a redeem script for the output
> (to verify we are sending to a correct P2SH)? To mix those two seems
> really confusing.
>
> Yet again, adding a new output section would make this more readable. We
> would include the input’s redeem script in the input section and the
> output’s redeem script again in the output section, because they’ll most
> likely differ anyway.
I think here it makes sense because there can actually only be (up to)
one redeemscript and (up to) one witnessscript. So if we made those
per-input and per-output, it may simplify signers as they don't need a
table lookup to find the correct one. That would also mean we can drop
their hashes, even if we keep a key-value model.
> 3) The sighash type 0x03 says the sighash is only a recommendation. That
> seems rather ambiguous. If the field is specified shouldn't it be binding?
Perhaps, yes.
> 4) Is it a good idea to skip records which types we are unaware of? We
> can't come up with a reasonable example, but intuitively this seems as a
> potential security issue. We think we should consider introducing a
> flag, which would define if the record is "optional". In case the signer
> encounters a record it doesn't recognize and such flag is not set, it
> aborts the procedure. If we assume the set model we could change the
> structure to <type><optional flag><length>{data}. We are not keen on
> this, but we wanted to include this idea to see what you think.
Originally there was at least this intuition for why it shouldn't be
necessary: the resulting signature for an input is either valid or
invalid. Adding information to a PSBT (which is what signers do)
either helps with that or not. The worst case is that they simply
don't have enough information to produce a signature together. But an
ignored unknown field being present should never result in signing the
wrong thing (they can always see the transaction being signed), or
failing to sign if signing was possible in the first place. Another
way of looking at it, the operation of a signer is driven by queries:
it looks at the scriptPubKey of the output being spent, sees it is
P2SH, looks for the redeemscript, sees it is P2WSH, looks for the
witnessscript, sees it is multisig, looks for other signers'
signatures, finds enough for the threshold, and proceeds to sign and
create a full transaction. If at any point one of those things is
missing or not comprehensible to the signer, he simply fails and
doesn't modify the PSBT.
However, if the sighash request type becomes mandatory, perhaps this
is not the case anymore, as misinterpreting something like this could
indeed result in an incorrect signature.
If we go down this route, if a field is marked as mandatory, can you
still act as a combiner for it? Future extensions should always
maintain the invariant that a simple combiner which just merges all
the fields and deduplicates should always be correct, I think. So such
a mandatory field should only apply to signers?
> In general, the standard is trying to be very space-conservative,
> however is that really necessary? We would argue for clarity and ease of
> use over space constraints. We think more straightforward approach is
> desired, although more space demanding. What are the arguments to make
> this as small as possible? If we understand correctly, this format is
> not intended for blockchain nor for persistent storage, so size doesn’t
> matter nearly as much.
I wouldn't say it's trying very hard to be space-conservative. The
design train of thought started from "what information does a signer
need", and found a signer would need information on the transaction to
sign, and on scripts to descend into, information on keys to derive,
and information on signatures provided by other participants. Given
that some of this information was global (at least the transaction),
and some of this information was per-input (at least the signatures),
separate scopes were needed for those. Once you have a global scope,
and you envision a signer which looks up scripts and keys in a map of
known ones (like the signing code in Bitcoin Core), there is basically
no downside to make the keys and scripts global - while giving space
savings for free to deduplication.
However, perhaps that's not the right way to think about things, and
the result is simpler if we only keep the transaction itself global,
and everything else per-input (and per-output).
I think there are good reasons to not be gratuitously large (I expect
that at least while experimenting, people will copy-paste these things
a lot and page-long copy pastes become unwieldy quickly), but maybe
not at the cost of structural complexity.
On Tue, Jun 19, 2018 at 7:22 AM, matejcik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> hello,
> this is our second e-mail with replies to Pieter's suggestions.
>
> On 16.6.2018 01:34, pieter.wuille at gmail.com (Pieter Wuille) wrote:
>> * Key-value map model or set model.
> Just to note, we should probably use varint for the <type> field - this
> allows us, e.g., to create “namespaces” for future extensions by using
> one byte as namespace identifier and one as field identifier.
Agree, but this doesn't actually need to be specified right now. As
the key's (and or value's) interpretation (including the type) is
completely unspecified, an extension can just start using 2-byte keys
(as long as the first byte of those 2 isn't used by another field
already).
>> One exception is the "transaction" record, which needs to be unique.
>> That can either be done by adding an exception ("there can only be one
>> transaction record"), or by encoding it separately outside the normal
>> records (that may also be useful to make it clear that it is always
>> required).
>
> This seems to be the case for some fields already - i.e., an input field
> must have exactly one of Non-witness UTXO or Witness Output. So “adding
> an exception” is probably just a matter of language?
Hmm, I wouldn't say so. Perhaps the transaction's inputs and outputs
are chosen by one entity, and then sent to another entity which has
access to the UTXOs or previous transactions. So while the UTXOs must
be present before signing, I wouldn't say the file format itself must
enforce that the UTXOs are present.
However, perhaps we do want to enforce at-most one UTXO per input. If
there are more potential extensions like this, perhaps a key-value
model is better, as it's much easier to enforce no duplicate keys than
it is to add field-specific logic to combiners (especially for
extensions they don't know about yet).
> We’d also like to note that the “number of inputs” field should be
> mandatory - and as such, possibly also a candidate for outside-record field.
If we go with the "not put signatures/witnesses inside the transaction
until all of them are finalized" suggestion, perhaps the number of
inputs field can be dropped. There would be always one exactly for
each input (but some may have the "final script/witness" field and
others won't).
>> * Derivation from xpub or fingerprint
>>
>> For BIP32 derivation paths, the spec currently only encodes the 32-bit
>> fingerprint of the parent or master xpub. When the Signer only has a
>> single xprv from which everything is derived, this is obviously
>> sufficient. When there are many xprv, or when they're not available
>> indexed by fingerprint, this may be less convenient for the signer.
>> Furthermore, it violates the "PSBT contains all information necessary
>> for signing, excluding private keys" idea - at least if we don't treat
>> the chaincode as part of the private key.
>>
>> For that reason I would suggest that the derivation paths include the
>> full public key and chaincode of the parent or master things are
>> derived from. This does mean that the Creator needs to know the full
>> xpub which things are derived from, rather than just its fingerprint.
>
>
> We don’t understand the rationale for this idea. Do you see a scenario
> where an index on master fingerprint is not available but index by xpubs
> is? In our envisioned use cases at least, indexing private keys by xpubs
> (as opposed to deriving from a BIP32 path) makes no sense.
Let me elaborate.
Right now, the BIP32 fields are of the form <master
fingerprint><childidx><childidx><childidx>...
Instead, I suggest fields of the form <master pubkey><master
chaincode><childidx><childidx><childidx>...
The fingerprint in this case is identical to the first 32 bit of the
Hash160 of <master pubkey>, so certainly no information is lost by
making this change.
This may be advantageous for three reasons:
* It permits signers to have ~thousands of master keys (at which point
32-bit fingerprints would start having reasonable chance for
collisions, meaning multiple derivation attempts would be needed to
figure out which one to use).
* It permits signers to index their master keys by whatever they like
(for example, SHA256 rather than Hash160 or prefix thereof).
* It permits signers who don't store a chaincode at all, and just
protect a single private key.
Cheers,
--
Pieter

2023-06-07 18:13:02

- reply

📅 Original date posted:2018-06-15
📝 Original message:Hello all,
given some recent work and discussions around BIP 174 (Partially
Signed Bitcoin Transaction Format) I'd like to bring up a few ideas.
First of all, it's unclear to me to what extent projects have already
worked on implementations, and thus to what extent the specification
is still subject to change. A response of "this is way too late" is
perfectly fine.
So here goes:
* Key-value map model or set model.
This was suggested in this thread:
https://twitter.com/matejcik/status/1002618633472892929
The motivation behind using a key-value model rather than a simple
list of records was that PSBTs can be duplicated (given to multiple
people for signing, for example), and merged back together after
signing. With a generic key-value model, any implementation can remove
the duplication even if they don't understand fields that may have
been added in future extensions.
However, almost the same can be accomplished by using the simpler set
model (the file consists of a set of records, with no duplication
allowed). This would mean that it would technically be legal to have
two partial signatures with the same key for the same input, if a
non-deterministic signer is used.
On the other hand, this means that certain data currently encoded
inside keys can be dropped, reducing the PSBT size. This is
particularly true for redeemscripts and witnessscripts, as they can
just be computed by the client when deserializing. The two types could
even be merged into just "scripts" records - as they don't need to be
separated based on the way they're looked up (Hash160 for P2SH, SHA256
for P2WSH). The same could be done for the BIP32 derivation paths,
though this may be expensive, as the client would need to derive all
keys before being able to figure out which one(s) it needs.
One exception is the "transaction" record, which needs to be unique.
That can either be done by adding an exception ("there can only be one
transaction record"), or by encoding it separately outside the normal
records (that may also be useful to make it clear that it is always
required).
* Ability for Combiners to verify two PSBT are for the same transaction
Clearly two PSBTs for incompatible transactions cannot be combined,
and this should not be allowed.
It may be easier to enforce this if the "transaction" record inside a
PSBT was required to be in a canonical form, meaning with empty
scriptSigs and witnesses. In order to do so, there could be per-input
records for "finalized scriptSig" and "finalized witness". Actually
placing those inside the transaction itself would only be allowed when
all inputs are finalized.
* Optional signing
I think all operation for the Signer responsibility should be
optional. This will inevitably lead to incompatibilities, but with the
intent of being forward compatible with future developments, I don't
think it is possible to require every implementation to support the
same set of scripts or contracts. For example, some signers may only
implement single-key P2PKH, or may only support signing SegWit inputs.
It's the user's responsibility to find compatible signers (which is
generally not an issue, as the different participants in a setup
necessarily have this figured out before being able to create an
address). This does mean that there can't be an unconditional test
vector that specifies the produced signature in certain circumstances,
but there could be "For implementations that choose to implement
signing for P2PKH inputs using RFC6979, the expected output given
input X and access to key Y is Z".
On the other hand, the Combiner and Finalizer roles can probably be
specified much more accurately than they are now.
* Derivation from xpub or fingerprint
For BIP32 derivation paths, the spec currently only encodes the 32-bit
fingerprint of the parent or master xpub. When the Signer only has a
single xprv from which everything is derived, this is obviously
sufficient. When there are many xprv, or when they're not available
indexed by fingerprint, this may be less convenient for the signer.
Furthermore, it violates the "PSBT contains all information necessary
for signing, excluding private keys" idea - at least if we don't treat
the chaincode as part of the private key.
For that reason I would suggest that the derivation paths include the
full public key and chaincode of the parent or master things are
derived from. This does mean that the Creator needs to know the full
xpub which things are derived from, rather than just its fingerprint.
* Generic key offset derivation
Whenever a BIP32 derivation path does not include any hardened steps,
the entirety of the derivation can be conveyed as "The private key for
P is equal to the private key for Q plus x", with P and Q points and x
a scalar. This representation is more flexible (it also supports
pay-to-contract derivations), more efficient, and more compact. The
downside is that it requires the Signer to support such derivation,
which I don't believe any current hardware devices do.
Would it make sense to add this as an additional derivation method?
* Hex encoding?
This is a very minor thing. But presumably there will be some standard
way to store PSBTs as text for copy-pasting - either prescribed by the
spec, or de facto. These structures may become pretty large, so
perhaps it's worth choosing something more compact than hexadecimal -
for example Base64 or even Z85 (https://rfc.zeromq.org/spec:32/Z85/).
Cheers,
--
Pieter

2023-06-07 18:12:39

- reply

📅 Original date posted:2018-06-03
📝 Original message:On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Lighter but SPV secure nodes (filter committed) would help the network
> (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW.
>
> On longer term most users' security will be determined by either trusted
> hubs or POW.
> I do not know which is worse, but we should at least offer the choice to
> the user, therefore commit filters.
>
I don't think that's the point of discussion here. Of course, in order to
have filters that verifiably don't lie by omission, the filters need to be
committed to by blocks.
The question is what data that filter should contain.
There are two suggestions:
(a) The scriptPubKeys of the block's outputs, and prevouts of the block's
inputs.
(b) The scriptPubKeys of the block's outputs, and scriptPubKeys of outputs
being spent by the block's inputs.
The advantage of (a) is that it can be verified against a full block
without access to the outputs being spent by it. This allows light clients
to ban nodes that give them incorrect filters, but they do need to actually
see the blocks (partially defeating the purpose of having filters in the
first place).
The advantage of (b) is that it is more compact (scriot reuse, and outputs
spent within the same block as they are created). It also had the advantage
of being more easily usable for scanning of a wallet's transactions. Using
(a) for that in some cases may need to restart and refetch when an output
is discovered, to go test for its spending (whose outpoint is not known
ahead of time). Especially when fetching multiple filters at a time this
may be an issue.
I think both of these potentially good arguments. However, once a committed
filter exists, the advantage of (a) goes away completely - validation of
committed filters is trivial and can be done without needing the full
blocks in the first place.
So I think the question is do we aim for an uncommitted (a) first and a
committed (b) later, or go for (b) immediately?
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180602/ddc0b29e/attachment-0001.html>

2023-06-07 18:12:29

- reply

📅 Original date posted:2018-05-25
📝 Original message:Hi all,
I spent some time working out the optimal parameter selection for the
Golomb Coded Sets that are proposed in BIP158:
https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845
TL;DR: if we really want an FP rate of exactly 1 in 2^20, the Rice
parameter should be 19, not 20. If we don't, we should pick an FP rate
of 1 in a 1.4971*2^B. So for example M=784931 B=19 or M=1569861 B=20.
Cheers,
--
Pieter

2023-06-07 18:12:23

- reply

📅 Original date posted:2018-05-22
📝 Original message:Hello all,
Given the recent discussions about Taproot [1] and Graftroot [2], I
was wondering if a practical deployment needs a way to explicitly
enable or disable the Graftroot spending path. I have no strong
reasons why this would be necessary, but I'd like to hear other
people's thoughts.
As a refresher, the idea is that a script type could exists which
looks like a pubkey Q, but can be spent either:
* By signing the spending transaction directly using Q (key spending)
* By proving Q was derived as Q = P + H(P,S)*G, with a script S and
its inputs (Taproot script spending).
* By signing a script S using Q, and providing S's inputs (Graftroot
script spending).
Overall, these constructions let us create combined
pay-to-pubkey-or-script outputs that are indistinguishable, and don't
even reveal a script spending path existed in the first place when the
key spending path is used. The two approaches ((T)aproot and
(G)raftroot) for the script spending path have different trade-offs:
* T outputs can be derived noninteractively from key and scripts; G
outputs need an interaction phase where the key owner(s) sign off on
the potential script spending paths.
* T lets you prove what all the different spending paths are.
* T without any other technology only needs to reveal an additional
point when spending a single script; G needs half-aggregated
signatures [3] to achieve the same, which complicates design (see
[4]).
* G is more compact when dealing with many spending paths (O(1) in the
number of spending paths), while T spends need to be combined with
Merkle branches to deal with large number of spends (and even then is
still O(log n)).
* G spending paths can be added after the output is created; T
requires them be fixed at output creation time.
My question is whether it is safe to always permit both types of
script spending paths, or an explicit commitment to whether Graftroot
is permitted is necessary. In theory, it seems that this shouldn't be
needed: the key owners are always capable of spending the funds
anyway, so them choosing to delegate to others shouldn't enable
anything that isn't
possible by the key owners already.
There are a few concerns, however:
* Accidentally (participating in) signing a script may have more broad
consequences. Without Graftroot, that effect is limited to a single
transaction with specific inputs and outputs, and only as long as all
those inputs are unspent. A similar but weaker concern exists for
SIGHASH_NOINPUT.
* In a multisignature setting (where the top level key is an aggregate
of multiple participants), the above translates to the ability for a
(threshold satsisfying) subset of participants being able to (possibly
permanently) remove others from the set of signers (rather than for a
single output).
* In a situation where private keys are stored in an HSM, without
Graftroot an attacker needs access to the device and convince it to
sign for every output he wants to steal (assuming the HSM prevents
leaking private keys). With Graftroot, the HSM may be tricked into
signing a script that does not include itself. Arguably, in a
Graftroot setting such an HSM would need a degree of protection
similar to not leaking private keys applied to not signing scripts,
but this may be less obvious.
Overall, none of these are convincing points, but they do make me
uncomfortable about the effect the Graftroot spending path may have on
some use cases. Given that Taproot/Graftroot's primary advantage is
increasing fungibility by making all outputs look identical, it seems
good to discuss potential reasons such outputs couldn't or wouldn't be
adopted in certain applications.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014308.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015838.html
Cheers,
--
Pieter

2023-06-07 18:11:15

- reply

📅 Original date posted:2018-03-26
📝 Original message:Hello,
Thanks for starting a discussion about this idea.
A few comments inline:
On Wed, Mar 14, 2018 at 1:09 AM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> I am considering writing a replacement for the message signing tools
> that are currently broken for all but the legacy 1xx addresses. The
> approach (suggested by Pieter Wuille) is to do a script based
> approach. This does not seem to require a lot of effort for
> implementing in Bitcoin Core*. Below is my proposal for this system:
>
> A new structure SignatureProof is added, which is a simple scriptSig &
> witnessProgram container that can be serialized. This is passed out
> from/into the signer/verifier.
>
You need a bit more logic to deal with softforks and compatibility. The
question is which script validation flags you verify with:
* If you make them fixed, it means signatures can't evolve with new address
types being introduced that rely on new features.
* If you make it just consensus flags (following mainnet), it means that
people with old software will see future invalid signatures as always
valid; this is probably not acceptable.
* If you make it standardness flags, you will get future valid signatures
that fail to verify.
One solution is to include a version number in the signature, which
explicitly corresponds to a set of validation flags. When the version
number is something a verifier doesn't know, it can be reported as
inconclusive (it's relying on features you don't know about).
An solution is to verify twice; once with all consensus rules you know
about, and once with standardness rules. If they're both valid, the
signature is valid. If they're both invalid, the signature is invalid. If
they're different (consensus valid but standardness invalid), you report
the signature validation as inconclusive (it's relying on features you
don't know about). This approach works as long as new features only use
previous standardness-invalid scripts, but perhaps a version number is
still needed to indicate the standardness flags.
RPC commands:
>
> sign <address> <message> [<prehashed>=false]
>
Why not extend the existing signmessage/verifymessage RPC? For legacy
addresses it can fall back to the existing signature algorithm, while using
the script-based approach for all others.
>
> Generates a signature proof for <message> using the same method that
> would be used to spend coins sent to <address>.**
>
> verify <address> <message> <proof> [<prehashed>=false]
>
> Deserializes and executes the proof using a custom signature checker
> whose sighash is derived from <message>. Returns true if the check
> succeeds, and false otherwise. The scriptPubKey is derived directly
> from <address>.**
>
> Feedback welcome.
>
> -Kalle.
>
>
(**) If <prehashed> is true, <message> is the sighash, otherwise
> sighash=sha256d(message).
>
That's very dangerous I'm afraid. It could be used to trick someone into
signing off on an actual transaction, if you get them to sign a "random
looking" prehashed message. Even if you have a prehashed message, there is
no problem with treating it as hex input to a second hashing step, so I
think the prehashed option isn't needed. It's why the existing message
signing functionality always forcibly prefixes "Bitcoin signed message:",
to avoid signing something that unintentionally corresponds to a message
intended for another goal.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180326/8324b4f3/attachment.html>

2023-06-07 18:09:38

- reply

📅 Original date posted:2018-01-09
📝 Original message:On Jan 9, 2018 13:41, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
The use of the alt stack is a hack for segwit script version 0 which has
the clean stack rule. Anticipated future improvements here are to switch to
a witness script version, and a new segwit output version which supports
native MAST to save an additional 40 or so witness bytes. Either approach
would allow getting rid of the alt stack hack. They are not part of the
proposal now because it is better to do things incrementally, and because
we anticipate usage of MAST to better inform these less generic changes.
If the goal is to introduce a native MAST output type later, what is gained
by first having the tailcall semantics?
As far as I can see, this proposal does not have any benefits over Johnson
Lau's MAST idea [1]:
* It is more compact, already giving us the space savings a native MAST
version of the tail call semantics would bring.
* It does not need to work around limitations of push size limits or
cleanstack rules.
* The implementation (of code I've seen) is easier to reason about, as it's
just another case in VerifyScript (which you'd need for a native MAST
output later too) without introducing jumps or loops inside EvalScript.
* It can express the same, as even though the MBV opcode supports proving
multiple elements simultaneously, I don't see a way to use that in the tail
call. Every scenario that consists of some logic before deciding what the
tail call is going to be can be rewritten to have that logic inside each of
the branches, I believe.
* It does not interfere with static analysis (see further).
* Tail call semantics may be easier to extend in the future to enable
semantics that are not compactly representable in either proposal right
now, by allowing a single top-level script may invoke multiple subscripts,
or recursion. However, those sound even riskier and harder to analyse to
me, and I don't think there is sufficient evidence they're needed.
Native MAST outputs would need a new witness script version, which your
current proposal does indeed not need. However, I believe a new script
version will be desirable for other reasons regardless (returning invalid
opcodes to the pool of NOPs available for softforks, for example).
I will make a strong assertion: static analyzing the number of opcodes and
sigops gets us absolutely nothing. It is cargo cult safety engineering. No
need to perpetuate it when it is now in the way.
I'm not sure I agree here. While I'd like to see the separate execution
limits go away, removing them entirely and complicating future ability to
introduce unified costing towards weight of execution cost seems the wrong
way to go.
My reasoning is this: perhaps you can currently make an argument that the
current weight limit is sufficient in preventing overly expensive block
validation costs, due to a minimal ratio between script sizes and their
execution cost. But such an argument needs to rely on assumptions about
sighash caching and low per-opcode CPU time, which may change in the
future. In my view, tail call semantics gratuitously remove or complicate
the ability to reason about the executed code.
One suggestion to reduce the impact of this is limiting the per-script
execution to something proportional to the script size. However, I don't
think that addresses all potential concerns about static analysis (for
example, it doesn't easily let you prove all possible execution paths to a
participant in a smart contract).
Another idea that has been suggested on this list is to mark pushes of
potentially executable code on the stack/witness explicitly. This would
retain all ability to analyse, while still leaving the flexibility of
future extensions to tail call execution. If tail call semantics are
adopted, I strongly prefer an approach like that to blindly throwing out
all limits and analysis.
[1] https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180109/6c862414/attachment.html>

2023-06-07 18:08:36

- reply

📅 Original date posted:2017-12-11
📝 Original message:On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
This topic has come up several times in recent years. While it is well
intentioned, it can have devastating outcomes for people that want to save
long term. If such a system were implemented, it would force people to move
funds around in order to not get nullified. In that process, it introduces
multiple opportunities for errors. Cold storage should be able to stay
cold. I personally would be apprehensive about implementing this kind of a
system.
Furthermore, if it rewards miners with funds that are expired, it creates
terrible incentives. Miners in their best interest could choose to censor
transactions that move funds close to their expiration time, to increase
their own future rewards.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171211/e43f4baa/attachment.html>

2023-06-07 18:06:06

- reply

📅 Original date posted:2017-09-16
📝 Original message:On Sep 15, 2017 01:56, "Thomas Voegtlin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Note 3: we could also use a bech32 format for the private key, if it is
going to be used with a bech32 address. I am not sure if such a format
has been proposed already.
I've been working on an "extended bech32" format with 12 character checksum
rather than 6, for private keys and other things that need stronger
protection. It would guarantee correcting 4 errors, where normal bech32 can
only detect (but not correct) 4.
The rationale is that in the case of an address, if an error is detected,
you can ask the receiver for a corrected version. As that option doesn't
exist for private keys you want something stronger.
This has been a low-priority thing for me, though, and the computation work
to find a good checksum is significant.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170916/e9b7ad89/attachment.html>

2023-06-07 18:04:13

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Tue, Jul 11, 2017 at 1:36 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> Pieter,
>
> I think that you have misrepresented Chris' view by taking it out of
> context. His complete quote reads "If drivechains are successful they should
> be viewed as the way we scale -- not hard forking the protocol." Chris is
> comparing Drivechains/sidechains to a hard fork.
I apologize here; I didn't mean to misrepresent his viewpoint.
> You went on to "disagree", but every point of contention you introduced was
> something that would apply to both drivechain-sourced capacity and
> hardfork-sourced capacity. Neither improves scalability, and both allow
> users only the opportunity to select a different security model. If I
> understand you, the point at which a security model does not become
> "interesting" to you, would be the exact same point in the drivechain and
> hardfork worlds. Both, at any rate, have the same effect on "validation cost
> to auditors".
If you're talking about the extreme case where every full node in the
increased capacity single chain model corresponds to a node that
validates both chains and all transfers between them in the
drivechains, I agree. At that point they become nearly equivalent in
terms of ease of adoption, resource costs, and capacity.
However, I don't think that is a realistic expectation. When
considering drivechains as a capacity increase, I believe most people
think about a situation where there are many chains that give an
increased capacity combined, but not everyone verifies all of them.
This is what I meant with uninteresting security model, as it requires
increased miner trust for preventing the other chains' coins from
being illegally transferred to the chain you're operating on.
Regardless, people are free experiment and adopt such an approach. The
nice thing about it not being a hardfork is that it does not require
network-wide consensus to deploy. However, I don't think they offer a
security model that should be encouraged, and thus doesn't have a
place on a roadmap.
> Since their sidechain coins cannot appreciate in value relative
> to the mainchain coins, users would only opt-in if they felt that they were
> sufficiently compensated for any and all risks. Hence, it is difficult to
> list this item as a drawback when, to the user, it is a strict improvement
> (at least, by any epistemological standard that I can think of). If you have
> new objections to these claims, I'm sure we would all benefit from hearing
> them, myself most of all.
Am I right in summarizing your point here as "This approach cannot
hurt, because if it were insecure, people can choose to not use it."?
I'm not sure I agree with that, as network effects or misinformation
may push users beyond what is reasonable.
Cheers,
--
Pieter

2023-06-07 18:04:12

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Jul 11, 2017 09:18, "Chris Stewart via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Concept ACK.
If drivechains are successful they should be viewed as the way we scale
I strongly disagree with that statement.
Drivechains, and several earlier sidechains ideas, are not a scalability
improvement, but merely enabling users to opt-in for another security model.
While obviously any future with wider adoption will need different
technologies that have different trade-offs, and anyone is free to choose
their security model, I don't think this particular one is interesting. In
terms of validation cost to auditors, it is as bad as just a capacity
increase on chain, while simultaneously adding the extra risk of miners
being able to vote to steal your money.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/6c7b8145/attachment.html>

2023-06-07 18:01:14

- reply

📅 Original date posted:2017-05-16
📝 Original message:On Tue, May 16, 2017 at 4:01 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> To be clear, *none* of the previous (U)TXO commitment schemes require *miners*
> to participate in generating a commitment. While that was previously thought to
> be true by many, I've seen no counter-arguments to the argument I published I
> few months ago(1) that (U)TXO commitments did not require a soft-fork to
> deploy.
>
> 1) "[bitcoin-dev] TXO commitments do not need a soft-fork to be useful",
> Peter Todd, Feb 23 2017,
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
I'm aware, I agree, and I even referenced that mail in my original post.
However, all of those approaches still require a network wide choice
to be useful. A validating node that does not maintain a UTXO X must
get a proof of its unspentness from somewhere for at least the block
which contains a spend of X. In a world where such a model is deployed
network-wide, that proof information is generated by the wallet and
relayed wherever needed. In a partial deployment however, you need
nodes that can produce the proof for other nodes, and the ability to
produce a proof is significantly more expensive than running either an
old or a new full node.
This ability to produce proofs becomes even harder when there are
different models deployed at once. Even just having a different
criterion for which UTXOs need a proof (eg. "only outputs created more
than 1000 blocks ago") may already cause compatibility issues. Combine
that with the multitude of ideas about this (insertion-ordered TXO
trees, txid-ordered UTXO Patricia tries, AVL+ trees, append-only
bitfield, ...) with different trade-offs (in CPU, RAM for validators,
complexity for wallets/index services, ...), I don't think we're quite
ready to make that choice.
To be clear: I'm very much in favor of moving to a model where the
responsibilities of full nodes are reduced in the long term. But
before that can happen there will need to be implementations,
experiments, analysis, ...
Because of that, I think it is worthwhile to investigate solutions to
the "how can we efficiently compare UTXO sets" problem separately from
the "how do we reduce full node costs by sending proofs instead of it
maintaining the data". And rolling UTXO set hashes are a solution for
just the first - and one that has very low costs and no normative
datastructures at all.
--
Pieter

2023-06-07 17:58:13

- reply

📅 Original date posted:2017-03-28
📝 Original message:On Tue, Mar 28, 2017 at 12:56 PM, Paul Iverson via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> So I think Core can't decide on hard forks like this. It must be left up to
> the users. I think only choice is for Core to add a run-time option to allow
> node operators to increase block size limit, so that this very controversial
> decision is not coming from Core. It must come from the community.
Bitcoin Core's (nor any other software's) maintainers can already not
decide on a hard fork, and I keep being confused by the focus on Core
in this topic. Even if a hard forking change (or lack thereof) was
included into a new release, it is still up to the community to choose
to run the new software. Bitcoin Core has very intentionally no
auto-update feature, as the choice for what network rules to implement
must come from node operators, not developers. Ask yourself this: if a
new Bitcoin Core release would include a new rule that blacklists
<random famous person>'s coins. What do you think would happen? I hope
that people would refuse to update, and choose to run different full
node software.
Core is not special. It is one of many pieces of software that
implement today's Bitcoin consensus rules. If a hardfork is to take
place in a way that does not result in two currencies, it must be
clear that the entire ecosystem will adopt it. Bitcoin Core will not
merge any consensus changes that do not clearly satisfy that
criterion.
--
Pieter

2023-06-07 17:57:43

- reply

📅 Original date posted:2017-03-23
📝 Original message:On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Long story short, when nodes 0.13+ receive blocks from 0.13+ nodes all is
> ok, and those blocks propagate to older nodes with no issues. But when a
> block tries to be propagated from bitcoind 0.12.+ to newer ones those blocks
> are NOT being propagated to the peers with newer versions while these newer
> blocks are being propagated to peers with older versions with no issues.
>
> My conclusion is that we have a backward compatibility issue between 0.13.X+
> and older versions.
Hello Juan,
this is expected behaviour. Nodes with segwit active only download
blocks from other segwit peers, as old peers cannot provide the
witness data they need to verify the blocks.
--
Pieter

2023-06-07 17:57:37

- reply

📅 Original date posted:2017-03-20
📝 Original message:Hello everyone,
I'd like to propose a new BIP for native segwit addresses to replace
BIP 142. These addresses are not required for segwit, but are more
efficient, flexible, and nicer to use.
The format is base 32 and uses a simple checksum algorithm with strong
error detection properties. Reference code in several languages as
well as a website demonstrating it are included.
You can find the text here:
https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
Cheers,
--
Pieter

2023-06-07 17:56:47

- reply

📅 Original date posted:2017-02-26
📝 Original message:On Feb 25, 2017 22:26, "Steve Davis" <steven.charles.davis at gmail.com> wrote:
Hi Pieter,
> On Feb 25, 2017, at 4:14 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
>
> Any alternative to move us away from RIPEMD160 would require:
> <snipped>
“Any alternative”? What about reverting to:
[<public_key>, OP_CHECKSIG]
snip
Could that be the alternative?
Ok, fair enough, that is an alternative that avoids the 160-bit hash
function, but not where it matters. The 80-bit collision attack only
applies to jointly constructed addresses like multisig P2SH, not single-key
ones. As far as I know for those we only rely preimage security, and
RIPEMD160 has 160 bit security there, which is even more than our ECDSA
signatures offer.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/6f7d3907/attachment.html>

2023-06-07 17:56:46

- reply

📅 Original date posted:2017-02-25
📝 Original message:On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Hi Peter,
I really, really don’t want to get into it but segwit has many aspects that
are less appealing, not least of which being the amount of time it would
take to reach the critical mass.
Surely there's a number of alternative approaches which could be explored,
even if only to make a fair assessment of a best response?
Any alternative to move us away from RIPEMD160 would require:
* A drafting of a softfork proposal, implementation, testing, review.
* A new address format
* Miners accepting the new consensus rules
* Wallets adopting the new address format, both on the sender side and
receiver side (which requires new signatures).
I.e., exactly the same as segwit, for which most of these are already done.
And it would still only apply to wallets adopting it.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170225/e3856947/attachment-0001.html>

2023-06-07 17:54:54

- reply

📅 Original date posted:2016-12-10
📝 Original message:On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We have models for estimating the probability that a block is orphaned
> given average network bandwidth and block size.
>
> The question is, do we have objective measures of these two quantities?
> Couldn't we target an orphan_rate < max_rate?
>
Models can predict orphan rate given block size and network/hashrate
topology, but you can't control the topology (and things like FIBRE hide
the effect of block size on this as well). The result is that if you're
purely optimizing for minimal orphan rate, you can end up with a single
(conglomerate of) pools producing all the blocks. Such a setup has no
propagation delay at all, and as a result can always achieve 0 orphans.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/edca6d6b/attachment.html>

2023-06-07 17:52:57

- reply

📅 Original date posted:2016-08-16
📝 Original message:On Aug 17, 2016 00:36, "Russell O'Connor" <roconnor at blockstream.io> wrote:
> Can I already do something similar with replace by fee, or are there
limits on that?
BIP125 and mempool eviction both require the replacing transaction to have
higher fee, to compensate for the cost of relaying the replaced
transaction(s).
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/3710f5b7/attachment.html>

2023-06-07 17:52:56

- reply

📅 Original date posted:2016-08-16
📝 Original message:On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If one's goal is to mess with an transaction to prevent it from being
mined, it is more effective to just not relay the transaction rather than
to mess with the witness. Given two transactions with the same txid and
different witness data, miners and good nodes ought to mine/relay the
version with the lower cost (smaller?) witness data.
That implies that everyone will see both versions and be able to make that
choice. Unfortunately, those two versions will be definition be in conflict
with each other, and thus only one will end up paying a fee. We're can't
relay two transactions for the price of one, or we'd expose the p2p network
to a very cheap DDoS attack: just send increasingly small versions of the
same transaction.
Segwit's third party mallebility protection makes it not an issue for
dependent contracts if transactions are mauled (=apparently the verb
related to malleability), but there are still good reasons for senders not
to gratuitously make their transactions extensible in size or other
resources.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/2c5284a7/attachment.html>

2023-06-07 17:52:37

- reply

📅 Original date posted:2016-08-10
📝 Original message:On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> By sending a public seed, there's no way for someone to use the transmitted
> address and trace the total amount of payments to it.
Worse. By revealing a public seed, anyone who has seen it (= anyone
who ever pays you through it) can identity all payments to _any_
address derived from that seed.
--
Pieter

2023-06-07 17:51:35

- reply

📅 Original date posted:2016-06-29
📝 Original message:On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >It's also not clear to me why the HMAC, vs just
SHA256(key|cipher-type|mesg). But that's probably just my crypto
ignorance...
>
> SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
> the length extension property of SHA256.
This property does technically not apply here, as the output of the hash is
kept secret, and the possible messages are constants (which are presumably
chosen in such a way that one is never an extension of another).
However, this is a good example of why you can't generically use a hash
function in places where you want a MAC (aka "a hash with a shared
secret"). Furthermore, if you already have a hash function anyway, HMAC is
very easy construct on top of it.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160629/72f9c103/attachment.html>

2023-06-07 17:51:23

- reply

📅 Original date posted:2016-06-23
📝 Original message:On Jun 23, 2016 14:10, "Peter Todd" <pete at petertodd.org> wrote:
> Right, so you accept that we'll exert some degree of editorial control;
the
> question now is what editorial policies should we exert?
No, I do not. I am saying that some degree of editorial control will
inevitably exist, simply because there is some human making the choice of
assigning a BIP number and merging. My opinion is that we should try to
restrict that editorial control to only be subject to objective process,
and not be dependent on personal opinions.
> My argument is that rejecting BIP75 is something we should do on
> ethical/strategic grounds. You may disagree with that, but please don't
troll
> and call that "advocating censorship"
I think that you are free to express dislike of BIP75. Suggesting to remove
it for that reason is utterly ridiculous to me, whatever you want to call
it.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/ba7a229f/attachment.html>

2023-06-07 17:51:22

- reply

📅 Original date posted:2016-06-23
📝 Original message:On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In any case, I'd strongly argue that we remove BIP75 from the bips
repository,
> and boycott wallets that implement it. It's bad strategy for Bitcoin
developers
> to willingly participate in AML/KYC, just the same way as it's bad for
Tor to
> add wiretapping functionality, and W3C to support DRM tech. The minor
tactical
> wins you'll get our of this aren't worth it.
I hope you're not seriously suggesting to censor a BIP because you feel it
is a bad idea.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/b6c34061/attachment.html>

2023-06-07 17:50:20

- reply

📅 Original date posted:2016-05-09
📝 Original message:On 05/03/2016 12:13 AM, lf-lists at mattcorallo.com (Matt Corallo) wrote:
> Hi all,
>
> The following is a BIP-formatted design spec for compact block relay
> designed to limit on wire bytes during block relay. You can find the
> latest version of this document at
> https://github.com/TheBlueMatt/bips/blob/master/bip-TODO.mediawiki.
Hi Matt,
thank you for working on this!
> ===New data structures===
> Several new data structures are added to the P2P network to relay
> compact blocks: PrefilledTransaction, HeaderAndShortIDs,
> BlockTransactionsRequest, and BlockTransactions. Additionally, we
> introduce a new variable-length integer encoding for use in these data
> structures.
>
> For the purposes of this section, CompactSize refers to the
> variable-length integer encoding used across the existing P2P protocol
> to encode array lengths, among other things, in 1, 3, 5 or 9 bytes.
This is a not, but I think it's a bit strange to have two separate
variable length integers in the same specification. I understand is one
is already the default for variable-length integers currently, and there
are reasons to use the other one for efficiency reasons in some places,
but perhaps we should aim to get everything using the latter?
> ====New VarInt====
> Variable-length integers: bytes are a MSB base-128 encoding of the number.
> The high bit in each byte signifies whether another digit follows. To make
> sure the encoding is one-to-one, one is subtracted from all but the last
> digit.
Maybe it's worth mentioning that it is based on ASN.1 BER's compressed
integer format (see
https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
section 8.1.3.5), though with a small modification to make every integer
have a single unique encoding.
> ====HeaderAndShortIDs====
> A HeaderAndShortIDs structure is used to relay a block header, the short
> transactions IDs used for matching already-available transactions, and a
> select few transactions which we expect a peer may be missing.
>
> |shortids||List of uint64_ts||8*shortids_length bytes||Little
> Endian||The short transaction IDs calculated from the transactions which
> were not provided explicitly in prefilledtxn
I tried to derive what length of short ids is actually necessary (some
write-up is on
https://gist.github.com/sipa/b2eb2e486156b5509ac711edd16153ed but it's
incomplete).
For any reasonable numbers I can come up with (in a very wide range),
the number of bits needed is very well approximated by:
log2(#receiver_mempool_txn * #block_txn_not_in_receiver_mempool /
acceptable_per_block_failure_rate)
For example, with 20000 mempool transactions, 2500 transactions in a
block, 95% hitrate, and a chance of 1 in 10000 blocks to fail to
reconstruct, needed_bits = log2(20000 * 2500 * (1 - 0.95) / 0.0001) =
34.54, or 5 byte txids would suffice.
Note that 1 in 10000 failures may sound like a lot, but this is for each
individual connection, and since every transmission uses separately
salted identifiers, occasional failures should not affect global
propagation. Given that transmission failures due to timeouts, network
connectivity, ... already occur much more frequently than once every few
gigabytes (what 10000 blocks corresponds to), that's probably already
more than enough.
In short: I believe 5 or 6 byte txids should be enough, but perhaps it
makes sense to allow the sender to choose (so he can weigh trying
multiple nonces against increasing the short txid length).
> ====Short transaction IDs====
> Short transaction IDs are used to represent a transaction without
> sending a full 256-bit hash. They are calculated by:
> # single-SHA256 hashing the block header with the nonce appended (in
> little-endian)
> # XORing each 8-byte chunk of the double-SHA256 transaction hash with
> each corresponding 8-byte chunk of the hash from the previous step
> # Adding each of the XORed 8-byte chunks together (in little-endian)
> iteratively to find the short transaction ID
An alternative would be using SipHash-1-3 (a form of SipHash with
reduced iteration counts; the default is SipHash-2-4). SipHash was
designed as a Message Authentication Code, where the security
requirements are much stronger than in our case (in particular, we don't
care about observers being able to finding the key, as the key is just
public knowledge here). One of the designers of SipHash has commented
that SipHash-1-3 for collision resistance in hash tables may be enough:
https://github.com/rust-lang/rust/issues/29754#issuecomment-156073946
Using SipHash-1-3 on modern hardware would take ~32 CPU cycles per txid.
> ===Implementation Notes===
There are a few more heuristics that MAY be used to improve performance:
* Receivers should treat short txids in blocks that match multiple
mempool transactions as non-matches, and request the transactions. This
significantly reduces the failure to reconstruct.
* When constructing a compact block to send, the sender can verify it
against its own mempool to check for collisions, and if so, choose to
either try another nonce, or increase the short txid length.
Cheers,
--
Pieter

2023-06-07 17:48:26

- reply

📅 Original date posted:2016-02-02
📝 Original message:On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev
wrote:
> > I really don't like the idea of policing other people's use of the
> > protocol. If a transaction pays its fee and has a greater than dust
value,
> > it makes no sense to object to it.
>
> I'll point out that getting a BIP for a feature is *not* a hard
> requirement for deployment. I'd encourage you to go write up your BIP
> document, give it a non-numerical name for ease of reference, and lobby
> wallet vendors to implement it.
>
> While I'll refrain from commenting on whether or not I think the feature
> itself is a good idea, I really don't want people to get the impression
> that we're gatekeepers for how people choose use Bitcoin.
I'll go further: whatever people have commented here and elsewhere about
this feature (myself included) are personal opinions on the feature itself,
in the hope you take the concerns into account.
These comments are not a judgement on whether this should be accepted as a
BIP. Specifically, the BIP editor should accept a BIP even if he personally
dislikes the ideas in it, when the criteria are satisfied.
Beyond that, having a BIP accepted does not mean wallets have to implement
it. That's up to the individual wallet authors/maintainers.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160202/1e70ea91/attachment.html>

2023-06-07 17:47:42

- reply

📅 Original date posted:2016-01-07
📝 Original message:> "The problem case is where someone in a contract setup shows you a
script, which you accept as being a payment to yourself. An attacker could
use a collision attack to construct scripts with identical hashes, only one
of which does have the property you want, and steal coins.
>
> So you really want collision security, and I don't think 80 bits is
something we should encourage for that. Normal pubkey hashes don't have
that problem, as they can't be constructed to pay to you."
>
> ... but I'm unconvinced:
>
> "But it is trivial for contract wallets to protect against collision
attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
ignore that arbitrary data" a wallet can just refuse. Even more likely, a
contract wallet won't even recognize that as a pay-to-gavin transaction.
>
> I suppose it could be looking for some form of "gavin_pubkey
somebody_else_pubkey CHECKMULTISIG ... with the attacker using
somebody_else_pubkey to force the collision, but, again, trivial contract
protocol tweaks ("send along a proof you have the private key corresponding
to the public key" or "everybody pre-commits pubkeys they'll use at
protocol start") would protect against that.
Yes, this is what I worry about. We're constructing a 2-of-2 multisig
escrow in a contract. I reveal my public key A, you do a 80-bit search for
B and C such that H(A and B) = H(B and C). You tell me your keys B, and I
happily send to H(A and B), which you steal with H(B and C).
Sending along a proof does not help, you can't prove that you do not know
of a collision. Pre-committing does help, but is a very non-obvious
security requirement, something I strongly believe is far riskier in
practice.
Bitcoin does have parts that rely on economic arguments for security or
privacy, but can we please stick to using cryptography that is up to par
for parts where we can? It's a small constant factor of data, and it
categorically removes the worry about security levels.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/e2e921fb/attachment.html>

2023-06-07 17:47:41

- reply

📅 Original date posted:2016-01-08
📝 Original message:On Fri, Jan 8, 2016 at 2:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm saying we can eliminate one somewhat unlikely attack (that there is a
> bug in the code or test cases, today or some future version, that has to
> decide what to do with "version 0" versus "version 1" witness programs) by
> accepting the risk of another insanely, extremely unlikely attack.
Ok, just having one witness program version now is a somewhat different
proposal. It would be simpler for sure. The reasoning was that you'd need
this to not add significant overhead to small scripts, but that may not be
the case anymore. I wouldn't mind seeing numbers.
> My proposal would be to just do a version 0 witness program now, that is
> RIPEMD160(SHA256(script)).
I don't think that is wise. Bitcoin has a 128-bit security target for
everything else. We did not know that P2SH and similar constructs were
vulnerable to a collision attack at the time, but now we do, so the obvious
choice is to pick a size that is sufficiently large to maintain the 128-bit
security target. This is a no brainer to me; we're not proposing switching
to a 160-bit EC curve either, right?
> I'm really disappointed with the "Here's the spec, take it or leave it"
> attitude. What's the point of having a BIP process if the discussion just
> comes down to "We think more is better. We don't care what you think."
It is a proposal and we are discussing it. You first brought up some
criticisms in private, and I agreed with several things you said.
But it remains the proposal of a few people including me, and I do not
agree with the specific suggestion of reducing the security target for
witness scripts to 80 bits.
We are not deciding what the system will be. We're making a proposal, and
hope that due to its technical merit, the ecosystem will adopt it. You're
free to participate in that discussion.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/2420393c/attachment.html>

2023-06-07 17:46:45

- reply

📅 Original date posted:2015-12-18
📝 Original message:Hello all,
For a long time, I was personally of the opinion that soft forks
constituted a mild security reduction for old full nodes, albeit one
that was preferable to hard forks due to being far less risky, easier,
and less forceful to deploy.
After thinking more about this, I'm not convinced that it is even that anymore.
Let's analyze all failure modes (and feel free to let me know whether
I've missed any specific ones):
1) The risk of an old full node wallet accepting a transaction that is
invalid to the new rules.
The receiver wallet chooses what address/script to accept coins on.
They'll upgrade to the new softfork rules before creating an address
that depends on the softfork's features.
So, not a problem.
2) The risk of an old full node wallet accepting a transaction whose
coins passed through a script that depends on the softforked rules.
It is reasonable that the receiver of a transaction places some trust
in the sender, and on the basis of that, decides to reduce the number
of confirmations before acceptance. In case the transaction indirectly
depends on a low-confirmation transaction using softforked rules, it
may be treated as an anyone-can-spend transaction. Obviously, no trust
can be placed in such a transactions not being reorged out and
replaced with an incompatible one.
However, this problem is common for all anyonecanspend transactions,
which are perfectly legal today in the blockchain. So, if this is a
worry, we can solve it by marking incoming transactions as "uncertain
history" in the wallet if they have an anyonecanspend transaction with
less than 6 confirmations in its history. In fact, the same problem to
a lesser extent exists if coins pass through a 1-of-N multisig or so,
because you're not only trusting the (indirect) senders, but also
their potential cosigners.
3) The risk of an SPV node wallet accepting an unconfirmed transaction
which is invalid to new nodes.
Defrauding an SPV wallet with an invalid unconfirmed transaction
doesn't change with the introduction of new consensus rules, as they
don't validate them anyway.
In the case the client trusts the full node peer(s) it is connected to
to do validation before relay, nodes can either indicate (service bit
or new p2p message) which softforks are accepted (as it only matters
to SPV wallets that wish to accept transactions using new style script
anyway), or wallets can rely on the new rules being non-standard even
to old full nodes (which is typically aimed for in softforks).
4) The risk of an SPV node wallet accepting a confirmed transaction
which is invalid to new nodes
Miners can of course construct an invalid block purely for defrauding
SPV nodes, without intending to get that block accepted by full nodes.
That is expensive (no subsidy/fee income for those blocks) and more
importantly it isn't in any way affected by softforks.
So the only place where this matters is where miners create a block
chain that violates the new rules, and still get it accepted. This
requires a hash rate majority, and sufficiently few economically
important full nodes that forking them off is a viable approach.
It's interesting that even though it requires forking off full nodes
(who will notice, there will be an invalid majority hash rate chain to
them), the attack only allows defrauding SPV nodes. It can't be used
to bypass any of the economic properties of the system (as subsidy and
other resource limits are still enforced by old nodes, and invalid
scripts will either not be accepted by old full nodes wallets, or are
as vulnerable as unrelated anyonecanspends).
Furthermore, it's easily preventable by not using the feature in SPV
wallets until a sufficient amount of economically relevant full nodes
are known to have upgraded, or by just waiting for enough
confirmations.
So, we'd of course prefer to have all full nodes enforce all rules,
but the security reduction is not large. On the other hand, there are
also security advantages that softforks offer:
A) Softforks do not require the pervasive consensus that hardforks
need. Soft forks can be deployed without knowing when all full nodes
will adopt the rule, or even whether they will ever adopt it at all.
B) Keeping up with hard forking changes puts load on full node
operators, who may choose to instead switch to delegating full
validation to third parties, which is worse than just validating the
old rules.
C) Hardfork coordination has a centralizing effect on development. As
hardforks can only be deployed with sufficient node deployment, they
can't just be triggered by miner votes. This requires central
coordination to determine flag times, which is incompatible with
having multiple independent consensus changes being proposed. For
softforks, something like BIP9 supports having multiple independent
softforks in flight, that nodes can individually chose to accept or
not, only requiring coordination to not choose clashing bit numbers.
For hardforks, there is effectively no choice but having every
codebase deployed at a particular point in time to support every
possible hard forks (there can still be an additional hashpower based
trigger conditions for hardforks, but all nodes need to support the
fork at the earliest time it can happen, or risk being forked off).
D) If you are concerned about the security degradation a soft fork
might bring, you can always configure your node to treat a (signalled)
softfork as a hardfork, and stop processing blocks if a sortfork
condition is detected. The other direction is not possible.
--
Pieter

2023-06-07 17:46:27

- reply

📅 Original date posted:2015-12-26
📝 Original message:On Dec 26, 2015 23:55, "Jonathan Toomim" <j at toom.im> wrote:
>
> On Dec 26, 2015, at 8:44 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Furthermore, 75% is pretty terrible as a switchover point, as it
guarantees that old nodes will still see a 25% forked off chain temporarily.
>
> Yes, 75% plus a grace period is better. I prefer a grace period of about
4000 to 8000 blocks (1 to 2 months).
I think that's extremely short, even assuming there is no controversy about
changing the rules at all. Things like BIP65 and BIP66 already took
significantly longer than that, were uncontroversial, and only need miner
adoption. Full node adoption is even slower.
I think the shortest reasonable timeframe for an uncontroversial hardfork
is somewhere in the range between 6 and 12 months.
For a controversial one, not at all.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151227/9446849d/attachment.html>

2023-06-07 17:46:27

- reply

📅 Original date posted:2015-12-26
📝 Original message:On Dec 27, 2015 00:06, "Jonathan Toomim" <j at toom.im> wrote:
> Given that a supermajority of users and miners have been asking for a
hard fork to increase the blocksize for years, I do not think that
mobilizing people to upgrade their nodes is going to be hard.
>
> When we do the hard fork, we will need to encourage people to upgrade
their full nodes. We may want to request that miners not trigger the fork
until some percentage of visible full nodes have upgraded.
I am generally not interested in a system where we rely on miners to make
that judgement call to fork off nodes that don't pay attention and/or
disagree with the change. This is not because I don't trust them, but
because I believe one of the principle values of the system is that its
consensus system should be hard to change.
I can't tell you what code to run of course, but I can decide what system I
find interesting to build. And it seems many people have signed off on
working towards a plan that does not include a hard fork being scheduled
right now: https://bitcoin.org/en/bitcoin-core/capacity-increases
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151227/96ee711e/attachment.html>

2023-06-07 17:46:08

- reply

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 4:25 PM, jl2012--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm trying to list the minimal consensus rule changes needed for segwit
> softfork. The list does not cover the changes in non-consensus critical
> behaviors, such as relay of witness data.
>
> 1. OP_NOP4 is renamed as OP_SEGWIT
> 2. A script with OP_SEGWIT must fail if the scriptSig is not completely
> empty
> 3. If OP_SEGWIT is used in the scriptPubKey, it must be the only and the
> last OP code in the scriptPubKey, or the script must fail
> 4. The OP_SEGWIT must be preceded by exactly one data push (the "serialized
> script") with at least one byte, or the script must fail
The use of a NOP opcode to indicate a witness script was something I
considered at first too, but it's not really needed. You wouldn't be
able to use that opcode in any place a normal opcode could occur, as
it needs to be able to inspect the full scriptSig (rather than just
its resulting stack) anyway. So both in practice and conceptually it
is only really working as a template that gets assigned a special
meaning (like P2SH did). We don't need an opcode for that, and instead
we could say that any scriptPubKey (or redeemscript) that consists of
a single push is a witness program.
> 5. The most significant byte of serialized script is the version byte, an
> unsigned number
> 6. If the version byte is 0x00, the script must fail
What is that good for?
> 7. If the version byte is 0x02 to 0xff, the rest of the serialized script is
> ignored and the output is spendable with any form of witness (even if the
> witness contains something invalid in the current script system, e.g.
> OP_RETURN)
Do you mean the scriptPubKey itself, or the script that follows after
the version byte?
* The scriptPubKey itself: that's in contradiction with your rule 4,
as segwit scripts are by definition only a push (+ opcode), so they
can't be an OP_RETURN.
* The script after the version byte: agree - though it doesn't
actually need to be a script at all even (see further).
> 8. If the version byte is 0x01,
> 8a. rest of the serialized script is deserialized, and be interpreted as the
> scriptPubKey.
> 8b. the witness is interpreted as the scriptSig.
> 8c. the script runs with existing rules (including P2SH)
I don't think it's very useful to allow P2SH inside segwit, as we can
actually do better and allow segwit scripts to push the (perhaps 256
bit) hash of the redeemscript in the scriptPubKey, and have the full
redeemscript in the witness. See further for details. The numbers I
showed in the presentation were created using a simulation that used
that model already.
It is useful however to allow segwit inside P2SH (so the witness
program including version byte goes into the redeemscript, inside the
scriptSig). This allows old clients to send to new wallets without any
modifications (at slightly lower efficiency). The rules in this case
must say that the scriptSig is exactly a push of the redeemscript
(which itself contains the witness program), to provide both
compatibility with old consensus rules and malleability protection.
So let me summarize by giving an equivalent to your list above,
reflecting how my current prototype works:
A) A scriptPubKey or P2SH redeemscript that consists of a single push
of 2 to 41 bytes gets a new special meaning, and the byte vector
pushed by it is called the witness program.
A.1) In case the scriptPubKey pushes a witness program directly, the
scriptSig must be exactly empty.
A.2) In case the redeemscript pushes a witness program, the scriptSig
must be exactly the single push of the redeemscript.
B) The first byte of a witness program is the version byte.
B.1) If the witness version byte is 0, the rest of the witness program
is the actual script, which is executed after normal script evaluation
but with data from the witness rather than the scriptSig. The program
must not fail and result in a single TRUE on the stack, and nothing
else (to prevent stuffing the witness with pointless data during relay
of transactions).
B.2) if the witness version byte is 1, the rest of the witness program
must be 32 bytes, and a SHA256 hash of the actual script. The witness
must consist of an input stack to feed to the program, followed by the
serialized program itself (whose hash must match the hash pushed in
the witness program). It is executed after normal script evluation,
and must not fail and result in a single TRUE on the stack, and
nothing else.
B.3) if the witness version byte is 2 or higher, no further
interpretation of the data happens, but can be softforked in.
I'll write a separate mail on the block commitment structure.
--
Pieter

2023-06-07 17:45:48

- reply

📅 Original date posted:2015-12-21
📝 Original message:On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via bitcoin-dev
wrote:
>> TL;DR: I propose we work immediately towards the segwit 4MB block
>> soft-fork which increases capacity and scalability, and recent speedups
>> and incoming relay improvements make segwit a reasonable risk. BIP9
>> and segwit will also make further improvements easier and faster to
>> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
>> scaling, while building additional tools that would make bandwidth
>> increases safer long term. Further work will prepare Bitcoin for further
>> increases, which will become possible when justified, while also
providing
>> the groundwork to make them justifiable.
>
> Sounds good to me.
Better late than never, let me comment on why I believe pursuing this plan
is important.
For months, the block size debate, and the apparent need for agreement on a
hardfork has distracted from needed engineering work, fed the external
impression that nothing is being done, and generally created a toxic
environment to work in. It has affected my own productivity and health, and
I do not think I am alone.
I believe that soft-fork segwit can help us out of this deadlock and get us
going again. It does not require the pervasive assumption that the entire
world will simultaneously switch to new consensus rules like a hardfork
does, while at the same time:
* Give a short-term capacity bump
* Show the world that scalability is being worked on
* Actually improve scalability (as opposed to just scale) by reducing
bandwidth/storage and indirectly improving the effectiveness of systems
like Lightning.
* Solve several unrelated problems at the same time (fraud proofs, script
extensibility, malleability, ...).
So I'd like to ask the community that we work towards this plan, as it
allows to make progress without being forced to make a possibly divisive
choice for one hardfork or another yet.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/30bc71df/attachment.html>

2023-06-07 17:34:18

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.
I don't understand this. All problems that result from propagation delay
are literally doubled by doing so. Centralization pressure results from the
ratio between propagation time and interblock time. Efficient propagation
algorithms like the relay network make this presumably grow sublinear with
larger blocks, but changing the interblock time affects it exactly
proportionally.
All problems that result from propagation delay are literally doubled by
doing this. Doubling the block size has a smaller effect. You may argue
that these centralization effects are small, but reducing the interblock
time has a stronger effect on them than the block size.
Also, you seem to consider SPV mining a good thing? It requires trust
between miners that know eachother, and fundamentally breaks the security
assumption of SPV clients... and if the propagation/interblock ratio was
lower, SPV mining would have less effect. I'd say it is exactly a result of
the centralization pressure we're trying to avoid.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/f50a4a75/attachment-0001.html>

2023-06-07 17:33:57

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Mon, Aug 10, 2015 at 4:12 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
>
> Executive summary: when networks get over-saturated, they become
> unreliable. Unreliable is bad.
>
> Unreliable and expensive is extra bad, and that's where we're headed
> without an increase to the max block size.
>
I think I see your point of view. You see demand for on-chain transactions
as a single number that grows with adoption. Once the transaction creation
rate grows close to the capacity, transactions will become unreliable, and
you consider this a bad thing.
And if you see Bitcoin as a payment system where guaranteed time to
confirmation is a feature, I fully agree. But I think that is an
unrealistic dream. It only seems reliable because of lack of use. It costs
1.5 BTC per day to create enough transactions to fill the block chain at
the minimum relay fee, and a small multiple of that at actual fee levels.
Assuming that rate remains similar with an increased block size, that
remains cheap.
If you want transactions to be cheap, it will also be cheap to make them
unreliable.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/0fff338b/attachment.html>

2023-06-07 17:33:51

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber <mickeybob at gmail.com> wrote:
> Bitcoin would be better money than current money even if it were a bit
> more expensive to transact, simply because of its other great
> characteristics (trustlessness, limited supply, etc). However... it is not
> better than something else sharing all those same characteristics but which
> is also less expensive. The best money will win, and if Bitcoin doesn't
> increase capacity then it won't remain the best.
>
If it is less expensive, it is harder to be reliable (because it's easier
for a sudden new use case to outbid the available space), which is less
useful for a payment mechanism.
If it has better scale (with the same technology), it will have higher
centralization pressure. The higher price you potentially pay (in fees) to
get your transactions on a smaller block chain is the price of higher
security and independence. Perhaps the compromise is not at the optimal
place, but please stop saying "below what the technology can do". The
technology can "do" gigabyte blocks I'm sure, If you accept that you need a
small cluster to keep up with validation, and all blocks are produced by a
single miner cartel.
IMHO, Bitcoin (or any cryptocurrency) on-chain as a payment system is:
* Expensive: there is a (known in advance and agreed upon) inflation that
we're using to pay miners. But by holding Bitcoin you're paying for the
security of the system, even if it is not in fees.
* Unreliable: you never know when suddenly there will be more higher-fee
transactions that outbid you.
* Slow, unless you already trust the sender to not double spend (in which
case you don't actually need the security of the blockchain).
I don't know the future, and I don't know what use cases will develop and
what they'll want to pay or what reliability they need. But let's please
not throw out the one quality that Bitcoin is still good at: lack of
centralized parties to trust.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/a9e6e3a9/attachment.html>

2023-06-07 17:33:32

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you feel
>> that blocks should be increased in response to (or for fear of) such a
>> scenario.
>>
>
> I think there are multiple reasons to raise the maximum block size, and
> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
> of the reasons.
>
> I take the opinion of smart engineers who actually do resource planning
> and have seen what happens when networks run out of capacity very seriously.
>
This is a fundamental disagreement then. I believe that the demand is
infinite if you don't set a fee minimum (and I don't think we should), and
it just takes time for the market to find a way to fill whatever is
available - the rest goes into off-chain systems anyway. You will run out
of capacity at any size, and acting out of fear of that reality does not
improve the system. Whatever size blocks are actually produced, I believe
the result will either be something people consider too small to be
competitive ("you mean Bitcoin can only do 24 transactions per second?"
sounds almost the same as "you mean Bitcoin can only do 3 transactions per
second?"), or something that is very centralized in practice, and likely
both.
> And if so, if that is a reason for increase now, won't it be a reason for
>> an increase later as well? It is my impression that your answer is yes,
>> that this is why you want to increase the block size quickly and
>> significantly, but correct me if I'm wrong.
>>
>
> Sure, it might be a reason for an increase later. Here's my message to
> in-the-future Bitcoin engineers: you should consider raising the maximum
> block size if needed and you think the benefits of doing so (like increased
> adoption or lower transaction fees or increased reliability) outweigh the
> costs (like higher operating costs for full-nodes or the disruption caused
> by ANY consensus rule change).
>
In general that sounds reasonable, but it's a dangerous precedent to make
technical decisions based on a fear of change of economics...
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/8322a671/attachment.html>

2023-06-07 17:33:31

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
> low fee.
>
> All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>
> In the limit, that logic becomes "wait an infinite amount of time, pay
> zero fee."
>
That's only the case when the actual rate of transactions with a non-zero
fee is below what fits in blocks. If the total production rate is higher,
even without configured floor by miners, a free transaction won't ever be
mined, as there will always be some backlog of non-free transaction. Not
saying that this is a likely outcome - it would inevitably mean that people
are creating transactions without any guarantee that they'll be mined,
which may not be what anyone is interested in. But perhaps there is some
"use" for ultra-low-priority unreliable transactions (... despite DoS
attacks).
>
> So... I have no idea what the 'market minimum fee' will be, because I have
> no idea how long people will be willing to wait, how many times they'll be
> willing to retransmit a low-fee transaction that gets evicted from
> memory-limited memory pools, or how much memory miners will be willing to
> dedicate to storing transactions that won't confirm for a long time because
> they're waiting for a flurry of blocks to be found.
>
Fair enough, I don't think anyone knows.
I guess my question (and perhaps that's what Jorge is after): do you feel
that blocks should be increased in response to (or for fear of) such a
scenario. And if so, if that is a reason for increase now, won't it be a
reason for an increase later as well? It is my impression that your answer
is yes, that this is why you want to increase the block size quickly and
significantly, but correct me if I'm wrong.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/a3e40340/attachment.html>

2023-06-07 17:33:27

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Aug 7, 2015 7:50 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of people in the
ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
improvement over other systems is the lack of need for trust, I believe
that with increased adoption should also come an increased (in absolute
terms) incentive for people to use a full node. I'm seeing the opposite
trend, and that is worrying IMHO.
>
>
> Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?
I shouldn't have said majority, sorry. But I do believe that as the odds at
stake in the system go up, so should those who take an interest in
verifying. That doesn't seem to be the case, and is a problem, where that
is a result of the block chain size or not.
> If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.
>
> I believe people in the Bitcoin ecosystem will choose different
tradeoffs, and I believe that is OK-- people should be free to make those
tradeoffs.
I agree. Though I believe that the blockchain itself cannot offer many
tradeoffs, and by trying to make it scale we hurt the whole system. The
place to introduce tradeoffs is in layers on top - there you can build
systems with various levels of trust without hurting others.
> And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then).
That's inevitable, I'm sure.
> I firmly believe that block size has very little to do with the decision
to run a full node or not.
Within certain limits, maybe not. Within certain limits, maybe it also does
not incentivize trusted miner setups like SPV mining (which hurt the
security of SPV nodes tremendously).
But if the reason for increasing is because you fear a change of economics,
then it means you prefer not dealing with that change. I believe you prefer
not dealing with it ever, and would rather have a system where as much as
possible happens on-chain, even when we unknowingly go beyond those limits.
I think we don't do the ecosystem a service by promising that such a future
is possible without compromises.
So, I think the block size should follow technological evolution, and not
reenforce the belief that the block size should follow demand. There will
always be demand, and we should learn to deal with it.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/e442538b/attachment.html>

2023-06-07 17:33:25

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > If the incentives for running a node don't weight up against the
> > cost/difficulty using a full node yourself for a majority of people in
> the
> > ecosystem, I would argue that there is a problem. As Bitcoin's
> fundamental
> > improvement over other systems is the lack of need for trust, I believe
> > that with increased adoption should also come an increased (in absolute
> > terms) incentive for people to use a full node. I'm seeing the opposite
> > trend, and that is worrying IMHO.
>
> And you do the same thing again; you dismiss the need factor.
>
Of course there is a need. It's the primary mechanism that keeps Bitcoin
secure and immune from malicious influence.
Of course not everyone needs to run a node. But that leaves the
responsibility on us - the community - to help the situation by not making
it too hard to run a node. And I see the block size as the primary way
through which we do that.
If the impact of the system goes us, so should the - joint - incentives to
keep it secure. And I think we're (slowly) failing at that.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/96f446eb/attachment.html>

2023-06-07 17:32:59

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based
> on the 51% rule. But aren't they using full nodes for propagation? In this
> sense, anyone can vote by coding.
>
They don't need to use full nodes for propagation. Miners don't care when
other full nodes hear about their blocks, only whether they (eventually)
accept them.
And yes, full nodes can change what blocks they accept. That's called a
hard fork :)
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/2899162c/attachment.html>

2023-06-07 17:32:55

- reply

📅 Original date posted:2015-08-04
📝 Original message:I would like to withdraw my proposal from your self-appointed vote.
If you want to let a majority decide about economic policy of a currency, I
suggest fiat currencies. They have been using this approach for quite a
while, I hear.
Bitcoin's consensus rules are a consensus system, not a democracy. Find a
solution that everyone agrees on, or don't.
On Aug 4, 2015 9:51 AM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> As now we have some concrete proposals (
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html),
> I think we should wrap up the endless debate with voting by different
> stakeholder groups.
>
> ---------------------------------
> Candidate proposals
>
> Candidate proposals must be complete BIPs with reference implementation
> which are ready to merge immediately. They must first go through the usual
> peer review process and get approved by the developers in a technical
> standpoint, without political or philosophical considerations. Any fine
> tune of a candidate proposal may not become an independent candidate,
> unless it introduces some “real” difference. “No change” is also one of the
> voting options.
> ---------------------------------
> Voter groups
>
> There will be several voter groups and their votes will be counted
> independently. (The time frames mentioned below are just for example.)
>
> Miners: miners of blocks with timestamp between 1 to 30 Sept 2015 are
> eligible to vote. One block one vote. Miners will cast their votes by
> signing with the bitcoin address in coinbase. If there are multiple
> coinbase outputs, the vote is discounted by output value / total coinbase
> output value.
> Many well-known pools are reusing addresses and they may not need to
> digitally sign their votes. In case there is any dispute, the digitally
> signed vote will be counted.
>
> Bitcoin holders: People with bitcoin in the UTXO at block 372500 (around
> early September) are eligible to vote. The total “balance” of each
> scriptPubKey is calculated and this is the weight of the vote. People will
> cast their votes by digital signature.
> Special output types:
> Multi-sig: vote must be signed according to the setting of the multi-sig.
> P2SH: the serialized script must be provided
> Publicly known private key: not eligible to vote
> Non-standard script according to latest Bitcoin Core rules: not eligible
> to vote in general. May be judged case-by-case
>
> Developers: People with certain amount of contribution in the past year in
> Bitcoin Core or other open sources wallet / alternative implementations.
> One person one vote.
>
> Exchanges: Centralized exchanges listed on Coindesk Bitcoin Index,
> Winkdex, or NYSE Bitcoin index, with 30 days volume >100,000BTC are
> invited. This includes Bitfinex, BTC China, BitStamp, BTC-E, itBit, OKCoin,
> Huobi, Coinbase. Exchanges operated for at least 1 year with 100,000BTC
> 30-day volume may also apply to be a voter in this category. One exchange
> one vote.
>
> Merchants and service providers: This category includes all bitcoin
> accepting business that is not centralized fiat-currency exchange, e.g.
> virtual or physical stores, gambling sites, online wallet service, payment
> processors like Bitpay, decentralized exchange like Localbitcoin, ETF
> operators like Secondmarket Bitcoin Investment Trust. They must directly
> process bitcoin without relying on third party. They should process at
> least 100BTC in the last 30-days. One merchant one vote.
>
> Full nodes operators: People operating full nodes for at least 168 hours
> (1 week) in July 2015 are eligible to vote, determined by the log of
> Bitnodes. Time is set in the past to avoid manipulation. One IP address one
> vote. Vote must be sent from the node’s IP address.
>
> --------------------
> Voting system
>
> Single transferable vote is applied. (
> https://en.wikipedia.org/wiki/Single_transferable_vote). Voters are
> required to rank their preference with “1”, “2”, “3”, etc, or use “N” to
> indicate rejection of a candidate.
> Vote counting starts with every voter’s first choice. The candidate with
> fewest votes is eliminated and those votes are transferred according to
> their second choice. This process repeats until only one candidate is left,
> which is the most popular candidate. The result is presented as the
> approval rate: final votes for the most popular candidate / all valid votes
>
> After the most popular candidate is determined, the whole counting process
> is repeated by eliminating this candidate, which will find the approval
> rate for the second most popular candidate. The process repeats until all
> proposals are ranked with the approval rate calculated.
>
> --------------------
> Interpretation of results:
>
> It is possible that a candidate with lower ranking to have higher approval
> rate. However, ranking is more important than the approval rate, unless the
> difference in approval rate is really huge. 90% support would be excellent;
> 70% is good; 50% is marginal; <50% is failed.
>
> --------------------
> Technical issues:
>
> Voting by the miners, developers, exchanges, and merchants are probably
> the easiest. We need a trusted person to verify the voters’ identity by
> email, website, or digital signature. The trusted person will collect votes
> and publish the named votes so anyone could verify the results.
>
> For full nodes, we need a trusted person to setup a website as an
> interface to vote. The votes with IP address will be published.
>
> For bitcoin holders, the workload could be very high and we may need some
> automatic system to collect and count the votes. If people are worrying
> about reduced security due to exposed raw public key, they should move
> their bitcoin to a new address before voting.
>
> Double voting: people are generally not allowed to change their mind after
> voting, especially for anonymous voters like bitcoin holders and solo
> miners. A double voting attempt from these classes will invalidate all
> related votes.
>
> Multiple identity: People may have multiple roles in the Bitcoin ecology.
> I believe they should be allowed to vote in all applicable categories since
> they are contributing more than other people.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/db57dc3a/attachment-0001.html>

2023-06-07 17:32:36

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."
I partially agree. The community should decide what risks it is willing to
take, and set limits accordingly. Let the market decide how that space is
best used.
>
>>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
blocksize increase proposals should have to justify "why this size" or "why
this rate of increase." Part of my frustration with this whole debate is
we're talking about a sanity-check upper-limit; as long as it doesn't open
up some terrible new DoS possibility I don't think it really matters much
what the exact number is.
It is only a DoS protection limit if you want to rely on trusting miners. I
prefer a system where I don't have to do that.
But I agree the numbers don't matter much, for a different reason: the
market will fill up whatever space is available, and we'll have the same
discussion when the new limit doesn't seem enough anymore.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/7e4c45e8/attachment.html>

2023-06-07 17:32:33

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> But you seem to consider that a bad thing. Maybe saying that you're
>> claiming that this equals Bitcoin failing is an exaggeration, but you do
>> believe that evolving towards an ecosystem where there is competition for
>> block space is a bad thing, right?
>>
>
> No, competition for block space is good.
>
So if we would have 8 MB blocks, and there is a sudden influx of users (or
settlement systems, who serve much more users) who want to pay high fees
(let's say 20 transactions per second) making the block chain inaccessible
for low fee transactions, and unreliable for medium fee transactions (for
any value of low, medium, and high), would you be ok with that? If so, why
is 8 MB good but 1 MB not? To me, they're a small constant factor that does
not fundamentally improve the scale of the system. I dislike the outlook of
"being forever locked at the same scale" while technology evolves, so my
proposal tries to address that part. It intentionally does not try to
improve a small factor, because I don't think it is valuable.
What is bad is artificially limiting or centrally controlling the supply of
> that space.
>
It's exactly as centrally limited as the finite supply of BTC - by
consensus. You and I may agree that a finite supply is a good thing, and
may disagree about whether a consensus rule about the block size is a good
idea (and if so, at what level), but it's a choice we make as a community
about the rules of the system we want to use.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/d69b8f33/attachment-0001.html>

2023-06-07 17:32:33

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is a much more reasonable position. I wish this had been starting
>> point of this discussion instead of "the block size limit must be
>> increased as soon as possible or bitcoin will fail".
>>
>
> It REALLY doesn't help the debate when you say patently false statements
> like that.
>
> My first blog post on this issue is here:
> http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
>
> ... and I NEVER say "Bitcoin will fail". I say:
>
> "If the number of transactions waiting gets large enough, the end result
> will be an over-saturated network, busy doing nothing productive. I don’t
> think that is likely– it is more likely people just stop using Bitcoin
> because transaction confirmation becomes increasingly unreliable."
>
But you seem to consider that a bad thing. Maybe saying that you're
claiming that this equals Bitcoin failing is an exaggeration, but you do
believe that evolving towards an ecosystem where there is competition for
block space is a bad thing, right?
I don't agree that "Not everyone is able to use the block chain for every
use case" is the same thing as "People stop using Bitcoin". People are
already not using it for every use case.
Here is what my proposed BIP says: "No hard forking change that relaxes the
block size limit can be guaranteed to provide enough space for every
possible demand - or even any particular demand - unless strong
centralization of the mining ecosystem is expected. Because of that, the
development of a fee market and the evolution towards an ecosystem that is
able to cope with block space competition should be considered healthy."
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/aff56c38/attachment.html>

2023-06-07 17:32:27

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I would say that things already demonstrately got terrible. The mining
>> landscape is very centralized, with apparently a majority depending on
>> agreements to trust each other's announced blocks without validation.
>>
> And that is a problem... why?
>
If miners need to form alliances of trusting each other's blocks without
validation to overcome the inefficiencies of slow block propagation, I
think we have a system that is in direct conflict with the word
"permissionless" that you use later.
> As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's
> original code did everything: hashing, block assembly, wallet, consensus,
> network. That is changing, and that is OK.
>
Specialization is perfectly fine.
>
> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
Why is what you, personally, find interesting relevant?
>
I find it interesting to build a system that has potential to bring about
innovation.
I understand you want to build an extremely decentralized system, where
> everybody participating trusts nothing except the genesis block hash.
>
That is not true, I'm sorry if that is the impression I gave.
I see centralization and scalability as a trade-off, and for better or for
worse, the block chain only offers one trade-off. I want to see technology
built on top that introduces lower levels of trust than typical fully
centralized systems, while offering increased convenience, speed,
reliability, and scale. I just don't think that all of that can happen on
the lowest layer without hurting everything built on top. We need different
trade-offs, and the blockchain is just one, but a very fundamental one.
I think it is more interesting to build a system that works for hundreds of
> millions of people, with no central point of control and the opportunity
> for ANYBODY to participate at any level. Permission-less innovation is what
> I find interesting.
>
That sounds amazing, but do you think that Bitcoin, as it exists today, can
scale to hundreds of millions of users, while retaining any glimpse of
permission-lessness and decentralization? I think we need low-trust
off-chain systems and other innovations to make that happen.
> And I think the current "demonstrably terrible" Bitcoin system is still
> INCREDIBLY interesting.
>
I'm happy for you, then.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/1128ad92/attachment.html>

2023-06-07 17:32:23

- reply

📅 Original date posted:2015-08-04
📝 Original message:I would say that things already demonstrately got terrible. The mining
landscape is very centralized, with apparently a majority depending on
agreements to trust each other's announced blocks without validation. Full
node count is at its historically lowest value in years, and outsourcing of
full validation keeps growing.
I believe that if the above would have happened overnight, people would
have cried wolf. But somehow it happened slow enough, and "things kept
working".
I don't think that this is a good criterion. Bitcoin can "work" with
gigabyte blocks today, if everyone uses the same few blockchain validation
services, the same few online wallets, and mining is done by a cartel that
only allows joining after signing a contract so they can sue you if you
create an invalid block. Do you think people will then agree that "things
got demonstratebly worse"?
Don't turn Bitcoin into something uninteresting, please.
--
Pieter
On Aug 4, 2015 1:04 PM, "Hector Chu via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Mike's position is that he wants the block size limit
> to eventually be removed. That is of course an extreme view. Meanwhile,
> your view that the block size should be artificially constrained below the
> organic growth curve (in a way that will penalize a majority of existing
> and future users) lies at the other extreme. The majority position lies
> somewhere in between (i.e. a one-time increase to 8MB). This is the
> position that ultimately matters.
>
> If the block size is increased to 8MB and things get demonstrably a whole
> lot worse, then you will have a solid leg to stand on. In that case we can
> always do another hard fork later to reduce the block size back to
> something smaller, and henceforth the block size will never be touched
> again.
>
> On 4 August 2015 at 11:35, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn <hearn at vinumeris.com> wrote:
>> >> How more users or more nodes can bring more miners, or more
>> importantly,
>> >> improve mining decentralization?
>> >
>> >
>> > Because the bigger the ecosystem is the more interest there is in taking
>> > part?
>>
>> As explained by Venzen, this is a non-sequitur.
>>
>> > I mean, I guess I don't know how to answer your question.
>>
>> I don't know the answer either, that's fine. It's the opposite
>> question that I've been insistently repeating and you've been
>> (consciously or not) consistently evading.
>> But that's also fine because I believe you finally answer it a few lines
>> below.
>>
>> > When Bitcoin was
>> > new it had almost no users and almost no miners. Now there are millions
>> of
>> > users and factories producing ASICs just for Bitcoin.
>>
>> The emergence of a btc price enabled the emergence of professional
>> miners, which in turn enabled the emergence of sha256d-specialized
>> hardware production companies.
>> Nothing surprising there.
>> By no means it consitutes an example of how a bigger consensus sizes
>> can cause less mining centralization.
>>
>> > Surely the correlation is obvious?
>>
>> Correlation does not imply causation. I will better leave it at that...
>>
>> >> I'm sorry, but until there's a simulation that I can run with different
>> >> sizes' testchains (for example using #6382) to somehow compare them, I
>> will
>> >> consider any value arbitrary.
>> >
>> >
>> > Gavin did run simulations. 20mb isn't arbitrary, the process behind it
>> was
>> > well documented here:
>> >
>> >
>> http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
>> >
>> > I chose 20MB as a reasonable block size to target because 170 gigabytes
>> per
>> > month comfortably fits into the typical 250-300 gigabytes per month data
>> > cap– so you can run a full node from home on a “pretty good” broadband
>> plan.
>> >
>> > Did you think 20mb was picked randomly?
>>
>> No, I think 20 MB was chosen very optimistically, considering 3rd
>> party services rates (not the same service as self-hosting) in the
>> so-called "first world". And then 20 MB goes to 20 GB, again with
>> optimistic and by no means scientific expectations.
>>
>> But where the number comes from it's not really what I'm demaning,
>> what I want is some criterion that can tell you that a given size
>> would be "too centralized" but another one isn't.
>> I haven't read any analysis on why 8GB is a better option than 7GB and
>> 9GB for a given criterion (nor one declaring 20 GB a winner over 19 GB
>> or 21 GB).
>> A simulation test passing 20 GB but not 21 GB would make it far less
>> arbitrary.
>>
>> >> Agreed on the first sentence, I'm just saying that the influence of
>> >> the blocksize in that function is monotonic: with bigger sizes, equal
>> >> or worse mining centralization.
>> >
>> >
>> > I have a hard time agreeing with this because I've seen Bitcoin go from
>> > blocks that were often empty to blocks that are often full, and in this
>> time
>> > the number of miners and hash power on the network has gone up a huge
>> amount
>> > too.
>>
>> I'm of course talking about consensus maximum blocksize, not about
>> actual blocksize.
>> Yes, again, when mining becomes profitable, economic actors tend to
>> appear and get those profits.
>> But don't confuse total hashrate improvements with an "increase in the
>> number of miners" or with mining decentralization.
>>
>> > You can argue that a miner doesn't count if they pool mine. But if a
>> miner
>> > mines on a pool that uses exactly the same software and settings as the
>> > miner would have done anyway, then it makes no difference. Miners can
>> switch
>> > between pools to find one that works the way they like, so whilst less
>> > pooling or more decentralised pools would be nice (e.g.
>> getblocktemplate),
>> > and I've written about how to push it forward before, I still say there
>> are
>> > many more miners than in the past.
>> >
>> > If I had to pick between two changes to improve mining decentralisation:
>> >
>> > 1) Lower block size
>>
>> Finally, I think you finally answered my repetitive question here.
>> If I say "Mike Hearn understands that the consensus block size maximum
>> rule is a tool for limitting mining centralization" I'm not putting
>> words in your mouth, right?
>> I think many users advocating for an increase in the consensus limit
>> don't understand this, which is extremely unfortunate for the debate.
>>
>> > 2) Finishing, documenting, and making the UX really slick for a
>> > getblocktemplate based decentralised mining pool
>> >
>> > then I'd pick (2) in a heartbeat. I think it'd be a lot more effective.
>>
>> Great! Maybe after 2 mining centralization improves so much that we're
>> confortable not only not lowering it but rather increasing it.
>>
>> >> you should be consequently advocating for full removal of the limit
>> rather
>> >> than changes towards bigger arbitrary values.
>> >
>> >
>> > I did toy with that idea a while ago. Of course there can not really be
>> no
>> > limit at all because the code assumes blocks fit into RAM/swap, and
>> nodes
>> > would just end up ignoring blocks they couldn't download in time anyway.
>> > There is obviously a physical limit somewhere.
>>
>> Did the fact that you "understand that the consensus block size
>> maximum rule is a tool for limitting mining centralization" influenced
>> your rejection of that idea at all?
>>
>> > But it is easier to find common ground with others by compromising. Is
>> 8mb
>> > better than no limit? I don't know and I don't care much: I think
>> Bitcoin
>> > adoption is a slow, hard process and we'll be lucky to increase average
>> > usage 8x over the next couple of years. So if 8mb+ is better for others,
>> > that's OK by me.
>>
>> The only way that "not caring much whther we have a consensus limit or
>> not" and "understand that the consensus block size maximum rule is a
>> tool for limitting mining centralization" at the same time is by not
>> caring about mining centralization at all.
>> Is that your position?
>>
>> If you don't care about having a limit but you don't want to limit
>> transaction volume, then ++current_size will ALWAYs be your
>> "compromise position" and no blocksize increase will ever be enough
>> until the limit is completely removed.
>> Is that your position?
>>
>> > Re: exchange profit. You can pick some other useful service provider if
>> you
>> > like. Payment processors or cold storage providers or the TREZOR
>> > manufacturers or whoever.
>>
>> Yes, and I believe the same points stand.
>>
>> > My point is you can't have a tiny high-value-transactions only currency
>> AND
>> > all the useful infrastructure that the Bitcoin community is making.
>> It's a
>> > contradiction. And without the infrastructure bitcoin ceases to be
>> > interesting even to people who are willing to pay huge sums to use it.
>>
>> You keep talking about "high-value-transactions-only" like if
>> non-urgent transaction fees rising from zero to, say, 1 satoshi, would
>> automatically result in that "high-value-transactions-only" Bitcoin.
>> Please, stop talking as if someone was proposing a
>> "high-value-transactions-only" Bitcoin. That may happen but nobody
>> really knows. If it happens it may not be bad thing necessarily (ie
>> bitcoin microtransactions can still happen using trustless payment
>> channels and x is still cheaper than x% for any transacted value
>> higher than 100) but that's really not what we're talking about here
>> so it seems distraction that can only help further polirizing this
>> discussion.
>>
>> What we're talking about here is that hitting the limit would
>> (hopefully) make miners start caring about fees. Enough that they stop
>> being irrational about free transactions. If both things happen,
>> non-urgent transaction fees will likely rise (as said, above zero).
>>
>> You think that would be a catastrophe for adoption and I disagree.
>> But (as Pieter has repeatedly explained) for any size there will be
>> use cases that will be eventually priced out.
>> So when rising this consensus limit, not increasing centralization
>> should be the priority and the potential impact in market fees a much
>> more secondary concern.
>> Do you agree with this?
>>
>> I'm sure there are many intermediate positions between "caring more
>> about mining centralization than market fees when deciding about a
>> consensus rule that limits mining centralization" and "not caring
>> about mining centralization at all".
>> I really don't want to put words in your mouth, but I honestly don't
>> know what your position is.
>> I don't really know how else can I ask the same question: you don't
>> care the consensus maximum blocksize rule being here at all or not
>> (you just said that).
>> Is it because you don't think it limits mining centralization or
>> because you don't care about limiting mining centralization with
>> consensus rules at all?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/2b6fdfa3/attachment.html>

2023-06-07 17:32:10

- reply

📅 Original date posted:2015-08-02
📝 Original message:>>> 2. Starting date: 30 days after 75% miner support, but not before
>>> 2016-01-12 00:00 UTC
>>>
>>> Rationale: A 30-day grace period is given to make sure everyone has
>>> enough time to follow. This is a compromise between 14 day in BIP101
>>> and 1 year in BIP103. I tend to agree with BIP101. Even 1 year is
>>> given, people will just do it on the 364th day if they opt to
>>> procrastinate.
>>
>>
>> Given the time recent softforks have taken to deploy, I think that's
>> too soon.
>
>
> Since I'm using "30 days after 75% miner support", the actual deployment
period will be longer than 30 days. Anyway, if all major exchanges and
merchants agree to upgrade, people are forced to upgrade immediately or
they will follow a worthless chain.
If we don't want it to go fast, why let them? A hardfork is a means for the
community to agree on the rules that different parties have to obey.
>>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and
>>> multiplied by 1.414213 by every 2^23 seconds (97 days) until exactly
>>> 8MB is reached on 2017-05-11.
>>>
>>> Rationale: Instead of jumping to 8MB, I suggest to increase it
>>> gradually to 8MB in 16 months. 8MB should not be particularly
>>> painful to run even with current equipment (you may see my earlier
>>> post on bitctointalk:
>>> https://bitcointalk.org/index.php?topic=1054482.0 ). 8MB is also
>>>
>>> agreed by Chinese miners, who control >60% of the network.
>>
>>
>> I have considered suggesting a faster ramp-up in the beginning, but I
>> don't think there is indisputable evidence that we can currently deal
>> with significantly larger blocks. I don't think "painful" is the right
>> criterion either; I'm sure my equipment can "handle" 20 MB blocks too,
>> but with a huge impact on network propagation speed, and even more
>> people choosing the outsource their full nodes.
>>
>> Regarding "reasonable", I have a theory. What if we would have had 8
>> MB blocks from the start? My guess is that some more people would have
>> decided to run their high-transaction-rate use cases on chain, that
>> we'd regularly see 4-6 MB blocks, there would be more complaints about
>> low full node counts, maybe 90% instead of 60% of the hash rate would
>> be have SPV mining agreements with each other, we'd somehow have
>> accepted that even worse reality, but people would still be
>> complaining about the measly 25 transactions per second that Bitcoin
>> could handle on-chain, and be demanding a faster rampup to a more
>> "reasonable" 64 MB block size as well.
>
>
> Since the block reward is miners' major income source, no rational miner
would create mega blocks unless the fee could cover the extra orphaning
risk. Blocks were not constantly full until recent months, and many miners
are still keeping the 750kB soft limit. This strongly suggests that we
won't have 4MB blocks now even Satoshi set a 8MB limit.
I disagree. I think "demand" is strongly influenced by the knowledge of
space that looks available. If you look at historic block sizes, you see it
follows a series of block functions, not nice organic growth. My theory is
that this is changed defaults in software, new services appearing suddenly,
and people reacting to it. Demand fills the available space.
Also, SPV mining has nearly zero orphaning risk, only brief chance of loss
of fees as income.
> I don't have the data now but I believe the Satoshi Dice model failed not
primarily due to the 1MB cap, but the raise in BTC/USD rate. Since minting
reward is a fixed value in BTC, the tx fee must also be valued in BTC as it
is primarily for compensating the extra orphaning risk. As the BTC/USD rate
increases, the tx fee measured in USD would also increase, making
micro-payment (measured in USD) unsustainable.
I agree, but how does that matter? I don't think high fees and full blocks
should be the goal, but I think it would be a healthier outcome than what
we have now.
> We might have less full nodes, but it was Satoshi's original plan: "At
first, most users would run network nodes, but as the network grows beyond
a certain point, it would be left more and more to specialists with server
farms of specialized hardware. A server farm would only need to have one
node on the network and the rest of the LAN connects with that one node."
Theoretically, we only require one honest full node to prove wrongdoing on
the blockchain and tell every SPV nodes to blacklist the invalid chain.
Theoretically, we also only need one central bank, then? Sorry, if the
outcome is one (or just a few) entities that keep the system in check, I
think it loses any benefit it has over other systems, while still keeping
its costs and disadvantages (confirmation speed, mining infrastructure,
subsidy...).
I know that 8 MB blocks do not immediately mean such a dramatic outcome.
But I do believe that as a community setting the block size based on
observed demand (which you do by saying "8 is a more reasonable size than
2" as argument) is the wrong way. What do you do when your 8 MB starts to
look "full", before your schedule says it can increase?
The block size and its costs - bandwidth, processing, centralization
effects for miners, ... - are the things that should be constrained. Demand
will fill it.
> I think SPV mining exists long before the 1MB block became full, and I
don't think we could stop this trend by artificially suppressing the block
size. Miners should just do it properly, e.g. stop mining until the
grandparent block is verified, which would make sure an invalid fork won't
grow beyond 2 blocks.
That would be a huge reduction in security as a mechanism itself, and even
worse due to needing to trust miners to follow that protocol. Without
proper incentives, miners become a trusted party, and due to needed SPV
mining agreements, potentially a closed group too. That is not an
interesting future.
> If you believe Bitcoin should become a global settlement network, 32MB
would be the very minimum as that is only 75% of current SWIFT traffic.
See my BIP text about advantages of Bitcoin, please. A future where it has
to compete with the existing system - using that system's own strengths -
is not interesting.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150802/d39a8ed3/attachment.html>

2023-06-07 17:32:08

- reply

📅 Original date posted:2015-08-01
📝 Original message:On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of 750 out of the last
> 1000 blocks. The "hardfork bit" mechanism might be used:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>
This is fine, I think. I believe we shouldn't proceed with a hardfork
without having reasonable expectation that it will be deployed by everyone
in time, while we can only measure miner acceptance. Still, as a
belt-and-suspenders this won't hurt.
> 2. Starting date: 30 days after 75% miner support, but not before
> 2016-01-12 00:00 UTC
>
> Rationale: A 30-day grace period is given to make sure everyone has enough
> time to follow. This is a compromise between 14 day in BIP101 and 1 year in
> BIP103. I tend to agree with BIP101. Even 1 year is given, people will just
> do it on the 364th day if they opt to procrastinate.
>
Given the time recent softforks have taken to deploy, I think that's too
soon.
2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in China.
> Most pool operators and devs should be back from new year holiday and not
> sleeping. (If the initiation is delayed, we may require that it must be UTC
> Tuesday midnight).
>
That's an interesting thing to take into account.
> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied by
> 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on
> 2017-05-11.
>
> Rationale: Instead of jumping to 8MB, I suggest to increase it gradually
> to 8MB in 16 months. 8MB should not be particularly painful to run even
> with current equipment (you may see my earlier post on bitctointalk:
> https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed by
> Chinese miners, who control >60% of the network.
>
I have considered suggesting a faster ramp-up in the beginning, but I don't
think there is indisputable evidence that we can currently deal with
significantly larger blocks. I don't think "painful" is the right criterion
either; I'm sure my equipment can "handle" 20 MB blocks too, but with a
huge impact on network propagation speed, and even more people choosing the
outsource their full nodes.
Regarding "reasonable", I have a theory. What if we would have had 8 MB
blocks from the start? My guess is that some more people would have decided
to run their high-transaction-rate use cases on chain, that we'd regularly
see 4-6 MB blocks, there would be more complaints about low full node
counts, maybe 90% instead of 60% of the hash rate would be have SPV mining
agreements with each other, we'd somehow have accepted that even worse
reality, but people would still be complaining about the measly 25
transactions per second that Bitcoin could handle on-chain, and be
demanding a faster rampup to a more "reasonable" 64 MB block size as well.
>
> 4. After 8MB is reached, the block size will be increased by 6.714% every
> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
> 2042-11-17.
>
> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
> p.a. of BIP101. This will take us almost 8 years from now just to go back
> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>
> SSD price is expected to drop by >50%/year in the coming years. In 2020,
> we will only need to pay 2% of current price for SSD. 98% price reduction
> is enough for 40 years of 27.67% growth.
> Source:
> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>
I know many technologies have had faster growth, but I believe that global
bandwidth accessibility is the bottleneck, so the growth rate in my
proposal is based on that.
> Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
> should be safe at least for the coming 10 years.
> Source:
> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>
I'd rather be conservative here. My primary purpose is trying to create an
uncontroversial proposal that introduces an expectation of growth with
technology.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150801/78c2ce7a/attachment.html>

2023-06-07 17:32:08

- reply

📅 Original date posted:2015-08-01
📝 Original message:On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Regarding the block size increase, at least conceptually it seems to me
> there should be an easy solution. If we look at what works well with
> bitcoin, for example the block reward halving and difficulty regimes which
> due to their step function nature both contribute to the stability and
> predictability of the bitcoin universe while still allowing for the
> necessary dynamic adjustments. It seems to me there should be a
> corresponding and equally simple solution for the maximum block size.
>
> I've never quite understood the supposed rationale behind the proposals
> for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be
> trivial to implement. Why not come up with an equally simple, predictable
> dynamic function consistent with what is already proven to work in the
> bitcoin universe that would both preserve the scarcity of transaction
> capacity to encourage a fee market but also allow for more transactions
> when needed.
>
I disagree with the notion of "needed". The blockchain provides utility at
every size, and perhaps more at some sizes than at other sizes, but any
finite size will permit some use cases and not others. This is already the
case and will remain the case. I think the "demand for payments" should be
considered infinite, and some of them will fit on a block chain and pay a
fee for it, and others will need to rely on more efficient, cheaper, but
higher trust systems. You can't use observed usage as a metric for demand
without fixing the cost.
I think available space should grow with technology, to keep the relative
costs to the ecosystem for maintaining a decentralized system constant.
That may or may not lead to a fee market, but I don't think the fee market
is a goal - only a healthy outcome. The goal is an ecosystem that accepts
that the limit to scalability is set by the requirements of a decentralized
system, and its demand - and certainly not perceived demand at potentially
near-zero fee/cost - can't change that.
> For example how about something like once every month at month-end, take
> the 6-month average non-zero transaction fee block size and multiply by 1.5?
>
>
That's trivially gamable by miners, by filling the blocks with their own
transactions.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150801/df61499e/attachment.html>

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 11:30 PM, Angel Leon via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> tell that to people in poor countries, or even in first world countries.
> The competitive thing here is a deal breaker for a lot of people who have
> no clue/don't care for decentralization,
>
Then they also don't need their transactions to be on the blockchain, right?
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/f3e65461/attachment-0001.html>

2023-06-07 15:45:52

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>
The question is not what the technology can deliver. The question is what
price we're willing to pay for that. It is not a boolean "at this size,
things break, and below it, they work". A small constant factor increase
will unlikely break anything in the short term, but it will come with
higher centralization pressure of various forms. There is discussion about
whether these centralization pressures are significant, but citing that
it's artificially constrained under the limit is IMHO a misrepresentation.
It is constrained to aim for a certain balance between utility and risk,
and neither extreme is interesting, while possibly still "working".
Consensus rules are what keeps the system together. You can't simply switch
to new rules on your own, because the rest of the system will end up
ignoring you. These rules are there for a reason. You and I may agree about
whether the 21M limit is necessary, and disagree about whether we need a
block size limit, but we should be extremely careful with change. My
position as Bitcoin Core developer is that we should merge consensus
changes only when they are uncontroversial. Even when you believe a more
invasive change is worth it, others may disagree, and the risk from
disagreement is likely larger than the effect of a small block size
increase by itself: the risk that suddenly every transaction can be spent
twice (once on each side of the fork), the very thing that the block chain
was designed to prevent.
My personal opinion is that we should aim to do a block size increase for
the right reasons. I don't think fear of rising fees or unreliability
should be an issue: if fees are being paid, it means someone is willing to
pay them. If people are doing transactions despite being unreliable, there
must be a use for them. That may mean that some use cases don't fit
anymore, but that is already the case.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/851e0acb/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 8:43 PM, Michael Naber <mickeybob at gmail.com> wrote:
> How many nodes are necessary to ensure sufficient network reliability?
> Ten, a hundred, a thousand? At what point do we hit the point of
> diminishing returns, where adding extra nodes starts to have negligible
> impact on the overall reliability of the system?
>
It's not about reliability. There are plenty of nodes currently for
synchronization and other network functions.
It's about reduction of trust. Running a full node and using it verify your
transactions is how you get personal assurance that everyone on the network
is following the rules. And if you don't do so yourself, the knowledge that
others are using full nodes and relying on them is valuable. Someone just
running 1000 nodes in a data center and not using them for anything does
not do anything for this, it's adding network capacity without use.
That doesn't mean that the full node count (or the reachable full node
count even) are meaningless numbers. They are an indication of how hard it
is (for various reasons) to run/use a full node, and thus provide feedback.
But they are not the goal, just an indicator.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/5c5defdf/attachment-0001.html>

- reply

- reply

- reply

- reply