* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
@ 2015-03-27 4:31 Thy Shizzle
0 siblings, 0 replies; 17+ messages in thread
From: Thy Shizzle @ 2015-03-27 4:31 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
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. I mean if a business doesn't care who can see their bitcoin takings and they are willing to keep shifting the bitcoin and live woth the exposed pubkey let them yea?
http://www.forexminute.com/bitcoin/australian-association-asks-voluntary-bitcoin-register-individuals-companies-51183
________________________________
From: Gregory Maxwell<mailto:gmaxwell@gmail•com>
Sent: 27/03/2015 2:13 PM
To: Thy Shizzle<mailto:thyshizzle@outlook•com>
Cc: s7r@sky-ip.org<mailto:s7r@sky-ip•org>; Tom Harding<mailto:tomh@thinlink•com>; Bitcoin Development<mailto: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 <thyshizzle@outlook•com> 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 a country specific bitcoin group to their government and
> so not allowing address reuse would neuter that :(
I hope you're mistaken, because that would be a serious attack on the
design of bitcoin, which obtains privacy and fungibility, both
essential properties of any money like good, almost exclusively
through avoiding reuse.
[What business would use a money where all their competition can see
their sales and identify their customers, where their customers can
track their margins and suppliers? What individuals would use a system
where their inlaws could criticize their spending? Where their
landlord knows they got a raise, or where thieves know their net
worth?]
Though no one here is currently suggesting blocking reuse as a network
rule, the reasonable and expected response to what you're suggesting
would be to do so.
If some community wishes to choose not to use Bitcoin, great, but they
don't get to simply choose to screw up its utility for all the other
users.
You should advise this "country specific bitcoin group" that they
shouldn't speak for the users of a system which they clearly do not
understand.
[-- Attachment #2: Type: text/html, Size: 3802 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 21:44 ` Gregory Maxwell
2015-03-26 22:23 ` Tom Harding
2015-03-26 22:28 ` s7r
@ 2015-06-13 4:52 ` odinn
2 siblings, 0 replies; 17+ messages in thread
From: odinn @ 2015-06-13 4:52 UTC (permalink / raw)
To: bitcoin-development
-----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 should be able to have it...
if they want to have an address that expires they should be able to
have it.
The reuse problem is, I think, better solved by the presentation of
stealth address proposals, and would be handled by a stealth BIP (BIP
63) which has been recently re-discussed here:
https://bitcointalk.org/index.php?topic=1083961.0
On 03/26/2015 02:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com>
> 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 significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
- --------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVe7cJAAoJEGxwq/inSG8C2uwH/2UfTX+6CEssv5ZhiwwqVNWk
bmlODZulsJK0FIIcz2oVtMvnMR7L8DX/XtFOdiVTk/wOn7vc7X/DZ9UVKSixKCLJ
IJLzBKEzFzMmNhxXv9fPsefuMsMlTkhifykl2BOp0T2gMEr5GweKSqn9XpQuo9mb
LhS5vqNCRw0X3eQ5sIalSfmK3ghP5yaU+orhFjvb3QJ/JN3mxgXyl3xLx9diPVdu
2I1QoxzCyE/tlEnxZGPrCtGe3d93mPhEFGGeiP+7eW8TkJa5AGCg3QWbzniC3Nsv
gjg6rCbLKtj300hH0glbPT96YO+r9l5itox+aArkCtNnR+/HlUb6zubgqebzPuc=
=KZQe
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-27 1:51 Thy Shizzle
@ 2015-03-27 3:13 ` Gregory Maxwell
0 siblings, 0 replies; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-27 3:13 UTC (permalink / raw)
To: Thy Shizzle; +Cc: Bitcoin Development
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle <thyshizzle@outlook•com> 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 a country specific bitcoin group to their government and
> so not allowing address reuse would neuter that :(
I hope you're mistaken, because that would be a serious attack on the
design of bitcoin, which obtains privacy and fungibility, both
essential properties of any money like good, almost exclusively
through avoiding reuse.
[What business would use a money where all their competition can see
their sales and identify their customers, where their customers can
track their margins and suppliers? What individuals would use a system
where their inlaws could criticize their spending? Where their
landlord knows they got a raise, or where thieves know their net
worth?]
Though no one here is currently suggesting blocking reuse as a network
rule, the reasonable and expected response to what you're suggesting
would be to do so.
If some community wishes to choose not to use Bitcoin, great, but they
don't get to simply choose to screw up its utility for all the other
users.
You should advise this "country specific bitcoin group" that they
shouldn't speak for the users of a system which they clearly do not
understand.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
@ 2015-03-27 1:51 Thy Shizzle
2015-03-27 3:13 ` Gregory Maxwell
0 siblings, 1 reply; 17+ messages in thread
From: Thy Shizzle @ 2015-03-27 1:51 UTC (permalink / raw)
To: s7r, Gregory Maxwell, Tom Harding; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]
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 so not allowing address reuse would neuter that :(
________________________________
From: s7r<mailto:s7r@sky-ip•org>
Sent: 27/03/2015 9:29 AM
To: Gregory Maxwell<mailto:gmaxwell@gmail•com>; Tom Harding<mailto:tomh@thinlink•com>
Cc: Bitcoin Development<mailto: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 example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).
I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.
On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com>
> 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 significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
--------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 5302 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 22:28 ` s7r
@ 2015-03-26 23:00 ` Gregory Maxwell
0 siblings, 0 replies; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-26 23:00 UTC (permalink / raw)
To: s7r; +Cc: Bitcoin Development
On Thu, Mar 26, 2015 at 10:28 PM, s7r <s7r@sky-ip•org> 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 this way.
For a point of pedantry, the protocol actually was designed that way
and in the initial versions of the software there was actually no user
exposed mechanism to reuse a scriptPubkey no matter how hard you
tried.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 21:44 ` Gregory Maxwell
2015-03-26 22:23 ` Tom Harding
@ 2015-03-26 22:28 ` s7r
2015-03-26 23:00 ` Gregory Maxwell
2015-06-13 4:52 ` odinn
2 siblings, 1 reply; 17+ messages in thread
From: s7r @ 2015-03-26 22:28 UTC (permalink / raw)
To: Gregory Maxwell, Tom Harding; +Cc: Bitcoin Development
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 which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).
I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.
On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com>
> 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 significant dent
>> if something like this worked, and were used by default someday.
>
> Great, that can be accomplished by simply encoding an expiration
> into the address people are using and specifying that clients
> enforce it.
>
> ----------------------------------------------------------------------
--------
>
>
>
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 21:44 ` Gregory Maxwell
@ 2015-03-26 22:23 ` Tom Harding
2015-03-26 22:28 ` s7r
2015-06-13 4:52 ` odinn
2 siblings, 0 replies; 17+ messages in thread
From: Tom Harding @ 2015-03-26 22:23 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
On 3/26/2015 2:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com> 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 significant dent if something like this worked, and were used by default
>> someday.
> Great, that can be accomplished by simply encoding an expiration into
> the address people are using and specifying that clients enforce it.
Another way to look at it: is the benefit of the bitcoin network
providing this service sufficiently greater than the cost?
The main cost is that a reorganization has a chance of invalidating a
payment made at or just before expiration (if the payment isn't early
enough in the new chain). Would that increase recommended confirmations
above their current levels, which are centered around the possibility of
a malicious double-spend? Unclear to me.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 21:26 ` Tom Harding
2015-03-26 21:33 ` Peter Todd
@ 2015-03-26 21:44 ` Gregory Maxwell
2015-03-26 22:23 ` Tom Harding
` (2 more replies)
1 sibling, 3 replies; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-26 21:44 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding <tomh@thinlink•com> 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 significant dent if something like this worked, and were used by default
> someday.
Great, that can be accomplished by simply encoding an expiration into
the address people are using and specifying that clients enforce it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 21:26 ` Tom Harding
@ 2015-03-26 21:33 ` Peter Todd
2015-03-26 21:44 ` Gregory Maxwell
1 sibling, 0 replies; 17+ messages in thread
From: Peter Todd @ 2015-03-26 21:33 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
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 have to live with the
> > results, esp. as we can't prevent that in a strong sense.
>
> 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 significant dent if something like this worked, and were
> used by default someday.
Again, along the lines of what Gregory Maxwell is saying, if the payment
instructions you have given to the sender say "don't make funds
spendable with scriptPubKey after this date" why are you scanning those
"old" bitcoin addresses for future payments? That makes no more sense
than taking your p2pkh addresses and scanning for the same scriptPubKey
embedded within a p2sh address - you haven't told anyone to pay you via
that method so why expect anyone to do so?
> Address expiration is not an enhancement to the payment experience and
> it doesn't stop sender from doing something weird. Hacking a new
> address for the recipient would be just as weird as hacking their client
> IMHO.
The sender is free to bury their Bitcoins in a safe in your neighbors
front yard; you have no reason to accept such silly behavior as payment
and every reason to ignore it.
--
'peter'[:-1]@petertodd.org
00000000000000000b48023e9c98038c50b9a2044975bbdf9f43313400a156b6
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 20:42 ` Gregory Maxwell
@ 2015-03-26 21:26 ` Tom Harding
2015-03-26 21:33 ` Peter Todd
2015-03-26 21:44 ` Gregory Maxwell
0 siblings, 2 replies; 17+ messages in thread
From: Tom Harding @ 2015-03-26 21:26 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
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 strong sense.
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 significant dent if something like this worked, and were
used by default someday.
Address expiration is not an enhancement to the payment experience and
it doesn't stop sender from doing something weird. Hacking a new
address for the recipient would be just as weird as hacking their client
IMHO.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-26 20:38 ` Tom Harding
@ 2015-03-26 20:42 ` Gregory Maxwell
2015-03-26 21:26 ` Tom Harding
0 siblings, 1 reply; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-26 20:42 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding <tomh@thinlink•com> 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 not make it a client feature
instead of a consensus rule?
If someone wants to bypass anything they always can, thats what I mean
by "hide their payment under a rock"
E.g. I can take your pubkey, add G to it (adding 1 to the private
key), strip off the time limits, and send the funds.
"What do you mean I didn't pay you? I wrote a check. locked it in a
safe, and burred it in your back garden."
The answer to this can only be that payment is only tendered when its
made _exactly_ to the payee's specifications.
If someone violates the specifications all they're doing is destroying
coins. Nothing can stop people from destroying coins...
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 strong sense.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-25 19:22 ` Gregory Maxwell
@ 2015-03-26 20:38 ` Tom Harding
2015-03-26 20:42 ` Gregory Maxwell
0 siblings, 1 reply; 17+ messages in thread
From: Tom Harding @ 2015-03-26 20:38 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
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-coded in this simple scheme (X=144 => "1-day addresses").
You could picture a selectable expiration duration too.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-25 18:44 ` Tom Harding
@ 2015-03-25 19:22 ` Gregory Maxwell
2015-03-26 20:38 ` Tom Harding
0 siblings, 1 reply; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-25 19:22 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
On Wed, Mar 25, 2015 at 6:44 PM, Tom Harding <tomh@thinlink•com> 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
> wouldn't allow the string to be trivially changed by the sender?
The sender is always able to intentionally hide their payment under a
rock-- There is no encoding that can prevent that.
The defense against that is to not accept payments not made according
to the payees specification.
> I don't understand, explanation would be appreciated.
To reject reused scriptPubKeys you must remember past scriptPubkeys in
order to test against them.
For illustration purposes imagine a bitcoin system where there is only
a single base unit available for trade.
Verification of that chain requires O(1) storage (the identity of the
current chain tip, and the identity of the spendable coin.).
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.
(The same is true for actual Bitcoin as well, though the constant
factors make the difference somewhat less stark.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-25 16:34 ` Gregory Maxwell
@ 2015-03-25 18:44 ` Tom Harding
2015-03-25 19:22 ` Gregory Maxwell
0 siblings, 1 reply; 17+ messages in thread
From: Tom Harding @ 2015-03-25 18:44 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
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 major benefit of address
expiration, if it works, would be that it works without requiring
payment protocol.
> If the sender is an uncooperative idiot, they can always change your
> target and send anyways.
Are you suggesting there is no implementation of address expiration that
wouldn't allow the string to be trivially changed by the sender?
>> Block containing tx invalid if a prior confirmed tx has paid address
> Requires a unprunable verification state.
I don't understand, explanation would be appreciated.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-25 1:57 Tom Harding
2015-03-25 10:09 ` Matt Whitlock
@ 2015-03-25 16:34 ` Gregory Maxwell
2015-03-25 18:44 ` Tom Harding
1 sibling, 1 reply; 17+ messages in thread
From: Gregory Maxwell @ 2015-03-25 16:34 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
On Wed, Mar 25, 2015 at 1:57 AM, Tom Harding <tomh@thinlink•com> 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 = 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.
If the sender is an uncooperative idiot, they can always change your
target and send anyways.
This would seem to work nearly as well as the non-reorg safe network
impacting version, and yet has no cost beyond the extra size is
communicating the limit.
> Block containing tx invalid if a prior confirmed tx has paid address
Requires a unprunable verification state.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] Address Expiration to Prevent Reuse
2015-03-25 1:57 Tom Harding
@ 2015-03-25 10:09 ` Matt Whitlock
2015-03-25 16:34 ` Gregory Maxwell
1 sibling, 0 replies; 17+ messages in thread
From: Matt Whitlock @ 2015-03-25 10:09 UTC (permalink / raw)
To: bitcoin-development
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 bounded resource requirements,
The core devs seem not to like ideas such as this because a transaction that was once valid can become invalid due to a chain reorganization.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bitcoin-development] Address Expiration to Prevent Reuse
@ 2015-03-25 1:57 Tom Harding
2015-03-25 10:09 ` Matt Whitlock
2015-03-25 16:34 ` Gregory Maxwell
0 siblings, 2 replies; 17+ messages in thread
From: Tom Harding @ 2015-03-25 1:57 UTC (permalink / raw)
To: Bitcoin Development
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 paying this
address, could be made reuse-proof with bounded resource requirements,
if for locktime'd tx paying address, the following were enforced by
consensus:
- Expiration
Block containing tx invalid at height > 349366
- Finality
Block containing tx invalid if (349366 - locktime) > X
(X is the address validity duration in blocks)
- Uniqueness
Block containing tx invalid if a prior confirmed tx has paid address
Just an an idea, obviously not a concrete proposal.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-06-13 4:52 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-27 4:31 [Bitcoin-development] Address Expiration to Prevent Reuse Thy Shizzle
-- strict thread matches above, loose matches on Subject: below --
2015-03-27 1:51 Thy Shizzle
2015-03-27 3:13 ` Gregory Maxwell
2015-03-25 1:57 Tom Harding
2015-03-25 10:09 ` Matt Whitlock
2015-03-25 16:34 ` Gregory Maxwell
2015-03-25 18:44 ` Tom Harding
2015-03-25 19:22 ` Gregory Maxwell
2015-03-26 20:38 ` Tom Harding
2015-03-26 20:42 ` Gregory Maxwell
2015-03-26 21:26 ` Tom Harding
2015-03-26 21:33 ` Peter Todd
2015-03-26 21:44 ` Gregory Maxwell
2015-03-26 22:23 ` Tom Harding
2015-03-26 22:28 ` s7r
2015-03-26 23:00 ` Gregory Maxwell
2015-06-13 4:52 ` odinn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox