[Bitcoin-development] Pubkey addresses

[Bitcoin-development] Pubkey addresses

[Luke-Jr]

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.

Re: [Bitcoin-development] Pubkey addresses

[Jorge Timón]

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

Re: [Bitcoin-development] Pubkey addresses

[Wladimir]

[-- 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 --]

Re: [Bitcoin-development] Pubkey addresses

[Matt Corallo]

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

Re: [Bitcoin-development] Pubkey addresses

[Jordan Mack]

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

Re: [Bitcoin-development] Pubkey addresses

[Luke-Jr]

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?

Re: [Bitcoin-development] Pubkey addresses

[Gregory Maxwell]

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).

Re: [Bitcoin-development] Pubkey addresses

[Luke-Jr]

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...

Re: [Bitcoin-development] Pubkey addresses

[Luke-Jr]

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...

Re: [Bitcoin-development] Pubkey addresses

[Jorge Timón]

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?

Re: [Bitcoin-development] Pubkey addresses

[Luke-Jr]

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.

Re: [Bitcoin-development] Pubkey addresses

[Jorge Timón]

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

Re: [Bitcoin-development] Pubkey addresses

[Luke-Jr]

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.

Re: [Bitcoin-development] Pubkey addresses

[Pieter Wuille]

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

Re: [Bitcoin-development] Pubkey addresses

[Jorge Timón]

Now I get it. Thank you.
You save space by having shorter scripts in transactions.