Gregory Maxwell [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-07-01 to 2019-03-13
💬 Posted a total of 765 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15, PATCH, RFC, PATCH, try2, BIP proposal, QT, BIP draft, softfork proposal, bitcoin-dev, BIP-draft, was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!, Was: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!, BIP, patch, BIP Proposal, trivial protocol change BIP, bitcoin-core-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet

Profile Code

nprofile1qqsy4fk0n2ju36v0gqw6ccpudggzqagfk6s8x9m8d6wkv90n6ugr6ucprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueq3c4y9m

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet

Show more details

Last Notes

2023-06-09 12:51:06

- reply

📅 Original date posted:2018-07-02
📝 Original message:
On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
I know it seems kind of silly, but I think it's somewhat important
that the formal name of this flag is something like
"SIGHASH_REPLAY_VULNERABLE" or likewise or at least
"SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
insecure for traditional applications where a third party might pay to
an address a second time, and should only be used in special protocols
which make that kind of mistake unlikely. Otherwise, I'm worried
that wallets might start using this sighash because it simplifies
handling malleability without realizing that when a third party reuses
a script pubkey, completely outside of control of the wallet that uses
the flag, funds will be lost as soon as a troublemaker shows up (but
not, sadly, in testing). This sort of risk is magnified because the
third party address reuser has no way to know that this sighash flag
has (or will) be used with a particular scriptpubkey.
So, one could even argue that the possibility that someone might use
this flag means that it's generally unsafe to reuse a scriptpubkey. I
don't think the same argument applies for NONE or the single-bug
because they render even a single use insecure... The best mitigation
I can think of is defence in depth to ensure that anyone who uses this
sighash flag understands the consequences.

2023-06-09 12:51:06

- reply

📅 Original date posted:2018-07-03
📝 Original message:
On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd <pete at petertodd.org> wrote:
> The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> about what the flag actually does.
I believe that making the signature replayable is 1:1 with omitting
the identification of the specific coin being spent from it.

2023-06-07 18:16:40

- reply

📅 Original date posted:2019-03-06
📝 Original message:On Wed, Mar 6, 2019 at 12:22 AM Wladimir J. van der Laan via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Field <code>addr</code> has a variable length, with a maximum of 32 bytes (256 bits). Clients SHOULD reject
> longer addresses.
Is 32 bytes long enough for I2P? It seems like there are two formats,
is there a reason we might want to use the longer one?
https://geti2p.net/en/docs/naming
Probably the spec should define the limit per address type (e.g.
sending a 32 byte IPv4 makes no sense). And either a maximum for ANY
type (so that 1000*largest size is reasonable), or a maximum size for
the message (e.g. regardless of the included size, an add message
should never be over, say 100k).
> * ''Client MAY store and gossip address formats that they do not know about'': does it ever make sense to gossip addresses outside a certain overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no exit nodes as there is no overlap with the globally routed internet at all.
I think clients should be discouraged from gossiping stuff they cannot
test but not forbidden from doing so. Separately, they should be
strongly discouraged from gossiping types they don't understand at
all. We don't really want to see people doing file xfer over invalid
addr types. :)

2023-06-07 18:16:36

- reply

📅 Original date posted:2019-03-07
📝 Original message:On Thu, Mar 7, 2019 at 11:46 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> First and foremost, reject messages are an indication that the
> transaction isn't going to confirm. Without these messages, we'd need to
> revert to pre-BIP61 behaviour of using a timeout for reception of
> network confirmations.
That is already required because even in the presence of perfectly
honest and cooperative hosts reject messages at most can only tell you
about first-hop behaviour. It won't even tell you if the transaction
was ever even attempted to be sent to a next hop. So alternative
handling must be provided and must be reliable for the software to
work at all regardless of reject messages.
> - Not enough fee
Rejection on low fee (over the static minimum feerate) only happens at
the point where the nodes mempool is full, which is already at a point
where you might be waiting weeks for confirmation.
Rejection causes were also not stable or reliable because the validity
criteria cannot generally be tested independently. For example, if a
transaction is queued due to missing a parent it isn't rejected
because missing the parent is often a temporary issue, but its feerate
cannot be measured without the parent. Later, when the parent is
obtained, the transaction can then be rejected due to feerate-- but no
reject is sent then.
Output already spend is often completely indistinguishable from a
missing parent and can't get rejects generated for it generally.
Similarly, the error state detected for things like invalid signatures
are often not very useful. The software knows that script execution
returned false, but in the general case _why_ it returned false is not
clear, and a straightforward high performance validation
implementation doesn't necessarily yield a good way of figuring out
and propagating up that information. (I think invalid signatures end
up returning a stack-nonempty state from validation currently, as an
example of that).

2023-06-07 18:16:25

- reply

📅 Original date posted:2019-02-06
📝 Original message:On Wed, Feb 6, 2019 at 8:10 AM Tamas Blummer <tamas.blummer at gmail.com> wrote:
> I am skeptical that commitment of any filter will come into Core soon. [...] A committed filter makes light clients much more reliable and attractive, for some taste too much more.
You keep repeating this smear. Please stop.
If you would actually bother reading the threads where this was
discussed previously you will see that there was significant interest
from bitcoin developers to eventually commit an output filter, and a
significant investment of effort in improving the proposal to that
end. It is really disheartening to see you continue to repeat your
negative assumptions about other people's wishes when you haven't even
invested the time required to read their words.

2023-06-07 18:14:30

- reply

📅 Original date posted:2018-09-11
📝 Original message:On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty <erik at q32.com> wrote:
> The security advantages of a redistributable threshold system are huge. If a system isn't redistributable, then a single lost or compromised key results in lost coins... meaning the system is essetntially unusable.
>
> I'm actually worried that Bitcoin releases a multisig that encourages loss.
There is no "non- edistributiable multisig" proposed for Bitcoin
anywhere that I am aware of.

2023-06-07 18:14:29

- reply

📅 Original date posted:2018-09-11
📝 Original message:On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty <erik at q32.com> wrote:
> To answer points:
>
> - I switched to the medium article so that I could correct, edit and
> improve things to make them more clear.
> - I responded to feedback by modifying the protocol to make it work - not
> by ignoring it.
>
To this moment there remains no response at your post.
https://bitcointalk.org/index.php?topic=4973123.0
I'm not sure how I am supposted to have figured out that you wrote a
somewhat different repost of it elsewhere...
- An M-1 rogue-key attack would require the attacker would to either
>
> - attack the hash function to produce a predictable R based on a known
> mesage
> - attack the DLP to influence x or k
>
> Neither attack gives any particular advantage to someone who has M-1 keys.
>
You keep asserting this. It isn't true. Asserting it more does not make it
any more true. I already explained how to attack this style of signature
(e.g. in the BCT thread).
Set aside your 'interpolation' for a moment, and imagine that you construct
a 2 of 2 signature by just adding the keys. Your tell me your key, P1 and
then I tell you that my key P2 which I derived by computing -P1 + xG. We
now compute P = P1 + P2 = P1 + -P1 + xG = xG ... and now in spite adding P1
with an unknown discrete log, I know the discrete log of P with respect to
G and I did not need to violate the standard DL security assumption to
achieve that.
With the 'interpolation' in effect the same attack applies but its
execution is somewhat more complex: instead of adding the negation of P1 I
must add a number of multiplicities of P1 (like P1*2, P1*3, P1*4...)
selected so that their interpolation coefficients add up to -1. Finding a
suitable subset requires solving a randomized modular subset sum problem
and Wagner's algorithm provides a computationally tractable solution to it.
The potential of rogue keys applies to both the keys themselves and to the
nonces. There are several ways to prevent these attacks, the musig paper
describes a delinearization technique which doesn't require additional
interaction or communication.
I haven't tested whether the R,s version is susceptible though.
>
There is a perfect bijection between the two encodings which is easily
computable, so they're the same thing from an abstract security perspective.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180911/6d4ebd71/attachment.html>

2023-06-07 18:14:28

- reply

📅 Original date posted:2018-09-05
📝 Original message:On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Detailed explanation with code snippets:
>
> https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip]
This appears to be a repost of the broken scheme you posted about on
Bitcointalk, but then failed to respond to the response.
https://bitcointalk.org/index.php?topic=4973123.0
> The more I look into it and speak to professors about i, the more it seems "so trivial nobody really talks about it".
I think you might be falling into the trap of ignoring feedback you
don't like and and accepting that which sounds like "yea yea,
something like that".
Something "like that" does work: and is expressly and explicitly
anticipated by the BIP but to be both secure and functional requires
proper delineation (E.g. musig) _and_ interaction. What you're
proposing is continually vague. My best efforts at making sense of
what you've written indicate that either it's non-interactive and
not-actually functional at all, OR it's interactive and just a less
secure subset (no proper delinearization to prevent rogue key attacks)
of what we already propose.
When Poelstra suggests a CAS implementation he means something like
this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage This
provides for a method of communicating in both directions which is
completely precise.

2023-06-07 18:14:09

- reply

📅 Original date posted:2018-08-20
📝 Original message:Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
difficulty calculation was vulnerable to gaming with inaccurate
timestamps to massively increase the rate of block production beyond
the system's intentional design. It can be fixed with a soft-fork that
further constraints block timestamps, and a couple of proposals have
been floated along these lines.
I put a demonstration of timewarp early in the testnet3 chain to also
let people test mitigations against that. It pegs the difficulty way
down and then churned out blocks at the maximum rate that the median
time protocol rule allows.
I, and I assume others, haven't put a big priority into fixing this
vulnerability because it requires a majority hashrate and could easily
be blocked if someone started using it.
But there haven't been too many other network consensus rules going on
right now, and I believe at least several of the proposals suggested
are fully compatible with existing behaviour and only trigger in the
presence of exceptional circumstances-- e.g. a timewarp attack. So
the risk of deploying these mitigations would be minimal.
Before I dust off my old fix and perhaps prematurely cause fixation on
a particular approach, I thought it would be useful to ask the list if
anyone else was aware of a favourite backwards compatible timewarp fix
proposal they wanted to point out.
Cheers.

2023-06-07 18:13:25

- reply

📅 Original date posted:2018-07-03
📝 Original message:On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd <pete at petertodd.org> wrote:
> The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> about what the flag actually does.
I believe that making the signature replayable is 1:1 with omitting
the identification of the specific coin being spent from it.

2023-06-07 18:13:24

- reply

📅 Original date posted:2018-07-02
📝 Original message:On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
I know it seems kind of silly, but I think it's somewhat important
that the formal name of this flag is something like
"SIGHASH_REPLAY_VULNERABLE" or likewise or at least
"SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
insecure for traditional applications where a third party might pay to
an address a second time, and should only be used in special protocols
which make that kind of mistake unlikely. Otherwise, I'm worried
that wallets might start using this sighash because it simplifies
handling malleability without realizing that when a third party reuses
a script pubkey, completely outside of control of the wallet that uses
the flag, funds will be lost as soon as a troublemaker shows up (but
not, sadly, in testing). This sort of risk is magnified because the
third party address reuser has no way to know that this sighash flag
has (or will) be used with a particular scriptpubkey.
So, one could even argue that the possibility that someone might use
this flag means that it's generally unsafe to reuse a scriptpubkey. I
don't think the same argument applies for NONE or the single-bug
because they render even a single use insecure... The best mitigation
I can think of is defence in depth to ensure that anyone who uses this
sighash flag understands the consequences.

2023-06-07 18:13:09

- reply

📅 Original date posted:2018-06-21
📝 Original message:On Thu, Jun 21, 2018 at 7:56 PM, Peter D. Gray via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> PSBT is something we need, and has been missing from the ecosystem
> for a long time. Let's push this out and start talking about future
> versions after we learn from this one.
When you implement proposals that have little to no public discussion
about them you take the risk that your work needs to be changed when
other people do actually begin reviewing the work. It is incredibly
demoralizing as a designer and a reviewer to have proposals that were
put out for discussion show up implemented in things with these vested
interests then insisting that they not be refined further. I think
kind of handling is toxic to performing development in public.
Although it's silly enough that it won't happen, I think our industry
would be better off if there was a social norm that anytime someone
insists an unfinished proposal shouldn't be changed because they
already implemented it that the spec should _always_ be changed, in
order to discourage further instances of that conduct.

2023-06-07 18:12:39

- reply

📅 Original date posted:2018-06-02
📝 Original message:On Sat, Jun 2, 2018 at 10:02 PM, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Years of experience implementing wallets with BIP 37
pretty much us that all these filter things are a total waste of time.
BIP37 use is nearly dead on the network-- monitor your own nodes to
see the actual use of the filters: it's very low. I see under average
of 1 peer per day using it.
Moreover the primary complaint from users about BIP37 vs the
alternatives they're choosing over it (electrum and web wallets) is
that the sync time is too long-- something BIP158 doesn't improve.
So if we were going to go based on history we wouldn't bother with on
P2P at all. But I think the history's lesson here may mostly be an
accident, and that the the non-use of BIP37 is due more to the low
quality and/or abandoned status of most BIP37 implementing software,
rather than a fundamental lack of utility. Though maybe we do find
out that once someone bothers implementing a PIR based scanning
mechanism (as electrum has talked about on and off for a while now)
we'll lose another advantage.
BIP37 also got a number of things wrong-- what went into the filters
was a big element in that (causing massive pollution of matches due to
useless data), along with privacy etc. This kind of approach will
have the best chances if it doesn't repeat the mistakes... but also
it'll have the best chances if it has good security, and getting SPV-
equivalent security will require committing the filters, but
committing them is a big step because then the behaviour becomes
consensus normative-- it's worth spending a few months of extra
iteration getting the design as good as possible before doing that
(which is what we've been seeing lately).

2023-06-07 18:12:29

- reply

📅 Original date posted:2018-05-25
📝 Original message:On Fri, May 25, 2018 at 5:54 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
I did a rough analysis using Pieter's approximations on what
parameters minimizes the total communications for a lite wallet
scanning the chain and fetching a witnessless block whenever they get
a filter hit. For a wallet with 1000 keys and blocks of 1MB if the
number of entries in the is at least 5096 then M=784931 results in a
lower total data rate rate (FP blocks + filters) than M=1569861.
M=392465 (the optimal value for the rice parameter 18) is
communications is better if at least 10192 entries are set, and
M=196233 (optimal FP for rice 17) is better if at least 20384 entries
are set.
The prior filter set proposal is setting roughly 13300 entries per
full block, and I guestimate that the in+out scripts only ones are
setting about 7500 entries (if that actual number was in any of the
recent posts I missed it, I'm guessing based on jimpo's sizes graph).
The breakpoints are obviously different if the client is monitoring
for, say, 10,000 keys instead of 1000 but I think it generally makes
more sense to optimize for lower key counts since bigger users are
more likely to tolerate the additional bandwidth usage.
So I think that assuming that all-scripts inputs and outputs (but no
txids) are used and that my guess of 7500 bits set for that
configuration is roughly right, then M=1569861 and rice parameter 19
should be used.
The actual optimal FP rate for total data transferred won't be one
that gets the optimal rice coding efficiency, but since different
clients will be monitoring for different numbers of keys, it probably
makes sense to pick a parameter with optimal compression rather than
optimal-data-transfer-for-a-specific-key-count-- at least then we're
spending the least amount of filter bits per false positive rate,
whatever that rate is... if we can't be optimal at least we can be
efficient. :)

2023-06-07 18:12:29

- reply

📅 Original date posted:2018-05-25
📝 Original message:On Fri, May 25, 2018 at 6:42 PM, Gregory Maxwell <greg at xiph.org> wrote:
> configuration is roughly right, then M=1569861 and rice parameter 19
> should be used.
That should have been M=784931 B=19 ... paste error.

2023-06-07 18:12:26

- reply

📅 Original date posted:2018-05-23
📝 Original message:On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks everyone who commented so far, but let me clarify the context
> of this question first a bit more to avoid getting into the weeds too
> much.
My understanding of the question is this:
Are there any useful applications which would be impeded if a signing
party who could authorize an arbitrary transaction spending a coin had
the option to instead sign a delegation to a new script?
The reason this question is interesting to ask is because the obvious
answer is "no": since the signer(s) could have signed an arbitrary
transaction instead, being able to delegate is strictly less powerful.
Moreover, absent graftroot they could always "delegate" non-atomically
by spending the coin with the output being the delegated script that
they would have graftrooted instead.
Sometimes obvious answers have non-obvious counter examples, e.g.
Andrews points related to blindsigning are worth keeping in mind.

2023-06-07 18:12:25

- reply

📅 Original date posted:2018-05-23
📝 Original message:On Wed, May 23, 2018 at 10:06 PM, Natanael via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Consider for example a P2SH address for some fund, where you create a
> transaction in advance. Even if the parties involved in signing the
> transaction would agree (collude), the original intent of this particular
> P2SH address may be to hold the fund accountable by enforcing some given
> rules by script. To be able to circumvent the rules could break the purpose
> of the fund.
I am having a bit of difficulty understanding your example.
If graftroot were possible it would mean that the funds were paid to a
public key. That holder(s) of the corresponding private key could
sign without constraint, and so the accoutability you're expecting
wouldn't exist there regardless of graftroot.
I think maybe your example is only making the case that it should be
possible to send funds constrained by a script without a public key
ever existing at all. If so, I agree-- but that wasn't the question
here as I understood it.

2023-06-07 18:12:17

- reply

📅 Original date posted:2018-05-28
📝 Original message:Is there an application that requires watching for output scripts that
doesn't also require watching for input scrips (or, less efficiently,
input outpoints)?
Any of the wallet application that I'm aware of need to see coins
being spent as well as created, else they may try to spend already
spent coins. If we're not aware of any applications that wouldnt use
both, there isn't much reason to separate them and if input scripts
are used instead of input outpoints there is additional savings from
combining them (due to the same scripts being spent as were created in
the block-- due to reuse and chaining).
I still am of the belief, based on Matt's argument, that there is no
use for txid what-so-ever (instead just watch for an outpoint).
On Mon, May 28, 2018 at 6:28 PM, Tamas Blummer <tamas.blummer at gmail.com> wrote:
> Forgot to mention: The link I sent is to a branch that is patched to produce the filter stats.
> This is the main project and the BIP158 implementation: https://github.com/rust-bitcoin/rust-bitcoin-spv/blob/master/src/blockfilter.rs
>
> Tamas Blummer
>
>> On May 28, 2018, at 20:18, Tamas Blummer <tamas.blummer at gmail.com> wrote:
>>
>> Hi Jim,
>>
>> A “basic” combined filter would mean up to 0.5 GB filter data per month (with 100% segwith use). Considering that 1 GB is the usual data quota for an entry level mobile phone contract, this could be a too high barrier for adoption.
>>
>> I repeated your calculations and produced a slightly different graph that shows the fraction of cummulative filter size to cummulative blockchain size. This is less noisy but otherwise confirms your measurement.
>>
>> I think that the data supports separation of filters as a combined filter does not seem to come with significant savings. (basic size ~= txid + input points + output scripts sizes)
>>
>> My calculations are repeatable with:
>>
>> https://github.com/tamasblummer/rust-bitcoin-spv/blob/blockfilterstats/src/bin/blockfilterstats.rs
>>
>> that is using a Rust implementation of an SPV client built on top of other libraries we work on in the rust-bitcoin GitHub community (https://github.com/rust-bitcoin). Yes, this is a shameles plug for the project hoping to attract more developer.
>>
>> Tamas Blummer
>>
>>
>> <filters.png>
>>
>>> On May 24, 2018, at 05:48, Jim Posen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Greg, I've attached a graph including the input scripts.
>>>
>>> In the top graph, we can see how the input script filter compares to the input outpoint filter. It is definitely smaller as a result of address reuse. The bottom graph shows the ratio over time of combining the input prev script and output script filters vs keeping them separate. In more recent blocks, it appears that there are decreasing savings.
>>>
>>
>

2023-06-07 18:12:15

- reply

📅 Original date posted:2018-05-23
📝 Original message:Any chance you could add a graph of input-scripts (instead of input outpoints)?
On Wed, May 23, 2018 at 7:38 AM, Jim Posen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> So I checked filter sizes (as a proportion of block size) for each of the
> sub-filters. The graph is attached.
>
> As interpretation, the first ~120,000 blocks are so small that the
> Golomb-Rice coding can't compress the filters that well, which is why the
> filter sizes are so high proportional to the block size. Except for the
> input filter, because the coinbase input is skipped, so many of them have 0
> elements. But after block 120,000 or so, the filter compression converges
> pretty quickly to near the optimal value. The encouraging thing here is that
> if you look at the ratio of the combined size of the separated filters vs
> the size of a filter containing all of them (currently known as the basic
> filter), they are pretty much the same size. The mean of the ratio between
> them after block 150,000 is 99.4%. So basically, not much compression
> efficiently is lost by separating the basic filter into sub-filters.
>
> On Tue, May 22, 2018 at 5:42 PM, Jim Posen <jim.posen at gmail.com> wrote:
>>>
>>> My suggestion was to advertise a bitfield for each filter type the node
>>> serves,
>>> where the bitfield indicates what elements are part of the filters. This
>>> essentially
>>> removes the notion of decided filter types and instead leaves the
>>> decision to
>>> full-nodes.
>>
>>
>> I think it makes more sense to construct entirely separate filters for the
>> different types of elements and allow clients to download only the ones they
>> care about. If there are enough elements per filter, the compression ratio
>> shouldn't be much worse by splitting them up. This prevents the exponential
>> blowup in the number of filters that you mention, Johan, and it works nicely
>> with service bits for advertising different filter types independently.
>>
>> So if we created three separate filter types, one for output scripts, one
>> for input outpoints, and one for TXIDs, each signaled with a separate
>> service bit, are people good with that? Or do you think there shouldn't be a
>> TXID filter at all, Matt? I didn't include the option of a prev output
>> script filter or rolling that into the block output script filter because it
>> changes the security model (cannot be proven to be correct/incorrect
>> succinctly).
>>
>> Then there's the question of whether to separate or combine the headers.
>> I'd lean towards keeping them separate because it's simpler that way.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:12:12

- reply

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 4:59 PM, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> Yea I generally would really prefer something like that but it
> significantly complicates the download logic - currently clients can
> easily cross-check [...] Maybe
> there is some other reasonable download logic to replace it with, however.
I think lite clients cross checking is something which very likely
will never be implemented by anyone, and probably not stay working
(due to under-usage) if it is implemented. This thought is driven by
three things (1) the bandwidth overhead of performing the check, (2)
thinking about the network-interacting-state-machine complexity of it,
and by the multitude of sanity checks that lite clients already don't
implement (e.g. when a lite client noticed a split tip it could ask
peers for the respective blocks and check at least the stateless
checks, but none has ever done that), and...
(3) that kind of checking would be moot if the filters were committed
and validated... and the commitment would be both much simpler to
check for lite clients and provide much stronger protection against
malicious peers.
My expectation is that eventually one of these filter-map designs
would become committed-- not after we already had it deployed and had
worked out the design to the n-th generation (just as your proposed
revisions are doing to the initial proposal), but eventually.
Also, even without this change clients can still do that "are multiple
peers telling me the same thing or different things" kind of checking,
which I expect is the strongest testing we'd actually see them
implement absent a commitment.

2023-06-07 18:12:12

- reply

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 8:19 PM, Jim Posen <jim.posen at gmail.com> wrote:
> In my opinion, it's overly pessimistic to design the protocol in an insecure
> way because some light clients historically have taken shortcuts.
Any non-commited form is inherently insecure. A nearby network
attacker (or eclipse attacker) or whatnot can moot whatever kind of
comparisons you make, and non-comparison based validation doesn't seem
like it would be useful without mooting all the bandwidth improvements
unless I'm missing something.
It isn't a question of 'some lite clients' -- I am aware of no
implementation of these kinds of measures in any cryptocurrency ever.
The same kind of comparison to the block could have been done with
BIP37 filtering, but no one has implemented that. (similarly, the
whitepaper suggests doing that for all network rules when a
disagreement has been seen, though that isn't practical for all
network rules it could be done for many of them-- but again no
implementation or AFAIK any interest in implementing that)
> If the
> protocol can provide clients the option of getting additional security, it
> should.
Sure, but at what cost? And "additional" while nice doesn't
necessarily translate into a meaningful increase in delivered security
for any particular application.
I think we might be speaking too generally here.
What I'm suggesting would still allow a lite client to verify that
multiple parties are offering the same map for a given block (by
asking them for the map hash). It would still allow a future
commitment so that lite client could verify that the hashpower they're
hearing from agrees that the map they got is the correct corresponding
map for the block. It would still allow downloading a block and
verifying that all the outpoints in the block were included. So still
a lot better than BIP37.
What it would not permit is for a lite client to download a whole
block and completely verify the filter (they could only tell if the
filter at least told them about all the outputs in the block, but if
extra bits were set or inputs were omitted, they couldn't tell).
But in exchange the filters for a given FP rate would be probably
about half the current size (actual measurements would be needed
because the figure depends on much scriptpubkey reuse there is, it
probably could be anywhere between 1/3 and 2/3rd). In some
applications it would likely have better anonymity properties as well,
because a client that always filters for both an output and and input
as distinct items (and then leaks matches by fetching blocks) is more
distinguishable.
I think this trade-off is at leat worth considering because if you
always verify by downloading you wash out the bandwidth gains, strong
verification will eventually need a commitment in any case. A client
can still partially verify, and can still multi-party comparison
verify. ... and a big reduction in filter bandwidth
Monitoring inputs by scriptPubkey vs input-txid also has a massive
advantage for parallel filtering: You can usually known your pubkeys
well in advance, but if you have to change what you're watching block
N+1 for based on the txids that paid you in N you can't filter them
in parallel.
> On the general topic, Peter makes a good point that in many cases filtering
> by txid of spending transaction may be preferable to filtering by outpoint
> spend, which has the nice benefit that there are obviously fewer txs in a
> block than txins. This wouldn't work for malleable transactions though.
I think Peter missed Matt's point that you can monitor for a specific
transaction's confirmation by monitoring for any of the outpoints that
transaction contains. Because the txid commits to the outpoints there
shouldn't be any case where the txid is knowable but (an) outpoint is
not. Removal of the txid and monitoring for any one of the outputs
should be a strict reduction in the false positive rate for a given
filter size (the filter will contain strictly fewer elements and the
client will match for the same (or usually, fewer) number).
I _think_ dropping txids as matt suggests is an obvious win that costs
nothing. Replacing inputs with scripts as I suggested has some
trade-offs.

2023-06-07 18:12:11

- reply

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 3:25 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe (1) could be skipped entirely - there is almost no reason why
> you'd not be able to filter for, eg, the set of output scripts in a
> transaction you know about
I think this is convincing for the txids themselves.
What about also making input prevouts filter based on the scriptpubkey
being _spent_? Layering wise in the processing it's a bit ugly, but
if you validated the block you have the data needed.
This would eliminate the multiple data type mixing entirely.

2023-06-07 18:12:11

- reply

2023-06-07 18:10:29

- reply

📅 Original date posted:2018-02-05
📝 Original message:On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant <bitcoin-dev at rgrant.org> wrote:
> Am I reading correctly that this allows unilateral key rotation (to a
> previously unknown key), without invalidating the interests of other
> parties in the existing multisig (or even requiring any on-chain
> transaction), at the cost of storing the signed delegation?
Yes, though I'd avoid the word rotation because as you note it doesn't
invalidate the interests of any key, the original setup remains able
to sign. You could allow a new key of yours (plus everyone else) to
sign, assuming the other parties agree... but the old one could also
still sign.

2023-06-07 18:10:29

- reply

📅 Original date posted:2018-02-05
📝 Original message:In my post on taproot I showed a simple commitment scheme for scripts
that is very efficient that there exists some collection of pubkeys
(like an M-of-N or even N-of-N) whos authorization is an acceptable
alternative to whatever other conditions we might want to impose on a
coin. If this holds then when spends happen via the plain signature
path the existence of the alternative is never revealed, providing
privacy with improved efficiency compared to not being private at all.
Taproot suffers from a limitation that it only natively provides for
one alternative. Trees or cascades of taproots can be done, but they
have less privacy and efficiency than just a single level. E.g. a tree
commitment has overhead that grows with the log of the number of
alternatives.
However, under the taproot assumption-- that there exists some
monotone function on plain public keys and nothing else that is
sufficient to authorize a transaction-- we can do even better.
With graftroot, the participants establish a threshold key, optionally
with a taproot alternative, just as they do with taproot. At any
time, they can delegate their ability to sign to a surrogate script by
signing that script (and just the script) with their taproot key, and
sharing that delegation with whomever they choose. Later, when it
comes time to spend the coin, if the signers aren't available and the
script must be used, the redeeming party does whatever is required to
satisfy the script (e.g. provides their own signature and a timelock,
or whatnot) and presents that information along with the signer's
signature of the script.
The result is that instead of allowing only one alternative an
unlimited number of alternatives can be provided. All are executed
with equal efficiency to a single alternative, and the number of them
is hidden without overhead. Alternatives can be provided for existing
coins too, without requiring they get moved-- movement is only
required to destroy the ability to use alternatives by changing keys.
Allowing this kind of delegation makes sense because the same signers
could have just signed the transaction outright. The new script simply
stands in for them, if they're not available or cooperating. No
special conditions are needed outside of the surrogate script on when
the surrogate is allowed, because they can be written inside the
surrogate.
We've discussed delegation in script back to at least 2012-- with
speculation that enabling it may have been an original motivation
behind codeseperator. ... but these design discussions have gotten
mired in how to express and connect the levels of delegation. But the
case where delegation is accomplished with a simple unconditional
signature is an especially simple case, and under the taproot
assumption the only case that is ever needed.
A naive implementation of this idea requires a complete signature
every time a surrogate is used, which means 64 bytes of data (assuming
128 bit ECC). This is higher overhead than taproot.
However, the non-interactive schnorr aggregation trick[1] can be
applied to merge the S values of all graftroots and signatures in a
transaction into a single aggregate. With this approach only a single
R value for each graftroot need be published, lowering the overhead to
~32 bytes-- the same as taproot. This has a side benefit of binding
the published grafts to a particular transaction, which might help
avoid some screwups.
In cases where the taproot assumption doesn't hold, taproot can still
be used by setting the public key to a NUMS point, which preserves
privacy (e.g. you can't distinguish txn where the key could never have
been used.) A similar thing can be done for graftroot if the
signature is not a proof of knowledge (commits to the public key): you
select the signature in a NUMS manner, and then recover the applicable
public key. Though this can't be done if the signature is a PoK, and
it's probably a pretty good idea to make it a PoK.
The primary limitation of this approach compared to taproot
alternatives and trees is that it requires that anyone who wants to
make use of a particular surrogate to interact with the participants
and store the resulting signature because a single party couldn't
compute it again on their own from public data. For trees and taproot
alternatives, the alternatives can be setup without any interaction
with the participants. The primary advantage is that it scales to any
number of alternatives with small constant overhead, can be delegated
after the fact, and can still be spent by the participants without
overhead.
Summarizing: A coin's authorizing contract is decomposed into a top
level OR between a monotone function of pubkeys (such as N of N) and
any number of arbitrary surrogate scripts which are acceptable
authorizations. A key aggregate (see [2]) is formed, and is used to
sign each of the the surrogates. Participants save these signatures.
Later, when it comes time to spend the coin, if the pubkey holders are
unwilling or unavailable, the spender presents and satisfies the
relevant surrogate along with it's signature R-value and
non-interactively aggregates the S-value into the transaction's
overall aggregate signature. The result is 0-overhead if the signers
cooperate, or ~32-byte overhead (plus the script) if they don't. This
avoids the log() overhead of tree based schemes, and allows delegation
to take place before or after the fact but requires storage. The
potential for unexpected surrogate replay if keys are reused in
foolish ways also needs to be kept in mind, though it may be somewhat
mitigated by aggregation. The existence of unused surrogates is
completely hidden.
I believe this general design is simple and powerful enough that it
avoids the rathole that earlier delegation discussions have suffered.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html
And the secure construction at:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014308.html
[2] https://eprint.iacr.org/2018/068

2023-06-07 18:10:24

- reply

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> For check locktime, the median of the last 11 blocks is used as an improved
> indicator of what the actual real time is. Again, it assumes that a
> majority of the miners are honest.
It would be more accurate to say that the median is not used for
improved accuracy but to mitigate a consensus incompatibility:
If the block's own timestamp were used for nlocktime and time based
nlocks were common on the network each miner would maximize their fee
income by setting the value as high as they could get away with. What
concerned us wasn't so much that this would make the times less
accurate (though it would) but rather that it would create an
incentive for a runaway situation that could harm network stability
(e.g. with all miners cranking times against the 2hr window, then
creating pressure for miners to accept further and further in the
future; each responding to his own local incentives).
This incentive incompatibility could have been addressed e.g. by using
the prior block's time, but since the protocol doesn't require times
to be monotone (and for good reason!) the simple implementation of
that wouldn't have been a soft-fork. The 11 block MTP worked out
nicely because the protocol already required new times to be larger
than that.
The timestamps in Bitcoin aren't intended to be particularly accurate.
They're used only for controlling the difficulty, and the adjustment
window is large enough that there isn't much distortion that can be
accomplished there. It's not clear to me that much better can really
be done... if there were tighter time requirements in the protocol
miners would address them by running NTP which as an _astounding_ lack
of security in terms of how it is commonly deployed. As far as I
know, I'm the only person whos ever mined blocks with their own
stratum 1 time source.
If times need to be accurate Bitcoin would need to use a rather
different design (e.g. each block would commit to the observation time
of the prior N blocks, and an iterative algorithm would solve for each
blocks time and each miners local offset).
IIRC open-timestamp calendar servers provide more precise
time-stamping under the assumption that the calendar server is
behaving correctly.

2023-06-07 18:10:18

- reply

📅 Original date posted:2018-01-27
📝 Original message:Not incentive compatible. Miners would prefer to include transactions
paying fees via alternative mechanisms (anyone can spend outputs,
direct pay to miner outputs, or completely out of band), if they even
paid attention to internal fees at all they would give a lot more
weight to direct payment fees. Users would accordingly pay much lower
fees if they used these alternatives instead of directly, so the
equlibrium state is almost everyone bypassing. Bypass fee mechenisms
have been supported by miners since 2011 too, so it isn't just
conjecture.
On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Miners can fill their blocks with transactions paying very high fees at no
> cost because they get the fees back to themselves. They can do this for
> different purposes, like trying to increase the recommended fee. Here I
> propose a backwards-compatible solution to this problem.
>
> The solution would be to reward the fees of the current block to the miner
> of the next block (or X blocks after the current one). That way, if a miner
> floods its own block with very high fee transactions, those fees are no
> longer given back to itself, but to the miner of future blocks which could
> potentially be anyone. Flooding blocks with fake txs is now discouraged.
> However, filling blocks with real transactions paying real fees is still
> encouraged because you could be the one to mine the block that would claim
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be to
> enforce miners to set an anyone-can-spend output in the coinbase transaction
> of the block (by adding this as a rule for verifying new blocks). The miner
> of 100 blocks after the current one can add a secondary transaction spending
> this block's anyone-can-spend coinbase transaction (due to the coinbase
> needing 100 blocks to mature) and thus claiming the funds. This way, the
> block reward of a block X is always transferred to the miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that extra
> transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won’t get any
> reward for mining blocks for a period of 100 blocks. They could choose to
> power off the mining equipment for maintenance or to save power over that
> period, so the hashrate could drop temporarily. However, if the hashrate
> drops too much, blocks would take much longer to mine, and miners wouldn’t
> want that either since they want to go through those 100 reward-less blocks
> as soon as possible so they can start getting rewards from mining again.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:10:15

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, Jan 24, 2018 at 3:50 AM, Артём Литвинович via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Greetings.
>
> I wanted to ask what was the rationale behind still having both public
> key and signature in Segwit witness?
>
> As is known for a while, the public key can be derived from the
> signature and a quadrant byte, a trick that is successfully used both
> in Bitcoin message signing algorithm and in Ethereum transaction
> signatures. The later in particular suggests that this is a perfectly
> functional and secure alternative.
> Leaving out the public key would have saved 33 bytes per signature,
> which is quite a lot.
>
> So, the question is - was there a good reason to do it the old way
> (security, performance, privacy, something else?), or was it something
> that haven't been thought of/considered at the time?
It is slow to verify, incompatible with batch validation, doesn't save
space if hashing isn't used, and is potentially patent encumbered.

2023-06-07 18:10:08

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns <aj at erisian.com.au> wrote:
> Is this really intended as paying directly to a pubkey, instead of a
> pubkey hash?
>
> If so, isn't that a step backwards with regard to resistance to quantum
> attacks against ECC?
You're reading too much into a description of the idea. It's not a BIP
or a spec; I tried to provide enough details to make the general idea
concrete. I didn't dive into details or optimizations (for example,
you can use this with a "no EC redemption path" by special casing
empty C as the point at infinity, and you'd have an output that was
indistinguishable until spend... yadda yadda).
Considering the considerable level of address reuse -- I recall prior
stats that a majority of circulating funds are on addresses that had
previously been used, on top of the general race limitations-- I am
now dubious to the idea that hashing provides any kind of meaningful
quantum resistance and somewhat regret introducing that meme to the
space in the first place. If we considered quantum resistance a
meaningful concern we should address that specifically. --- so I
don't think that should be a factor that drives a decision here.
When collision resistance is needed (as I think it clearly is for
taproot) you don't get a space savings in the txout from hashing, so
there is an argument to use the public key directly at least... but
it's worth considering. Direct SPK use is also adventitious for being
able to efficiently ZKP over the UTXO set, e.g. for private solvency
proofs, but it isn't absolutely mandatory for that (one can hash
inside the proof, but it's slower).

2023-06-07 18:10:08

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns <aj at erisian.com.au> wrote:
> Hmm, at least people can choose not to reuse addresses currently --
> if everyone were using taproot and that didn't involve hashing the key,
Can you show me a model of quantum computation that is conjectured to
be able to solve the discrete log problem but which would take longer
than fractions of a second to do so? Quantum computation has to occur
within the coherence lifetime of the system.
> way for individuals to hedge against quantum attacks in case they're ever feasible, at least that I can see (well, without moving their funds out of bitcoin anyway)?
By using scriptpubkeys with actual security against quantum computers
instead of snake-oil.
> (It seems like using the point at infinity wouldn't work because
Indeed, that doesn't work.
> that when quantum attacks start approaching feasibility. If funds are
> being held in reused addresses over the long term, that would be more
They are. But I don't believe that is relevant; the attacker would
simply steal the coins on spend.

2023-06-07 18:10:07

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The issue with that approach without support for the privacy-encouraging
> wrapper proposed by Greg here is that it encourages adoption halfway and
> destroys a lot of the value of the apparent-script monoculture for privacy
> preservation. Greg's proposal here doesn't change the format of any specific
> MAST implementation, but instead adds the privacy wrapper that I always felt
> was missing in existing proposals, without any real additional overhead in
> many use-cases!
>
> Indeed, permissionless innovation is important, but the huge advantage of
> providing the privacy wrapper by default here is absolutely massive to the
> ecosystem and should not be handwaved away for vague possibly-advantages.
Even if to someone who didn't care about anyone's privacy at all,
non-taproot is simply inefficient. In the (I argue) overwhelmingly
common case of everyone-agrees simple hash based branching requires a
30% overhead to communicate the commitment to the untaken branch (and
worse in the case of extensive aggregation). I don't think an
argument can be sustained in favor of that kind of communications
overhead.

2023-06-07 18:10:05

- reply

📅 Original date posted:2018-01-22
📝 Original message:Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
areas: efficiency and privacy. Efficiency because unexecuted forks of
a script can avoid ever hitting the chain, and privacy because hiding
unexecuted code leaves scripts indistinguishable to the extent that
their only differences are in the unexecuted parts.
As Mark Friedenbach and others have pointed out before it is almost
always the case that interesting scripts have a logical top level
branch which allows satisfaction of the contract with nothing other
than a signature by all parties. Other branches would only be used
where some participant is failing to cooperate. More strongly stated,
I believe that _any_ contract with a fixed finite participant set
upfront can be and should be represented as an OR between an N-of-N
and whatever more complex contract you might want to represent.
One point that comes up while talking about merkelized scripts is can
we go about making fancier contract use cases as indistinguishable as
possible from the most common and boring payments. Otherwise, if the
anonymity set of fancy usage is only other fancy usage it may not be
very large in practice. One suggestion has been that ordinary
checksig-only scripts should include a dummy branch for the rest of
the tree (e.g. a random value hash), making it look like there are
potentially alternative rules when there aren't really. The negative
side of this is an additional 32-byte overhead for the overwhelmingly
common case which doesn't need it. I think the privacy gains are
worth doing such a thing, but different people reason differently
about these trade-offs.
It turns out, however, that there is no need to make a trade-off. The
special case of a top level "threshold-signature OR
arbitrary-conditions" can be made indistinguishable from a normal
one-party signature, with no overhead at all, with a special
delegating CHECKSIG which I call Taproot.
Let's say we want to create a coin that can be redeemed by either
Alice && Bob or by CSV-timelock && Bob.
Alice has public A, Bob has pubkey B.
We compute the 2-of-2 aggregate key C = A + B. (Simplified; to
protect against rogue key attacks you may want to use the MuSig key
aggregation function [1])
We form our timelock script S = "<timeout> OP_CSV OP_DROP B OP_CHECKSIGVERIFY"
Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
(This is the attack hardened pay-to-contract construction described in [2])
Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
Now Alice and Bob-- assuming they are both online and agree about the
resolution of their contract-- can jointly form a 2 of 2 signature for
P, and spend as if it were a payment to a single party (one of them
just needs to add H(C||S) to their private key).
Alternatively, the Taproot consensus rules would allow this script to
be satisfied by someone who provides the network with C (the original
combined pubkey), S, and does whatever S requires-- e.g. passes the
CSV check and provides Bob's signature. With this information the
network can verify that C + H(C||S) == P.
So in the all-sign case there is zero overhead; and no one can tell
that the contract alternative exists. In the alternative redemption
branch the only overhead is revealing the original combined pubkey
and, of course, the existence of the contract is made public.
This composes just fine with whatever other merkelized script system
we might care to use, as the S can be whatever kind of data we want,
including the root of some tree.
My example shows 2-of-2 but it works the same for any number of
participants (and with setup interaction any threshold of
participants, so long as you don't mind an inability to tell which
members signed off).
The verification computational complexity of signature path is
obviously the same as any other plain signature (since its
indistinguishable). Verification of the branch redemption requires a
hash and a multiplication with a constant point which is strictly more
efficient than a signature verification and could be efficiently fused
into batch signature validation.
The nearest competitor to this idea that I can come up with would
supporting a simple delegation where the output can be spent by the
named key, or a spending transaction could provide a script along with
a signature of that script by the named key, delegating control to the
signed script. Before paying into that escrow Alice/Bob would
construct this signature. This idea is equally efficient in the common
case, but larger and slower to verify in the alternative spend case.
Setting up the signature requires additional interaction between
participants and the resulting signature must be durably stored and
couldn't just be recomputed using single-party information.
I believe this construction will allow the largest possible anonymity
set for fixed party smart contracts by making them look like the
simplest possible payments. It accomplishes this without any overhead
in the common case, invoking any sketchy or impractical techniques,
requiring extra rounds of interaction between contract participants,
and without requiring the durable storage of other data.
[1] https://eprint.iacr.org/2018/068
[2] https://blockstream.com/sidechains.pdf Appendix A

2023-06-07 18:10:00

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.
It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.
The number of ways n choose m combines grows exponentially, and you
only need to get close enough over the right value so that you're
paying excess fees equal or less than the cost of the change (which
should include the current cost output itself as well as estimated
cost of the future signature to spend it).
Achow101 and Murch have code to implement an efficient algorithm for
finding these solutions for Bitcoin core which will hopefully get in
soon.

2023-06-07 18:09:58

- reply

📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Interesting. I didn't think about this before, but it seems like bip125 is
> rather incentive incompatible right now? If we're assuming a competitive
> mempool, it really doesn't seem generally rational to accept a replacement
> transaction of a lower fee rate.
BIP125 replacement requires that the fee rate increases. The text of
the BIP document is written in a confusing way that doesn't make this
clear.

2023-06-07 18:09:53

- reply

📅 Original date posted:2018-01-18
📝 Original message:A common question when discussing newer more efficient pubkey types--
like signature aggregation or even just segwit-- is "will this thing
make the spending of already existing outputs more efficient", which
unfortunately gets an answer of No because the redemption instructions
for existing outputs have already been set, and don't incorporate
these new features.
This is good news in that no one ends up being forced to expose their
own funds to new cryptosystems whos security they may not trust. When
sigagg is deployed, for example, any cryptographic risk in it is borne
by people who opted into using it.
Lets imagine though that segwit-with-sigagg has been long deployed,
widely used, and is more or less universally accepted as at least as
good as an old P2PKH.
In that case, it might be plausible to include in a hardfork a
consensus rule that lets someone spend scriptPubkey's matching
specific templates as though they were an alternative template. So
then an idiomatic P2PKH or perhaps even a P2SH-multisig could be spent
as though it used the analogous p2w-sigagg script.
The main limitation is that there is some risk of breaking the
security assumptions of some complicated external protocol e.g. that
assumed that having a schnorr oracle for a key wouldn't let you spend
coins connected to that key. This seems like a pretty contrived
concern to me however, and it's one that can largely be addressed by
ample communication in advance. (E.g. discouraging the creation of
excessively fragile things like that, and finding out if any exist so
they can be worked around).
Am I missing any other arguments?

2023-06-07 18:09:30

- reply

📅 Original date posted:2018-01-10
📝 Original message:On Wed, Jan 10, 2018 at 8:28 PM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> On 09/01/18 16:12, Pavol Rusnak via bitcoin-dev wrote:
>> On 09/01/18 00:47, Gregory Maxwell wrote:
>>> Have you considered using blind host-delegated KDFs, where the KDF
>>> runs on the user's computer instead of the hardware wallet, but the
>>> computer doesn't learn anything about they keys?
>>
>> Any examples of these?
Yes, this scheme.
https://bitcointalk.org/index.php?topic=311000.msg3342217#msg3342217
> Actually, scratch that. HW wallet would not know whether the host
> computer is lying or not. The computer would not learn about the keys,
> but still could be malicious and provide invalid result. Is that correct?
I believe that can be avoided by having the computer do somewhat more
work and checking the consistency after the fact.
(or for decode time, having a check value under the encryption...)

2023-06-07 18:09:28

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Mon, Jan 8, 2018 at 12:39 PM, Pavol Rusnak <stick at satoshilabs.com> wrote:
> On 08/01/18 05:22, Gregory Maxwell wrote:
>>> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>
> Hey Gregory!
>
> Thanks for looking into the scheme. I appreciate your time!
>
>> This specification forces the key being used through a one way
>> function, -- so you cannot take a pre-existing key and encode it with
>> this scheme.
>
> Originally, we used a bi-directional function to be able to encode and
> decode the key in both directions using the passphrase. We stretched the
> passphrase using KDF and then applied AES or other symmetric cipher
>
> We found the following (theoretical) problem:
>
> If an attacker has knowledge of few words from the beginning of shares,
> they are able to reconstruct the beginning of the master secret and if
> the size of the reconstruced master secret is bigger then the cipher
> blocksize (for block ciphers; for stream ciphers 1 bit is enough), then
> they can reconstruct the beginning of the seed.
>
> Can you find a scheme which does not have this problem? Or you think
> this problem is not worth solving?
You can use a large block cipher. E.g. CMC cipher mode.
Though I am doubtful that this is a very relevant concern: What
consequence is it if someone with partial access to more than a
threshold of the shares can recover part of the seed? This doesn't
seem like a very interesting threat. A large block mode would be
more complete, but this isn't something that would keep me up at night
in the slightest.
Perhaps I'm missing something, -- but the only real attack I see here
is that a enduser mistakenly shows the first or couple words of all
their shares on national television or what not... but doing so would
not really harm their security unless they showed almost all of them,
and in that case an attacker could simply search the remaining couple
words.
Also, if we are going to assume that users will leak parts, the
mnemonic encoding ends up being pretty bad... since just leaking a
letter or two of each word would quite likely give the whole thing
away.
In any case, to whatever extent partial leaks are a concern, using a
large block cipher would be the obvious approach.
> Yes. We want this to be possible to be computed on TREZOR-like devices
> on boot, similarly how we compute BIP39 on boot right now.
Under this constraint it might be arguably to just eliminate the KDF.
I think it provides false security and makes the implementation much
more complicated.
Have you considered using blind host-delegated KDFs, where the KDF
runs on the user's computer instead of the hardware wallet, but the
computer doesn't learn anything about they keys?
> Again, this is by design and it is main point why plausible deniability
> is achieved both in BIP39 and SLIP39. If we used a different
> construction we'd loose plausible deniability.
I don't believe you can justify this design decision with any kind of
rigorous threat model.
The probability that a user loses funds because they have at some
point recovered with the wrong key and don't know it would almost
certainly dwarf the probability that the user face some kind of
movie-plot threat where someone is attempting to forcibly extract a
key and yet somehow has no information about the user's actual
wallet-- through, for example, leaked data on the users computers, the
users past payments to online accounts, or through a compromise or
lawful order to satoshilab's web service which the users send private
information to-- which would allow them to determine the key they were
given was not correct.
But even there, given the weak level of false input rejection that you
have used (16 bits), it would be fairly straight forward to grind out
an alternative passphrase that also passed the test. Might that not
make for a better compromise?
Another thing to consider is that the main advantage of SSS over
ordinary computational secret sharing is that it's possible to
generate alternative shares to an sub-threshold set of primary shares
that decodes to arbitrarily selected alternative data-- but it seems
the proposal makes no use of this fact.
>> It
>> is again, unversioned-- so it kinda of seems like it is intentionally
>> constructed in a way that will prevent interoperable use, since the
>> lack of versioning was a primary complaint from other perspective
>> users. Of course, it fine if you want to make a trezor only thing,
>> but why bother BIPing something that was not intended for
>> interoperability? Even for a single vendor spec the lack of
>> versioning seems to make things harder to support new key-related
>> features such as segwit.
>
> This is argument I keep having all the time.
>
> Suppose we'd introduce a version to encode PBKDF2 rounds or even
> different KDFs. We'll end up with different SLIP39 mnemonics, but they
> will not be compatible among implementations (because TREZOR can only up
> to 100.000 rounds of PBKDF2 and does not support Argon2 at all, while
> other desktop implementation would rather use memory-hard Argon2).
>
> My gut feeling is that this would lead to WORSE interoperability, not
> better. Look at BIP32 for example. There are lots of wallet that claim
> they are BIP32 compatible, but in reality they use different paths, so
> they are not compatible. BIP32 is a good standard, but in reality
> "BIP32-compatible" does not mean anything, whereas when you say the
> wallet is "BIP44-compatible" you can be sure the migration path works.
The end result is no better-- I think. If you compromise
functionality or security (e.g. pretextual KDF) because your product
doesn't yet support -- say, aggregate signatures-- or won't ever
support a strong KDF; then other software will just not be
interoperable. In cases were you won't ever support it, that doesn't
matter-- but presumably you would later support new signature styles
and the loss of interoperability would potentially be gratitious.
That said, I'm generally skeptical of key interoperability to begin
with. Wallets can't share keys unless their functionality is
identical, half-interoperability can lead to funds loss. Identical
functionality would mean constraining to the least common denominator.
But even if we exclude cross vendor interoperability entirely,
wouldn't you want your next version of your firmware to be able to
support new and old key styles (e.g. aggregate signatures vs plain
segwit) without having to define a whole new encoding?
> Originally, we wanted to use 16-bit of CRC32 for checksum, but after the
> discussion with Daan Sprenkels we were suggested to change this for
> cryptographically strong function. The argument was that CRC32 contains
> less entropy and mixing high-entropy data (secret) with low-entropy data
> (checksum) is not a good idea.
That sounds like a kind of hand-wave and cargo cult argument-- pleas
be more specific, because that just sounds like amateur block cipher
design.
There isn't any difference in "entropy" in either of these cases.
As an aside, using "n bits of a longer CRC" usually results in a low
quality code for error detection similar to using a cryptographic
hash.
> Also, there is an argument between a checksum and ECC. We discussed that
> ECC might not be a good idea, because it helps the attacker to compute
> missing information, while we only want to check for integrity. Also the
Not meaningfully more than the truncated cryptographic hash.
The best possible code of that length would allow you to list decode
to around two errors with a lot of computation.
With the cryptographic hash the attacker need only check the 2^28
two-error candidates to do exactly the same thing.
So the attacker there is no real difference-- he can brute force
search to the same radius as correction would allow, but for the
honest users and software the probability of undetected error is
greater. Similarly, while 2^28 operations is nothing to an attacker,
if user software wants to use the correction for error hinting,
running a hash 2^28 times would lead to a somewhat unfriendly user
experience so non-attack tools would be pretty unlikely to implement
it.

2023-06-07 18:09:25

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Sun, Jan 7, 2018 at 3:16 PM, Pavol Rusnak via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 05/01/18 14:58, nullius via bitcoin-dev wrote:
> I am currently drafting a new standard[1] which will allow also Shamir
> Secret Scheme Splitting and there we disallow usage of a custom wordlist
> in order to eradicate this mess. Will try to push this as BIP too once
> we get it to the point we are OK with the contents.
>
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
This specification forces the key being used through a one way
function, -- so you cannot take a pre-existing key and encode it with
this scheme. The KDF it specifies is unconfigurable and fairly weak
(20000xhmac-sha2-- which can be cracked at about 0.7M passwords a
second on a single motherboard GPU cracker). The construction also
will silently result in the user getting a different private key if
they enter the wrong passphrase-- which could lead to funds loss. It
is again, unversioned-- so it kinda of seems like it is intentionally
constructed in a way that will prevent interoperable use, since the
lack of versioning was a primary complaint from other perspective
users. Of course, it fine if you want to make a trezor only thing,
but why bother BIPing something that was not intended for
interoperability? Even for a single vendor spec the lack of
versioning seems to make things harder to support new key-related
features such as segwit.
The 16-bit "checksum" based on sha2 seems pretty poor since basing
small checksums on a cryptographic hash results in a fairly poor
checksum that is surprisingly likely to accept an errored string. Your
wordlist is 10 bits and you have much less than 1023*10 bits of input,
so you could easily have a 20 bit code (two words) which guaranteed
that up to two errored words would always be detected, and probably
could choose one which catches three words much more often 1:2^20
(sipa's crc tools can help find codes like this).
The metadata seems to make fairly little affordance to help users
avoid accidentally mixing shares from distinct sharings of the same
key. Is it the idea that this is the only likely cause of a checksum
error? (1:2^16 chance of silently returning the wrong key seems kinda
bad). -- I'm not sure much could be done here, though, since
additional payload is precious.
As an aside, your specification might want to give some better advice
about the SSS since my experience virtually everyone gets it wrong in
ways that degrade or destroy its properties e.g. many fail to generate
the additional coefficients of the polynominal randomly which results
in insecurity (see armory for an example). Oh, also, I believe it is
normally refereed to as "SSS" (three S)-- four S is the name of a
linux program for secret sharing.
I'm happy to see that there is no obvious way to abuse this one as a
brainwallet scheme!

2023-06-07 18:08:59

- reply

📅 Original date posted:2017-12-21
📝 Original message:Personally, I'm pulling out the champaign that market behaviour is
indeed producing activity levels that can pay for security without
inflation, and also producing fee paying backlogs needed to stabilize
consensus progress as the subsidy declines.
I'd also personally prefer to pay lower fees-- current levels even
challenge my old comparison with wire transfer costs-- but we should
look most strongly at difficult to forge market signals rather than
just claims-- segwit usage gives us a pretty good indicator since most
users would get a 50-70% fee reduction without even considering the
second order effects from increased capacity.
As Jameson Lopp notes, more can be done for education though-- perhaps
that market signal isn't efficient yet. But we should get it there.
But even independently of segwit we can also look at other inefficient
transaction styles: uncompressed keys, unconfirmed chaining instead of
send many batching, fee overpayment, etc... and the message there is
similar.
I've also seen some evidence that a portion of the current high rate
congestion is contrived traffic. To the extent that it's true there
also should be some relief there soon as the funding for that runs
out, in addition to expected traffic patterns, difficulty changes,
etc.
On Thu, Dec 21, 2017 at 9:30 PM, Melvin Carvalho via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I asked adam back at hcpp how the block chain would be secured in the long
> term, once the reward goes away. The base idea has always been that fees
> would replace the block reward.
>
> At that time fees were approximately 10% of the block reward, but have now
> reached 45%, with 50% potentially being crossed soon
>
> https://fork.lol/reward/feepct
>
> While this bodes well for the long term security of the coin, I think there
> is some legitimate concern that the fee per tx is prohibitive for some use
> cases, at this point in the adoption curve.
>
> Observations of segwit adoption show around 10% at this point
>
> http://segwit.party/charts/
>
> Watching the mempool shows that the congestion is at a peak, though it's
> quite possible this will come down over the long weekend. I wonder if this
> is of concern to some.
>
> https://dedi.jochen-hoenicke.de/queue/more/#24h
>
> I thought these data points may be of interest and are mainly FYI. Though
> if further discussion is deemed appropriate, it would be interesting to hear
> thoughts.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:08:50

- reply

📅 Original date posted:2017-12-18
📝 Original message:Because it would make no meaningful difference now, and if you are not
going to check the history there are much more efficient things to
do-- like not transfer it at all.
On Mon, Dec 18, 2017 at 8:32 AM, Kalle Rosenbaum via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear list,
>
> I find it hard to understand why a full node that does initial block
> download also must download witnesses if they are going to skip
> verification anyway. If my full node skips signature verification for
> blocks earlier than X, it seems the reasons for downloading the
> witnesses for those blocks are:
>
> * to be able to send witnesses to other nodes.
>
> * to verify the witness root hash of the blocks
>
> I suppose that it's important to verify the witness root hash because
> a bad peer may send me invalid witnesses during initial block
> download, and if I don't verify that the witness root hash actually
> commits to them, I will get banned by peers requesting the blocks from
> me because I send them garbage.
>
> So both the reasons above (there may be more that I don't know about)
> are actually the same reason: To be able to send witnesses to others
> without getting banned.
>
> What if a node could chose not to download witnesses and thus chose to
> send only witnessless blocks to peers. Let's call these nodes
> witnessless nodes. Note that witnessless nodes are only witnessless
> for blocks up to X. Everything after X is fully verified.
>
> Witnessless nodes would be able to sync faster because it needs to
> download less data to calculate their UTXO set. They would therefore
> more quickly be able to provide full service to SPV wallets and its
> local wallets as well as serving blocks to other witnessless nodes
> with same or higher assumevalid block. For witnessless nodes with
> lower assumevalid they can serve at least some blocks. It could also
> serve blocks to non-segwit nodes.
>
> Do witnessless nodes risk dividing the network in two parts, one
> witnessless and one with full nodes, with few connections between the
> parts?
>
> So basically, what are the reasons not to implement witnessless
> nodes?
>
> Thank you,
> /Kalle
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:07:52

- reply

📅 Original date posted:2017-11-21
📝 Original message:With the way pruning works today my expirence is that virtually no one
sets any parameter other than the minimum, though even with that set a
few more blocks can be available.
In the future we would set further pruning identifying bits, with
those set node would (obviously) answer for their blocks. An earlier
version of this BIP had such a bit defined but it appeared that we
lacked sufficient experience from practice to usefully specify what
height it should mean exactly and the proposals sounded like they
would likely interact poorly with other future proposals, so we
thought it better to delay defining any additional levels for the
time.
Part of your concern is mooted by the logistics of actually fetching
those additional blocks. At least in the network today we have a
superabundance of nodes that serve anything, to handle them being rare
will require very different approaches than we have now. We have no
reason to believe that "like the pruning thing but more blocks" is
actually all that useful-- and some reason to expect that its not:
once you go back more than a handful of weeks the probably of fetching
get pretty close to uniform, those fetches are only be newly
initializing nodes that need all the blocks.
On Tue, Nov 21, 2017 at 2:03 PM, Sjors Provoost via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I came across the proposed Bitcoin Core implementation of BIP159 [0] in this PR [1]. The goal is to allow pruned nodes to "serve a limited number of historical blocks" (as opposed to none at all).
>
> It contains a counter-measure for peer fingerprinting. I'm trying to understand how that impacts extendibility.
>
>> Peers may have different prune depths (depending on the peers configuration,
>> disk space, etc.) which can result in a fingerprinting weakness (finding the
>> prune depth through getdata requests). NODE_NETWORK_LIMITED
>> supporting peers SHOULD avoid leaking the prune depth and therefore
>> not serve blocks deeper then the signaled NODE_NETWORK_LIMITED
>> thresholds.
>
> This means pruned nodes can only serve the last 288 blocks:
>
>> If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 day
>
> As the blockchain keeps growing there will be ever more pruned nodes (perhaps offset by new nodes with more storage). Although a strict improvement over todays situation, it seems a bit wasteful to have a node with 10-100 GB of storage only be able to share the most recent 288 blocks.
>
> It would be nice if a future extension of this BIP allows more flexibility. To limit the ability to fingerprint nodes, we could limit the number of choices to e.g. 288 + 1000 * 2^n. That yields only 8 possibilities at the current chain size. A slightly better formula could take into account typical hard drive size increments, leaving enough space for the OS and other data. Node operators could opt-in to this if they think the increased fingerprint risk outweighs their desire to share archived blocks.
>
> I can also imagine - but not implement :-) - a future scenario where nodes prune a random subset of their chain, meaning that even nodes with little storage can be of help during Initial Blockchain Download (IBD) of other nodes.
>
>
> How would such extension be signaled for? Would we need a whole new version bit?
>
> Would upgraded nodes need a new message type to communicate the chosen prune depth? Or can that information tag along some existing message?
>
> Jonas Schnelli pointed out on the Github discussion that waiting for BIP150 would be appropriate. Can you explain how this is related? Although I can see why whitelisted peers can be exempted from the anti-fingerprinting measure, I would not want to restrict it to just those.
>
>
> Some minor suggestions for improving the BIP itself:
> * add link to mailinglist discussion(s) in reference section
> * explain that 288 is not just the minimum limit for Bitcoin Core, but also the bulk of traffic (as I understand from earlier discussion [2])
>
> Cheers,
>
> Sjors
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
> [1] https://github.com/bitcoin/bitcoin/pull/10387
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.html#14315
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:07:44

- reply

📅 Original date posted:2017-11-14
📝 Original message:On Tue, Nov 14, 2017 at 10:38 AM, Gregory Maxwell <greg at xiph.org> wrote:
> I think it's still fair to say that ring-in and tree-in approaches
> (monero, and zcash) are fundamentally less scalable than
> CT+valueshuffle, but more private-- though given observations of Zcash
While I'm enumerating private transaction topologies there is fourth
one I'm aware of (most closely related to ring-in):
take N inputs, write >= N outputs, where some coins are spent and
replaced with a new output, or an encrypted dummy... and other coins
are simply reencrypted in a way that their owner can still decode.
Provide a proof that shows you did this faithfully. So this one avoids
the spent coins list by being able to malleiate the inputs.
We never previously found an efficient way to construct that one in a
plain DL setting, but it's probably possible w/ bulletproofs, at least
for some definition of efficient.

2023-06-07 18:07:43

- reply

📅 Original date posted:2017-11-14
📝 Original message:On Tue, Nov 14, 2017 at 9:11 AM, Peter Todd <pete at petertodd.org> wrote:
> I _strongly_ disagree with this statement and urge you to remove it from the
> paper.
I very strongly disagree with your strong disagreement.
> The worst-case risk of undetected inflation leading to the destruction of a
> currency is an easily quantified risk: at worst any given participant loses
> whatever they have invested in that currency. While unfortunate, this isn't a
> unique or unexpected risk: cryptocurrencies regularly lose 50% - or even 90% -
> of their value due to fickle markets alone. But cryptocurrency owners shrug
> these risks off. After all, it's just money, and diversification is an easy way
> to mitigate that risk.
>
> But a privacy break? For many users _that_ threatens their very freedom,
> something that's difficult to even put a price on.
Its important that people know and understand what properties a system has.
Perhaps one distinction you miss is that perfectly hiding systems
don't even exist in practice: I would take a bet that no software on
your system that you can use with other people actually implements a
perfectly hiding protocol (much less find on most other people's
system system :)).
In the case of practical use with CT perfect hiding is destroyed by
scalability-- the obvious construction is a stealth address like one
where a DH public key is in the address and that is used to scan for
your payments against a nonce pubkey in the transactions. The
existence of that mechanism destroys perfect hiding. No scheme that
can be scanned using an asymmetric key is going to provide perfect
hiding.
Now, perhaps what you'd like is a system which is not perfect hiding
but where the hiding rests on less "risky" assumptions. That is
something that can plausibly be constructed, but it's not itself
incompatible with unconditional soundness.
As referenced in the paper, there is also the possibility of having a
your cake and eating it too-- switch commitments for example allow
having computational-hiding-depending-on-the-hardness-of-inverting-hashes
(which I would argue is functionally as good as perfect hiding, esp
since hiding is ultimately limited by the asymmetric crypto used for
discovery) and yet it retains an option to upgrade or block spending
via unsound mechanisms in the event of a crypto break.
> Furthermore, the risk of inflation is a risk that's easily avoided:
Sounds like you are assuming that you know when there is a problem, if
you do then the switch commitments scheme works and doesn't require
any selling of anything. Selling also has the problem that everyone
would want to do it at once if there was a concern; this would not
have good effects. :) Without switch commitments though, you are just
hosed. And you cannot have something like switch commitments without
abandoning perfect hiding ( though you get hiding which is good enough
(tm), as mentioned above).
On Tue, Nov 14, 2017 at 10:07 AM, Peter Todd <pete at petertodd.org> wrote:
> Re: the unprunable accumulators, that doesn't need to be an inherent property
> of Zcash/Monero style systems.
>
> It'd be quite feasible to use accumulator epochs and either make unspent coins
> in a previous epoch unspendable after some expiry time is reached - allowing
Miners to reduce coin supply, enhancing the value of their own
holdings, by simply not letting near-expiry ones get spent...
(This can be partially mediated by constructing proofs to hide if a
coins in near expiration or not.)
> or make use of a merkelized key-value scheme with transaction provided proofs to shift the costs of
> maintaining the accumulator to wallets.
Yes, that they can do-- though with the trade-offs inherent in that.
It is worse than what you were imagining in the Bitcoin case because
you cannot use one or two time-ordered trees, the spent coins list
needs search-insertion; so maintaining it over time is harder. :( The
single time ordered tree trick doesn't work because you can't mutate
the entries without blowing anonymity.
I think it's still fair to say that ring-in and tree-in approaches
(monero, and zcash) are fundamentally less scalable than
CT+valueshuffle, but more private-- though given observations of Zcash
behavior perhaps not that much more private. With the right smart
tricks the scalablity loss might be more inconvenient than fatal, but
they're still a loss even if they're one that makes for a good
tradeoff.
As an aside, you shouldn't see Monero as entirely distinct now that
we're talking about a framework which is fully general: Extending
this to a traceable 1 of N input for monero is simple-- and will add
size log() in the number of ring inputs with good constant factors.
One could also store inputs in a hash tree, and then have a
bulletproof that verified membership in the tree. This would provide
tree-in style transactions with proofs that grow with the log() of the
size of the tree (and a spent coins accumulator); the challenge there
would be choosing a hash function that had a compact representation in
the arithmetic circuit so that the constant factors aren't terrible.
Effectively that's what bulletproofs does: It takes a general scheme
for ZKP of arbitrary computation, which could implement a range proof
by opening the commitments (e.g. a circuit for EC point scalar
multiply) and checking the value, and optimizes it to handle the
commitments more directly. If you're free to choose the hash function
there may be a way to make a hash tree check ultra efficient inside
the proof, in which case this work could implement a tree-in scheme
like zcash-- but with larger proofs and slower verification in
exchange for much better crypto assumptions and no trusted setup.
This is part of what I meant by it opening up "many other interesting
applications".
But as above, I think that the interactive-sparse-in (CJ) has its own
attractiveness, even though it is not the strongest for privacy.

2023-06-07 18:07:31

- reply

📅 Original date posted:2017-11-02
📝 Original message:On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> algorithm. Bitcoin itself might need to hard fork to employ a similar
> algorithm. It's about as good as they come because it followed the
This is the bitcoin development mailing list, not the "give free
review to the obviously defective proposals of adversarial competing
systems" mailing list. Your posting is off-topic.

2023-06-07 18:07:19

- reply

📅 Original date posted:2017-10-30
📝 Original message:On Mon, Oct 30, 2017 at 9:42 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I admittedly haven't had a chance to read the paper in full details, but I
> was curious how you propose dealing with "jets" in something like Bitcoin.
> AFAIU, other similar systems are left doing hard-forks to reduce the
> sigops/weight/fee-cost of transactions every time they want to add useful
> optimized drop-ins. For obvious reasons, this seems rather impractical and a
> potentially critical barrier to adoption of such optimized drop-ins, which I
> imagine would be required to do any new cryptographic algorithms due to the
> significant fee cost of interpreting such things.
For some framing-- I think we're still a long way off from proposing
something like this in Bitcoin, and _how_ it's ultimately proposed is
an open question.
There are many ways to use simplicity, for an extreme example: one
could define a collection of high level operations and combinators at
the level of things in Bitcoin Script (op_sha256, op_equal, op_cat,
etc.) and make an interpreter that implements these operations as
discounted jets and ONLY these operations at all.
At that point you have a system which is functionally like Bitcoin
Script-- with the same performance characteristics-- but with a pretty
much perfectly rigorous formal specification and which is highly
amenable to the formal analysis of smart contracts written in it.
At the other extreme, you expose a full on Bitmachine and allow
arbitrary simplicity-- But this is probably slow enough to not be
very useful. Simplicity itself is so simple that it doesn't natively
have a concept of a _bit_, library code programs the concept of a bit,
then the concept of a half adder ... and so on. As a result a
completely unjetted implementation is slow (actually remarkably fast
considering that it's effectively interpreting a circuit constructed
from pure logic).
The most useful way of using it would probably be in-between: a good
collection of high level functions, and mid-level functions (e.g.
arithmetic and string operations) making a wide space of useful but
general software both possible and high performance. But to get there
we need enough experience with it to know what the requisite
collection of operations would be.
One challenge is that I don't think we have a clear mental model for
how nominal validation costs are allowed to be before there is a
negative impact. It's probably safe to assume 'pretty darn nominal'
is a requirement, but there is still a lot that can be done within
that envelope.
As far as consensus discounted jets goes:
>From my perspective there are three related ideas around this:
Is a particular script-root jetted or not in an implementation?
-- In and of itself this is not of consensus consequence; esp.
because a major design feature of simplicity is that it should be
possible using to prove that an optimized C implementation of a
simplicity program is complete and correct (using VST+COQ).
Is a particular script-root 'standard and known' in the P2P network:
-- This means that you can skip communicating it when sending
witnesses to peers; but this is something that could be negotiated on
a peer by peer basis-- like compressing transactions, and isn't at all
consensus normative.
Is a particular jet discounted and what are the discounts:
-- This is inherently a consensus question; as the bitmachine costing
for a program is consensus normative (assuming that you allow
arbitrary simplicity code at all).
A script-versioning like mechanism can provide for a straight-forward
way to upgrade discounted cost tables in a compatible way-- if you're
running old software that doesn't have the required jets to justify a
particular discount collection -- well that's okay, you won't validate
those scripts at all. (so they'll be super fast for you!)
Another potential tool is the idea of sunsetting cost limits that
sunset; e.g. after N years, the limits go away with an assumption that
updated limits have been softforked in that ativate at that time and
themselves expire in N years. Old software would become slower
validating due to newly discounted code they lack jets for... but
would continue validating (at least until they run out of performance
headroom).
This is theoretically attractive in a number of regards, but
unfortunately I think our industry hasn't shown sufficient maturity
about engineering tradeoffs to make this a politically viable choice
in the mid-term-- I known I'm personally uncomfortable with the
outspokenness of parties that hold positions which I think can fairly
be summarized "We should remove all limits and if the system crashes
and burns as a result, we'll just make a new one! YOLO.". But it's
interesting to think about in the long term.
There are also hybrid approaches where you can imagine this decision
being made by node operators, e.g. continuing to validate code that
exceeds your effort limits on probabilistic and best effort basis;
even more attractive if there were a protocol for efficiently showing
others that an operation had an invalid witness. Though there is a lot
to explore about the brittleness to partitioning that comes from any
expectation that you'd learn about invalid updates by exception.
In any case, these are all options that exist completely independently
of simplicity. I think we should think of simplicity as a rigorous
base which we could _potentially_ use to build whatever future
direction of script we like out of... by itself it doesn't mandate a
particular depth or level of adoption.
And for the moment it's still also mostly just a base-- I don't
anticipate typical smart contracting end users programming directly w/
simplicity even if Bitcoin did support arbitrary simplicity-- I
expect they'd program in user friendly domain specific languages which
are formally tied to their implementations in simplicity that allow-
but do not force- closed loop formal reasoning about their contracts
all the way from their high level business rules straight through to
the machine code implementing the interpreter(s) that run in the
network.
But to get there we'll have to prove in practice that this is actually
workable. We have some evidence that it is, e.g. Roconnor's SHA2
implementation in simplicity is proven to implement the same function
that a C implementation implements (via the compcert formalization of
C). but there will need to be more.

2023-06-07 18:06:23

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen; there
When Pieter and I were working on Bech32 we specifically designed for
error correcting codes that had good performance for longer lengths
than we technically needed specifically to incorporate things like
dates and explicit amounts.
(explicit amounts so that typos and bit flips in amounts displayed or
in memory couldn't result in sending the wrong amount)
But we also thought that also adding those features at the same time
would retard adoption-- both due to debating over the encodings and
because handling would result in different software requirements and
layering, so you couldn't just drop them in.
Doubly unfortunately, people have even deployed BIP173 already (prior
to it even having much peer review or being adopted by its own
authors), so I think a rethink now wouldn't be timely (I mean as a
replacement to BIP173 rather than an additional format). :(
But I do support the idea.
One thing to keep in mind is that address format linked fields are
most efficient if they're multiples of 5 bits. Perhaps use 1 bit to
indicate an embedded amount and 19 bits of 1 day precision, resulting
in a 1435 year span.
Keep in mind that high precision of the expiration times is asking the
sender to have a higher precision of idea of the time, date only is
kinda nice. I think shorter expiration times are unlikely to be
useful due to clock skew-- you can't assume a signer has any access to
the Bitcoin network at all.

2023-06-07 18:06:23

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Fri, Sep 29, 2017 at 1:50 AM, Peter Todd <pete at petertodd.org> wrote:
> What do you mean by "an embedded amount"?
I ask you to pay 1 Bitcoin to bc1blahblah.
...you make a typo, or a poorly placed cosmic ray switches it in your
ram to bc1blohblahbah. No problem, it'll get rejected. (even if the
cosmic ray happens just before signing... if the software is robust
it'll reencode from the signed transaction and check against the
original input.
But if instead the typo converts it to 2 Bitcoins or the cosmic ray
converts it to 2.34217728... the payment will happily go through,
assuming your wallet had enough, and you're stuck asking me to refund
you the excess.
Sure, you can put amounts in URIs and whatnot, but they're not error
protected... so there will always be unprotected poritons where a
glitch can radically change the amount.
In many cases you know exactly what amount you're asking for when you
generate an address. There isn't any reason the amount couldn't be
covered by the addresses checksum in those cases.
There are a couple ways of doing that... e.g. adding it explicitly,
where the checksum includes it but not the address itself; so it
errors out if you get it wrong. But this is unfortunate because it
can't tell you the expected amount when its wrong. Another way would
be to embed the amount in the address, and then the software can tell
you the amount the address was expecting and not let you proceed until
they match.

2023-06-07 18:06:22

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 7:35 PM, Chris Priest via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A better solution is to just have the sending wallet check to see if the
> address you are about to send to has been used before.
So every wallet needs all the addresses ever used and a fast index into them?
This seems pretty harmful for scalability.
> they first consult the address expiration service,
So you propose a best practice that requires contacting a service and
telling them what addresses you're planning on paying? This seems
pretty harmful for privacy.

2023-06-07 18:05:56

- reply

📅 Original date posted:2017-09-12
📝 Original message:On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher cannot report to alt-coins which have a different
> policy.
I agree with your post, but wanted to make a point of clarification on
the use of "can't".
If someone wants to report something to the Bitcoin project we're
obviously at your mercy in how we handle it. If we disagree on the
handling approach we may try to talk you into a different position
based with a rational judgement based on our experience (or, if
justified, advice that we're likely to whine about your approach in
public). But if you still want to go also report a common issue to
something else with a different approach then you can. Even our
ire/whining can be avoided by a sincere effort to communicate and give
us an opportunity to mitigate harm.
That said, as mentioned, we'd encourage otherwise for issues that
warrant it-- and I think with cause enough that the reporter will
agree. So that is a different kind of "cant". :)
In Bitcoin the overwhelming majority of serious issues we've
encountered have been found by people I'd consider 'inside the
project' (frequent regular contributors who aren't seriously involved
in other things). That hasn't been so obviously the case for other
open source projects that I've been involved with; but Bitcoin is
pretty good from a basic security perspective and finding additional
issues often requires specialized experience that few people outside
of the project regulars have (though some, like Sergio, clearly do).
I know through direct experience that both Mozilla and the Chrome
project fix _serious_ (like RCE bugs) issues based on internal
discoveries which they do not make public (apparently ever), though
they may coordinate with distributors on some of them. (Some of
these experiences are also why I give the advice that you should not
consider any computer which has ever run a web browser to be strongly
secure...)

2023-06-07 18:05:52

- reply

📅 Original date posted:2017-09-11
📝 Original message:On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
>
> E.g.
> Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
> Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
> DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unscheduled inflation of
> coins)
> Compromising Node performance (Various node-specific DoS attacks)
>
> Should have different disclosure policies, IMO
This assumes the states are discernible. They often aren't cleanly.
You obviously know how bad it is in the best case, but the worst could
be much worse.
I've multiple time seen a hard to exploit issue turn out to be trivial
when you find the right trick, or a minor dos issue turn our to far
more serious.
Simple performance bugs, expertly deployed, can potentially be used to
carve up the network--- miner A and exchange B go in one partition,
everyone else in another.. and doublespend.
And so on. So while I absolutely do agree that different things
should and can be handled differently, it is not always so clear cut.
It's prudent to treat things as more severe than you know them to be.
In fact, someone pointed out to me a major amplifier of the
utxo-memory attack thing today that Bitcoin Core narrowly dodges which
would have made it very easy to exploit against some users, and which
it seems no one previously considered.
I also think it's somewhat incorrect to call this thread anything
about disclosure, this thread is not about disclosure. Disclosure is
when you tell the vendor. This thread is about publication and that
has very different implications. Publication is when you're sure
you've told the prospective attackers.

2023-06-07 18:04:20

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
That might be your impression, then you've misunderstood what I
intended-- What I wrote was carefully constructed as a personal view
of how things might work out. It never claimed to be a a project
roadmap. Though as usual, I work hard to propose things that I believe
will be successful... and people are free to adopt what they want.
And to the extent that it got taken that way I think it was an error
and that it has harmed progress in our community; and created more
confusion about control vs collaboration.
With perfect hindsight I wouldn't have posted it; especially since
we've learned that the demand for increased capacity from many people
was potentially less than completely earnest. (The whole, can't double
capacity until we quadruple it thing...)
> As to your specific complaints, I have addressed both the security model
and the concept of mining centralization on this list in the recent
past.
I don't agree that you have; but for the purpose of this thread
doesn't really matter if I (specifically) do or don't agree. It's an
objective truth that many people do not yet believe these concerns
have been addressed.
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
That Adam asked me to write publish a new "roadmap" for Bitcoin as
you've done here, with particular features and descriptions, which I
declined; and explained why I didn't believe that was the right
approach. And Adam worked with you on the document, and provided
content for it (which I then recognized in the post).
Set aside what you know to be true for a moment and consider how this
might look to an outsider who found out about it. It could look a
like Blockstream was trying to influence the direction of Bitcoin by
laundering proposals through an apparently unaffiliated third party.
Doubly so considering who participated in your drafting and who didn't
(more below).
I don't think in actuality you did anything remotely improper
(ill-advised, perhaps, since your goal to speak for developers but you
didn't speak to them, IMO--) but I think transparency is essential to
avoid any appearance of misconduct.
> But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
I did--
As Bryan pointed out... with the exception of the intro and end and a
couple sentences in the middle my entire response to your post, with
the position on "roadmaps" was written a long time ago, specifically
to complain about and argue against that particular approach.
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
I think you may be mistaking a roadmap with "communications"-- people
taking about research they are exploring is great! and we should have
more of it. But like with RedHat and kernel features, we can't really
roadmap things that are unresourced and currently just unimplemented
exploration or test code-- without seeing things which are more or
less done the community can't rightfully decide if they'd want to
support something or not. Perhaps they'll be good things perhaps
awful-- the devil is in the details, and until an effort is fairly
mature, you cannot see the details.
There have, for example, been signature aggregation proposals in the
past that required address reuse (could only aggregate if they're
reused). I would strongly oppose such a proposal, and I hope everyone
else here would too. So if I were a third party looking at your
message, rather than the person who initially proposed the agg sig
thing you're talking about, I wouldn't know if I could love it or hate
it yet; and probably couldn't be expected to have much of an opinion
on it until there is a BIP and/or example implementation.
To the extent that a roadmap differs from communications in general,
it is in that it also implies things that none of us can promise
except for our own efforts; Completion of implementations, success of
experiments, adoption-- basically assuming a level of top down control
that doesn't exist in a wide public collaboration.
One of the great challenges in our industry is that we don't have
rings of communication: We don't have much in the way of semi-experts
to communicate to semi-semi-experts to communicate to media pundits to
communicate to the unwashed masses-- at each level closing the
inferential gap and explaining things in terms the audience
understands. We don't have things like LWN. We'll get there, but it
it took the Linux world decades to build to what it has now. I think
various forces in the industry work against us-- e.g. we lose a mot of
mid tier technical people to the allure of striking it rich printing
money in their own altcoins.
It might be attractive to try to end-run the slow development
appropriate web of reliable communications by deploying high authority
edicts, but it ultimately can't work because it doesn't map to how
things are accomplished, not in true collaborative open source, and
certainly not in an effort whos value comes substantially from
decentralization. Doing so, I fear, creates a false understanding of
authority.
(It's a common misunderstanding, for example, that people do what I
want (for example); but in reality, I just try to avoid wasting my
time advocating things that I don't think other people are already
going to do; :) otherwise, if _I_ want something done I've got to do
it myself or horse trade for it, just like anyone else.)
One of the great things about general communications is anyone can do
it. Of course, unless they're talking about their own work, they
can't promise any of it will be completely-- but that is always true.
If someone wants some guarantee about work, they have to be willing
to get it done themselves (and, of course, if it's a consensus
feature-- that much is necessary, but still not sufficient to get a
guarantee).
[from your other reply]
>> A fine intention, but I've checked with many of the top contributors
>> and it sounds like the only regular developer you spoke with was
>> Luke-Jr. Next time you seek to represent someone you might want to
>> try talking to them!
>
> That is false. I could provide a list of names but I'm really not sure
> what would be gained as result. You yourself admit that it is an
> excellent list of research, almost all which you support directly.
>
> So I think your only real objection is that I didn't talk to you
> specifically.
Come now, this is needlessly insulting. I would have made the same
comment if you had talked to me because you didn't talk to most/all of
Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the
people doing most of the work of actually building the system. Before
making that comment I went and checked with people to find out if only
I was left out. Talking to Adam (who isn't involved in the project)
and Luke-jr (who is but is well known for frustratingly extreme
minority positions and also contracts for Blockstream sometimes) isn't
a great approach for the stated goal of speaking for developers!

2023-06-07 18:04:14

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Tue, Jul 11, 2017 at 8:18 PM, Paul Sztorc via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I wrote the roadmap to try to be representative of a Core / developer
> position.
A fine intention, but I've checked with many of the top contributors
and it sounds like the only regular developer you spoke with was
Luke-Jr. Next time you seek to represent someone you might want to
try talking to them!
> I am philosophically against hard forks, but HFs were in the end
> of the previous roadmap so I felt it should stay. And, I felt that if I
I think the project is not philosophically against hardforks, at least
not in an absolute sense.
Part of the reason they were discussed in the capacity document was to
make it clear that I wasn't, and to invite other project members to
expose disagreement (though I'd mostly checked in advance...)
But these recently proposed ultra-hasty highly contentious changes,
that seem to be being suggested on shorter and shorter timeframes; I
do think the project is actually opposed to those in a very strong
sense.
But if you were instead to talk about things like fixing timewarp,
recovering header bits, etc. It would clearly be the other way.
At least at the moment computers and bandwidth are improving; I don't
think any regular developers are opposed to hardforks that change
capacity well tech improvements and protocol improvements have made it
obviously not much of a trade-off.
Personally, I wish the project had previously adopted a license that
requires derived works to not accept any block the derived-from work
wouldn't accept for at least two years, or otherwise the derivative
has to be clearly labeled not-bitcoin. :P
In any case, I think it's safe to say that people's opinions on
hardforks are complicated. And all the smoke right now with unusually
poorly executed proposals probably clouds clear thinking.

2023-06-07 18:04:03

- reply

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 11:27 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Larger block sizes is not likely to have a meaningful impact on fee pressure.
> Any expectations that do not match the reality are merely misguided, and
> should not be a basis for changing Bitcoin.
I think it's very clear that they will in the very short term
(https://anduck.net/bitcoin/fees/4320_blocks.php note the rate drops
when demand falls below supply). But I agree with you if you mean a
somewhat longer term e.g. a year out.

2023-06-07 18:04:02

- reply

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 10:44 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is not a hard fork, simply adding a new limit is a soft fork. You
> appear to be confused - as originally written, AFAIR, Jeff's btc1 branch
> did not increase the block size, your specification here matches that
> original change, and does not increase the block size.
Indeed, their code previously did not increase the blocksize but it
was adjusted at the last minute to do so-- so it may actually do that
now. Because they don't appear to have implemented any tests for it, I
wouldn't be too surprised if it still didn't work at all but also
wouldn't be surprised if it did.
You are correct that the specification text appears to refer to the
prior change that did not. (In my response I just assumed that it
meant what they actually did-- good catch).

2023-06-07 18:04:02

- reply

📅 Original date posted:2017-07-07
📝 Original message:On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
I'm happy to see that someone has begun writing a specification. But I
am appalled to see one just being written now for change it's authors
expect to be irreversibly applied to the network in less than 30 days.
The timeline of this proposal is recklessly short to such an extreme
level that we have never, to the best of my knowledge, seen a prior
proposal so hasty. Nowhere does this specification provide
justification or assurance that this is at all safe. The time line of
it violates the most minimal of responsible engineering practices, by
being shorter than even a fast development and release candidate
timeframe. This proposal carries an extreme risk for parties to lose
money due to transaction reversals at two distinct points in time and
provides no proposed countermeasures to avoid these losses.
The proposal adds another gratuitous limit to the system: A maximum
transaction size where none existed before, yet this limit is almost
certainly too small to prevent actual DOS attacks while it is also
technically larger than any transaction that can be included today
(the largest possible transaction today is 1mb minus the block
overheads). The maximum resource usage for maliciously crafted 1MB
transaction is enormous and permitting two of them greatly exacerbates
the existing vulnerability.
> Assuming the current transaction pattern is replicated in a 2 MB plain-sized block that is 100% filled with transactions, then the witness-serialized block would occupy 3.6 MB
But in a worst case the result would be 8MB, which this document fails
to mention.
> This is considered safe by many users, companies, miners and academics [2].
The claim that the document's [2] says that these increases are "safe"
is incorrect and is a matter which has been previously corrected by
the authors of the document:
https://www.reddit.com/r/btc/comments/626ud7/coauthor_of_the_paper_that_blockstream_core_keep/dflrshg/
.
The cited paper does an approximate best case analysis considering
only a couple of risk factors (in particular, block relay time, but
ignoring durability to dos attacks, robustness against state
intervention, and initial synchronization time) and concluded that 4MB
was the largest they could argue was safe. The paper goes on to then
argue that even if you crank Bitcoin's parameters to the maximum in
those dimensions that it doesn't result in a truly meaningful increase
in scalablity-- in effect, it's a weak argument against your proposal
and ones like it.
> Deploy a modified BIP91 to activate Segwit. The only modification is that the signal "segsignal" is replaced by "segwit2x".
This means that BIP-91 and your proposal are indistinguishable on the
network, because the string "segsignal" is merely a variable name used
in the software.
> If segwit2x (BIP91 signal) activates at block N,
The proposal is unable to distinguish itself from BIP-91. Does this
mean if segwit2x or BIP91 activates ?
> This reduces the fee pressure on users and companies creating on-chain transactions, matching market expectations and preventing further market disruption
Considering that we just spent the whole weekend with the mempool
having ~1 block or less worth of transactions most of the time, it
seems highly likely that just activating segwit will substantially
disrupt the fee market; to say nothing for the further doubling that
isn't even tempered by new wallet adoptions. There seems to be no
consideration given to avoiding this disruption and preventing further
emergency events when the new capacity is eventually used and software
is again left unprepared for having to pay market fees.
> and buy time for more comprehensive solutions to be developed and tested
In effect, the document admits that it isn't a solution that
meaningfully improves the scale or scalablity but rather it's just a
bailout to temporarily lower/negate transaction fees. It doesn't seem
to make any argument (or even acknowledge) that the risks and
disruption are worth its benefit, and it exacerbates those risks by
being the product of a closed process and having a timeline shorter
than basically any software update for production software (much less
the timeframe for any consensus update previously). Kudos for being
frank here, but it's not exactly selling itself.
It seems to me that the document doesn't really even make an effort to
justify the bailout at all and don't explain how it will result in
anything except an endless series of additional fee bailouts.
Moreover, it doesn't discuss any remediation against the replay
exposure that the proposed hardfork is sure to create. ( I can
guarantee to you, I will not adopt this hardfork; especially given
that is has been made completely clear that the terms of it were set
in its closed door meetings and the input of non-supporters was not
welcome. )

2023-06-07 18:03:56

- reply

📅 Original date posted:2017-07-05
📝 Original message:On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've already opened a PR almost 2 weeks ago to do this and fix the other
> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>
> It just needs your ACK to merge.
These proposals for gratuitous orphaning are reckless and coersive.
We have a professional obligation to first do no harm, and amplifying
orphaning which can otherwise easily be avoided violates it.
It is not anyones position to decide who does and doesn't need to be
"woken up" with avoidable finical harm, nor is it any of our right to
do so at the risk of monetary losses by any and all users users from
the resulting network instability.
It's one thing to argue that some disruption is strictly needed for
the sake of advancement, it's another to see yourself fit as judge,
jury, and executioner to any that does not jump at your command.
(which is exactly the tone I and at least some others extract from
your advocacy of these changes and similar activity around BIP148).
I for one oppose those changes strongly.
> Not having a mandatory signal turned out to be a serious bug in BIP 9,
I have seen no evidence or case for this.

2023-06-07 18:03:39

- reply

📅 Original date posted:2017-06-28
📝 Original message:On Wed, Jun 28, 2017 at 12:37 AM, Chris Stewart via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A new block rule is added which requires that the miner's coinbase reward be
> at index 0 in the coinbase transaction's output vector.
This is an absurd restriction-- I hope it was not your intent to
directly ban P2Pool and probably any other form of decentralized or
less centralized mining pooling... but thats what doing that does.
> It also fixes the witness commitment output to be at index 1 of the coinbase transaction's output vector.
This removes important flexibility that was intentionally preserved.
What happens when an additional commitment is needed for bitcoin?
must some sidechain be irreparably destroyed? looks like it in your
proposal.
> For instance, the mimblewimble sidechain could correspond to index 2 of the vector outputs on the coinbase transaction.
And what happens if index 1 isn't present? if index 35 is used must
there be 34 dummy outputs?
> This op code looks into the coinbase transaction's output vector at the given index (which is derived from the sidechain id) and checks to see if the hash in the block matches the hash inside of the BRIBEVERIFY progra
This is not monotone/reorg safe. It means that the output coins (if
any) are not equivalently fungible with other bitcoins (for, e.g. 100
blocks) because if there is a reorg this transaction cannot be
restored to the chain. It's also impure and not compatible with
caching, which would be unfortunate and slow block propagation.

2023-06-07 18:03:33

- reply

📅 Original date posted:2017-06-20
📝 Original message:On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
<hampus.sjoberg at gmail.com> wrote:
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> BIP148) node, because they wouldn't have the new consensus rule of requiring
> all blocks to signal for segwit.
All versions of Bitcoin Core since 0.13.1 signal segwit, 0.14.1+ even
when downstream mining software doesn't support it.
I think it would be useful for there to exist a useful and trivial
patch against current (0.14.2) software to engage in the BIP91-like
orphaning, like people have provided for BIP148-- but right now I
don't see any specification of the behavior so it's unclear to me
_exactly_ what it would need to implement to be consistent.

2023-06-07 18:02:13

- reply

📅 Original date posted:2017-06-19
📝 Original message:On Mon, Jun 19, 2017 at 12:26 PM, bfd--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Several times. It's been debated if unconfirmed transactions are necessary,
> methods of doing more private filtering have been suggested, along with
> simply not filtering unconfirmed transactions at all. My collected data
> suggests that there is very little use of BIP37 at present, based on
> incoming connections to nodes I know end up in the DNS seed responses (no
> "SPV" clients do their own peer management).
Sending just the output addresses of each transaction would use about
1 kilobit/s of data. Sending the entire transactions would use
~14kbit/sec data. These don't seem to be a unsustainable tremendous
amount of data to use while an application is running.
Doubly so for SPV wallets which are highly vulnerable to unconfirmed
transactions, and many which last I heard testing reports on became
pretty severely corrupted once given a fake transaction.
Can someone make a case why saving no more than those figures would
justify the near total loss of privacy that filtering gives?
"Because they already do it" isn't a good argument when talking about
a new protocol feature; things which already do BIP37 will presumably
continue to already do BIP37.

2023-06-07 18:02:08

- reply

📅 Original date posted:2017-06-07
📝 Original message:On Thu, Jun 1, 2017 at 7:01 PM, Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
> * https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
I see the inner loop of construction and lookup are free of
non-constant divmod. This will result in implementations being
needlessly slow (especially on arm, but even on modern x86_64 a
division is a 90 cycle-ish affair.)
I believe this can be fixed by using this approach
http://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/
which has the same non-uniformity as mod but needs only a multiply
and shift.
Otherwise fast implementations will have to implement the code to
compute bit twiddling hack exact division code, which is kind of
complicated. (e.g. via the technique in "{N}-bit Unsigned Division via
{N}-bit Multiply-Add" by Arch D. Robison).
Shouldn't all cases in your spec where you have N=transactions be
n=indexed-outputs? Otherwise, I think your golomb parameter and false
positive rate are wrong.

2023-06-07 18:02:06

- reply

📅 Original date posted:2017-06-01
📝 Original message:On Fri, Jun 2, 2017 at 2:15 AM, Chris via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
>
>> One aspect which isn't in this BIP draft is direct support for unconfirmed
>> transactions. I consider such a feature an important UX feature for mobile
>> phones, and something which I've personally seen as an important
>> UX-experience when on-boarding new users to Bitcoin.
>
> Totally agree. My first thought is maybe you could keep bip37 filtering
> as optional for unconfirmed transactions. Since you're only interested
Really bad for privacy. Data for transactions at the tip is only
14kb/s-- potentially less if segwit is in use and you're not getting
witnesses. Is that really that burdensome?
FWIW, leaving a mobile browser just running while pointed at some
websites seems to use more traffic than that just loading advertising.
:)

2023-06-07 18:01:46

- reply

📅 Original date posted:2017-05-23
📝 Original message:Based on how fast we saw segwit adoption, why is the BIP149 timeout so
far in the future?
It seems to me that it could be six months after release and hit the
kind of density required to make a stable transition.
(If it were a different proposal and not segwit where we already have
seen what network penetration looks like-- that would be another
matter.)

2023-06-07 18:01:14

- reply

📅 Original date posted:2017-05-16
📝 Original message:On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> just the first - and one that has very low costs and no normative
> datastructures at all.
The serialization of the txout itself is normative, but very minimal.

2023-06-07 18:01:13

- reply

📅 Original date posted:2017-05-15
📝 Original message:On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> transactions is in the header, which would let lite nodes download a UTXO
> set from any full node and verify it by verifying only block headers
> starting from genesis.
Ya, lite nodes with UTXO sets are one of the the oldest observed
advantages of a commitment to the UTXO data:
https://bitcointalk.org/index.php?topic=21995.0
But it requires a commitment. And for most of the arguments for those
you really want compact membership proofs. The recent rise in
interest in full block lite clients (for privacy reasons), perhaps
complements the membership proofless usage.
Pieter describes some uses for doing something like this without a
commitment. In my view, it's more interesting to first gain
experience with an operation without committing to it (which is a
consensus change and requires more care and consideration, which are
easier if people have implementation experience).
> rather than merkle tree root of transactions is in the header,
For audibility and engineering reasons it would need to be be in
addition to rather than rather than, because the proof of work needs
to commit to the witness data (in that kind of flip, the transactions
themselves become witnesses for UTXO deltas) or you get trivial DOS
attacks where people provide malleated blocks that have invalid
witnesses.

2023-06-07 18:00:59

- reply

📅 Original date posted:2017-05-09
📝 Original message:On Tue, May 9, 2017 at 7:15 PM, Sergio Demian Lerner via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The capacity of Segwit(50%)+2MbHF is 50% more than Segwit, and the maximum
> block size is the same.
And the UTXO bloat potential is twice as large and the cost of that
UTXO bloat is significantly reduced. So you're basically gutting the
most of the gain from weight, making something incompatible, etc.
I'm not sure what to explain-- even that page on segwit.org explains
that the values are selected to balance worst case costs not to
optimize one to the total exclusion of others. Raw size is not very
relevant in the long run, but if your goal were to optimize for it
(which it seems to be), then the limit should be pure size.

2023-06-07 18:00:59

- reply

📅 Original date posted:2017-05-09
📝 Original message:On Tue, May 9, 2017 at 7:42 PM, Matt Corallo <lf-lists at mattcorallo.com> wrote:
> at beast.
Rawr.

2023-06-07 18:00:45

- reply

📅 Original date posted:2017-05-03
📝 Original message:On Wed, May 3, 2017 at 9:08 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> CONS:
The primary result would be paying people to sybil attack the network.
It's far cheaper to run one node behind thousands of IPs than it is to
run many nodes.
Suggestions like this have come up many times before.

2023-06-07 18:00:12

- reply

📅 Original date posted:2017-04-15
📝 Original message:On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> triggering BIP141 activation, and therefore not enabling the new consensus
> rules on already deployed full nodes. BIP148 is making an explicit choice
> to favor dragging along those users which have upgraded to BIP141 support
> over those miners who have failed to upgrade.
>
I do not follow the argument that a critical design feature of a particular
"user activated soft fork" could be that it is users don't need to be
involved. If the goal is user activation I would think that the
expectation would be that the overwhelming majority of users would be
upgrading to do it, if that isn't the case, then it isn't really a user
activated softfork-- it's something else.
> On an aside, I'm somewhat disappointed that you have decided to make a
> public statement against the UASF proposal. Not because we disagree -- that
> is fine -- but because any UASF must be a grassroots effort and
> endorsements (or denouncements) detract from that.
>
So it has to be supported by the public but I can't say why I don't support
it? This seems extremely suspect to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/1328569c/attachment.html>

2023-06-07 18:00:11

- reply

📅 Original date posted:2017-04-25
📝 Original message:On Thu, Apr 20, 2017 at 6:39 PM, shaolinfry <shaolinfry at protonmail.ch> wrote:
> I agree with much of your thoughts. I originally started working on a
> generalized way to deploy user activated soft forks, in a way that leveraged
> BIP9 to allow for optional faster MASF activation. BIP148 came about as a
> way to satify many people's frustrations about the current segwit
> activation. I have said several times in various places that the proposal
> requires a very high amount of consensus that needs to be present to make
> actual deployment feasible. BIP148 is certainly not what a normal UASF would
> or should look like.
>
> I remain convinced the community very much wants segwit activated and that
> the UASF movement in general has gained a lot of traction. While support for
> BIP148 is surprisingly high, there are definitely important players who
> support UASF in general but do not like BIP148 approach (which you rightly
> point out is a UASF to force a MASF).
[...]
> With BIP8 we could perform a UASF segwit deployment. Due to some
> complexities in the peering logic, I recommend a new deployment with a fresh
> bit that starts right after November 15th (when BIP9 segwit timesout) with a
> BIP8 timeout for April 2018. The code can deployed much earlier. For example
> if code was deployed today, it would give the economy a year to upgrade.
> Activation could still occur safely by MASF any time from now until April
> 2018 (SEGWIT until Nov, then UASEGWIT from Nov until April 2018).
>
> I am still working on the finer implementation details, but you can see a
> rough draft from this diff (which includes BIP8 in the first commit, and the
> proposed bip-segwit-uasf in the second commit).
>
> https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday
>
> I believe this approach would satisfy the more measured approach expected
> for Bitcoin and does not have the issues you brought up about BIP148.
I have not reviewed it carefully yet, but I agree that it addresses my
main concern! I think this is a much better approach. Thanks.

2023-06-07 18:00:09

- reply

📅 Original date posted:2017-04-15
📝 Original message:On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham <da2ce7 at gmail.com> wrote:
> As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.
And as a result we ultimately got a clearly inferior solution (520
byte script limit; 80-bit security; months of orphaned blocks-- and
two of those were not issues in BIP17). I went along for the cram
fest on 16 after 12 caught fire, and I was mistaken to do so.
Doubly so because it took years for P2SH to achieve any kind of mass
deployment due to issues far away from consensus. An extra two months
spent on some ground-work (including communications and documentation)
could have pulled forward practical deployment by a year and given
time to find and fix some of the flaws in the design of P2SH.
> BIP 148 is out (our?) terms of peace. The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.
It seems I lost a word in my comment: that should have been "almost
guarantees at _least_ a minor level of disruption". A minor level of
disruption is the _minimum_ amount of disruption, and for no good
reason except an unprecedented and unjustified level of haste.
Considering that you did not spare a single word about the specific
property that I am concerned about-- that the proposal will reject the
blocks of passive participants, due to avoidable design limitations--
I can't help but feel that you don't even care to understand the
concern I was bringing up. :(
How many people barely reviewed the specifics of the proposal simply
because they want something fast and this proposal does something
fast?
> tired-to-death of this war and wants a resolution swiftly
By now competitors and opponents to Bitcoin have surely realized that
they can attack Bitcoin by stirring up drama.
As a result, the only way that we will ever be free from "war" is if
we choose to not let it impact us as much as possible. We must be
imperturbable and continue working at the same level of excellence as
if virtual shells weren't flying overhead-- or otherwise there is an
incentive to keep them flying 24/7. Internet drama is remarkably cheap
to generate. "The only thing we have to fear is fear itself".
The alternative is that we hand opponents a ready made formula for
disruption: astroturf enough drama up that Bitcoiners "sacrifice
correctness" themselves right off a cliff in a futile attempt to make
it go away. :)

2023-06-07 18:00:02

- reply

📅 Original date posted:2017-04-14
📝 Original message:I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.
I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.
The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
of disruption.
Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
activates.
Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.
I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.
But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.
"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
more strongly.
Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights. We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony. It's kind of weird to see UASF
portrayed as something new.
It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers. Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.
There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.
We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.
If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)
So have patience, don't take short cuts. Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.

2023-06-07 17:59:44

- reply

📅 Original date posted:2017-04-07
📝 Original message:On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.
Only with the additional commitment structure such as those proposed
by Peter Todd in his stxo/txo commitment designs, e.g.
https://petertodd.org/2016/delayed-txo-commitments

2023-06-07 17:59:43

- reply

📅 Original date posted:2017-04-06
📝 Original message:On Fri, Apr 7, 2017 at 12:48 AM, Tomas <tomas at tomasvdw.nl> wrote:
> Bitcrust separates script validation (base load, when transaction come
> in) from order validation (peak load, when blocks come in).
How do you deal with validity rules changing based on block height?
> For script validation it would obviously need the ~2GB (or I think
> ~1.5GB) of outputs needed to validate these.
So it sounds like to work the software still needs an analog of a
(U)TXO database? I am confused by the earlier comments about thinking
the the resource consumption of the (U)TXO database is not a
consideration in your design.
> For order validation it
> needs ~200mb or the spent-index (for bit-lookups) and I would guess
> roughly ~500mb of the spent-tree (for scanning), though I don't think
> the 5.7GB full spend tree isn't worth pruning anytime soon.
If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an
output that never existed how does your spent index reject this spend?

2023-06-07 17:59:42

- reply

📅 Original date posted:2017-04-08
📝 Original message:On Sat, Apr 8, 2017 at 8:21 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
> pre-synced means already in mempool and verified? Then it sounds like we just need some mempool optimisation? The tx order in a block is not important, unless they are dependent
In Bitcoin Core the software _explicitly_ and intentionally does not
exploit mempool pre-validation because doing that very easily leads to
hard to detect consensus faults and makes all mempool code consensus
critical when it otherwise is not. There have been bugs in the past
which would have split the network if this optimization had been used.
(in particular, I believe I recall one related to correctly removing
coinbase spends from the mempool during reorganization that made them
immature; and with the optimization and without the CNB post-test
would have resulted in nodes that saw the reorg creating and accepting
an invalid block, while nodes that didn't rejecting it; but because of
prudent design it was largely harmless).
Because signature validation is cached, and takes the majority of the
block validation time the speed up from the risky optimization isn't
that considerable, and there are other lower hanging fruity with
bigger payouts like Pieter's change to the per-txout management model
and the new non-atomic flushing logic.... and these things don't make
more of the system consensus critical.

2023-06-07 17:59:40

- reply

📅 Original date posted:2017-04-07
📝 Original message:On Fri, Apr 7, 2017 at 9:14 PM, Tomas <tomas at tomasvdw.nl> wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.
Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protocol addressing the UTXO growth, might not be worth considering
*protocol improvements* "
As you note that the output costs still bound the resource
requirements. Short of radical protocol changes like TXO-proofs the
UTXO data remains a driving unavoidable long term resource cost, not
an implementation detail. Implementation optimizations like improving
locality further or keeping spentness in memory do not change this
fact.
> The storage that is accessed during peak load (block validation with
> pre-synced transactions), is minimized as this only needs the transaction
> index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of
Latency related costs in Bitcoin Core also do not depend on the number
of outputs in transactions in a block. When a transaction is handled
it goes into an in-memory buffer and only gets flushed later if isn't
spent before the buffer fills. A block will take more time to
validate with more inputs, same as you observer, but the aggregate
resource usage for users depends significantly on outputs (so, in fact
there is even further misaligned incentives than just the fact that
small outputs have a outsized long term cost).

2023-06-07 17:59:15

- reply

📅 Original date posted:2017-04-05
📝 Original message:On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon <joseph at lightning.network> wrote:
> #bitcoin at freenode:
> 00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
>
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking you seriously and having second thoughts and want to make public
> commitments to do the right thing without any evidence and you come out
> and say *this*?
I apologize for the glib talk on chat and I hope you understand that
the tone in such venues is significantly informal; and that my remark
was a causal one among friends which was not intended in a spirit as
seriously as you've taken it.
That said, two days ago you participated in a highly unusual
announcement of a protocol change that-- rather than being sent for
community review in any plausible venue for that purpose-- was
announced as a done deal in embargoed media announcements. This
proposed protocol change seemed custom tailored to preserve covert
boosting, and incorporated direct support for lightning -- and the
leading competing theory was that a large miner opposed segwit
specifically because they wanted to block lightning. Moreover, I have
heard reports I consider reliable that this work was funded by the
miner in question.
In the time since, when people asked for revisions to the proposal to
not block segwit they received responses from the Bcoin account on
twitter that "there would be no amendments", and I was sent leaked
chatlogs of you making considerably hostile statements, claiming that
if your extension block proposal is "a litmus test for corruption",
and claimed (before AFAIK anyone had had a chance to comment on it)
that the Bitcoin project contributors opposed it for "nonsense
reasons".
It is with this in mind that when you tried to pull me into an off the
record conversation that I responded stating:
"[...] I am disinclined to communicate with you except in email where I can
get third party transferable proof of our communication. I'm
concerned that you may now be involved in a conspiracy which I do not
want to be implicated in myself.
It is my estimation that, for that above reason, it would be in my
best interest to not communicate with you at all. But in all your
prior interactions you appeared to have integrity and sense, so out of
respect for that history I'm willing to communicate with you, but only
in public or in email where my end is on gmail."
This was two days ago and you did not respond further.
With that in mind I hope you do not find some casual crap-talking on
chat to be especially surprising.
I understand that you didn't intend for the initial message to be
posted in public, so I'm sorry for continuing the thread here-- but I
thought it was useful for people to understand the context behind that
glib remark: Including the point that I do not know for a fact that
you are complicit in anything, but I consider your recent actions to
be highly concerning.

2023-06-07 17:59:14

- reply

📅 Original date posted:2017-04-05
📝 Original message:On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This seems to be a serious security problem. Would it be possible to have
> a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger
> 3-6 months from release should be sufficient for enough of the economy to upgrade,
> given the severity of the issue.
Not 0.14.1 because that is in RC already and will hopefully be out in a week.
I think the speed of adoption depends a lot of the level of support
from the community. I don't believe there are any technical hurdles to
implementing this relatively quickly (and I specifically propose using
the users choice of the segwit commitment or a modified form in order
to lower the technical complexity and risk).
> BIP 141 says that the the commitment is optional if there are no SegWit transactions in
> the block, so will today's SegWit-ready miners always produce it even when optional
> according to BIP 141, as required by this softfork?
This is the default behavior as of 0.13.2, but I haven't gone out to
measure this which is why the backwards compatibility section of the
BIP isn't written yet.
While I'm posting, I've had a dozen off-list emails that presented me
with some FAQ:
Many people asked what other protocol upgrades beyond segwit could run
into the same incompatibility.
Many proposed improvements to Bitcoin require additional
transaction-dependent commitment data.
Examples include:
(1) Segwit.
(2) UTXO commitments. (non-delayed, at least)
(3) Committed Bloom filters
(4) Committed address indexes
(5) STXO commitments (non-delayed).
(6) Weak blocks
(7) Most kinds of fraud proofs
-- to state a few.
Unfortunately, putting *any* commitment to data dependent on the right
hand side of the hash tree in the left hand side (e.g. coinbase) means
a massive increase in the computation required for covert boosting,
because it means you can't use the left+right side combinations to
eliminate most of the hashing.
It's plausible, in fact, that this extra computation could completely
nullify the ASICBOOST advantage-- though this depends a lot on the
fine details of the implementation.
This proposal does not itself propose nullifying ASICBOOST entirely,
it proposes severely handicapping the covert form of it, and
eliminating the differential advantage for boosting miners related to
the use of transaction-dependent commitments.
Basically there are two completely separate concerns: that boosting
can produce a monopoly advantage which could be severely harmful to
the ecosystem, and that the efficient implementation of _covert_
boosting can severely harm many useful protocol improvements. My
proposal only addresses the second concern, by (I believe) completely
leveling the playing field so that opposing commitments will not break
boosting any worse, and by making covert boosting less appealing in
general.
Use of the segwit-style commitment even in non-segwit blocks is sufficient
because the segwit commitment commits to all transactions (except
the coinbase) and not just segwit ones.
(It was designed this way so that lite clients that needed witness
data could work with just one tree).

2023-06-07 17:59:13

- reply

📅 Original date posted:2017-04-05
📝 Original message:A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
is exploited by ASICBOOST and the various steps which could be used to
block it in the network if it became a problem.
While most discussion of ASICBOOST has focused on the overt method
of implementing it, there also exists a covert method for using it.
As I explained one of the approaches to inhibit covert ASICBOOST I
realized that my words were pretty much also describing the SegWit
commitment structure.
The authors of the SegWit proposal made a specific effort to not be
incompatible with any mining system and, in particular, changed the
design at one point to accommodate mining chips with forced payout
addresses.
Had there been awareness of exploitation of this attack an effort
would have been made to avoid incompatibility-- simply to separate
concerns. But the best methods of implementing the covert attack
are significantly incompatible with virtually any method of
extending Bitcoin's transaction capabilities; with the notable
exception of extension blocks (which have their own problems).
An incompatibility would go a long way to explain some of the
more inexplicable behavior from some parties in the mining
ecosystem so I began looking for supporting evidence.
Reverse engineering of a particular mining chip has demonstrated
conclusively that ASICBOOST has been implemented
in hardware.
On that basis, I offer the following BIP draft for discussion.
This proposal does not prevent the attack in general, but only
inhibits covert forms of it which are incompatible with
improvements to the Bitcoin protocol.
I hope that even those of us who would strongly prefer that
ASICBOOST be blocked completely can come together to support
a protective measure that separates concerns by inhibiting
the covert use of it that potentially blocks protocol improvements.
The specific activation height is something I currently don't have
a strong opinion, so I've left it unspecified for the moment.
<pre>
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert attack on the Bitcoin POW function
Author: Greg Maxwell <greg at xiph.org>
Status: Draft
Type: Standards Track
Created: 2016-04-05
License: PD
</pre>
==Abstract==
This proposal inhibits the covert exploitation of a known
vulnerability in Bitcoin Proof of Work function.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
==Motivation==
Due to a design oversight the Bitcoin proof of work function has a potential
attack which can allow an attacking miner to save up-to 30% of their energy
costs (though closer to 20% is more likely due to implementation overheads).
Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
which they have so far not licensed for free and open use by the public.
They have been marketing their patent licenses under the trade-name
ASICBOOST. The document takes no position on the validity or enforceability
of the patent.
There are two major ways of exploiting the underlying vulnerability: One
obvious way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol. The covert mechanism is not
easily detected except through its interference with the protocol.
In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.
Exploitation of this vulnerability could result in payoff of as much as
$100 million USD per year at the time this was written (Assuming at
50% hash-power miner was gaining a 30% power advantage and that mining
was otherwise at profit equilibrium). This could have a phenomenal
centralizing effect by pushing mining out of profitability for all
other participants, and the income from secretly using this
optimization could be abused to significantly distort the Bitcoin
ecosystem in order to preserve the advantage.
Reverse engineering of a mining ASIC from a major manufacture has
revealed that it contains an undocumented, undisclosed ability
to make use of this attack. (The parties claiming to hold a
patent on this technique were completely unaware of this use.)
On the above basis the potential for covert exploitation of this
vulnerability and the resulting inequality in the mining process
and interference with useful improvements presents a clear and
present danger to the Bitcoin system which requires a response.
==Background==
The general idea of this attack is that SHA2-256 is a merkle damgard hash
function which consumes 64 bytes of data at a time.
The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.
The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.
Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.
There are two broad ways of making use of this attack. The obvious
way is to try candidates with different version numbers. Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.
The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it. If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the attack.
To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.
An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.
This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right side of the tree using transaction permutation or
substitution of a small number of transactions. All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.
With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce grinding which would substantially erode the
benefit of the attack.
It is this final optimization which this proposal blocks.
==New consensus rule==
Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.
(See BIP-141 "Commitment structure" for details)
Existing segwit using miners are automatically compatible with
this proposal. Non-segwit miners can become compatible by simply
including an additional output matching a default commitment
value returned as part of getblocktemplate.
Miners SHOULD NOT automatically discontinue the commitment
at the expiration height.
==Discussion==
The commitment in the left side of the tree to all transactions
in the right side completely prevents the final sqrt speedup.
A stronger inhibition of the covert attack in the form of
requiring the least significant bits of the block timestamp
to be equal to a hash of the first 64-bytes of the header. This
would increase the collision space from 32 to 40 or more bits.
The root value could be required to meet a specific hash prefix
requirement in order to increase the computational work required
to try candidate roots. These change would be more disruptive and
there is no reason to believe that it is currently necessary.
The proposed rule automatically sunsets. If it is no longer needed
due to the introduction of stronger rules or the acceptance of the
version-grinding form then there would be no reason to continue
with this requirement. If it is still useful at the expiration
time the rule can simply be extended with a new softfork that
sets longer date ranges.
This sun-setting avoids the accumulation of technical debt due
to retaining enforcement of this rule when it is no longer needed
without requiring a hard fork to remove it.
== Overt attack ==
The non-covert form can be trivially blocked by requiring that
the header version match the coinbase transaction version.
This proposal does not include this block because this method
may become generally available without restriction in the future,
does not generally interfere with improvements in the protocol,
and because it is so easily detected that it could be blocked if
it becomes an issue in the future.
==Backward compatibility==
==Implementation==
==Acknowledgments==
==Copyright==
This document is placed in the public domain.

2023-06-07 17:53:37

- reply

📅 Original date posted:2016-09-23
📝 Original message:I've proposed a revision to BIP-1 that removes the option to license
the work under the OPL: https://github.com/bitcoin/bips/pull/446
The OPL contains troublesome terms where the licensor can elect to
prohibit print publication of the work as well as the creation of
modified versions without their approval.
"Distribution of substantively modified versions of this document is
prohibited without the explicit permission of the copyright holder."
"Distribution of the work or derivative of the work in any standard
(paper) book form is prohibited unless prior permission is obtained
from the copyright holder."
Additionally, even without these optional clauses the specific
construction of this licenses' attribution requirements are
restrictive enough that Debian does not consider it acceptable for
works included in their distribution
(https://lists.debian.org/debian-legal/2004/03/msg00226.html).
I can't find any discussion that indicates anyone involved with the
project was aware of these clauses at the time this text was added...
and I believe they are strongly incompatible with having a
transparent, public, collaborative process for the development of
standard for interoperablity. I certainly wasn't aware of it, and
would have argued against it if I was.
Moreover, the project that created this license has recommended people
use creative commons licenses instead since 2007.
The only BIPs that have availed themselves of this are BIP145 (which
is dual licensed under the permissive 2-clause BSD, which I wouldn't
object to adding as an option-- and which doesn't active the
objectionable clauses) and the recently assigned BIP134.

2023-06-07 17:53:34

- reply

📅 Original date posted:2016-09-23
📝 Original message:On Fri, Sep 23, 2016 at 10:20 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> In the innocent use case of this opcode, a double-spend has already occurred,
> and this should be a strict improvement. In the non-innocent abuse of this
> opcode, I don't see that it's any worse than simply double-spending.
There is a fungibility hit... right now, absent double spends (and
privacy issues), every coin you might get paid is equal.
With this script feature as described, you could get paid a coin which
has one of these in its recent past, pinning the block immediately
before it. A reorg long enough to remove that block-- due to an
attack, or an ordinary block race, or some kind of consensus glitch
(like we had in March 2013 or around the activation of BIP65)-- is
_guaranteed_ to invalidate those coins, even without any double spend.
If the scheme doesn't do as I suggest and prevent over-eager usage
(perhaps 100 is too much, I just decided to match coinbases); then it
should probably have a consensus enforced explicit "maximum survivable
reorg" that is traced along with the outputs, so that someone who
received exposed coins could handle it sensibly.
Just for plain engineering reasons, I still think it is important to
now allow overly short back references. If the reference has to be a
few blocks back we don't need to worry about short forks breaking
propagation, and simple mempool handling like purging all CBAH
transactions on a large reorg would work fine. It need not be so long
as to implicate Petertodd's concern that you could only use it where
it wouldn't matter. (Though I also disagree that a depth of 100
achieves that, consider persistent chain forks).

2023-06-07 17:53:27

- reply

📅 Original date posted:2016-09-21
📝 Original message:On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP number for my FT spec.
This document does not appear to be concretely specified enough to
review or implement from it.
For example, it does not specify the serialization of "integer" (is it
a 32 bit word in network byte order or?) nor does it specify how the
presence of the optional fields are signaled nor the cardinality of
the inputs or outputs. For clearly variable length elements
('bytearray') no mention is made of their length encoding. etc.
Without information like this, I don't see how someone could
realistically begin reviewing this proposal.
The motivation seems unclear to me as well: The scheme is described as
'flexible' but it appears to remove flexibility from the existing
system. The "schema" appears to be hardcoded and never communicated.
If the goal is to simply have a more compact on the wire
representation, this could be done without changing the serialization
used for hashing or the serialization used for costing.

2023-06-07 17:53:10

- reply

📅 Original date posted:2016-08-25
📝 Original message:On Thu, Aug 25, 2016 at 2:27 PM, Christian Decker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If however
> he is planning to use it as a foothold to further compromise your
> company, send spam or similar, he will likely try to avoid these
> tripwires. [...]
Depends on the value of their activity compared to the value of the coins.
Spamming doesn't pay much.
Covert tripwires would obviously be better, but if shared tripwires
allow you to have 100x the funds available it could be a good
trade-off.

2023-06-07 17:53:08

- reply

📅 Original date posted:2016-08-24
📝 Original message:On Wed, Aug 24, 2016 at 11:03 PM, Chris Priest via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> How does your system prevent against insider attacks? How do you know
> the money is stolen by someone who compromised server #4, and not
> stolen by the person who set up server #4? It is my understanding
> these days most attacks are inside jobs.
Working as designed in that case: You know #4 is compromised, it
doesn't tell you if it was an insider or an outsider, but in both
cases someone unauthorized or without integrity got access to the
key(s).

2023-06-07 17:53:02

- reply

📅 Original date posted:2016-08-24
📝 Original message:On Tue, Aug 23, 2016 at 8:54 PM, Kenneth Heutmaker via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> SPV is kinda broken if the wallet doesn’t do this detection. If your wallet connects only to nodes that don’t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.
>
> We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.
There are almost no NODE_BLOOM supporting bloom-off nodes on the
network currently. So, while supporting this is important, I am
doubtful that its the current problem you've suffered.
There are a great many fake nodes which appear to exist purely to
monitor transactions. Many do not implement enough of the protocol to
support scanning or transaction relay. (and, in fact, relaying
transactions would make monitoring less effective).
You can't count on peers on a peer to peer network to be honest and
cooperative. Implementations need to work hard to be robust to abusive
peers. Unfortunately, the design of the bloom filtering is such that
it isn't always easy (or even possible) to be robust.

2023-06-07 17:52:57

- reply

📅 Original date posted:2016-08-16
📝 Original message:On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I see.
>
> But is it really necessary to soft fork over this issue? Why not just make
> it a relay rule? Miners are already incentivized to modify transactions to
> drop excess witness data and/or prioritize (versions of) transactions based
> on their cost. If a miner wants to mine a block with excess witness data,
> it is mostly their own loss.
Relay rules are quite fragile-- people build programs or protocols not
expecting them to be violated, without proper error handling in those
cases... and then eventually some miner rips them out because they
simply don't care about them: not enforcing them won't make their
blocks invalid.
It's my general view that we should avoid blocking things with relay
rules unless we think that someday they could be made invalid... not
necessarily that they will, but that it's plausible. Then the
elimination at the relay level is just the first exploratory step in
that direction.
One should also consider adversarial behavior by miners. For example,
I can mine blocks with mutated witnesses with a keyed mac that chooses
the mutation. The key is shared by conspirators or customers, and now
collectively we have a propagation advantage (since we know the
mutated version before it shows up). Not the _biggest_ concern, since
parties doing this could just create their own new transactions to
selectively propagate; but doing that would require leaving behind fee
paying public transactions, while using malleability wouldn't.

2023-06-07 17:52:38

- reply

📅 Original date posted:2016-08-11
📝 Original message:On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Still not sure how you can take a BIP32 public seed and figure out if an
> address was derived from it though. I mean, wouldn't I have to compute all
> 2^31 possible public child addresses?
Which would take a quad core laptop about 8 hours with competent software
And presumably you're not using the whole 2^31 space else the receiver
also has to do that computation...

2023-06-07 17:51:38

- reply

📅 Original date posted:2016-06-28
📝 Original message:On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> An "out of band key check" is not part of BIP151.
It has a session ID for this purpose.
> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised.
One might wonder how you ever use a Bitcoin address, or even why we
might guess these emails from "you" aren't actually coming from the
NSA.

2023-06-07 17:50:36

- reply

📅 Original date posted:2016-05-11
📝 Original message:On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is what I meant. If existing hardware gets forked-out it will
> inevitably lead to the creation of an altcoin. Simply because the hardware
> exists and can't be used for anything else both chains will survive. I was
> only comparing the situation to a contentious hardfork that does not fork
> out any hardware. If the latter one is suspected to lead to the permanent
> existence of two chains then a hardfork that forks out hardware is even more
> likely to do so (I claim it's guaranteed).
There are already many altcoins out there, we could not prevent that
even if we wanted to. New ones are created all the time.
A 20% inherent advantage, in perfect competition, is likely to lead to
an eventual monopoly of mining if monopoly patent right prohibit
competitions-- if mining profits go are under the level of that
enhancement everyone without it would be operating at a loss.
Preserving a vulnerability that will ultimately harm the system's
decentralization for just the betterment of some miners does not seem
like a rational decision for the users of Bitcoin-- no more than it
would reasonable to add a rule that all blocks must be signed by a
particular private key.
As an altcoin the "asicboost" altcoin would be one of the least
interesting altcoins ever created... after all, no other altcoin has
ever been created that required licensing in order to mine.
I don't know if forking it out is the best move here and now, but I'm
happy some people are thinking carefully about what it would take to
do that.

2023-06-07 17:50:21

- reply

📅 Original date posted:2016-05-10
📝 Original message:On Tue, May 10, 2016 at 5:28 AM, Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I used variable-length bit encodings, and used the shortest encoding
> which is unique to you (including mempool). It's a little more work,
> but for an average node transmitting a block with 1300 txs and another
> ~3000 in the mempool, you expect about 12 bits per transaction. IOW,
> about 1/5 of your current size. Critically, we might be able to fit in
> two or three TCP packets.
Hm. 12 bits sounds very small even giving those figures. Why failure
rate were you targeting?
I've mostly been thing in terms of 3000 txn, and 20k mempools, and
blocks which are 90% consistent with the remote mempool, targeting
1/100000 failure rates (which is roughly where it should be to put it
well below link failure levels).
If going down the path of more complexity, set reconciliation is
enormously more efficient (e.g. 90% reduction), which no amount of
packing/twiddling can achieve.
But the savings of going from 20kb to 3kb is not interesting enough to
justify it*. My expectation is that later we'll deploy set
reconciliation to fix relay efficiency, where the savings is _much_
larger, and then with the infrastructure in place we could define
another compactblock mode that used it.
(*Not interesting because it mostly reduces exposure to loss and the
gods of TCP, but since those are the long poles in the latency tent,
it's best to escape them entirely, see Matt's udp_wip branch.)
> I would also avoid the nonce to save recalculating for each node, and
> instead define an id as:
Doing this would greatly increase the cost of a collision though, as
it would happen in many places in the network at once over the on the
network at once, rather than just happening on a single link, thus
hardly impacting overall propagation.
(The downside of the nonce is that you get an exponential increase in
the rate that a collision happens "somewhere", but links fail
"somewhere" all the time-- propagation overall doesn't care about
that.)
Using the same nonce means you also would not get a recovery gain from
jointly decoding using compact blocks sent from multiple peers (which
you'll have anyways in high bandwidth mode).
With a nonce a sender does have the option of reusing what they got--
but the actual encoding cost is negligible, for a 2500 transaction
block its 27 microseconds (once per block, shared across all peers)
using Pieter's suggestion of siphash 1-3 instead of the cheaper
construct in the current draft.
Of course, if you're going to check your whole mempool to reroll the
nonce, thats another matter-- but that seems wasteful compared to just
using a table driven size with a known negligible failure rate.
64-bits as a maximum length is high enough that the collision rate
would be negligible even under fairly unrealistic assumptions-- so
long as it's salted. :)
> As Peter R points out, we could later enhance receiver to brute force
> collisions (you could speed that by sending a XOR of all the txids, but
> really if there are more than a few collisions, give up).
The band between "no collisions" and "infeasible many" is fairly
narrow. You can add a small amount more space to the ids and
immediately be in the no collision zone.
Some earlier work we had would send small amount of erasure coding
data of the next couple bytes of the IDs. E.g. the receiver in all
the IDs you know, mark totally unknown IDs as erased and the let the
error correction fix the rest. This let you algebraically resolve
collisions _far_ beyond what could be feasibly bruteforced. Pieter
went and implemented... but the added cost of encoding and software
complexity seem not worth it.

2023-06-07 17:50:18

- reply

📅 Original date posted:2016-05-09
📝 Original message:On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> You misunderstand the networking effects.
> The fact that your node is required to choose which one to set the announce
> bit on implies that it needs to predict which node will have the best data in
> the future.
Not required. It may. If it chooses fortunately, latency is reduced--
to 0.5 RTT in many cases. If not-- nothing harmful happens.
Testing on actual nodes in the actual network (not a "lab") shows that
blocks are normally requested from one of the last three peers they
were requested from 70% of the time, with no special affordances or
skipping samples when peers disconnected.
(77% for last 4, 88% for last 8)
This also _increases_ robustness. Right now a single peer failing at
the wrong time will delay blocks with a long time out. In high
bandwidth mode the redundancy means that node will be much more likely
to make progress without timeout delays-- so long at least one of the
the selected opportunistic mode peers was successful.
Because the decision is non-normative to the protocol, nodes can
decide based on better criteria if better criteria is discovered in
the future.
> Another problem with your solution is that nodes send a much larger amount of
> unsolicited data to peers in the form of the thin-block compared to the normal
> inv or header-first data.
"High bandwidth" mode uses somewhat more bandwidth than low
bandwidth... but still >>10 times less than an ordinary getdata relay
which is used ubiquitously today.
If a node is trying to minimize bandwidth usage, it can choose to not
request the "high bandwidth" mode.
The latency bound cannot be achieved without unsolicited data. The
best we can while achieving 0.5 RTT is try to arrange things so that
the information received is maximally useful and as small as
reasonably possible.
If receivers implemented joint decoding (combining multiple
comprblocks in the event of faild decoding) 4 byte IDs would be
completely reasonable, and were what I originally suggested (along
with forward error correction data, in that case).
> Am I to understand that you choose the solution based on the fact that service
> bits are too expensive to extend? (if not, please respond to my previous
> question actually answering the suggestion)
>
> That sounds like a rather bad way of doing design. Maybe you can add a second
> service bits field of message instead and then do the compact blocks correctly.
Service bits are not generally a good mechanism for negating optional
peer-local parameters.
The settings for compactblocks can change at runtime, having to
reconnect to change them would be obnoxious.
> Wait, you didn't steal the variable length encoding from an existing standard
> and you programmed a new one?
This is one of the two variable length encodings used for years in
Bitcoin Core. This is just the first time it's shown up in a BIP.
[It's a little disconcerting that you appear to be maintaining a fork
and are unaware of this.]
> Look at UTF-8 on wikipedia, you may have "invented" the same encoding that IBM
> published in 1992.
The similarity with UTF-8 is that both are variable length and some
control information is in the high bits. The similarity ends there.
UTF-8 is more complex and less efficient for this application (coding
small numbers), as it has to handle things like resynchronization
which are critical in text but irrelevant in our framed, checksummed,
reliably transported binary protocol.
> Just the first (highest) 8 bytes of a sha256 hash.
>
> The amount of collisions will not be less if you start xoring the rest.
> The whole reason for doing this extra work is also irrelevant as a spam
> protection.
Then you expose it to a trivial collision attack: To find two 64 bit
hashes that collide I need perform only roughly 2^32 computation. Then
I can send them to the network. You cannot reason about these systems
just by assuming that bad things happen only according to pure chance.
This issue is eliminated by salting the hash. Moreover, with
per-source randomization of the hash, when a rare chance collision
happens it only impacts a single node at a time, so the propagation
doesn't stall network wide on an unlucky block; it just goes slower on
a tiny number of links a tiny percent of the time (instead of breaking
everywhere an even tinyer amount of the time)-- in the non-attacker,
chance event case.

2023-06-07 17:49:35

- reply

📅 Original date posted:2016-03-02
📝 Original message:On Wed, Mar 2, 2016 at 5:14 PM, David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Mar 02, 2016 at 02:56:14PM +0000, Luke Dashjr via bitcoin-dev wrote:
>> To alleviate this risk, it seems reasonable to propose a hardfork to the
>> difficulty adjustment algorithm so it can adapt quicker to such a significant
>> drop in mining rate.
>
> Having a well-reviewed hard fork patch for rapid difficulty adjustment
> would seem to be a useful reserve for all sorts of possible problems.
> That said, couldn't this specific potential situation be dealt with by a
> relatively simple soft fork?
[...]
What you are proposing makes sense only if it was believed that a very
large difficulty drop would be very likely.
This appears to be almost certainly untrue-- consider-- look how long
ago since hashrate was 50% of what it is now, or 25% of what it is
now-- this is strong evidence that supermajority of the hashrate is
equipment with state of the art power efficiency. (I've also heard
more directly-- but I think the this evidence is more compelling
because it can't be tainted by boasting). If a pre-programmed ramp and
drop is set then it has the risk of massively under-setting
difficulty; which is also strongly undesirable (e.g. advanced
inflation and exacerbating existing unintentional selfish mining)...
and that is before suggesting that miners voluntarily take a loss of
inflation now.
So while I think this concern is generally implausible; I think it's
prudent to have a difficulty step patch (e.g. a one time single point
where a particular block is required to lower bits a set amount) ready
to go in the unlikely case the network is stalled. Of course, if the
alternative is "stuck" from a large hashrate drop the deployment would
be both safe and relatively uncontroversial. I think the
unfavorability of that approach is well matched to the implausibility
of the situation, and likely the right coarse of action compared to
risky interventions that would likely cause harm. The cost of
developing and testing such a patch is low, and justified purely on
the basis of increasing confidence that an issue would be handled (a
fact _I_ am perfectly confident in; but apparently some are not).
With respect what Luke was suggesting; without specifics its hard to
comment, but most altcoin "tolerate difficulty drop" changes have made
them much more vulnerable to partitioning attacks and other issues
(e.g. strategic behavior by miners to increase inflation), and have
actually been exploited in practice several times (solidcoin's being
the oldest I'm aware of). Many survived a fairly long time before
being shown to be pretty broken, simply because they were deployed in
cases where no one cared to attack. I'm currently doubtful that
particular path would be fruitful.

2023-06-07 17:49:20

- reply

📅 Original date posted:2016-02-26
📝 Original message:I am happy to announce the first successful Zero-Knowledge Contingent
Payment (ZKCP) on the Bitcoin network.
ZKCP is a transaction protocol that allows a buyer to purchase
information from a seller using Bitcoin in a manner which is private,
scalable, secure, and which doesn’t require trusting anyone: the
expected information is transferred if and only if the payment is
made. The buyer and seller do not need to trust each other or depend
on arbitration by a third party.
Imagine a movie-style “briefcase swap” (one party with a briefcase
full of cash, another containing secret documents), but without the
potential scenario of one of the cases being filled with shredded
newspaper and the resulting exciting chase scene.
An example application would be the owners of a particular make of
e-book reader cooperating to purchase the DRM master keys from a
failing manufacturer, so that they could load their own documents on
their readers after the vendor’s servers go offline. This type of sale
is inherently irreversible, potentially crosses multiple
jurisdictions, and involves parties whose financial stability is
uncertain–meaning that both parties either take a great deal of risk
or have to make difficult arrangement. Using a ZKCP avoids the
significant transactional costs involved in a sale which can otherwise
easily go wrong.
In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle
for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a
demonstration performed live at Financial Cryptography 2016 in
Barbados. I played my part in the transaction remotely from
California.
The transfer involved two transactions:
8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e
200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae
Almost all of the engineering work behind this ZKCP implementation was
done by Sean Bowe, with support from Pieter Wuille, myself, and Madars
Virza.
Read more, including technical details at
https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
[I hope to have a ZKCP sudoku buying faucet up shortly. :) ]

2023-06-07 17:49:19

- reply

📅 Original date posted:2016-02-26
📝 Original message:On Fri, Feb 26, 2016 at 5:35 AM, Jonathan Toomim via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> An improvement that I've been thinking about implementing (after
> Blocktorrent) is an option for batched INVs. Including the hashes for two
> txes per IP packet instead of one would increase the INV size to 229 bytes
> for 64 bytes of payload -- that is, you add 36 bytes to the packet for every
> 32 bytes of actual payload. This is a marginal efficiency of 88.8% for each
> hash after the first. This is *much* better.
>
> Waiting a short period of time to accumulate several hashes together and
> send them as a batched INV could easily reduce the traffic of running
> bitcoin nodes by a factor of 2,
Copying my response to you from BitcoinTalk
(https://bitcointalk.org/index.php?topic=1377345.msg14013294#msg14013294):
Uh. Bitcoin has done this since the very early days. The batching was
temporarily somewhat hobbled between 0.10 and 0.12 (especially when
you had any abusive frequently pinging peers attached), but is now
fully functional again and it now manages to batch many transactions
per INV pretty effectively. Turn on net message debugging and you'll
see the many INVs that are much larger than the minimum. The average
batching size (ignoring the trickle cut-through) is about 5 seconds
long-- and usually gets about 10 transactions per INV. My measurements
were with these fixes in effect; I expect the blocksonly savings would
have been higher otherwise.
2016-02-26 05:47:08 sending: inv (1261 bytes) peer=33900
2016-02-26 05:47:08 sending: inv (109 bytes) peer=32460
2016-02-26 05:47:08 sending: inv (37 bytes) peer=34501
2016-02-26 05:47:08 sending: inv (217 bytes) peer=33897
2016-02-26 05:47:08 sending: inv (145 bytes) peer=41863
2016-02-26 05:47:08 sending: inv (37 bytes) peer=35725
2016-02-26 05:47:08 sending: inv (73 bytes) peer=20567
2016-02-26 05:47:08 sending: inv (289 bytes) peer=44703
2016-02-26 05:47:08 sending: inv (73 bytes) peer=13408
2016-02-26 05:47:09 sending: inv (649 bytes) peer=41279
2016-02-26 05:47:09 sending: inv (145 bytes) peer=42612
2016-02-26 05:47:09 sending: inv (325 bytes) peer=34525
2016-02-26 05:47:09 sending: inv (181 bytes) peer=41174
2016-02-26 05:47:09 sending: inv (469 bytes) peer=41460
2016-02-26 05:47:10 sending: inv (973 bytes) peer=133
2016-02-26 05:47:10 sending: inv (361 bytes) peer=20541
Twiddling here doesn't change the asymptotic efficiency though; which
is what my post is about.
[I'm also somewhat surprised that you were unaware of this; one of the
patches "classic" was talking about patching out was the one restoring
the batching... due to a transaction deanonymization service (or
troll) claiming it interfered with their operations.]

2023-06-07 17:49:16

- reply

📅 Original date posted:2016-02-25
📝 Original message:On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm interested in input and in the level of receptiveness to this. If
> there is interest, I'll write up a draft BIP in the next couple days.
The design of segwit was carefully constructed to make it maximally
easy and safe to soft-fork in future script enhancements after its
deployment with the specific goal of avoiding indefinite delays in its
deployment from inevitable scope creep from additional things that are
"easy" to deploy as part of segwit. I think to be successful we must
be absolutely ruthless about changes that go in there beyond the
absolute minimum needed for the safe deployment of segwit... so I
think this should probably be constructed as a new segwit script type,
and not a base feature.
The exact construction you're thinking of there isn't clear to me...
one thing that comes to mind is that I think it is imperative that we
do not deploy a without-inputs SIGHASH flag without also deploying at
least a fee-committing sighash-all. The reason for this is that if
hardware wallets are forced to continue transferring input
transactions to check fees or to use without-inputs, they may choose
the latter and leave the users needlessly exposed to replay attacks.
When you do write a BIP for this its imperative that the vulnerability
to replay is called out in bold blinking flaming text, along with the
necessary description of how to use it safely. The fact that without
input commitments transactions are replayable is highly surprising to
many developers... Personally, I'd even go so far as to name the flag
SIGHASH_REPLAY_VULNERABLE. :)

2023-06-07 17:46:14

- reply

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 8:13 AM, Chris Priest <cp368202 at ohiou.edu> wrote:
> Lets say it's 2050 and I want to sweep a paper wallet I created in
> 2013. I can't just make the TX and send it to the network, I have to
> first contact an "archive node" to get the UTXO data in order to make
> the TX. How is this better than how the system works today?
You already are in that boat. If your paper wallet has only the
private key (as 100% of them do today). You'll have no idea what coins
have been assigned to it, or what their TXids are. You'll need to
contact a public index (which isn't a service existing nodes provide)
or synchronize the full blockchain history to find it. Both are also
sufficient for jl2012's (/Petertodd's STXO), they'd only be providing
you with somewhat more data. If instead, you insist that you'd
already be running a full node and not have to wait for the sync, then
again you'd also be your own archive. In none of these cases do you
lose anything.

2023-06-07 17:46:14

- reply

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 9:17 AM, Chris Priest <cp368202 at ohiou.edu> wrote:
>> In none of these cases do you lose anything.
>
> Nor do you gain anything. Archive nodes will still need to exist
Not every node is an archive node; that's even the case today.
Lowering the resource requirements to independently enforce the rules
of the system is highly virtuous.
> precisely because paper wallets don't include UTXO data. This is like
> adding the ability to partially seed a movie with bittorrent.
[...]
> Every paper wallet would have to be re-printed with UTXO data
They are not printed now with UTXO data
(txid:vout:scriptpubkey:amount), and unless you start and fully
synchronize (or are running a full node) you already cannot author a
transaction without that data. The private key is already not enough,
and no Bitcoin node will just give you what you need to know.
The only additional information JL2012's scheme would add would be the
hash tree fragments to show membership; and the same places that
currently give you what is required to author a transaction could
provide it for you.
> included. It doesn't even solve the core problem because someone can
> still flood the network with lots of UTXOs, as long as they spend them
> quickly.
The system already inhibits the rate new UTXO can be added; but we're
still left with the perpetually growing history that contains many
lost and otherwise unspendable outputs.

2023-06-07 17:46:13

- reply

📅 Original date posted:2015-12-13
📝 Original message:On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> have run a node/kept their utxo before they were aware of this change and
> then realise miners have discarded their utxo. Oops?
I believe you have misunderstood jl2012's post. His post does not
cause the outputs to become discarded. They are still spendable,
but the transactions must carry a membership proof to spend them.
They don't have to have stored the data themselves, but they must
get it from somewhere-- including archive nodes that serve this
purpose rather than having every full node carry all that data forever.
Please be conservative with the send button. The list loses its
utility if every moderately complex idea is hit with reflexive
opposition by people who don't understand it.
Peter Todd has proposed something fairly similar with "STXO
commitments". The primary argument against this kind of approach that
I'm aware of is that the membership proofs get pretty big, and if too
aggressive this trades bandwidth for storage, and storage is usually
the cheaper resource. Though at least the membership proofs could be
omitted when transmitting to a node which has signaled that it has
kept the historical data anyways.

2023-06-07 17:46:08

- reply

📅 Original date posted:2015-12-10
📝 Original message:On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 4. Sum of fee, sigopcount, size etc as part of the witness hash tree: for
I should have also commented on this: the block can indicate how many
sum criteria there are; and then additional ones could be soft-forked
in. Haven't tried implementing it yet, but there you go. :)

2023-06-07 17:46:07

- reply

📅 Original date posted:2015-12-10
📝 Original message:On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> It seems the current consensus is to implement Segregated Witness. SW opens
> many new possibilities but we need a balance between new features and
> deployment time frame. I'm listing by my priority:
> 2. Deployment time frame: I prefer as soon as possible, even if none of the following new features are implemented.
Thanks, I agree there.
A point to keep in mind: Segregated Witness was specifically designed
to make script changes / improvements / additions / total rewrites no
harder to do _after_ SW then they would be do do along with it. For
many people the "ah ha! lets do this" was realizing it could be a
pretty clean soft-fork. For me, it was realizing that we could
structure Segwit in a way that radically simply future script updates
... and in doing so avoid a getting trapped by a rush to put in every
script update someone wants.
This is achieved by having the 'version' byte(s) at the start of the
witness program. If the witness program prefix is unrecognized it
means RETURN TRUE. This recaptures the behavior that seems to have
been intended by OP_VER in the earliest versions of the software, but
actually works instead of giving every user the power to hardfork the
system at any time. :) This escapes much of the risk in script
changes, as we no longer need to worry about negation, or other
interactions potentially breaking things. A new version flag can have
its whole design crafted as if it were being created on a clean slate.
Optimizing layout and such I think makes sense, but I think we should
consider any script enhancements completely off the table for SW;
otherwise the binding will delay deployment and increase complexity. I
want most of those things too (a couple I disagree with) and a few of
them we could do quite quickly-- but no need to bind them up; post SW
and esp with version bits we could deploy them quite rapidly and on
their own timeframes.
> Multiplication and division may still considered to be risky and not very useful?
Operations like these make sense with fixed with types, when they are
over arbitrary bignums, they're a complexity nightmare... as
demonstrated by Bitcoin. :)
RE: OP_DUPTOALTSTACK yea, I've wanted that several times (really I've
been sad that there isn't just a stack flag on every manipulation
instruction).

2023-06-07 17:45:42

- reply

📅 Original date posted:2015-12-09
📝 Original message:On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler <rryananizer at gmail.com> wrote:
>>I agree, but nothing I have advocated creates significant technical
>>debt. It is also a bad engineering practice to combine functional
>>changes (especially ones with poorly understood system wide
>>consequences and low user autonomy) with structural tidying.
>
> I don't think I would classify placing things in consensus critical code
> when it doesn't need to be as "structural tidying". Gavin said "pile on"
> which you took as implying "a lot", he can correct me, but I believe he
> meant "add to".
Nothing being discussed would move something from consensus critical
code to not consensus critical.
What was being discussed was the location of the witness commitment;
which is consensus critical regardless of where it is placed. Should
it be placed in an available location which is compatible with the
existing network, or should the block hashing data structure
immediately be changed in an incompatible way to accommodate it in
order to satisfy an ascetic sense of purity and to make fraud proofs
somewhat smaller?
I argue that the size difference in the fraud proofs is not
interesting, the disruption to the network in an incompatible upgrade
is interesting; and that if it really were desirable reorganization to
move the commitment point could be done as part of a separate change
that changes only the location of things (and/or other trivial
adjustments); and that proceeding int this fashion would minimize
disruption and risk... by making the incompatible changes that will
force network wide software updates be as small and as simple as
possible.
>> (especially ones with poorly understood system wide consequences and low
>> user autonomy)
>
> This implies there you have no confidence in the unit tests and functional
> testing around Bitcoin and should not be a reason to avoid refactoring.
> It's more a reason to increase testing so that you will have confidence when
> you refactor.
I am speaking from our engineering experience in a public,
world-wide, multi-vendor, multi-version, inter-operable, distributed
system which is constantly changing and in production contains private
code, unknown and assorted hardware, mixtures of versions, unreliable
networks, undisclosed usage patterns, and more sources of complex
behavior than can be counted-- including complex economic incentives
and malicious participants.
Even if we knew the complete spectrum of possible states for the
system the combinatioric explosion makes complete testing infeasible.
Though testing is essential one cannot "unit test" away all the risks
related to deploying a new behavior in the network.