<unnamed>

Public Key

npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r

Profile Code

nprofile1qqs9evsm7htlyk5ag6rewy7t6vjr8w7ppeqwlqf68s50uu647jv9f4spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsjcy6ea

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:19:50 CEST

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: A proposal to use short IDs to minimize bandwidth in Bitcoin transactions has been suggested, with short ID 0 reserved for long commands. This would reduce complexity and eliminate the need for variable-length encoding.
📝 Original message:On Friday, February 17th, 2023 at 10:51 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it's probably less complex to close some of the doors?
> 2) are short ids available/meaningful to send prior to VERACK being
> completed?
Ah, I hadn't considered this nuance. If we don't care about them being available before VERACK negotiation, then it may be possible to introduce a way to negotiate a different short id mapping table without needing a mechanism for *re*-negotiating.
> Here's another approach:
>
> idea: we use short ids to minimise bandwidth, and don't care about
> bandwidth for long ids
>
> implementation:
> short id 0 is reserved for long commands. when received, we
> decode the first 12 bytes of the payload and treat them
> exactly the same as a v1 p2p message (trailing 0-bytes, etc)
> (if there's not 12 bytes of payload, it's just treated as an
> invalid command and dropped)
>
> short ids 1-255 are available for use as aliases of particular
> long commands
>
> (That's exactly compatible with p2p v1, and also avoids the temptation
> to try to choose short command names rather than descriptive ones -- the
> 0-padding to 12 bytes prevents you from saving any bandwidth that way;
> but that's what we have short ids for anyway)
I like this idea. It avoids the variable-length encoding question and related complexity entirely for things where we admittedly don't care about the bandwidth impact anyway.
It may also have another (rather weak) advantage, in that it may reduce how much information a passive observe may learn about application level features (sendheaders, sendaddrv2, ...) from the packet size sent (which would otherwise depend on command lengths), even when decoys are not in use, if no short commands are included for these messages.
> > - We remove 1 byte allocations for messages that are sent at most once per connection per direction
>
> I think this leaves 32 commands that get short ids initially:
>
> misc: ADDR, ADDRV2, BLOCK, FEEFILTER, GETBLOCKS, GETDATA, GETHEADERS,
> HEADERS, INV, NOTFOUND, PING, PONG, TX
> bip 35/37: FILTERADD, FILTERCLEAR, FILTERLOAD, MEMPOOL, MERKLEBLOCK
> bip 152: BLOCKTXN, CMPCTBLOCK, GETBLOCKTXN
> bip 157: CFCHECKPT, CFHEADERS, CFILTER, GETCFCHCKPT, GETCFHEADERS,
> GETCFILTERS
> bip 330: RECONCILDIFF, REQRECON, REQSKETCHEXT, SENDCMPCT, SKETCH
Sounds right.
> which drops:
>
> VERSION, VERACK, GETADDR, SENDADDRV2, SENDHEADERS, SENDTXRCNCL,
> WTXIDRELAY
Indeed.
> compared to bip 324 currently.
>
> I think the things missing from the current list (and not currently in
> use by bitcoin core) are:
>
> bip 61: REJECT
> bip 331: GETPKGTXNS, PKGTXNS, ANCPKGINFO
Do you feel REJECT should be included?
> > - Optionally, in the implementation we can attempt to move the type id mapping to the p2p layer away from the transport layer. I suspect this could also be done after the implementation is merged but might be cleaner as the mapping is a p2p concern.
>
> I agree that's fine, though I expect that we'll probably want to do it
> not long after bip 331 is ready for merge (or some other p2p improvement
> comes along)...
I do prefer that as well; it feels like the transport layer shouldn't be aware of the different command names that exist, but this is very much just an implementation issue.
Perhaps a possibility is having the transport layer translate short-command-number-N to the 12-byte command "\x00\x00..." + byte(N), and hand that to the application layer, which could then do the mapping?
Cheers,
--
Pieter

2023-06-08 01:14:19 CEST

- reply

📅 Original date posted:2022-10-12
📝 Original message:On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.
>
>
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:
Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry for missing this; I see now that you were certainly aware of what the PR under consideration did.
Further comments inline.
> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
> > The question then is whether an opt-in flag for full-RBF will have enough
> > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > objective of allowing nodes participating in multi-party funding protocols
> > to assume that they can rely on full-RBF. If it is, then zero-conf applications
> > will be at severe risk (per the logic in the initial email).
>
>
> That logic seems reasonably sound to me:
>
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
>
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
>
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the network
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)
I certainly recognize that adding the flag is a likely step towards, over time, the full RBF policy becoming more widely adopted on the network. That is presumably the reason why people are in favor of having the flag, even default off - including me. I believe that policy's adoption is inevitable eventually, but the speed at which that is achieved is certainly a function of availability and adopted of software which provides the option.
That said, I think it's a bit of a jump to conclude that the only two options are that either the existence of the flag either has no effect at all, or poses an immediate threat to those relying on its absence. In my view, it is just what I said: a step towards getting full RBF on the network, by allowing experimentation and socializing the notion that developers believe it is time. So I have a hard time imagining how it would change anything *immediately* on the network at large (without things like default on and/or preferential peering, ...), but I still believe it's an important step.
Cheers,
--
Pieter

2023-06-08 01:14:18 CEST

- reply

📅 Original date posted:2022-10-11
📝 Original message:On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello David,
>
> Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> confusion. I'm referring to the opt-in flag for full-RBF from #25353
> (https://github.com/bitcoin/bitcoin/pull/25353).
Hello Dario,
It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.
As explained by others, it's only a configuration option that is default off, and the possibility of running rull-RBF policy nodes on the network have been trivial for anyone who wanted to for a long time on the network.
I don't want to sound dismissive of your concerns, but at this point I'm not convinced you're actually aware of what this PR does and doesn't do.
Cheers,
--
Pieter

2023-06-08 01:12:19 CEST

- 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-08 01:00:20 CEST

- reply

📅 Original date posted:2021-10-26
📝 Original message:On Monday, October 25th, 2021 at 10:56 PM, lisa neigut via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mempool is obsolete and should be eliminated.
Hi Lisa,
I see where this idea is coming from, especially as it relates to reducing complexities around transaction relays, but I strongly believe this is throwing out the baby with the bathwater. Comments inline below.
> In reality however, mempool relay is unnecessary where the majority of hashpower and thus block template creation is concentrated in a semi-restricted set.
The *entire* reason mining and PoW exist, as opposed to having a fixed, centralized (set of) actors who decide transaction ordering, is to make the "censorship rights" of the network permissionless. It is essential that anyone can become a miner if they dislike what existing miners are doing, with income close to proportional to their investment. The existing reality isn't perfect, but it's fairly close to that. Sure, at any given point in time, a nontrivial fraction of mining power is in the hands of a few, but over time, those can, and have, changed a lot. Furthermore, if miners were to actually exercise censorship, it could quite reasonably incentivize other ecosystem players to start mining, perhaps close at cost or even at a small loss.
Your proposal, as far as I can tell, makes it *far* harder to become a miner. Ideas to provide a mechanism for miners to publish their "tx submit" URL/IP/onion on chain don't help; that's dependent on other miners to not censor the publishing. Furthermore, it gives a tremendous centralizing incentive: it's just far easier for most wallets to just submit to the largest few pools, because the cost/complexity of an additional submission is independent of the pool's hashrate, but the benefit is directly proportional to it. There would be very little incentive to submit to a sub-1% pool for anyone.
> Removing the mempool would greatly reduce the bandwidth requirement for running a node,
That's not true due to compact blocks (most transactions are relayed exactly once to every node, and not repeated in blocks), and with Erlay it will be even less the case.
> keep intentionality of transactions private until confirmed/irrevocable,
Except to miners; it's replacing socialized transparency with a few who get to see the actual details. Not the same scale obviously, but there is some similarity to banks in the existing financial system. Our privacy goals shouldn't be relying on a few trusted gatekeepers.
> and naturally resolve all current issues inherent in package relay and rbf rules. It also resolves the recent minimum relay questions, as relay is no longer a concern for unmined transactions.
There are other solutions to this, like weak blocks (miners get to relay partial PoW solutuon of say 10% of the difficulty to the network; and nodes which receive such a weak block can "forcibly" insert its transaction to their mempool, as there is evidence it's actually being worked on, while still being DoS resistant because partial PoW is still PoW).
> Provided the number of block template producing actors remains beneath, say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can independently + directly submit their transactions to. In fact, merely allowing users to select their own list of endpoints to use alternatively to the mempool would be a low effort starting point for the eventual replacement.
In this scenario, there is no incentive for miners to relay to each other. The fewer other miners know about a high fee-paying transaction, the better you as a miner.
More conceptually: it is a responsibility of the full node network to relay blocks between miners quickly, to limit how much advantage well-connected miners over less-well-connected ones have. If the network doesn't have the transactions being included in those blocks, this is *far* harder (additional roundtrips, as nodes can't reconstruct from mempools).
> A direct communication channel between block template construction venues and transaction proposers also provides a venue for direct feedback wrt acceptable feerates at the time, which both makes transaction confirmation timelines less variable as well as provides block producers a mechanism for (independently) enforcing their own minimum security budget. In other words, expressing a minimum acceptable feerate for continued operation.
Yes, it's definitely easier. That doesn't make it right.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211026/f0c847d7/attachment-0001.html>

2023-06-08 00:59:33 CEST

- 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 20:27:40 CEST

- 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 20:26:21 CEST

- reply

📅 Original date posted:2020-08-19
📝 Original message:On Wednesday, August 12, 2020 11:49 AM, Pieter Wuille <bitcoin-dev at wuille.net> wrote:
> 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.
As the responses have been pretty positive so far, we've gone ahead and made a patch to implement the change to the even tiebreaker: https://github.com/sipa/bips/pull/210
If there are no other arguments (against), I'll PR it to the BIPs repo in a week or so.
All comments/questions/... still welcome.
Cheers,
--
Pieter

2023-06-07 20:26:19 CEST

- 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 20:23:11 CEST

- reply

📅 Original date posted:2020-03-03
📝 Original message:Hi all,
Given the recent activity and attention [1,2] around anti-covert channel
signing schemes, I decided to create this overview of the various techniques
that I know of, their trade-offs, and the various issues they protect against.
Most of this is based on various schemes by a number of authors, and credit
goes to them. I'm putting this together into something hopefully more
comprehensive, but mistakes and omissions in this writeup are likely mine.
I don't believe we have security proofs for any of the schemes, or for any of
the claims I make about the mitigation techniques below. I hope that having
all properties written up in one place makes it easier to eventually get those.
1) Security model
-----------------
When talking about signing with covert channels, we consider 3 parties:
* HW, the hardware wallet (or other offline signing device) with secret data
(a private key, or a seed from which the private key is derived).
* SW, the software wallet (or whatever communicates with HW and the network).
* OO, the outside observer who is trying to learn information about HW's
secret data.
We consider two distinct attack models:
* MSW, "malicious software wallet", but with honest HW. OO and SW are the
same party here, so this models the usual scenarios hardware wallets are
designed for, including side-channel attacks if those are considered to be
part of the threat model.
* MHW, "malicious hardware wallet", but with honest SW and no malicious party
being able to communicate with HW directly. OO and HW may have shared secret
information that SW (or anyone else) is unaware of. SW's job is trying to
prevent HW from using this to leak any information about its secret.
When both the HW and the SW are compromised, clearly no security is possible,
as all entities are controlled by the same party in that case.
In case HW uses a deterministic algorithm, it is possible to protect against
the MHW case by spot checking HW's behavior, by using an externally known
secret/seed. However, we'd like to have better than just spot checking
security, and for protection against side-channel attacks we may want
something that keeps working even when randomness is used by HW.
To keep the scope limited, we assume SW has no secret key of their own. This
rules out solutions like using 2-of-2 MuSig between HW and SW, which work, but
come with their own complications (like needing secure storage for that
secret).
2) Issues and solutions
-----------------------
In this section I will go over the various issues that exist in the MHW and MSW
models, the known mitigation techniques, and the resulting schemes.
I'm assuming a Schnorr-like signature protocol, though everything should apply
equally to ECDSA, and to a lesser extent probably also to multisignature
schemes. These variable names are used:
* H is a hash function.
* G is the curve generator.
* m is the message to be signed, known to and agreed upon by SW and HW.
* d is HW's secret key, with corresponding public key Q=dG.
* k is the secret nonce k, with corresponding public nonce R=kG.
The simplest protocol is naive Schnorr with deterministic nonce generation,
where SW only verifies that a signature created by HW is valid:
[Scheme 1: deterministic nonce, no tweak]
* SW requests a signature by sending (Q,m) to HW.
* HW computes k=H(d,m), R=kG, s=k+H(R,Q,m)d, and sends (R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, and publishes sig (R,s) in case of success.
2.a) Predictable k value
There is a simple attack against Scheme 1 that will leak the entire private
key undetectably using a single signature, under MHW. Assume HW and OO both
have access to a shared secret a, unknown to anyone else. HW computes
k=H(a,Q,m) instead, which SW cannot distinguish from the honest k=H(d,m) as it
knows neither a or d. OO can compute k using the same formula, and thus
recover the private key as d=(s-k)/H(R,Q,m).
The general strategy to avoid this is by letting SW provide entropy that is
included into the nonce computation. A very naive (and ineffective) way of
doing that would be:
* SW generates random t, and requests a signature by sending (Q,m,t) to HW.
* HW computes k0=H(d,m,t), R0=k0G, k=k0+t, R=kG, s=k+H(R,Q,m)d, and sends
(R0,R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+tG, and publishes sig (R,s) if all is good.
This does not help as HW can still choose k directly, and retroactively
compute R0 as R-tG, satsifying SW's requirements. To address that, there are
two options:
* Turning R into a binding commitment to R0 and t (see Scheme 2).
* Only revealing t after HW has revealed their R0 (see Scheme 3).
The first approach is based on making R a commitment to R0 and t using
R=R0+H(R0,t)G. When applied to public keys this is known as pay-to-contract
(and is the basis for Taproot); when applied to the R point in signatures it's
known as sign-to-contract [3]. These are generally useful approaches to make
public keys and signatures commit to/timestamp external data, but using this
to protect against covert channels in signatures was first discussed by Greg
Maxwell [4]:
[Scheme 2: deterministic nonce, S2C tweak]
* SW generates random t, and requests a signature by sending (Q,m,t) to HW.
* HW computes k0=H(d,m,t), R0=k0G, k=k0+H(R0,t), R=kG,
s=k+H(R,Q,m)d, and sends (R0,R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+H(R0,t)G, and publishes sig (R,s) if all
is good.
The second approach is adding a round, and only revealing the tweak t after HW
has revealed their R0:
[Scheme 3: deterministic nonce, tweak revealed after nonce]
* SW requests a signature by sending (Q,m) to HW.
* HW computes k0=H(d,m), R0=k0G, and sends R0 to SW.
* SW generates a random t, and sends it to HW.
* HW computes k=k0+t, R=kG, s=k+H(R,Q,m)d, and sends (R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+tG, and publishes (R,s) if all is good.
2.b) Replay attacks
Scheme 3 introduces another problem however, this time under MSW. SW can ask
HW to sign the same message twice, but then pick distinct values for t (t and
t'). The resulting R points will be R=(k0+t)G and R'=(k0+t')G, and the s
values will be s=k0+t+H(R,Q,m)d and s'=k0+t'+H(R',Q,m)d. This allows SW to
compute d=(s'-t'-s+t)/(H(R',Q,m)-H(R,Q,m)). A similar problem would also exist
in Scheme 2 if t wasn't included in the formula for k0.
The problem is that SW is allowed to change their tweak while the nonce
only undergoes a linear function known to SW. There are again two ways to
address this problem:
* Making k0 generation non-repeating by including a counter or randomness
in it (Scheme 4).
* Making SW commit to their tweak before revealing it as well (Scheme 5).
[Scheme 4: counter/random nonce, tweak revealed after nonce]
* SW requests a signature by sending (Q,m) to HW.
* HW uses a global counter c, or fresh randomness b, and computes k0=H(d,m,c)
or k0=H(d,m,b), R0=k0G, and sends R0 to SW.
* SW generates a random t, and sends it to HW.
* HW computes k=k0+t, R=kG, s=k+H(R,Q,m)d, and sends (R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+tH, and publishes (R,s) if all is good.
A variant of Scheme 4, but with multiplicative tweak rather than additive,
and only revealing H(R0) rather than R0 immediately, was suggested by Sergio
Demian Lerner in [5].
[Scheme 5: deterministic nonce, precommited tweak revealed after nonce]
* SW generates a random t, computes h=H(t), and requests a signature by
sending (Q,m,h) to HW.
* HW computes k0=H(d,m,h), R0=k0G, and sends R0 to SW.
* SW sends t to HW.
* HW verifies h=H(t), and if so, computes k=k0+t, R=kG, s=k+H(R,Q,m)d, and
sends (R,s) to SW.
* SW verifies sG=R+H(R,Q,m)Q, R=R0+tG, and publishes (R,s) if all is good.
Scheme 5 is the one suggested by Stepan Snigirev in [2,6]. A variant with
S2C tweaking instead of additive tweaked was suggested by Andrew Poelstra
in his talk [7], with transcript by Bryan Bishop in [8].
2.c) k0 grinding
So far Schemes 2, 4, and 5 protect against predictable k values and replay
attacks. Predictable k values are however not the only way MWH can leak
secrets.
If we imagine HW has significant computational power, in Scheme 2 it can try
many different k0 values (by deviating from k0=H(d,m,t)), and observe what the
resulting (R,s) signature will be. For example, by iterating on average 256
times, it can choose 8 bits in (R,s) that convey information about k, d, or
whatever seed or master key they are derived from. Using forward error
correction (FEC) schemes, this channel of a few bits per signature may be
enough to leak an entire seed over enough signatures. Using a shared secret a
between HW and OO those bits can again be made undetectable to anyone else.
Schemes 4 and 5 are not vulnerable to this problem, as they force HW to commit
to its R0 before knowing the resulting R. One might think that Scheme 4 merely
shifts this problem to MSW, where SW can grind t to make R biased in a similar
way. We assumed that SW does not have access to any secrets however, so this
is harmless.
2.d) Statefulness
We're left with Schemes 4 and 5 that protect against all listed issues. Both
need two interaction rounds, with state that needs to be kept by HW between
the rounds (the k0 value). While not a problem in theory, this may be hard to
implement safely in simple APIs.
One possibility is sticking with our "best one-round" Scheme 2, and accepting
that that implies the k0 grinding vulnerability.
There is another possibility, namely splitting Scheme 5 into two independent
interactions with HW, where no memory between them is needed on the HW side:
[Scheme 6: deterministic nonce, precommitted tweak revealed separately]
First interaction:
* SW generates a random t, computes h=H(t), and requests the R0 point that HW
would use by sending (Q,m,h) to HW.
* HW computes k0=H(d,m,h), R0=k0G, and sends R0 to SW.
Second interaction:
* SW requests a signature by sending (Q,m,t) to HW
* HW computes k0=H(d,m,H(t)), k=k0+t, R0=R0k, R=kG, s=k+H(R,Q,m)d, and sends
(R0,R,s) to SW.
* SW verifies that R0 matches the earlier R0 it received, and that
sG=R+H(R,Q,m)Q, R=R0+tG, and publishes (R,s) if all is good.
A variant of Scheme 6, with S2C tweaking instead of additive tweaking, is what
is being worked on by Jonas Nick [9] and Marko Bencun [10] for the
libsecp256k1 library.
The same technique cannot be applied to Scheme 4, as HW inherently needs state
to keep the counter c, or to remember the randomness b between interactions
there.
2.e) Failure bias
There is yet another, and even weaker, leak that is available in MHW: whenever
HW learns what the eventual signature (R,s) will be, it could pretend to fail
and go offline, or return some kind of error. In theory, this is enough to
introduce a similar bias, though it would come at possibly enormous failure
rates. If HW is allowed to fail 255 times out of 256, it can introduce an
8-bit bias, and employ similar techniques (FEC and shared HW/OO secret).
The obvious solution is showing a big warning to the user whenever any kind of
failure occurs (including device going offline, or returning invalid
responses) that the device is failing, and that if this happens frequently, it
should be treated as malicious.
Interestingly, Scheme 6 can be adapted to reduce this (already very weak)
channel further. The observation is that HW cannot predict during the first
interaction what (R,s) is going to be, as t is not known. This means it can
only fail during the second interaction when the result is already committed
to. Thus, if failure occurs during the second interaction, SW can simply
retry it with the same t value. If that succeeds, either a glitch occurred and
was safely retried, or the device's attempt to bias was prevented. If the
failure persists, the user should still be warned - as restarting with a
different k would reintroduce the possibility for bias.
2.f) Side-channel attacks
As a last consideration, let's see if these schemes have an impact on
potential resilience against side-channel attacks. I say potential, because
these classes of attacks are in general hard to protect against and model,
as they depend on implementation details and hardware protections. Still,
there are some general observations possible.
A significant amount of time in HW is likely spent on the EC multiplications
to obtain R0 and R from k0 and k. As s=k+H(R,Q,m)d, an variation of the replay
attack is possible here. In schemes with deterministic nonces, SW can ask for
the same signature twice, but use a fault injection to hopefully (only) cause
an error in R, R'. This would reveal (R,s) and (R',s') to SW, where s' is
k+H(R',Q,m)d, which would let them compute d=(s'-s)/(H(R',Q,m)-H(R,q,m)).
There is an easy solution against this, namely verifying the final signature
(R,s) in HW before sending it to SW, as almost certainly the result of such
a fault would not result in a valid signature. This comes at an extra
computational cost, though.
For other side-channel attacks like different power analysis, research [11]
shows that introducing fresh randomness in the right place may be helpful.
This approach is called "synthetic nonces" [12]. Unfortunately usage of these
rules out the deterministic approach from Scheme 6. A variant of Scheme 5
with fresh randomness in the k0 computation can be used, though.
3) Summary
----------
Six different issues of various levels of severity were discussed:
(a) Predictable k: (MHW) a single signature leaks the entire private key.
(b) Replay attacks: (MSW) a single signature leaks the entire private key.
(c) k0 grinding: (MHW) the HW can leak n bits with 2^n work.
(d) Statefulness: HW has to correctly maintain state, complicating things.
(e) Failure bias: (MHW) a selective failure rate of (2^n-1)/2^n can be used
to leak n bits of secret per signature.
(f) Side-channel attacks: (MSW) physical access to HW can help extracting
secrets.
It seems any reasonable solution should at least protect against (a), (b), and
(c), but it seems no solution can be optimal for all of (d), (e), and (f) too.
If statelessness and protection against failure bias are prioritized, Scheme 6
seems best. Its additive tweaking can be replaced with S2C (or multiplicative)
tweaking too. S2C in particular may be desirable to unify with support for
S2C-based timestamping.
If resistance against side-channels is prioritized, solutions with synthetic
nonces seem best; either Scheme 4, or Scheme 5 with randomness added to the
k0 computation. Again, any tweaking approach can be chosen.
If the 2-round approaches for Schemes 4, 5, and 6 are really unacceptable,
Scheme 2 (with S2C tweaking) could be used, but in that case protection
against k0 grinding is reduced to spot checking. If randomness is additionally
added for side-channel resistance, the ability to spot check disappears
entirely.
4) References
-------------
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017649.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017655.html
[3] https://blog.eternitywall.com/2018/04/13/sign-to-contract/
[4] https://bitcointalk.org/index.php?topic=893898.msg9861102#msg9861102
[5] https://bitcointalk.org/index.php?topic=893898.msg9841502#msg9841502
[6] https://medium.com/cryptoadvance/hardware-wallets-can-be-hacked-but-this-is-fine-a6156bbd199
[7] https://youtu.be/j9Wvz7zI_Ac?t=640
[8] https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2019-02-04-threshold-signatures-and-accountability/
[9] https://github.com/bitcoin-core/secp256k1/pull/590
[10] https://github.com/bitcoin-core/secp256k1/pull/669
[11] https://eprint.iacr.org/2017/985
[12] https://moderncrypto.org/mail-archive/curves/2017/000925.html

2023-06-07 20:20:23 CEST

- 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 20:18:23 CEST

- 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 20:17:59 CEST

- reply

📅 Original date posted:2019-05-08
📝 Original message:Thanks for the comments so far!
I'm going to respond to some of the comments here. Things which I plan
to address with changes in the BIP I'll leave for later.
On Mon, 6 May 2019 at 13:17, Luke Dashjr <luke at dashjr.org> wrote:
> Tagged hashes put the tagging at the start of the hash input. This means
> implementations can pre-cache SHA2 states, but it also means they can't reuse
> states to produce data for different contexts. (I'm not sure if there is a
> use for doing so... but maybe as part of further hiding MAST branches?)
It's true you can't cache/precompute things across tags, but I also
think there is no need. The type of data hashed in a sighash vs a
merkle branch/leaf vs a tweak is fundamentally different. I think this
is perhaps a good guidance to include about when separate tags are
warranted vs. simply making sure the input does not collide: there
shouldn't be much or any shared data with things that are expected to
be inputs under other tags.
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) *cannot* agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
Yes, absolutely - you can use a point with unknown discrete logarithm
as internal key. This will result in only script path spends being
available. For the specific goal you're stating an alternative may be
using a valid known private key, using it to pre-sign a timelocked
transaction, and destroying the key.
> It may be useful to have a way to add a salt to tap branches.
If you don't reuse public keys, effectively every branch is
automatically salted (and the position in the tree gets randomized
automatically when doing so, providing a small additional privacy
benefit).
>> Some way to sign an additional script (not committed to by the witness
>> program) seems like it could be a trivial addition.
> This would be especially useful for things like OP_CHECKBLOCKATHEIGHT:
> https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki
If you're talking about the ability to sign over the ability to spend
to another script ("delegation"), there are lots of interesting
applications and ways to implement it. But it overlaps with Graftroot,
and doing it efficiently in general has some interesting and
non-obvious engineering challenges (for example, signing over to a
script that enforces "f(tx)=y" for some f can be done by only storing
f and then including y in the sighash).
For the specific example of BIP115's functionality, that seems like a
reasonable thing that could be dealt with using the annex construction
in the proposed BIP. A consensus rule could define a region inside the
annex that functions as a height-blockhash assertion. The annex is
included in all sighashes, so it can't be removed from the input;
later opcodes could include the ability to inspect that assertion
even.
On Tue, 7 May 2019 at 13:43, Sjors Provoost <sjors at sprovoost.nl> wrote:
> One reason why someone would want to avoid a "everone agrees" branch, is duress (or self-discipline, or limiting powers of a trustee). In particular with respect to time-locks.>
Indeed, though as I suggested above, you can also use timelocked
transactions (but using only CLTV branches is more flexible
certainly).
> Can this "unknown discrete logarithm" be made provably unknown, so all signers are assured of this property? Bonus points if the outside world can't tell. The exact mechanism could be outside the scope of the BIP, but knowing that it's possible is useful.
Yes, that's a TODO that's left in the draft, but this is absolutely
possible (using a hash-to-curve operation). As ZmnSCPxj already
suggested, there can even be a fixed known constant you can use for
this. However, you get better privacy by taking this fixed known
constant (call it C) and using as internal key a blinded version of it
(C+rG, for some random value r, and G the normal secp256k1 generator);
as long as the DL between G and C is unknown, this is safe (and does
not reveal to the world that in fact no key-path was permitted when
spending).
> Regarding usage of Schnorr: do I understand correctly that the "everyone agrees" internal key MUST use Schnorr, and that individual branches MAY use Schnorr, but only if they're marked as tapscript spend?
>
> Why is tapscript not mandatory?
Spending using the internal key always uses a single Schnorr signature
and nothing else. When you spend using a script path, you must reveal
both the script and its leaf version. If that leaf version is 0xc0,
the script is interpreted as a tapscript (in which only Schnorr
opcodes exist). If that leaf version is not 0xc0, the script is
undefined, and is unconditionally valid. This is one of the included
extension mechanisms, allowing replacing the whole script language
with something else, but without revealing it unless a branch using it
is actually used (different Merkle tree leaves can have a distinct
leaf versions).
So the reason that tapscript is not mandatory is because other leaf
versions are undefined, and left for future extensions (similar to how
future segwit versions at the output level are undefined).
Cheers,
--
Pieter

2023-06-07 20:17:57 CEST

- reply

📅 Original date posted:2019-05-06
📝 Original message:Hello everyone,
Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:
* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable wallet software to use key
aggregation/thresholds within one input.
* Improvements to the signature hashing algorithm (including signing
all input amounts).
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
batch validation.
* Tagged hashing for domain separation (avoiding issues like
CVE-2012-2459 in Merkle trees).
* Extensibility through leaf versions, OP_SUCCESS opcodes, and
upgradable pubkey types.
The BIP drafts can be found here:
* https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
specifies the transaction input spending rules.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
specifies the changes to Script inside such spends.
* https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
is the Schnorr signature proposal that was discussed earlier on this
list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html)
An initial reference implementation of the consensus changes, plus
preliminary construction/signing tests in the Python framework can be
found on https://github.com/sipa/bitcoin/commits/taproot. All
together, excluding the Schnorr signature module in libsecp256k1, the
consensus changes are around 520 LoC.
While many other ideas exist, not everything is incorporated. This
includes several ideas that can be implemented separately without loss
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
which we're working on as an independent proposal.
The document explains basic wallet operations, such as constructing
outputs and signing. However, a wide variety of more complex
constructions exist. Standardizing these is useful, but out of scope
for now. It is likely also desirable to define extensions to PSBT
(BIP174) for interacting with Taproot. That too is not included here.
Cheers,
--
Pieter

2023-06-07 20:15:15 CEST

- reply

📅 Original date posted:2018-11-19
📝 Original message:Hello everyone,
For future segwit versions, I think it would be good add a few things
to the sighash by default that were overlooked in BIP143:
* Committing to the absolute transaction fee (in addition to just the
amount being spent in each input) would categorically remove concerns
about wallets lying about fees to HW devices or airgapped signers.
* Committing to the scriptPubKey (in addition to the scriptCode) would
prevent lying to devices about the type of output being spent, even
when the scriptCode is correct. As a reminder, the scriptCode is the
actually executed script (which is the redeemscript in non-segwit
P2SH, and the witnesscript in P2WSH/P2WPKH).
As this implies additional information that may not be desirable to
commit to in all circumstances, it makes sense to make these optional.
This obviously interacts with SIGHASH_NOINPUT, which really adds two
different ways of rebinding signatures to inputs:
* Changing the prevout (so that the txid doesn't need to be known when
the signature is created)
* Changing the script (so that the exact scriptPubKey/redeemScript/...
doesn't need to be known when the signature is created)
Of course, the second implies the first, but do all use cases require
both being able to change the prevout and (arbitrarily) changing the
scriptPubKey? While BIP118 correctly points out this is secure if the
same keys are only used in scripts with which binding is to be
permitted, I feel it would be preferable if signatures/scripts would
explicitly state what can change. One way to accomplish this is by
indicating exactly what in a script is subject to change.
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).
So my question is whether anyone can see ways in which this introduces
redundant flexibility, or misses obvious use cases?
Cheers,
--
Pieter

2023-06-07 20:13:41 CEST

- reply

📅 Original date posted:2018-07-09
📝 Original message:On Sun, Jul 8, 2018, 21:29 Erik Aronesty <erik at q32.com> wrote:
> Because it's non-interactive, this construction can produce multisig
> signatures offline. Each device produces a signature using it's own
> k-share and x-share. It's only necessary to interpolate M of n shares.
>
> There are no round trips.
>
> The security is Shamir + discrete log.
>
> it's just something I've been tinkering with and I can't see an obvious
> problem.
>
> It's basically the same as schnorr, but you use a threshold hash to fix
> the need to be online.
>
> Just seems more useful to me.
>
That sounds very useful if true, but I don't think we should include novel
cryptography in Bitcoin based on your not seeing an obvious problem with it.
I'm looking forward to seeing a more complete writeup though.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/3551e8cf/attachment.html>

2023-06-07 20:13:41 CEST

- reply

📅 Original date posted:2018-07-08
📝 Original message:On Sun, Jul 8, 2018, 07:26 Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> To save space, start with the wiki terminology on schnorr sigs.
>
> Consider changing the "e" term in the schnorr algorithm to hash of message
> (elligator style) to the power of r, rather than using concatenation.
>
This is a very vague description. Is there some paper you can reference, or
a more detailed explanation of the algorithm?
This would allow m of n devices to sign a transaction without any of them
> knowing a private key at all.
>
IE: each device can roll a random number as a share and the interpolation
> of that is the private key.
>
> The public shares can be broadcast and combines. And signature shares can
> be broadcast and combined.
>
> The net result of this is it really possible for an arbitrary set of
> devices to create a perfectly secure public-private key pair set.
>
At no point was the private key anywhere.
>
All of this sounds like a threshold signature scheme, which as Tim pointed
out is already possible with Schnorr.
What are the advantages of what you're describing?
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/396b25b7/attachment.html>

2023-06-07 20:13:40 CEST

- reply

📅 Original date posted:2018-07-08
📝 Original message:On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Pretty sure these non interactive sigs are more secure.
>
Schnorr signatures are provably secure in the random oracle model assuming
the discrete logarithm problem is hard in the used group.
What does "more secure" mean? Is your construction secure with weaker
assumptions?
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180708/4f9bcb27/attachment.html>

2023-06-07 20:13:39 CEST

- reply

📅 Original date posted:2018-07-14
📝 Original message:On Sat, Jul 14, 2018 at 8:42 AM, Sjors Provoost <sjors at sprovoost.nl> wrote:
> Questions:
>
> Regarding verification: why does bytes(P) use compressed key serialization rather than the implicit Y coordinate used for signing? I understand space savings don't matter since these values don't end up on the blockchain. Is it just easier to implement or is it faster?
Following the design decision to use key-prefixed Schnorr, the
signature must commit to the entire public key, including its Y
coordinate.
It would be possible to only permit public keys whose Y coordinates
are even, or quadratic residues (like the signature internally uses
for the R point), but that would mean changing what public keys are
acceptable. Not doing so has significant practical advantages, like
not breaking existing key generation mechanisms (like BIP32 and
derivatives).
So if we're going to serialize the public key into the hash, in full,
the easiest choice seems to be to use the encoding everyone already
uses for public keys.
> Regarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) "avoids the difficulty of encoding a point R in the signature". But since e = H(sG - eP || m) also involves converting a point to some byte encoding in order to hash it, how much difficulty is actually avoided? Is that, like for previous question, because you could get away with compressed keys rather than implicit Y coordinates?
This is mostly a historical argument. When Schnorr is applied to an
integer multiplication group rather than an elliptic curve group,
serializing a group element is many times larger than serializing a
hash. For elliptic curve based Schnorr, there is hardly any benefit
for choosing the (e,s) form over (R,s).
> Regarding batch verification: "randomly generated independently for each batch of verifications" - by whom? I assume randomly picked by the verifier?
Randomly picked by the verifier, yes. The randomization factors are
there so that an attacker cannot choose signatures which cancel out
other invalid signatures within the same batch.
> Regarding random number used for signing. The suggested (?) deterministic algorithm to derive secret key ''k'' from the private key ''d'' seems similar to RFC6979. Maybe it's useful to briefly explain the difference, as well as your rationale for not making it mandatory (presumably the same as why RFC6979 isn't mandatory although most (?) wallets use it).
What would "mandatory" mean? To follow the BIP, signers must sign
using nonces generated deterministically following the provided
method. That's as far as mandatory can go.
However, it is not possible to enforce (by a verifier) than nonces
were generated in a specific way. To do so, the verifier would need to
know the nonce, which implies learning the private key. So the nonce
choosing algorithm cannot be enforced by the verifier. This implies
that it is possible to generate valid (and secure) nonces in a way
that does not follow the BIP.
> * Motivation: "signatures ... These are standardized", but the "standardized" link points to the secp256k1 curve parameters, not to anything signature related afaik
There are two documents on the site linked to. One describes the ECDSA
signing algorithm and serializations, the other specifies the curve
parameter. I could link to both.
> * "message m: an array of 32 bytes", maybe add "typically the sha256 hash of the transaction components commited to by SIGHASH_TYPE”
Ok.
> * I left a few even smaller nits as a PR: https://github.com/sipa/bips/pull/10
Thanks for your comments, will review.
Cheers,
--
Pieter

2023-06-07 20:13:06 CEST

- 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 20:13:04 CEST

- 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 20:13:02 CEST

- 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 20:12:50 CEST

- reply

📅 Original date posted:2018-06-11
📝 Original message:On Mon, Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for the comments Pieter!
>
> We can make descriptions for the intended node behaviors more clear in the
> BIP.
>
> Regarding interaction with BIPs 37 and 133, we have found that if
> Dandelion routing decisions are based on self-reported features, malicious
> nodes can often exploit that to launch serious deanonymization attacks. As
> a result, we recommend not allowing fee filters from peers to influence the
> choice of route. Your suggestion of automatically fluffing is a good
> solution. Another (similar) option would be to apply fee filters in the
> stempool. This would prevent the tx from propagating in stem phase, so
> eventually an embargo timer on the stem will expire and the transaction
> will fluff. This is slower than auto-fluffing, but requires (slightly) less
> code.
>
I understand the argument about not making routing decisions based on
self-reported features, but I would expect it to only matter if done
selectively? Allowing a node to opt out of Dandelion entirely should always
be possible regardless - as they can always indicate not supporting it.
The reason for my suggestion was that most full nodes on the network use
feefilter, while only (from the perspective of Dandelion uninteresting)
light nodes and blocksonly nodes generally use Bloom filters.
Just dropping stem transactions that would otherwise be sent to a Dandelion
peer which fails its filter, and relying on embargo seems fine. But perhaps
this option is something to describe in the BIP ("Nodes MAY choose to
either drop stem transactions or immediately start diffusion when a
transaction would otherwise be sent to a Dandelion node whose filter is not
satisfied for that transaction. A node SHOULD NOT make any routing
decisions based on the transaction itself, and thus SHOULD NOT try to find
an alternative Dandelion node to forward to" for example).
Regarding mempool-dependent transactions, the reference implementation adds
> any mempool transactions to the stempool but not vice-versa so that the
> stempool becomes a superset of the mempool. In other words, information is
> free to flow from the mempool to the stempool. Information does not flow
> from the stempool to the mempool except when a transaction fluffs. As a
> result, a node's stempool should accept and propagate Dandelion
> transactions that depend on other unconfirmed normal mempool transactions.
> The behavior you described is not intended; if you have any tests
> demonstrating this behavior, would you mind sharing them?
>
Oh, I see! I was just judging based on the spec code you published, but I
must have missed this. Yes, that makes perfect sense. There may be some
issues with this having a significant impact on stempool memory usage, but
let's discuss this later on implementation.
Orphans: stem orphans can occur when a node on the stem shuffles its route
> between sending dependent transactions. One way to deal with this issue
> would be to re-broadcast all previous Dandelion transactions that have not
> been fluffed after Dandelion route shuffling. This could add a fair amount
> of data and logic. This re-broadcast method also telegraphs the fact that a
> Dandelion shuffle has taken place and can result in bursts of transactions
> depending on traffic patterns. A second option (which we used in the
> reference implementation) is to wait for the fluff phase to begin, at which
> point the orphans will be resolved. This should happen within 15 seconds
> for most transactions. Do you have any thoughts on which option would be
> more palatable? Or if there are other options we have missed?
>
Another option (just brainstorming, I may be missing something here), is to
remember which peer each stempool transaction was forwarded to. When a
dependent stem transaction arrives, it is always sent to (one of?) the
peers its dependencies were sent to, even if a reshuffle happened in
between.
Thinking more about it, relying on embargo is probably fine - it'll just
result in slightly lowered average stem length, and perhaps multiple
simultaneous fluffs starting?
Regarding preferred connections, we have found that making Dandelion
> routing decisions based on claims made by peer nodes can cause problems and
> therefore would recommend against biasing the peer selection code.
>
Oh, I don't mean routing decisions, but connections in general.
On the implementation side:
>
Let's discuss these later.
> Based on the feedback we have received so far, we are planning to
> prioritize writing up a clearer spec for node behavior in the BIP. Does
> that seem reasonable, or are there other issues that are more pressing at
> this point?
>
I think that's the primary thing to focus on at this point, but perhaps
others on this list feel different.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180611/308dd73e/attachment-0001.html>

2023-06-07 20:12:39 CEST

- 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 20:12:34 CEST

- reply

📅 Original date posted:2018-05-31
📝 Original message:On Fri, May 25, 2018 at 3:14 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> A graftroot design like this is a strict subset of existing signature checking rules. If this is dangerous, the existing signature checking rules must be dangerous.
While you may be right in this situation, I'm not sure that conclusion
follows from your argument. Whether or not a construction is safe does
not just depend on the consensus rules, but also on how it is used.
Otherwise you could as well argue that since OP_TRUE is possible right
now which is obviously insecure, nothing more dangerous can be
accomplished through any soft fork.
The best argument for why Graftroot does not need to be optional I
think was how Greg put it: "since the signer(s) could have signed an
arbitrary transaction instead, being able to delegate is strictly less
powerful.".
Cheers,
--
Pieter

2023-06-07 20:12:29 CEST

- 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 20:05:40 CEST

- reply

📅 Original date posted:2017-09-22
📝 Original message:On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the variable size increase is only a few bytes, then three
> possibilities arise:
>
> - one should allow signatures to be zero padded (to reach the maximum
> size) and abandon strict DER encoding
>
> - one should allow spare witness stack elements (to pad the size to match
> the maximum size) and remove the cleanstack rule. But this is tricky
> because empty stack elements must be counted as 1 byte.
>
> - signers must loop the generation of signatures until the signature
> generated is of its maximum size.
>
Or (my preference);
- Get rid of DER encoding alltogether and switch to fixed size signatures.
Cheers,
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/5cb68030/attachment.html>

2023-06-07 20:04:13 CEST

- 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 20:04:12 CEST

- 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 19:58:13 CEST

- 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 19:56:47 CEST

- 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 19:56:46 CEST

- 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 19:54:54 CEST

- 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 19:54:00 CEST

- reply

📅 Original date posted:2016-10-16
📝 Original message:Hello all,
We're getting ready for Bitcoin Core's 0.13.1 release - the first one
to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin
mainnet, after being extensively tested on testnet and in other
software. Following the BIP9 recommendation [1] to set the versionbits
start time a month in the future and discussion in the last IRC
meeting [2], I propose we set BIP 141's start time to November 15,
2016, 0:00 UTC (unix time 1479168000).
Note that this is just a lower bound on the time when the versionbits
signalling can begin. Activation on the network requires:
(1) This date to pass
(2) A full retarget window of 2016 blocks with 95% signalling the
version bit (bit 1 for BIP141)
(3) A fallow period consisting of another 2016 blocks.
[1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
[2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html
Cheers,
--
Pieter

2023-06-07 19:51:23 CEST

- 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 19:51:22 CEST

- 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 19:50:20 CEST

- 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 19:47:42 CEST

- 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 19:47:41 CEST

- 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 19:46:45 CEST

- 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 19:46:20 CEST

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
>
> This circles back to Problem #1: Avoidance of a choice is a still a choice
> - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Economic
> Change Event risk.
We are not avoiding a choice. We don't have the authority to make a choice.
> And #3: If the likely predicted course is that Bitcoin Core will not accept
> a protocol change changing MAX_BLOCK_SIZE via hard fork in the short term,
> the core dev team should communicate that position clearly to users and
> media.
I indeed think we can communicate much better that deciding consensus
rules is not within our power.
--
Pieter

2023-06-07 19:46:19 CEST

- reply

📅 Original date posted:2015-12-16
📝 Original message:On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 2) If block size stays at 1M, the Bitcoin Core developer team should sign a
> collective note stating their desire to transition to a new economic policy,
> that of "healthy fee market" and strongly urge users to examine their fee
> policies, wallet software, transaction volumes and other possible User
> impacting outcomes.
You present this as if the Bitcoin Core development team is in charge
of deciding the network consensus rules, and is responsible for making
changes to it in order to satisfy economic demand. If that is the
case, Bitcoin has failed, in my opinion.
What the Bitcoin Core team should do, in my opinion, is merge any
consensus change that is uncontroversial. We can certainly -
individually or not - propose solutions, and express opinions, but as
far as maintainers of the software goes our responsibility is keeping
the system running, and risking either a fork or establishing
ourselves as the de-facto central bank that can make any change to the
system would greatly undermine the system's value.
Hard forking changes require that ultimately every participant in the
system adopts the new rules. I find it immoral and dangerous to merge
such a change without extremely widespread agreement. I am personally
fine with a short-term small block size bump to kick the can down the
road if that is what the ecosystem desires, but I can only agree with
merging it in Core if I'm convinced that there is no strong opposition
to it from others.
Soft forks on the other hand only require a majority of miners to
accept them, and everyone else can upgrade at their leisure or not at
all. Yes, old full nodes after a soft fork are not able to fully
validate the rules new miners enforce anymore, but they do still
verify the rules that their operators opted to enforce. Furthermore,
they can't be prevented. For that reason, I've proposed, and am
working hard, on an approach that includes Segregated Witness as a
first step. It shows the ecosystem that something is being done, it
kicks the can down the road, it solves/issues half a dozen other
issues at the same time, and it does not require the degree of
certainty needed for a hardfork.
--
Pieter

2023-06-07 19:46:08 CEST

- 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 19:33:59 CEST

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Aug 11, 2015 12:52 AM, "Pieter Wuille" <pieter.wuille at gmail.com> wrote:
>
>
> On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Have you ever been to a concert that was far away from public
transport? They
> > typically set up bus shuttles, or taxis to get people back into town
> > afterwards.
> > The result there is always you end up waiting forever and it actually
may be
> > easier to just walk instead of wait.
> > The amount you pay is irrelevant if everyone is paying it. There still
is more
> > demand than there is capacity.
>
> That's an incorrect analogy. You choose the rate you pay, and get higher
priority when you pay more. Taxi drivers can't pick out higher-paying
customers in advance.
I'm sorry, I missed your "if everyone is paying it". This changes a lot. I
agree with you: if everyone wants to pay much then it becomes unreliable.
But I don't think that is something we can avoid with a small constant
factor block size increase, and we don't do the world a service by making
it look like it works for longer.
Let's grow within bounderies set by technology and centralization pressure
that we can agree on. Let the market decide whether how they will that will
low volume reliable transactions and/or high volume unreliable ones.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/59b198e8/attachment.html>

2023-06-07 19:33:59 CEST

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Have you ever been to a concert that was far away from public transport?
They
> typically set up bus shuttles, or taxis to get people back into town
> afterwards.
> The result there is always you end up waiting forever and it actually may
be
> easier to just walk instead of wait.
> The amount you pay is irrelevant if everyone is paying it. There still is
more
> demand than there is capacity.
That's an incorrect analogy. You choose the rate you pay, and get higher
priority when you pay more. Taxi drivers can't pick out higher-paying
customers in advance.
A better comparison is Uber, which charges more in places with high demand,
and you can accept or refuse in advance. And yes, it remains reliable if
you're among those with the highest willingness to pay.
> So, no, its not unreliable for cheap free transactions.
> Its unreliable for all types of transactions.
If 2500 transactions fit in the block chain per day (assuming constant
size) and there are less than 2500 per hour that pay at least 0.001 BTC in
fee, then any transaction which pays more than 0.001 BTC will have a very
high chance of getting in a small multiple of one hour, since miners
prioritize by feerate.
If there are in addition to that 5000 transactions per hour which pay less,
then yes, they need to compete for the remaiming space and their
confirmation will be unreliable.
The whole point is that whether confirmation at a particular price point is
reliable depends on how much demand there is at that price point. And
increasing the block size out of fear of what might happen is failing to
recognize that it can always happen that there is a sudden change in demand
that outcompetes the rest.
The point is not that evolution towards a specific higher feerate needs to
happen, but an evolution to an ecosystem that accepts that there is never a
guarantee for reliability, unless you're willing to pay more than everyone
else - whatever that number is.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/b117bc74/attachment-0001.html>

2023-06-07 19:33:51 CEST

- 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 19:33:47 CEST

- 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 19:33:45 CEST

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

2023-06-07 19:33:32 CEST

- 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 19:33:31 CEST

- 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 19:33:25 CEST

- 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 19:33:24 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> You make a logical fallacy;
>
> I would agree that nodes are there for people to stop trusting someone that
> they have no trust-relationship with.
>
Yay, trust!
> But your conclusion that low node count is an indication that its hard to
> run
> one discards your own point. You forget the point that running a node is
> only
> needed if you don't know anyone you can trust to run it for you. I'm
> pretty
> darn sure that this will have a bigger effect on nodecount than how hard it
> is.
>
I never said it is the only factor that influences node count.
Or, in other words, without a need to run a node you can't judge the
> difficulty of why there aren't more running.
>
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.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/76c1ddc9/attachment.html>

2023-06-07 19:33:24 CEST

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

2023-06-07 19:33:23 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 5:06 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Thu, Aug 6, 2015 at 10:53 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> 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?
>
>
> Yes, that's fine. If the network cannot handle the transaction volume that
> people want to pay for, then the marginal transactions are priced out. That
> is true today (otherwise ChangeTip would be operating on-blockchain), and
> will be true forever.
>
The network can "handle" any size. I believe that if a majority of miners
forms SPV mining agreements, then they are no longer affected by the block
size, and benefit from making their blocks slow to validate for others (as
long as the fee is negligable compared to the subsidy). I'll try to find
the time to implement that in my simulator. Some hardware for full nodes
will always be able to validate and index the chain, so nobody needs to run
a pesky full node anymore and they can just use a web API to validate
payments.
Being able the "handle" a particular rate is not a boolean question. It's a
question of how much security, centralization, and risk for systemic error
we're willing to tolerate. These are not things you can just observe, so
let's keep talking about the risks, and find a solution that we agree on.
>
>> 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.
>
>
> "better is better" -- I applaud efforts to fundamentally improve the
> scalability of the system, but I am an old, cranky, pragmatic engineer who
> has seen that successful companies tackle problems that arise and are
> willing to deploy not-so-perfect solutions if they help whatever short-term
> problem they're facing.
>
I don't believe there is a short-term problem. If there is one now, there
will be one too at 8 MB blocks (or whatever actual size blocks are
produced).
>
>
>> 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.
>
>
> I think consensus is against you on that point.
>
Maybe. But I believe that it is essential to not take unnecessary risks,
and find a non-controversial solution.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/895a1775/attachment.html>

2023-06-07 19:32:36 CEST

- 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 19:32:33 CEST

- 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 19:32:33 CEST

- 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 19:32:27 CEST

- 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 19:32:23 CEST

- 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 19:31:33 CEST

- reply

2023-06-07 17:46:03 CEST

- reply

2023-06-07 17:46:03 CEST

- reply

2023-06-07 17:46:01 CEST

- 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:45:57 CEST

- reply

2023-06-07 17:45:53 CEST

- reply

2023-06-07 17:45:52 CEST

- reply

2023-06-07 17:45:40 CEST

- reply

2023-06-07 17:45:39 CEST

- reply

2023-06-07 17:45:33 CEST

- reply

2023-06-07 17:45:33 CEST

- reply

2023-06-07 17:45:32 CEST

- reply

2023-06-07 17:45:31 CEST

- reply

2023-06-07 17:44:54 CEST

- reply

2023-06-07 17:44:52 CEST

- reply

2023-06-07 17:44:52 CEST

- reply

2023-06-07 17:44:47 CEST

- reply

2023-06-07 17:44:14 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:Hello all,
here is a proposal for long-term scalability I've been working on:
https://gist.github.com/sipa/c65665fc360ca7a176a6
Some things are not included yet, such as a testnet whose size runs ahead
of the main chain, and the inclusion of Gavin's more accurate sigop
checking after the hard fork.
Comments?
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/99e5886b/attachment.html>

2023-06-07 17:43:48 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> Let's scale the block size gradually over time, according to
>> technological growth.
>
>
> Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
>
Oh come on. Immediately increasing to 8 MB while miners currently don't
even seem to bother validating blocks?
With the added belt&suspenders reality check of miners, who won't produce
> blocks too big for whatever technology they're using.
>
Or a future where miners are even more centralized than now, which avoids
all problems relay and propagation speed has?
> So what do you think the scalability road map should look like? Should we
> wait to hard fork until Blockstream Elements is ready for deploying on the
> main network, and then have One Grand Hardfork that introduces all the
> scalability work you guys have been working on (like Segregated Witness and
> Lightning)?
>
Lightning does not require a hard fork, except that larger blocks would be
very useful for its bulk settlements.
Or is the plan to avoid controversy by people voluntarily moving their
> bitcoin to a sidechain where all this scaling-up innovation happens?
>
As I have said a dozen times now: sidechains are a mechanism for
experimentation. Maybe through them we will discover technology that allows
better on-chain and/or off-chain scalability, but people moving their coins
to a sidechain has far worse security tradeoffs than just increasing the
Bitcoin blockchain.
No plan for how to scale up is the worst of all possible worlds, and the
> lack of a direction or plan(s) is my main objection to the current status
> quo.
>
Ok, here is a proposal I was working on. I'd like to have had more time,
but I agree a direction/plan are needed to align expectations for the
future: https://gist.github.com/sipa/c65665fc360ca7a176a6.
> And any plan that requires inventing brand-new technology is going to be
> riskier than scaling up what we already have and understand, which is why I
> think it is worthwhile to scale up what we have IN ADDITION TO working on
> great projects like Segregated Witness and Lightning.
>
And I think that the reason that so many people care about this suddenly is
because of a fear that somehow the current block size "won't be enough".
Bitcoin has utility at any block size, and perhaps more at some values for
it than others. Talking about "not enough" is acknowledging that we really
believe the block size should scale to demand, while it is the other way
around.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/db66bf01/attachment.html>

2023-06-07 17:43:48 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think that given
> what we now today about the Bitcoin network, increasing block size
> externalizes costs in dangerous ways. Remember that total cost includes not
> just equipment costs but also things like block propagation latency and
> specifically identified security risks. Some of these security risks were
> only appreciated relatively recently and were completely unknown in 2009.
>
> I would like (and have been asking) those people to take the time to
> quantify those costs and write up those risks in a careful way.
>
> I believe the costs and risks of 8MB blocks are minimal, and that the
> benefits of supporting more transaction FAR outweigh those costs and risks,
> but it is hard to have a rational conversation about that when even simple
> questions like 'what is s reasonable cost to run a full node' are met with
> silence.
>
I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
(even assuming miners actually produce 8 MB blocks). There are very few use
cases that Bitcoin on-chain can support with a small extra factor. I think
the market will grow to adapt to whatever is offered anyway.
Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.
Wanting to increase the scale of the system is in conflict with all of
those. Attempting to buy time with a fast increase is not wanting to face
that reality, and treating the system as something whose scale trumps all
other concerns. A long term scalability plan should aim on decreasing the
need for trust required in off-chain systems, rather than increasing the
need for trust in Bitcoin.
Making controversial changes to the network, and not wanting to face the
reality that block chain space is a finite resource - whether enforced by a
consensus rule or by miner's capacity to process transactions - is a huge
treat to Bitcoin's usefulness in the long term.
I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".
Let's scale the block size gradually over time, according to technological
growth.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/fcd26023/attachment.html>

2023-06-07 17:43:39 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I'd like to disclose a vulnerability I discovered in September 2014,
which became unexploitable when BIP66's 95% threshold was reached
earlier this month.
## Short description:
A specially-crafted transaction could have forked the blockchain
between nodes:
* using OpenSSL on a 32-bit systems and on 64-bit Windows systems
* using OpenSSL on non-Windows 64-bit systems (Linux, OSX, ...)
* using some non-OpenSSL codebases for parsing signatures
## Upgrade instructions:
None. Transactions that could trigger this problem have become invalid
on the network since BIP66's deployment of version 3 blocks reached 95%
on July 4th, 2015.
## Long description:
The problem is related to the signature encoding rules.
Bitcoin's signatures are ASN.1 BER encoded. BER is a complex standard
that allows many different encodings for the same data. Since Bitcoin
Core 0.8, a standardness rule has been in effect that only allowed
subset of encodings (DER) for relay and mining, even though any BER
remained valid in the blockchain - at least in theory.
In practice, BER has many weird edge cases, and I have not found a
single cryptographic codebase that can parse all of them correctly.
This includes OpenSSL, Crypto++, BouncyCastle, btcec, and our own
libsecp256k1 library.
This on itself would not be a problem, as full nodes on the network
currently use OpenSSL. However, while researching what was needed to
make libsecp256k1 compatible with it, I discovered that OpenSSL is even
inconsistent with itself across different platforms.
One of the features of BER is the ability for internal structures to
have a length descriptor whose size itself is up to 126 bytes (see
X.690-0207 8.1.3.5). A 1 terabyte data structure would for example use
a 5-byte length descriptor. However, there is no requirement to use the
shortest possible descriptor, so even a 70-byte ECDSA signature could
use a 5-byte length descriptor and be valid. Unfortunately, OpenSSL
supports length descriptors only as long as their size is at most that
of a C 'long int', a type whose size depends on the platform (Windows
and 32-bit Linux/OSX have a 4-byte long int, 64-bit Linux/OSX have an
8-byte long int). See
https://github.com/openssl/openssl/blob/bfa34f551c2d38e826deb44a269cb0f720f9f63b/crypto/asn1/asn1_lib.c#L178.
Some non-OpenSSL based signature validation
systems don't support such length descriptors at all, resulting in an
extra forking risk on top for them if used for blockchain validation.
This effectively means that a block chain containing a transaction with
a valid signature using such a 5-byte length descriptor would be
accepted by some systems and not by others, resulting in a fork if it
were mined into a block.
## Timeline:
* 2013-Feb-19: Bitcoin Core 0.8.0 was released, which made non-DER
signatures non-standard. No release since then would relay or mine
transactions that could trigger the vulnerability. However, such a
transaction was still valid inside blocks.
* 2014-Feb-10: I proposed BIP62 to deal with transaction malleability.
The BIP62 draft includes a rule that would make version 2 transactions
with non-DER signatures invalid.
* 2014-Jul-18: In order to make Bitcoin's signature encoding rules not
depend on OpenSSL's specific parser, I modified the BIP62 proposal to
have its strict DER signatures requirement also apply to version 1
transactions. No non-DER signatures were being mined into blocks
anymore at the time, so this was assumed to not have any impact. See
https://github.com/bitcoin/bips/pull/90 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-July/006299.html.
Unknown at the time, but if deployed this would have solved the
vulnerability.
* 2014-Sep-01: While analysing OpenSSL's source code for BER parsing, I
discovered the architecture dependency listed above and the associated
vulnerability. The best means to fix it at the time was by getting
BIP62 adopted.
* 2014-Sep-07, 2014-Oct-17, 2014-Oct-26, 2014-Dec-06, 2015-Jan-09:
Several proposed changes to BIP62. See
https://github.com/bitcoin/bips/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+bip62.
* 2015-Jan-10: OpenSSL releases versions 1.0.0p and 1.0.1k, with a fix
for CVE-2014-8275. The fix introduced a restriction on ECDSA signatures
to be strict DER, which would have solved all problems related to
signature encodings, except Bitcoin's consensus-critical nature
requires bug-for-bug compatibility between nodes. Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks. The only immediate
solution that did not introduce more risk for forks was parsing and
re-encoding signatures using OpenSSL itself before verification to
bypass the restriction, making the problem persist. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html.
* 2015-Jan-21: The new attention to signature encoding might have
revealed the vulnerability, and the presence of miners not enforcing
strict DER might have made the vulnerability actually exploitable.
BIP62 was still a moving target, so we wanted a faster means to solve
this. Therefore, a new BIP was proposed with just the strict DER
requirement, numbered BIP66. This would both allow non-OpenSSL
verification, and solve the vulnerability, without needing to fix the
less urgent malleability problem that BIP62 wanted to address. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007156.html.
* 2015-Feb-17: Bitcoin Core 0.10.0 was released, with support for
BIP66. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html.
* 2015-Jul-04: BIP66's 95% threshold was reached, enabling a consensus
rule for strict DER signatures in the blockchain. This solved the
vulnerability, and opens the door to using non-OpenSSL signature
verification in the near future.
- --
Pieter Wuille
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBAgAGBQJVt5FGAAoJEFeJbS/48LZX3ccMAJdPrpa8ggcYEyy8naqc7ewL
1Mwv24p/6Q8+T7Q6EWmgoApY1jljF+AzgSpfaf310QZf9yuC/JC++AmHfUaa9UQG
Mq1+duX64uDWIeNKTfuCwZvU0ataARZKmFUpp60UF+VtiJyLo9tpHTVajM0lv9Oq
OX40qHVC/iBogRLNREC1ggWH1JPMTbEch50YX1bgNi3gE5gtMggSQ2OXrGCCtrvR
7cVFlIyOhlLtvSAnxzmHyY8Iol+qVhIZi4mCmDgOoQKVaiYm1cODQ+nrMHx02DKC
Wqstwb/mET/vbCX4qxSNQ2B+mQk0WO/gSrWiQkBLi/AfLBh/8A/kL1RpKxVQzoaP
O165LbXye42w8Js/sE/zT6d4CIbYaW0GpF6m4agwDYgPLomhdk/elPRojKYsEab+
oFWPVagqKI9e/pjFBxqfIv3iyx1hHB6YIaX5TfFRVjsWzag5Qi2ssQYOQymyjg4J
UHNR/xW0PMPAOg5KS/uFja4OWxstHhTW9G+rslEK9g==
=7F3K
-----END PGP SIGNATURE-----

2023-06-07 17:42:48 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:Hello all,
I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of Bitcoin
Core to create software which helps guarantee the security and operation of
the Bitcoin network.
In addition to normal software maintenance, bug fixes and performance
improvements, this includes DoS protection mechanism deemed necessary to
keep the network operational. Sometimes, such (per-node configurable)
policies have had economic impact, for example the dust rule.
This also includes participating in discussions about consensus changes,
but not the responsibility to decide on them - only to implement them when
agreed upon. It would be irresponsible and dangerous to the network and
thus the users of the software to risk forks, or to take a leading role in
pushing dramatic changes. Bitcoin Core developers obviously have the
ability to make any changes to the codebase or its releases, but it is
still up to the community to choose to run that code.
Some people have called the prospect of limited block space and the
development of a fee market a change in policy compared to the past. I
respectfully disagree with that. Bitcoin Core is not running the Bitcoin
economy, and its developers have no authority to set its rules. Change in
economics is always happening, and should be expected. Worse, intervening
in consensus changes would make the ecosystem more dependent on the group
taking that decision, not less.
So to point out what I consider obvious: if Bitcoin requires central
control over its rules by a group of developers, it is completely
uninteresting to me. Consensus changes should be done using consensus, and
the default in case of controversy is no change.
===
My personal opinion is that we - as a community - should indeed let a fee
market develop, and rather sooner than later, and that "kicking the can
down the road" is an incredibly dangerous precedent: if we are willing to
go through the risk of a hard fork because of a fear of change of
economics, then I believe that community is not ready to deal with change
at all. And some change is inevitable, at any block size. Again, this does
not mean the block size needs to be fixed forever, but its intent should be
growing with the evolution of technology, not a panic reaction because a
fear of change.
But I am not in any position to force this view. I only hope that people
don't think a fear of economic change is reason to give up consensus.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/0a8c7519/attachment.html>

2023-06-07 17:42:21 CEST

- reply

📅 Original date posted:2015-07-15
📝 Original message:On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large
> number of standard nodes and actually make the network stronger? Personally
> I never bring claims like this if I just assume. A lot of people in the
> community really trust you, do you realize you potentially hurt them for no
> reason?
>
Running normal full nodes only provides extra service to nodes
synchronizing and lightweight clients. It does not "make the network
stronger" in the sense that it does not reduce the trust the participants
need to have in each other.
It's such a misconception that running many nodes somehow helps. It's much
better that you run and control one or a few full nodes which you actually
use to validate your transactions, than to run 1000s of nodes in third
party datacenters. The latter only looks more decentralized.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150715/1b2a1d26/attachment.html>

2023-06-07 17:40:29 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I am not saying that economic change is what we want. Only that it is
inevitable, independent of whether larger blocks happen or not.
I am saying that acting because of fear of economic change is a bad reason.
The reason for increase should be because of the higher utility. We need it
at some point, but there should be no rush.
I do understand that we want to avoid a *sudden* change in economic policy,
but I'm generally not too worried. Either fees increase and they get paid,
and we're good. But more likely is that some uses just move off-chain
because the block chain does not offer what they need. That's sad, but it
is inevitable at any size: some uses fit, some don't.
--
Pieter
On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
> It is not "fear" of fee pressure.
>
> 1) Blocks are mostly not-full on average.
>
> 2) Absent long blocks and stress tests, there is little fee pressure above
> the anti-spam relay fee metric, because of #1.
>
> 3) As such, inducing fee pressure is a delta, a change from years-long
> bitcoin economic policy. Each time we approach the soft limit, Bitcoin
> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
> lobbies miners to upgrade.
>
> (note - this is not an endorsement of these actions - it is a neutral
> observation)
>
> 4) Inaction leads to consistent fee pressure as the months tick on and
> system volume grows; thus, inaction leads to economic policy change.
>
> 5) Economic policy change leads to market and software disruption. The
> market and software - notably wallets - is not prepared for this.
>
> 6) If you want to change economic policy, that's fine. But be honest and
> admit you are arguing for a change, a delta from current market
> expectations and behavior.
>
> 7) It is critical to first deal with what _is_, not what you wish the
> world to be. You want a fee market to develop. There is nothing wrong
> with that desire. It remains a delta from where we are today, and that is
> critically relevant in a $3b+ market.
>
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> Hello all,
>>
>> here I'm going to try to address a part of the block size debate which
>> has been troubling me since the beginning: the reason why people seem to
>> want it.
>>
>> People say that larger blocks are necessary. In the long term, I agree -
>> in the sense that systems that do not evolve tend to be replaced by other
>> systems. This evolution can come in terms of layers on top of Bitcoin's
>> blockchain, in terms of the technology underlying various aspects of the
>> blockchain itself, and also in the scale that this technology supports.
>>
>> I do, however, fundamentally disagree that a fear for a change in
>> economics should be considered to necessitate larger blocks. If it is, and
>> there is consensus that we should adapt to it, then there is effectively no
>> limit going forward. This is similar to how Congress voting to increase the
>> copyright term retroactively from time to time is really no different from
>> having an infinite copyright term in the first place. This scares me.
>>
>> Here is how Gavin summarizes the future without increasing block sizes in
>> PR 6341:
>>
>> > 1. Transaction confirmation times for transactions with a given fee
>> will rise; very-low-fee transactions will fail to get confirmed at all.
>> > 2. Average transaction fee paid will rise
>> > 3. People or applications unwilling or unable to pay the rising fees
>> will stop submitting transactions
>> > 4. People and businesses will shelve plans to use Bitcoin, stunting
>> growth and adoption
>>
>> Is it fair to summarize this as "Some use cases won't fit any more,
>> people will decide to no longer use the blockchain for these purposes, and
>> the fees will adapt."?
>>
>> I think that is already happening, and will happen at any scale. I
>> believe demand for payments in general is nearly infinite, and only a small
>> portion of it will eventually fit on a block chain (independent of whether
>> its size is limited by consensus rules or economic or technological means).
>> Furthermore, systems that compete with Bitcoin in this space already offer
>> orders of magnitude more capacity than we can reasonably achieve with any
>> blockchain technology at this point.
>>
>> I don't know what subset of use cases Bitcoin will cater to in the long
>> term. They have already changed - you see way less betting transactions
>> these days than a few years ago for example - and they will keep changing,
>> independent of what effective block sizes we end up with. I don't think we
>> should be afraid of this change or try to stop it.
>>
>> If you look at graphs of block sizes over time (for example,
>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
>> little "organic" growth, and a lot of sudden changes (which could
>> correspond to changing defaults in miner software, introduction of popular
>> sites/services, changes in the economy). I think these can be seen as the
>> economy changing to full up the available space, and I believe these will
>> keep happening at any size effectively available.
>>
>> None of this is a reason why the size can't increase. However, in my
>> opinion, we should do it because we believe it increases utility and
>> understand the risks; not because we're afraid of what might happen if we
>> don't hurry up. And from that point of view, it seems silly to make a huge
>> increase at once...
>>
>> --
>> Pieter
>>
>>
>> _______________________________________________
>> 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/20150626/f54b9275/attachment.html>

2023-06-07 17:40:27 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:On Fri, Jun 26, 2015 at 5:22 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> >None of this is a reason why the size can't increase. However, in my
> opinion, we should do it because we believe it increases utility and
> understand the risks; not because we're afraid of what might happen if we
> don't hurry up. And from that point of view, it seems silly to make a huge
> increase at once...
>
> Yes. I think people/businesses want some kind of assurance that there is
> a path to get things done when needed rather than immediate changes. Since
> there is currently no clear path/schedule to get any changes accomplished
> they gets anxious.
>
I think you just proved my point by saying "when needed".
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/cc04ed8a/attachment.html>

2023-06-07 17:40:26 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:Hello all,
here I'm going to try to address a part of the block size debate which has
been troubling me since the beginning: the reason why people seem to want
it.
People say that larger blocks are necessary. In the long term, I agree - in
the sense that systems that do not evolve tend to be replaced by other
systems. This evolution can come in terms of layers on top of Bitcoin's
blockchain, in terms of the technology underlying various aspects of the
blockchain itself, and also in the scale that this technology supports.
I do, however, fundamentally disagree that a fear for a change in economics
should be considered to necessitate larger blocks. If it is, and there is
consensus that we should adapt to it, then there is effectively no limit
going forward. This is similar to how Congress voting to increase the
copyright term retroactively from time to time is really no different from
having an infinite copyright term in the first place. This scares me.
Here is how Gavin summarizes the future without increasing block sizes in
PR 6341:
> 1. Transaction confirmation times for transactions with a given fee will
rise; very-low-fee transactions will fail to get confirmed at all.
> 2. Average transaction fee paid will rise
> 3. People or applications unwilling or unable to pay the rising fees will
stop submitting transactions
> 4. People and businesses will shelve plans to use Bitcoin, stunting
growth and adoption
Is it fair to summarize this as "Some use cases won't fit any more, people
will decide to no longer use the blockchain for these purposes, and the
fees will adapt."?
I think that is already happening, and will happen at any scale. I believe
demand for payments in general is nearly infinite, and only a small portion
of it will eventually fit on a block chain (independent of whether its size
is limited by consensus rules or economic or technological means).
Furthermore, systems that compete with Bitcoin in this space already offer
orders of magnitude more capacity than we can reasonably achieve with any
blockchain technology at this point.
I don't know what subset of use cases Bitcoin will cater to in the long
term. They have already changed - you see way less betting transactions
these days than a few years ago for example - and they will keep changing,
independent of what effective block sizes we end up with. I don't think we
should be afraid of this change or try to stop it.
If you look at graphs of block sizes over time (for example,
http://rusty.ozlabs.org/?p=498), it seems to me that there is very little
"organic" growth, and a lot of sudden changes (which could correspond to
changing defaults in miner software, introduction of popular
sites/services, changes in the economy). I think these can be seen as the
economy changing to full up the available space, and I believe these will
keep happening at any size effectively available.
None of this is a reason why the size can't increase. However, in my
opinion, we should do it because we believe it increases utility and
understand the risks; not because we're afraid of what might happen if we
don't hurry up. And from that point of view, it seems silly to make a huge
increase at once...
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/69d0ee83/attachment.html>

2023-06-07 17:39:45 CEST

- reply

📅 Original date posted:2015-06-23
📝 Original message:On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> Wladimir noted that 'The original presented intention of block size
>> increase was a one-time "scaling" to grant time for more decentralizing
>> solutions to develop'
>>
>> Comments?
>>
>
> Consensus is that this process is too painful to go through once a year.
> I agree.
>
If you believe we will need to go through this process once a year, we are
not talking about a one-time scaling to grant time for more decentralizing
solutions. It means you think we should keep scaling. I don't disagree
there - as long as we're talking about scaling as availability of
bandwidth, storage and processing power increase, there is no reason
Bitcoin's blockchain can't grow proportionally.
However, an initial bump 8 MB and the growth rate afterwards seem more like
a no-effectively-limit-ever to me.
I fear that the wish of not wanting to deal with - admittedly - a very hard
problem, resulted here in throwing away several protections we currently
have. And yes, I know you believe 8 MB won't be created immediately. I
truly, honestly, do not think so either. But I prefer a system where I
don't need to rely on anyone's guesses for the future.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/a2560dc8/attachment.html>

2023-06-07 17:38:41 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn <mike at plan99.net> wrote:
> OK, let's agree to unpack the two things.
>
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>
> But let's leave it to one side for a moment.
>
> Let's focus on the other issue: what happens if the Bitcoin Core
> decision making process goes wrong?
>
Why do you keep talking about Bitcoin Core maintainers? The means for doing
a hard fork is convincing the network to run modified code, whether that is
a new version of Bitcoin Core or a fork of it, or something else entirely.
If I see consensus about a proposed network change, I will be in favor of
implementing it in Bitcoin Core. But we're not at that point. There is no
network change proposed with consensus. There is not even a patch to be
discussed. There are working proposals, and people are talking about them.
This is good.
I think maintainers of particular software should not be, and are not those
who decide the network's rules. People running the code are. Of course
maintainers have a large influence, but so do other people - like you.
> This was a reference to a post by Gregory on Reddit where he said if
Gavin were to do a pull request for the block size change and then merge
it, he would revert it. And I fully believe he would do so!
I believe so too, and I would do the same. Because I believe implementing a
consensus rule change without having very good expectations that the
network will adopt it, is reckless from the point of view of maintainers,
for all reasons I have mentioned before.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/d8c40122/attachment.html>

2023-06-07 17:38:28 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan <laanwj at gmail.com>
wrote:
> Like in any open source project there is lots of decision making ability
> for code changes. I'd say look at the changelog for e.g. 0.11
> https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
> or follow pull requests for a while, to see how many decisions about
> changes are made from day to day. No, I'm not sitting on my hands, and so
> is none of the other contributors that you'd like to get rid of.
>
The analogy goes further even. Even though I disagree with some of the
changes you're making, I respect Mike's (and anyone's) right to make a fork
of Bitcoin Core. That's how open source works: if people disagree with
changes made or not made, they can maintain their own version. However:
> Consensus changes are *much* more difficult, on the other hand. Even
> relatively straightforward softforks come with a long discussion process
> (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
> needs to upgrade their software!), and simply not possible if almost the
> entire technical community disagrees with you.
>
Consensus changes - in particular hardforks - are not about making a change
to the software. You are effectively asking users of the system to migrate
to a new system. Perhaps one which is a philosophical successor to the old
one, but a different system, with new rules that are incompatible with the
old one.
I believe this is something that can only be done if there is no
controversy about the change, for different reasons:
* Risk: no matter how you determine the switchover date, there is no way of
knowing when (and whether at all) everyone changes their full nodes (and
perhaps other software), and even very high hash power votes cannot prevent
an actual fork from appearing afterwards. At best, people lose the
guarantee that their confirmations are meaningful (because at some point it
becomes clear that the other side will get adopted, and they need to
switch). At worst, a fork persists, and two partitions appear, in each of
which you can spend every pre-existing coin. This defeats the primary
purpose Bitcoin was designed for: double spend protection.
* Philosophy: Bitcoin is not a democracy. The full node security model is
designed to minimize trust in other parties in the system. This works by
validating as much as possible according to the consensus rules. In
particular, there is no "majority vote" that can override things (contrary
to what some people think, it is not "longest chain wins, and a majority of
miners decide"; even a majority of miners cannot steal your coins or
produce more than the allowed subsidy, unless they convince others to
change their software). Changing the rules should be possible if there is
wide consensus, but nobody should feel forced to change their code against
their will.
* Governance: being able to push for a controversial change to the system
sets an incredibly dangerous precedent about who is in charge of the
system's rules. What if next time it is a change demanded by parties with
less good intentions (and yes, I believe people in this discussions all
have good intentions to improve the system in a way they think is most
useful)? I can promise you that I will say anything in mail to this list if
someone points a gun at me, and I think you should make the same assumption
about other people here. By avoiding controversial changes, you avoid
external and potentially invisible manipulation.
Of course, sometimes changes to the consensus rules may be wanted. The
presence of a bug is a good reason, and widespread agreement about one of
the system's limitation is too. As I said before, I think technological
growth in network bandwidth, processing power, and storage, are a good
reason why the system should be able to scale proportionally. I think there
are good technical and economic reasons why we should be cautious about
this, but the primary requirement is consensus, and aligning people's
expectation about what they can expect from network's evolution.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/306edc65/attachment.html>

2023-06-07 17:37:23 CEST

- reply

📅 Original date posted:2015-06-12
📝 Original message:Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports different
block sizes, takes fees into account, does difficulty adjustments, and
takes processing and mining delays into account. It also simulates longer
periods of time, and averages the result of many simulations running in
parallel until the variance on the result is low enough.
The code is here: https://github.com/sipa/bitcoin-net-simul
The configuration used in the code right now simulates two groups of miners
(one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
internally, but are only connected to each other through a slow 2 Mbit/s
link.
Here are some results.
This shows how the group of smaller miners loses around 8% of their
relative income (if they create larger blocks, their loss percentage goes
up slightly further):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 1000000.000000
* Expected average block size: 16200000.000000
* Average fee per block: 0.250000
* Fee per byte: 0.0000000154
Result:
* Miner group 0: 81.648985% income (factor 1.020612 with hashrate)
* Miner group 1: 18.351015% income (factor 0.917551 with hashrate)
When fees become more important however, and half of a block's income is
due to fees, the effect becomes even stronger (a 15% loss), and the optimal
way to compete for small miners is to create larger blocks as well (smaller
blocks for them result in even less income):
Configuration:
* Miner group 0: 80.000000% hashrate, blocksize 20000000.000000
* Miner group 1: 20.000000% hashrate, blocksize 20000000.000000
* Expected average block size: 20000000.000000
* Average fee per block: 25.000000
* Fee per byte: 0.0000012500
Result:
* Miner group 0: 83.063545% income (factor 1.038294 with hashrate)
* Miner group 1: 16.936455% income (factor 0.846823 with hashrate)
The simulator is not perfect. It doesn't take into account that multiple
blocks/relays can compete for the same bandwidth, or that nodes cannot
process multiple blocks at once.
The numbers used may be unrealistic, and I don't mean this as a prediction
for real-world events. However, it does very clearly show the effects of
larger blocks on centralization pressure of the system. Note that this also
does not make any assumption of destructive behavior on the network - just
simple profit maximalization.
Lastly, the code may be buggy; I only did some small sanity tests with
simple networks.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/e8c2f530/attachment.html>

2023-06-07 17:37:23 CEST

- reply

📅 Original date posted:2015-06-12
📝 Original message:If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
effect is likely an order of magnitude less important still, but the effect
is likely the same.
On Jun 12, 2015 8:31 PM, "Peter Todd" <pete at petertodd.org> wrote:
> On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> > Nice work, Pieter. You're right that my simulation assumed bandwidth for
> > 'block' messages isn't the bottleneck.
> >
> > But doesn't Matt's fast relay network (and the work I believe we're both
> > planning on doing in the near future to further optimize block
> propagation)
> > make both of our simulations irrelevant in the long-run?
>
> Then simulate first the relay network assuming 100% of txs use it, and
> secondly, assuming 100%-x use it.
>
> For instance, is it in miners' advantage in some cases to sabotage the
> relay network? The analyse say yes, so lets simulate that. Equally even
> the relay network isn't instant.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/ba1f8c93/attachment.html>

2023-06-07 17:36:55 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:You can't avoid sharing the token, and you can't avoid sharing the private
keys used for signing either. If they are single use, you don't lose
anything by sharing them.
Also you are not creating a real transaction. Why does the OP_RETURN
limitation matter?
On Jun 16, 2015 9:22 PM, "Kalle Rosenbaum" <kalle at rosenbaum.se> wrote:
> Thank you for your comments Pieter! Please find my answers below.
>
> 2015-06-16 16:31 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
> > On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <kalle at rosenbaum.se>
> wrote:
> >>
> >> 2015-06-15 12:00 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
> >> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> >> someone with more insight into CoinJoin have some input?
> >
> >
> > Not really. The problem is that you assume a transaction corresponds to a
> > single payment. This is true for simple wallet use cases, but not
> compatible
> > with CoinJoin, or with systems that for example would want to combine
> > multiple payments in a single transaction.
> >
>
> Yes, you are right. It's not compatible with CoinJoin and the likes.
>
> >
> > 48 bits seems low to me, but it does indeed solve the problem. Why not
> 128
> > or 256 bits?
>
> The nonce is limited because of the OP_RETURN output being limited to
> 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce.
>
> >
> >> > Why does anyone care who paid? This is like walking into a coffeshop,
> >> > noticing I don't have money with me, let me friend pay for me, and
> then
> >> > have
> >> > the shop insist that I can't drink it because I'm not the buyer.
> >>
> >> If you pay as you use the service (ie pay for coffee upfront), there's
> >> no need for PoP. Please see the Motivation section. But you are right
> >> that you must have the wallet(s) that paid at hand when you issue a
> >> PoP.
> >>
> >> >
> >> > Track payments, don't try to assign identities to payers.
> >>
> >> Please elaborate, I don't understand what you mean here.
> >
> >
> > I think that is a mistake. You should not assume that the wallet who held
> > the coins is the payer/buyer. That's what I said earlier; you're
> implicitly
> > creating an identity (the one who holds these keys) based on the
> > transaction. This seems fundamentally wrong to me, and not necessary. The
> > receiver should not care who paid or how, he should care what was payed
> for.
>
> You are saying that it's a problem that the wallet used to pay, must
> also be used to issue the PoP? That may very well be a problem in some
> cases. People using PoP should of course be aware of it's limitations
> and act accordingly, i.e. don't pay for concert tickets for a friend
> and expect your friend to be able to enter the arena with her wallet.
> As Tom Harding noted, it is possible to transfer keys to your friend's
> wallet, but that might not be desirable if those keys are also used
> for other payments. Also that would weaken the security of an HD
> wallet, since a chain code along with a private key would reveal all
> keys in that tree. Another solution is that your friend forwards the
> PoP request to your wallet, through twitter or SMS, and you send the
> PoP for her. Maybe that forwarding mechanism can be built into wallets
> and automated so that the wallet automatically suggests to sign the
> PoP for your friend. This is probably something to investigate
> further, but not within the scope of this BIP.
>
> Of course the simplest solution would be to send money to your friend
> first so that she can pay for the ticket from her own wallet, but
> that's not always feasible.
>
> >
> > The easiest solution to this IMHO would be an extension to the payment
> > protocol that gives you (or your wallet) a token in return for paying,
> and
> > that knowledge of that token is used to gain access to the services you
> > provide.
> >
>
> That token would then be reusable. Someone stealing it would be able
> to use it as much as she wants. That is what I want to avoid with PoP.
> The BIP proposal briefly mentions something like this in the
> rationale. I also had a discussion about this with Mike Hearn on this
> list on Mars 13 that I think covers most pros and cons of the
> different approaches.
>
> While your suggestion does indeed separate the transaction from the
> proof of payment, it also assumes that the token is held in the wallet
> that pays. Otherwise you would need to keep it in another safe place,
> remember it's reusable. Where would that be? How would you transfer
> that token to your friend?
>
> Thank you again for your comments. I appreciate it.
>
> Best regards,
> Kalle
>
> > --
> > Pieter
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/e854b9db/attachment.html>

2023-06-07 17:36:54 CEST

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
> 2015-06-15 12:00 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>
Not really. The problem is that you assume a transaction corresponds to a
single payment. This is true for simple wallet use cases, but not
compatible with CoinJoin, or with systems that for example would want to
combine multiple payments in a single transaction.
> > Also, if I understand correctly, there is no commitment to anything
> you're
> > trying to say about the sender? So once I obtain a proof-of-payment from
> you
> > about something you paid, I can go claim that it's mine?
>
> I don't understand this. The pop includes a nonce randomly generated
> by the server. If you're very lucky, 1/(2^48) per try, you can reuse a
> pop.
>
>
I owe you an apology here, for judging based on the summary you posted
rather than reading the actual text.
48 bits seems low to me, but it does indeed solve the problem. Why not 128
or 256 bits?
> Why does anyone care who paid? This is like walking into a coffeshop,
> > noticing I don't have money with me, let me friend pay for me, and then
> have
> > the shop insist that I can't drink it because I'm not the buyer.
>
> If you pay as you use the service (ie pay for coffee upfront), there's
> no need for PoP. Please see the Motivation section. But you are right
> that you must have the wallet(s) that paid at hand when you issue a
> PoP.
>
> >
> > Track payments, don't try to assign identities to payers.
>
> Please elaborate, I don't understand what you mean here.
>
I think that is a mistake. You should not assume that the wallet who held
the coins is the payer/buyer. That's what I said earlier; you're implicitly
creating an identity (the one who holds these keys) based on the
transaction. This seems fundamentally wrong to me, and not necessary. The
receiver should not care who paid or how, he should care what was payed for.
The easiest solution to this IMHO would be an extension to the payment
protocol that gives you (or your wallet) a token in return for paying, and
that knowledge of that token is used to gain access to the services you
provide.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/75813f1f/attachment.html>

2023-06-07 17:36:52 CEST

- reply

📅 Original date posted:2015-06-15
📝 Original message:I did misunderstand that. That changes things significantly.
However, having paid is not the same as having had access to the input
coins. What about shared wallets or coinjoin?
Also, if I understand correctly, there is no commitment to anything you're
trying to say about the sender? So once I obtain a proof-of-payment from
you about something you paid, I can go claim that it's mine?
Why does anyone care who paid? This is like walking into a coffeshop,
noticing I don't have money with me, let me friend pay for me, and then
have the shop insist that I can't drink it because I'm not the buyer.
Track payments, don't try to assign identities to payers.
On Jun 15, 2015 11:35 AM, "Kalle Rosenbaum" <kalle at rosenbaum.se> wrote:
> Hi Pieter!
>
> It is intended to be a proof that you *have paid* for something. Not
> that you have the intent to pay for something. You cannot use PoP
> without a transaction to prove.
>
> So, yes, it's just a proof of access to certain coins that you no longer
> have.
>
> Maybe I don't understand you correctly?
>
> /Kalle
>
> 2015-06-15 11:27 GMT+02:00 Pieter Wuille <pieter.wuille at gmail.com>:
> > Now that you have removed the outputs, I don't think it's even a intent
> of
> > payment, but just a proof of access to certain coins.
> >
> > On Jun 15, 2015 11:24 AM, "Kalle Rosenbaum" <kalle at rosenbaum.se> wrote:
> >>
> >> Hi all!
> >>
> >> I have made the discussed changes and updated my implementation
> >> (https://github.com/kallerosenbaum/poppoc) accordingly. These are the
> >> changes:
> >>
> >> * There is now only one output, the "pop output", of value 0.
> >> * The sequence number of all inputs of the PoP must be set to 0. I
> >> chose to set it to 0 for all inputs for simplicity.
> >> * The lock_time of the PoP must be set to 499999999 (max block height
> lock
> >> time).
> >>
> >> The comments so far has been mainly positive or neutral. Are there any
> >> major objections against any of the two proposals? If not, I will ask
> >> Gregory Maxwell to assign them BIP numbers.
> >>
> >> The two BIP proposals can be found at
> >> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and
> >> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The
> source
> >> for the Proof of Payment BIP proposal is also in-lined below.
> >>
> >> A number of alternative names have been proposed:
> >>
> >> * Proof of Potential
> >> * Proof of Control
> >> * Proof of Signature
> >> * Signatory Proof
> >> * Popo: Proof of payment origin
> >> * Pots: Proof of transaction signer
> >> * proof of transaction intent
> >> * Declaration of intent
> >> * Asset-access-and-action-affirmation, AAaAA, or A5
> >> * VeriBit
> >> * CertiBTC
> >> * VBit
> >> * PayID
> >>
> >> Given this list, I still think "Proof of Payment" is the most
> descriptive
> >> to non-technical people.
> >>
> >> Regards,
> >> Kalle
> >>
> >>
> >> #################################################
> >> <pre>
> >> BIP: <BIP number>
> >> Title: Proof of Payment
> >> Author: Kalle Rosenbaum <kalle at rosenbaum.se>
> >> Status: Draft
> >> Type: Standards Track
> >> Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
> >> </pre>
> >>
> >> == Abstract ==
> >>
> >> This BIP describes how a wallet can prove to a server that it has the
> >> ability to sign a certain transaction.
> >>
> >> == Motivation ==
> >>
> >> There are several scenarios in which it would be useful to prove that
> you
> >> have paid for something. For example:
> >>
> >> * A pre-paid hotel room where your PoP functions as a key to the door.
> >> * An online video rental service where you pay for a video and watch it
> on
> >> any device.
> >> * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity.
> During
> >> this period you can upload new content to the sign whenever you like
> using
> >> PoP.
> >> * Log in to a pay site using a PoP.
> >> * A parking lot you pay for monthly and the car authenticates itself
> using
> >> PoP.
> >> * A lottery where all participants pay to the same address, and the
> winner
> >> is selected among the transactions to that address. You exchange the
> prize
> >> for a PoP for the winning transaction.
> >>
> >> With Proof of Payment, these use cases can be achieved without any
> >> personal information (user name, password, e-mail address, etc) being
> >> involved.
> >>
> >> == Rationale ==
> >>
> >> Desirable properties:
> >>
> >> # A PoP should be generated on demand.
> >> # It should only be usable once to avoid issues due to theft.
> >> # It should be able to create a PoP for any payment, regardless of
> script
> >> type (P2SH, P2PKH, etc.).
> >> # It should prove that you have enough credentials to unlock all the
> >> inputs of the proven transaction.
> >> # It should be easy to implement by wallets and servers to ease
> adoption.
> >>
> >> Current methods of proving a payment:
> >>
> >> * In BIP0070, the PaymentRequest together with the transactions
> fulfilling
> >> the request makes some sort of proof. However, it does not meet 1, 2 or
> 4
> >> and it obviously only meets 3 if the payment is made through BIP0070.
> Also,
> >> there's no standard way to request/provide the proof. If standardized it
> >> would probably meet 5.
> >> * Signing messages, chosen by the server, with the private keys used to
> >> sign the transaction. This could meet 1 and 2 but probably not 3. This
> is
> >> not standardized either. 4 Could be met if designed so.
> >>
> >> If an input script type is P2SH, any satisfying script should do, just
> as
> >> if it was a payment. For M-of-N multisig scripts, that would mean that
> any
> >> set of M keys should be sufficient, not neccesarily the same set of M
> keys
> >> that signed the transaction. This is important because strictly
> demanding
> >> the same set of M keys would defeat the purpose of a multisig address.
> >>
> >> == Specification ==
> >>
> >> === Data structure ===
> >>
> >> A proof of payment for a transaction T, here called PoP(T), is used to
> >> prove that one has ownership of the credentials needed to unlock all the
> >> inputs of T. It has the exact same structure as a bitcoin transaction
> with
> >> the same inputs as T and in the same order as in T, but with each
> sequence
> >> number set to 0. There is exactly one output, here called the pop
> output,
> >> with value 0. The pop output must have the following format:
> >>
> >> OP_RETURN <version> <txid> <nonce>
> >>
> >> {|
> >> ! Field !! Size [B] !! Description
> >> |-
> >> | <version> || 2 || Version, little endian, currently 0x01
> 0x00
> >> |-
> >> | <txid> || 32 || The transaction to prove
> >> |-
> >> | <nonce> || 6 || Random data
> >> |}
> >>
> >> The lock_time of the PoP must be set to 499999999 to prevent the PoP
> from
> >> being included in a block, should it appear on the bitcoin p2p network.
> This
> >> is also the reason for setting the sequence numbers to 0, since sequence
> >> number of ffffffff would make lock_time ineffective. This specification
> >> demands that all input sequence numbers are 0, not just one of them,
> which
> >> would be sufficient to make lock_time effective. This is for simplicity
> >> reasons.
> >>
> >> An illustration of the PoP data structure and its original payment is
> >> shown below.
> >>
> >> <pre>
> >> T
> >> +------------------------------------------------+
> >> |inputs | outputs |
> >> | Value,Sequence | Value,Script |
> >> +------------------------------------------------+
> >> |input0 1,ffffffff | 0,pay to A |
> >> |input1 3,ffffffff | 2,OP_RETURN <some data> |
> >> |input2 4,ffffffff | 1,pay to B |
> >> | | 4,pay to C |
> >> +------------------------------------------------+
> >>
> >> PoP(T)
> >> +-------------------------------------------------------------+
> >> | inputs | outputs |
> >> | Value,Sequence | Value,Script |
> >> +-------------------------------------------------------------+
> >> |input0 1,00000000 | 0,OP_RETURN <version> <txid> <nonce> |
> >> |input1 3,00000000 | |
> >> |input2 4,00000000 | |
> >> +-------------------------------------------------------------+
> >> | lock_time=499999999 |
> >> +-------------------------------------------------------------+
> >> </pre>
> >>
> >> The PoP is signed using the same signing process that is used for
> bitcoin
> >> transactions.
> >>
> >> The purpose of the nonce is to make it harder to use a stolen PoP; Once
> >> the PoP has reached the server, that PoP is useless since the server
> will
> >> generate a new nonce for every PoP request.
> >>
> >> === Process ===
> >>
> >> # A proof of payment request is sent from the server to the wallet. The
> >> PoP request contains:
> >> ## a random nonce
> >> ## a destination where to send the PoP, for example a https URL
> >> ## data hinting the wallet which transaction to create a proof for. For
> >> example:
> >> ##* txid, if known by the server
> >> ##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070
> >> payment)
> >> ##* amount, label, message or other information from a BIP0021 URI
> >> # The wallet identifies a transaction T, if possible. Otherwise it asks
> >> the user to select among the ones that match the hints in 1.iii.
> >> # The wallet creates an unsigned PoP (UPoP) for T, and asks the user to
> >> sign it.
> >> # The user confirms
> >> # The UPoP(T) is signed by the wallet, creating PoP(T).
> >> # The PoP is sent to the destination in 1.ii.
> >> # The server receiving the PoP validates it and responds with “valid” or
> >> “invalid”.
> >> # The wallet displays the response in some way to the user.
> >>
> >> '''Remarks:'''
> >>
> >> * The method of transferring the PoP request at step 1 is not specified
> >> here. Instead that is specified in separate specifications. See [btcpop
> >> scheme BIP](btcpop scheme BIP).
> >> * The nonce must be randomly generated by the server for every new PoP
> >> request.
> >>
> >> === Validating a PoP ===
> >>
> >> The server needs to validate the PoP and reply with "valid" or
> "invalid".
> >> That process is outlined below. If any step fails, the validation is
> aborted
> >> and "invalid" is returned:
> >>
> >> # Check the format of the PoP. It must pass normal transaction checks,
> >> except that the inputs may already be spent.
> >> # Check that lock_time is 499999999.
> >> # Check that there is exactly one output. This output must have value 0
> >> and conform to the OP_RETURN output format outlined above.
> >> # Check that the nonce is the same as the one requested.
> >> # Check that the inputs of the PoP are exactly the same as in
> transaction
> >> T, except that the sequence numbers must all be 0. The ordering of the
> >> inputs must also be the same as in T.
> >> # Run the scripts of all the inputs. All scipts must return true.
> >> # Check that the txid in the PoP output is the transaction you actually
> >> want proof for. If you don’t know exactly what transaction you want
> proof
> >> for, check that the transaction actually pays for the product/service
> you
> >> deliver.
> >> # Return "valid".
> >>
> >> == Security considerations ==
> >>
> >> * Someone can intercept the PoP-request and change any parameter in it.
> >> These can be mitigated by using secure connections. For example:
> >> ** Pop destination - Stealing your PoP.
> >> ** label - Trick you to sign an unintended pop or set a label that your
> >> wallet doesn't have any record for, resulting in a broken service.
> Always
> >> check the PoP before signing.
> >> ** nonce - Your pop will not validate on server.
> >> * Someone can steal a PoP, for example by tampering with the PoP
> request,
> >> and try to use the service hoping to get a matching nonce. Probability
> per
> >> try: 1/(2^48). The server should have a mechanism for detecting a brute
> >> force attack of this kind, or at least slow down the process by
> delaying the
> >> PoP request by some 100 ms or so.
> >> * Even if a wallet has no funds it might still be valuable as a
> generator
> >> for PoPs. This makes it important to keep the security of the wallet
> after
> >> it has been emptied.
> >> * Transaction malleability may cause the server to have another
> >> transaction id for a payment than the client's wallet. In that case the
> >> wallet will not be able to prove the transaction to the server. Wallets
> >> should not rely on the transaction id of the outgoing transaction.
> Instead
> >> it should listen for the transaction on the network and put that in its
> list
> >> of transactions.
> >>
> >> == Reference implementation ==
> >>
> >> [https://github.com/kallerosenbaum/poppoc poppoc on GitHub]
> >>
> >> [https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub]
> >>
> >> == References ==
> >>
> >> [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki
> BIP0021]:
> >> URI Scheme
> >>
> >> [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
> BIP0070]:
> >> Payment Protocol
> >>
> >> [[btcpop scheme BIP]]
> >>
> >> #########################################################
> >>
> >> 2015-06-06 23:25 GMT+02:00 Kalle Rosenbaum <kalle at rosenbaum.se>:
> >> > Thank you all for the feedback.
> >> >
> >> > I will change the data structure as follows:
> >> >
> >> > * There will be only one output, the "pop output", and no outputs from
> >> > T will be copied to the PoP.
> >> > * The pop output will have value 0.
> >> > * The sequence number of all inputs of the PoP will be set to 0. I
> >> > chose to set it to 0 for all inputs for simplicity.
> >> > * The lock_time of the PoP is always set to 499999999.
> >> >
> >> > Any comments on this?
> >> >
> >> > /Kalle
> >> >
> >> > 2015-06-06 19:00 GMT+02:00 Kalle Rosenbaum <kalle at rosenbaum.se>:
> >> >> 2015-06-06 18:10 GMT+02:00 Tom Harding <tomh at thinlink.com>:
> >> >>> On Jun 6, 2015 8:05 AM, "Kalle Rosenbaum" <kalle at rosenbaum.se>
> wrote:
> >> >>>
> >> >>>> I'm open to changes here.
> >> >>>
> >> >>> I suggest:
> >> >>>
> >> >>> - Don't include any real outputs. They are redundant because the
> >> >>> txid is
> >> >>> already referenced.
> >> >>
> >> >> with the nLocktime solution, the copied outputs are not needed.
> >> >>
> >> >>>
> >> >>> - Start the proof script, which should be invalid, with a magic
> >> >>> constant and
> >> >>> include space for future expansion. This makes PoP's easy to
> identify
> >> >>> and
> >> >>> extend.
> >> >>
> >> >> I did remore the constant (a "PoP" literal ascii encoded string)
> >> >> because it didn't add much. The recipient will expect a pop, so it
> >> >> will simply treat it as one. I did add a 2 byte version field to make
> >> >> it extendable.
> >> >>
> >> >>>
> >> >>> - "Proof of Potential"
> >> >>
> >> >> Noted :-)
> >> >>
> >> >> Thank you
> >> >> /Kalle
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/eb18f534/attachment.html>

2023-06-07 17:36:51 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr <luke at dashjr.org> wrote:
> I also agree with Pieter, that this should *not* be so cleanly compatible
> with Bitcoin transactions. If you wish to share code, perhaps using an
> invalid opcode rather than OP_RETURN would be appropriate.
Using an invalid opcode would merely send funds into the void. It wouldn't
invalidate the transaction.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/e8ba6131/attachment.html>

2023-06-07 17:36:49 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
> > What do you gain by making PoPs actually valid transactions? You could
> for
> > example change the signature hashing algorithm (prepend a constant
> string,
> > or add a second hashing step) for signing, rendering the signatures in a
> PoP
> > unusable for actual transaction, while still committing to the same
> actual
> > transaction. That would also remove the need for the OP_RETURN to catch
> > fees.
>
> The idea is to simplify implementation. Existing software can be used
> as is to sign and validate PoPs. But I do agree that it would be a
> cleaner specification if we would make the PoP invalid as a
> transaction. I'm open to changes here. I do like the idea to prepend a
> constant string. But that would require changes in transaction signing
> and validation code, wouldn't it?
>
Yes, of course. An alternative is adding a 21M BTC output at the end, or
bitflipping the txin prevout hashes, or another reversible transformation
on the transaction data that is guaranteed to invalidate it.
I think that the risk of asking people to sign something that is not an
actual transaction, but could be used as one, is very scary.
> > Also, I would call it "proof of transaction intent", as it's a
> commitment to
> > a transaction and proof of its validity, but not a proof that an actual
> > transaction took place, nor a means to prevent it from being double
> spent.
>
>
> Naming is hard. I think a simpler name that explains what its main
> purpose is (prove that you paid for something) is better than a name
> that exactly tries to explain what it is.
"Proof of Payment" indeed does make me think it's something that proves you
paid. But as described, that is not what a PoP does. It proves the ability
to create a particular transaction, and committing to it. There is no
actual payment involved (plus, payment makes me think you're talking about
BIP70 payments, not simple Bitcoin transactions).
> "Proof of transaction
> intent" does not help me understand what this is about. But I would
> like to see more name suggestions. The name does not prevent people
> from using it for other purposes, ie internet over telephone network.
>
I don't understand why something like "Proof of Transaction Intent" would
be incompatible with internet over telephone network either...
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/f9b9daa2/attachment.html>

2023-06-07 17:36:47 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:What do you gain by making PoPs actually valid transactions? You could for
example change the signature hashing algorithm (prepend a constant string,
or add a second hashing step) for signing, rendering the signatures in a
PoP unusable for actual transaction, while still committing to the same
actual transaction. That would also remove the need for the OP_RETURN to
catch fees.
Also, I would call it "proof of transaction intent", as it's a commitment
to a transaction and proof of its validity, but not a proof that an actual
transaction took place, nor a means to prevent it from being double spent.
On Sat, Jun 6, 2015 at 4:35 PM, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
> Hi
>
> Following earlier posts on Proof of Payment I'm now proposing the
> following BIP (To read it formatted instead, go to
> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP).
>
> Regards,
> Kalle Rosenbaum
>
> <pre>
> BIP: <BIP number>
> Title: Proof of Payment
> Author: Kalle Rosenbaum <kalle at rosenbaum.se>
> Status: Draft
> Type: Standards Track
> Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
> </pre>
>
> == Abstract ==
>
> This BIP describes how a wallet can prove to a server that it has the
> ability to sign a certain transaction.
>
> == Motivation ==
>
> There are several scenarios in which it would be useful to prove that you
> have paid for something. For example:
>
> * A pre-paid hotel room where your PoP functions as a key to the door.
> * An online video rental service where you pay for a video and watch it on
> any device.
> * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During
> this period you can upload new content to the sign whenever you like using
> PoP.
> * Log in to a pay site using a PoP.
> * A parking lot you pay for monthly and the car authenticates itself using
> PoP.
> * A lottery where all participants pay to the same address, and the winner
> is selected among the transactions to that address. You exchange the prize
> for a PoP for the winning transaction.
>
> With Proof of Payment, these use cases can be achieved without any
> personal information (user name, password, e-mail address, etc) being
> involved.
>
> == Rationale ==
>
> Desirable properties:
>
> # A PoP should be generated on demand.
> # It should only be usable once to avoid issues due to theft.
> # It should be able to create a PoP for any payment, regardless of script
> type (P2SH, P2PKH, etc.).
> # It should prove that you have enough credentials to unlock all the
> inputs of the proven transaction.
> # It should be easy to implement by wallets and servers to ease adoption.
>
> Current methods of proving a payment:
>
> * In BIP0070, the PaymentRequest together with the transactions fulfilling
> the request makes some sort of proof. However, it does not meet 1, 2 or 4
> and it obviously only meets 3 if the payment is made through BIP0070. Also,
> there's no standard way to request/provide the proof. If standardized it
> would probably meet 5.
> * Signing messages, chosen by the server, with the private keys used to
> sign the transaction. This could meet 1 and 2 but probably not 3. This is
> not standardized either. 4 Could be met if designed so.
>
> If the script type is P2SH, any satisfying script should do, just like for
> a payment. For M-of-N multisig scripts, that would mean that any set of M
> keys should be sufficient, not neccesarily the same set of M keys that
> signed the transaction. This is important because strictly demanding the
> same set of M keys would undermine the purpose of a multisig address.
>
> == Specification ==
>
> === Data structure ===
>
> A proof of payment for a transaction T, here called PoP(T), is used to
> prove that one has ownership of the credentials needed to unlock all the
> inputs of T. It has the exact same structure as a bitcoin transaction with
> the same inputs and outputs as T and in the same order as in T. There is
> also one OP_RETURN output inserted at index 0, here called the pop output.
> This output must have the following format:
>
> OP_RETURN <version> <txid> <nonce>
>
> {|
> ! Field !! Size [B] !! Description
> |-
> | <version> || 2 || Version, little endian, currently 0x01 0x00
> |-
> | <txid> || 32 || The transaction to prove
> |-
> | <nonce> || 6 || Random data
> |}
>
> The value of the pop output is set to the same value as the transaction
> fee of T. Also, if the outputs of T contains an OP_RETURN output, that
> output must not be included in the PoP because there can only be one
> OP_RETURN output in a transaction. The value of that OP_RETURN output is
> instead added to the value of the pop output.
>
> An illustration of the PoP data structure and its original payment is
> shown below.
>
> <pre>
> T
> +----------------------------------------------+
> |inputs | outputs |
> | Value | Value Script |
> +----------------------------------------------+
> |input0 1 | 0 pay to A |
> |input1 3 | 2 OP_RETURN <some data> |
> |input2 4 | 1 pay to B |
> | | 4 pay to C |
> +----------------------------------------------+
>
> PoP(T)
> +----------------------------------------------------------+
> |inputs | outputs |
> | Value | Value Script |
> +----------------------------------------------------------+
> |input0 1 | 3 OP_RETURN <version> <txid> <nonce> |
> |input1 3 | 0 pay to A |
> |input2 4 | 1 pay to B |
> | | 4 pay to C |
> +----------------------------------------------------------+
> </pre>
>
> The PoP is signed using the same signing process that is used for bitcoin
> transactions.
>
> The purpose of the nonce is to make it harder to use a stolen PoP; Once
> the PoP has reached the server, that PoP is useless since the server will
> generate a new nonce for every PoP request.
>
> Since a PoP is indistinguishable from a bitcoin transaction, there is a
> risk that it, accidently or maliciously, enters the bitcoin p2p network. If
> T is still unconfirmed, or if a reorg takes place, chances are that PoP(T)
> ends up in a block, invalidating T. Therefore it is important that the
> outputs of the PoP are the same as in T. The zero transaction fee in PoP(T)
> is to minimize the incentives for miners to select PoP(T) for inclusion.
>
> === Process ===
>
> # A proof of payment request is sent from the server to the wallet. The
> PoP request contains:
> ## a random nonce
> ## a destination where to send the PoP, for example a https URL
> ## data hinting the wallet which transaction to create a proof for. For
> example:
> ##* txid, if known by the server
> ##* PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070
> payment)
> ##* amount, label, message or other information from a BIP0021 URL
> # The wallet identifies a transaction T, if possible. Otherwise it asks
> the user to select among the ones that match the hints in 1.iii.
> # The wallet creates an unsigned PoP (UPoP) for T, and asks the user to
> sign it.
> # The user confirms
> # The UPoP(T) is signed by the wallet, creating PoP(T).
> # The PoP is sent to the destination in 1.ii.
> # The server receiving the PoP validates it and responds with “valid” or
> “invalid”.
> # The wallet displays the response in some way to the user.
>
> '''Remarks:'''
>
> * The method of transferring the PoP request at step 1 is not specified
> here. Instead that is specified in separate specifications. See [btcpop
> scheme BIP](btcpop scheme BIP).
> * The nonce must be randomly generated by the server for every new PoP
> request.
>
> === Validating a PoP ===
>
> The server needs to validate the PoP and reply with "valid" or "invalid".
> That process is outlined below. If any step fails, the validation is
> aborted and "invalid" is returned:
>
> # Check the format of the PoP. It must pass normal transaction checks,
> except that the inputs may already be spent.
> # Check the PoP output at index 0. It must conform to the OP_RETURN output
> format outlined above.
> # Check that the rest of the outputs exactly corresponds to the outputs of
> T and that they appear in the same order as in T. An exception to this is
> that any OP_RETURN outputs of T must not be included in the PoP. All output
> value from the OP_RETURN must instead be included in the PoP output.
> # Check that the nonce is the same as the one you requested.
> # Check that the inputs of the PoP are exactly the same as in transaction
> T, and in the same order.
> # Check the scripts of all the inputs, as would be done on a normal
> transaction.
> # Check that the txid in the PoP output is the transaction you actually
> want proof for. If you don’t know exactly what transaction you want proof
> for, check that the transaction actually pays for the product/service you
> deliver.
> # Return "valid".
>
> == Security considerations ==
>
> * Someone can intercept the PoP-request and change the PoP destination so
> that the user sends the PoP to the bad actor.
> * Someone can intercept the PoP-request and change for example the txid to
> trick the user to sign a PoP for another transaction than the intended.
> This can of course be avoided if the user is actually looking at the UPoP
> before signing it. The bad actor could also set hints for a transaction,
> existing or not, that the user didn’t make, resulting in a broken service.
> * Someone can steal a PoP and try to use the service hoping to get a
> matching nonce. Probability per try: 1/(2^48). The server should have a
> mechanism for detecting a brute force attack of this kind, or at least slow
> down the process by delaying the PoP request by some 100 ms or so.
> * Even if a wallet has no funds it might still be valuable as a generator
> for PoPs. This makes it important to keep the security of the wallet after
> it has been emptied.
> * Transaction malleability may cause the server to have another
> transaction id than the wallet for the payment. In that case the wallet
> will not be able to prove the transaction for the server. Wallets should
> not rely on the transaction id of the outgoing transaction. Instead it
> should listen for the transaction on the network and put that in its list
> of transactions.
>
> The first two issues are the same attack vector as for traditional, ie
> BIP0021, bitcoin payments. They could be mitigated by using secure
> connections.
>
> == Reference implementation ==
>
> [https://github.com/kallerosenbaum/poppoc poppoc on GitHub]
>
> [https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub]
>
> == References ==
>
> [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP0021]:
> URI Scheme
>
> [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP0070]:
> Payment Protocol
>
> [[btcpop scheme BIP]]
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/f67abf67/attachment.html>

2023-06-07 17:34:10 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:> until we have size-independent new block propagation
I don't really believe that is possible. I'll argue why below. To be clear,
this is not an argument against increasing the block size, only against
using the assumption of size-independent propagation.
There are several significant improvements likely possible to various
aspects of block propagation, but I don't believe you can make any part
completely size-independent. Perhaps the remaining aspects result in terms
in the total time that vanish compared to the link latencies for 1 MB
blocks, but there will be some block sizes for which this is no longer the
case, and we need to know where that is the case.
* You can't assume that every transaction is pre-relayed and pre-validated.
This can happen due to non-uniform relay policies (different codebases, and
future things like size-limited mempools), double spend attempts, and
transactions generated before a block had time to propagate. You've
previously argued for a policy of not including too recent transactions,
but that requires a bound on network diameter, and if these late
transactions are profitable, it has exactly the same problem as making
larger blocks non-proportionally more economic for larger pools groups if
propagation time is size dependent).
* This results in extra bandwidth usage for efficient relay protocols,
and if discrepancy estimation mispredicts the size of IBLT or error
correction data needed, extra roundtrips.
* Signature validation for unrelayed transactions will be needed at block
relay time.
* Database lookups for the inputs of unrelayed transactions cannot be
cached in advance.
* Block validation with 100% known and pre-validated transactions is not
constant time, due to updates that need to be made to the UTXO set (and
future ideas like UTXO commitments would make this effect an order of
magnitude worse).
* More efficient relay protocols also have higher CPU cost for
encoding/decoding.
Again, none of this is a reason why the block size can't increase. If
availability of hardware with higher bandwidth, faster disk/ram access
times, and faster CPUs increases, we should be able to have larger blocks
with the same propagation profile as smaller blocks with earlier technology.
But we should know how technology scales with larger blocks, and I don't
believe we do, apart from microbenchmarks in laboratory conditions.
--
Pieter
On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration and
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
A lot of people like this idea, or something like it. It is nice and
simple, which is really important for consensus-critical code.
With this rule in place, I believe there would be more "fee pressure"
(miners would be creating smaller blocks) today. I created a couple of
histograms of block sizes to infer what policy miners are ACTUALLY
following today with respect to block size:
Last 1,000 blocks:
http://bitcoincore.org/~gavin/sizes_last1000.html
Notice a big spike at 750K -- the default size for Bitcoin Core.
This graph might be misleading, because transaction volume or fees might
not be high enough over the last few days to fill blocks to whatever limit
miners are willing to mine.
So I graphed a time when (according to statoshi.info) there WERE a lot of
transactions waiting to be confirmed:
http://bitcoincore.org/~gavin/sizes_357511.html
That might also be misleading, because it is possible there were a lot of
transactions waiting to be confirmed because miners who choose to create
small blocks got lucky and found more blocks than normal. In fact, it
looks like that is what happened: more smaller-than-normal blocks were
found, and the memory pool backed up.
So: what if we had a dynamic maximum size limit based on recent history?
The average block size is about 400K, so a 1.5x rule would make the max
block size 600K; miners would definitely be squeezing out transactions /
putting pressure to increase transaction fees. Even a 2x rule (implying
800K max blocks) would, today, be squeezing out transactions / putting
pressure to increase fees.
Using a median size instead of an average means the size can increase or
decrease more quickly. For example, imagine the rule is "median of last
2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
producing max-size blocks. The median is max-size, so the 51% have total
control over making blocks bigger. Swap the roles, and the median is
min-size.
Because of that, I think using an average is better-- it means the max size
will change (up or down) more slowly.
I also think 2016 blocks is too long, because transaction volumes change
quicker than that. An average over 144 blocks (last 24 hours) would be
better able to handle increased transaction volume around major holidays,
and would also be able to react more quickly if an economically irrational
attacker attempted to flood the network with fee-paying transactions.
So my straw-man proposal would be: max size 2x average size over last 144
blocks, calculated at every block.
There are a couple of other changes I'd pair with that consensus change:
+ Make the default mining policy for Bitcoin Core neutral-- have its target
block size be the average size, so miners that don't care will "go along
with the people who do care."
+ Use something like Greg's formula for size instead of bytes-on-the-wire,
to discourage bloating the UTXO set.
---------
When I've proposed (privately, to the other core committers) some dynamic
algorithm the objection has been "but that gives miners complete control
over the max block size."
I think that worry is unjustified right now-- certainly, until we have
size-independent new block propagation there is an incentive for miners to
keep their blocks small, and we see miners creating small blocks even when
there are fee-paying transactions waiting to be confirmed.
I don't even think it will be a problem if/when we do have size-independent
new block propagation, because I think the combination of the random timing
of block-finding plus a dynamic limit as described above will create a
healthy system.
If I'm wrong, then it seems to me the miners will have a very strong
incentive to, collectively, impose whatever rules are necessary (maybe a
soft-fork to put a hard cap on block size) to make the system healthy again.
--
--
Gavin Andresen
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/5c893428/attachment.html>

2023-06-07 17:32:31 CEST

- reply

📅 Original date posted:2015-04-17
📝 Original message:> Anyone can alter the txid - more details needed. The number of altered
> txids in practice is not so high in order to make us believe anyone can
> do it easily. It is obvious that all current bitcoin transactions are
> malleable, but not by anyone and not that easy. At least I like to think
so.
Don't assume that because it does not (frequently) happen, that it cannot
happen. Large amounts of malleated transactions have happened in the past.
Especially if you build a system depends on non-malleability for its
security, you may at some point have an attacker who has financial gain
from malleation.
> >From your answer I understand that right now if I create a transaction
> (tx1) and broadcast it, you can alter its txid at your will, without any
> mining power and/or access to my private keys so I would end up not
> recognizing my own transaction and probably my change too (if my systems
> rely hardly on txid)?
In theory, yes, anyone can alter the txid without invalidating it, without
mining power and without access to the sender's private keys.
All it requires is seeing a transaction on the network, doing a trivial
modification to it, and rebroadcasting it quickly. If the modifies version
gets mined, you're out of luck. Having mining power helps of course.
After BIP62, you will, as a sender, optionally be able to protect others
from malleating. You're always able to re-sign yourself.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150417/0f221669/attachment.html>

2023-06-07 17:28:51 CEST

- reply

📅 Original date posted:2015-01-20
📝 Original message:Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
"OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection."
on this mailing list) have made it clear that the problem is very
real, however, and I would prefer to have a fundamental solution for
it sooner rather than later.
I therefore propose a softfork to make non-DER signatures illegal
(they've been non-standard since v0.8.0). A draft BIP text can be
found on:
https://gist.github.com/sipa/5d12c343746dad376c80
The document includes motivation and specification. In addition, an
implementation (including unit tests derived from the BIP text) can be
found on:
https://github.com/sipa/bitcoin/commit/bipstrictder
Comments/criticisms are very welcome, but I'd prefer keeping the
discussion here on the mailinglist (which is more accessible than on
the gist).
--
Pieter

2023-06-07 17:28:51 CEST

- reply

📅 Original date posted:2015-01-21
📝 Original message:On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> // Null bytes at the start of R are not allowed, unless it would otherwise be
> // interpreted as a negative number.
> if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80))
> return false;
>
> You mean "null bytes at the start of S".
Thanks, fixed.
--
Pieter