From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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: Date: Sun, 12 Jan 2014 13:48:32 -0800 From: "Odinn Cyberguerrilla" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: Jeremy Spilman Cc: "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 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

> 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 >

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: > > > 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