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
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 fee
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
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 agg
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/verifica
> 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" sch
- 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 a
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, the
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
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
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 wor
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 mome
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.co
13 matches
Mail list logo
