📅 Original date posted:2014-03-08
📝 Original message:You can always use a secure multiparty computation algorithm to do it.
https://en.wikipedia.org/wiki/Secure_multi-party_computation
But those aren't the fastest algorithms in the world, and usually both
participants needs to be online at the same time. I guess most people would
prefer a two-step algorithm that can be performed asynchronously.
- Sent from my phone
Den 8 mar 2014 18:44 skrev "Adam Back" <adam at cypherspace.org>:
> Also the other limitation for ECDSA is that there is no known protocol to
> create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without
> either a sending its private key to b or viceversa (or both to a third
> party).
>
> With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a
> (secure)
> direct multiparty signature quite difficult.
>
> ps probably only 1 party needs to hash their key
>
> P=aG
> H(P) ->
>
> <- Q=bG
>
> P ->
>
> Adam
>
> On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
> > If both parties insist on seeing a hash of the other party's public key
> > before they'll show their own public key, they can be sure that the
> > public key is not chosen based on the public key they themselves
> > presented.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/7bff5314/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 15:14:38
in reply to nevent1q…ghqw
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 15:14:38Event JSON
{
"id": "ae4d47899f816f2f3f7d0a69ccdefe383d30700f5c7aafdaa56e05b01da51c49",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686150878,
"kind": 1,
"tags": [
[
"e",
"a6dc4c63eb9cc184811ab757ec03e54259d685e9ca9a0fa081c9c1805eb862b9",
"",
"root"
],
[
"e",
"476a1da1259adbf35837f936fd4bcaa74400806998363bb8ae7cda1589caef20",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2014-03-08\n📝 Original message:You can always use a secure multiparty computation algorithm to do it.\n\nhttps://en.wikipedia.org/wiki/Secure_multi-party_computation\n\nBut those aren't the fastest algorithms in the world, and usually both\nparticipants needs to be online at the same time. I guess most people would\nprefer a two-step algorithm that can be performed asynchronously.\n\n- Sent from my phone\nDen 8 mar 2014 18:44 skrev \"Adam Back\" \u003cadam at cypherspace.org\u003e:\n\n\u003e Also the other limitation for ECDSA is that there is no known protocol to\n\u003e create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without\n\u003e either a sending its private key to b or viceversa (or both to a third\n\u003e party).\n\u003e\n\u003e With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a\n\u003e (secure)\n\u003e direct multiparty signature quite difficult.\n\u003e\n\u003e ps probably only 1 party needs to hash their key\n\u003e\n\u003e P=aG\n\u003e H(P) -\u003e\n\u003e\n\u003e \u003c- Q=bG\n\u003e\n\u003e P -\u003e\n\u003e\n\u003e Adam\n\u003e\n\u003e On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:\n\u003e \u003e If both parties insist on seeing a hash of the other party's public key\n\u003e \u003e before they'll show their own public key, they can be sure that the\n\u003e \u003e public key is not chosen based on the public key they themselves\n\u003e \u003e presented.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Subversion Kills Productivity. Get off Subversion \u0026 Make the Move to\n\u003e Perforce.\n\u003e With Perforce, you get hassle-free workflows. Merge that actually works.\n\u003e Faster operations. Version large binaries. Built-in WAN optimization and\n\u003e the\n\u003e freedom to use Git, Perforce or both. Make the move to Perforce.\n\u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=122218951\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/7bff5314/attachment.html\u003e",
"sig": "c6cf7fd152d4b11e8c056b7371d68ac903de32991005f4a79b03ba6311a5298fe1367dc6c01ec3e3586a945f1158b7ebd75b6d2b6d072cf36dde591122d51259"
}