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

nprofile1qqsy4fk0n2ju36v0gqw6ccpudggzqagfk6s8x9m8d6wkv90n6ugr6ucpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds30ze4a

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet

Show more details

Last Notes

2023-06-09 14: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 14: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 20:16:54

- reply

📅 Original date posted:2019-03-06
📝 Original message:On Wed, Mar 6, 2019 at 12:32 AM Amine Chakak via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The idea has been floated around to switch to satoshi as a base unit.
If Satoshi wanted the currency units named after him, he would simply
have done it. I think this behaviour seems creepy and is harmful to
Bitcoin.
> The lightning network uses satoshis as a base unit.
It absolutely does not. Lightning uses units of 10 picobitcoin (1e-11
btc), which is significantly smaller.
> Pleas let me know if it would be appropriate to write a BIP for it.
Please don't.

2023-06-07 20:16:48

- reply

📅 Original date posted:2019-03-12
📝 Original message:On Wed, Mar 13, 2019 at 12:42 AM Jacob Eliosoff via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Also, if future disabling isn't the point of making a tx type like OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite support of these oddball features, what do we gain by making them hard to use/mine?
It makes them infeasible to abuse without miner assistance... which
doesn't fix them, but in practice greatly reduces the risk they create
and allows efforts improving the system to be allocated to other more
pressing issues.
> I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white. We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc.
Don't underestimate the value of taking a principled position that
*strongly* avoids confiscating user funds. Among many other benefits
being cautious about this avoids creating a situation where people are
demanding human intervention to restore improperly lost funds and the
associated loss of effort that would come from the effort wasted
debating that.
It's true that most other cryptocurrencies proceed without any such
caution or care-- e.g. bcash recently confiscating all funds
accidentally sent to segwit using Bitcoin addresses because of their
reckless address aliasing as a result of promoting the standardness
rule that made those txn non-standard before segwit without
considering the implications--, but they're not the standard we should
hold Bitcoin to...
> Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far.
All things in balance: Codeseperator and its related costs are not an
especially severe problem. The arguments on both side of this point
have enough merit to be worth discussing, at least.

2023-06-07 20: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 20:16:37

- reply

📅 Original date posted:2019-03-12
📝 Original message:On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> These two cases are understood and handled by current code. Generally
> the idea is take reject messages serious, but don't overrate the lack
> of. Luckily, network confirmations fill the gap. (Yes, a timeout is
I'd like to better understand this, but it would be easier to just
read the code than ask a bunch of questions. I tried looking for the
handling of reject messages in Android Bitcoin Wallet and BitcoinJ
and didn't really find and handling other than logging exceptions.
Would you mind giving me a couple pointers to where in the code
they're handled?

2023-06-07 20: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 20: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 20:15:04

- reply

📅 Original date posted:2018-10-24
📝 Original message:On Wed, Oct 24, 2018 at 3:52 PM Chris Belcher via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Thanks for bringing our attention to this important topic.
>
> According to (https://p2sh.info/dashboard/db/bip-69-stats) around 60% of
> transaction follow bip69 (possibly just by chance).
A two input randomly ordered transaction has a 50% chance of
'following' bip-69. So 60% sound like a small minority.

2023-06-07 20:14:51

- reply

📅 Original date posted:2018-09-25
📝 Original message:It's generally not /too/ important where ideas come from, even in our
open source non-patent encumbering world the only compensation people
get for sharing a good idea is the credit they receive. Most of the
time people are still happy to see their ideas further developed, even
if credit isn't sufficiently given.
But I'm particularly disappointed when attribution gets withheld in
the furtherance of political attaks. In some cases people have adopted
public positions that e.g. Bitcoin developers don't care about
scalability and then show that, by comparison, they care by publishing
work explaining/elaborating the scaling work of Bitcoin devs, but to
maintain consistency with their claims go through an extended effort
to avoid attributing them.
In two cases so far, I've painstakingly walked through an idea with a
political opponent in the Bitcoin space in private, only to have them
turn around and present the ideas I argued into their heads as novel
inventions without a shred of credit to me or the Bitcoin development
community.
One of them was the case of Peter R and the subchains paper, which I
previously forwarded to the list the correspondence between myself and
him where I argued the concept of preconsensus as part of his disproof
of the orphaning-controls-capacity claim.
The other is on compact fraud proofs with Justus Ranvier (again, a BU
person). I promptly complained directly to Justus when I saw him doing
it. I'm now forwarding to the list for posterity, because after almost
two years and several pings, I was never even given a response.
This came up to my attention today because V. Buterin published a
paper on lite client security ( https://arxiv.org/pdf/1809.09044.pdf )
that was apparently unaware of proposals from our community on sampled
anti-withholding[1]. ... and this paper cites Justus' writeup as both
the only example of fraud proofs previously, and evidence that
sampling coded data was not previously considered.
[1] e.g. https://download.wpsoftware.net/bitcoin/wizards/2015-04-18.html
starting at "The improvement we have is this". Error coded
anti-withholding been discussed many times-- and I've been pretty
bummed that I've been unable to excite people much about the idea,
hopefully that will change with the eth hype machine behind it--, but
this particular citation is while not the earliest or clearest
description, perfect for this case since the context is that it's a
complaint that the same author was failing to cite our communities
past efforts on fraud proofs, and as a result they weren't aware of
the state of the art like anti-withholding.
---------- Forwarded message ---------
From: Gregory Maxwell <gmaxwell at gmail.com>
Date: Fri, Nov 25, 2016 at 9:46 PM
Subject: A plea for ethical behavior
To: Justus Ranvier <justusranvier at gmail.com>
https://www.reddit.com/r/btc/comments/5evvth/fraud_proofs/
I spent _hours_ explaining how this technology would work to you on
reddit in private message, walking you through arguments on it.
Pointing out some of the details.
I also originally introduced the idea of compact fraud proofs to the
community (though the general idea was that of Bitcoin's creator,
without the compact-- just the unworkable kind) and was the first
person to enumerate the missing components for it.
Yet, the idea here is attribute solely to you, leaving me erased from history.
This isn't right. It is especially offensive because the same parties
affiliated with BU use this plagiarism as a proof point that they are
scaling innovators while I am not, -- the height of absurdity when
they do it with ideas I invented and introduced to them.
Mike Hearn didn't have the integrity to credit Matt for the invention
of thinblocks; instead he was happy to have other people misrepresent
the history, I think you are a better person than him and hope you
will say something.
------

2023-06-07 20:14:50

- reply

📅 Original date posted:2018-09-22
📝 Original message:On Sat, Sep 22, 2018 at 7:22 PM sickpig at gmail.com <sickpig at gmail.com> wrote:
> > For some reason I don't understand, Andrea Suisani is stating on
> > twitter that the the report by awemany was a report of an inflation
> > bug, contrary to the timeline we published.
>
> guess that the fact you don't understand it, it's probably related to the fact
> that you didn't read properly the tweet you are referring to, for reference this
> the tweet URL https://twitter.com/sickpig/status/1043530088636194816
>
> This is the text of such a tweet
OKAY. The only tweet I was shown was this one:
https://twitter.com/sickpig/status/1043428373530390528
It doesn't many any mention to him not reporting it and I encountered
it in the context of another person citing it to claim it had been
reported.
> Furthermore as you should be aware, having been copied on the report,
> awemany specifically
> said that "[the assert(is_spent)] *seems* to prevent the worse outcome
> of monetary inflation"
Yes, in fact I referred to the that specifically in my message as well
as including his entire message in my post.
> I guess that in the hurry of informing you and other people involved of the DoS
> vector he identified and proved, he decided to give priority to
> informing Core about that
> rather than waiting and continue exploring the idea he had about exploiting the
> code to create coins out of thin air.
I'm unclear what you're now stating. Are you stating that awemany knew
that it could
cause inflation but indicated otherwise to us or are you stating that
he did not know and
in the abundance of caution he sent the report as fast as possible
before making that
determination?
I'm just asking because I'm confused by your response; I don't think
it's particularly important one way or another.

2023-06-07 20:14:37

- reply

📅 Original date posted:2018-09-06
📝 Original message:Functionality such as this does not currently exist not because no one
thought of it before, but because it has been proposed many times
before and determined to be harmful. The existing design of CLTV/CSV
were carefully constructed to make it impossible for a transaction to
go from valid to invalid based on the time. The most naive
construction-- e.g. push the current time/height on the stack-- would
have that property and was specifically avoided.
When a spend goes from valid to invalid it means that a reorganization
will destroy coins even completely absent any dishonest actions of the
coins prior owner in the coins recent casual history. Effectively a
coin with any kind of non-monotone validity event in its recent
history functions like a recently generated coin: a coin that reorgs
destroy. Bitcoin addresses the issue for recently generated coins by
not permitting their use for 100 blocks. I've yet to see an argument
for a use case for non-monotone validity that still sounds useful once
the negative effects are addressed (e.g. by subjecting coins that have
gone through them to a maturity limitation).

2023-06-07 20:14:33

- reply

📅 Original date posted:2018-09-06
📝 Original message:On Thu, Sep 6, 2018 at 11:33 PM Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Now you can argue that the attacker is storing encrypted traffic today to decrypt it later.
That is the argument. We know for that state level parties are storing
unimaginable amounts of data for future decryption, that threat isn't
theoretical.
> Sure,
> but if that's your threat model then Bitcoin is probably not the right tool for you. (And if
Why not?
> you insist that Bitcoin is the right tool, then you can and probably should use it over Tor
> anyway.)
Currently, Tor provides _no confidentiality at all_ in that threat
model. Part of why I think this enhancement is interesting is because
without it BIP151 doesn't actually add anything for those p2p
connections running over Tor, but with it -- it at least adds some
long term confidentiality hedge.
> It's not worth the hassle, would hinder adoption,
Why do you say this?
> impression of "bulletproof" security. Even worse, there will be too many people that will suddenly
> assume that Bitcoin is post-quantum secure.
People already make that claim with respect to public key hashing. I
don't think "we shouldn't improve security because someone will
mistake an improvement for perfection" is an an especially interesting
argument.
> Key exchange indistinguishable from random
> ==========================================
> I would rather love to see a simple ECDH key exchange as currently used but with an encoding of
> public key that provides indistinguishability from random bitstrings. "Elligator" does not work
> but "Elligator Squared" [1] does the job for secp256k1 -- it just doubles the size of the public
Here is where I turn the argument around on you: This requires
writing a non-trivial amount of moderately complex new cryptographic
code (which is not the case for PQ schemes-- that merely requires
dropping in pre-existing code) and yet I am not aware of any attack
model that this which would any improvement in actually delivered
security: Bitcoin traffic is _trivially_ identifiable by its traffic
patterns.
(Blockstream previously wrote the SW forward transform for asset
generation, but this requires the inverse too, as well as glue code.
It also isn't clear to me if it's possible to make this construction
constant time, which would be okay for BIP151 purposes but if we
wanted to have a generic uniform encoder in libsecp256k1 I think we'd
prefer it be constant time? maybe?)
The scheme in the BIP thus far achieves the property that there are no
fixed bytes for brain-dead byte matching DPI traffic filtering or
anti-virus to match on (or accidentally false positive on). AV false
positives are already an existing problem with the current protocol
and any fixed bytes in the communication are at risk for false
positives or targeted filtering. And achieving that property
requires basically nothing: a test for the first byte of a generated
serialized pubkey and a negate on the private key if it was wrong.
> key. Together with the encrypted packet lengths, the entire data stream looks like random then,
No, it doesn't-- due to traffic analysis. Including, for example, the
pattern that 64-bytes must be sent in each direction, before further
data continues, bursts of traffic coinciding with blocks newly found
on the network, etc.
I don't believe that indistinguishable keys are actually useful
outside of the context of things like stegnographic embedding-- cases
where protocol 'metadata' doesn't tell you that a key is there
regardless.
I suppose if the code already existed to do it I might as well go
"okay, sure why not", it's not going to harm anything (the added
computation time to generate the uniform encoding would probably be no
more than a 10% slowdown). I wouldn't argue against it on the basis
that someone might believe it resulted in anti-censorship properties
that it doesn't have ... even though it's clearly the case... because
I categorically reject that form of argument. :)
I think your view on the two distinctive proposals is askew: PQ
agreement has a clear benefit under a plausible threat model and is
quite easy to implement... while uniform encoding is somewhat harder
to implement (though admittedly not very hard) but doesn't appear to
provide a concrete benefit under any threat model that I'm currently
aware of...
> The key derivation can be improved. It should include each peer's understanding of its role,
> i.e., requester (or "initiator" is the more common term) or responder. At the moment, an attacker
> can create a situation where two peers think they're in the same session (with the same session
> id) but they're actually not. Also, it's possible for an attacker to rerandomize the public keys.
> That's nothing bad by itself but anything which restricts the flexibility of the attacker without
> adding complexity is a good idea. Something like
> "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should just avoid this issue.
I also prefer the contributory key model, but Pieter proved me on IRC
last week that the attack form that I was concerned about was not
possible.
Do you actually have an attack in mind that you can spell out here? I
don't see a harm in changing that, but given that I'd already twice
talked myself out of proposing the same thing, I'd like to understand
if I'm missing something. :)
> Re-keying
> =========
> The problem with signalling re-keying in the length field is that the length field is not covered
> by the MAC.
It's AAD data in the mac, unless I misunderstand the protocol.
> Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey
> every 10 seconds
That would be pretty harmless, since the rekeying operation costs
similar to one message decryption.
> and implementations that just don't rekey at all (rendering the 10 s rekeying
> interval in the opposite direction useless).
The protocol requires rekeying at least after a given amount of data
is transmitted. Peers that violate that can be disconnected. But it
could be unfortunately infrequent.
> Different policies also make it possible to
> fingerprint implementations.
I agree that is a good point.
Personally I'd prefer that we used a ciphersuite that effectively
"rekeyed" every message-- along the lines of the constructions
described https://blog.cr.yp.to/20170723-random.html Unfortunately I
was unable to find _any_ well analyized authenticated encryption mode
that has the fast erasure property. It's too bad because it would be
trivial to adhoc one (e.g. use the extra 32 bytes from the poly1305
chacha run to update the keys for the next message).
> What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much
It doesn't much matter, except for fingerprinting reasons.
> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but
> again both are reasonable choices.)
Here we have a very clear motiviation. On devices without hardware
AES/clmul constant time AES-GCM is _terribly slow_ compared to
ChaCha20/Poly1305. Performance on the slowest devices is where the
the ones where the ciphersuite choice likely matters at all (because
it could actually make a meaningful difference in their system's
ability to keep up), and the slowest devices that I'm aware of users
commonly using are also devices without good AES-GCM performance.
Unfortunately.
On fast desktop hardware the performance of AES-GCM and
ChaCha20/Poly1305 is also fairly close.
So when it matters, chacha20/poly1305 is higher performance by a wide
margin. (Too bad, because otherwise I'd much rather use AES-GCM)
> I didn't think about this in detail: maybe there are a few meaningful cases where padding could
> hide the message length without too much overhead. (I'm not convinced, just a random thought.)
This can be done at the message level. E.g. new TX messages that round
tx sizes up to the next multiple. I don't think useful low overhead
padding is otherwise possible.
> written in stone, again to avoid complexity and to avoid fingerprinting.
Writing things in stone is a great way to never finish a protocol.
Right now we know we have new upcoming proposals for messages where
the overhead matters, e.g. we need a replacement addr message ASAP,
and there is ongoing work for transaction relay that would also
benefit from low overhead.
The norm in Bitcoin is to ignore messages you don't know how to parse
anyways, so there is no complexity that arises from "may negotiate"
itself-- only from actually making use of that possibility in the
future, so the merits of any particular usage could be decided when
something wants to actually use it. The purpose of pointing out "may
negotiate" is, I think, primarily to avoid a debate about who would
assign numbers from this limited space in the future-- and the answer
just is that they're implementation defined (e.g. by the BIPs using
them).
> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you want to debug your code
> or some random network failure but that's hard anyway when encryption is used.
Right, encryption kills external analysers in any case. It's also easy
to just logprintf traffic (this is open source software after all),
which doesn't have a decoding problem.
> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, every peer updates its
> own sending key, so this should just read "sent" instead of "sent or received"?
I think it says 'received there' mostly because it's implicitly
telling you that you can hang up on someone who violates it. I agree
it would be more consistent to express it sending side there.

2023-06-07 20:14:31

- reply

📅 Original date posted:2018-09-11
📝 Original message:On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty <erik at q32.com> wrote:
>
> - Musig, by being M of M, is inherently prone to loss.
M of M is a particular threshold. If you want M of M (there are
plenty of cases where M of M _must_ be used) then you get the
consequences of M of M, which presumably you want.
This has nothing to do with musig. If you want a threshold other than
M of M then you use a threshold other than M of M.
No one is under the impression that M of M is somehow a replacement
for other thresholds. We've spent more time talking about M of M in
some writeups in the past because it's exactly the case you need for
signature aggregation in Bitcoin and because it's a simpler case to
explain.
> - Having the senders of the G*x pubkey shares sign their messages with the associated private key share should be sufficient to prevent them from using wagner's algorithm to attack the combined key.
Yes, that is one possibility which is described in the musig paper,
but it requires users communicate an extra signature per key. So, for
example, if used with aggregate signature it would completely
eliminate the communications efficiency gains from aggregation, making
aggregation worse than pointless. It also has somewhat worse failure
properties than delinearization, because a signer that fails to
validate other's share signatures behaves behaves exactly the same as
a correct one, on honest inputs. That approach has its uses but I
think that in any case where delinearization can be used it's a better
option.

2023-06-07 20: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 20: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 20: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 20: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 20:14:06

- reply

📅 Original date posted:2018-08-13
📝 Original message:An alternative is to require reading either or but also require
writing without the witness. It's likely that two years from now,
nothing will write the witnesses, and the requirement to support
reading them could be dropped.
On Mon, Aug 13, 2018 at 8:32 PM Achow101 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Since the BIP is already in proposed status, I think that we should specify the non-witness utxo to just be "witness or non-witness" serialization. This maintains compatibility with things that have already implemented but also maintains the forwards compatibility that is needed.
>
> Andrew
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On August 13, 2018 11:56 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hello all,
> >
> > BIP174 currently specifies that non-witness UTXOs (the transactions
> > being spent by non-witness inputs) should be serialized in network
> > format.
> >
> > I believe there are two issues with this.
> >
> > 1. Even in case the transaction whose output being spent itself has a
> > witness, this witness is immaterial to PSBT. It's only there to be
> > able to verify the txid commits to the output/amount being spent,
> > which can be done without witness.
> >
> > 2. "Network format" is a bit ambiguous. We can imagine a future
> > softfork that introduces a new type of witness. Network format could
> > be interpreted as including that new witness type, which is clearly
> > unnecessary (by the above argument), and would gratuitously break
> > compatibility with existing signers if implemented pedantically.
> >
> > So my suggestion is to update the specification to state that
> > non-witness UTXOs must be serialized without witness. If it's too late
> > for that, it should instead be updated to explicitly specify with or
> > witnout witness, but it's safe to drop the witness.
> >
> > Opinions?
> >
> > Cheers,
> >
> > --
> > Pieter
> >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:14:02

- reply

📅 Original date posted:2018-08-05
📝 Original message:Coinr8d posted on bct that the node software would process large
locators limited only by the maximum message size yet sensible usage
of locators only results in messages of log2(n_blocks) size. He was
concerned that it might be a DOS vulnerability but quick measurements
indicated to me that it likely wasn't worse than many other protocol
messages. It still seems silly to allow absurd locators. So I propose
that the size of locators be limited.
However, capping them is a P2P change that could potentially result in
network splits if older nodes would potentially produce larger
locators (esp if triggered to produce unexpectedly large ones by
forks). A quick survey of node software indicated that no software I
could find would ever produce a locator with more than 42 hashes
before encountering other limits, so I think a limit of 64 will be
automatically compatible with all or virtually all nodes on the
network.
I'm bothering writing a BIP because there might be some naive
implementation lurking out there that sends a crazy number due to
sub-exponential backoff that would be broken by nodes enforcing a
limit... particularly since the correct use of locators was never
previously mandated and might not be obvious to all developers.
I take the opportunity to also specify that the locators be correctly
ordered in terms of total work, but don't specify that they all come
from the same chain.
Cheers,
==Introduction==
===Abstract===
This document proposes limiting the locator messages used in the getblocks
and getheaders to 64 entries and requiring that be ordered by total
work.
===Copyright===
This document is licensed under the 2-clause BSD license.
==Motivation==
The Bitcoin P2P protocol uses a simple and efficient data structure
to reconcile blockchains between nodes called a locator. A locator
communicates a list of known hashes which allows a peer to find a
recent common ancestor between the best chains on two nodes. By
exponentially increasing the space between each entry, the locator
allows a log() sized message to find the difference between two nodes
with only a constant factor overhead.
Because short forks are much more common than long forks the typical
usage of the locator includes a small number of topmost hashes before
switching to exponential spacing.
The original Bitcoin implementation provided no explicit limit to the
number of hashes in a locator message, allowing for absurd and
wasteful uses like including
all hashes in a chain.
Although locators are very inexpensive for existing node software to
process there is no known utility for sending very large locators.
To reduce the worst case cost of processing a locator message it would
be useful if the size of locator messages were strictly
bounded to sensible levels.
Common implementations have implicit limitations of 2^32 blocks and an
exponent of 2 after the first 10 locators and so could never request
more than 42 hashes in any case.
== Specification ==
A locator included in a getblock or getheaders message may include no more
than 64 hashes, including the final hash_stop hash. Additionally, the blocks
referenced by the locator must be in order of equal or decreasing total
work.
Sending a locator that violates these requirements may result in normal
processing, the message being ignored, a disconnection, or a ban.
Implementations that seek to handle larger numbers of blocks than afforded
by this limit with an exponent of 2 can adaptively switch to a larger
exponent as required to stay within the limit.
== Acknowledgements ==
Thanks to Coinr8d on bitcointalk for pointing out that node software would
process and respond to locators with about 125,000 hashes in them.

2023-06-07 20:13:46

- reply

📅 Original date posted:2018-07-09
📝 Original message:On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> and where H(g*x) can
> be considered their public index for the purposes of Shamir polynomial
> interpolation
This is isomorphic to the insecure musig variant where keys are
blinded by H(g*x) instead of a commitment to all keys. It is insecure
because it vulnerable to an attacker knowing a victim pubkey P who
uses wagner's algorithim to solve a random modular subset sum problem:
-1H(P) = H(aP)/a + H(bP)/b + H(cP)/c + ... for some a,b,c... then
claiming to be participants with keys aP, bP, cP, ..., xG (their own
key) and canceling out key P, allowing the value to just be signed for
with their key alone.
AFAICT your suggestion is using simple multiplication in the place of
a cryptographic hash. E.g. you have just suggested a schnorr
signature where H() is just r*m in the field of size n. It doesn't
have any new properties about how you can use it. The same linearities
do and don't apply as the normal schnorr construction, but for any of
the security proofs to hold we'd have to believe that multiplication
in the field of n is a suitable random oracle-- which is not very
plausible.

2023-06-07 20:13:43

- reply

📅 Original date posted:2018-07-09
📝 Original message:On Mon, Jul 9, 2018 at 4:33 PM, Erik Aronesty <erik at q32.com> wrote:
>>> with security assumptions that match the original Schnorr construction more closely,
>> More closely than what?
> More closely than musig.
Musig is instructions on using the original schnorr construction for
multiparty signing which is secure against participants adaptively
choosing their keys, which is something the naive scheme of just
interpolating keys and shares is vulnerable to. It works as
preprocessing on the keys, then you continue on with the naive
protocol. The verifier (e.g. network consensus rules) is the same.
Now that you're back to using a cryptographic hash, I think what
you're suggesting is "use naive interpolation of schnorr signatures"
-- which you can do, including with the verifier proposed in the BIP,
but doing that alone is insecure against adaptive key choice (and
potentially adaptive R choice, depending on specifics which aren't
clear enough to me in your description). In particular, although it
seems surprising picking your interpolation locations with the hash of
each key isn't sufficient to prevent cancellation attacks due to the
remarkable power of wagner's algorithm.

2023-06-07 20:13:42

- reply

📅 Original date posted:2018-07-09
📝 Original message:On Mon, Jul 9, 2018 at 3:02 PM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> with
> security assumptions that match the original Schnorr construction more
> closely,
More closely than what?

2023-06-07 20:13:40

- reply

📅 Original date posted:2018-07-08
📝 Original message:On Sun, Jul 8, 2018 at 3:16 PM, Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> so what
> you want is possible already with Schnorr signatures.
As also described in "Multisignatures and Threshold Signatures" in the BIP.

2023-06-07 20:13:38

- reply

📅 Original date posted:2018-07-06
📝 Original message:On Fri, Jul 6, 2018 at 9:05 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the inputs to hash were reordered as hash(bytes(dG) || bytes(x(R)) || m)
> then there is an opportunity for SHA256 expander to be partially prefilled
> for a fixed public key. This could provide a little benefit, especially
> when multiple signatures for a single public key need to be generated and/or
> verified. If all things are otherwise equal, perhaps this alternate order
> is better.
There is a minor design preference to have message before nonce when
H() is a MD-style hash function. Say the attacker knows some weakness
in H and can find pairs of messages m and m' so that the compression
function results in the same midstate. He could then ask you to sign
m but get a signature that also works for m'. If the signer
controlled R value comes first, then this doesn't work. The pubkey
being where it is in the current design just follows from the idea
that it is just logically prepended on the message. I don't think the
pubkey is sufficiently attacker controlled that the above argument
would apply, so H(P || R.x || m) would be okay.
BUT, the sha256 compression function reads 64 bytes at a time. PRM
would not let you precompute a whole compression function run, but
instead would just let you hardwire part of the expander in a pubkey
dependant way-- an optimization I'm pretty confident virtually no one
would use. (Hardwiring to a constant, yes. Hardwiring to a reused
dynamic value that comes in from the network, no)
If instead the hash function were defined as using 31 zeros then
P||R||m (or P || 31 zeros bytes || R || m, I'm not sure what would be
better), an entire midstate could be cached for different pubkeys. m
is often 32 bytes, sadly- - but the final compression run in that case
would only be the constant update with the length.... and
almost-all-zeros + constant length, is an easy optimization. (Bitcoin
core even has it for computing sha256(sha256())).
[I'm not really sure if I was clear, so I'll try TLDRing it: I think
optimizing sha256 where part of the input is constant is realistic,
optimizing midstate reuse is realistic, optimizing where part is
reused is less realistic. If we insert padding, and put P first, we
can make it possible to midstate cache P, and the 'extra' compression
function run ends up with all constant input, so it could be made
faster.]

2023-06-07 20:13:38

- reply

📅 Original date posted:2018-07-06
📝 Original message:On Fri, Jul 6, 2018 at 10:00 PM, Gregory Maxwell <greg at xiph.org> wrote:
> There is a minor design preference to have message before nonce when
::sigh:: to NOT have the message before the nonce.

2023-06-07 20:13:34

- reply

📅 Original date posted:2018-07-11
📝 Original message:On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think that's a particularly useful policy, but certainly
> Signers are allowed to implement any policy they like about what they
> accept in signing.
Do we really want the specification to permit conforming
implementations to refuse to sign because there is extra metadata?
ISTM this would make it very hard to implement new features that
require extra data. For example, say you have a checkmultisig with one
key in it using schnorr multisignature which require the extra rounds
to establish an R, and the other keys are legacy stuff. If the other
signer(s) suddenly stop working when there are extra fields irrelevant
to them, then this will create a substantial pressure to not extend
the PSBT in the intended way, but to instead find places to stuff the
extra data where it won't interfere with already deployed signers.
This would be really unfortunate since PSBT was created specifically
to avoid field stuffing (otherwise we could have accomplished all the
intended goals by field stuffing a bitcoin transaction encoding).
Obviously no signer should be signing data they don't understand, but
extra data that they ignore which doesn't change their signature
should not stop them. Another way of looking at it, perhaps somewhere
someplace some idiot defined signatures starting with 0xdead to give
away all the users funds or whatever. That's something you "can't
understand" either, ... but no one would conclude because something
could happen somewhere that you don't know about that you just can't
sign at all... yet it is possible. :)
If someone wants to make a non-conforming signer, that is cool too and
they may have good reason to do so-- but I think it would be sad if
new applications get gunked up, slowed down or forced to use ugly
hacks, due to the intentional extension support in the protocol being
blocked by things claiming to support the spec. The whole reason the
spec doesn't lock in exactly the possible fields and allow no others
is to allow extensions without breaking compatibility.

2023-06-07 20: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 20: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 20: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 20:12:51

- reply

📅 Original date posted:2018-06-26
📝 Original message:On Tue, Jun 26, 2018 at 12:12 AM, Bradley Denby via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> That's right, the idea is to choose Dandelion relays independently from
> whether they support Dandelion. If the chosen nodes do not support
> Dandelion, then the transactions are fluffed. Otherwise, the transactions
> are relayed along a stem.
I don't see any problem with doing that... Although an additional
countermeasure we're likely to take against attacks on partial
deployment is that we'd likely make the wallet's use of stem
forwarding be a configuration option which is initially hidden and set
to off. In a subsistent release after dandelion propagation is widely
deployed we'd unhide the option and default it to on. This way users
don't begin using it until the deployment is relatively dense.
I believe this approach is a is sufficient such that it could always
select out-peers that were dandelion capable without harm, but at the
same time I also don't see a reason that we can't do both.
(in fact, for privacy reasons we might want to three-stage the
deployment, with the use of dandelion by wallets having a setting of
off, sometimes, or always so that attackers can't so easily correlate
the use of dandelion with upgrades.)

2023-06-07 20:12:44

- reply

📅 Original date posted:2018-06-05
📝 Original message:On Tue, Jun 5, 2018 at 1:08 AM, Jim Posen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> hesitant to make the complexity tradeoff for bandwidth savings due to a
> behavior that is actively discouraged.
As an important point of clarification here. If scripts are used to
identify inputs and outputs, then no use is required for that savings.
Each coin spent was created once, so in an absurd hypothetical you can
get a 2:1 change in bits set without any reuse at all. I don't know
what portion of coins created are spent in the same 144 block
window...

2023-06-07 20:12:42

- reply

📅 Original date posted:2018-06-09
📝 Original message:> So what's the cost in using
> the current filter (as it lets the client verify the filter if they want to,
An example of that cost is you arguing against specifying and
supporting the design that is closer to one that would be softforked,
which increases the time until we can make these filters secure
because it slows convergence on the design of what would get
committed.
>> I don't agree at all, and I can't see why you say so.
>
> Sure it doesn't _have_ to, but from my PoV as "adding more commitments" is
> on the top of every developers wish list for additions to Bitcoin, it would
> make sense to coordinate on an "ultimate" extensible commitment once, rather
> than special case a bunch of distinct commitments. I can see arguments for
> either really.
We have an extensible commitment style via BIP141 already. I don't see
why this in particular demands a new one.
> 1. The current filter format (even moving to prevouts) cannot be committed
> in this fashion as it indexes each of the coinbase output scripts. This
> creates a circular dependency: the commitment is modified by the
> filter,
Great point, but it should probably exclude coinbase OP_RETURN output.
This would exclude the current BIP141 style commitment and likely any
other.
Should I start a new thread on excluding all OP_RETURN outputs from
BIP-158 filters for all transactions? -- they can't be spent, so
including them just pollutes the filters.
> 2. Since the coinbase transaction is the first in a block, it has the
> longest merkle proof path. As a result, it may be several hundred bytes
> (and grows with future capacity increases) to present a proof to the
If 384 bytes is a concern, isn't 3840 bytes (the filter size
difference is in this ballpark) _much_ more of a concern? Path to the
coinbase transaction increases only logarithmically so further
capacity increases are unlikely to matter much, but the filter size
increases linearly and so it should be much more of a concern.
> In regards to the second item above, what do you think of the old Tier Nolan
> proposal [1] to create a "constant" sized proof for future commitments by
> constraining the size of the block and placing the commitments within the
> last few transactions in the block?
I think it's a fairly ugly hack. esp since it requires that mining
template code be able to stuff the block if they just don't know
enough actual transactions-- which means having a pool of spendable
outputs in order to mine, managing private keys, etc... it also
requires downstream software not tinker with the transaction count
(which I wish it didn't but as of today it does). A factor of two
difference in capacity-- if you constrain to get the smallest possible
proof-- is pretty stark, optimal txn selection with this cardinality
constraint would be pretty weird. etc.
If the community considers tree depth for proofs like that to be such
a concern to take on technical debt for that structure, we should
probably be thinking about more drastic (incompatible) changes... but
I don't think it's actually that interesting.
> I don't think its fair to compare those that wish to implement this proposal
> (and actually do the validation) to the legacy SPV software that to my
> knowledge is all but abandoned. The project I work on that seeks to deploy
Yes, maybe it isn't. But then that just means we don't have good information.
When a lot of people were choosing electrum over SPV wallets when
those SPV wallets weren't abandoned, sync time was frequently cited as
an actual reason. BIP158 makes that worse, not better. So while I'm
hopeful, I'm also somewhat sceptical. Certainly things that reduce
the size of the 158 filters make them seem more likely to be a success
to me.
> too difficult to implement "full" validation, as they're bitcoin developers
> with quite a bit of experience.
::shrugs:: Above you're also arguing against fetching down to the
coinbase transaction to save a couple hundred bytes a block, which
makes it impossible to validate a half dozen other things (including
as mentioned in the other threads depth fidelity of returned proofs).
There are a lot of reasons why things don't get implemented other than
experience! :)

2023-06-07 20:12:40

- reply

📅 Original date posted:2018-06-08
📝 Original message:On Fri, Jun 8, 2018 at 5:03 AM, Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> As someone who's written and reviews code integrating the proposal all the
> way up the stack (from node to wallet, to application), IMO, there's no
> immediate cost to deferring the inclusion/creation of a filter that includes
> prev scripts (b) instead of the outpoint as the "regular" filter does now.
> Switching to prev script in the _short term_ would be costly for the set of
> applications already deployed (or deployed in a minimal or flag flip gated
> fashion) as the move from prev script to outpoint is a cascading one that
> impacts wallet operation, rescans, HD seed imports, etc.
It seems to me that you're making the argument against your own case
here: I'm reading this as a "it's hard to switch so it should be done
the inferior way". That in argument against adopting the inferior
version, as that will contribute more momentum to doing it in a way
that doesn't make sense long term.
> Such a proposal would need to be generalized enough to allow several components to be committed,
I don't agree at all, and I can't see why you say so.
> likely have versioning,
This is inherent in how e.g. the segwit commitment is encoded, the
initial bytes are an identifying cookies. Different commitments would
have different cookies.
> and also provide the necessary extensibility to allow additional items to be committed in the future
What was previously proposed is that the commitment be required to be
consistent if present but not be required to be present. This would
allow changing whats used by simply abandoning the old one. Sparsity
in an optional commitment can be addressed when there is less than
100% participation by having each block that includes a commitment
commit to the missing filters ones from their immediate ancestors.
Additional optionality can be provided by the other well known
mechanisms, e.g. have the soft fork expire at a block 5 years out
past deployment, and continue to soft-fork it in for a longer term so
long as its in use (or eventually without expiration if its clear that
it's not going away).
> wallets which wish to primarily use the filters for rescan purposes can't
> just construct them locally for this particular use case independent of
> what's currently deployed on the p2p network.
Absolutely, but given the failure of BIP37 on the network-- and the
apparent strong preference of end users for alternatives that don't
scan (e.g. electrum and web wallets)-- supporting making this
available via P2P was already only interesting to many as a nearly
free side effect of having filters for local scanning. If it's a
different filter, it's no longer attractive.
It seems to me that some people have forgotten that this whole idea
was originally proposed to be a committed data-- but with an added
advantage of permitting expirementation ahead of the commitment.
> Maintaining the outpoint also allows us to rely on a "single honest peer"security model in the short term.
You can still scan blocks directly when peers disagree on the filter
content, regardless of how the filter is constructed-- yes, it uses
more bandwidth if you're attacked, but it makes the attack ineffective
and using outpoints considerably increases bandwidth for everyone
without an attack. These ineffective (except for increasing
bandwidth) attacks would have to be common to offset the savings. It
seems to me this point is being overplayed, especially considering the
current state of non-existing validation in SPV software (if SPV
software doesn't validate anything else they could be validating, why
would they implement a considerable amount of logic for this?).

2023-06-07 20: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 20:12:38

- reply

📅 Original date posted:2018-06-01
📝 Original message:On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>> A typical network attacker (e.g. someone on your lan or wifi segmet, or
>> someone who has compromised or operates an upstream router) can be all of
>> your peers.
>
> This is true, but it cannot make us accept any invalid filters unless the
> attacker is also creating invalid blocks w/ valid PoW.
I wish that were the true, but absent commitments that wouldn't be the
case unless you were always downloading all the blocks-- since you
wouldn't have any sign that there was something wrong with the
filter-- and downloading all the blocks would moot using the filters
in the first place. :)
Or have I misunderstood you massively here?
For segwit originally I had proposed adding additional commitments
that would make it possible to efficiently prove invalidity of a
block; but that got stripped because many people were of the view that
the "assume you have at least one honest peer who saw that block and
rejected it to tell you that the block was invalid" security
assumption was of dubious value. Maybe it's more justifiable to make
use of a dubious assumption for a P2P feature than for a consensus
feature? Perhaps, I'd rather have both filter types from day one so
that things not implementing the comparison techniques don't get the
efficiency loss or the extra work to change filter types for a
consensus one.
[I think now that we're much closer to a design that would be worth
making a consensus committed version of than we were a few months ago
now, since we are effectively already on a second generation of the
design with the various improvements lately]

2023-06-07 20:12:37

- reply

📅 Original date posted:2018-06-01
📝 Original message:On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> One notable thing that I left off is the proposed change to use the previous
> output script rather than the outpoint. Modifying the filters in this
> fashion would be a downgrade in the security model for light clients, as it
Only if you make a very strong assumption about the integrity of the
nodes the client is talkign to. A typical network attacker (e.g.
someone on your lan or wifi segmet, or someone who has compromised or
operates an upstream router) can be all of your peers.
The original propsal for using these kinds of maps was that their
digests could eventually be commited and then checked against the
commitment, matching the same general security model used otherwise in
SPV.
Unfortunately, using the scripts instead of the outpoints takes us
further away from a design that is optimized for committing (or, for
that matter, use purely locally by a wallet)...

2023-06-07 20:12:31

- reply

📅 Original date posted:2018-05-30
📝 Original message:On Wed, May 30, 2018 at 6:30 AM, shiva sitamraju via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The idea to add birthdate and gap limit sounds very good and addresses lots
> of problems users are facing.
>
> However, adding birthday to keys breaks two basic properties
>
> - Visually Comparing two keys to find if they are same (Important)
Can you explain exactly what you mean there? I can think of to
plausible meanings (that two valid keys could differ by only a single
symbol, which wouldn't be true due to the checksum and could be made
even stronger if we thought that would be useful or I think you could
also be complaining that the same "key material" could be encoded two
ways which I think is both harmless and unavoidable for anything
versioned).
> - Different wallet software could set different birthday/gap limit. creating
> different xpub/xprv for the same set of mathematically derived individual
> keys. This removes the decoupling between key and wallet metadata
Personally, I think it's a mistake to believe that any key format can
really make private keying material strongly compatible between
wallets. At best you can hope for a mostly compatible kind of recovery
handling.
But the lookahead amount may be pretty integral to the design of the
software, so signaling it may not mean the other side can obey the
signal... but that wouldn't make the signal completely useless.

2023-06-07 20: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 20: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 20: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 20: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 20: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 20: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 20: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 20: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 20: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 20:12:08

- reply

📅 Original date posted:2018-05-17
📝 Original message:On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Tl;dr: Rather than storing all unspent outputs, store their hashes.
My initial thoughts are it's not _completely_ obvious to me that a 5%
ongoing bandwidth increase is actually a win to get something like a
40% reduction in the size of a pruned node (and less than a 1%
reduction in an archive node) primarily because I've not seen size of
a pruned node cited as a usage limiting factor basically anywhere. I
would assume it is a win but wouldn't be shocked to see a careful
analysis that concluded it wasn't.
But perhaps more interestingly, I think the overhead is not really 5%,
but it's 5% measured in the context of the phenomenally inefficient tx
mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).
Napkin math on the size of a txn alone tells me it's more like a 25%
increase if you just consider size of tx vs size of
tx+scriptpubkeys,amounts. If I'm not missing something there, I think
that would get in into a very clear not-win range.
On the positive side is that it doesn't change the blockchain
datastructure, so it's something implementations could do without
marrying the network to it forever.

2023-06-07 20:11:28

- reply

📅 Original date posted:2018-04-03
📝 Original message:On Mon, Apr 2, 2018 at 10:18 PM, Gleb Naumenko via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
> I have a couple of ideas regarding transaction relay protocol and wanted to
> share it with and probably get some feedback.
https://bitcointalk.org/index.php?topic=1377345.0
https://people.xiph.org/~greg/mempool_sync_relay.txt

2023-06-07 20:10:53

- reply

📅 Original date posted:2018-02-17
📝 Original message:On Fri, Feb 16, 2018 at 10:49 PM, Johnson Lau via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since we have a block weight limit of 4,000,000 and sigop limit of 80,000,
> each sigop could not use more than 50 weight unit on average. For new script
> proposals we could count the actual number of sigop at execution (i.e. skip
> unexecuted sigop, skip 0-size signature, count the actual checksig
> operations in multi-sig), and make sure the number of executed sigop * 50 is
> not greater than the size of the input.
We have a related policy rule in Bitcoin Core for some time now, the
weight of the transaction for the purpose of mining is
max(weight,lambda*sigops), though we set lambda a bit lower than makes
sense due to how checkmultisig. This policy rule replaced an earlier
one which was almost equivalent to your proposal: it rejected
transactions with too many sigops per the byte count, but we found it
block actual more or less sensible transactions.
Going forward I don't think this is a great framework. It works if
the only expensive operations all involve large input data, but I
think many proposals people have made for new operations would have
computational cost which requires relatively small amounts of
additional input-- aggregation is just one fairly minor example.

2023-06-07 20:10:51

- reply

📅 Original date posted:2018-02-14
📝 Original message:On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote:
>> BIP 123 suggests that BIPs in the consensus layer should be assigned a
>> label "soft fork" or "hard fork". However, I think the differentiation
>> into soft fork or hard fork should not be made for BIPs that document
>> buried deployments. In contrast to soft forks and hard forks, buried
>> deployments do not require community and miner coordination for a safe
>> deployment.
>
> They also do not require software coordination. Therefore, why should there be
> BIPs at all? Seems to me that we should instead add these documents to
> https://github.com/bitcoin-core/docs
In that sense, no but they help people understand the system (e.g. so
they don't go look at implementations and confuse that the activations
they expect are simply not there); and they aid other implementations
in understanding what other people have already analyzed and concluded
was safe. You could certainly get an analysis wrong for one of these
things.

2023-06-07 20:10:30

- reply

📅 Original date posted:2018-02-24
📝 Original message:On Thu, Feb 22, 2018 at 7:44 PM, Daniel Edgecumbe via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think that binding grafts to a particular transaction requires this aggregation.
> It seems to me that you could just sign H(txid, script) rather than H(script).
> I'm not aware of whether this would break aggregation.
That would require that you know the txid in advance. Sometimes you
do-- and a graftroot sighash flag could handle that... but usually you
wouldn't. The case where you already do know it can sort of be
covered today without using the graftroot: Sign a transaction
spending the multisig coin to the graft. This isn't a strict
alternative however, because it's not atomic: you could imagine that
txn being announced and then the graft not being spent, while someone
would like to spend a different graft. That non-atomiticity could be
addressed by making the graft spends an OR of all the other graft
spends but that isn't scalable or private. Regardless, still doesn't
work if the graft isn't created after the fact.
The aggregation bit has the property of working just in time, even on
grafts created in advance.

2023-06-07 20: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 20: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 20: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 20:10:20

- reply

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm not sure who cooked up this myth about miners gaining advantage over
> those who buy block space by mining empty space, rejecting higher-fee
> transactions, and/or mining "recovery" transactions, but the idea is
> complete nonsense.
I agree.
Steel-manning it, I guess I could argue that empty blocks are slightly
more conspicuous and might invite retaliation especially given the
high levels of mining centralization creates retaliation exposure. ...
but dummy transactions are hardly less conspicuous, many nodes log now
when blocks show up containing txn that they've never seen before.
Moreover, inexplicably underfilled blocks are produced (e.g. by
bitmain's antpool) and no retaliation seems to be forthcoming.

2023-06-07 20:10:20

- reply

📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil <eric at voskuil.org> wrote:
> Block space created by a miner is property that belongs to the miner, it
> can be sold or not sold.
That case would be stronger when there is no more subsidy, but we
collectively the uses of Bitcoin are currently paying miners around
$130k USD per block in the form of inflation for the job of honestly
complying with the Bitcoin protocol.
I don't think you can argue that they have any more right to do that
than any of us have a right to run software that invalidates their
coinbase outputs when they do; which would be the sort of retaliation
they might get targeted with.

2023-06-07 20:10:16

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, Jan 24, 2018 at 11:16 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
> Then what about
> https://blockchain.info/tx/226a8b08dc46a00e9ecec5567a303a0b354bef3c1674476eb5e4b627b2ace493?format=hex
> ?
>
> Scriptsig:
>
> 473044022057a1234709270325e7215200f982546304cf465971cbd55d54231ead54ef1a7802207a82e93ef2b0f87188abe87bccb67ee9d5c650b1b58948e5b1c80ba1b4c43dc301
>
> No pubkey...
Because the pubkey is in the scriptPubKey of vout 0 of
40872a376e98a1f8b285827c2ad8c5b3eec7d779d752dc3a4adda5d9bb70f3b5 which
it is spending.

2023-06-07 20: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 20:10:15

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, Jan 24, 2018 at 10:24 AM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
> out the fact that pubkey is there now even for standard p2pkh
> transactions and it was not the case some time ago
>
> But I never got any answer regarding what motivated this change
> (compared to the previous behavior) and when, so whether I am missing
> something obvious, whether nobody wants to answer
No such behaviour ever existed, you are simply mistaken.

2023-06-07 20:10:12

- reply

📅 Original date posted:2018-01-26
📝 Original message:On Tue, Jan 23, 2018 at 12:30 AM, Gregory Maxwell <greg at xiph.org> wrote:
> 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.
Keeping in mind that a single public point can stand in for any
monotone function of public keys, a taproot branch is only needed for
accountability (being able to tell from public data which branches
were used) or when conditions other than public keys are required e.g.
CSV + a monotone function of keys.
I believe that with scriptless-scripts most of hash preimages can be
accomplished without an actual hash pre-image condition.
Are there other simple and very useful/general preconditions that
would be useful ANDed with a monotone function of public keys like is
the case for CSV?
I ask because recursive taproot by itself isn't very interesting,
since (other than accountability) there is no gain to not just merging
the alternative, but if there are additional conditions then it can be
useful. E.g.
[pubkey]
\-[pubkey]&&CSV
\-[fancy script]
So it might make sense to support a taproot construction that can
nest, where interior nested keys have a CSV/CLTV predicate. But are
there other simple predicates that cover a lot of cases?
[Aside: _please_ change the subject lines for further discussion about
quantum computers;]

2023-06-07 20: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 20: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 20: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 20: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 20: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 20: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 20:09:54

- reply

📅 Original date posted:2018-01-19
📝 Original message:Not really all that on-topic, but since it was suggested to me that
this would be an efficient venue to reach others who might care to
know:
In order to spend more time working independently on deep protocol
work, especially new cryptographic privacy and security technology for
Bitcoin, I resigned from Blockstream last November. It took until the
end of December to wind down my involvement there.
Back when we founded the company I was concerned that there was
significant underinvestment in Bitcoin technology: Bitcoin had a
healthy technical community just as it does today, but lacked the kind
of industry support that projects like Linux have. Without sustained
financial support, some kinds of bigger projects seemed really hard to
pull off with developers needing to share time between non-bitcoin
employment, their families, and their other interests. For the most
part, back then early Bitcoin companies weren't investing in public
technology, at least not effectively.
We hoped that Blockstream could help act as an anchor of support for
technology development, and in doing so help grow the community. I
think that has been a big success. The Bitcoin industry has matured a
lot and today Bitcoin Core gets significant regular contributions from
many organizations (including Chaincode, DCI, Blockstream, Coinbase,
Bitmain, Blockchain, and probably others that I am forgetting or not
even aware of) and a volunteer community much larger and more active
than it has ever been before. From what I've been told Blockstream
plans to continue to contribute to awesome technology in Bitcoin--as
demonstrated by their Lightning webstore this week--but if they
didn't, that wouldn't be a problem for Bitcoin.
So for me this means that I can go back to working on the things I
find most exciting ... without the overhead of managing staff or
dealing with the many non-Bitcoin blockchain applications which are
important to Blockstream's business. The maturing Bitcoin industry
means I don't need to worry that Bitcoin development could be left
with inadequate financial support.
I'm very excited about all the new and interesting technology that is
coming to production--Bulletproofs / CT, signature aggregation,
improved propagation and synchronization--as well as the continuing
maturation of Bitcoin as a viable subject matter for academic
researchers. I'll be spending more time helping with these and other
things, and will no longer have insight into Blockstream's activities
or a Blockstream email address (I can continue to be reached at my
xiph.org and gmail email addresses as I've used here in the past), but
otherwise this shouldn't change anything for anyone here.
Cheers,

2023-06-07 20:09:40

- reply

📅 Original date posted:2018-01-16
📝 Original message:On Tue, Jan 16, 2018 at 1:06 AM, Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The rule AFAICT is "standard transactions must still work". This was
> violated with low-S, but the transformation was arguably trivial.
That is my view, generally. Like any other principle, its
applicability is modulated by the specific facts.
For low-s the most critical mitigating specific facts were (in order
of importance): Any third party could malleate non-conforming
transactions to make them conform and that code to do this was written
and run, that S-value malleation was being actively attacked at the
time, and that the intention to eventually enforce lowS had been made
clear a long time ahead and the vast majority of transactions were
already conforming.
In particular these facts meant that the change could not result in
the confiscation of funds except in the case of a key-destroyed
unconfirmed chain of timelock transactions which was already highly
vulnerable due to the malleation attacks -- and even there, the
non-standardness step itself wouldn't destroy the funds esp. given the
malleation risk redemption of that sort of chain would probably be
best accomplished with the collaboration of a miner.

2023-06-07 20:09:33

- reply

📅 Original date posted:2018-01-17
📝 Original message:On Wed, Jan 17, 2018 at 11:39 AM, Ondřej Vejpustek via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Consider a few notes:
> * Nowadays there exists more complicated variants of mentioned attacks
> which have weaker premisses.
> * There is a considerable similarity between RSA and SSS. Both schemes
> are algebraically-based (rather than boolean function based).
I'm sorry but I must not be following your message. I read the above
as "these are similar because they are based on math"...
Shamir secret sharing, correctly implemented (which indeed seems to be
many parties problem...) achieves information theoretic security. In
this critical sense it is utterly unrelated to RSA.
In fact this applies generally given any fixed threashold-1 set of
shares there is an value of the final remaining share which decodes to
every possible message. So without knowing of an extra share you know
nothing of the message.
The simplest demonstration is the 2 of 2 case, which can most simply
be constructed over GF(2) as in the traditional "one time pad":
message = share1 xor share2. For any given share1 or given share2
there exist a value of share2 or share1 respectively which yields
every possible message.
If the generalization isn't obvious, it might be helpful to make a
little test utility that tries all possible one byte messages with all
possible share values using the GF(256) sharing scheme proposed in the
draft-- in this case information theory is why we can know SSS (and
similar) have (within their limited scope) _perfect_ security, rather
than it being a reason to speculate that they might not turn out to be
secure at all. (or, instead of a test utility just work through some
examples on paper in a small field).
This doesn't change when you add additional conditionals on it-- e.g.
Say you a 2-of-3 sharing where you have your choice of any of the
three shares but do not know the others and assume you know every bit
of the plaintext save one bit or any linear or non-linear relationship
between plaintext bits (excepting for actually knowing the secret)...
In these case there can still be no attack arising out of this
charitably bad plaintext structure because-- as pointed out above--
all possible plaintexts are equal-probable you know nothing of which
of the two possible solutions is correct without knowing about the
other shares because for each possible value there exists a value for
the unknown shares which would cause that decoding-- there is no
leakage at all, the share doesn't teach you anything you didn't
already know.
In my view any SSS tool should also include a forgery utility which
demonstrates this property, both as a critical test-- but also because
being able to forge an alternative answer to deceive an attacker which
has compromised some of your shares is one of the (at least
theoretical) arguments for using SSS over computational secret
sharing.
> unless it is introduced in a complicated way
Complicated does not mean secure. And from an information theoretic
perspective the hash does almost nothing (other then some small
destruction of entropy due to its lack of perfect uniformity which is
information theoretically equivalent to using a smaller perfect code).
There are many cases where I too am more comfortable using a hash --
where it may destroy some structure which I cannot _prove_ would be
safe to retain, but this is not one of those cases.
> * CRCs (and error-correcting codes generally) introduce redundancy
into the message
The discussion of using a proper code was primarily related to the
outer check value which protects the shares themselves and is sitting
unprotected in plaintext; not so much the one inside the sharing in
any case; since its the outer one which could be structured to provide
perfect detection of errors that align with words (e.g. transposing
two words).

2023-06-07 20:09:33

- reply

📅 Original date posted:2018-01-18
📝 Original message:On Thu, Jan 18, 2018 at 1:50 PM, Ondřej Vejpustek
<ondrej.vejpustek at satoshilabs.com> wrote:
> (1) Our proposal doesn't use SSS for the whole secret, but it divides
> the secret into bytes and uses SSS for every byte separately. This
> scheme is weaker because to reconstruct n-th byte it suffices to have
> n-th bytes from k shares.
If being secure against partial share leakage is really part of your
threat model the current proposal is gratuitously insecure against it.
And the choice of check algorithm really doesn't matter for that.
For example, in a 2-of-3 share say I have the first half of shares
1,2 and the second half of shares 2,3 with the current proposal the
secret is directly revealed, even though I didn't have any single
complete share.
If partial share disclosure were an actual concern, I would recommend
that after sharing and before encoding for transmission (e.g. before
applying check values and word encoding to the share) the individual
shares be passed through a large block unkeyed cryptographic
permutation. Under reasonable-ish assumptions about the difficulty of
inverting the permutation with partial knowledge, this transformation
would prevent attacks from leaks of partial share information.

2023-06-07 20:09:32

- reply

📅 Original date posted:2018-01-17
📝 Original message:On Wed, Jan 17, 2018 at 3:28 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> it is impossible to break SSS.
Obligatory repeated point: if the scheme being used actually is SSS
and not a Shamir-Shaped-Sharing instead. This should go without
mention by my experience is that a great many things which claim to be
SSS aren't. Sometimes precisely because they stuck in some hashes in
arbitrary places and destroyed the properties (in fact, the really old
broken armory implementation effectively did that, and in fact
resulted in a real weakness not just a theoretical one).

2023-06-07 20: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 20: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 20:09:00

- reply

📅 Original date posted:2017-12-21
📝 Original message:On Fri, Dec 22, 2017 at 12:30 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Every transaction is replace-by-fee capable already. Opt-in replace by fee
> as specified in BIP 125 is a fiction that held sway only while the income
> from fees or fee replacement was so much smaller than subsidy.
The distinction is does a next fee replacement hit the next block 99%
of the time or does it do so with 10% probability each successive
block that the original remains unconfirmed; eventually converging to
the same 99% but only after a non-trivial additional delay. As a
result it's still useful to flip it on.
I believe electrum has been defaulting to opt-in without any big problems.
There was discussion in the bitcoin core weekly irc meeting today
about defaulting it on. Some expressed the view that perhaps it
should be left off by default for the RPC because some industrial
users but I'm of the view that those users are both most likely to
want it on and also the most able to see it in the release notes and
change their settings.

2023-06-07 20: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 20: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 20:08:41

- reply

📅 Original date posted:2017-12-12
📝 Original message:On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar <sdaftuar at gmail.com> wrote:
> But I think we should be able to get nearly all the benefit just by
> including nBits in any messages where the value is ambiguous; ie we include
> it with the first header in a message, and whenever it changes from the
> previous header's nBits.
Yes, that is what I was thinking last time we discussed it, just with
each header include a one byte flag that lets you express:
bit: meaning
(0) if nbits is the same as last,
(1) if timestamp is a full field or a small offset, (e.g. two bytes
defined as unsigned offset between the last time - 7200 and the new
time).
(2,3,4) if version is the same as the last distinct value .. 7th last,
or a new 32bit distinct value;
(5,6) if prev is entirely there, entirely gone, first 4 bytes
provided, or first 8 bytes provided. (if provided they override the
computed values).
That would be 7 bits in total; the 8th could be reserved or use to
signal "more headers follow" to make the encoding self-delimiting.
The downside with nbits the same as last as the optimization is that
if we ever change consensus rules to ones where difficulty management
works differently it may be the case that nbits changes every block.
Alternatively, nbits could get a differential encoding that could be
opted into for small differences-- though I haven't thought much about
it to see if a one byte difference would be that useful (e.g. can bch
differences usually be expressed with one byte?)
I'm kind of dubious of the consensus layer anti-dos separation: nbits
minimum is so low compared to the speed of a mining device, virtually
any attack that you might do with invalid headers could still be done
with headers at the minimum difficulty. But I'm fully willing to
accept that simpler is better...
>> I would rather not change the serialization of existing messages,
>> nodes are going to have to support speaking both messages for a long
>> time, and I think we already want a different protocol flow for
>> headers fetching in any case.
>
>
> I agree with this. Specifically the way I envisioned this working is that
> we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for
> syncing using this new message type, while leaving the existing
> 'headers'/'getheaders' messages unchanged. So when communicating with
> upgraded peers, we'd never use 'getheaders' messages, and we'd only use
> 'headers' messages for potentially announcing new blocks.
>
> Of course, we'll have to support the existing protocol for a long time. But
> one downside I've discovered from deploying BIP 130, which introduced block
> announcements via headers messages, is that overloading a 'headers' message
> to be either a block announcement or a response to a 'getheaders' message
> results in p2p-handling logic which is more complicated than it needs to be.
> So splitting off the headers chain-sync functionality to a new message pair
> seems like a nice side-effect benefit, in the long run.
>

2023-06-07 20:08:41

- reply

📅 Original date posted:2017-12-12
📝 Original message:On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar <sdaftuar at gmail.com> wrote:
> I agree with this. Specifically the way I envisioned this working is that
> we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for
> syncing using this new message type, while leaving the existing
> 'headers'/'getheaders' messages unchanged. So when communicating with
> upgraded peers, we'd never use 'getheaders' messages, and we'd only use
> 'headers' messages for potentially announcing new blocks.
The question becomes there-- how should it work.
In an ideal world, we'd decide what peers to fetch headers from based
on a compact proof of the total work in their chains... but we cannot
construct such proofs in Bitcoin today.
I think that instead of that a weak heuristic is to fetch first from
the peers with the tip at the highest difficulty. Then work backwards.
See: https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
Which is the inspiration for the current headers first sync, but
without the reverse part because the protocol didn't permit it: you
can't request a linear wad of headers that come before a header. This
is the thing I was mostly thinking of when I mentioned that we may
want to change the interface.

2023-06-07 20:08:40

- reply

📅 Original date posted:2017-12-11
📝 Original message:On Mon, Dec 11, 2017 at 10:41 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is a method called "high hash highway" that allows compact proofs of
> total POW.
That provides no security without additional consensus enforced
commitments, so I think pretty off-topic for this discussion.

2023-06-07 20:08:39

- reply

📅 Original date posted:2017-12-11
📝 Original message:On Mon, Dec 11, 2017 at 8:40 PM, Jim Posen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Firstly, I don't like the idea of making the net header encoding dependent
> on the specific header validation rules that Bitcoin uses (eg. the fact that
> difficulty is only recalculated every 2016 blocks). This would be coupling
In the last proposal I recall writing up, there was a one byte flag on
each header to indicate what was included.
Nbits _never_ needs to be sent even with other consensus rules because
its more or less necessarily a strict function of the prior headers.
This still holds in every clone of Bitcoin I'm aware of; sending it
with the first header in a group probably makes sense so it can be
checked independently.
> with insufficient benefit.
another >18% reduction in size beyond the removal of prev. is not
insubstantial by any means. I don't think it should lightly be
ignored.
Prev omission itself is not, sadly, magically compatible: I am quite
confident that if there is a bitcoin hardfork it would recover the
nbits/4-guarenteed always-zero bits of prev to use as extra nonce for
miners. This has been proposed many times, implemented at least once,
and the current requirement for mining infrastructure to reach inside
the coinbase txn to increment a nonce has been a reliable source of
failures. So I think we'd want to have the encoding able to encode
leading prev bits.
Many altcoins also change the header structures. If the better thing
is altcoin incompatible, we should still do it. Doing otherwise would
competitively hobble Bitcoin especially considering the frequent
recklessly incompetent moves made by various altcoins and the near
total lack of useful novel development we've seen come out of the
clones.
Probably the most important change in a new header message wouldn't be
the encoding, but it would be changing the fetching mechanism so that
header sets could be pulled in parallel, etc.
I would rather not change the serialization of existing messages,
nodes are going to have to support speaking both messages for a long
time, and I think we already want a different protocol flow for
headers fetching in any case.

2023-06-07 20:07:59

- reply

📅 Original date posted:2017-11-30
📝 Original message:This idea presumes that the protocol has any ability to regulate fees. I
believe the locally optimal strategy for both miners and payers alike is to
accept (pay) zero fees natively in the protocol and instead accept (pay)
their actual fees out-of-band or via OP_TRUE outputs which the miner can
simply collect. Then the miner sets the fee threshold to ~0 and selects
transactions on the basis of out of band fees.
Miners today already accept out-of-band fees, and as far back as at least
2011 there were miners that would also accept fees in the form of
additional transaction outputs which they were able to spend.
On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
>
> This idea presumes that the protocol has any ability to regulate fees. I
> believe the locally optimal strategy for both miners and payers alike is to
> accept (pay) zero fees natively in the protocol and instead accept (pay)
> their actual fees out-of-band or via OP_TRUE outputs which the miner can
> simply collect. Then the miner sets the fee threshold to ~0 and selects
> transactions on the basis of out of band fees.
>
> Miners today already accept out-of-band fees, and as far back as at least
> 2011 there were miners that would also accept fees in the form of
> additional transaction outputs which they were able to spend.
>
>
>
> On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Comrades,
>>
>> Long term, tx fees must support hash power by themselves. The following
>> is an economic approach to maximize total fee collection, and therefore
>> hashpower.
>>
>> *Goals*
>> Maximize total transaction fees
>> Reduce pending transaction time
>> Reduce individual transaction fees
>>
>> *Challenges*
>> Validators must agree on the maximum block size, else miners can cheat
>> and include extra transactions.
>> Allowing too many transactions per block will increase the cost of the
>> mining without collecting much income for the network.
>>
>>
>> *Problem*
>> In the transaction market, users are the demand curve, because they will
>> transact less when fees are higher, and prefer altcoins. The block size is
>> the supply curve, because it represents miners' willingness to accept
>> transactions.
>> Currently, the supply curve is inelastic:
>>
>> Increasing the block size will not affect the inelasticity for any
>> fixed block size. The downsides of a fixed block size limit are well-known:
>> - Unpredictable transaction settlement time
>> - Variable transaction fees depending on network congestion
>> - Frequent overpay
>>
>> *Proposal*
>> 1. Miners implicitly choose the market sat/byte rate with the
>> cheapest-fee transaction included in their block. Excess transaction fees
>> are refunded to the inputs.
>> 2. Remove the block size limit, which is no longer necessary.
>>
>> *Benefits*
>> - Dynamic block size limit regulated by profit motive
>> - Transaction fees maximized for every block
>> - No overpay; all fees are fair
>>
>> Miners individually will make decisions to maximize their block-reward
>> profit.
>> Miners are incentivized to ignore low-fee transactions because they would
>> shave the profits of their other transactions and increase their hash time.
>> Users and services are free to bid higher transaction fees in order to
>> reach the next block, since their excess bid will be refunded.
>>
>> The block size limit was added as a spam-prevention measure, but in order
>> for an attacker to spam the network with low-fee transactions, they would
>> have to offset the marginal cost of reducing the price with their own
>> transaction fees. Anti-spam is thus built into the marginal system without
>> the need for an explicit limit.
>>
>> Rarely, sections of the backlog would become large enough to be
>> profitable. This means every so many blocks, lower-fee transactions would
>> be included en masse after having been ignored long enough. Low-fee
>> transactions thus gain a liveness property not previously enjoyed: low-fee
>> transactions will eventually confirm. Miners targeting these transactions
>> would be at a noteworthy disadvantage because they would be hashing a
>> larger block. I predict that this scheme would result in two markets: a
>> backlog market and a real-time market. Users targeting the backlog market
>> would match the price of the largest backlog section in order to be
>> included in the next backlog block.
>>
>> *Examples*
>>
>> Scenario 1
>> Sat/byte Bytes Reward
>> 400 500000 200000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1500000 150000000
>> 50 5000000 250000000
>> 20 10000000 200000000
>> A miner would create a 5MB block and receive 0.25 BTC
>>
>> Scenario 2
>> Sat/byte Bytes Reward
>> 400 600000 240000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1800000 180000000
>> 50 4000000 200000000
>> 20 10000000 200000000
>> A miner would create a 600KB block and receive 0.24 BTC
>>
>> Thanks,
>> William Morriss
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/b113f2f5/attachment.html>

2023-06-07 20:07:57

- reply

📅 Original date posted:2017-11-30
📝 Original message:On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe this OOB scenario is imaginary. Either it would be more profitable
Out of band fees are a reality even today-- and have for most of
Bitcoin's life--, without a system that has any particular incentive
for them.
> for a miner to mine fairly, or cheaper for the end-user to pay the fee
> in-band. Consider MINFEE to the the effective fee paid for the block mined
> by the OOB-incentivized miner. Consider MARKFEE to the the market fee
> collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB.
> Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by Mark
> Friedenbach, the system disincentivizes OOB tx fees.
This kind of analysis seems to imagine that a single decision maker is
making a globally optimal decision and that also people are somehow
forced to only make one choice. Both are untrue in this case (and most
other economic circumstances). Instead, participants can take the best
of multiple choices and will often act locally for their own best
interest even when it reduces revenue for their industry in total.
Concretely: as a user with competent wallet software, I would be
automatically drafting two transactions-- one paying OOB and one
paying min fee, at equivalent expected rates. Miners would construct
blocks which locally maximized their revenue. It is far from clear
that use of the minfee scheme is an equilibrium-- in fact I think it
is clearly not an equilibrium: a user that writes both transactions
will always pay equal or less fees for the transactions where they do
both (even if all users doing this causes users collectively to pay
higher fees), a miner who considers both will always make equal or
greater fee income on a block by block basis (even if it lowers miner
income collectively when all do this).
(If it were in fact preferred by users and miners alike: why doesn't
it already exist? Since the existence of OOB fees cannot be
eliminated, as far as we know, any use of MINFEE would be inherently
voluntary-- so in one sense we already 'have' voluntary minfee, but no
one uses it.)
Ignoring the possibility of evasion, there are some other concerns
that you might want to consider:
I believe the idea converts variance in fee willingness into variance
in capacity for the network. If rich uncle bill wants to waste money
with uneconomically high fees, with a constant flow of transactions,
he'll effectively knock out a large number of participants. You could
argue that bill could spend those same fees in spam to displace the
same amount of transactions while also using more capacity; but I
UncleBill isn't trying to attack the capacity of the system. It's just
collateral damage. I worry also about related strategies that arise
in that world: For example, lets imagine that world consisted of a
couple unclebill who will pay high fees, and the unwashed masses that
will not and pay a much lower consistent feerate. Honest conformance
with your protocol would result in miners either processing only the
UncleBill txn or processing all of them at the lower rate, whichever
is more profitable. Super-rational behavior might be for a majority
of hashpower to collude to only permit high fee-rate transactions
every other block and only permit low feerate in the others, and then
the network processes all unclebills in one block (at full rate), and
all the unwashed in the others. From a fee perspective it arguably
isn't any worse than today, but I believe it significantly handicaps
your capacity limiting argument.
> wherein there is no penalty for arbitrarily favoring individual transactions with lower fees
Nor does a MINFEE system; since the user can near costlessly construct
as many variations of their transaction as they like.
> The hashpower of individual miners is not impressive compared to the entire network,
That is unfortunately not the reality of Bitcoin today.

2023-06-07 20:07:50

- reply

📅 Original date posted:2017-11-20
📝 Original message:On Mon, Nov 20, 2017 at 5:24 PM, Praveen Baratam via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Noob here. Please forgive my ignorance.
>
> From what I understand, in SegWit, the transaction needs to be serialized
> into a data structure that is different from the current one where
> signatures are separated from the rest of the transaction data.
>
> Why change the format at all? Why cant we just compute the Transaction ID
> the same way the hash for signing the transaction is computed?
That is effectively what segwit does, upto engineering minutia and
compatibility details.
Segwit does not serialize transactions in to a data structure where
signatures are separated from the rest of the transaction data; this
is a misunderstanding. The "segregated" refers to them being excluded
from the TXID. The serialization of segwit on the p2p network in
transactions and in blocks encodes the witness field inside the
transactions, immediately prior to the nlocktime field.

2023-06-07 20:07:43

- reply

📅 Original date posted:2017-11-13
📝 Original message:Jump to "New things here" if you're already up to speed on CT and just
want the big news.
Back in 2013 Adam Back proposed that Bitcoin and related systems could
use additive homomorphic commitments instead of explicit amounts in
place of values in transactions for improved privacy. (
https://bitcointalk.org/index.php?topic=305791.0 )
We've since adopted the name 'confidential transactions' for this
particular approach to transaction privacy.
This approach makes transaction amounts private--known only to the
sender, the receiver, and whichever parties they choose to share the
information with through sharing watching keys or through revealing
single transactions. While that, combined with pseudonymous addresses,
is a pretty nice privacy improvement in itself, it turns out that
these blinded commitments also perfectly complement CoinJoin (
https://bitcointalk.org/index.php?topic=279249.0 ) by avoiding the
issue of joins being decoded due to different amounts being used. Tim
Ruffing and Pedro Moreno-Sanchez went on to show that CJ can be
dropped into distributed private protocols for CoinJoin (
http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final6.pdf ) which
achieve the property where no participant learns which output
corresponds to which other participant.
The primary advantage of this approach is that it can be constructed
without any substantial new cryptographic assumptions (e.g., only
discrete log security in our existing curve), that it can be high
performance compared to alternatives, that it has no trusted setup,
and that it doesn't involve the creation of any forever-growing
unprunable accumulators. All major alternative schemes fail multiple
of these criteria (e.g., arguably Zcash's scheme fails every one of
them).
I made an informal write-up that gives an overview of how CT works
without assuming much crypto background:
https://people.xiph.org/~greg/confidential_values.txt
The main sticking point with confidential transactions is that each
confidential output usually requires a witness which shows that the
output value is in range. Prior to our work, the smallest range
proofs without trusted setup for the 0-51 bit proofs needed for values
in Bitcoin would take up 160 bytes per bit of range proved, or 8160
bytes needed for 51 bits--something like a 60x increase in transaction
size for a typical transaction usage.
I took Adam's suggestion and invented a number of new optimizations,
and created a high performance implementation. (
https://github.com/ElementsProject/secp256k1-zkp/tree/secp256k1-zkp/src/modules/rangeproof
). With these optimizations the size is reduced to 128 bytes per two
bits plus 32 bytes; about 40% of the prior size. My approach also
allowed a public exponent and minimum value so that you could use a
smaller range (e.g., 32 bits) and have it cover a useful range of
values (though with a little privacy trade-off). The result could give
proof sizes of about 2.5KB per output under realistic usage. But this
is still a 20x increase in transaction size under typical usage--
though some in the Bitcoin space seem to believe that 20x larger
blocks would be no big deal, this isn't a view well supported by the
evidence in my view.
Subsequent work has been focused on reducing the range proof size further.
In our recent publication on confidential assets (
https://blockstream.com/bitcoin17-final41.pdf ) we reduce the size to
96*log3(2)*bits + 32, which still leaves us at ~16x size for typical
usage. (The same optimizations support proofs whose soundness doesn't
even depend on the discrete log assumption with the same size as the
original CT publication).
-- New things here --
The exciting recent update is that Benedikt Bünz at Standford was able
to apply and optimize the inner product argument of Jonathan Bootle to
achieve an aggregate range proof for CT with size 64 * (log2(bits *
num_outputs)) + 288, which is ~736 bytes for the 64-bit 2-output case.
This cuts the bloat factor down to ~3x for today's traffic patterns.
Since the scaling of this approach is logarithmic with the number of
outputs, use of CoinJoin can make the bloat factor arbitrarily small.
E.g., combining 64 transactions still only results in a proof under
1.1KB, so in that case the space overhead from the range proof is
basically negligible.
The log scaling in the number of range-bits also means that unlike the
prior construction there is little reason to be skimpy with the number
of bits of range at the potential expense of privacy: covering the
full range of possible values takes only slightly longer proofs than
covering a short range. This scheme also has a straightforward and
efficient method for multi-party computation, which means that the
aggregates can be used in all-party-private coinjoins like the value
shuffle work mentioned above.
Unlike prior optimizations, verification in this new work requires
computation which is more than linear in the size of the proof (the
work is linear in the size of the statement being proved). So it's
likely that in spite of the small proofs the verification will be
similar in speed to the prior version, and likely that computation
will be the bottleneck. Andrew, Pieter, Jonas Nick, and I are working
on an optimized implementation based on libsecp256k1 so we'll know
more precise performance numbers soon.
This work also allows arbitrarily complex conditions to be proven in
the values, not just simple ranges, with proofs logarithmic in the
size of the arithmetic circuit representing the conditions being
proved--and still with no trusted setup. As a result it potentially
opens up many other interesting applications as well.
The pre-print on this new work is available at https://eprint.iacr.org/2017/1066

2023-06-07 20: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 20:06:28

- reply

📅 Original date posted:2017-09-29
📝 Original message:On Fri, Sep 29, 2017 at 12:45 PM, Andreas Schildbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 15+ Mio Coinbase users
Who's payment protocol SSL cert was expired for months without even
generating a post on reddit. Not exactly convincing there.
The fact that someone supports it doesn't mean its being used.

2023-06-07 20: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 20:06:15

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Also, even the old version lists some icons "based on Stephan Hutchings
> Typicons" as "License: MIT", which could be a violation of CC BY-SA if
> I'm not mistaken.
Relicensed by the copyright holder:
https://github.com/bitcoin/bitcoin/commit/dae0a89d4b66f08c83ccc8c20cf37521084b6257
(For future reference, git log -p <file> makes it easy to go find
where some string was last in a file, so you can look at the commit
that changed it.)

2023-06-07 20: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 20: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 20:04:47

- reply

📅 Original date posted:2017-08-15
📝 Original message:This construction appears to me to be completely insecure.
Say my pubkey (the result of the derivation path) is P.
We agree to contract C1. A payment is made to P + G*H(C1).
But in secret, I constructed contract C2 and pubkey Q and set P = Q + G*H(C2).
Now I can take that payment (paid to Q + G*(C1) + G*H(C2)) and assert
it was in act a payment to P' + G*H(C2). (P' is simply Q + G*H(C1))
I don't see anything in the proposal that addresses this. Am I missing it?
The applications are also not clear to me, and it doesn't appear to
address durability issues (how do you avoid losing your funds if you
lose the exact contract?).
On Mon, Aug 14, 2017 at 6:05 AM, omar shibli via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hey all,
>
> A lot of us familiar with the pay to contract protocol, and how it uses
> cleverly the homomorphic property of elliptic curve encryption system to
> achieve it.
> Unfortunately, there is no standard specification on how to conduct such
> transactions in the cyberspace.
>
> We have developed a basic trade finance application that relies on the
> original idea described in the Homomorphic Payment Addresses and the
> Pay-to-Contract Protocol paper, yet we have generalized it and made it BIP43
> complaint.
>
> We would like to share our method, and get your feedback about it, hopefully
> this effort will result into a standard for the benefit of the community.
>
> Abstract idea:
>
> We define the following levels in BIP32 path.
> m / purpose' / coin_type' / contract_id' / *
>
> contract_id is is an arbitrary number within the valid range of indices.
>
> Then we define, contract base as following prefix:
> m / purpose' / coin_type' / contract_id'
>
> contract commitment address is computed as follows:
> hash document using cryptographic hash function of your choice (e.g. blake2)
> map hash to partial derivation path
> Convert hash to binary array.
> Partition the array into parts, each part length should be 16.
> Convert each part to integer in decimal format.
> Convert each integer to string.
> Join all strings with slash `/`.
> compute child public key by chaining the derivation path from step 2 with
> contract base:
> m/<contract_base>/<hash_derivation_path>
> compute address
> Example:
>
> master private extended key:
> xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
> coin type: 0
> contract id: 7777777
>
> contract base computation :
>
> derivation path:
> m/999'/0'/7777777'
> contract base public extended key:
> xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE
>
> Contract content:
> foo
>
> Contract sha256 signature:
> 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
>
> Contract partial derivation path:
> 11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>
> Contract commitment pub key path:
> m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
> or
> <contract_base_extended_pub_key>/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310
>
> Contract commitment pub key:
> xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS
>
> Contract commitment address:
> 17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R
>
>
> You can find the full BIP draft in the following link:
> https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki
>
>
> Regards,
> Omar
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 20:04:25

- reply

📅 Original date posted:2017-07-12
📝 Original message:On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi!
>
> Up to now, I have purposefully been running bitcoin releases prior to
> 0.13.1 as a way to avoid the (possible) segwit activation, at least
> until such time as I personally am comfortable with it.
It is not simple to do so correctly, I couldn't tell you off the top
of my head; a number of things must be changed it isn't as simple as
disabling the activiation because of the segwit P2P changes. Nor is
it a supported configuration. Even if it were now, it wouldn't be one
we'd continue to support in the future after segwit is active, as
we're likely to drop deployment/compat code.
Can you explain why you wish to do this? It should have absolutely no
adverse impact on you-- if you don't use segwit, you don't use it-- it
may be the case that there is some confusion about the implications
that I could clear up for you... or suggest alternatives that might
achieve your goals.
Having a node that supports it won't make it more likely to activate,
you can mine without signaling segwit even on a node that supports it.
Your own transactions will not use segwit just because your node
supports it.
Effectively the only reason I'm aware of to intentionally not run with
segwit support beyond just not having upgraded yet, is a desire to try
to temporarily have as your tip block a block that was actively
stealing the segwit transactions of a third party. Which doesn't seem
either personally or publicly desirable; but I fully admit I may be
missing some good reason which I am not aware of.

2023-06-07 20: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 20:04:15

- reply

📅 Original date posted:2017-07-11
📝 Original message:I think it's great that people want to experiment with things like
drivechains/sidechains and what not, but their security model is very
distinct from Bitcoin's and, given the current highly centralized
mining ecosystem, arguably not very good. So positioning them as a
major solution for the Bitcoin project is the wrong way to go. Instead
we should support people trying cool stuff, at their own risk.
So, given that although the vast majority of the things in the document
are things I've been supporting for months (Please see Note 1 way down
at the bottom) I cannot support your document.
I think you may have have missed how much work I put into what I published
before talking with people who actually work on the project to find out
what they wouldn't object to before publishing the prior document--
and how much I left out that I would have loved to have in; and why
I specifically held back from describing it as a roadmap or prompting
people to sign onto it (though they did of their own accord).
On a more meta-subject, I think grandly stated "top down" roadmaps
in highly collaborative development are of minimal utility at best and
actively misleading at worst. Fundamentally, it misunderstands the nature
of peer collaboration. It's kind of like asking for a roadmap for the
development of fusion power; individual practitioners have their own
roadmaps, but the collaboration of science does not.
Consider an example,
The Linux kernel is one of the largest and best funded open source
projects, which produces the most widely used operating system kernel
in the world and one of the most widely used pieces of software of all
time, and it produces _no_ roadmaps.
Quoting Andrew Morton, "Instead of a roadmap, there are technical
guidelines. Instead of a central resource allocation, there are
persons and companies who all have a stake in the further development
of the Linux kernel, quite independently from one another: People like
Linus Torvalds and I don’t plan the kernel evolution. We don’t sit
there and think up the roadmap for the next two years, then assign
resources to the various new features. That's because we don’t have
any resources. The resources are all owned by the various corporations
who use and contribute to Linux, as well as by the various independent
contributors out there. It's those people who own the resources who
decide."
Linus remarked, "I look at the current release and the next one, as I
don't think planning 10 years ahead is sane."
Yet the Linux kernel still has every advantage over us: They have far
more contributing resources from far more sources, they have a fairly
centralized model and control over their own destiny because they have
a much more functional pathway to disagreement than we have in Bitcoin
for consensus rules.
IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
and release process once the basic technology is done; because it's
only past that point that guarantees can really start being made.
But that isn't what your document does-- it names a lot of things which
are still various shades of research at this point (much of it research
I'm working on and strongly support, in fact--)
We can also talk in a visionary sense about the sorts of things we're
exploring, but it just isn't possible to nail down when they'll be
ready until they are: If it's not something the linux kernel can do,
it's not something we can do. These are neat and existing ideas,
but not a roadmap.
At least not as a group. Individually contributing parties have a lot
more visibility and control into their own activities, and there is
virtue in forecasting at that level. Redhat, for example, has
roadmaps. They primarily deal with stabilization and support of
already existing technology that you could get in the raw from the
various upstream sources (fedora, kernel, etc.). (see for an example,
http://www.slideshare.net/albertspijkers/red-hat-enterprise-linux-roadmap
)
Separately, what we can do stably in Core is have timely reliable
releases. Juniper made it 10 years with regular timed releases that
did not slip by more than IIRC three days and which were _all_ production
deployable (things changed later, but thats another story).
This was an incredible benefit to our customers, but the only way it was
possible was because _features_ were not guaranteed in a release.
If a feature failed during the final testing and it needed more than the
most trivial of fixes, it was _removed_ or disabled. As soon as there
are multiple in-flight deliverables it becomes more important to be
timely over-all even that that significantly delays single deliverables.
This is effectively at odds with hard deadlines on functionality, even
before getting into the fact that for consensus features delivery in
software is irrelevant until activation which is a public election.
(E.g. we shipped segwit almost a year ago, but it still hasn't arrived
for users).
>From the perspective of Bitcoin I think what people are actually
asking for us to do is to (help) drive the Bitcoin Story-- the actual
technology and its timelines is usually not that relevant: if it were,
they'd be stepping up with resources to contribute to it. There are
many ways to do that, -- we don't have to use highly authoritarian
methods that wouldn't even work for the Linux kernel.
[And all these projects you listed, your help would be more than welcome!]
This can be done by a mixture of talking about research _as research_
not a done deal, and by moving discussions of non-research things to
where they're actually more forecastable. 98% of the public
discussion about segwit was before the pull request, -- there were
solid political reasons for this-- but it was the wrong timing. On
the case of CSV and CLTV, the general public didn't hear about them
until they were merged -- pretty much-- and the timing then was much
more compatible with 'roadmapping' +/- activation uncertainty.
Some of this is driven by competitive pressure with things like
Ethereum or other altcoins (e.g. dash, god save us) that have a lot
lower commitment to engineering integrity or even logical consistency.
We can't compete with technobabble bullshit, and we shouldn't try and
as a side effect back ourselves into a corner where we're making
remarkable accomplishments but regarded as failures in payment
(because we either forecast it taking N years, which is the best we
could promise, or because we forecast the best we might achieve and it
was both still too long and the timeframe got missed).
One of the big screwups with segwit handling was people sticking
some random unrealistic date on it it which was done AFAIK,
by well meaning folks who took some random numbers from people
working on it for when they'd be done with the development-- not the
testing, not the integration, and certainly not deployment and published
it as The Date. Then even though the development was actually done
by them, segwit was portrayed as massively delayed, because what
matters to the users is deployment-- which we can't control.
I see you've done this yourself with signature aggregation, sticking Q4 2016
right on it, which as far as I can tell is a figure that comes from mars.
(Well not quite mars, see Note 1)
Probably we'll have the research and an implementation done by then, but
with so much uncertainty around segwit activation, I doubt anyone can be
about when users will be able to use it (which is what they care about!)
It's also not really appropriate to ask people to sign onto stuff when they
can't even review it. Perhaps the signature aggregation stuff is insecure,
patent encumbered, or practically useless... (It won't be but no one could
tell that from your post; because it doesn't even exist as a concrete proposal)
I think people would rightly protest about a number of these things-- especially
things like the the agg sigs and tx compaction, "wtf, I've not heard
of this. Who
are you to insist this goes into Bitcoin?"
In any case; I can repeat the same story for major RFCs, FWIW. Collaborative
innovation is _very_ hard to stick to a tight schedule. And road-maps
of totally prospective technology that no one has the actual authority to make
happen aren't a productive thing for the industry.
In a few weeks you'll start seeing articles on the major new things
coming in Bitcoin Core 0.15,
-- now that we can do, because the work is done, and the outcome is
very predictable. There are some awesome improvements around it-- ones
we can rally around; and know will be delivered for sure.
[ Note 1: I think it is important to disclose that several of the
items in this list appear to be more or less quoted out of my own
blockstream-internal descriptions of things we've been working on in
Bitcoin.
A while back Adam Back asked me to publish something which contained
significant chunks of this document more or less verbatim, and I
declined saying that I personally disagree with some of his points and
didn't think that Blockstream attempting to redirect the Bitcoin
project (esp towards drivechains) was appropriate-- along with my
(above) views on roadmaps (which I have included here a private email
thread on the subject). I feel it's important to disclose this, and
that the document was not otherwise created with the input of project
contributors (except Luke-Jr, apparently). I wasn't previously aware
that Adam had been working with Paul on this, had I been I would have
also encouraged people to be a little more transparent about it. ]

2023-06-07 20:04:15

- reply

📅 Original date posted:2017-07-11
📝 Original message:On Tue, Jul 11, 2017 at 9:11 PM, Gregory Maxwell <greg at xiph.org> wrote:
> which I have included here a private email
> thread on the subject
To make it clear, since I munged the English on this: Most of my post
is just copied straight out of a private thread where I explained my
perspective on 'roadmaps' as they apply to projects like Bitcoin.

2023-06-07 20: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 20: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 20:03:47

- reply

📅 Original date posted:2017-07-02
📝 Original message:On Sun, Jul 2, 2017 at 8:35 PM, Rhavar via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> ==Abstract==
>
> BIP125 allows transactions to opt into replaceability with a primary use
> case
> of allowing users to increase the fees of unconfirming transactions, helping
> create
> a more efficient fee market place.
I don't really see how this is desirable: Just replace it-- the
receiver foolishly spent it at its own peril, spending a unconfirmed
payment from a third party is something that Core never does, it's
reckless unless you're doing something like CPFPing it to yourself,
which is harmless (either it'll work, or it'll fail and you'll be fine
with that).
Beyond being paternalistic the issue I see with your proposal is that
its contrary to miner income-- you're asking miners to ignore these
spends that otherwise they could accept. This seems unstable-- some
people would ignore your rule even if it were otherwise widely
adopted, leading to the network behavior having higher volatility.
Instead, perhaps a BIP that very strongly advises parties to not spend
unconfirmed outputs from third parties while making a payment to third
parties would achieve your end?

2023-06-07 20:03:47

- reply

📅 Original date posted:2017-07-02
📝 Original message:On Sun, Jul 2, 2017 at 9:01 PM, Rhavar <rhavar at protonmail.com> wrote:
> That's not really realistic. In practice some receivers do big sweeps and
> include unconfirmed inputs. Replacing the transaction means you need to pay
> the cost of the sweep, which you probably don't want to do (can be in the
> order of $100s of dollars).
Perhaps I am not following what you're saying here.
If the receiver is paying a higher feerate than your replacement,
he'll get it confirmed as fast or faster than your replacement in any
case.