Odinn Cyberguerrilla [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-14 📝 Original message:Hello Peter et. al. As I ...

📅 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
>