[bitcoin-dev] Schnorr signatures BIP

Hello everyone, Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures, over the same curve as is currently used in ECDSA: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki It is simply a draft specification of the signature scheme itself. It does not concern conse

[bitcoin-dev] BIP 174 thoughts

On 4.7.2018 20:35, Achow101 wrote: > You cannot simply reject PSBTs for having conflicting values for the same > key. Especially > for the Partial Signatures, you can have two signatures for the same pubkey > that are both (...) > order to avoid the conflict. That complicates things and is muc

Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

Dear Bradley, maybe I’m a little bit late to the discussion, but I’d also like to share some thoughts: * Could you elaborate on the reasoning behind choosing the periodic route shuffling interval to be around 10 minutes? I guess that there is some tradeoff between making intersection attacks p

Re: [bitcoin-dev] BIP 174 thoughts

Has there been any thought to standardizing file names used when creating .psbt files? Maybe something that gives some reliability of being collision resistant and descriptive. For example: [8 char trim of hash of unsigned tx]+[Role that created file (Ex: Signer)]+[4 char trim of hash of data uniq

Re: [bitcoin-dev] BIP 174 thoughts

I have another concern with the format. (my original bip comment for some context: [1]) It looks like the one of the reasons I was confused is because you can only parse the format properly by first deserializing the transaction. Since there is no "length" field for the key-value map arrays, yo

Re: [bitcoin-dev] An efficient re-implementation of Electrum Server in Rust

This is awesome, nice work! On Mon, Jul 2, 2018 at 4:16 PM Roman Zeyde via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > I was working on this project for the last few months, so a user could run > his own Electrum server, with required hardware resources not much b

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

You can provide a reusable payment code (BIP-47) instead of an actual address. Unfortunately that not yet supported by the clients/apps most people use. Just that would be less a hurdle than providing a service that e.g. generates addresses from xpub. Am July 4, 2018 6:08:43 PM UTC schrieb fred

Re: [bitcoin-dev] BIP 174 thoughts

Hi, ‐‐‐ Original Message ‐‐‐ On July 5, 2018 12:20 PM, William Casarin wrote: > ​​ > > I have another concern with the format. (my original bip comment for some > context: [1]) > > It looks like the one of the reasons I was confused is because you can > > only parse the format prope

Re: [bitcoin-dev] Schnorr signatures BIP

Some quick comments: Signing > > To sign: > >- Let *k = int(hash(bytes(d) || m)) mod n*[8 > > >]. >- Let *R = kG*. >- If *jacobi(y(R)) ≠ 1*, let *k = n - k*. >- Let *e = int(hash(bytes(x(R)) |

Re: [bitcoin-dev] Schnorr signatures BIP

On Fri, Jul 6, 2018 at 9:05 PM, Russell O'Connor via bitcoin-dev wrote: > If the inputs to hash were reordered as hash(bytes(dG) || bytes(x(R)) || m) > then there is an opportunity for SHA256 expander to be partially prefilled > for a fixed public key. This could provide a little benefit, especia

Re: [bitcoin-dev] Schnorr signatures BIP

On Fri, Jul 6, 2018 at 10:00 PM, Gregory Maxwell wrote: > There is a minor design preference to have message before nonce when ::sigh:: to NOT have the message before the nonce. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://