Re: [Bitcoin-development] Pubkey addresses
2011/12/17, Jordan Mack jordanm...@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? -- 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
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 l...@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 -- 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
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. -- 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
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 -- 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
Now I get it. Thank you. You save space by having shorter scripts in transactions. -- 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
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? -- 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
[Bitcoin-development] Pubkey addresses
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
