summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOdinn Cyberguerrilla <odinn.cyberguerrilla@riseup.net>2014-01-12 13:48:32 -0800
committerbitcoindev <bitcoindev@gnusha.org>2014-01-12 21:48:42 +0000
commitc1a47e03e39a4ce6141de12df02e34bd80d9d057 (patch)
treeb2a460a755a8e000904c99d0a452c0718d001c76
parent97d56661b6f9812ba7a3f2074e637c0bf4b7621d (diff)
downloadpi-bitcoindev-c1a47e03e39a4ce6141de12df02e34bd80d9d057.tar.gz
pi-bitcoindev-c1a47e03e39a4ce6141de12df02e34bd80d9d057.zip
[Bitcoin-development] Bitcoin strengthening, giving, more - Re: Stealth Addresses
-rw-r--r--b1/f90248c1bd30cdc5ea38c09b5f6c301f063611424
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
+
+
+