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] Protocol extensions
On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs 50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- 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] Protocol extensions
The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to understand of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations). In fact, I would argue that a full node (Satoshi client), has the same level of security as a headers-only client... because they both base *all* their verification decisions on computations that end with comparing hashes to the longest-chain headers. In the case that an attacker figures out how to isolate your node entirely and start feeing you poisoned blocks, then you are vulnerable with any kind of node, full or lightweight. I don't see where the reduced security is. The only issue I see is that a truly light-weight, headers-only node will be having to download an entire block to get one transaction it needs. This would be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning. If a node can ask for a tx and the tx-hash-list of the block that incorporated that tx, he can easily verify his tx against his no-need-to-trust-anyone headers, and doesn't have to download MBs for every one. As for blockchain pruning... I think it's absolutely critical to find a way to do this, /for all nodes/. I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for /anyone/ to act as a full node (if possible). As such, I believe that the current system of minimizing TxOut size is the right one. TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved). -Alan On 12/18/2011 12:09 PM, theymos wrote: On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- 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 -- 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] Protocol extensions
Has anyone considered 'snapshot' frames (blocks). Message to node: getsnapshot: hash Node responds with a 'block' message. Then the hash for that particular snapshot is hardcoded into the sourcecode. It would replace the checkpoints and use the last hash in that list. Validating blocks is pretty fast right up until block 135k, which is where time taken balloons and starts become exponentially slower. As blockchain grows linearly, resources needed grows exponentially if you think about it. From: Alan Reiner etothe...@gmail.com To: bitcoin-development@lists.sourceforge.net Sent: Sunday, December 18, 2011 6:06 PM Subject: Re: [Bitcoin-development] Protocol extensions The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to understand of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations). In fact, I would argue that a full node (Satoshi client), has the same level of security as a headers-only client... because they both base all their verification decisions on computations that end with comparing hashes to the longest-chain headers. In the case that an attacker figures out how to isolate your node entirely and start feeing you poisoned blocks, then you are vulnerable with any kind of node, full or lightweight. I don't see where the reduced security is. The only issue I see is that a truly light-weight, headers-only node will be having to download an entire block to get one transaction it needs. This would be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning. If a node can ask for a tx and the tx-hash-list of the block that incorporated that tx, he can easily verify his tx against his no-need-to-trust-anyone headers, and doesn't have to download MBs for every one. As for blockchain pruning... I think it's absolutely critical to find a way to do this, for all nodes. I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for anyone to act as a full node (if possible). As such, I believe that the current system of minimizing TxOut size is the right one. TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved). -Alan On 12/18/2011 12:09 PM, theymos wrote: On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs 50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- 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 -- 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 ___
Re: [Bitcoin-development] Protocol extensions
2011/12/17, theymos they...@mm.st: My preferred solution for handling scalability in the future is to have lightweight clients download only headers and Merkle trees (which are both small and easy to distribute), and then require senders to contact recipients directly in order to transmit their transactions. Then lightweight clients never need full blocks to build their balances, and full nodes don't have to handle expensive queries from lightweight clients. This idea is really interesting. Is there any drawback I don't see? -- 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] [BIP 15] Aliases
On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote: Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?) Like SSH, don't make it easy to ignore. eg, to ignore it, you need to manually go in and remove it from the URI. -- 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] [BIP 15] Aliases
Pieter, it was more rhetorical question than asking for explanation, but thanks anyway. As an Internet application developer, I of course understand security issues while using HTTPS and CA. I have a gut feeling that there simply does not exist any single solution which is both easy to use and secure enough. At least nobody mentioned it yet. And if I need to choose between easy solution or secure solution for aliases, I'll pick that easy one. I mean - we need some solution which will be easy enough for daily use; it is something what we currently don't have. But if I want to be really really sure I'm using correct destination for paying $1mil for a house, I can every time ask for real bitcoin addresses, this is that secure way which we currently have. slush On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote: Maybe I'm retarded, but where's the point in providing alliases containing yet another hash in URL? Any DNS-based alias system is vulnerable to spoofing. If I can make people's DNS server believe that mining.cz points to my IP, I'll receive payments to you... If no trusted CA is used to authenticate the communication, there is no way to be sure the one you are asking how to pay, is the person you want to pay. Therefore, one solution is to put a bitcoin address in the identification string itself, and requiring SSL communication authenticated using the respective key. This makes the identification strings obviously less useful as aliases, but pure aliases in the sense of human-typable strings have imho limited usefulness anyway - in most cases these identification strings will be communicated through other electronic means anyway. Furthermore, the embedded bitcoin address could be hidden from the user: retrieved when first connecting, and stored together with the URI in an address book. Like ssh, it could warn the user if the key changes (which wil be ignored by most users anyway, but what do you do about that?) -- 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 -- 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
