On Mon, 2023-10-23 at 15:35 +, Peter Todd via bitcoin-dev wrote:
> Thus
> we should limit BIP assignment to the minimum possible: _extremely_
> widespread
> standards used by the _entire_ Bitcoin community, for the core
> mission of
> Bitcoin.
BIPs are Bitcoin Improvement *Proposals*. What you
Hello,
We'd like to announce two recent updates to BIP324 ("Version 2 P2P
Encrypted Transport Protocol"). Some of these changes affect semantics
and some are backwards-incompatible.
While we are not aware of any implementations of BIP324 except the one
in Bitcoin Core (see https://github.com/bitc
Hello,
We'd like to announce the release of version 0.3.2 of libsecp256k1:
https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.2
This is a bugfix release after 0.3.1. The impetus for this release is
the discovery that GCC 13 became smart enough to optimize out a
specific timing side-ch
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
On Sat, 2021-05-15 at 12:21 +0200, vjudeu via bitcoin-dev wrote:
> All that is needed is producing a signature matching the sum of the
> public keys used in taproot, which is "(a+b-a)*G",
This is simply not true.
Taproot does not enable this, or any other form of "cross-input
aggregation", i.
On Mon, 2021-03-22 at 10:24 -0400, Erik Aronesty via bitcoin-dev wrote:
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
Yes, for sure. This is certainly somet
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 publ
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
Hi Dustin,
That sounds interesting but I can't follow your email to be honest.
On Mon, 2020-03-23 at 07:38 -0700, Dustin Dettmer via bitcoin-dev
wrote:
> This mitigates, I believe, all leak vectors besides k/R hacking and
> prechosen entropy.
Hm, so what vectors is this supposed to mitigate? Lea
I think your proposal is simply to use BIP32 for all derivations and
the observation that you can work with derived keys with the
corresponding suffixes of the path. I believe that this is a good idea.
But I don't think that simply writing a standard will help. It's just
one step. If all your wall
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 signa
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 s
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_
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 completel
; twice, it should help reduce the attack surface.
>
> On Mon, Feb 24, 2020 at 6:41 AM Tim Ruffing via bitcoin-dev
> wrote:
> > On Sun, 2020-02-23 at 02:27 -0500, Erik Aronesty via bitcoin-dev
> > wrote:
> > > > Thus, two-phase MuSig is potentially unsafe.
> >
On Sun, 2020-02-23 at 02:27 -0500, Erik Aronesty via bitcoin-dev wrote:
> > Thus, two-phase MuSig is potentially unsafe.
> > https://eprint.iacr.org/2018/417.pdf describes the argument.
>
> One solution is to add a signature timeout to the message (say a
> block height) .
>
> A participant refu
On Fri, 2018-09-07 at 02:31 +, 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, b
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
Is it intentional that the encoding of public (and private) keys is
unspecified? I'd consider at least the encoding of the public key to be
part of the signature scheme, so ideally it should be specified already
in this BIP. On the other hand, there may be good arguments against it,
but I'm not awa
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?
(Simi
n for the
case when one really solves the delegated script (as you mentioned) but
only in this case.
Tim
On Wed, 2018-06-06 at 10:04 -0700, Pieter Wuille wrote:
> On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev
> wrote:
> > On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille
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
> t
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 Thu, 2018-02-15 at 23:44 +0100, Natanael wrote:
> If your argument is that we publish the full transaction minus the
> public key and signatures, just committing to it, and then revealing
> that later (which means an attacker can't modify the transaction in
> advance in a way that produces a val
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
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 spendi
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 -d...@lists.linux
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 a
n tx.
I'm pretty confident that I'm not overlooking an obvious attack. If I'm
wrong then please describe exactly the steps of the user and the
attacker.
Best,
Tim
On Thu, 2018-01-25 at 01:09 +0100, Natanael wrote:
>
> Den 25 jan. 2018 00:22 skrev "Tim Ruffing
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 publ
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
On Wed, 2018-01-24 at 01:52 +, 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 knowl
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 +, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 9:54 PM, Tim Ruffing via bitcoin-dev
> wrote:
&g
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
On Tue, 2017-04-18 at 12:34 +0200, Natanael via bitcoin-dev wrote:
> To prove that an implementation is near optimal, you would show
> there's a minimum number of necessary transistor activations per
> computed hash, and that your implementation is within a reasonable
> range of that number.
I'm
I don't have an opinion on whether signaling is a good idea in general.
However I don't think that using addresses is a good idea, because this
has privacy implications. For example, it makes it much easier to link
the addresses, e.g., inputs with change address. (The change address
votes for the
(I'm not a lawyer...)
I'm not sure if I can make sense of your email.
On Mon, 2017-03-20 at 20:12 +, Martin Stolze via bitcoin-dev wrote:
> As a participant in the economy in general and of Bitcoin in
> particular, I desire an ability to decide where I transact. The
> current state of Bitcoin
On Mon, 2017-03-06 at 17:30 -0500, Tim Ruffing via bitcoin-dev wrote:
>
> That works but a standardized way of indicating that piece of
> information to the client is useful. Then the client can display a
> "connection status" to the user, e.g., an "possible out-
On Mon, 2017-03-06 at 22:14 +, Luke Dashjr wrote:
> It would be a privacy leak to request only the specific timestamps,
> but I
> suppose many wallets lack even basic privacy to begin with.
>
> To address the bounds issue, I have specified that when from/to don't
> have an
> exact record, th
On Mon, 2017-03-06 at 16:54 -0500, Tim Ruffing via bitcoin-dev wrote:
>
> > Pushing is what longpolling does.
> >
>
> That makes a lot of sense, yes.
>
Forgot one thing:
For longpolling, maybe we would like to have the possibility to request
some periodic message fr
On Mon, 2017-03-06 at 07:09 +, 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
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 th
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
> ha
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
Not a covenant but interesting nevertheless: _One_ of OP_CAT and
OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner
takes double-spend" [1]:
You can create an output, which is spendable by everybody if you ever
double-spend the output with two different transactions. Then the ne
45 matches
Mail list logo
