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; 
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
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Bitcoin strengthening, giving,
 more - Re:  Stealth Addresses
Precedence: list

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