Re: [Bitcoin-development] Service bits for pruned nodes
On 4/28/2013 8:55 PM, Peter Todd wrote: On Mon, Apr 29, 2013 at 03:48:18AM +, John Dillon wrote: We can build this stuff incrementally I'll agree. It won't be the case that one in a thousand nodes serve up the part of the chain you need overnight. So many I am over engineering the solution with BitTorrent. I think that pretty much sums it up. With the block-range served in the anounce message you just need to find an annoucement with the right range, and at worst connect to a few more node to get what you need. One of the technologies that can be borrowed from Bittorrent (besides downloading from multiple peers at once) is analysis by clients of the part distribution, which allows a client to download and share the least-propagated parts first to maintain high availability of the whole file, even when not one individual currently has downloaded the complete file (the seed has left the swarm). Unlike Bittorrent, a partial-blockchain swarm client needs to make informed decisions about how much to download, such as rules like until it sees at least 20 complete blockchain-equivalents in the swarm, until it has 10% of the blockchain itself, work backwards, all blocks from the hash tree required to verify my payments or other minimums that might all be criteria. Bittorrent only considers directly connected peers' piecemaps when making decisions of what to download. Bitcoin, however, already has a protocol to allow peer discovery beyond the connected nodes; this could be extended to communicate what parts the peer is hosting. Careful thought into attack vectors would need to be paid in design, so that only a majority of outbound-connected peers's advertisement are able to inform consensus about part or peer availability, messages able to remove a peer or part availability from other's lists are confirmed independently without such removal verification generating DDOS traffic amplification, lying clients can be marked as discovered by the majority, etc. Such thought doesn't have to be paid if directly implementing Bittorrent, but it has the burden of centralized trackers or expensive DHT, and it also doesn't have any logic informing it besides don't quit until I get the whole file. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Hardware BitCoin wallet as part of Google Summer of Code
Crypto Stick is an open source USB key for encryption and secure authentication. We have been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. One of our project ideas is to develop a physical BitCoin wallet according to https://en.bitcoin.it/wiki/Smart_card_wallet If you are a student interested in working on that idea - this is for you. You can apply for a project with us and if accepted our mentors will work with you over the summer and Google will sponsor you USD 5000 during that time. Please check out our ideas page at https://www.assembla.com/spaces/cryptostick/wiki/Ideas or suggest your own idea. And, join our mailinglist to discuss it: https://lists.crypto-stick.org/mailman/listinfo/dev Your applications should be submitted through Google Melange (https://google-melange.com) until 3rd May! You can continue to submit additional information and comments into the system after your initial application submission. In order to participate in the program, you must be a student in an accredited institution or university. Links: * Crypto Stick project: http://crypto-stick.org * Ideas Page: https://www.assembla.com/spaces/cryptostick/wiki/Ideas * GSOC Progam FQ: https://google-melange.appspot.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page * Crypto Stick Mailing List: https://lists.crypto-stick.org/mailman/listinfo/dev Regards, Jan -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hardware BitCoin wallet as part of Google Summer of Code
On Mon, Apr 29, 2013 at 10:30:47PM +0800, Crypto Stick wrote: Crypto Stick is an open source USB key for encryption and secure authentication. We have been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. One of our project ideas is to develop a physical BitCoin wallet according to https://en.bitcoin.it/wiki/Smart_card_wallet A word of caution: hardware Bitcoin wallets really do need some type of display so the wallet itself can tell you where the coins it is signing are being sent, and that in turn implies support for the upcoming payment protocol so the wallet can also verify that the address is actually the address of the recipient the user is intending to send funds too. The current Crypto Stick hardware doesn't even have a button for user interaction. (press n times to approve an n-BTC spend) Having said that PGP smart cards and USB keys already have that problem, but the consequences of signing the wrong document are usually less than the consequences of sending some or even all of the users funds to a thief. You can usually revoke a bad signature after the fact with a follow-up message. Not to say hardware security for private keys isn't a bad thing, but the protections are a lot more limited than users typically realize. I will say though I am excited that this implies that the Crypto Stick could have ECC key support in the future. -- 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hardware BitCoin wallet as part of Google Summer of Code
Are you familiar with this: http://code.google.com/p/opencryptotoken/ It does ecc and as it is based on an atmel micro controller, adding a display is pretty straight forward Michael On 29/04/2013, at 18.28, Peter Todd p...@petertodd.org wrote: On Mon, Apr 29, 2013 at 10:30:47PM +0800, Crypto Stick wrote: Crypto Stick is an open source USB key for encryption and secure authentication. We have been accepted as a mentor organization for Google Summer of Code (GSOC) 2013. One of our project ideas is to develop a physical BitCoin wallet according to https://en.bitcoin.it/wiki/Smart_card_wallet A word of caution: hardware Bitcoin wallets really do need some type of display so the wallet itself can tell you where the coins it is signing are being sent, and that in turn implies support for the upcoming payment protocol so the wallet can also verify that the address is actually the address of the recipient the user is intending to send funds too. The current Crypto Stick hardware doesn't even have a button for user interaction. (press n times to approve an n-BTC spend) Having said that PGP smart cards and USB keys already have that problem, but the consequences of signing the wrong document are usually less than the consequences of sending some or even all of the users funds to a thief. You can usually revoke a bad signature after the fact with a follow-up message. Not to say hardware security for private keys isn't a bad thing, but the protections are a lot more limited than users typically realize. I will say though I am excited that this implies that the Crypto Stick could have ECC key support in the future. -- 'peter'[:-1]@petertodd.org -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
It's neat to use the payment address as an implicit signature by hashing something and multiplying it into the payee's pubKey. One downside is that it complicates the merchant's wallet. In this case the payment is going to a pseudo-random address which the merchant will have to explicitly add to their wallet, complicating backups, etc. The other challenge is how to handle an error when you POST to the payment_url. In the original spec, the payer would only broadcast the transaction themselves if there wasn't a payment_url. In the current version it looks like the payer will broadcast the transaction(s) either way. I only saw some of the discussions around this, but I think part of the problem is what state do you put the payer's wallet into if you POST a Payment and don't get a PaymentAck? If the payer always broadcasts the transaction, then wallet state becomes obvious. With your proposal you would not want the payer to broadcast the transaction without a PaymentAck, since you need the merchant to acknowledge they know where to look for the payment. Backing up a step, I'm not sure what the threat model is for signing the refund address? The same process that's signing the transaction is doing an HTTPS POST with the refund address. If an attacker can defeat that, then they can just redirect the payment in the first place. The only benefit I can think of is the payer can prove what refund address they specified with the payment. Wouldn't it be easier to just get the merchant to sign the PaymentAck? Technically they already are signing it, but a TLS stream probably isn't the most convenient way to capture that. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
