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-bitcoin-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 which 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 were 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 enable 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=qLci5DoZqHU&feature=youtu.be&t=2m38s ) 1)b.4 0.00005 BTC to a future US gov't-run Social Security address 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 <m...@plan99.net> To: Jeremy Spilman <jer...@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 work 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 <jer...@taplink.co> wrote: > > 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>=2) 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 important > to be able to scan for transactions with a key which can't actually spend > the funds. > > The first approach is just one-pass ECDH. I think you're saying the second > approach is two rounds of ECDH but re-using the same e/P (usually referred > 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 = e * Q [first shared secret] > 3) S2 = e * Q2 [second shared secret, reusing > 'e'] > 4) Q' = Q + H(S) [pay-to stealth address] > 5) Q2' = Q2 + H(S2) [stealth 'marker'] > > Watch: 1) Look for TxOut with OP_RETURN <P> > 2) Q2' = 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 to > 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_RETURN > <P> <Q2'> would be 66 bytes. > > But then Mallory could generate transactions with the right Q2' but with > 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 going > to want to check it against your 'd' before fulfilling a large order. Your > 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 (for > example): > > > xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX > > tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba > > Those addresses are 74 bytes: > <Prefix><CompressedPubKey1><CompressedPubKey2><Checksum> > > xSTL Prefix = 0xC0CB9270 > tSTL Prefix = 0xB2E27D50 > NOTE: I do NOT have the corresponding privkeys for these four pubkeys! > > Those just happened to be the first matching prefixes I found for 74 byte > 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 from > 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 given > encrypted d/d2 > > Obviously extending QT directly for #1 would be ideal, I may even be able > to do that since supporting a new address type should be fairly contained. > But if not I'll punt to writing a node.js or python script which connects > to bitcoind via RPC. > > Thanks, > Jeremy > > [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols > http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf > > [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=119420431&iu=/4140/ostg.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=119420431&iu=/4140/ostg.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=119420431&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
