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
Small correction, see edited quote
Den 15 feb. 2018 23:44 skrev "Natanael" :
Allowing expiration retains insecurity, while *NOT* allowing expiration
makes it a trivial DoS target.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https:
Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
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 ma
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
Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
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 c
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
