I think stealth addresses combined with zk-snarks would obviate the need
for CoinJoin. zk-snarks could be used to hide the coin's value and
stealth addresses could be used to hide the recipient for payments and
even mined coins. More info on zero-knowledge snarks:
http://cs.tau.ac.il/~tromer/
On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
>
>
> > On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote:
> >> Isn't there a much faster asymmetric scheme that we can use? I've heard
> >> people talk about ed25519, though I'm not sure it can be used for
> >> encryption.
> >
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery
> only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20
> byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bit
> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote:
>> Isn't there a much faster asymmetric scheme that we can use? I've heard
>> people talk about ed25519, though I'm not sure it can be used for encryption.
>
> Doing ECDH with our curve is within a factor of ~2 of the fastest
> encryption
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote:
> Isn't there a much faster asymmetric scheme that we can use? I've heard
> people talk about ed25519, though I'm not sure it can be used for encryption.
Doing ECDH with our curve is within a factor of ~2 of the fastest
encryption available at
*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*
Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead? Then we don't need any ephemeral keys. We use the
much simpler scheme like I mentioned before (just root keys and
mul
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
One of the possible words that haven't been proposed is 'personal' where
bitcoin addressed are commonly incorrectly called public address.
Maybe 'personal account' or even 'personal address' would imply that the
balance on such an account shouldn't
Well, at least we don't have to worry about cache invalidation.
Ben
On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd wrote:
> On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> > I must say, this shed is mighty fine looking. It'd be a great place to
> > store our bikes. But, what colour
On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
I think we should paint it this colour:
They had uncovered what seemed to be the side of a large coloure
On naming, please allow consideration of "Confidential address".
Less conflation with "private key", connotes confidence, and as the address is
known to the transacting parties, it is a precisely accurate name.
One of the use cases for these will be in multinational corporate internal
internati
That could also work. Still, didn't we want to ditch the word address?
Could be a privacy key...
On 17 Jan 2014 09:15, "Mike Hearn" wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
>
> How about we split the di
So far I've only liked the original name "Stealth address" and the
suggestion "routing address".
Should we put this up for some kind of informal vote with comments allowed?
Like a Google docs form?
- Sent from my phone
Den 17 jan 2014 10:18 skrev "Mike Hearn" :
> I must say, this shed is mighty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
>
> How about we split the difference and go with "privacy address"?
> As
Too c
I must say, this shed is mighty fine looking. It'd be a great place to
store our bikes. But, what colour should we paint it?
How about we split the difference and go with "privacy address"? As Peter
notes, that's what people actually like and want. The problem with stealth
is it's got strong conno
Peter I agree with you about "reusable addresses", but aren't we also
trying to get away from the word "address" entirely? How about calling it
a "payment key" or "reusable payment key" instead? using "stealth" is just
asking for bad press imo.
On 16 January 2014 21:28, Peter Todd wrote:
> On
I hear you, and I really don't care that much what it's called, as much as,
does it work and how!
> I might even try to enter in a "reusable" address in blockchain.info, which
> won't work, and I'll just figure
> "must be some new unsupported thing" and move on with my life.
>
Regardless of wh
On 01/16/2014 01:28 PM, Peter Todd wrote:
> I'm very against the name "reusable addresses" and strongly belive we
> should stick with the name stealth addresses.
I agree wholeheartedly against using "reusable address". I personally
am fine with "stealth address", but can see where there might be
On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more
> so encourages wallets to present options as 'one time use' vs
> 'reusable'.
>
> It definitely packs a marketing punch whi
I think we have a winner in "reusable address". Yes an existing address can
be reused and will superficially appear to work, it just won't work well.
Calling them reusable addresses helps reinforce the idea in peoples mind
that the other kind shouldn't be reused.
On Thu, Jan 16, 2014 at 11:14 AM,
On 16 January 2014 00:05, Jeremy Spilman wrote:
> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
The problem is all addresses are reusable and to an average
On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe wrote:
> I like "reusable address".
>
Simple and clear, I like it too.
I see the term is routing is used in finance in the USA, but as a Dutch
person I associate "routing address" with network routing, not with
banking. It's non-trivial to translate to
I like "reusable address".
It is very clear what the intended purpose is and gives a subtle hint that
other types of address should not be re-used.
On 16 January 2014 00:44, Eric Martindale wrote:
> One variation of this, "recycled address", might avert misconceptions that
> the "re-use" is e
One variation of this, "recycled address", might avert misconceptions that
the "re-use" is exclusive to one's own identity.
Eric Martindale, relentless maker.
http://www.ericmartindale.com
+1 (919) 374-2020 | *BitMessage: *BM-2cWCmYBpV64FRSJpHHKWi1Cfc9W52jydwe
*Note:* Beginning December 11th, 201
Yes. Good idea(s).
> Might I propose "reusable address".
>
> I think that describes it best to any non-programmer, and even more so
> encourages wallets to present options as 'one time use' vs 'reusable'.
>
> It definitely packs a marketing punch which could help drive adoption. The
> feature is o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".
Say it like it is. This is the only suggestion so far that I really like.
No amount of finger wagging got people to stop using the block chain
for data storage, but n
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".
I like this too.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyL
Might I propose "reusable address".I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'.It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted.
On Wed, Jan 15, 2014 at 11:17:33PM +, I wrote:
> How about just calling them 'type S addresses'?
(Assuming they're encoded in such as way that they actually start with 's'.
Otherwise whatever prefix is actually used, obviously.)
How about just calling them 'type S addresses'?
Not sure any other name will in reality convey much more meaning than
that.
On Wed, Jan 15, 2014 at 06:07:28PM -0500, Jeff Garzik wrote:
> "Routing address" is pretty good too. Unsure whether the synergy and
> familiarity with bank routing numbers
"Routing address" is pretty good too. Unsure whether the synergy and
familiarity with bank routing numbers improves the situation, or
not...
On Wed, Jan 15, 2014 at 6:04 PM, Roy Badami wrote:
> On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
>> "static address" seems like a reasona
On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
...as opposed to an address configured by DHCP?
More seriously, I don't think a typical user will understand anything from
the phrase "static add
Do any people who aren't computer programmers or physicists ever use the
term "static"?
I liked routing address.
On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik wrote:
> "static address" seems like a reasonable attempt at describing intended
> use/direction.
>
>
>
> On Wed, Jan 15, 2014 at 3:38 P
"static address" seems like a reasonable attempt at describing intended
use/direction.
On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell wrote:
> On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport
> wrote:
> > But may I suggest we consider changing the name "stealth address" to
> > something more
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport wrote:
> But may I suggest we consider changing the name "stealth address" to
> something more neutral?
ACK. Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.
"Private address" would be fine if not for confusion w
Love what's happening here, and how quickly things are moving, from initial
concept, to first implementation, to first transaction.
But may I suggest we consider changing the name "stealth address" to
something more neutral?
Already, many people on Reddit and elsewhere are misinterpreting the
pur
Sorry this is possibly OT, but someone posted this thread to r/bitcoin and
it's gone straight to position 1. People are really enthusiastic about this
feature.
Drak
--
CenturyLink Cloud: The Leader in Enterprise Cloud Serv
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
>
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back wrote:
> I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
> typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
> and therefore that Util.SingleSHA256() multiplies by G internally?
>
> Adam
>
Thanks for re
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
-
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
> Maybe you are saying:
>
> byte[] S = EC.DH(e, Q2);
> byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
> byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
>
> But the payment would have (q2New - q1New) == (Q2 - Q1), s
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>> I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping
>> one of the pubKeys in the OP-RETURN, to prevent a malicious sender from
>> triggering false posi
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 presen
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>
> > Uh while I'm responding again, what I'd discussed with Peter Todd in
> > IRC used two EC points in the stealth address. One for the payment and
> > one for the ECDH. The reason to use two is that it makes delegating
> > detecti
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 genera
On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd wrote:
>
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind the OP_RETURN output at 2^l
> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH. The reason to use two is that it makes delegating
> detection possible and so you don't have to have you spending keys
> online to ev
On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
> > I don't know if stealth addresses are the best solution to address
> > this use case, but AFAIK the only current solution to this use case is
> > to store a long-lived Bitcoin address in the addresss book.
> >
> > roy
> >
>
> Fair en
On 01/13/2014 04:02 PM, Roy Badami wrote:
>> It's not public. When I say "please pay me" I also say "use this
>> multiplier".
> Sending a "please pay me" message is really great for business
> transactions.
>
> But I think the use case that Peter Todd mentions is actually *the*
> most important cu
> It's not public. When I say "please pay me" I also say "use this
> multiplier".
Sending a "please pay me" message is really great for business
transactions.
But I think the use case that Peter Todd mentions is actually *the*
most important currently under-addresesd use case:
> With stealth ad
On Mon, Jan 13, 2014 at 12:41 PM, Alan Reiner wrote:
> It's not public. When I say "please pay me" I also say "use this
> multiplier". The multiplier isn't published, and it's not publicly
> discoverable without my wallet (or access to my email).
If you have enough of a communications channel t
On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch. You can put your root key on a business card if you
On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
> Uh while I'm responding again, what I'd discussed with Peter Todd in
> IRC used two EC points in the stealth address. One for the payment and
> one for the ECDH. The reason to use two is that it makes delegating
> detection possibl
On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
> How is this different from the proposal I have made?
>
> You distribute the root public key (but not chaincode!) of a BIP32
> branch. You can put your root key on a business card if you want. Then
> when someone wants to pay you, you
On Mon, Jan 13, 2014 at 04:58:01PM +0100, Mike Hearn wrote:
> Signing a payment request for an individual is easy, anyway, depending on
> the kind of ID you want. If you want to sign with an email address, just go
> here with a browser like Chrome/Safari/IE that uses the system keystore:
>
>ht
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner wrote:
> Then when someone
> wants to pay you, you simply give them the multiplier and root key (they
> already have the root key, but should verify).
[...]
> What
> advantages does "stealth addresses" have over this scheme? You could extend
> it usin
rOn Mon, Jan 13, 2014 at 08:57:33PM +0100, Mike Hearn wrote:
> >
> > On further reflection, I'm not sure I understand this use case of the
> > payment protocol. Since a PaymentRequest currently contains the
> > Outputs that specify the addresses to send to, reusing a
> > PaymentRequest like this w
How is this different from the proposal I have made?
You distribute the root public key (but not chaincode!) of a BIP32
branch. You can put your root key on a business card if you want. Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the ro
>
> On further reflection, I'm not sure I understand this use case of the
> payment protocol. Since a PaymentRequest currently contains the
> Outputs that specify the addresses to send to, reusing a
> PaymentRequest like this without using stealth addresses implies
> address reuse.
Yes indeed ..
> > Likewise, I could attach a payment request to an email and send it to you,
> > and now you can pay me whenever you want forever.
>
> That certainly sounds like a plausible use case. You do still have
> the problem that e-mail is an insecure channel, but it's no worse than
> exchanging Bitcoin
On 13 January 2014 19:40, Roy Badami wrote:
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
My thoughts exactly.
Drak
---
On Mon, Jan 13, 2014 at 01:52:25AM -0800, Gregory Maxwell wrote:
> On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen
> wrote:
> > No, please. Make it easy for non-geeks, extend the payment protocol, or
> > we'll spend the next two years writing code that tries to ignore linebreaks
> > and spaces an
On Mon, Jan 13, 2014 at 2:37 PM, Roy Badami wrote:
> That does require trusting the third party not to later tamper with
> the payment request, though.
You have to trust the billboard owner too. If you're relying on a third
party to relay a payment instruction, that will always be an issue, hen
> I was thinking that people could upload a payment protocol file somewhere
> once (like to their personal web page, or shared via dropbox or google
> drive or some custom new pastebin style service), and then just encode a
> regular bitcoin URI into the qrcode on the billboard.
That does require
>
> However, if you're able to use the payment protocol then you probably
> don't need stealth addresses to prevent reuse.
>
I was thinking that people could upload a payment protocol file somewhere
once (like to their personal web page, or shared via dropbox or google
drive or some custom new pas
On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or
> we'll spend the next two years writing code that tries to ignore linebreaks
> and spaces and changing elements in HTML forms to
However, if you're able to use
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman wrote:
> > I think for displaying the payment in the UI after it's been made via
> PP, we have to fully
> > support sending to a new standard address type anyway.
On Sun, 12 Jan 2014 10:26:18 -0800, Mike Hearn wrote:
> Why? Showing an address is
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman wrote:
> ...
> 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 (for
> example):
>
>
> xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3
On Sun, Jan 12, 2014 at 7:20 PM, Jeremy Spilman wrote:
> I think for displaying the payment in the UI after it's been made via
> PP, we have to fully support sending to a new standard address type anyway.
>
Why? Showing an address is meaningless, especially if the user didn't type
it in or see
You can always just extend the payment protocol with the new fields as well, vs making very long addresses. I should have mentioned that as Task #4. Agree it could be an optional extension and backward compatible. I think for displaying the payment in the UI after it's been made via PP, we have to
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 work
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 bac
> 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>=2) Interestingly that also means you
> can gi
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote:
> On 10 January 2014 10:20, Peter Todd wrote:
>
> > 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
On 10 January 2014 10:20, Peter Todd wrote:
> 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>
On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
> Thanks Peter for the paper!
>
> I'm just going to restate your 'simple explanation' to make sure I
> got it...
>
> The payee publishes a public key of theirs, which will be a
> long-standing identifier, public key = 'Q', correspond
Thanks Peter for the paper!
I'm just going to restate your 'simple explanation' to make sure I got
it...
The payee publishes a public key of theirs, which will be a long-standing
identifier, public key = 'Q', corresponding private key = 'd'.
To pay them, payee generate a keypair, private key
75 matches
Mail list logo
