Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale
This is the sort of thing I expect to emerge from the places that use Bitcoin "on the street." We should be watching how local wallet software displays bitcoin amounts, letting the standards write themselves over time. The units debate (bits, millibits, etc) has been going on nearly as long as I've known about Bitcoin and yet most tools display standard bitcoin amounts (1 unit = 1e8 satoshi). -Clark On Wed, Sep 12, 2018 at 8:41 AM Martin Damgaard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A very good point. I have realized the immature nature of my suggestion > due to this and a number of other good remarks, and will like to retract > the initial suggestion. > > Thank you and all the best > > Martin Damgaard > > > > *Fra: *Karl-Johan Alm > *Sendt: *12. september 2018 08:14 > *Til: *damgaard.mar...@gmail.com; Bitcoin Protocol Discussion > > *Emne: *Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale > > > > A potential problem is that it would be a new attack vector to simply > > color something to appear as e.g. 10x more than it really is, if > > everyone started using this system. > > On Sun, Aug 19, 2018 at 5:27 AM Martin Damgaard via bitcoin-dev > > wrote: > > > > > > Hi bitcoin-dev@lists.linuxfoundation.org > > > > > > Here is my humble attempt to make a contribution to the impressive work > that you all are doing. > > > > > > I am unfamiliar with the normal BIP procedures. I have therefore just > tried to follow the example of BIP 176 by Jimmy Song, in order make > something similar. I suggest a universal bitcoin value color scale, for > tackling the same decimal problem, as identified by the BIP 176 proposal. > > > > > > I have attached the document in three different formats (*.rtf, *.pdf > and *.docx) as I do not know your preferred format. I hope you will find my > suggestion useful. > > > > > > > > > > > > Thank you and all the best > > > > > > Martin Damgaard > > > > > > ___ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] RFC: BIP 322: Generic Signed Message Format
Greetings,
(The quoted proposal is already outdated, and I recommend you check
out the up to date formatted version here:
https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-0322.mediawiki
The PR with comments is here: https://github.com/bitcoin/bips/pull/725)
A big part of the feedback boils down to conflicts of opinion related
to whether or not proofs should be given as transactions or not.
I am attempting to write down the pros and cons below, some of which
are contradictory/complementary based on multiple people's opinions.
Pros of using transaction format:
1. works out of the box with existing HSM:s, some of which may be
purposefully built to not be upgradable for security reasons (unless
sighash modified; see below)
2. easier to incorporate into existing software
3. forward compatible with bitcoin extensions (e.g. mimblewimble,
confidential transactions, etc)
4. HSM:s *should* be blind to whether or not a transaction or a
message or proof of funds is being signed (see Con #3)
Cons:
1. dangerous if challenger is able to convince prover to sign a
message that corresponds to an actual transaction; modifying sighash
is suggested, but defeats pro #1 above; can define in tx to have txin
as sighash to guarantee invalid on chain
2. unupgraded software are unable to make distinction between message
sign and transaction sign
3. if HSM:s do not support it and do not support upgrading, this is by
design, and message signing should be explicitly supported or not be
possible (see Pro #4)
4. severely cripples UX for hardware wallets that actually show the
contents of the transaction during the signing
If anyone has comments on this, it would be tremendously appreciated.
There is also a divided opinion on whether an "OP_MESSAGEONLY" opcode
should be introduced, but I'd like to address the above first, if
possible.
On Tue, Sep 11, 2018 at 1:41 PM Karl-Johan Alm
wrote:
>
> Hi.
>
> [note: BIP number was assigned to PR before this email was sent; I did
> not self-assign the BIP number]
>
> Below is a proposal to extend the existing sign/verifymessage format
> to a more generalized variant relying on the script verification
> mechanism in Bitcoin itself for message signing/verification, based on
> the original discussion
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html)
> .
>
> PR is here: https://github.com/bitcoin/bips/pull/725
>
> A formatted version of this text can be seen here:
> https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-generic-signmessage.mediawiki
>
> Note: I am not sure how to best deal with CLTV/CSV stuff here, ultimately.
>
> Note 2: I have received suggestions from several people to use a
> Bitcoin transaction instead. If someone could explain why this is
> beneficial, it would be very helpful. I'm not against it, just feels
> like the whole transaction part is unnecessary complexity/overhead.
>
> ---
>
> BIP: 322
> Layer: Applications
> Title: Generic Signed Message Format
> Author: Karl-Johan Alm
> Comments-Summary: No comments yet.
> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
> Status: Draft
> Type: Standards Track
> Created: 2018-09-10
> License: CC0-1.0
>
>
> == Abstract ==
>
> A standard for interoperable generic signed messages based on the
> Bitcoin Script format.
>
> == Motivation ==
>
> The current message signing standard only works for P2PKH (1...)
> addresses. By extending it to use a Bitcoin Script based approach, it
> could be made more generic without causing a too big burden on
> implementers, who most likely have access to Bitcoin Script
> interpreters already.
>
> == Specification ==
>
> A new structure SignatureProof is added, which is a
> simple serializable scriptSig & witnessProgram container.
>
> Two actions "Sign" and "Verify" are defined.
>
> === SignatureProof container ===
>
> {|class="wikitable" style="text-align: center;"
> |-
> !Type
> !Length
> !Name
> !Comment
> |-
> |Uint32||4||flags||standard flags (1-to-1 with standard flags in Bitcoin Core)
> |-
> |VarInt||1-8||msglen||Number of bytes in message string, excluding NUL
> termination
> |-
> |Char*||[msglen]||msg||The message being signed for all subjects,
> excluding NUL termination
> |-
> |Uint8||1||entries||Number of proof entriesWhy support
> multiple proofs? In particular with proof of funds, it is
> non-trivial to check a large number of individual proofs (one per
> UTXO) for duplicates. Software could be written to do so, but it seems
> more efficient to build this check into the specification
> itself.
> |}
>
> The above is followed by [entries] number of signature entries:
>
> {|class="wikitable" style="text-align: center;"
> |-
> !Type
> !Length
> !Name
> !Comment
> |-
> |VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data
> |-
> |Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
> |-
> |VarInt||1-8||witlen||Number of bytes in witness program data
> |-
>
Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale
A potential problem is that it would be a new attack vector to simply color something to appear as e.g. 10x more than it really is, if everyone started using this system. On Sun, Aug 19, 2018 at 5:27 AM Martin Damgaard via bitcoin-dev wrote: > > Hi bitcoin-dev@lists.linuxfoundation.org > > Here is my humble attempt to make a contribution to the impressive work that > you all are doing. > > I am unfamiliar with the normal BIP procedures. I have therefore just tried > to follow the example of BIP 176 by Jimmy Song, in order make something > similar. I suggest a universal bitcoin value color scale, for tackling the > same decimal problem, as identified by the BIP 176 proposal. > > I have attached the document in three different formats (*.rtf, *.pdf and > *.docx) as I do not know your preferred format. I hope you will find my > suggestion useful. > > > > Thank you and all the best > > Martin Damgaard > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Multisignature for bip-schnorr
Hi Jonas Thank you for your comment. I wrote a new text. https://gist.github.com/tnakagawa/e6cec9a89f698997dc58a09db541e1eb If you have time, please review this. 2018年9月7日(金) 17:09 Jonas Nick : > > Your multisignature writeup appears to be vulnerable to key cancellation > attacks because the aggregated public key is just the sum of public keys (and > there is no proof of knowledge of the individual secret keys). Therefore, in a > multisignature between Alice and an attacker, the attacker can choose their > key > to be -alice_key+attacker_key resulting in an aggregated key for which the > attacker can sign alone (without requiring Alice's partial signature). The > Schnorr BIP links to the MuSig paper which describes a secure key aggregation > scheme. See https://eprint.iacr.org/2018/068 > > On 8/7/18 6:35 AM, nakagat via bitcoin-dev wrote: > > Hi all, > > > > I wrote a multisignature procedure using bip-schnorr. > > > > If you have time to review and give feedback, I’d really appreciate it. > > Thanks in advance! > > > > Multisignature > > https://gist.github.com/tnakagawa/0c3bc74a9a44bd26af9b9248dfbe598b > > > > Original > > https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#Multisignatures_and_Threshold_Signatures > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] RFC: BIP 322: Generic Signed Message Format
Hi.
[note: BIP number was assigned to PR before this email was sent; I did
not self-assign the BIP number]
Below is a proposal to extend the existing sign/verifymessage format
to a more generalized variant relying on the script verification
mechanism in Bitcoin itself for message signing/verification, based on
the original discussion
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015818.html)
.
PR is here: https://github.com/bitcoin/bips/pull/725
A formatted version of this text can be seen here:
https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-generic-signmessage.mediawiki
Note: I am not sure how to best deal with CLTV/CSV stuff here, ultimately.
Note 2: I have received suggestions from several people to use a
Bitcoin transaction instead. If someone could explain why this is
beneficial, it would be very helpful. I'm not against it, just feels
like the whole transaction part is unnecessary complexity/overhead.
---
BIP: 322
Layer: Applications
Title: Generic Signed Message Format
Author: Karl-Johan Alm
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
Status: Draft
Type: Standards Track
Created: 2018-09-10
License: CC0-1.0
== Abstract ==
A standard for interoperable generic signed messages based on the
Bitcoin Script format.
== Motivation ==
The current message signing standard only works for P2PKH (1...)
addresses. By extending it to use a Bitcoin Script based approach, it
could be made more generic without causing a too big burden on
implementers, who most likely have access to Bitcoin Script
interpreters already.
== Specification ==
A new structure SignatureProof is added, which is a
simple serializable scriptSig & witnessProgram container.
Two actions "Sign" and "Verify" are defined.
=== SignatureProof container ===
{|class="wikitable" style="text-align: center;"
|-
!Type
!Length
!Name
!Comment
|-
|Uint32||4||flags||standard flags (1-to-1 with standard flags in Bitcoin Core)
|-
|VarInt||1-8||msglen||Number of bytes in message string, excluding NUL
termination
|-
|Char*||[msglen]||msg||The message being signed for all subjects,
excluding NUL termination
|-
|Uint8||1||entries||Number of proof entriesWhy support
multiple proofs? In particular with proof of funds, it is
non-trivial to check a large number of individual proofs (one per
UTXO) for duplicates. Software could be written to do so, but it seems
more efficient to build this check into the specification
itself.
|}
The above is followed by [entries] number of signature entries:
{|class="wikitable" style="text-align: center;"
|-
!Type
!Length
!Name
!Comment
|-
|VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data
|-
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
|-
|VarInt||1-8||witlen||Number of bytes in witness program data
|-
|Uint8*||[witlen]||wit||Witness program
|}
In some cases, the scriptsig may be empty (scriptsiglen=0).
=== Signing ===
The "Sign" action takes as input a scriptPubKey and a message (e.g.
"hello world"). It succeeds or fails.
# FAIL if scriptPubKey already exists in scriptPubKeys set, otherwise
insert itWhy track duplicates? Because a 3-entry
proof is not proving 3 scriptPubKeys unless they are all distinct, or
unless they are proving different UTXO:s (see Future Extensions)
# Derive the private key privkey for the scriptPubKey, or FAIL
# Define the message pre-image as the sequence "Bitcoin Message:"
concatenated with the message, encoded in UTF-8 using Normalization
Form Compatibility Decomposition (NFKD)
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
# Generate a signature sig with privkey=privkey, sighash=sighash
Repeat the above operation for each scriptPubKey, retaining the
scriptPubKeys set. As noted, if the same scriptPubKey appears more
than once, the sign operation must fail.
=== Verifying ===
The "Verify" action takes as input a standard flags value, a
scriptPubKey, a message, a script sig, and a witness program.
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
# Return ERROR if scriptPubKey already exists in scriptPubKeys set,
otherwise insert it
# If one or more of the standard flags are unknown, return INCONCLUSIVE
# Define the message pre-image as the sequence "Bitcoin Message:"
concatenated with the message, encoded in UTF-8 using Normalization
Form Compatibility Decomposition (NFKD).
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
# Verify Script with flags=standard flags, scriptSig=script sig,
scriptPubKey=scriptPubKey, witness=witness program, and
sighash=sighash
# Return VALID if verify succeeds, otherwise return INVALID
Repeat the above operation for each scriptPubKey, retaining the
scriptPubKeys set. As noted, if the same scriptPubKey appears more
than once, the verify operation must fail with an ERROR.
* If a verification call returns ERROR or INVALID, return ERROR or
INVALID immediately, ignoring as yet unverified entries.
Re: [bitcoin-dev] Schnorr signatures BIP
> That approach has its uses but I think that in any case where delinearization can be used it's a better option. I agree, communication efficiency is a concern for some applications, and I can think of cases where delinearization is the better option as well. For users that want an "M of N" scheme that a) doesn't cost more to send funds b) allows them to lose a device and keep their coins c) allows them to establish and validate the scheme safely ... a simple, "verified signer" threshold scheme is probably the best solution. On Tue, Sep 11, 2018 at 1:51 PM Gregory Maxwell wrote: > On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty wrote: > > > > - Musig, by being M of M, is inherently prone to loss. > > M of M is a particular threshold. If you want M of M (there are > plenty of cases where M of M _must_ be used) then you get the > consequences of M of M, which presumably you want. > > This has nothing to do with musig. If you want a threshold other than > M of M then you use a threshold other than M of M. > > No one is under the impression that M of M is somehow a replacement > for other thresholds. We've spent more time talking about M of M in > some writeups in the past because it's exactly the case you need for > signature aggregation in Bitcoin and because it's a simpler case to > explain. > > > - Having the senders of the G*x pubkey shares sign their messages with > the associated private key share should be sufficient to prevent them from > using wagner's algorithm to attack the combined key. > > Yes, that is one possibility which is described in the musig paper, > but it requires users communicate an extra signature per key. So, for > example, if used with aggregate signature it would completely > eliminate the communications efficiency gains from aggregation, making > aggregation worse than pointless. It also has somewhat worse failure > properties than delinearization, because a signer that fails to > validate other's share signatures behaves behaves exactly the same as > a correct one, on honest inputs. That approach has its uses but I > think that in any case where delinearization can be used it's a better > option. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
- Musig, by being M of M, is inherently prone to loss. - Having the senders of the G*x pubkey shares sign their messages with the associated private key share should be sufficient to prevent them from using wagner's algorithm to attack the combined key. Likewise, the G*k nonce fragments should also be signed with the pubkey shares. On Tue, Sep 11, 2018 at 1:27 PM Gregory Maxwell wrote: > On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty wrote: > > The security advantages of a redistributable threshold system are huge. > If a system isn't redistributable, then a single lost or compromised key > results in lost coins... meaning the system is essetntially unusable. > > > > I'm actually worried that Bitcoin releases a multisig that encourages > loss. > > There is no "non- edistributiable multisig" proposed for Bitcoin > anywhere that I am aware of. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
Greg, I added, stripped out, and added analogous musig delinearization 3 times in response to stuff posted here. I'm adding it back now. Not sure why my head is thick around that issue. The security advantages of a redistributable threshold system are huge. If a system isn't redistributable, then a single lost or compromised key results in lost coins... meaning the system is essetntially unusable. I'm actually worried that Bitcoin releases a multisig that encourages loss. On Tue, Sep 11, 2018 at 1:00 PM Gregory Maxwell wrote: > On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty wrote: > >> To answer points: >> >> - I switched to the medium article so that I could correct, edit and >> improve things to make them more clear. >> - I responded to feedback by modifying the protocol to make it work - not >> by ignoring it. >> > > To this moment there remains no response at your post. > https://bitcointalk.org/index.php?topic=4973123.0 > > I'm not sure how I am supposted to have figured out that you wrote a > somewhat different repost of it elsewhere... > > - An M-1 rogue-key attack would require the attacker would to either >> >> - attack the hash function to produce a predictable R based on a known >> mesage >> - attack the DLP to influence x or k >> >> Neither attack gives any particular advantage to someone who has M-1 keys. >> > > You keep asserting this. It isn't true. Asserting it more does not make it > any more true. I already explained how to attack this style of signature > (e.g. in the BCT thread). > > Set aside your 'interpolation' for a moment, and imagine that you > construct a 2 of 2 signature by just adding the keys. Your tell me your > key, P1 and then I tell you that my key P2 which I derived by computing > -P1 + xG. We now compute P = P1 + P2 = P1 + -P1 + xG = xG ... and now in > spite adding P1 with an unknown discrete log, I know the discrete log of P > with respect to G and I did not need to violate the standard DL security > assumption to achieve that. > > With the 'interpolation' in effect the same attack applies but its > execution is somewhat more complex: instead of adding the negation of P1 I > must add a number of multiplicities of P1 (like P1*2, P1*3, P1*4...) > selected so that their interpolation coefficients add up to -1. Finding a > suitable subset requires solving a randomized modular subset sum problem > and Wagner's algorithm provides a computationally tractable solution to it. > > The potential of rogue keys applies to both the keys themselves and to the > nonces. There are several ways to prevent these attacks, the musig paper > describes a delinearization technique which doesn't require additional > interaction or communication. > > I haven't tested whether the R,s version is susceptible though. >> > > There is a perfect bijection between the two encodings which is easily > computable, so they're the same thing from an abstract security perspective. > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
To answer points: - I switched to the medium article so that I could correct, edit and improve things to make them more clear. - I responded to feedback by modifying the protocol to make it work - not by ignoring it. - I coded it up in python so I could be sure it worked, because I was concerned that it was broken - Yes, coding it up showed me that it's definitely interactive, and no different than a "standard shnorr sig" in any meaningful way regarding the security - No special protocol support is needed over Schnorr signing itself. The e, s version can be made at least as secure as schnorr + DLP. I haven't researched the R,s version. - An M-1 rogue-key attack would require the attacker would to either - attack the hash function to produce a predictable R based on a known mesage - attack the DLP to influence x or k Neither attack gives any particular advantage to someone who has M-1 keys. I haven't tested whether the R,s version is susceptible though. On Thu, Sep 6, 2018 at 9:15 AM Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev > wrote: > > Detailed explanation with code snippets: > > > > https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip] > > This appears to be a repost of the broken scheme you posted about on > Bitcointalk, but then failed to respond to the response. > > https://bitcointalk.org/index.php?topic=4973123.0 > > > The more I look into it and speak to professors about i, the more it > seems "so trivial nobody really talks about it". > > I think you might be falling into the trap of ignoring feedback you > don't like and and accepting that which sounds like "yea yea, > something like that". > > Something "like that" does work: and is expressly and explicitly > anticipated by the BIP but to be both secure and functional requires > proper delineation (E.g. musig) _and_ interaction. What you're > proposing is continually vague. My best efforts at making sense of > what you've written indicate that either it's non-interactive and > not-actually functional at all, OR it's interactive and just a less > secure subset (no proper delinearization to prevent rogue key attacks) > of what we already propose. > > When Poelstra suggests a CAS implementation he means something like > this Sage notebook: http://bitcoin.ninja/secp256k1.ecdsa.sage This > provides for a method of communicating in both directions which is > completely precise. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
On Tue, Sep 11, 2018 at 5:38 PM Erik Aronesty wrote: > > - Musig, by being M of M, is inherently prone to loss. M of M is a particular threshold. If you want M of M (there are plenty of cases where M of M _must_ be used) then you get the consequences of M of M, which presumably you want. This has nothing to do with musig. If you want a threshold other than M of M then you use a threshold other than M of M. No one is under the impression that M of M is somehow a replacement for other thresholds. We've spent more time talking about M of M in some writeups in the past because it's exactly the case you need for signature aggregation in Bitcoin and because it's a simpler case to explain. > - Having the senders of the G*x pubkey shares sign their messages with the > associated private key share should be sufficient to prevent them from using > wagner's algorithm to attack the combined key. Yes, that is one possibility which is described in the musig paper, but it requires users communicate an extra signature per key. So, for example, if used with aggregate signature it would completely eliminate the communications efficiency gains from aggregation, making aggregation worse than pointless. It also has somewhat worse failure properties than delinearization, because a signer that fails to validate other's share signatures behaves behaves exactly the same as a correct one, on honest inputs. That approach has its uses but I think that in any case where delinearization can be used it's a better option. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
On Tue, Sep 11, 2018 at 5:20 PM Erik Aronesty wrote: > The security advantages of a redistributable threshold system are huge. If > a system isn't redistributable, then a single lost or compromised key results > in lost coins... meaning the system is essetntially unusable. > > I'm actually worried that Bitcoin releases a multisig that encourages loss. There is no "non- edistributiable multisig" proposed for Bitcoin anywhere that I am aware of. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Schnorr signatures BIP
On Tue, Sep 11, 2018 at 4:34 PM Erik Aronesty wrote: > To answer points: > > - I switched to the medium article so that I could correct, edit and > improve things to make them more clear. > - I responded to feedback by modifying the protocol to make it work - not > by ignoring it. > To this moment there remains no response at your post. https://bitcointalk.org/index.php?topic=4973123.0 I'm not sure how I am supposted to have figured out that you wrote a somewhat different repost of it elsewhere... - An M-1 rogue-key attack would require the attacker would to either > > - attack the hash function to produce a predictable R based on a known > mesage > - attack the DLP to influence x or k > > Neither attack gives any particular advantage to someone who has M-1 keys. > You keep asserting this. It isn't true. Asserting it more does not make it any more true. I already explained how to attack this style of signature (e.g. in the BCT thread). Set aside your 'interpolation' for a moment, and imagine that you construct a 2 of 2 signature by just adding the keys. Your tell me your key, P1 and then I tell you that my key P2 which I derived by computing -P1 + xG. We now compute P = P1 + P2 = P1 + -P1 + xG = xG ... and now in spite adding P1 with an unknown discrete log, I know the discrete log of P with respect to G and I did not need to violate the standard DL security assumption to achieve that. With the 'interpolation' in effect the same attack applies but its execution is somewhat more complex: instead of adding the negation of P1 I must add a number of multiplicities of P1 (like P1*2, P1*3, P1*4...) selected so that their interpolation coefficients add up to -1. Finding a suitable subset requires solving a randomized modular subset sum problem and Wagner's algorithm provides a computationally tractable solution to it. The potential of rogue keys applies to both the keys themselves and to the nonces. There are several ways to prevent these attacks, the musig paper describes a delinearization technique which doesn't require additional interaction or communication. I haven't tested whether the R,s version is susceptible though. > There is a perfect bijection between the two encodings which is easily computable, so they're the same thing from an abstract security perspective. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale
A very good point. I have realized the immature nature of my suggestion due to this and a number of other good remarks, and will like to retract the initial suggestion. Thank you and all the best Martin Damgaard Fra: Karl-Johan Alm Sendt: 12. september 2018 08:14 Til: damgaard.mar...@gmail.com; Bitcoin Protocol Discussion Emne: Re: [bitcoin-dev] Suggestion for a universal bitcoin value scale A potential problem is that it would be a new attack vector to simply color something to appear as e.g. 10x more than it really is, if everyone started using this system. On Sun, Aug 19, 2018 at 5:27 AM Martin Damgaard via bitcoin-dev wrote: > > Hi bitcoin-dev@lists.linuxfoundation.org > > Here is my humble attempt to make a contribution to the impressive work that > you all are doing. > > I am unfamiliar with the normal BIP procedures. I have therefore just tried > to follow the example of BIP 176 by Jimmy Song, in order make something > similar. I suggest a universal bitcoin value color scale, for tackling the > same decimal problem, as identified by the BIP 176 proposal. > > I have attached the document in three different formats (*.rtf, *.pdf and > *.docx) as I do not know your preferred format. I hope you will find my > suggestion useful. > > > > Thank you and all the best > > Martin Damgaard > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
