diff options
author | Odinn Cyberguerrilla <odinn.cyberguerrilla@riseup.net> | 2014-01-12 13:48:32 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-12 21:48:42 +0000 |
commit | c1a47e03e39a4ce6141de12df02e34bd80d9d057 (patch) | |
tree | b2a460a755a8e000904c99d0a452c0718d001c76 | |
parent | 97d56661b6f9812ba7a3f2074e637c0bf4b7621d (diff) | |
download | pi-bitcoindev-c1a47e03e39a4ce6141de12df02e34bd80d9d057.tar.gz pi-bitcoindev-c1a47e03e39a4ce6141de12df02e34bd80d9d057.zip |
[Bitcoin-development] Bitcoin strengthening, giving, more - Re: Stealth Addresses
-rw-r--r-- | b1/f90248c1bd30cdc5ea38c09b5f6c301f063611 | 424 |
1 files changed, 424 insertions, 0 deletions
diff --git a/b1/f90248c1bd30cdc5ea38c09b5f6c301f063611 b/b1/f90248c1bd30cdc5ea38c09b5f6c301f063611 new file mode 100644 index 000000000..6219b17c2 --- /dev/null +++ b/b1/f90248c1bd30cdc5ea38c09b5f6c301f063611 @@ -0,0 +1,424 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <odinn.cyberguerrilla@riseup.net>) id 1W2Ste-000382-EF + for bitcoin-development@lists.sourceforge.net; + Sun, 12 Jan 2014 21:48:42 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net + designates 198.252.153.129 as permitted sender) + client-ip=198.252.153.129; + envelope-from=odinn.cyberguerrilla@riseup.net; + helo=mx1.riseup.net; +Received: from mx1.riseup.net ([198.252.153.129]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1W2Sta-0002m4-V2 + for bitcoin-development@lists.sourceforge.net; + Sun, 12 Jan 2014 21:48:42 +0000 +Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (Client CN "*.riseup.net", + Issuer "Gandi Standard SSL CA" (not verified)) + by mx1.riseup.net (Postfix) with ESMTPS id BAF7B423EF; + Sun, 12 Jan 2014 13:48:32 -0800 (PST) +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net) + with ESMTPSA id 81BF2154 +Received: from localhost (127.0.0.1) + (SquirrelMail authenticated user odinn.cyberguerrilla) + by fulvetta.riseup.net with HTTP; Sun, 12 Jan 2014 13:48:32 -0800 +Message-ID: <e0ad383c6ef578daae63ede1a77c5065.squirrel@fulvetta.riseup.net> +Date: Sun, 12 Jan 2014 13:48:32 -0800 +From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net> +To: mike@plan99.net +User-Agent: SquirrelMail/1.4.21 +MIME-Version: 1.0 +Content-Type: text/plain;charset=utf-8 +X-Priority: 3 (Normal) +Importance: Normal +X-Virus-Scanned: clamav-milter 0.97.8 at mx1 +X-Virus-Status: Clean +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [198.252.153.129 listed in list.dnswl.org] + -0.0 SPF_HELO_PASS SPF: HELO matches SPF record + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain + 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay + lines +X-Headers-End: 1W2Sta-0002m4-V2 +Cc: bitcoin-development@lists.sourceforge.net +Subject: [Bitcoin-development] Bitcoin strengthening, giving, + more - Re: Stealth Addresses +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sun, 12 Jan 2014 21:48:42 -0000 + +Hello, + +My apologies, to start with, as I am temporarily unable to reply directly +to the thread. I am remembering this conversation due to a few things: + +1) the discussion re. extending the payment protocol with new fields +2) discussions about "long addresses" +3) bitcoin strengthening / decentralization / cex.io,ghash.io growth etc. +4) microdonation / giving / microtransaction development, e.g. +coinbase-bitmonet Android SDK, +http://blog.coinbase.com/post/72785739620/android-sdk-released-accept-bit= +coin-payment-in-your +5) multisignature via browser, e.g. https://coinb.in/multisig/ + +Different thoughts are running through my head here, so I will make a +sincere effort to coagulate them into a couple of meaningful and coherent +questions, and perhaps as time goes on, an issue or BIP. However, I will +precede this with a "scenario" and with some "possibilities" (all of whic= +h +are hypothetical - I think) before presenting the "questions" below. + + | + | + V + +"Scenario(s)" + +Suppose that there were to exist a method of extending the payment +protocol such that either "very long addresses" or multiple addresses wer= +e +presented by default from within the bitcoin client. In the scenario +being imagined here, the standard option would exist to enter a payment +address directly. However, coupled with this would be an option to enabl= +e +microdonations (or put another way, multiple transactions associated with +each instance of use of the protocol to facilitate a purchase) as a +default (as background activity automatically corresponding to any given +transaction). Whether or not this process is engaged in would be entirely +voluntary, in other words, users' choice. + +The addresses to which this giving or microdonation would occur would be +stipulated by the user but also would be limited to the ability of the +network to support this microdonation process. + +So, for example: + +1) Let us say that you are to buy a piece of gum and the price of that +piece of gum is 0.00008 BTC. + 1)a. The user has the ability to support additional (individuals, +organizations, causes, etc) for each transaction (instance of use of +the protocol to facilitate a purchase). + 1)b. The user has set as a default to be "microdonated" each time a +transaction occurs, the following: + 1)b.1 0.0003 BTC to Sean's Outpost + 1)b.2 0.0004 BTC to a cousin who has a medical debt + 1)b.3 0.00006 BTC to a multisignature account which is intended +to "give youth a future and old age a security" +( Re: https://www.youtube.com/watch?v=3DqLci5DoZqHU&feature=3Dyoutu.be&t=3D= +2m38s ) + 1)b.4 0.00005 BTC to a future US gov't-run Social Security addr= +ess + 1)b.5 0.0002 BTC to an anarchist collective's donation address + 1)b.6 0.0002 BTC to a personal investment or retirement account + 1)c. The user then purchases a compound bow for 0.17 BTC. The +purchase occurs the day after the gum purchase was initiated. The +user has left the default microdonation settings in place, so Sean's +Outpost, the cousin, the multisignature account, the US gov't run +Social Security address, the anarchist collective, and the personal +investment / retirement account all receive something (automatically) +again as per the user's settings. + +"Possibilities" + +2) Some Possibilities (depending on implementation): + 2)a. The transaction completes for the purchase of gum but the +microtransactions are not allowed to complete until the compound bow +purchase is complete due to that the gum price is lower than the +collective microdonations which are set by the user as default. + 2)b. The transaction for the purchase of gum is not completed due to +the user realizing that the fee will be larger than the price of gum, +but the microdonations are completed (the user has opted to allow them +to occur anyway) and transaction(s) confirmed. Subsequently, the +compound bow purchase occurs and the microdonations are given again. + 2)c. The transaction for the purchase of gum is completed and the +microdonations are completed, everything is confirmed, the next day +the same thing happens with the compound bow purchase, more +microdonations arrive. + 2)d. The microdonations are interpreted by the system as part of a +very long address created for the transaction. Due to the tiny price +of the gum the microtransactions are held until another larger +purchase is completed. The microtransactions occur "times 2" at the +time of the compound bow purchase, since they could not be completed +during the gum purchase, they are completed / confirmed at the time of +the compound bow purchase. The user is alerted that the ordinary +microdonations will be multiplied by two for the transaction and is +offered an option to either run the default microdonation or the +micronation "times two." The user confirms the "times two" option and +the microdonations are completed. + 2)e. The microdonations are each handled as seperate microdonations = +- +each has a distinct transaction + 2)f. A fee is collected for some microdonations but not for others +depending upon their size of the microdonation and other factors + 2)g. Microtransactions are conducted over mobile with zero fees, the +fees are applied only to the item purchased, unless the value of the +microdonations is at a certain threshold value where fees will apply. + 2)h. The user has the microdonations set by default in the user's +bitcoin client, but also uses 'donation services' (that operate +through a website) apart from the user's client, for example, flattr, +which can provide small bitcoin donations to persons or entities that +the user selects without having to also commit to the "microdonation +default" (Sean's outpost, the cousin, etc) when that 'donation +service' is used. In other words, the user can commit to a +transaction for the purpose of donation to some person or entity, with +the option of not having the default microdonations occur (user's +option) for that transaction. + +(I could go on with all sorts of scenarios here but I think those will +suffice to describe _some_ possibilities) + +"Possibilities - continued" + +3) The system uses the microdonation process to limit possibility of a 50= +% ++ 1 attack. At the user's option, microdonations are routed to different +pools when certain thresholds are reached, to decentralize mining. This +would occur either as distinct microtransaction (materially, no different +than the microdonation to Sean's Outpost that the user has set as a +default for every purchase) or would occur as part of a "very long +address." + +"Questions" + +1) What are (some) obstacles to this sort of suggestion to decentralize +the giving process? +2) Would donations be identified as donations or just as another +transaction in the Bitcoin network? Maybe there is another question +flowing from this question: + 2)a. Where the user wants the ability to decide to make a donation +'anonymously' or not, could this occur as a default setting for either +one (or all) of the microdonations that the user has set? +3) What would be the simplest possible form of a prototype implementation= +? + +References / things being reflected upon in background / note(s): + +a) 'ABIS' - protocol concept to enable decentralization and expansion of = +a +giving economy and a new social good (ABISprotocol) +https://github.com/ABISprotocol/ABIS +b) 'BitHub' - An experiment in funding privacy OSS (WhisperSystems / +moxie0) https://github.com/WhisperSystems/BitHub +c) 'coinbase-android-sdk' - Coinbase Android SDK developed in +collaboration with Bitmonet Open-source project (coinbase / bitmonet) +https://github.com/coinbase/coinbase-android-sdk +d) 'bitcoin' (bitcoin) https://github.com/bitcoin/bitcoin + +Finally: My apologies in advance for any obvious omissions, +inconsistencies, poorly constructed statements, or whatever malformed +thing you perceive that you have just endured reading. (If you liked it, +though, you are most welcome. I'm happy to contribute.) This is an +initial stab by me in this list to generate discussion about these issues= +. + + -----this message is in reply to the below------- + +From: Mike Hearn <mike@plan99.net> +To: Jeremy Spilman <jeremy@taplink.co> +Cc: "bitcoin-development@lists.sourceforge.net" +<bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Stealth Addresses +Date: Sun, 12 Jan 2014 13:51:54 +0100 + +You can always just extend the payment protocol with the new fields as +well, vs making very long addresses. If this technique can be made to wor= +k +well, it would have applicability in both fixed textual address context, +and for a fixed/upload-once payment protocol file. That has the advantage +of backwards compatibility as well - the new addresses would not be +clickable or acceptable by old wallets, but with the payment protocol you +can always craft a bitcoin URI that contains a regular current style +address, and a link to a fixed payment protocol file (uploaded to a +pastebin type site), and modern wallets would ignore the address and use +the ECDH based system instead. + + + +On Sun, Jan 12, 2014 at 11:33 AM, Jeremy Spilman <jeremy@taplink.co> wrot= +e: + +> > Oh, sorry, I forgot to mention it in my first write-up but you can +> > easily make stealth addresses include a second pubkey for the purpose= + of +> > the communication that either isn't used in the scriptPubKey at all, = +or +> > is part of a n-of-m multisig. (n>=3D2) Interestingly that also means = +you +> > can give a third-party that key and out-source the effort of scanning +> > the blockchain for you. +> +> Great point. Even if it's not a 3rd party, I think it's really importan= +t +> to be able to scan for transactions with a key which can't actually spe= +nd +> the funds. +> +> The first approach is just one-pass ECDH. I think you're saying the sec= +ond +> approach is two rounds of ECDH but re-using the same e/P (usually refer= +red +> to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral = +key +> for signing operations. +> +> Payee: Publish Q, Q2 [d, d2 are privkeys, Q, Q2 = +are +> pubkeys] +> Payer: 1) Generate ephemeral key: e / P [e is privkey, P is pubkey] +> 2) S =3D e * Q [first shared secret] +> 3) S2 =3D e * Q2 [second shared secret, re= +using +> 'e'] +> 4) Q' =3D Q + H(S) [pay-to stealth address] +> 5) Q2' =3D Q2 + H(S2) [stealth 'marker'] +> +> Watch: 1) Look for TxOut with OP_RETURN <P> +> 2) Q2' =3D Q2 + H(d2 * P) +> 3) Check for Q2' elsewhere in the Tx +> +> S/MIME for example, allows reuse of the ephemeral keypair. When reusing= + an +> ephemeral keypair where A reuses (x, X) to encrypt different messages t= +o +> more than one user, A should verify the static public keys to prevent +> small-subgroup attacks.[1][2] +> +> Let's say you pay-to Q' and then Q2' value has to be somewhere else in = +the +> transaction. You could put it next to the shared P in OP_RETURN. OP_RET= +URN +> <P> <Q2'> would be 66 bytes. +> +> But then Mallory could generate transactions with the right Q2' but wit= +h +> his own pubkey in Step 2 instead of Q. So your scanner would detect a +> payment, but you wouldn't be able to spend it, and Mallory could. +> +> That's a good argument for putting Q2' in a 2-of-2 multisig so that +> pulling this trick would at least make the transaction unspendable for +> both parties, which may be good enough deterrent, but you're still goin= +g +> to want to check it against your 'd' before fulfilling a large order. Y= +our +> online watch process could queue the matching transactions, which you +> could move to your offline machine, decrypt your key, and verify the +> transactions are spendable. +> +> Now, you would need to get two pubkeys to the payer, throw in a prefix = +to +> help standardize it, and end up with addresses that could look like (fo= +r +> example): +> +> +> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKx= +QzrfC3pDimfTWMkiUb7x3jX3J26JSX +> +> tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACL= +LFYK8EwVo1jdjxNDFNDWxhnQiAy4ba +> +> Those addresses are 74 bytes: +> <Prefix><CompressedPubKey1><CompressedPubKey2><Checksum> +> +> xSTL Prefix =3D 0xC0CB9270 +> tSTL Prefix =3D 0xB2E27D50 +> NOTE: I do NOT have the corresponding privkeys for these four pubkey= +s! +> +> Those just happened to be the first matching prefixes I found for 74 by= +te +> addresses. I could try to find ones which start with a specific byte if +> that's somehow better, like 0x04 to match BIP32. +> +> Unfortunately, I don't think you can just derive a second public key fr= +om +> the first to keep the address shorter, and still keep the first private +> key secure, even if the second private key is stolen. You only get +> equivalent security as BIP32 public derivation, where you can't lose a +> child private key. +> +> Do we also want xSTL (or whatever user friendly string) prefixes for +> single pubkey (41 byte) stealth addresses? +> +> I'll wait a couple days for feedback, then I'll try to implement the +> following prototypes: +> +> 1) Pay to STL addresses +> 2) Watcher process to detect and queue STL payments for a given d2/Q2 +> 3) Offline verifier to take output from Watcher and verify spendable gi= +ven +> encrypted d/d2 +> +> Obviously extending QT directly for #1 would be ideal, I may even be ab= +le +> to do that since supporting a new address type should be fairly contain= +ed. +> But if not I'll punt to writing a node.js or python script which connec= +ts +> to bitcoind via RPC. +> +> Thanks, +> Jeremy +> +> [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protoco= +ls +> http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pd= +f +> +> [2] - Validation of Elliptic Curve Public Keys +> http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf +> +> +> +> -----------------------------------------------------------------------= +------- +> CenturyLink Cloud: The Leader in Enterprise Cloud Services. +> Learn Why More Businesses Are Choosing CenturyLink Cloud For +> Critical Workloads, Development Environments & Everything In Between. +> Get a Quote or Start a Free Trial Today. +> +> http://pubads.g.doubleclick.net/gampad/clk?id=3D119420431&iu=3D/4140/os= +tg.clktrk +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +-------------------------------------------------------------------------= +----- +CenturyLink Cloud: The Leader in Enterprise Cloud Services. +Learn Why More Businesses Are Choosing CenturyLink Cloud For +Critical Workloads, Development Environments & Everything In Between. +Get a Quote or Start a Free Trial Today. +http://pubads.g.doubleclick.net/gampad/clk?id=3D119420431&iu=3D/4140/ostg= +.clktrk + +_______________________________________________ +Bitcoin-development mailing list +Bitcoin-development@lists.sourceforge.net +https://lists.sourceforge.net/lists/listinfo/bitcoin-development + + + |