On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
Let's say the payee's reusable address is 'version prefix Q1 Q2
...', where prefix is 2 bytes. Without any length indicator. What's the
payer going to put on the blockchain? How would they know what the 'rest
of the space'
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
Ignoring prefixes the cost for each reusable address is only a small
percentage of the full node cost (rational: each transaction has one
or more ECDSA signatures, and the derivation is no more expensive), so
I would only
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell gmaxw...@gmail.com
wrote:
I'd point out that regardless of how long the desired prefix is, the
encoded prefix should probably always be constant length in all
reusable addresses.
I might be misunderstanding, but I think prefix length must
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote:
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman jer...@taplink.co wrote:
Choosing how many bits to put in the prefix may be difficult, particularly
if transaction load changes dramatically over time. 0 or 1 bits may be
just
Like any other mechanism that puts extra data in the blockchain, the
sender pays the fees.
This mechanism is to improve privacy for static addresses (donation
links on websites and so on). I personally don't think it will be used
nearly as much as BIP0032 or the payment protocol (both of which
But I think it's great people can choose how to trade privacy for
computation/bandwidth however they want, and services can compete to
offer monitoring for 0+ bit prefixes.
Its not a decision with user localised effect. If most users use it with
parameters giving high elimination
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back a...@cypherspace.org wrote:
I was meaning to comment on the SPV privacy properties.
For full-node use these unlinkable static addresses have quite nice
properties. It also nicely solves the problem of having to educate users
and wallet authors to
7 matches
Mail list logo