Re: [Bitcoin-development] Why Bitcoin is and isn't like the Internet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 3rd party / web wallets are no longer viable except as means to burn customers and divulge (or be forced to divulge) their data to governments and corporations. Rather than restate what I have already posted on this matter I'll leave it there. It's time also for those who are managing bitcoin.org to reconsider what's posted there (the criteria for what's posted there - at present the web wallet section should be excluded, that is to say, Removed! from bitcoin.org with the possible exception of CoinKite to remain, which has a reasonable argument for having made such privacy advances as to merit usage by people (and to remain at bitcoin.org) Additionally, I see no point in recommending any of the other wallets except Electrum, Mycelium, Core, and in the hardware side, the ones that appear (Trezor and HW1). Furthermore, I believe those of you who are working for Coinbase customer operations or Bitpay (I will not name names, you know who you are) should resign from your employment. I will bring this point up regularly. You can easily find employment elsewhere, your skills are in high demand. - -O Alon Muroch: Bitcoin has a major crossroad ahead regarding a suitable platform for the average non technical main stream user. Until now the majority of the available solutions were at two extremes, or DIY your security and privacy *OR* let a 3rd party service do it for you. The DIY solution is obviously not scalable, but it seems that 3rd party solutions are not scalable as well. If we compare for a second a 3rd party services with traditional banks, it seems banks have two major advantages over them. Entry costs for creating a bank are HUGE so a priori very few people can actually create such a service, second, their physical and IT security infrastructure are heavily regulated which insures a minimum of security level to the end user (and even so money is stolen frequently). Entry costs and regulation do not exist in the bitcoin space, meaning two programers in their spare time can create a wallet/ platform and the non technical end user cannot know if his money is safe, did they hire the right security expert, did they invest enough in protecting and backing up his keys, etc. Many services tried to tackle those problems with multisig (2 of 2 and 2 of 3) to create a syntactical 2 factor authentication/ authorisation mechanism but in reality those solutions didn't really increase security and their failure point is always a single device. Coupling those said problems with the fact that bitcoin transactions are irreversible and are a scarce commodity, trying to insure them the way our money is insured by the government when we deposit it in the bank becomes a huge problem. Premiums will be very high and will only grow as the appetite of hackers to steal coins increase. I personally believe we have the tools for creating a platform that is both secure and private but most importantly it does it in a decentralised way. Creating true 2 (or more) factor authentication/ authorisation schemes can improve dramatically personal security to a point where 3rd party wallet services will become a thing of the past. Succeeding in that will mean the next billion non technical bitcoin users will have a platform to use securely and a base line for building cool services on top. Alon Muroch bitcoinauthenticator.org -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJUwAGjAAoJEGxwq/inSG8CJoAIAMDR0h40IhFQNa8BW4AFeKUR 7tg84e752c7wY153GY/P7MOFL6w3E9h4tXzxdohTMMfF5Q6Ip6HaaifYmMpegFSS WEHK0a3C2F+4sQMmMBtWbfyPsG5sJYtldY5hboSbh/6vXJJLXLSd+Sz3WHYx1Qjs qn6sw5CA2Q0fborTxcsNZixUXD/OF5tTjDozp+KfnZ0imvBoKfhfJFlaNUXNon7U zdPfahOrRIM5o70pjo6VwoutKRXr49JIoi47r9Uc3ujckUbLA5CVBApj4FApayb5 sXk8Ks+p6IvBr6Q0ycxXOKmPwbSALC5pLa7Ncb1MFFBGzxKFsMjoRwOLTXHlLUE= =WgO4 -END PGP SIGNATURE- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/1/20 19:35, Pieter Wuille wrote: Hello everyone, Comments/criticisms are very welcome, but I'd prefer keeping the discussion here on the mailinglist (which is more accessible than on the gist). Nice paper, Pieter. I do have a bit of feedback. 1)The first sentence of Deployment has a typo. We reuse the double-threshold switchover mechanism from BIP 34, with the same *thresholds*, [] 2)I think the handling of the sighash byte in the comments of IsDERSignature() could use a little tweaking. If you look at CheckSignatureEncoding() in the actual code (src/script/interpreter.cpp in master), it's clear that the sighash byte is included as part of the signature struct, even though it's not part of the actual DER encoding being checked by IsDERSignature(). This is fine. I just think that the code comments in the paper ought to make this point clearer, either in the sighash description, or as a comment when checking the sig size (i.e., size-3 is valid because sighash is included), or both. 3)The paper says a sig with size=0 is correctly coded but is neither valid nor DER. Perhaps this code should be elsewhere in the Bitcoin code? It seems to me that letting a sig pass in IsDERSignature() when it's not actually DER-encoded is incorrect. Thanks. - --- Douglas Roark Senior Developer Armory Technologies, Inc. d...@bitcoinarmory.com PGP key ID: 92ADC0D7 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUv/4vAAoJEGybVGGSrcDXMxkP/1N2lLAloCKdRUpMBLPEZ5jh bJ4reCeqrMy6JetsKSGfGKdAe7kGkeRl6s8dlHYnpUmnODXU9BCku3zHi3+qm8IC GZlwSdSSgmRneP7btPula0CG31o7X2UJiDW/2IOZl6ul8b7LB2L56O+Ew+PNm+at tCfRcpKtq9LYCnRYR0azd4c5YY9/o7zlkpGi8CututzuEa4Rcm92U1extoo2tC/j nzUfbfcQVL0a7JaRU4VYNceYrcG/xSpKPjsEU/F+5IwnUxL/kebz0EDt1kzm+fOE EMUMXyYgoyW5VDFNjxu00PnJUfVNCOXN/N/h9eCdskCL3AtH6xg1kzam5OGvpEZS QDMNSmQl4Zpx5WiATylNkhhzb/8GowamkSFg4SUjBsjpwOTMTIF0Qhnt+DdzwpI2 etxCGds154nL4p/bkulseczwxOZWin9oZxJnCxp40oFl8fva0BwHVx45uMyI61Ko qRJ9Ol0CDoId3h1EMTt4uyoNxrOzgrj8/+V4BBytOAMMmsfD0VgY68xzdywJxYnC jgU99huhwtJpn9QT6JAbgPAaboomu6hDCohV+J+DCCkIiYFk1jxp+FQ4xZDzcKeo gMYpmFefPAxnHvDXf1v1A+Xw8plN6/NREaIpprh7Ep+q/8vYAiwwHfKjubdMkB3D WnTR5YbqyGxc/Pvh9Ncq =C/wj -END PGP SIGNATURE- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell ru...@rustcorp.com.au wrote: // Null bytes at the start of R are not allowed, unless it would otherwise be // interpreted as a negative number. if (lenS 1 (sig[lenR + 6] == 0x00) !(sig[lenR + 7] 0x80)) return false; You mean null bytes at the start of S. Thanks, fixed. -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
I've read this and it looks A-OK to me. Andrew On Tue, Jan 20, 2015 at 07:35:49PM -0500, Pieter Wuille wrote: Hello everyone, We've been aware of the risk of depending on OpenSSL for consensus rules for a while, and were trying to get rid of this as part of BIP 62 (malleability protection), which was however postponed due to unforeseen complexities. The recent evens (see the thread titled OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. on this mailing list) have made it clear that the problem is very real, however, and I would prefer to have a fundamental solution for it sooner rather than later. I therefore propose a softfork to make non-DER signatures illegal (they've been non-standard since v0.8.0). A draft BIP text can be found on: https://gist.github.com/sipa/5d12c343746dad376c80 The document includes motivation and specification. In addition, an implementation (including unit tests derived from the BIP text) can be found on: https://github.com/sipa/bitcoin/commit/bipstrictder Comments/criticisms are very welcome, but I'd prefer keeping the discussion here on the mailinglist (which is more accessible than on the gist). -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew If they had taught a class on how to be the kind of citizen Dick Cheney worries about, I would have finished high school. --Edward Snowden pgpgbq38zIFUD.pgp Description: PGP signature -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/1/21 15:30, Pieter Wuille wrote: Thanks for the comments. I hope I have clarified the text a bit accordingly. You're welcome. All the revisions look good to me. - --- Douglas Roark Senior Developer Armory Technologies, Inc. d...@bitcoinarmory.com PGP key ID: 92ADC0D7 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUwA6WAAoJEGybVGGSrcDXvmEP/A09j4lq2P0RMqrvtwnDQRmH oimbGwC2a/BbpACBegn0cdFYMURFFcec4gHKyvuN7xR4SRsgQ+Djq/KranAMkYbs ZQVFGXRWdZhfsh7bY4zbBUj+H8c8PAsKL0D7S8r4iXviuUimXJXqESUYote9Ylz3 rwjiK3oRiCSMpTMiI3eDjrbQt5HHLw3hKL7W6zTerx64eCaO2JsIn/Pk4Krf9xwd 1ejpyqrK/9s90NPB0Qqieqbgg7WoQYP+ZMzFi5oNxtNrZjlOCNSQKLN0IXqnnMnS +AoB4B5TUGCdLq3Wlo69mhLaLYNaPNHEoGNUwikXqsd5WeqsayuYDl36rI4MLWgB ZBVO6D2BErqdqMTrmUEurubXMb6CCAuFu6iYjO3vucQ0l+7xD7OW/XiK7ZPNFuwj 2fJCjRHjqgDwKlIUF3Gh7BwRrT2iZRoFYWXDVRBMiJpHvs1+U79pQENp4BmQLWE+ xn3gX9r755mVDJL10MFM6jKijgTCGA2hEFjK2Vu1JJMeVSIGaOdEIen2DxS2mqnZ b/t9VDxfbFQRw5pj2zHsvFDGBe7DEhvBSqbNtiPrY5/LITeP8Nt4CZ9PHrYPJV5A ocUx98l1sqy7P0QiYzAEp5tpdjTS17MVNPt84JLJnk7wL+fDRfKKV3A7tI/ziFJe hjW91YNTIrs+ZFLV/HJc =Rjcd -END PGP SIGNATURE- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen gavinandre...@gmail.com wrote: DERSIG BIP looks great to me, just a few nit-picky changes suggested: You mention the DER standard : should link to http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or whatever is best reference for DER). this would simplify avoiding OpenSSL in consensus implementations -- this would make it easier for non-OpenSSL implementations causing opcode failure : I know what you mean by opcode failure, but it might be good to be more explicit. since v0.8.0, and nearly no transactions -- and very few transactions... reducing this avenue for malleability is useful on itself as well : awkward English. How about just This proposal has the added benefit of reducing transaction malleability (see BIP62). Nit addressed, hopefully. -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/1/21 15:37, Gavin Andresen wrote: You mention the DER standard : should link to http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or whatever is best reference for DER). The link you gave is to the 2002 revision. http://www.itu.int/rec/T-REC-X.690-200811-I/en has the latest revision (Nov. 2008) and, AFAIK, is the most visible link to people searching for X.690. That said, X.690 is the definitive DER document (if not exactly the easiest read). A link to it wouldn't hurt. this would simplify avoiding OpenSSL in consensus implementations -- this would make it easier for non-OpenSSL implementations causing opcode failure : I know what you mean by opcode failure, but it might be good to be more explicit. since v0.8.0, and nearly no transactions -- and very few transactions... reducing this avenue for malleability is useful on itself as well : awkward English. How about just This proposal has the added benefit of reducing transaction malleability (see BIP62). These all look good to me. - --- Douglas Roark Senior Developer Armory Technologies, Inc. d...@bitcoinarmory.com PGP key ID: 92ADC0D7 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUwBF8AAoJEGybVGGSrcDXBxcP/j9dKIeXkOvDFgSzON2hmjxT nzpPcxovGt+ds1KqHMtuMm8+Mmc/Z8kOhKWzgQKYlxq8eQayQ4X/DUr97IY248NX udVM6vEp/azPkXLOQnO6POpv8Il6twyuYGvFAHLiYe9k9qMfdSKZetx5xFKVBsuj DhRY2TnWC7/OXNUrT7H5TPHDaGHyXeJ47XSOVjGQ/qxdczIzvmt11amZ/Vn2+uXh Rvz+0CzbpXYaqYB04ZnIv5lxknmjWGbxPdht/SoOly8INehQacWnwUNZJpilKb6x qEpbDGNxW2zHEFgfNHmtr9PCBN8KyiVnTt+VZpNNl7PJCxZiK6uiwyNxsmOBhBtm Hrsvxb9GqEO/6PKesEo+Hi+6hhzzQRC6Xrf85SaFMzw9UjKuuRhstxx7XhudKFkN lBJcxd40G7kWk0Gv+YQmhFUyXUBqloEFGrFlzWniFKaJGzZs5D0JPd83DsPI4RuT 0M63YabL8qplYN8vnyUXabFpzglvQdAFqZS2GsO6zwAeWrqxsojpcEpikj4T+izR W1TzaRDdm5pEaMMxvb6wFIgO32uAjN1a8GrRj+uk5cxuiOuk/C4Ii18FYhqEtDNd Gv80rPxWEOxbCoSqH6igPnySw3ePFLBzgC4eSLBTnqfKYltd8fTeS9wGy47+L1YO qb5K/xlqt+REOdbTGLHi =MNXG -END PGP SIGNATURE- -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
DERSIG BIP looks great to me, just a few nit-picky changes suggested: You mention the DER standard : should link to http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or whatever is best reference for DER). this would simplify avoiding OpenSSL in consensus implementations -- this would make it easier for non-OpenSSL implementations causing opcode failure : I know what you mean by opcode failure, but it might be good to be more explicit. since v0.8.0, and nearly no transactions -- and very few transactions... reducing this avenue for malleability is useful on itself as well : awkward English. How about just This proposal has the added benefit of reducing transaction malleability (see BIP62). -- -- Gavin Andresen -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
On Wed, Jan 21, 2015 at 2:29 PM, Douglas Roark d...@bitcoinarmory.com wrote: Nice paper, Pieter. I do have a bit of feedback. Thanks for the comments. I hope I have clarified the text a bit accordingly. 1)The first sentence of Deployment has a typo. We reuse the double-threshold switchover mechanism from BIP 34, with the same *thresholds*, [] Fixed. 2)I think the handling of the sighash byte in the comments of IsDERSignature() could use a little tweaking. If you look at CheckSignatureEncoding() in the actual code (src/script/interpreter.cpp in master), it's clear that the sighash byte is included as part of the signature struct, even though it's not part of the actual DER encoding being checked by IsDERSignature(). This is fine. I just think that the code comments in the paper ought to make this point clearer, either in the sighash description, or as a comment when checking the sig size (i.e., size-3 is valid because sighash is included), or both. I've renamed the function to IsValidSignatureEncoding, as it is not strictly about DER (it adds a Bitcoin-specific byte, and supports and empty string too). 3)The paper says a sig with size=0 is correctly coded but is neither valid nor DER. Perhaps this code should be elsewhere in the Bitcoin code? It seems to me that letting a sig pass in IsDERSignature() when it's not actually DER-encoded is incorrect. I've expanded the comments about it a bit. -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
I'm really glad to see this proposal. We already treat non-DER signatures as non-standard in btcd and agree that extending them be illegal as a part of a soft fork is a smart and sane thing to do. It's also good to see the explicit use of signature parsing since it matches what we already do as well because we noticed noticed OpenSSL's notion of big numbers (unsigned) didn't agree with Go's (signed). By having the explicit signature scheme and checking clearly called out in a BIP, it greatly lowers the chances of there being any disagreement about what is valid or invalid due to an underlying dependency. +1 On 1/20/2015 6:35 PM, Pieter Wuille wrote: Hello everyone, We've been aware of the risk of depending on OpenSSL for consensus rules for a while, and were trying to get rid of this as part of BIP 62 (malleability protection), which was however postponed due to unforeseen complexities. The recent evens (see the thread titled OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. on this mailing list) have made it clear that the problem is very real, however, and I would prefer to have a fundamental solution for it sooner rather than later. I therefore propose a softfork to make non-DER signatures illegal (they've been non-standard since v0.8.0). A draft BIP text can be found on: https://gist.github.com/sipa/5d12c343746dad376c80 The document includes motivation and specification. In addition, an implementation (including unit tests derived from the BIP text) can be found on: https://github.com/sipa/bitcoin/commit/bipstrictder Comments/criticisms are very welcome, but I'd prefer keeping the discussion here on the mailinglist (which is more accessible than on the gist). signature.asc Description: OpenPGP digital signature -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Hi there, some thoughts in-line: Finally, distributors of consumer wallets can use this research in order to distribute their wallet with policies which may be less prone to Tor-specific attacks. Or leave this out altogether if their audience has different expectations for connecting to Bitcoin. Sure. I guess there will be wallets for all kinds of people in future, sharing a common core that they can customise (this is certainly the vision and general direction for bitcoinj, and it's working out OK). To clarify, my comments above were for mainstream granny-focused wallets. Wallets designed for crypto geeks can and should expose all the knobs to let people run wild. I hear that. But I don't see why mainstream wallets and wallets designed for crypto research should not share a common core. Nor do I understand why having a common core for different types of wallets should be reserved for BitcoinJ. When Bitcoin was pretty new, having a less customizable core did probably have more of a merit in order to achieve network stability through monoculture. But as of today, Bitcoin has proven itself as being capable of allowing a variety of client application to run on the network, so why should the reference implementation not reflect this kind of diversity? The policy the mainstream distribution imposes upon the core can still be rather restrictive. One possible direction to go is to use Tor for writing to the network and use general link encryption and better Bloom filtering for reading it. Thus new transactions would pop out of Tor exits, but there isn't much they can do that's malicious there except mutate them or block them entirely. If you insert the same transaction into the P2P network via say 10 randomly chosen exits, the worst a malicious mutator can do is race the real transaction and that's no different to a malicious P2P node. Even in a world where an attacker has DoS-banned a lot of nodes and now controls your TX submission path entirely, it's hard to see how it helps them. It might deserve some research in order to determine how Tor's privacy guarantees might be impacted if we allow attackers to mess around with exit node choices in a rather predictable and low-cost manner. Unfortunately, I can't think of another (non-Bitcoin) application which puts Tor to a similar test. The nice thing about the above approach is that it solves the latency problems. Startup speed is really an issue for reading from the network: just syncing the block chain is already enough of a speed hit without adding consensus sync as well. But if you're syncing the block chain via the clearnet you can connect to Tor in parallel so that by the time the user has scanned a QR code, verified the details on the screen and then pressed the Pay button, you have a warm connection and can upload the TX through that. It reduces the level of startup time optimisation needed, although Tor consensus download is still too slow even to race a QR code scan at the moment. I think tuning the consensus caching process and switching to a fresh one on the fly might be the way to go. I do agree that hybrid clearnet/Tor approaches come with interesting performance properties. When BIP70 is in use, you wouldn't write the tx to the network yourself but you could download the PaymentRequest and upload the Payment message via an SSLd Tor connection to the merchant. Then malicious exits can only DoS you but not do anything else so there's no need for multiple exit paths simultaneously. BIP70 is interesting, indeed, although I still fail to understand why (according to the specs I saw) the PaymentRequest message is signed, but not the Payment message. But in context of the discussed protocol issues, I think it just moves the issue from the payer to the payee, so it may or may not partially relieve network-related issues, depending on the usage scenario. Best regards, Isidor -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
Pieter Wuille pieter.wui...@gmail.com writes:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
on this mailing list) have made it clear that the problem is very
real, however, and I would prefer to have a fundamental solution for
it sooner rather than later.
OK, I worked up a clearer (but more verbose) version with fewer
magic numbers. More importantly, feel free to steal the test cases.
One weirdness is the restriction on maximum total length, rather than a
32 byte (33 with 0-prepad) limit on signatures themselves.
Apologies for my babytalk C++. Am sure there's a neater way.
/* Licensed under Creative Commons zero (public domain). */
#include vector
#include cstdlib
#include cassert
#ifdef CLARIFY
bool ConsumeByte(const std::vectorunsigned char sig, size_t off,
unsigned int val)
{
if (off = sig.size()) return false;
val = sig[off++];
return true;
}
bool ConsumeTypeByte(const std::vectorunsigned char sig, size_t off,
unsigned int t)
{
unsigned int type;
if (!ConsumeByte(sig, off, type)) return false;
return (type == t);
}
bool ConsumeNonZeroLength(const std::vectorunsigned char sig, size_t off,
unsigned int len)
{
if (!ConsumeByte(sig, off, len)) return false;
// Zero-length integers are not allowed.
return (len != 0);
}
bool ConsumeNumber(const std::vectorunsigned char sig, size_t off,
unsigned int len)
{
// Length of number should be within signature.
if (off + len sig.size()) return false;
// Negative numbers are not allowed.
if (sig[off] 0x80) return false;
// Zero bytes at the start are not allowed, unless it would
// otherwise be interpreted as a negative number.
if (len 1 (sig[off] == 0x00) !(sig[off+1] 0x80)) return false;
// Consume number itself.
off += len;
return true;
}
// Consume a DER encoded integer, update off if successful.
bool ConsumeDERInteger(const std::vectorunsigned char sig, size_t off) {
unsigned int len;
// Type byte must be integer
if (!ConsumeTypeByte(sig, off, 0x02)) return false;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Now the BE encoded value itself.
if (!ConsumeNumber(sig, off, len)) return false;
return true;
}
bool IsValidSignatureEncoding(const std::vectorunsigned char sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
[sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It cannot start with
any
// null bytes, unless the first byte that follows is 0x80 or higher, in
which
// case a single null byte is required.
// * S-length: 1-byte length descriptor of the S value that follows.
// * S: arbitrary-length big-endian encoded S value. The same rules apply.
// * sighash: 1-byte value indicating what data is hashed.
// Accept empty signature as correctly encoded (but invalid) signature,
// even though it is not strictly DER.
if (sig.size() == 0) return true;
// Maximum size constraint.
if (sig.size() 73) return false;
size_t off = 0;
// A signature is of type compound.
if (!ConsumeTypeByte(sig, off, 0x30)) return false;
unsigned int len;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Make sure the length covers the rest (except sighash).
if (len + 1 != sig.size() - off) return false;
// Check R value.
if (!ConsumeDERInteger(sig, off)) return false;
// Check S value.
if (!ConsumeDERInteger(sig, off)) return false;
// There should exactly one byte left (the sighash).
return off + 1 == sig.size() ? true : false;
}
#else
bool IsValidSignatureEncoding(const std::vectorunsigned char sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
[sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It must use the
shortest
// possible encoding for a positive integers (which means no null bytes
at
// the start, except a single one when the next byte has its highest
bit set).
// * S-length: 1-byte length descriptor of the S value that follows.
// * S: arbitrary-length big-endian encoded S value. The same rules apply.
// * sighash: 1-byte value indicating
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
To be more in the C++ spirit, I would suggest changing the (const
std::vectorunsigned char sig, size_t off) parameters to
(std::vectorunsigned char::const_iterator itr, std::vectorunsigned
char::const_iterator end).
Example:
bool ConsumeNumber(std::vectorunsigned char::const_iterator itr,
std::vectorunsigned char::const_iterator end, unsigned int len)
{
// Length of number should be within signature.
if (itr + len = end) return false;
// Negative numbers are not allowed.
if (*itr 0x80) return false;
// Zero bytes at the start are not allowed, unless it would
// otherwise be interpreted as a negative number.
if (len 1 (*itr == 0x00) !(*(itr + 1) 0x80)) return false;
// Consume number itself.
itr += len;
return true;
}
On Thursday, 22 January 2015, at 11:02 am, Rusty Russell wrote:
Pieter Wuille pieter.wui...@gmail.com writes:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
on this mailing list) have made it clear that the problem is very
real, however, and I would prefer to have a fundamental solution for
it sooner rather than later.
OK, I worked up a clearer (but more verbose) version with fewer
magic numbers. More importantly, feel free to steal the test cases.
One weirdness is the restriction on maximum total length, rather than a
32 byte (33 with 0-prepad) limit on signatures themselves.
Apologies for my babytalk C++. Am sure there's a neater way.
/* Licensed under Creative Commons zero (public domain). */
#include vector
#include cstdlib
#include cassert
#ifdef CLARIFY
bool ConsumeByte(const std::vectorunsigned char sig, size_t off,
unsigned int val)
{
if (off = sig.size()) return false;
val = sig[off++];
return true;
}
bool ConsumeTypeByte(const std::vectorunsigned char sig, size_t off,
unsigned int t)
{
unsigned int type;
if (!ConsumeByte(sig, off, type)) return false;
return (type == t);
}
bool ConsumeNonZeroLength(const std::vectorunsigned char sig, size_t off,
unsigned int len)
{
if (!ConsumeByte(sig, off, len)) return false;
// Zero-length integers are not allowed.
return (len != 0);
}
bool ConsumeNumber(const std::vectorunsigned char sig, size_t off,
unsigned int len)
{
// Length of number should be within signature.
if (off + len sig.size()) return false;
// Negative numbers are not allowed.
if (sig[off] 0x80) return false;
// Zero bytes at the start are not allowed, unless it would
// otherwise be interpreted as a negative number.
if (len 1 (sig[off] == 0x00) !(sig[off+1] 0x80)) return false;
// Consume number itself.
off += len;
return true;
}
// Consume a DER encoded integer, update off if successful.
bool ConsumeDERInteger(const std::vectorunsigned char sig, size_t off) {
unsigned int len;
// Type byte must be integer
if (!ConsumeTypeByte(sig, off, 0x02)) return false;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Now the BE encoded value itself.
if (!ConsumeNumber(sig, off, len)) return false;
return true;
}
bool IsValidSignatureEncoding(const std::vectorunsigned char sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
[sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It cannot start with
any
// null bytes, unless the first byte that follows is 0x80 or higher,
in which
// case a single null byte is required.
// * S-length: 1-byte length descriptor of the S value that follows.
// * S: arbitrary-length big-endian encoded S value. The same rules apply.
// * sighash: 1-byte value indicating what data is hashed.
// Accept empty signature as correctly encoded (but invalid) signature,
// even though it is not strictly DER.
if (sig.size() == 0) return true;
// Maximum size constraint.
if (sig.size() 73) return false;
size_t off = 0;
// A signature is of type compound.
if (!ConsumeTypeByte(sig, off, 0x30)) return false;
unsigned int len;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Make sure the length covers the rest (except sighash).
if (len + 1 != sig.size() - off) return false;
// Check R value.
if
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
Seems like a good change to me.
On Wed, Jan 21, 2015 at 7:32 PM, Rusty Russell ru...@rustcorp.com.au
wrote:
Pieter Wuille pieter.wui...@gmail.com writes:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
on this mailing list) have made it clear that the problem is very
real, however, and I would prefer to have a fundamental solution for
it sooner rather than later.
OK, I worked up a clearer (but more verbose) version with fewer
magic numbers. More importantly, feel free to steal the test cases.
One weirdness is the restriction on maximum total length, rather than a
32 byte (33 with 0-prepad) limit on signatures themselves.
Apologies for my babytalk C++. Am sure there's a neater way.
/* Licensed under Creative Commons zero (public domain). */
#include vector
#include cstdlib
#include cassert
#ifdef CLARIFY
bool ConsumeByte(const std::vectorunsigned char sig, size_t off,
unsigned int val)
{
if (off = sig.size()) return false;
val = sig[off++];
return true;
}
bool ConsumeTypeByte(const std::vectorunsigned char sig, size_t off,
unsigned int t)
{
unsigned int type;
if (!ConsumeByte(sig, off, type)) return false;
return (type == t);
}
bool ConsumeNonZeroLength(const std::vectorunsigned char sig, size_t
off,
unsigned int len)
{
if (!ConsumeByte(sig, off, len)) return false;
// Zero-length integers are not allowed.
return (len != 0);
}
bool ConsumeNumber(const std::vectorunsigned char sig, size_t off,
unsigned int len)
{
// Length of number should be within signature.
if (off + len sig.size()) return false;
// Negative numbers are not allowed.
if (sig[off] 0x80) return false;
// Zero bytes at the start are not allowed, unless it would
// otherwise be interpreted as a negative number.
if (len 1 (sig[off] == 0x00) !(sig[off+1] 0x80)) return
false;
// Consume number itself.
off += len;
return true;
}
// Consume a DER encoded integer, update off if successful.
bool ConsumeDERInteger(const std::vectorunsigned char sig, size_t off)
{
unsigned int len;
// Type byte must be integer
if (!ConsumeTypeByte(sig, off, 0x02)) return false;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Now the BE encoded value itself.
if (!ConsumeNumber(sig, off, len)) return false;
return true;
}
bool IsValidSignatureEncoding(const std::vectorunsigned char sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
[sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It cannot start
with any
// null bytes, unless the first byte that follows is 0x80 or
higher, in which
// case a single null byte is required.
// * S-length: 1-byte length descriptor of the S value that follows.
// * S: arbitrary-length big-endian encoded S value. The same rules
apply.
// * sighash: 1-byte value indicating what data is hashed.
// Accept empty signature as correctly encoded (but invalid) signature,
// even though it is not strictly DER.
if (sig.size() == 0) return true;
// Maximum size constraint.
if (sig.size() 73) return false;
size_t off = 0;
// A signature is of type compound.
if (!ConsumeTypeByte(sig, off, 0x30)) return false;
unsigned int len;
if (!ConsumeNonZeroLength(sig, off, len)) return false;
// Make sure the length covers the rest (except sighash).
if (len + 1 != sig.size() - off) return false;
// Check R value.
if (!ConsumeDERInteger(sig, off)) return false;
// Check S value.
if (!ConsumeDERInteger(sig, off)) return false;
// There should exactly one byte left (the sighash).
return off + 1 == sig.size() ? true : false;
}
#else
bool IsValidSignatureEncoding(const std::vectorunsigned char sig) {
// Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
[sighash]
// * total-length: 1-byte length descriptor of everything that follows,
// excluding the sighash byte.
// * R-length: 1-byte length descriptor of the R value that follows.
// * R: arbitrary-length big-endian encoded R value. It must use the
shortest
// possible encoding for a positive integers (which means no null
bytes at
// the start, except a single one when the next byte
Re: [Bitcoin-development] [softfork proposal] Strict DER signatures
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock b...@mattwhitlock.name wrote: To be more in the C++ spirit, I would suggest changing the (const std::vectorunsigned char sig, size_t off) parameters to (std::vectorunsigned char::const_iterator itr, std::vectorunsigned char::const_iterator end). I agree that is more in the spirit of C++, but part of the motivation for including C++ code that it mostly matches the exact code that has been used in the past two major Bitcoin Core releases (to interpret signatures as standard). -- Pieter -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why Bitcoin is and isn't like the Internet
Bitcoin has a major crossroad ahead regarding a suitable platform for the average non technical main stream user. Until now the majority of the available solutions were at two extremes, or DIY your security and privacy *OR* let a 3rd party service do it for you. The DIY solution is obviously not scalable, but it seems that 3rd party solutions are not scalable as well. If we compare for a second a 3rd party services with traditional banks, it seems banks have two major advantages over them. Entry costs for creating a bank are HUGE so a priori very few people can actually create such a service, second, their physical and IT security infrastructure are heavily regulated which insures a minimum of security level to the end user (and even so money is stolen frequently). Entry costs and regulation do not exist in the bitcoin space, meaning two programers in their spare time can create a wallet/ platform and the non technical end user cannot know if his money is safe, did they hire the right security expert, did they invest enough in protecting and backing up his keys, etc. Many services tried to tackle those problems with multisig (2 of 2 and 2 of 3) to create a syntactical 2 factor authentication/ authorisation mechanism but in reality those solutions didn't really increase security and their failure point is always a single device. Coupling those said problems with the fact that bitcoin transactions are irreversible and are a scarce commodity, trying to insure them the way our money is insured by the government when we deposit it in the bank becomes a huge problem. Premiums will be very high and will only grow as the appetite of hackers to steal coins increase. I personally believe we have the tools for creating a platform that is both secure and private but most importantly it does it in a decentralised way. Creating true 2 (or more) factor authentication/ authorisation schemes can improve dramatically personal security to a point where 3rd party wallet services will become a thing of the past. Succeeding in that will mean the next billion non technical bitcoin users will have a platform to use securely and a base line for building cool services on top. Alon Muroch bitcoinauthenticator.org -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
