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