Re: [Bitcoin-development] New BIP: protocol for multisignature payments
Hi Martin, You're on the right lines. Your writeup is pretty similar to the high level overview given here though: https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation To make 2-of-3 dispute mediation works requires implementing a wallet that supports it, and the tools mediators need to manage incoming tickets, etc. The BIP70 extension is probably the smallest part of the project. On Sat, Jan 31, 2015 at 2:30 AM, Martin Habovštiak martin.habovst...@gmail.com wrote: Hello, I've been thinking about how to solve security problems of the servers holding huge amounts of bitcoins (exchanges, markets...) and came up with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5 TL;DR: it's extension of BIP70 (but not fully compatible due to security reasons) which supports making of multisig transactions dynamically. (The most important thing is that the user provides his address.) What do you think? Is it a good way to solve the problem or do you know about something better? I would really like this or something similar implemented by wallets. Thank you for your feedback! Martin -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP: protocol for multisignature payments
I could look at implementing it someday, but now I'd like to receive feedback from community. IMO it's better to pair a protocol spec with an implementation. For one, it can show up issues in the design you didn't think of. For another, implementation is a lot more work than speccing out a few protocol buffers and high level procedures, so people who are going to write an implementation probably won't follow your design unless they have a great degree of confidence in it and some compelling reason to use it (e.g. interop with other users). -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?
Alipay handled up to 2.85 million transactions per minute, and 54 percent of its transactions are made via mobile device. I know China is a very big place but even so - 47,500 transactions per second would be almost quintiple what Visa handles across the entire world. With only 300 million users and primarily online usage (?) this claim feels a little suspect to me. Given the wording up to 2.85 million I wonder if that is some freak spike caused by people's behaviour being synchronised externally (e.g. a fixed start time for the sale that people are waiting for). It's hard to imagine that they sustained anything close to that for the entire day. So this is really a discussion about peak performance. If you average every transaction around 250 bytes, then you'd need ~15 Gigabytes per block to be broadcast and hashed by all the full nodes every 10 minutes, eating good 2Tb of storage daily... do miners have enough bandwidth and CPU power to handle this? There's a discussion of such things here that might be useful: https://en.bitcoin.it/wiki/Scalability It discusses various optimisations, like not actually sending tx data twice. I wouldn't worry about it too much. It took decades for Visa to even approach 10,000 txns/sec. PayPal, I believe, still only handles a few hundred. And those services had the benefits of minimal competition, working in people's local currencies, integrated dispute mediation and not representing any real threat to the political status quo. Bitcoin isn't going to be needing to handle Alipay's level of traffic any time soon. Frankly, scaling is a nice problem to have, it means you're popular. It'd be a mistake to just blindly assume Bitcoin will take over the world. Growing market share is difficult. Worry more about how to get 300 million crazy users than the precise broadcast protocol that'd be needed to handle them ;) -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP: protocol for multisignature payments
I know about that wiki page. I just wanted to design protocol which would make it easier in practice. (now it would be done manually) I could look at implementing it someday, but now I'd like to receive feedback from community. 2015-01-31 19:19 GMT+02:00 Mike Hearn m...@plan99.net: Hi Martin, You're on the right lines. Your writeup is pretty similar to the high level overview given here though: https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation To make 2-of-3 dispute mediation works requires implementing a wallet that supports it, and the tools mediators need to manage incoming tickets, etc. The BIP70 extension is probably the smallest part of the project. On Sat, Jan 31, 2015 at 2:30 AM, Martin Habovštiak martin.habovst...@gmail.com wrote: Hello, I've been thinking about how to solve security problems of the servers holding huge amounts of bitcoins (exchanges, markets...) and came up with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5 TL;DR: it's extension of BIP70 (but not fully compatible due to security reasons) which supports making of multisig transactions dynamically. (The most important thing is that the user provides his address.) What do you think? Is it a good way to solve the problem or do you know about something better? I would really like this or something similar implemented by wallets. Thank you for your feedback! Martin -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?
My concerns come from 2 projects that could easily raise the current transaction volume 10x daily in the short term, perhaps even 100x a year from now after the media blows it out. Think legal bittorrent file sales: ebooks, indie music (albums and singles), films, art, stock photography. Think p2p amazon (OpenBazaar) and how that could grow exponentially in terms of transactional volume when ecommerce penetrates geos currently underserved. Thanks for your explanations. it seems as of now we must rely on the likes of centralized solutions like Bitpay, Coinbase to manage the transactional volume we expect, or just wait for the technology to be ready finally handle it in a real p2p fashion, no intermediaries. On Sat, Jan 31, 2015, 6:04 PM Mike Hearn m...@plan99.net wrote: Alipay handled up to 2.85 million transactions per minute, and 54 percent of its transactions are made via mobile device. I know China is a very big place but even so - 47,500 transactions per second would be almost quintiple what Visa handles across the entire world. With only 300 million users and primarily online usage (?) this claim feels a little suspect to me. Given the wording up to 2.85 million I wonder if that is some freak spike caused by people's behaviour being synchronised externally (e.g. a fixed start time for the sale that people are waiting for). It's hard to imagine that they sustained anything close to that for the entire day. So this is really a discussion about peak performance. If you average every transaction around 250 bytes, then you'd need ~15 Gigabytes per block to be broadcast and hashed by all the full nodes every 10 minutes, eating good 2Tb of storage daily... do miners have enough bandwidth and CPU power to handle this? There's a discussion of such things here that might be useful: https://en.bitcoin.it/wiki/Scalability It discusses various optimisations, like not actually sending tx data twice. I wouldn't worry about it too much. It took decades for Visa to even approach 10,000 txns/sec. PayPal, I believe, still only handles a few hundred. And those services had the benefits of minimal competition, working in people's local currencies, integrated dispute mediation and not representing any real threat to the political status quo. Bitcoin isn't going to be needing to handle Alipay's level of traffic any time soon. Frankly, scaling is a nice problem to have, it means you're popular. It'd be a mistake to just blindly assume Bitcoin will take over the world. Growing market share is difficult. Worry more about how to get 300 million crazy users than the precise broadcast protocol that'd be needed to handle them ;) -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP: protocol for multisignature payments
I agree- standards should be descriptive (here is how this thing I did works) and NOT proscriptive (here's what I think will work, lets all try to do it this way.). On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn m...@plan99.net wrote: I could look at implementing it someday, but now I'd like to receive feedback from community. IMO it's better to pair a protocol spec with an implementation. -- -- Gavin Andresen -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP: protocol for multisignature payments
I didn't consider that, thank you for feedback! I will try to find some time for implementing it. I'll write again then. 2015-01-31 23:50 GMT+02:00 Gavin Andresen gavinandre...@gmail.com: I agree- standards should be descriptive (here is how this thing I did works) and NOT proscriptive (here's what I think will work, lets all try to do it this way.). On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn m...@plan99.net wrote: I could look at implementing it someday, but now I'd like to receive feedback from community. IMO it's better to pair a protocol spec with an implementation. -- -- Gavin Andresen -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 31 jan 2015 23:17 skrev Brian Erdelyi brian.erde...@gmail.com: Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? See vanitygen. Yes, 8 characters can be bruteforced. You need about 100 bits of security for strong security, and at the very least NOT less than ~64 (see distributed bruteforce projects attacking 64 bit keys for reference, you can find plenty via Google). You shouldn't rely on mechanisms intended to be used for one-shot auth where the secret is supposed to be unguessable for another system where the attacker knows what the target string is and have a fair amount of time to attempt bruteforce. Use something more like HMAC instead. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 1 feb 2015 00:05 skrev Brian Erdelyi brian.erde...@gmail.com: See vanitygen. Yes, 8 characters can be brute forced. Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address. I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one. As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed. Brian Erdelyi To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. One try = generate a random number, use it to generate an ECDSA keypair, SHA256 and RIPEMD160 hash the public key per Bitcoin specs, then run that OCRA hashing code, then compare strings. Considering the ECDSA operations is by a large margin slower than all the hash functions, consider them to just add a small percentage in performance drop vs regular vanitygen usage. My non-gaming laptop performed IIRC at *a few million keys per second* with OpenCL. I've used it to search for 6 character strings in the base58 Bitcoin addresses with it in 15 minutes to half an hour or so. That's about 35 bits of entropy (rough estimate, there's some details with padding in the base58 representation that alters it). So 2^(35-26) ~= 1 in 500 of that time, and that's if you use a laptop instead of a GPU rig. Seconds at worst. Milliseconds if done on a rig. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
See vanitygen. Yes, 8 characters can be brute forced. Thank you for this reference. Interesting to see that there is a tool to generate a vanity bitcoin address. I am still researching viruses that are designed to manipulate a bitcoin address. I suspect they are primitive in that they use a hardcoded rogue bitcoin address as opposed to dynamically generating one. As a start, this would help protect against malware that uses a static rogue bitcoin address. The next thing would be for the malware to brute-force the legitimate bitcoin address and generate a rogue bitcoin address that would produce the same 8 digit code. Curious to know how long this brute force would take? Or perhaps, before converting to 8 digits there is some other hashing function that is performed. Brian Erdelyi-- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to address Bitcoin malware
Den 1 feb 2015 00:37 skrev Natanael natanae...@gmail.com: To bruteforce 8 decimals, on average you need (10^8)/2 = 50 000 000 tries. log(50M)/log(2) = 25.6 bits of entropy. Oops. Used the wrong number in the entropy calculation. Add one bit, the division by 2 wasn't supposed to be used in the entropy calculation. Doesn't change the equation much, though. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal to address Bitcoin malware
Hello all, The number of incidents involving malware targeting bitcoin users continues to rise. One category of virus I find particularly nasty is when the bitcoin address you are trying to send money to is modified before the transaction is signed and recorded in the block chain. This behaviour allows the malware to evade two-factor authentication by becoming active only when the bitcoin address is entered. This is very similar to how man-in-the-browser malware attack online banking websites. Out of band transaction verification/signing is one method used with online banking to help protect against this. This can be done in a variety of ways with SMS, voice, mobile app or even security tokens. This video demonstrates how HSBC uses a security token to verify transactions online. https://www.youtube.com/watch?v=Sh2Iha88agE https://www.youtube.com/watch?v=Sh2Iha88agE. Many Bitcoin wallets and services already use Open Authentication (OATH) based one-time passwords (OTP). Is there any interest (or existing work) in in the Bitcoin community adopting the OATH Challenge-Response Algorithm (OCRA) for verifying transactions? I know there are other forms of malware, however, I want to get thoughts on this approach as it would involve the use of a decimal representation of the bitcoin address (depending on particular application). In the HSBC example (see YouTube video above), this was the last 8 digits of the recipient’s account number. Would it make sense to convert a bitcoin address to decimal and then truncate to 8 digits for this purpose? I understand that truncating the number in some way only increases the likelihood for collisions… however, would this still be practical or could the malware generate a rogue bitcoin address that would produce the same 8 digits of the legitimate bitcoin address? Brian Erdelyi signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?
On Fri, 30 Jan 2015, Nick Simpson wrote: This has been discussed before. I believe most people don't expect Bitcoin to replace all of the various methods of payment. Scalability is always a concern, just not to the level of Alipay this year (or the next or the next for that matter.) Yes, that about summarizes it. The block chain is a single channel broadcasted over the entire world, and I don't believe it will ever be possible nor desirable to broadcast all the world's transactions over one channel. The everyone-validates-everything approach doesn't scale. It is however useful to settle larger transactions in an irreversible, zero-trust way. That's what makes the bitcoin system, as it is now, valuable. But it is absurd for the whole world to have to validate every purchase of a cup of coffee or a bus ticket by six billion others. Naively scaling up the block size will get some leeway in the short term, but I believe a future scalable payment system based on bitcoin will be mostly based on off-blockchain transactions (in some form) or that there will be a hierarchical or subdivided system (e.g. temporary or per-locale sidechains). Wladimir-- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
