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