<unnamed>

Public Key

npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwkls

Profile Code

nprofile1qqsvd4ayqzyhgcxe5tq8hwk4sucmd5zzvlkawkh59t6973cmq3vpasspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgmxwzy8

Publishing to

relay.primal.net

Last Notes

2023-06-07 20:31:00 CEST

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

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

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

- 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 20:14:33 CEST

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

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

- reply

📅 Original date posted:2018-03-12
📝 Original message:You're right that this is a simple electronic voting scheme. The thing
is that cryptographers are working on e-voting for decades and the idea
to use homomorphic commitments (or encryption) and zero-knowledge
proofs is not new in this area. It's rather the case that e-voting
inspired a lot of work on homomorphic crypto and related zero-knowledge
proofs. For example, range proofs are overkill in e-voting. You just
need to ensure that the sum of all my votes (over all candidates) is 1.
E-voting protocols typically require some "bulletin board", where
ballots are stored. A blockchain could indeed be helpful in specific
cases (but not in all cases)...
If you're interested in that stuff, I'd suggest you to read some
literature about e-voting. (For example,
https://arxiv.org/pdf/1801.08064 looks interesting for the connection
to blockchains -- I haven't read it though). There are pretty
sophisticated protocols in the literature. And I think that this
mailing list may not be the best place to discuss these.
Best,
Tim
On Sun, 2018-03-11 at 13:44 +0100, JOSE FEMENIAS CAÑUELO via bitcoin-
dev wrote:
> If I understand Bulletproof Confidential Transactions properly, their
> main virtue is being able to hide not the senders/receivers of a coin
> but the amount transferred.
> That sounds to me like a perfect use case for an election.
> For instance, in my country, every citizen is issued a National ID
> Card with a digital certificate.
> So, a naive implementation could simply be that the Voting Authority,
> sends a coin (1 coin = 1 vote) to each citizen above 18. This would
> be an open transaction, so it is easily auditable.
> Later on, each voter sends her coin to her preferred party, as part
> of a Bulletproof CT, along with 0 coins to other parties to disguise
> her vote.
> In the end, each party will accrue as may votes as coins received.
>
> Is there any gotcha I’m missing here? Are there any missing features
> required in Bulletproof to support this use case?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:10:39 CEST

- 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 20:10:38 CEST

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

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

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

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

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

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

- 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 17:24:51 CEST

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