<unnamed>

Public Key

npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwkls

Profile Code

nprofile1qqsvd4ayqzyhgcxe5tq8hwk4sucmd5zzvlkawkh59t6973cmq3vpasspzpmhxue69uhkummnw3ezuamfdejsfm7xme

Publishing to

nostr.wine

Last Notes

2023-06-07 23:11:21 UTC

- reply

📅 Original date posted:2022-07-08
📝 Original message:Hi aj,
I think there's another workaround for the x-only issue with
TAPLEAF_UPDATE_VERIFY.
So the opcode will need a function f that ensures that the new internal
key f(P'), where P' = P + X, has even y. You describe what happens for
the canonical choice of
f(P') = if has_even_y(P') then P' else -P'.
This leads to issues because negation turns around the signs of A and B
if say P' = A + B. Or more generally, negation is multiplicative
tweaking with a tweak -1, and that changes the coefficients of A und B.
But what if we use additive tweaking, which won't change the
coefficients? For example, you could try adding the generator until you
hit an even point, i.e.,
f(P') = if has_even_y(P') then P' else f(P' + G).
Then you may get a chain like
* Pabc = A + B + C
* Pab = A + B + 2G
* Pa = A + 2G + 1G = A + 3G
Pool members will simply need to track the accumulated tweak t and take
the tweak into account when signing. For example, A and B would sign
with t = 2 and A alone would sign with t = 3.
This choice of f will succeed after 1 addition on average. (I don't
know if this can be proven but even if not, experiments show that it's
true and that's good enough.) So the actual running time is
probabilistic. I don't think that's an issue but if it is an issue,
other choices of f are possible, e.g., let the spender provide the
tweak t explicitly and set
f(P',t) = if 0 <= t < 128 and has_even_y(P'+tG) then P'+tG else fail.
This workaround is not exactly elegant either but it may be better than
the other suggestions.
Best,
Tim
On Thu, 2021-09-09 at 16:53 +1000, Anthony Towns via bitcoin-dev wrote:
> Moving on to the pooled scheme and actually updating the internal
> pubkey
> is, unfortunately, where things start to come apart. In particular,
> since taproot uses 32-byte x-only pubkeys (with implicit even-y) for
> the
> scriptPubKey and the internal public key, we have to worry about what
> happens if, eg, A,B,C and A+B+C all have even-more elegy, but
> (A+B)=(A+B+C)-C does
> not have even-y. In that case allowing C to remove herself from the
> pool,
> might result in switching from the scriptPubKey Qabc to the
> scriptPubKey
> Qab as follows:
>
> Qabc = (A+B+C) + H(A+B+C, (Sa, (Sb, Sc)))*G
> Qab = -(A+B) + H( -(A+B), (Sa, Sb)*G
>
> That's fine so far, but what happens if B then removes himself from
> the
> pool? You take the internal public key, which turns out to be -(A+B)
> since (A+B) did not have even y, and then subtract B, but that gives
> you
> -A-2B instead of just A. So B obtains his funds, but B's signature
> hasn't
> been cancelled out from the internal public key, so is still required
> in order to do key path spends, which is definitely not what we want.
>

2023-06-07 18:31:00 UTC

- reply

📅 Original date posted:2021-03-21
📝 Original message:On Sat, 2021-03-20 at 21:25 +0100, vjudeu via bitcoin-dev wrote:
> So, things have to be complicated to be secure?
Not at all. But we first need to spend some thoughts on what "secure"
means before we can tell if something is secure.
> By definition, using some private key, calculating some public key
> from it and incrementing that key is secure (it is definitely no
> worse than address reuse).
If secure means that it does not hurt the unforgeability of ECDSA, then
I believe you're right.
> The only problem with using "privKey", "(privKey+1) mod n",
> "(privKey+2) mod n" and so on is that all of those public keys could
> be easily linked together. If that is the only problem, then by
> making offset deterministic but less predictable, it should be secure
> enough, right? So, instead of simple incrementation, we would have
> "privKey" (parent), "(privKey+firstOffset) mod n" (first child),
> "(privKey+secondOffset) mod n" (second child) and so on. And as long
> as this offset is not guessed by the attacker, it is impossible to
> link all of those keys together, right?
I believe this intuition is also a good first approach. So let's have a
look: You say that offset = SHA256(masterPublicKey || nonce). Is this
predictable by the attacker?
I can't really answer that question because it's not specified how
"nonce" is obtained. Since this is supposed to be a deterministic
scheme, I see two basic ways: Either the master private key is involved
in the derivation of "nonce" (then "nonce" may be unpredictable) or
it's not (then "nonce" is predictable).
Another fact that may or not be a problem is that it may be possible to
compute a parent private key from the a private key. Again, I can't
tell because I don't know how nonce is obtained.
Taking a step back, BIP 32 addresses all of these concerns. I agree it
could be simpler but I don't see a practical necessity to invent a new
scheme. In any application where this proposal could potentially be
used, BIP 32 could also be used and it's just good enough.
Tim
>
> > On 2021-03-20 11:08:30 user Tim Ruffing <crypto at timruffing.de>
> > wrote:
> > > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> > > > is it safe enough to implement it and use in practice?
> > >
> > > This may be harsh but I can assure you that a HD wallet scheme
> > > that can
> > > be specified in 3 lines (without even specifying what the
> > > security
> > > goals are) should not be assumed safe to implement.
> > >
> > > Tim
> > >
> > >
> >
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:30:59 UTC

- reply

📅 Original date posted:2021-03-20
📝 Original message:On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> is it safe enough to implement it and use in practice?
This may be harsh but I can assure you that a HD wallet scheme that can
be specified in 3 lines (without even specifying what the security
goals are) should not be assumed safe to implement.
Tim

2023-06-07 18:23:18 UTC

- reply

📅 Original date posted:2020-03-12
📝 Original message:Hi Lloyd,
This is great research, thanks for this effort!
Here are some comments:
On Wed, 2020-03-04 at 18:10 +1100, Lloyd Fournier via bitcoin-dev
wrote:
>
> Property (2) is more difficult to argue as it depends on the multi-
> party key generation protocol. Case in point: Taproot is completely
> broken when combined with a proof of knowledge key generation
> protocol where along with their public keys each party provides a
> proof of knowledge of the secret key. Where X_1 is the key of the
> honest party, the malicious party can choose their key X_2 to be
> G*H(X_1 || m) where m is a malicious Merkle root. Clearly the
> malicious party has a covert Taproot for X = X_1 + X_2 and can
> produce a proof of knowledge for X_2.
I mean, the good thing is that there's a general method to defend
against this, namely always adding a Merkle root on top. Maybe it's
useful to make the warning here a litte bit more drastic:
https://github.com/sipa/bips/blob/bip-taproot/bip-0341.mediawiki#cite_ref-22-0
Maybe we could actually mention this in BIP340, too, when we talk about
key generation,
>
> Poelstra presented a proof in the ROM for the security of Taproot
> [3]. It frames Taproot as a way of combining two signature schemes
> into one public key (in our case Schnorr and Tapscript). He uses a
> similar line of reasoning to what I have just presented in his proof
> (Lemma 1, step 3) but this approach brings in many other
> considerations that I think can be avoided by modelling it as a
> commitment scheme. Note that this proof only shows that Taproot
> forgeries are hard i.e. property (1).
I agree that modeling it as a commitment scheme is more natural. But I
think an optimal model would capture both worlds, and would give the
attacker signing oracles for the inner and the outer key, and an
commitment opening oracle That is, it would capture that
* the ability to obtain signatures for the inner key does not help you
to forge for the outer key
* the ability to obtain signatures for the outer key does not help you
to open the commitment, and --- if already opened --- do not help
you to forge for the inner key
* the ability to obtain an opening does not help you to forge for
either key...
* etc
I believe that all these properties hold, and I believe this even
without a formal proof.
Still, it would be great to have one. The problem here is really that
things get complex so quickly. For example, how do you model key
generation in the game(s) that I sketched above? The traditional way or
with MuSig. The reality is that we want to have everything combined:
* BIP32
* MuSig (and variants of it)
* Taproot (with scripts that refer to the inner key)
* sign-to-contract stuff (e.g., to prevent covert channels with
hardware wallets)
* scriptless scrips
* blind signatures
* threshold signtures
* whatever you can imagine on top of this
It's very cumbersome to come up with a formal model that includes all
of this. One common approach to protocols that are getting too complex
is to switch to simpler models, e.g., symbolic models/Dolev-Yao models
but that's hard here given that we don't have clear layering. Things
would be easier to analyze if Taproot was really just a commitment to
a verification key. But it's more, it's something that's both a
verification and a commitment. Taproot interferes with Schnorr
signatures on an algebraic level (not at all black-box), and that's
actually the reason why it's so powerful and efficient. The same is
true for almost everything in the list above, and this puts Taproot
outside the scope of proof assistants for cryptographic protocols that
work on a symbolic level of abstraction. I really wonder how we can
handle this better. This would improve our understanding of the
interplay between various crypto components better, and make it easier
to judge future proposals on all levels, from consensus changes to new
multi-signature protocols, etc.
>
> In my opinion, the cost of Taproot is mostly borne by theoreticians.
> They can no longer treat a a public key ideally but have to consider
> the implications of it also being a commitment. For the user and
> Bitcoin as a whole it seems to offer an overwhelming benefit. In
> exchange for the complexity it adds to making security claims in the
> GGM (if using Taprscript and MuSig), it offers exciting new
> opportunities for non-interactivity and fungibility over what just
> what Schnorr would provide.
I agree with this overall statement. I'm confident in Taproot, and I
guess what say above really applies to the cost for theoreticians.
(Let's just make sure that we don't forget how theory is relevant to
security in practice.)
Tim

2023-06-07 18:23:13 UTC

- reply

📅 Original date posted:2020-03-22
📝 Original message:On Sun, 2020-03-22 at 11:30 -0400, Russell O'Connor wrote:
> Your claim is that if we don't fix the pubkey issue there is no point
> in fixing the signature issue. I disagree. While I think both
> issues need to be fully addressed, the issues around the original
> proposed non-deterministic signature scheme are far more severe. The
> proposal would move us from a deterministic scheme, where spot checks
> are possible, with all the caveats that entails, to a non-
> deterministic scheme where spot checks are impossible. My hope is
> that we can standardise a scheme that has the advantages of non-
> determinism without the threat of covert channels.
I think we agree that both issues should be addressed, and this is all
what matters in the end. Now that we have a proposal for Schnorr
signatures, it's indeed a good time to work on these issues.
Tim

2023-06-07 18:23:12 UTC

- reply

📅 Original date posted:2020-03-22
📝 Original message:On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> Public keys are deterministic and can be spot checked. In fact,
> AFAIU if hardened HD key derivations are not used, then spot checking
> is very easy.
>
> While spot checking isn't ideal, my original concern with the
> synthetic none standard proposal was that it is inherently non-
> deterministic and cannot ever be spot checked. This is why anti-
> covert signing protocols are so important if we are going to use
> synthetic nonces.
If spot checking means checking a few instances, then I think this is a
pretty weak defense. What if the device starts to behave differently
after a year?
On Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:
> Practically speaking, most hardware wallets allow you to import your
> own BIP39 seed, so you can work around key generation attacks today,
> with a one time inconvenience at the start. However, with the signing
> nonce attacks, a user today has no protection.
>
How do you know that the device really uses your seed? This can only be
done by comparing the public keys output by the HW with a second
computation. Even if you use only non-hardened derivation, you need to
check the master (root) public key and that means you need compute the
master root public key once from the seed. You can't do this manually
on a sheet of paper after you rolled a few dice to generate your seed.
So you need to store the seed on a second device (if only for a short
time). And I think this defeats the purpose of a HW wallet.
And even if assume that spot checking and importing the seed works, the
problem is not solved. We still need a clearly specified full protocol
that we can analyze.
Best,
Tim

2023-06-07 18:23:11 UTC

- reply

📅 Original date posted:2020-03-21
📝 Original message:Hi Pieter,
That's a really nice overview.
Let's take a step back first. If we believe that malicious hardware
wallets are big enough of a concern, then signing is only part of the
problem. The other issue is key generation. The PRG from which the seed
is derived can be malicious, e.g., just H(k_OO,counter) for a key k_OO
chosen by the hardware manufacturer. I haven't seen an argument why
attacks during the signing model should more realistic than attacks
during key generation, so I'd be very hesitant to deploy anti-covert
channel singing protocols without deploying protocols for key
generation that are secure in the same attacker model.
While there's a bunch of protocols for signing, there's not much
research for key generation. One simple idea is a simple commit-and-
reveal protocol to generate a master (elliptic curve) public key pair
with entropy contributions from both HW and SW (similar to the
protocols here for generating R). Then use BIP32 public derivation for
all other keys in order to make sure that SW can verify the derivation
of the public kyes. The corresponding master secret key would replace
the seed, i.e., there's no "symmetric" seed. That idea comes with other
drawbacks however, most importantly this is not compatible with
hardened derivation, which creates a new security risk. If we want
(something like) hardened derivation, zero-knowledge proofs of correct
derivation could maybe used but they again come with other issues
(efficiency, complexity).
By the way, here's a paper that considers a similar setting where the
hardware wallet is also malicious during key generation:
https://fc19.ifca.ai/preproceedings/93-preproceedings.pdf
This model goes a step further and assumes threshold signatures but
interestingly here the human user (instead of the SW) is the trusted
party interacting with the HW. In this model the human user has a low-
entropy password.
Now back to the signing process: I think yet another security property
to look at is security against a malicious SW with parallel signing
sessions. I think it's reasonable to restrict a single HW device to a
single session but what if the same seed is stored in two or more HW
wallets? That's plausible at least. Taking this additional security
property into account, it appears that Scheme 4 is vulnerable to
Wagner's attack because SW can influence R by choosing t after seeing
R0. (This can be fixed, e.g., by using Scheme 5 instead.)
On Tue, 2020-03-03 at 21:35 +0000, Pieter Wuille via bitcoin-dev wrote:
> 2.d) Statefulness
>
> We're left with Schemes 4 and 5 that protect against all listed
> issues. Both
> need two interaction rounds, with state that needs to be kept by HW
> between
> the rounds (the k0 value). While not a problem in theory, this may be
> hard to
> implement safely in simple APIs.
A generic way to make one party (HW in this case) stateless is to let
it encrypt and authenticate its state, e.g., using AEAD. In our
particular case I think that the state does not need to be
confidential, and a simple MAC suffices. For simplicity let's assume we
have another hash function H' (modeled as a random oracle) used as MAC.
We can (ab)use d as a MAC key.
If we don't want to spend an entire signature verification on the side
of HW to protect against fault attacks, we can additionally let SW
compute and send the challenge hash e=H(R,Q,m) and let HW only verify
the computation of e. This helps against fault-attacks in the
computation of R and e because now SW needs to commit to e, which is a
commitment to the exact computation fault that HW will suffer from. But
I'm not sure yet if this is weaker or stronger or incomparable to
verifying the signature. I guess it's weaker [1]. If we don't drop
signature verification, this technique does not hurt at least.
[Scheme 7: synthetic nonce, two interactions, stateless using MAC,
verifying e]
First interaction:
* SW generates a random t, computes h=H(t), and requests the R0 point
that HW would use by sending (Q,m,h) to HW.
* HW uses a global counter c (or fresh randomness c), and computes
k0=H(d,m,c,h), R0=k0G, mac=H'(d,m,c,h) and sends R0,c,mac to SW.
Second interaction:
* SW computes R=R0+tG, e=H(R,Q,m) and requests a signature by sending
(Q,m,t,e,c,mac) to HW
* HW verifies mac=H'(d,m,c,H(t)), recomputes k0=H(d,m,c,H(t)), k=k0+t,
computes R=kG, verifies e=H(R,Q,m), and if all is good computes
s=k+H(R,Q,m)d and sends s to SW.
* SW verifies that sG=R+eQ and publishes (R,s) if all is good.
One last observation: Since the inputs to H and H' are the same, we
could even use H'(x)=H(H(x)). Not sure if that's useful.
Best,
Tim
[1] In the (admittedly weird) case that faults in two runs of the
executions are independent and can be made highly likely (say
probability almost 1), verifying e could indeed be stronger than
verifying the signature: When verifying the signature, the fault attack
is successful if the *same* fault happens during signing and
verification (birthday collision!). When verifying e instead, the
attack is successful if the attacker predicts the fault correctly. But
I guess if faults can be made very likely, there's no hope anyway.

2023-06-07 18:14:34 UTC

- reply

📅 Original date posted:2018-09-07
📝 Original message:On Fri, 2018-09-07 at 02:31 +0000, Gregory Maxwell wrote:
> 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.
>
Okay, sure, I was assuming that Tor will deploy it at some point. No
idea what the status is.
> > It's not worth the hassle, would hinder adoption,
>
> Why do you say this?
My assumption is that NewHope is harder to implement. If you just
drop-in existing code, it's not. And I've neither implemented NewHope
nor Elligator Squared, so I may just be wrong.
>
> > 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.
I don't like the argument either but I think it's real.
> (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?)
No idea if it can be made constant time but yeah I think it's not
crucial in this case.
>
> 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 wasn't specific but my point is that these are indeed interesting
future directions. You can easily make the traffic look like any other
protocol which uses encryption. That's a really useful property if you
want to avoid censorship, even if traffic analysis still works. That's
true even if this it's not in the scope of this BIP, which is of course
the case.
If you ask me, that is more interesting than protecting against
potential decryption of P2P connections in a few decades. But I don't
have a definitive argument for this of course.
> 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. :)
I don't have a harmful example but here is harmless one (that you
probably know because it's really the simplest one can think of):
A M B
-- aG -->
<-- bG --
-- aG -->
<-- bG --
Now A and B share the same session id but any attempt to communicate
will fail because they both think that they're the initiator. Of course
that's not a big deal because M is in neither of those sessions. So
it's not an attack but it's a weird property of the key exchange. But I
think it's desirable to avoid such things if the cost to do so is very
low.
Also, here is a better argument:
A M B
-- aG -->
<-- bG --
<-- xG --
-- yG -->
After B's message, M's goal is create a collision of the session ids.
Since M can freely choose x and y, that's a birthday attack on the hash
function and needs 2^(l/2) work if the session id is l bits long.
Telegram has (had?) the same issue:
https://www.alexrad.me/discourse/a-264-attack-on-telegram-and-why-a-super-villain-doesnt-need-it-to-read-your-telegram-chats.html
With the other variant, M cannot collect both aG and bG upfront:
A M B
-- aG -->
-- yG -->
<-- bG --
<-- xG --
Now M can only choose x, so this is a second-preimage attack and takes
2^l work. So with the this variant, you can have a session id that's
only half the size. That's a real difference if session ids are meant
to be comparable by humans, e.g., over the phone.
(I think) it's possible to even go further with a 3-way handshake:
A M B
-- H(aG) -->
-- H(yG) -->
<-- bG --
<-- xG --
-- aG -->
-- yG -->
Here M has no flexibility at all, so the probability of a successful
attack against a single key exchange is just 2^(-l). This is similar to
ZRTP. I'm not saying that we should do this, it's something worth
noting that.
>
> > 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.
Oh nevermind.
> 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).
That adhoc construction is a very interesting idea. Hm... Just fyi, the
closest that comes to my mind is:
https://core.ac.uk/download/pdf/20880831.pdf
> 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).
Yeah, my point was not to write the entire list in stone. That was not
really clear from my message, sorry. Of course, new message types can
be added later. But I don't see a big advantage in allowing both ASCII
strings and short IDs. So I wanted to say that the usage of short IDs
should be written stone.
On Fri, 2018-09-07 at 10:34 +0200, Jonas Schnelli wrote:
>
> > 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.)
>
> I think a new message type that could contain message + pad would be
> trivial.
> Would this again be to obfuscate traffic patterns? Anti DPI is not
> the scope of BIP151.
Well, it's indeed to obfuscate traffic patterns but primarily for
confidentiality. If I see the length of the message, I can guess the
message type fairly well for example. (That's not no matter if my goal
as an attacker is to break your privacy or to censor your connection.
Of course more confidentiality helps also against DPI/censorship but
that was not my point here.)
> I was under the false impression that it is obvious to disconnect in
> those cases.
Yeah I think it's by far the most natural thing to do but it may be
better to make it explicit.
Tim

2023-06-07 18:14:33 UTC

- reply

📅 Original date posted:2018-09-06
📝 Original message:Hi Jonas,
Great to see progress in this area. I have quite a few comments.
Post-quantum key exchange
=========================
I think that's overkill. Bitcoin has huge problems in the presence of a quantum computer, and the
confidentiality of the P2P messages is the most minor one. If there is a quantum computer and
Bitcoin remains in its current form, then people should probably stop using it.
Now you can argue that the attacker is storing encrypted traffic today to decrypt it later. Sure,
but if that's your threat model then Bitcoin is probably not the right tool for you. (And if
you insist that Bitcoin is the right tool, then you can and probably should use it over Tor
anyway.) Given the fact that essentially all information in Bitcoin will be public in some way,
there are probably cheaper attacks (MITM, traffic analysis).
It's not worth the hassle, would hinder adoption, and it has the potential to create a wrong
impression of "bulletproof" security. Even worse, there will be too many people that will suddenly
assume that Bitcoin is post-quantum secure.
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
key. Together with the encrypted packet lengths, the entire data stream looks like random then,
which is pretty useful against censorship resistance for example. (The only exception is that the
stream will never start with the magic bytes.)
Key derivation
==============
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.
Re-keying
=========
The problem with signalling re-keying in the length field is that the length field is not covered
by the MAC. So the attacker can flip the signalling bit. The resulting protocol is probably still
secure but the malleability is certainly not desirable.
Deterministic rekeying rules may be better. Otherwise there will be implementations that rekey
every 10 seconds and implementations that just don't rekey at all (rendering the 10 s rekeying
interval in the opposite direction useless). Different policies also make it possible to
fingerprint implementations. Another problem is that people will set their policies arbitrarily.
What's better: 5 min or 30 min? I don't know, but both are reasonable choices. (Thats's very much
like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? I don't know, but
again both are reasonable choices.)
Symmetric crypto
================
You call it chacha20-poly1305 at bitcoin but what's the difference to the openssh then? Is the
idea to save a call to chacha here as you mentioned?
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.)
Misc
====
"The ID/string mapping is a peer to peer arrangement and MAY be negotiated between the
requesting and responding peer." I think that's overly complicated. I suggest it should just be
written in stone, again to avoid complexity and to avoid fingerprinting. New implementations are
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.
In general, the entire thing is a little bit underspecified. (I'm aware it's just a draft.)
A few examples:
- What should a peer do if the MAC verification fails?
- What should a peer do if it receives an even key?
- "Processing the message before the authentication succeeds (MAC verified) MUST not be done."
That should also apply to the ciphertext. (Or: What is a "message"?). It may be a good idea to
to refer to the openssh document or steal from it; it does a pretty good job.
- "Both peers MUST keep track of the message sequence number (uint32) of sent and received
messages for building a 64-bit symmetric cipher IV." I think you mean nonce when you say IV?
- What is the initial value of the sequence number?
- How is a 64-bit nonce formed from one (two?) uint32?
- What if the uint32 overflows?
- "Re-Keying interval is a peer policy with a minimum timespan of 10 seconds." What if I receive
too many re-keying requests? Nothing or should I raise the DoS score?
- "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"?
Pseudocode could probably help here.
[1] https://eprint.iacr.org/2014/043.pdf

2023-06-07 18:13:40 UTC

- reply

📅 Original date posted:2018-07-08
📝 Original message:Hi Erik,
On Sun, 2018-07-08 at 10:19 -0400, Erik Aronesty via bitcoin-dev wrote:
> Consider changing the "e" term in the schnorr algorithm to hash of
> message (elligator style) to the power of r, rather than using
> concatenation.
How do you compute s = x*e if e is an element of group G?
(Similar question: How do you verify if e is element of G?)
Are you aware of
http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps ?
This is a threshold signature scheme for Schnorr signatures, so what
you want is possible already with Schnorr signatures.
Best,
Tim

2023-06-07 18:12:34 UTC

- reply

📅 Original date posted:2018-06-06
📝 Original message:I haven't read the original Graftroot thread, so maybe all of this has
b
een discussed already or is just wrong... Please correct me if this
is
the case.
On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote:
> The best argument for why Graftroot does not need to be optional I
> think was how Greg put it: "since the signer(s) could have signed an
> arbitrary transaction instead, being able to delegate is strictly
> less
> powerful.".
I'm trying to get a more abstract view of the problem. One issue with
Greg's argument is the following:
If g-script is a script (containing a public key) that allows for
Graftroot spending, then the following "flow" of coins is valid:
g-script --g-sig--> script1 ---tx2---> script2
Here, g-sig is a Graftroot signature on script1 and tx2 is a
transaction that fulfills script1 and sends to script2. In other words,
the only transaction involved here is tx2; it provides g-sig, script1,
and a solution for tx1, and it spends to script2.
Now Greg's argument (as I understand it) is that this can be already
done without Grafroot with two transactions, namely a normal
transaction tx1 that spends g-script normally and tx2 that spends tx1
to script1.
g-script ---tx1---> script1 ---tx2---> script2.
So far, so good. A difference however is that g-sig *alone* can't be
committed to the chain but tx1 alone can be committed to the chain.
That means
g-script --g-sig--> script1 (*)
is "incomplete" but
g-script ---tx1---> script1 (**)
is a perfectly valid transaction that can be committed to the chain. So
I think Graftroot delegation is not "strictly less powerful" than just
using a normal transaction: Graftroot enables to delegate in a way such
that the delegation itself cannot be fixed in the chain. I think this
is not possible currently. (Okay, you can just pass around the secret
keys but has other problems obviously).
Does this have practical implications?
I don't see any but maybe this helps someone to identify an undesirable
implication.
One way to be on the safe side and probably make Greg's argument go
through is to just define the semantics such that (*) is allowed, i.e.,
call g-sig a "Graftroot transaction" and give it transaction semantics.
This provides a new perspective on Graftroot: Then Graftroot does not
introduce new semantics but (*) is just an optimized version of (**)
that uses fewer bytes and may be better for privacy.
Interestingly Andrew's blind-sig example and Johnson's fix (g-sig signs
the outpoint) are just a special case. If g-sig has transaction
semantics, it must sign the outpoint (and other stuff).
Now you can say that this is not really useful: if g-sig is essentially
a full transaction that can committed to the blockchain, then it needs
to specify inputs, outputs etc. So all the optimizations are lost and
those were the reason we want to introduce Grafroot in the first place.
But one observation here is that g-sig only needs to be a full
transaction if it's used standalone as in (*). If we want to have
g-script --g-sig--> script1 ---tx2---> script2
(and this should be the common case) then just the bare signature and
script1 suffices, as in the Graftroot proposal. In some sense, inputs
and outputs of the Graftroot transaction are just implicit in this
case.
Another way to look at this that instead of providing a transaction
with g-sig, script1, and a solution for script1, you can also choose to
provide a transaction with only g-sig and script1 (and don't solve
script1), which then just sends to script1.
I'm not saying that it's worth the hassle to add this possibility
without being aware of a problem that arises if we don't add it -- but
maybe my thoughts provide another perspective on the issue.
Best,
Tim

2023-06-07 18:10:39 UTC

- reply

📅 Original date posted:2018-02-15
📝 Original message:On Thu, 2018-02-15 at 21:27 +0100, Natanael wrote:
> I addressed this partially before, and this is unfortunately
> incomplete.
>
> Situation A: Regardless of expiration of commitments, we allow
> doubles. (Or no doubles allowed, but commitments expire.)
>
> If I can block your transaction from confirming (censorship), then I
> can make my own commitment + transaction. The miners will see two
> commitments referencing the same UTXO - but can see only one
> transaction which match a valid challenge and spends them, which is
> mine. You gained nothing from the commitment.
Yes, I assume situation A:
* commitments never expire
* and there is no limit on the number of commitment for the same UTXO
As I understand, you mean "decommitment" when you say "transaction".
Please correct me if I'm wrong. I'll stick with "decommitment".
Let's assume the attacker blocks the decommitment by the honest user,
inserts his own malicious commitment and his own decommitment, which
should be valid for the malicious commitment. Then the miners will see
two commitments (the earlier commitment by the honest user and the
later one by the attacker).
Also, the miners will indeed see one valid decommitment. This
decommitment may have been sent by the attacker but it's the preimage
chal of the address, because otherwise it's not valid for the malicious
commitment. But if the decommitment is chal, then this decommitment is
also valid for the commitment of the honest user, which is earliest
additionally. So the honest commitment wins. The attacker does not
succeed and everything is fine.
The reason why this works:
There is only one unique decommitment for the UTXO (assuming H_addr is
collision-resistant). The decommitment does not depend on the
commitment. The attacker cannot send a different decommitment, just
because there is none.
Maybe I'm wrong and I just don't understand your attack. In this case,
please explain it more detail.
Regards,
Tim

2023-06-07 18:10:38 UTC

- reply

📅 Original date posted:2018-02-15
📝 Original message:First of all, there is indeed an issue in my proposal:
The idea was to include a classic signature to make sure that, if (for
whatever reason) you have revealed classic_pk already.
However, the problem is that if you have revealed classic_pk, then
everybody can effectively prevent you from spending the funds as you
wish by just including the first commit entry with an arbitrary tx in
the blockchain. That's bad obviously.
Here is a fixed variant, which does not only work with normal P2PKH but
1) supports basically with any (hash-based) addresses, for which the
preimage has not been revealed and 2) does not change the conditions
under which a UTXO can be spent.
Setup
=====
We will need multiple hash functions KDF, H, and authenticated
symmetric encryption Enc/Dec.
Let's assume we have an UTXO with address addr = H_addr(chal), where
chal is a challenge, i.e., typically a scriptPubKey (what I called
classic_pk initially) and H_addr is the hash function used to form
addresses. (If there are multiple UTXO sharing the same address, they
can be spent simultaneously with this approach.) To spend this UTXO
with a transaction tx, the user performs the following two steps.
Note that -- in contrast to my earlier emails -- tx is assumed to
include a solution to the challenge in its input, i.e., a string which
proves that you are allowed to spend the UTXO (typically a scriptSig).
Commit step
===========
Derive a symmetric key k = KDF(chal).
Create and publish a commitment in the blockchain that references the
UTXO as inputs and contains the following data:
c = Enc(k, tx)
Wait until c is confirmed. (If it does not confirm, send it again as
usual.)
Decommit step
=============
Create and publish a decommitment with the following data:
d = chal
Consensus rules
===============
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first commitment (among all referencing the UTXO) in
the blockchain such that
1. k = KDF(chal) correctly decrypts Dec(k, c)
and
2. tx = Dec(k, c) is a valid transaction to spend UTXO
The UTXO is spent as described by tx.
Commitments never expire.
The second condition covers that tx contains a classic signature under
the public key specified in chal in normal P2PKH addresses.
The trick here is that the encryption ensures that the user commits to
tx (including the classic signature) already in the commit step, while
still keeping the decommitment unique. If I'm not mistaken, this scheme
is a variant of Adam Back's proposal for committed transactions from
2013, which he invented for an entirely different goal, namely
censorship resistance:
https://bitcointalk.org/index.php?topic=206303.msg2162962#msg2162962
(Adam noted the similarity of the problems on Twitter recently:
https://twitter.com/adam3us/status/948219461345075201)
The above variant is pretty simple. If it really works and is secure,
it has the advantage over Adam's proposal that it does not rely on
ECDSA specifically and can be used for any address type.
The aforementioned thread in the Bitcoin forum discusses the main
problem of an approach like that: Everybody can flood the blockchain
with commitments. Of course, one can require fees to create
commitments, but that's pretty ugly: If this UTXO is the only money you
have, then you need to borrow some to pay the transaction fees upfront.
But this may be the price you need to pay for recovery. This can be
acceptable, because recovery should be the exception (see below).
On Tue, 2018-02-13 at 21:06 +1100, Tristan Hoy via bitcoin-dev wrote:
> The worst-case outcome is that ECDSA is broken before PQ addresses
> are
> rolled out. There is no reactive response to this - all the existing
> ECDSA addresses will be compromised. A proactive measure is
> required,
> and it should be deployed sooner rather than later.
The proposal above does not require any changes to existing ECDSA
addresses, so there is no need to change something now already.
At some point in the future, PQ addresses will be deployed. And at some
(potentially different) point in the future, we should deploy a
solution to recover UTXOs. But there's no need to do this today. A
recovery solution can be deployed even when DLOG has been broken
already -- not optimal but possible.
>
> Any two-step approach adopted now as a proactive measure will not
> only
> bloat the blockchain, it will also double the effective confirmation
> time - for all transactions between now and when PQ addresses are
> rolled
> out, which seems unlikely to happen in the next 5 years. The bloat
> will
> be permanent.
>
I don't think that's true due to the situation I describe above. We
don't need to act now.
And even if we act now, i.e., even if we enable the above proposal (or
any other protocol that enables recovery of UTXOs with addresses)
today, people are not forced to use it. As long as ECDSA and the other
schemes we use today remain secure, people can and will continue to
perform conventional transactions. Ideally, people will need a recovery
protocol only for those UTXOs which they haven't touched for years and
have forgotten to convert to PQ in time.
You mentioned confirmation time. A nice thing is that the above
protocol does not double confirmation times. The sender needs to wait
for confirmation of the commitment. But as soon as the commitment is
confirmed, double-spending is excluded already, because the sender is
committed to the transaction. So the recipient does not need to wait
for confirmation of the decommitment. As soon as the recipient sees the
decommitment, everything is good. (If the decommitment is not
confirmed, the recipient can just re-broadcast it.)
In practice, we could even go further and call the transaction done
after the commitment is confirmed and the sender sends the data for the
second step to the recipient off-chain. Only when the recipient wants
to spend the funds again, the recipient will reveal this data.
The fact that double-spending is excluded after the first step is
confirmed, is exactly what makes the protocol secure against quantum
attackers who want to steal the money. As soon as the user reveals the
ECDSA public key, a quantum attacker has access to all secrets: The
attacker knows the preimage of the hash can compute the secret key.
So from this point on, there is no hope that we can distinguish the
honest user from the attacker. But since the correct transaction has
been committed to the blockchain, and cannot be changed anymore, we
don't need to distinguish the honest user from the attacker.
> Either way, would you mind if I included your approach in the
> article,
> with credit? I will seek your review before publishing.
Sure, feel free to include. You don't need to seek my review but I can
certainly have a look if desired.
Tim

2023-06-07 18:10:37 UTC

- reply

📅 Original date posted:2018-02-13
📝 Original message:On Tue, 2018-02-13 at 08:32 +1100, Tristan Hoy wrote:
> In a post-quantum world, your second "d" type transaction is
> completely forgeable, which means it is vulnerable to front-running.
> An adversary capable of breaking ECDSA needs only listen for these
> transactions, obtain "classic_sk" and then use a higher fee (or
> relationship with a miner) to effectively turn your original "d"
> transaction into a double-spend, with the forged transaction sending
> all your funds to the adversary.
That's not true. The d(ecommit) transaction, or better let's call it
"decommit step" of a two-step transaction does not specify the effects
(output script). This is what I denote by "tx" in the writeup, and it's
already fixed by the c(ommit) step.
So yes, if the user finally reveals
d = classic_pk||Sign(classic_sk, tx)
a quantum attacker can indeed forge
d' = classic_pk||Sign(classic_sk, tx')
for tx' != tx of his choice. But that won't help him, because the first
valid c step in the chain is for tx and not for tx'.
> The other issue with your approach is that if it is rolled out today,
> it will effectively double transaction volumes - this is what I tried
> to solve in solutions 2 and 3 in my article by instead modifying the
> address generation process.
Yep, it needs two entries in the blockchain, and that does not mean
that it doubles the data. It will need some more bytes in the
blockchain but also proper PQ-transactions could need more bytes in the
blockchain, so I don't think that's the major issue.
>
> Regards,
>
> Tristan
>
> On Tue, Feb 13, 2018 at 2:50 AM, Tim Ruffing via bitcoin-dev <bitcoin
> -dev at lists.linuxfoundation.org> wrote:
> > Hi Tristan,
> >
> > Regarding the "Post-Quantum Address Recovery" part (I haven't read
> > the
> > other parts), you may be interested in my message to the list from
> > last
> > month and the rest of the thread:
> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Januar
> > y/015659.html
> >
> > This is an approach which aims to avoid the issues that you've
> > mentioned in your blog post.
> >
> > Best,
> > Tim
> >
> > On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev
> > wrote:
> > > Hi all,
> > >
> > > Recently I've been exploring what a post-quantum attack on
> > Bitcoin
> > > would actually look like, and what options exist for mitigating
> > it.
> > >
> > > I've put up a draft of my research here: https://medium.com/@tris
> > tanh
> > > oy/11271f430c41
> > >
> > > In summary:
> > > 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are
> > > scalable
> > > 2) This is a rapidly advancing space and committment to a
> > specific
> > > post-quantum DSA now would be premature
> > > 3) I've identified a strategy (solution 3 in the draft) that
> > > mitigates against the worst case scenario (unexpectedly early
> > attack
> > > on ECDSA) without requiring any changes to the Bitcoin protocol
> > or
> > > total committment to a specific post-quantum DSA that will likely
> > be
> > > superseded in the next 3-5 years
> > > 4) This strategy also serves as a secure means of transferring
> > > balances into a post-quantum DSA address space, even in the event
> > > that ECDSA is fully compromised and the transition is reactionary
> > >
> > > The proposal is a change to key generation only and will be
> > > implemented by wallet providers.
> > >
> > > Feedback would be most appreciated.
> > >
> > > Regards,
> > >
> > > Tristan
> > > _______________________________________________
> > > 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 18:10:36 UTC

- reply

📅 Original date posted:2018-02-12
📝 Original message:Hi Tristan,
Regarding the "Post-Quantum Address Recovery" part (I haven't read the
other parts), you may be interested in my message to the list from last
month and the rest of the thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015659.html
This is an approach which aims to avoid the issues that you've
mentioned in your blog post.
Best,
Tim
On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev wrote:
> Hi all,
>
> Recently I've been exploring what a post-quantum attack on Bitcoin
> would actually look like, and what options exist for mitigating it.
>
> I've put up a draft of my research here: https://medium.com/@tristanh
> oy/11271f430c41
>
> In summary:
> 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are
> scalable
> 2) This is a rapidly advancing space and committment to a specific
> post-quantum DSA now would be premature
> 3) I've identified a strategy (solution 3 in the draft) that
> mitigates against the worst case scenario (unexpectedly early attack
> on ECDSA) without requiring any changes to the Bitcoin protocol or
> total committment to a specific post-quantum DSA that will likely be
> superseded in the next 3-5 years
> 4) This strategy also serves as a secure means of transferring
> balances into a post-quantum DSA address space, even in the event
> that ECDSA is fully compromised and the transition is reactionary
>
> The proposal is a change to key generation only and will be
> implemented by wallet providers.
>
> Feedback would be most appreciated.
>
> Regards,
>
> Tristan
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:10:10 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, 2018-01-24 at 19:51 +0100, Natanael wrote:
>
> That's not the type of attack I'm imagining. Both versions of your
> scheme are essentially equivalent in terms of this attack.
>
> Intended steps:
> 1: You publish a hash commitment.
> 2: The hash ends up in the blockchain.
> 3: You publish the transaction itself, and it matches the hash
> commitment.
> 4: Because it matches, miners includes it. It's now in the
> blockchain.
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction on the wire, the user does not
care and will try again.
By the way: As described here, everybody could do this first step and
flood the blockchain with it. We cannot immediately subtract a fee,
because it's not clear that some transaction will take place at all. So
we need to take the fee from somewhere else or do something else to
prevent spam. But that's entirely different issue...

2023-06-07 18:10:10 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, 2018-01-24 at 13:51 +0100, Natanael via bitcoin-dev wrote:
> Sidenote: There's a risk here with interception, insertion of a new
> commitment and getting the new transaction into the blockchain first.
> However, I would suggest a mining policy here were two known
> conflicting transactions with commitments are resolved such that the
> one with the oldest commitment wins. How to address detection of
> conflicting transactions with commitments older than confirmed
> transactions isn't obvious. Some of these may be fully intentional by
> the original owner, such as a regretted transaction.
Okay, I think my proposal was wrong...
This looks better (feel free to break again):
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed
2. Reveal classic_pk in the blockchain
Then the tx in the first valid commitment wins. If the attacker
intercepts classic_pk, it won't help him. He cannot create the first
valid commitment, because it is created already. (The reason is that
the decommitment is canonical now; for all commitments, the
decommitment is just classic_pk.)
By the way, maybe I'm stating the obvious but Taproot (or similar) is
indeed very nice for outputs generated in the future: You can have a
path for a classical signature scheme and a path for a quantum-secure
scheme.
Best,
Tim

2023-06-07 18:10:09 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Wed, 2018-01-24 at 01:52 +0000, Andrew Poelstra via bitcoin-dev
wrote:
>
> > They are. But I don't believe that is relevant; the attacker would
> > simply steal the coins on spend.
>
>
> Then the system would need to be hardforked to allow spending through
> a
> quantum-resistant ZKP of knowledge of the hashed public key. I expect
> that in a post-quantum world there will be demand for such a fork,
> especially if we came into such a world through surprise evidence of
> a discrete log break.
>
There are simpler ways using consensus / waiting instead of zero-
knowledge, e.g.,
1. Include H(classic_pk, tx) to blockchain, wait until confirmed.
2. Reveal classic_pk, tx
This is taken from my tweet [1] but now I realize that these are
basically Guy Fawkes "signatures" [2]. Joseph Bonneau and Andrew Miller
[3] had the idea to use this for cryptocurrency without asymmetric
cryptography.
Best,
Tim
[1] https://twitter.com/real_or_random/status/948226830166786048
[2] https://www.cl.cam.ac.uk/~rja14/Papers/fawkes.pdf
[3] http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf

2023-06-07 18:06:15 UTC

- reply

📅 Original date posted:2017-09-27
📝 Original message:Oh nevermind. I had a look at the history but missed that commit and
assumed the change was introduced when adding the text to
contrib/debian/copyright
Tim
On Wed, 2017-09-27 at 22:21 +0000, Gregory Maxwell wrote:
> 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/dae0a89d4b66f08c83ccc8c20cf
> 37521084b6257
>
> (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 18:06:15 UTC

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, 2017-09-27 at 17:20 -0400, Cory Fields via bitcoin-dev wrote:
> > Creative Commons Attribution Share Alike 3.0
>
> I didn't manage to find any CC-licensed files. The match probably
> comes from our gui svg icons, which contain an xml tag with a link to
> creativecommons.org. This seems to be the default behavior of
> inkscape, which was used to create those icons. Any icons that we
> have not created ourselves are listed in contrib/debian/copyright
> (they're all expat/public domain).
This is somewhat weird. Back in 2014, most of icons were listed as
"CC BY-SA" (which is the correct license according to the original
source):
https://github.com/bitcoin/bitcoin/blob/31aac02446472ec5bfc4676ab190ec9d37056503/doc/assets-attribution.md
However the current docs list them as "Expat". A mistake?
https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/copyright
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.
Best,
Tim

2023-06-07 17:56:53 UTC

- reply

📅 Original date posted:2017-03-06
📝 Original message:On Mon, 2017-03-06 at 07:09 +0000, Luke Dashjr wrote:
> On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev
> wrote:
> > But ignoring this, the server should be authenticated at a
> > minimum. Otherwise manipulating exchange rates seems to be a nice
> > way for the attacker on the wire to make money...
>
> HTTPS would be used for that. It's not something that needs to be at
> a higher
> layer.
Sure, HTTPS is the way to go. But I think that should be required or at
least noted in the BIP, because people could miss easily, e.g., "I
don't need TLS, all the data is public anyway."
> When displaying historical transactions, it doesn't really make sense
> to use
> the current market rate, but rather the market rate at the time the
> payment
> was made. While wallets might simply cache it with the transaction,
> it would
> be perhaps nicer if it could be automatically restored for seed-only
> recoveries. In any case, if a service/wallet doesn't want to
> provide/use
> historical information, it can simply not implement that part.
>
Having the rate at the time of payment is indeed very useful, yes.
However that requires just a single value per payment, and there is no
query that tells the server "give me the value closest to timestamp t"
or similar.
Of course the client can download and keep a large part of history and
extract the information on its own but I can imagine that not every
clients wants to do that, and also the client does not know in advance
the bounds (from, to) that it must query.
> > If yes, the client should be allowed to decide on which time scale
> the
> > data should be. (tick, min, hour, day, ...) That goes together with
> > clearly defining the type field (something like low, high, open,
> close,
> > but without flexibility). Think of a candle-stick chart basically.
>
> How is the current draft insufficient for this?
>
In the current draft the client or the server cannot specify
granularity. If the clients only wants one value per day but for an
entire year, then it has to perform many requests or download and
process a very large response.
Also, I think it's okay that the type field allows for arbitrary user-
defined values, but it should also have some precisely defined values
(e.g. the mentioned low/high/open/close/typical).
For example, it's not clear currently what "low" means for a timestamp
(as opposed to a time span). Is it the low of the entire day or the low
since the previous record or something different?
One has to be careful not to add too much complexity though. As soon as
one moves away from timestamps to something like hours or days, all
kind of issues with timezone, daylight saving time etc. appear. Maybe a
simple way to let the client ask "give me one value for every interval
of 3600 seconds" or similar.
> Pushing is what longpolling does.
>
That makes a lot of sense, yes.
Tim

2023-06-07 17:56:52 UTC

- reply

📅 Original date posted:2017-03-06
📝 Original message:I'm not sure if a BIP is the right thing in that case, given that the
provided functionality is not special to Bitcoin and can be used in
other contexts as well.
But ignoring this, the server should be authenticated at a
minimum. Otherwise manipulating exchange rates seems to be a nice
way for the attacker on the wire to make money...
Apart from that, my feeling is that it could be simplified. Is
longpolling useful? And is the historical rate thing really necessary
for typical applications?
If yes, the client should be allowed to decide on which time scale the
data should be. (tick, min, hour, day, ...) That goes together with
clearly defining the type field (something like low, high, open, close,
but without flexibility). Think of a candle-stick chart basically.
Also, pushing may be more appropriate for "current" rates than polling.
Then no polling interval is necessary. On the other hand, this adds
complexity in other places, e.g., state.
Tim
On Sat, 2017-03-04 at 08:27 +0000, Luke Dashjr via bitcoin-dev wrote:
> Investigating what it would take to add fiat currency information to
> Bitcoin
> Knots, I noticed Electrum currently has many implementations, one for
> each
> exchange rate provider, due to lack of a common format for such data.
>
> Therefore, I put together an initial draft of a BIP that could
> standardise
> this so wallets (or other software) and exchange rate providers can
> simply
> interoperate without a lot of overhead reimplementing the same thing
> many
> ways.
>
> One thing I am unsure about, is that currently this draft requires
> using XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis,
> but those
> don't really have a pseudo-ISO currency code to fit in nicely...
>
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.me
> diawiki
>
> Thoughts? Anything critical missing? Ways to make the interface
> better?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:56:38 UTC

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Fri, 2017-02-24 at 00:57 +0100, Aymeric Vitte via bitcoin-dev wrote:
>
> I have not worked on this since some time, so that's just thoughts,
> but maybe it can render things much more difficult
> than computing two files until the same hash is found
>
You basically rely on the idea that specific collisions are more
difficult to find. This trick or similar tricks will not help. (And
actually, the more files you add to the hash, the more freedom you give
the attacker.)
Even if certain collisions are more difficult to find today (which is
certainly true), the general rule is that someone will prove you wrong
in a year.
Even if ignore security entirely, switching to new hash function is
much simpler trying to fix the usage of a broken hash function.
Relying on SHA1 is hopeless. We have to get rid of it.
Best,
Tim

2023-06-07 17:56:38 UTC

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Fri, 2017-02-24 at 16:18 +0100, Aymeric Vitte via bitcoin-dev wrote:
> Not sure that you really read deeply what I sent, because stating
> that
> hashing files continuously instead of hashing the intermediate steps
> just gives more latitude to the attacker can't be true when the
> attacker
> has absolutely no control over the past files
What prevents the attacker to provide different past files when talking
to parties who are still in the initial state?
Then the question is: knowing the hash state, is it as easy to find a
> collision between two files that will be computed in the next round
> than
> finding a collision between two files only?
With the original usage of the hash function, the hash state is always
the initial state. Now that the attacker has some control over the hash
state even. In other words, if the original use of the hash function
was vulnerable, then your scheme is vulnerable for the initial state.
Concrete attack: If you can find x != y with H(x) = H(y), then you can
also find m, x != y, with H(m||x) = H(m||y), just by setting m = "".
Not sure if this is the right place to discuss that issue though...
Best,
Tim

2023-06-07 15:24:51 UTC

- reply

📅 Original date posted:2014-08-06
📝 Original message:Hey,
We (a group of researchers in Germany) propose a decentralized protocol for
CoinJoin, a way to mix coins among users to improve anonymity. Our protocol is
called CoinShuffle. We believe that CoinShuffle is a way to implement CoinJoin
in the original spirit of Bitcoin, i.e., decentralized and without trusted
third parties. (If you are not familiar with CoinJoin, the idea is explained
here: https://bitcointalk.org/index.php?topic=279249.0 )
The protocol is essentially a clever way to create a CoinJoin transaction.
Recall that the idea of CoinJoin is mixing with one SINGLE transaction that
has multiple input addresses and multiple fresh output addresses (i.e., one
pair of addresses per user). The advantage of CoinJoin over mixing with a
server or trusted party is that nobody can steal coins. Each user can check if
the single transaction sends enough coins to his fresh output address. If this
is not the case, the user can just refuse to sign the transaction and nothing
(bad) happens.
The difficulty in CoinJoin is to let the participants announce their fresh
output addresses without breaking anonymity: Of course, if a participant of
the protocol just announces "I have 1 BTC at address X now" and "I would like
to have it back at address Y", then everybody can link X and Y and mixing is
useless. A naive approach is to send these two messages via a secure channel
to a server that organizes the whole mixing. While the server cannot steal
coins, the server still has to be trusted for anonymity, because it knows
which input addresses belong to which output addresses.
We present the list of CoinShuffle's features at the end of this e-mail. An
overview over the technical details can be found on the project page:
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/
Moreover, for the full details, have a look at the research paper on
CoinShuffle that can be found here:
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf
The paper has been accepted at a major European academic conference on
security (ESORICS). We will present the idea there.
Our Proof-of-concept Implementation
-----------------------------------
There is a proof-of-concept implementation (written in Python) available on
our project page. It is really only a proof-of-concept and it implements only
the announcement of the addresses, not the creation of the transaction.
Moreover, the code is CERTAINLY INSECURE and not well-written; our only goal
was to demonstrate feasibility and estimate the performance of our approach.
Our Future Plans
----------------
Now we are planning a full, open-source implementation of the protocol. Of
course, we would like to build on top of an existing wide-spread client. Since
we do not have much experience in the design of existing Bitcoin clients, we
would appreciate any help in the process. In particular, we did not decide
which of the existing clients we would like to extend. Any hints towards this
decisions would very helpful. Help in design and coding would be great but we
also would like to hear your comments, criticism, and improvements for the
protocol itself.
CoinShuffle Features
--------------------
CoinShuffle has the following features:
- Decentralization / no third party:
There is no (trusted or untrusted) third party in a run of the protocol.
(Still, as in all mixing solutions, users need some way to gather together
before they can run the protocol. This can be done via a P2P protocol if a
decentralized solution is desired also for this step.)
- Unlinkability of input and output addresses:
Nobody, in particular no server (there is none!), can link input and output
addresses of a mixing transaction, as long as there are at least two honest
participants in run of the protocol.
(This is not a weakness: If there is only one honest participant, meaningful
mixing is just impossible, no matter how it is organized. If all the other
participants collude, they know all their input and output addresses and can
immediately determine the output address of the honest participant.)
- Security against thefts:
As explained above, nobody can steal coins during the mixing because of the
CoinJoin principle.
Every participant can verify that his money will not be stolen. Otherwise, he
refuses to sign the transaction and nothing will happen.
- Robustness against denial-of-service:
In CoinJoin, a single malicious (or malfunctioning) client suffices to stop
the whole protocol (e.g., by just refusing to sing the transaction without a
proper reason.) This can easily lead to DoS attacks but these can be countered
in CoinShuffle.
While in case of disruption, the current run of the protocol has to stop,
CoinShuffle addresses this problem as follows: In case of active disruption,
i.e., some participant sends wrong messages, the protocol provides a proof of
this misbehavior. Then the honest protocol parties can start a new run of the
protocol without the misbehaving participant. Also in case of passive
disruption, i.e., some participant does not respond (for whatever reason), the
remaining participants can agree on starting a new run without this
participant. This ensures that the protocol will finally succeed even in the
presence of malicious participant (although this can take quite a while then).
- Only public-key encryption and signatures:
The protocol requires only well-established cryptographic primitives. Besides
signatures and hash functions (that are already used by Bitcoin), only
standard public-key encryption is necessary.
- Efficiency:
A run of the protocol with 30 participants takes less than 100 seconds (in a
setting with reasonable bandwidth and delay). This is not much, given that 10
min (on average) are required to confirm the mixing transaction anyway.
The costs are almost completely caused by communication. The computation
overhead is minimal. (This is the main achievement actually. In theory, it is
clear that a protocol with all the properties can be built. However, generic
constructions cannot be used in practice yet, because the computation and
communication costs are huge.)
- Compatibility:
As CoinShuffle works on top of Bitcoin, it is fully compatible with the
current Bitcoin system. No changes to the Bitcoin protocol are required.
By the way: The NXT cryptocurrency picked up our idea and an implementation of
CoinShuffle for a part of NXT is under way. (
https://twitter.com/comefrombeyond/status/485429369268350977 )
TL,DR:
Mixing is the way to improve anonymity in Bitcoin now, as it does not require
changes to the Bitcoin protocol. We propose CoinShuffle, a decentralized
protocol to perform mixing in a secure way without trusted third parties, see
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/ for a technical
overview. Our next step is to implement the protocol. Help in design and
coding would be great but we also would like to hear your comments, criticism,
and improvements for the protocol itself.
Best,
Tim Ruffing, Pedro Moreno-Sanchez, Aniket Kate
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140807/f43f0fc1/attachment.sig>