* [Bitcoin-development] Pubkey addresses
@ 2011-12-17 6:32 Luke-Jr
2011-12-17 11:14 ` Jorge Timón
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Luke-Jr @ 2011-12-17 6:32 UTC (permalink / raw)
To: bitcoin-development
IMO, we should standardize and support public key addresses. While not ideal
for humans, because of their length, it's a better fit for large QR Codes IMO.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 6:32 [Bitcoin-development] Pubkey addresses Luke-Jr
@ 2011-12-17 11:14 ` Jorge Timón
2011-12-17 16:15 ` Matt Corallo
2011-12-17 13:54 ` Wladimir
2011-12-17 21:52 ` Luke-Jr
2 siblings, 1 reply; 15+ messages in thread
From: Jorge Timón @ 2011-12-17 11:14 UTC (permalink / raw)
Cc: bitcoin-development
Don't know much about QR codes, but I thought they have a length limitation.
Why jav wants to use not just addresses but firstbits then?
"Allow a field "green_address_list" (short "gal") to specify
acceptable addresses in Firstbit format directly in the QR code and
only use the "green_address_details" mechanism when that starts to get
too long to fit comfortably into the QR code"
https://bitcointalk.org/index.php?topic=32818.msg422789#msg422789
2011/12/17, Luke-Jr <luke@dashjr•org>:
> IMO, we should standardize and support public key addresses. While not ideal
> for humans, because of their length, it's a better fit for large QR Codes
> IMO.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 6:32 [Bitcoin-development] Pubkey addresses Luke-Jr
2011-12-17 11:14 ` Jorge Timón
@ 2011-12-17 13:54 ` Wladimir
2011-12-17 21:52 ` Luke-Jr
2 siblings, 0 replies; 15+ messages in thread
From: Wladimir @ 2011-12-17 13:54 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
I don't see reason why not. It could just be another, longer, address type.
The advantage being that it allows for shorter transactions in the block
chain (right?).
Wladimir
On Sat, Dec 17, 2011 at 7:32 AM, Luke-Jr <luke@dashjr•org> wrote:
> IMO, we should standardize and support public key addresses. While not
> ideal
> for humans, because of their length, it's a better fit for large QR Codes
> IMO.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 1563 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 11:14 ` Jorge Timón
@ 2011-12-17 16:15 ` Matt Corallo
2011-12-17 18:20 ` Jordan Mack
0 siblings, 1 reply; 15+ messages in thread
From: Matt Corallo @ 2011-12-17 16:15 UTC (permalink / raw)
To: bitcoin-development
On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
> Don't know much about QR codes, but I thought they have a length limitation.
> Why jav wants to use not just addresses but firstbits then?
Under no circumstances should the use of firstbits ever be supported.
It doesn't scale, not even close, especially as we (hopefully) move
towards SPV clients. Also, it provides incentives for people to spam
the chain to get a firstbits address. Never should that be supported.
Matt
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 16:15 ` Matt Corallo
@ 2011-12-17 18:20 ` Jordan Mack
2011-12-18 12:15 ` Jorge Timón
0 siblings, 1 reply; 15+ messages in thread
From: Jordan Mack @ 2011-12-17 18:20 UTC (permalink / raw)
To: bitcoin-development
While I think firstbits is an interesting idea, I agree with Matt on
this one. Firstbits, while being a clever idea, produces a less
desirable solution in comparison to the current alias proposals.
In addition to Matt's reasons, I would like to add that it is still a
block of random characters, just shorter. It creates the undesirable
effect of having addresses short enough that people may try to type it
in rather than pasting or scanning, which is more error prone.
One obvious scenario for potential exploitation would be if a large
organization adopted a firstbits address for donations. Others could
immediately try to collect similar addresses in hopes of a typo. A
second would be if the organization published the firstbits address on a
poster in a public location. Someone could easily secure a firstbits
address which was one character longer, then stencil that extra
character on to the poster.
On 12/17/2011 8:15 AM, Matt Corallo wrote:
> On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
>> Don't know much about QR codes, but I thought they have a length limitation.
>> Why jav wants to use not just addresses but firstbits then?
> Under no circumstances should the use of firstbits ever be supported.
> It doesn't scale, not even close, especially as we (hopefully) move
> towards SPV clients. Also, it provides incentives for people to spam
> the chain to get a firstbits address. Never should that be supported.
>
> Matt
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 6:32 [Bitcoin-development] Pubkey addresses Luke-Jr
2011-12-17 11:14 ` Jorge Timón
2011-12-17 13:54 ` Wladimir
@ 2011-12-17 21:52 ` Luke-Jr
2011-12-17 23:46 ` Gregory Maxwell
2 siblings, 1 reply; 15+ messages in thread
From: Luke-Jr @ 2011-12-17 21:52 UTC (permalink / raw)
To: bitcoin-development
I propose that full public key addresses be required to be "compact" (length
33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
byte data). Any reason this wouldn't be workable?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 21:52 ` Luke-Jr
@ 2011-12-17 23:46 ` Gregory Maxwell
2011-12-18 0:28 ` Luke-Jr
0 siblings, 1 reply; 15+ messages in thread
From: Gregory Maxwell @ 2011-12-17 23:46 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
On Sat, Dec 17, 2011 at 4:52 PM, Luke-Jr <luke@dashjr•org> wrote:
> I propose that full public key addresses be required to be "compact" (length
> 33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
> byte data). Any reason this wouldn't be workable?
Would introduce yet another address type that services will have to cope with.
No currently deployed sofware knows how to spend it.
No currently deployed software knows how to receive it.
All pay-to-pubkey schemes (point compressed or otherwise) shift
storage to TXN _output_ scripts which are the least prunable place, so
for nodes which are pruning any pay to pubkey scheme will result in
more storage than pay to address.
Ignoring pruning, pay-to-address + key recovery is quite a bit smaller
than pay-to-compressed pubkey.
The downsides to op-eval2+recovery were the lack of software, but
we're in an equal boat with this.
Excitement over key recovery fell was diminished when it was pointed
out that it only saves space in input scripts which wasn't so
important because they're quickly prunable. If you accept that
pruning will someday be common on many nodes then you should prefer
pay to address (since its smallest in that case). If you assume they
won't be, you should prefer pay to address plus key recovery (since
its the smallest without pruning).
Pay to non-compressed pubkey is smaller than
pay-to-address-without-recovery assuming you don't prune, and its more
deployable because nodes can already recieve it. It's larger if you
do prune, and it's larger than recovery either way. Pay-to-compressed
has all the disadvantages, it still larger than recovery and doesn't
have the advantage of already deployed software.
Sorry to be curt— I'm a little irritated that discussion on recovery
in OP_EVAL was dropped because "input script size doesn't matter
because of pruning" and now people are talking about adding another
address type which creates seriously bloated transactions where there
is pruning, because its slightly smaller in the no-pruning case (and
again, still not as small for key recovery).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 23:46 ` Gregory Maxwell
@ 2011-12-18 0:28 ` Luke-Jr
2011-12-18 0:39 ` Luke-Jr
0 siblings, 1 reply; 15+ messages in thread
From: Luke-Jr @ 2011-12-18 0:28 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
On Saturday, December 17, 2011 6:46:34 PM Gregory Maxwell wrote:
> Sorry to be curt— I'm a little irritated that discussion on recovery
> in OP_EVAL was dropped because "input script size doesn't matter
> because of pruning" and now people are talking about adding another
> address type which creates seriously bloated transactions where there
> is pruning, because its slightly smaller in the no-pruning case (and
> again, still not as small for key recovery).
I missed that bit. I'm willing to defer full OP_EVAL support on Eligius in
order to enable key recovery...
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 0:28 ` Luke-Jr
@ 2011-12-18 0:39 ` Luke-Jr
0 siblings, 0 replies; 15+ messages in thread
From: Luke-Jr @ 2011-12-18 0:39 UTC (permalink / raw)
To: bitcoin-development
On Saturday, December 17, 2011 7:28:12 PM Luke-Jr wrote:
> On Saturday, December 17, 2011 6:46:34 PM Gregory Maxwell wrote:
> > Sorry to be curt— I'm a little irritated that discussion on recovery
> > in OP_EVAL was dropped because "input script size doesn't matter
> > because of pruning" and now people are talking about adding another
> > address type which creates seriously bloated transactions where there
> > is pruning, because its slightly smaller in the no-pruning case (and
> > again, still not as small for key recovery).
>
> I missed that bit. I'm willing to defer full OP_EVAL support on Eligius in
> order to enable key recovery...
In fact, as long as we have this opportunity to enable new opcodes, maybe we
should spend some time revisiting what doors that opens...
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-17 18:20 ` Jordan Mack
@ 2011-12-18 12:15 ` Jorge Timón
2011-12-18 14:03 ` Luke-Jr
2011-12-18 15:42 ` Pieter Wuille
0 siblings, 2 replies; 15+ messages in thread
From: Jorge Timón @ 2011-12-18 12:15 UTC (permalink / raw)
Cc: bitcoin-development
2011/12/17, Jordan Mack <jordanmack@parhelic•com>:
> While I think firstbits is an interesting idea, I agree with Matt on
> this one. Firstbits, while being a clever idea, produces a less
> desirable solution in comparison to the current alias proposals.
I'm just saying is useful for the "green address" particular case.
People don't have to write or memorize the firstbit address, it's just
to have a shorter string to put it in the QR code. In this particular
case you don't really care about "squatting" or typographic errors
because the users are bot going to write or even see the firstbit
address. I think aliases are a better solution for the "memorizing use
case".
But anyway, reading some comments I feel I'm missing something about
this proposal. How can you save space by putting the whole public key
instead of just the address (a hash of the public key) with each
output?
Is this what it's being proposed?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 12:15 ` Jorge Timón
@ 2011-12-18 14:03 ` Luke-Jr
2011-12-18 14:28 ` Jorge Timón
2011-12-18 15:42 ` Pieter Wuille
1 sibling, 1 reply; 15+ messages in thread
From: Luke-Jr @ 2011-12-18 14:03 UTC (permalink / raw)
To: bitcoin-development
On Sunday, December 18, 2011 7:15:26 AM Jorge Timón wrote:
> I'm just saying is useful for the "green address" particular case.
"Green addresses" are also a broken-by-design feature and should be
discouraged.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 14:03 ` Luke-Jr
@ 2011-12-18 14:28 ` Jorge Timón
2011-12-18 14:34 ` Luke-Jr
0 siblings, 1 reply; 15+ messages in thread
From: Jorge Timón @ 2011-12-18 14:28 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
I see it as a good start for POS payments. I don't know what flaw
you're referring to.
Back on topic, is actually putting the whole pub key in each output
what you're proposing?
2011/12/18, Luke-Jr <luke@dashjr•org>:
> On Sunday, December 18, 2011 7:15:26 AM Jorge Timón wrote:
>> I'm just saying is useful for the "green address" particular case.
>
> "Green addresses" are also a broken-by-design feature and should be
> discouraged.
>
--
Jorge Timón
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 14:28 ` Jorge Timón
@ 2011-12-18 14:34 ` Luke-Jr
0 siblings, 0 replies; 15+ messages in thread
From: Luke-Jr @ 2011-12-18 14:34 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-development
On Sunday, December 18, 2011 9:28:36 AM Jorge Timón wrote:
> Back on topic, is actually putting the whole pub key in each output
> what you're proposing?
Yes, just like is already done for generation, since it is more efficient
*overall* for the block chain. sipa's key extraction is a MUCH better
solution, however, so if we can get that without a block chain fork, I'm
inclined to favour it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 12:15 ` Jorge Timón
2011-12-18 14:03 ` Luke-Jr
@ 2011-12-18 15:42 ` Pieter Wuille
2011-12-18 19:50 ` Jorge Timón
1 sibling, 1 reply; 15+ messages in thread
From: Pieter Wuille @ 2011-12-18 15:42 UTC (permalink / raw)
To: bitcoin-development
On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Timón wrote:
> But anyway, reading some comments I feel I'm missing something about
> this proposal. How can you save space by putting the whole public key
> instead of just the address (a hash of the public key) with each
> output?
> Is this what it's being proposed?
Yes. The reason is that currently a send-to-address puts the address in the
output script, while redeeming requires the full pubkey plus the signature
to be placed in the input script. Overall, this requires more space than a
send-to-pubkey, where the output contains the pubkey, and the input the
signature.
There are several possible improvements however, and they may not all have
been explained in this thread. To summarize:
* compressed public keys (33 byte pubkeys instead of 65 bytes)
* compact signatures (66 bytes instead of 72, including hash type byte)
* pubkey recovery (allows the public key to be derived from a compact signature)
The first is very easy to implement (see pull #649). Compact signatures
and pubkey recovery require a change to the scripting language (though are
already implemented, as they are used for message signing).
These result in several combinations that could be proposed:
1) send-to-pubkeys-hash
- currently the default addres type
2) send-to-recovered-pubkeys-hash-with-compact-signature-inside-op_eval
- extend the scripting language inside OP_EVAL, as described in
https://gist.github.com/1262449
- use compact signatures
- use key recovery, and never put a pubkey in the blockchain data
3) send-to-pubkey
- traditional transaction type
4) send-to-compressed-pubkey
- what Luke proposes as new address type
5) send-to-compressed-pubkeys-hash
- what pull #649 would bring
Gregory Maxwell made a small table to compare these options:
http://people.xiph.org/~greg/addr.compare.html
If you don't consider pruning, everything is better than send-to-pubkeys-hash
as we have now. Both using pubkeys instead of hashes, using compressed pubkeys
instead of full ones improve the situation independently, and using key
recovery is even better.
If you do consider pruning, the advantages are smaller, but it is far from
clear to me how pruning will be implemented in the future (as a pruning
node cannot function as a NODE_NETWORK service anymore).
--
Pieter
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bitcoin-development] Pubkey addresses
2011-12-18 15:42 ` Pieter Wuille
@ 2011-12-18 19:50 ` Jorge Timón
0 siblings, 0 replies; 15+ messages in thread
From: Jorge Timón @ 2011-12-18 19:50 UTC (permalink / raw)
Cc: bitcoin-development
Now I get it. Thank you.
You save space by having shorter scripts in transactions.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-12-18 19:50 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-17 6:32 [Bitcoin-development] Pubkey addresses Luke-Jr
2011-12-17 11:14 ` Jorge Timón
2011-12-17 16:15 ` Matt Corallo
2011-12-17 18:20 ` Jordan Mack
2011-12-18 12:15 ` Jorge Timón
2011-12-18 14:03 ` Luke-Jr
2011-12-18 14:28 ` Jorge Timón
2011-12-18 14:34 ` Luke-Jr
2011-12-18 15:42 ` Pieter Wuille
2011-12-18 19:50 ` Jorge Timón
2011-12-17 13:54 ` Wladimir
2011-12-17 21:52 ` Luke-Jr
2011-12-17 23:46 ` Gregory Maxwell
2011-12-18 0:28 ` Luke-Jr
2011-12-18 0:39 ` Luke-Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox