On 3/25/2015 12:22 PM, Gregory Maxwell wrote:
>
> Verification with duplicate elimination requires O(N) storage (with N
> being the length of the history), since you need to track all the
> duplicates to reject.
>
I addressed that by limiting the duplicate check to an X-block segment.
X is hard-
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding wrote:
> I addressed that by limiting the duplicate check to an X-block segment. X
> is hard-coded in this simple scheme (X=144 => "1-day addresses"). You
> could picture a selectable expiration duration too.
If its to be heuristic in any case why n
On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> Which is why a simpler, safer, client enforced behavior is probably
> preferable. Someone who wants to go hack their client to make a
> payment that isn't according to the payee will have to live with the
> results, esp. as we can't prevent that in a s
On Thu, Mar 26, 2015 at 02:26:59PM -0700, Tom Harding wrote:
> On 3/26/2015 1:42 PM, Gregory Maxwell wrote:
> > Which is why a simpler, safer, client enforced behavior is probably
> > preferable. Someone who wants to go hack their client to make a
> > payment that isn't according to the payee will
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding wrote:
> I should have been clearer that the motivation for address expiration is to
> reduce the rate of increase of the massive pile of bitcoin addresses out
> there which have to be monitored forever for future payments. It could make
> a significan
> If I understand correctly, transforming raw blocks to keyed blocks
> takes 512x longer than transforming keyed blocks back to raw. The key
> is public, like the IP, or some other value which perhaps changes less
> frequently.
>
Yes. I was thinking that the IP could be part of a first layer of
en
On 3/26/2015 2:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding wrote:
>> I should have been clearer that the motivation for address expiration is to
>> reduce the rate of increase of the massive pile of bitcoin addresses out
>> there which have to be monitored forever
This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations whic
On Thu, Mar 26, 2015 at 10:28 PM, s7r wrote:
> This should not be enforced by default.
No one suggested _anything_ like that. Please save the concern for
someplace its actually applicable.
> I know it's not recommended to use the same pubkey more than once, but
> the protocol was not designed th
Maybe I'm overlooking something, but I've been watching this thread with
increasing skepticism at the complexity of the offered solution. I don't
understand why it needs to be so complex. I'd like to offer an alternative for
your consideration...
Challenge:
"Send me: SHA256(SHA256(concatenation
Yes I agree, also there is talks about a government body I know of warming to
bitcoin by issuing addresses for use by a business and then all transactions
can be tracked for that business entity. This is one proposal I saw put forward
by a country specific bitcoin group to their government and s
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle wrote:
> Yes I agree, also there is talks about a government body I know of warming
> to bitcoin by issuing addresses for use by a business and then all
> transactions can be tracked for that business entity. This is one proposal I
> saw put forward by
Indeed, and with things like BIP32 it would be pointless to use one address,
and I agree it is silly to reuse addresses, some for the privacy aspect, some
for the revealing the pubkey on a spend aspect. But just because it is silly,
doesn't mean it's necessarily required for devs to disallow it.
13 matches
Mail list logo
