rich1.0npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zkhttps://nostr.ae/npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zknjumphttps://nostr.ae📅 Original date posted:2014-01-14 📝 Original message:Hello Peter et. al. As I read more into this stealth discussion I am curious to know what you think of the background microdonation concept I posted recently. It is shown in full here http://sourceforge.net/mailarchive/message.php?msg_id=31837430 Given the lengthy nature of the concept as presented I would be happy to distill it further, but I am interested in your thoughts as to the idea generally and how to further present it. -Odinn > On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote: >> It's a given this will be implemented for Payment Protocol. The question >> is whether it's also usable outside of PP. > > I think what stealth addresses is showing is that the concept of an > address being "instructions on how to generate a txout/tx that results > in me getting Bitcoins" is actually quite valuable; it and > BIP32-derivation addresses with chaincodes are pretty clear cases where > just replacing address with scriptPubKey isn't sufficient. > >> I was kind of imagining that we could encourage people to replace all >> their static address text that live on Github pages, and README.me, and >> forum signatures, etc. with new 'href=bitcoin:xSTL...' URIs. Convention >> could be to require only transporting xSTL addresses within a URI, even >> going so far as to not support them copy/pasted. 101 characters is not >> much longer (and sometimes shorter) than PaymentRequest URIs end up >> being. > > Yeah, I don't see anything wrong with stealth addresses whatever length > they wind up being. It's a good intermediate step, and without them > people will just pass around unsigned payment requests and other stuff. > >> I think there are ways to make stealth addresses easy enough to use that >> people actually prefer using them for P2P payments which do not involve >> a >> full-stack merchant. In that case, if it was a PaymentRequest it would >> almost certainly not be signed, and would be more easily shared over >> email >> or SMS as a URI than as a file attachment or, even worse, putting the >> unsigned PR file up on a third-party server which probably won't do a >> good >> job securing it. > > At the DarkWallet hackathon we had discussed how to integrate stealth > addresses into OpenPGP keys as a new user id type for instance, and > similarly into x.509 certs. > > The big advantage here is the identity of *who* you are paying is > important, not just "I got this signed payment request". Basically the > concept becomes "identity signed payment address" and the signature > binding the identity to the address is a one time and offline thing; an > issue with the payment protocol as it stands is that it encourages > signing keys to be kept online to issue payment requests. If you have a > scheme where the private keys that bound the identity to the address can > be kept offline you're much better off, because the attacker can only > create a fake payment request, they can't divert the funds to > themselves. > > So with that in mind, I strongly suggest sticking with defining a > reasonable stealth address spec. But when you do, keep in mind that you > may want to upgrade it in the future, preferably in a backwards > compatible way. Also, it shouldn't be limited to exactly 2-of-2 > CHECKMULTISIG, there's no reason why n and m can't be picked as needed. > Sure, it means the addresses are not fixed length, but for something > that is mostly an internal detail and only occasionally visible to > advanced users, I see no issues there. > > Along those lines: what would a BIP32 chain code address look like? What > happens when you want to use that with a multisig-protected wallet? > >> * PP Implementation Overview * >> >> The basic PaymentRequest>PaymentDetails is expecting 'output' containing >> one or more TxOuts with script and amount. I believe the general >> approach >> is to put a fallback address into 'output' for backward compatibility, >> and >> put Q and Q2 into an extension field. >> >> So we add a new optional field to PaymentDetails which contains the one >> or >> two PubKeys. Not sure if we want different protobuf tags, or if the >> difference in length of the value makes it obvious enough which approach >> is being used; >> >> optional bytes stealthOnePubKey = 1000 >> optional bytes stealthTwoPubKey = 1001 > > I think you're missing the bigger picture here, not least of which is > that backwards compatibility is a bit of a misnomer for an unreleased > standard. :) > > Why put this into the PaymentDetails? That a stealth address is to be > used for the payment is a property of the outputs being requested, not > the payment itself. We're better off if that goes into the Output > message, and further more it suggests that the Output message shouldn't > contain raw scriptPubKey's but rather addresses. After all, IsStandard() > means we have to inspect the scriptPubKey to see if we can even pay to > what the sender is requesting. > > Once you establish that it's addresses that Outputs specify, then it's > easy enough to make a stealth address type, or a BIP32-chain-code > address type, or whatever else comes up in the future. > > >> Also, ideally I think I would want multiple different stealth payments >> within a single wallet to the same merchant / pubkeys to be identifiable >> as such. > > Agreed. > > -- > 'peter'[:-1]@petertodd.org > 00000000bda8ab55740699711a11572c4eec9dc9f714e4896559aac310a115ff > ------------------------------------------------------------------------------ > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >