-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm way late to this one, I guess, but adding some thoughts here... it
seems that anything which mitigates the problem of reuse should be to
the maximum extent possible, the user's option... if a person wants to
have an address that lasts forever they
:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
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 u
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
o:bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
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 exampl
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
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 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
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
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 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 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/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 Wed, Mar 25, 2015 at 6:44 PM, Tom Harding wrote:
> Is this assuming payment protocol? A major benefit of address
> expiration, if it works, would be that it works without requiring
> payment protocol.
Not at all.
> Are you suggesting there is no implementation of address expiration that
> wo
On 3/25/2015 9:34 AM, Gregory Maxwell wrote:
>
>> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
> Assuming the sender is not an uncooperative idiot, you can simply
> include expiration information and the sender can refuse to send after
> that time.
Is this assuming payment protocol? A majo
On Wed, Mar 25, 2015 at 1:57 AM, Tom Harding wrote:
> The idea of limited-lifetime addresses was discussed on 2014-07-15 in
>
> http://thread.gmane.org/gmane.comp.bitcoin.devel/5837
>
> It appears that a limited-lifetime address, such as the fanciful
>
> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36
On Tuesday, 24 March 2015, at 6:57 pm, Tom Harding wrote:
> It appears that a limited-lifetime address, such as the fanciful
>
> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
>
> where 349366 is the last valid block for a transaction paying this
> address, could be made reuse-proof with bo
The idea of limited-lifetime addresses was discussed on 2014-07-15 in
http://thread.gmane.org/gmane.comp.bitcoin.devel/5837
It appears that a limited-lifetime address, such as the fanciful
address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366
where 349366 is the last valid block for a transaction
17 matches
Mail list logo
