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:
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com 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
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman jer...@taplink.co 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
-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 close
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 m...@plan99.net:
I must say, this shed
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 m...@plan99.net 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
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
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 coloured
Well, at least we don't have to worry about cache invalidation.
Ben
On Fri, Jan 17, 2014 at 6:46 AM, Peter Todd p...@petertodd.org 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.
-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
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com 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
On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe g.r...@froot.co.uk 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
On 16 January 2014 00:05, Jeremy Spilman jer...@taplink.co 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
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 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 which could
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 a
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 what it's
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 p...@petertodd.org
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@gmail.com 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
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 jgar...@bitpay.com wrote:
static address seems like a reasonable attempt at describing intended
use/direction.
On Wed, Jan 15, 2014
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 r...@gnomon.org.uk wrote:
On Wed, Jan 15, 2014 at 03:44:17PM -0500, Jeff Garzik wrote:
static address seems
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.)
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
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman jer...@taplink.co wrote:
Might I propose reusable address.
I like this too.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are
-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
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 only
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 e...@ericmartindale.com wrote:
One variation of this, recycled address, might avert misconceptions that
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
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
detection
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
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@petertodd.org 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
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), so I
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, 14 Jan 2014 13:51:06 -0800, Adam Back a...@cypherspace.org 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
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:
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
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
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 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 ..
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@gmail.com 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
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 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 possible
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 currently
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 enough. I
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 give a
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
On Sun, Jan 12, 2014 at 5:33 AM, Jeremy Spilman jer...@taplink.co 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):
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote:
On 10 January 2014 10:20, Peter Todd p...@petertodd.org 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
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
* Abstract
A Stealth Address is a new type of Bitcoin address and related
scriptPubKey/transaction generation scheme that allowers payees to
publish a single, fixed, address that payors can send funds efficiently,
privately, reliably and non-interactively. Payors do not learn what
other payments
50 matches
Mail list logo
