Re: [Bitcoin-development] Wallet nLockTime best practices
I'll implement it in breadwallet (oss SPV wallet, hopefully about to be in the app store) if other wallet authors are planning to. Aaron https://github.com/voisine/breadwallet There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, Jun 6, 2014 at 12:00 PM, Jeff Garzik wrote: > We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340 > "Discourage fee sniping with nLockTime" > > Comments from other wallet implementors in particular are welcomed. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ASIC-proof mining
Agreed. If the POW is most efficient on general purpose CPUs, that means Intel, AMD and maybe IBM would be the only entities capable of producing competitive mining equipment. Aaron Aaron Voisine breadwallet.com On Fri, Jul 4, 2014 at 11:39 AM, Ron Elliott wrote: > I feel everyone should re-read that last paragraph as it carries the most > weight IMO. > > > On Fri, Jul 4, 2014 at 9:50 AM, kjj wrote: >> >> Just some general comments on this topic/discussion. >> >> I suspect that there exist no algorithms which cannot be done better in >> an application-specific device than in a general purpose computer. And >> if there is such a thing, then it must necessarily perform best on one >> specific platform, making that platform the de facto application >> specific device. >> >> I'm not sure how one would go about proving or disproving that, but it >> seems very likely to be true. >> >> IO-bound is exactly the same as memory bound, for devices that have >> enough memory. 20 GB is already trivial today, and you don't really get >> into ask-the-wife-for-permission money until you cross 128 GB. The >> exception would be if the IO was to an oracle outside of the device's >> control, and artificially limited in throughput. Such a centralized >> oracle would be contrary to the goals usually stated by people thinking >> about anti-ASIC designs, so there isn't much point. >> >> Keeping the algorithm simple, and ASIC-easy, has one other advantage. >> Just about anyone can sit down and design an ASIC for SHA, for example, >> leading to diversity in the marketplace. A harder algorithm can still >> be made into an ASIC (or more generally into an ASD), but will require >> more skilled designers, more expensive fabrication, etc. This actually >> concentrates the ASIC advantage into the hands of fewer people, which >> again, is contrary to the stated goals. >> >> >> -- >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community >> Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > -- > - Ron > end of line. > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Protocol Specification
I wrote down a really short description in code comments for breadwallet, based on what I figured out: https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPeer.m#L318 Aaron Voisine breadwallet.com On Tue, Jul 8, 2014 at 1:04 PM, Matt Whitlock wrote: > Is anyone working on a similar specification document for Satoshi's P2P > protocol? I know how blocks and transactions are structured and verified, > but I'm interested in knowing how they're communicated over the network. > > -- > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Self-dependency transaction question...
I believe tx have to be ordered sequentially within a block. Also since a tx is referenced by it's hash, it's practically impossible to make a self referential tx. Aaron Voisine breadwallet.com On Sun, Jul 13, 2014 at 4:32 PM, Richard Moore wrote: > Hey all, > > I'm working on the UTXO database for my Python implementation of bitcoind > and have found a situation I did not realize was valid, but since it seems > to be, had a quick question. > > If you look at block #546 the 4th transaction's first input uses its own > block's 3rd transaction as an input. > https://blockchain.info/block/5a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6 > > My question is, would the other way be valid, that is, could the 3rd > transaction of a block, use the 4th transaction from the same block as an > input? Or are transactions processed strictly top to bottom? > > Thanks, > RicMoo > > P.S. If it is valid, another question; what would happen if a transaction > was self-referencing? I realize it would be very difficult to find one, but > if I could find a transaction X whose input was X and had an output Y, would > Y be a new valid utxo, without being a generation transaction input? > > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º> > > Richard Moore ~ Founder > Genetic Mistakes Software inc. > phone: (778) 882-6125 > email: ric...@geneticmistakes.com > www: http://GeneticMistakes.com > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck® > Code Sight™ - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck® Code Sight™ - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
If the user creates a password on an iOS device with an astral character and then can't enter that password on a JVM wallet, that sucks. If JVMs really can't support unicode NFC then that's a strong case to limit the spec to the subset of unicode that all popular platforms can support, but it sounds like it might just be a JVM string library bug that could hopefully be reported and fixed. I get the same result as in the test case using apple's CFStringNormalize(passphrase, kCFStringNormalizationFormC); Aaron Voisine breadwallet.com On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn wrote: > Yes, we know, Andreas' code is indeed doing normalisation. > > However it appears the output bytes end up being different. What I get back > is: > > cf930001303430300166346139 > > vs > > cf9300f0909080f09f92a9 > > from the spec. > > I'm not sure why. It appears this is due to the character from the astral > planes. Java is old and uses 16 bit characters internally - it wouldn't > surprise me if there's some weirdness that means it doesn't/won't support > this kind of thing. > > I recommend instead that any implementation that wishes to be compatible > with JVM based wallets (I suspect Android is the same) just refuse any > passphrase that includes characters outside the BMP. At least unless someone > can find a fix. I somehow doubt this will really hurt anyone. > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 38 NFC normalisation issue
If I first remove \u, so the non-normalized passphrase is "\u03D2\u0301\U00010400\U0001F4A9", and then NFC normalize it, it becomes "\u03D3\U00010400\U0001F4A9" UTF-8 encoded this is: 0xcf93f0909080f09f92a9 (not the same as what you got, Andreas!) Encoding private key: 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 with this passphrase, I get a BIP38 key of: 6PRW5o9FMb4hAYRQPmgcvVDTyDtr6R17VMXGLmvKjKVpGkYhBJ4uYuR9wZ I recommend rather than simply removing control characters from the password that instead the spec require that passwords containing control characters are invalid. We don't want people trying to be clever and putting them in thinking they are adding to the password entropy. Also for UI compatibility across many platforms, I'm also in favor disallowing any character below U+0020 (space) I can submit a PR once we figure out why Andreas's passphrase was different than what I got. Aaron Voisine breadwallet.com On Wed, Jul 16, 2014 at 4:04 AM, Andreas Schildbach wrote: > Damn, I just realized that I implement only the decoding side of BIP38. > So I cannot propose a complete test vector. Here is what I have: > > > Passphrase: ϓ␀𐐀💩 (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK > UPSILON WITH HOOK, COMBINING ACUTE ACCENT, NULL, DESERET CAPITAL LETTER > LONG I, PILE OF POO) > > Passphrase bytes after removing ISO control characters and NFC > normalization: 0xcf933034303066346139 > > Bitcoin Address: 16ktGzmfrurhbhi6JGqsMWf7TyqK9HNAeF > > Unencrypted private key (WIF): > 5Jajm8eQ22H3pGWLEVCXyvND8dQZhiQhoLJNKjYXk9roUFTMSZ4 > > > Can someone calculate the encrypted key from it (using whatever > implementation) and I will verify it decodes properly in bitcoinj? > > > > On 07/16/2014 12:46 PM, Andreas Schildbach wrote: >> I will change the bitcoinj implementation and propose a new test vector. >> >> >> >> On 07/16/2014 11:29 AM, Mike Hearn wrote: >>> Yes sorry, you're right, the issue starts with the null code point. >>> Python seems to have problems starting there too. It might work if we >>> took that out. >>> >>> >>> On Wed, Jul 16, 2014 at 11:17 AM, Andreas Schildbach >>> mailto:andr...@schildbach.de>> wrote: >>> >>> Guys, you are always talking about the Unicode astral plane, but in fact >>> its a plain old (ASCII) control character where this problem starts and >>> likely ends: \u. >>> >>> Let's ban/filter ISO control characters and be done with it. Most >>> control characters will never be enterable by any keyboard into a >>> password field. Of course I assume that Character.isISOControl() works >>> consistently across platforms. >>> >>> >>> http://docs.oracle.com/javase/7/docs/api/java/lang/Character.html#isISOControl%28char%29 >>> >>> >>> On 07/16/2014 12:23 AM, Aaron Voisine wrote: >>> > If the user creates a password on an iOS device with an astral >>> > character and then can't enter that password on a JVM wallet, that >>> > sucks. If JVMs really can't support unicode NFC then that's a strong >>> > case to limit the spec to the subset of unicode that all popular >>> > platforms can support, but it sounds like it might just be a JVM >>> > string library bug that could hopefully be reported and fixed. I get >>> > the same result as in the test case using apple's >>> > CFStringNormalize(passphrase, kCFStringNormalizationFormC); >>> > >>> > Aaron Voisine >>> > breadwallet.com <http://breadwallet.com> >>> > >>> > >>> > On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn >> <mailto:m...@plan99.net>> wrote: >>> >> Yes, we know, Andreas' code is indeed doing normalisation. >>> >> >>> >> However it appears the output bytes end up being different. What >>> I get back >>> >> is: >>> >> >>> >> cf930001303430300166346139 >>> >> >>> >> vs >>> >> >>> >> cf9300f0909080f09f92a9 >>> >> >>> >> from the spec. >>> >> >>> >> I'm not sure why. It appears this is due to the character from >>> the astral >>> >> planes. Java is old and uses 16 bit characters internally - it >>> wouldn't >>> >> surprise me if
Re: [Bitcoin-development] Small update to BIP 62
> 9. New signatures by the sender I'm not suggesting it be required, but it would be possible to mitigate this one by requiring that all signatures deterministically generate k per RFC6979. I'm using this in breadwallet. Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 1:56 PM, Wladimir wrote: > On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote: >> The rationale doesn't seem to apply to rule #4, what's so special about that >> one? > >> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig >> invalidates it. > > Having non-push operations in the scriptSig is a source of > malleability, as there can be multiple sequences of opcodes that > evaluate to the same result. > > Wladimir > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
Well, you could always create a transaction with a different signature hash, say, by changing something trivial like nLockTime, or changing the order of inputs or outputs. Is that what you're talking about? Or is there some sophistry I'm ignorant of having to do with the elliptic curve math in the signature itself? Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 6:28 PM, Gregory Maxwell wrote: > On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine wrote: >>> 9. New signatures by the sender >> >> I'm not suggesting it be required, but it would be possible to >> mitigate this one by requiring that all signatures deterministically >> generate k per RFC6979. I'm using this in breadwallet. > > Nope. > > Your homework assignment is to explain why. :) -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
Ah, good point. For some reason I was thinking the k value was generated only from the hash being signed, but it's derived from both the private key and the hash, so as you say there's no way for the verifier to tell if the scheme is being followed. Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 11:56 PM, Gregory Maxwell wrote: > On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote: >> Well, you could always create a transaction with a different signature >> hash, say, by changing something trivial like nLockTime, or changing >> the order of inputs or outputs. Is that what you're talking about? Or >> is there some sophistry I'm ignorant of having to do with the elliptic >> curve math in the signature itself? > > No, though thats true too. I was talking about the properties of the DSA > nonce: > > An attacker is not obligated to follow your protocol unless you can > prevent him. You can _say_ use derandomized DSA all you like, but he > can just not do so, there is no (reasonable) way to prove you're using > a particular nonce generation scheme without revealing the private key > in the process. The verifier cannot know the nonce or he can trivially > recover your private key thus he can't just repeat the computation > (well, plus if you're using RFC6979 the computation includes the > private key), so short of a very fancy ZKP (stuff at the forefront of > cryptographic/computer science) or precommiting to a nonce per public > key (e.g. single use public keys), you cannot control how a DSA nonce > was generated in the verifier in a way that would prevent equivalent > but not identical signatures. > > (I believe there was some P.O.S. altcoin that was vulnerable because > of precisely the above too— thinking specifying a deterministic signer > would prevent someone from grinding signatures to improve their mining > odds... there are signature systems which are naturally > randomness-free: most hash based signatures and pairing short > signatures are two examples that come to mind... but not DSA, schnorr, > or any of their derivatives). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Small update to BIP 62
Thanks g.maxwell, your explanation of *why* you can't just generate k in a way that the verifier can duplicate is really helpful. This also servers as a great illustration why engineers should never try to designing their own crypto protocols! I knew enough to know not try that at least. Aaron Voisine breadwallet.com On Fri, Jul 18, 2014 at 11:56 PM, Gregory Maxwell wrote: > On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine wrote: >> Well, you could always create a transaction with a different signature >> hash, say, by changing something trivial like nLockTime, or changing >> the order of inputs or outputs. Is that what you're talking about? Or >> is there some sophistry I'm ignorant of having to do with the elliptic >> curve math in the signature itself? > > No, though thats true too. I was talking about the properties of the DSA > nonce: > > An attacker is not obligated to follow your protocol unless you can > prevent him. You can _say_ use derandomized DSA all you like, but he > can just not do so, there is no (reasonable) way to prove you're using > a particular nonce generation scheme without revealing the private key > in the process. The verifier cannot know the nonce or he can trivially > recover your private key thus he can't just repeat the computation > (well, plus if you're using RFC6979 the computation includes the > private key), so short of a very fancy ZKP (stuff at the forefront of > cryptographic/computer science) or precommiting to a nonce per public > key (e.g. single use public keys), you cannot control how a DSA nonce > was generated in the verifier in a way that would prevent equivalent > but not identical signatures. > > (I believe there was some P.O.S. altcoin that was vulnerable because > of precisely the above too— thinking specifying a deterministic signer > would prevent someone from grinding signatures to improve their mining > odds... there are signature systems which are naturally > randomness-free: most hash based signatures and pairing short > signatures are two examples that come to mind... but not DSA, schnorr, > or any of their derivatives). -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
The upcoming release of breadwallet uses the height of the blockchain to enforce timed pin code lockouts for preventing an attacker from quickly making multiple pin guesses. This prevents them changing the devices system time to get around the lockout period. Aaron On Thursday, July 24, 2014, Ron OHara wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I thought I should shortcut my research by asking a direct question here. > > As I understand it, the blockchain actually provides an extra piece of > reliable data that is not being exploited by applications. > > Which data? The time. In this case 'the time' as agreed by >50% of > the participants, where those participants have a strong financial > incentive to keep that 'time' fairly accurate. (+/- about 10 minutes) > > Is this a reasonable understanding of 'time'? ... aka timestamps on the > block > > Ok... 'time' on the blockchain could be 'gamed' ... but with great > difficulty. An application presented with a fake blockchain can use > quite a few heuristics to test the 'validity' of the block chain. > It can review the usual cryptographic proofs, and check that difficulty > is growing/declining only in a realistic manner up to the most recent > block. Even use some arbitrary test like difficulty > 10,000,000,000 > ... on the presumption that any less means that the Bitcoin system has > failed massively from where it currently is and has become an unreliable > time source. > > Reliable 'time' has been impossible up until now - because you need to > trust the time source, and that can always be faked. Using the > blockchain as an approximate time source gives you a world wide > consensus without direct trust of any player. > > So if this presumption is correct, then we can now build time capsule > applications that can not be tricked into exposing their contents too > early by running them in a virtual environment with the wrong system time. > > Is this right? or did miss I something fundamental? > > Ron > > - -- > public identify: https://www.onename.io/ron_ohara > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.20 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJT0a9sAAoJEAla1VT1+xc2ONQH/0R09guSNNCxP36KziAjfcBc > JEhxMpIlqTTYEvNXaBmuPy4BN+IZQ9izgrW/cvlEJJNMmc5/VIBk83WZltmDwcKl > oo4MIdmp6vz984GWToyyLcLSEDT60UE9Hhe+U9RyF5J9kwbN8Uy4ozUHhFVP/0EL > q4O1V6ggPbHWgH4q8m8E9qWOlIFXCDgCjxpL8Ptxsk+UlBq2NWMiwTz6Tbc9KOB4 > hOffzXCZV+DkwjFZD2Rc4rHaxw1yLuYr7DzmzwZbhRQclv9tZt9hoVaAT+RQpE1k > X7pi+zVzeMMng0bzUv8t/G+gq0gaelyV41MJQRparEXhnuYkgU7rAPKIQEG8qpc= > =T5fw > -END PGP SIGNATURE- > > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Aaron Voisine breadwallet.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
It's based on the block height, not the block's timestamp. If you have access to the device and the phone itself is not pin locked, then you can jailbreak it and get access to the wallet seed that way. A pin locked device however is reasonably secure as the filesystem is hardware aes encrypted to a combination of pin+uuid. This was just an easy way to prevent multiple pin guesses by changing system time in settings, so that isn't the weakest part of the security model. Aaron Voisine breadwallet.com On Thu, Jul 24, 2014 at 8:21 PM, William Yager wrote: > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell > wrote: >> >> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise >> this sounds like security theater I attach a debugger to the >> process (or modify the program) and ignore the block sourced time. >> > > It's an iOS application. I would imagine it is substantially more difficult > to attach to a process (which, at the very least, requires root, and perhaps > other things on iOS) than to convince the device to change its system time. > > That said, the security benefits might not be too substantial. > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
The problem is if someone moves system time forward between app launches. The lockout period doesn't have to be all that precise, it just makes you wait for the next block, then 5, then 25, and so on. Using a well known time server over https would also be a good option, but the wallet app already has the chain height anyway. On Friday, July 25, 2014, Mike Hearn wrote: > Given that the speed at which the block chain advances is kind of > unpredictable, I'd think it might be better to just record the time to disk > when a PIN attempt is made and if you observe time going backwards, refuse > to allow more attempts until it's advanced past the previous attempt. > > > On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine > wrote: > >> It's based on the block height, not the block's timestamp. If you have >> access to the device and the phone itself is not pin locked, then you >> can jailbreak it and get access to the wallet seed that way. A pin >> locked device however is reasonably secure as the filesystem is >> hardware aes encrypted to a combination of pin+uuid. This was just an >> easy way to prevent multiple pin guesses by changing system time in >> settings, so that isn't the weakest part of the security model. >> >> Aaron Voisine >> breadwallet.com >> >> >> On Thu, Jul 24, 2014 at 8:21 PM, William Yager > > wrote: >> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell > > >> > wrote: >> >> >> >> >> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise >> >> this sounds like security theater I attach a debugger to the >> >> process (or modify the program) and ignore the block sourced time. >> >> >> > >> > It's an iOS application. I would imagine it is substantially more >> difficult >> > to attach to a process (which, at the very least, requires root, and >> perhaps >> > other things on iOS) than to convince the device to change its system >> time. >> > >> > That said, the security benefits might not be too substantial. >> > >> > >> -- >> > Want fast and easy access to all the code in your enterprise? Index and >> > search up to 200,000 lines of code with a free copy of Black Duck >> > Code Sight - the same software that powers the world's largest code >> > search on Ohloh, the Black Duck Open Hub! Try it now. >> > http://p.sf.net/sfu/bds >> > ___ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists.sourceforge.net >> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > >> >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > -- Aaron Voisine breadwallet.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Time
Yes, if the wallet isn't up to date yet, it uses the highest estimated block height from connected peers, but that could be gamed by controlling the network. The app has blockchain checkpoints in it though, so you couldn't truncate the chain starting point below that. The worst case is that you get a 4-5 extra guesses, but as I mentioned, it'd be easier to just jailbreak the phone if the phone itself isn't using a system wide pin lock. I just though it was a fun and convenient way to prevent the system time hack. The system pin is what protects your wallet in the event of physical theft, and the app pin is just for when you lend your phone to a friend for a few minutes. Aaron Voisine breadwallet.com On Fri, Jul 25, 2014 at 9:22 AM, Natanael wrote: > Probably because the network isn't designed for interactive proofs. Most > interactive algoritms AFAICT requires that some machine holds a secret state > (or at least continuous and untampered state, but you still need to verify > you're falling to the right machine), otherwise the machine can be mimicked > and "rewound" to earlier states. Without a challenge-response that can't be > faked, you've got problems. > > There's no trusted machines here that you can rely on. The certainty of > having the right blockchain is a statistical one over longer periods of > time, not enough for a PIN you want verified right now. So you can always be > shown an old copy, and if your node isn't up to date yet then it can also be > shown fake chains further into the future. > > Maybe you could throw in some kind of Secure Multiparty Computation among > the miners to enable challenge-response, with state saved in the blockchain > (so it can't be rolled back), but that would be fragile. How do you select > what nodes may participate? How do you prevent the secret state from > leaking? And performance would be absolutely horrible, and reliability is a > huge problem. > > Den 25 jul 2014 18:03 skrev "Mike Hearn" : > >> Sorry, you're right. I'd have hoped a delay that doubles on failure each >> time up to some max would be good enough, relying on the p2p network to >> unlock a PIN feels weird, but I can't really quantify why or what's wrong >> with it so I guess it's just me :-) >> >> >> On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine wrote: >>> >>> The problem is if someone moves system time forward between app launches. >>> The lockout period doesn't have to be all that precise, it just makes you >>> wait for the next block, then 5, then 25, and so on. Using a well known time >>> server over https would also be a good option, but the wallet app already >>> has the chain height anyway. >>> >>> >>> On Friday, July 25, 2014, Mike Hearn wrote: >>>> >>>> Given that the speed at which the block chain advances is kind of >>>> unpredictable, I'd think it might be better to just record the time to disk >>>> when a PIN attempt is made and if you observe time going backwards, refuse >>>> to allow more attempts until it's advanced past the previous attempt. >>>> >>>> >>>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine >>>> wrote: >>>>> >>>>> It's based on the block height, not the block's timestamp. If you have >>>>> access to the device and the phone itself is not pin locked, then you >>>>> can jailbreak it and get access to the wallet seed that way. A pin >>>>> locked device however is reasonably secure as the filesystem is >>>>> hardware aes encrypted to a combination of pin+uuid. This was just an >>>>> easy way to prevent multiple pin guesses by changing system time in >>>>> settings, so that isn't the weakest part of the security model. >>>>> >>>>> Aaron Voisine >>>>> breadwallet.com >>>>> >>>>> >>>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager >>>>> wrote: >>>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell >>>>> > >>>>> > wrote: >>>>> >> >>>>> >> >>>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise >>>>> >> this sounds like security theater I attach a debugger to the >>>>> >> process (or modify the program) and ignore the block sourced time. >>>>> >> >>>>> > >>>>> > It'
Re: [Bitcoin-development] BIP72 amendment proposal
Are there any circumstances where the payment request object might be served over a different domain than the CNAME of the object's signer? BIP72 states "Bitcoin wallets must support fetching PaymentRequests via http and https protocols;". If the request object is signed by the owner of the domain, then the worst an attacker who doesn't have the signing key can do is replace the request with another validly signed request intended for someone else, but that could be the attacker's own product order, tricking someone else into paying for it. Should BIP72 require that signed payment requests be from the same domain, and also require https? Aaron Aaron Voisine breadwallet.com On Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn wrote: > Putting aside the question of necessity for a moment, a more efficient > approach to this would be; > > Add another marker param like &s to the end of the URL > Add another field to PaymentRequest that contains an ECC signature > calculated using the public key that hashes to the address in the URI > Upgraded wallets look for the additional param and if it's there, expect to > find the PaymentDetails signed with the address key. PKI signing of course > is still useful to provide an actual identity for receipts, display on > hardware wallets, dispute mediation etc. > > This adds only a few characters to a normal backwards-compatible QR code, > and is not hard to implement. > > > On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn wrote: >>> >>> That way we leave up to implementers to experiment with different >>> lengths and figure out what the optimum is >> >> >> Ah, that's a good suggestion if we do go this way. > > > > -- > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] SPV clients and relaying double spends
There was some discussion of having nodes relay double-spends in order to alert the network about double spend attempts. A lot more users will be using SPV wallets in the future, and one of the techniques SPV clients use to judge how likely a transaction is to be confirmed is if it propagates across the network. I wonder if and when double-spend relaying is introduced, if nodes should also send BIP61 reject messages or something along those lines to indicate which transactions those nodes believe to be invalid, but are relaying anyway. This would be subject to sybil attacks, as is monitoring propagation, however it does still increase the cost of performing a 0 confirmation double spend attack on an SPV client above just relaying double-spends without indicating if a node believes the transaction to be valid. Aaron Voisine breadwallet.com -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV clients and relaying double spends
Something like that would be a great help for SPV clients that can't detect double spends on their own. (still limited of course to sybil attack concerns) Aaron Voisine breadwallet.com On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock wrote: > What's to stop an attacker from broadcasting millions of spends of the same > output(s) and overwhelming nodes with slower connections? Might it be a > better strategy not to relay the actual transactions (after the first) but > rather only propagate (once) some kind of double-spend alert? > > > On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote: >> There was some discussion of having nodes relay double-spends in order >> to alert the network about double spend attempts. >> >> A lot more users will be using SPV wallets in the future, and one of >> the techniques SPV clients use to judge how likely a transaction is to >> be confirmed is if it propagates across the network. I wonder if and >> when double-spend relaying is introduced, if nodes should also send >> BIP61 reject messages or something along those lines to indicate which >> transactions those nodes believe to be invalid, but are relaying >> anyway. >> >> This would be subject to sybil attacks, as is monitoring propagation, >> however it does still increase the cost of performing a 0 confirmation >> double spend attack on an SPV client above just relaying double-spends >> without indicating if a node believes the transaction to be valid. >> >> Aaron Voisine >> breadwallet.com > -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SPV clients and relaying double spends
Of course you wouldn't want nodes to propagate alerts without independently verifying them, otherwise anyone could just issue alerts for every new transaction. Aaron Voisine breadwallet.com On Thu, Sep 25, 2014 at 7:16 PM, Matt Whitlock wrote: > Probably the first double-spend attempt (i.e., the second transaction to > spend the same output(s) as another tx already in the mempool) would still > need to be relayed. A simple "double-spend alert" wouldn't work because it > could be forged. But after there have been two attempts to spend the same > output, no further transactions spending that same output should be relayed, > in order to prevent flooding the network. > > > On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote: >> Something like that would be a great help for SPV clients that can't >> detect double spends on their own. (still limited of course to sybil >> attack concerns) >> >> Aaron Voisine >> breadwallet.com >> >> >> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock >> wrote: >> > What's to stop an attacker from broadcasting millions of spends of the >> > same output(s) and overwhelming nodes with slower connections? Might it be >> > a better strategy not to relay the actual transactions (after the first) >> > but rather only propagate (once) some kind of double-spend alert? >> > >> > >> > On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote: >> >> There was some discussion of having nodes relay double-spends in order >> >> to alert the network about double spend attempts. >> >> >> >> A lot more users will be using SPV wallets in the future, and one of >> >> the techniques SPV clients use to judge how likely a transaction is to >> >> be confirmed is if it propagates across the network. I wonder if and >> >> when double-spend relaying is introduced, if nodes should also send >> >> BIP61 reject messages or something along those lines to indicate which >> >> transactions those nodes believe to be invalid, but are relaying >> >> anyway. >> >> >> >> This would be subject to sybil attacks, as is monitoring propagation, >> >> however it does still increase the cost of performing a 0 confirmation >> >> double spend attack on an SPV client above just relaying double-spends >> >> without indicating if a node believes the transaction to be valid. >> >> >> >> Aaron Voisine >> >> breadwallet.com >> > -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core
This is great Pieter. I was able to sync the entire blockchain from scratch in a little over 4 hours on a laptop over cable modem. :) No issues to report. Even my family photos are intact! This makes it practical to run a full node, part time on a laptop again. Aaron Voisine breadwallet.com On Sat, Oct 11, 2014 at 4:34 PM, Pieter Wuille wrote: > Hi all, > > I believe that a large change that I've been working on for Bitcoin > Core is ready for review and testing: headers-first synchronization. > In short, it changes the way the best chain is discovered, downloaded > and verified, with several advantages: > * Parallel block downloading (much faster sync on typical network > connections). > * No more stalled downloads. > * Much more robust against unresponsive or slow peers. > * Removes a class of DoS attacks related to peers feeding you > low-difficulty valid large blocks on a side branch. > * Reduces the need for checkpoints in the code. > * No orphan blocks stored in memory anymore (reducing memory usage during > sync). > * A major step step towards an SPV mode using the reference codebase. > > Historically, this mode of operation has been known for years (Greg > Maxwell wrote up a description of a very similar method in > https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync > in early 2012, but it was known before that), but it took a long time > to refactor these code enough to support it. > > Technically, it works by replacing the single-peer blocks download by > a single-peer headers download (which typically takes seconds/minutes) > and verification, and simultaneously fetching blocks along the best > known headers chain from all peers that are known to have the relevant > blocks. Downloading is constrained to a moving window to avoid > unbounded unordering of blocks on disk (which would interfere with > pruning later). > > At the protocol level, it increases the minimally supported version > for peers to 31800 (corresponding to bitcoin v3.18, released in > december 2010), as earlier versions did not support the getheaders P2P > message. > > So, the code is available as a github pull request > (https://github.com/bitcoin/bitcoin/pull/4468), or packaged on > http://bitcoin.sipa.be/builds/headersfirst, where you can also find > binaries to test with. > > Known issues: > * At the very start of the sync, especially before all headers are > processed, downloading is very slow due to a limited number of blocks > that are requested per peer simultaneously. The policies around this > will need some experimentation can certainly be improved. > * Blocks will be stored on disk out of order (in the order they are > received, really), which makes it incompatible with some tools or > other programs. Reindexing using earlier versions will also not work > anymore as a result of this. > * The block index database will now hold headers for which no block is > stored on disk, which earlier versions won't support. If you are fully > synced, it may still be possible to go back to an earlier version. > > Unknown issues: > * Who knows, maybe it will replace your familiy pictures with Nyan > Cat? Use at your own risk. > > TL;DR: Review/test https://github.com/bitcoin/bitcoin/pull/4468 or > http://bitcoin.sipa.be/builds/headersfirst. > > -- > Pieter > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://p.sf.net/sfu/Zoho > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ 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
Ultimately the only way to insure bitcoin holdings is with an insurer who themselves holds enough bitcoin to cover replacement of insured funds. In the existing insurance industry, this is handled through a system of re-insurance, where smaller firms are themselves insured against catastrophic events that might cause a large number of simultaneous claims. At the top of the chain sits super-cat insurance firms like Berkshire Hathaway who do actually have the reserves to pay out in case of such a super catastrophy. This is one of the most lucrative businesses in the world, and one that today's very large bitcoin holders will find themselves uniquely positioned to engage in as bitcoin grows into a major global currency. Aaron Voisine breadwallet.com On Tue, Jan 20, 2015 at 10:07 PM, 21E14 <21x...@gmail.com> wrote: > This is a response to a wonderfully insightful recent post by Joichi Ito, > the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board > Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the > Internet" and asked a most pertinent question: "Whether there is an ICANN > equivalent needed for Bitcoin." As suggested in recent posts to the mailing > list, I believe there might be, but for a reason that may not seem obvious > at first. > > Alan Reiner expressed the need this way: "I think one of the biggest issues > facing Bitcoin right now is not the lack of a 'killer app.' It is lack of > insurance options. Early adopters would like to believe that the majority of > users will hold their own Bitcoin, but I believe that is not a realistic > option when life-changing quantities of Bitcoin are involved. We should not > trust Grandma to secure her own retirement savings via complicated computer > maneuvers. More to the point, she should not trust herself or anyone else > (sic!) to hold it unless there is a strong protection against loss events. > Right now the solution is for Grandma to avoid keeping her money in Bitcoin. > Bitcoin needs a strong backbone of insured storage options so that Grandma > can confidently participate in this new technology." This is certainly an > observation to take heed of coming from the founder of Armory Technologies. > > The protection against loss events ought to be understood in the broadest > sense. What is needed is a disaster recovery mechanism. Andreas Antonopoulos > remarks expressed this candidly last year: "Bitcoin doesn't have a middle of > the road mediocre growth model. It basically either dies, because of a > fundamental flaw in the Bitcoin system. Not an external factor, an internal > factor: We blow it up by accident. And that could happen... Bitcoin will > play out in the next three years. In the next three years we're going to see > Bitcoin arrive on the global stage and make a substantial impact, both in > financial terms and in political terms. It will happen. Or it will die. > Either way. I'm not sure. In which case we'll reboot another currency." > > A body, not entirely unlike ICANN, can manage the nexus to the physical > world, and help address Bitcoin's catastrophic failure modes. Bitcoin's coin > ownership protocol would thus join the ranks of its payment protocol, coin > issuance protocol, consensus mechanism and inflation control that pose no > lethal threat to the ecosystem. In addition to their coin-agnostic nature, I > suspect the high valuation of large Bitcoin hubs relative to Bitcoin's > market cap at this stage in its lifecycle is partly reflective of the > sneaking suspicion that a custodial bitcoin (a bitcoin attached to an > identity) may be worth more than a non-custodial one. With this in mind, > I'll pitch in for the ticket should Dr. Ito decide to join the next month's > DevCore Boston conference aimed at supporting the future development of > Bitcoin. It's an hour's walk from MIT after all. > > -- > 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 > -- 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. Cho
Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
>> However, I don't think we should base >> bitcoin around what Apple wants us to do. They've already had their war >> on bitcoin. They are going to do whatever they can to protect their NFC >> based payment system. We need to make their platform the the less >> desirable one if they are going to play the game that way. If that means >> an Airbitz like proposal is implemented as a fallback, maybe that is >> fine and POS systems need to support both, but I just don't think we >> should limit what we can do because of Apple's products capabilities. > > Ack on Airbitz, and ack on our relationship to Apple (-: I also agree we shouldn't limit specs to Apple product capabilities. If history is any indication, NFC will be opened up to developers in iOS 9, just like touch id in was in iOS 8, and bluetooth LE in iOS 5, one major OS revision after the hardware capability is first introduced. Also, I'm pretty sure that Apple doesn't care about bitcoin at all. When they banned wallets from the app store, it was prior to the 2013 FinCEN guidance. At the time many of us, myself included, assumed USG would take the same stance with bitcoin as they did against e-gold. It wasn't clear at all that bitcoin didn't violate legal tender laws or who knows what. When Apple allowed wallets back in, it was just weeks before Apple pay launched. It's seems clear that bitcoin is too small for them to be concerned about in the slightest. Aaron Voisine co-founder and CEO breadwallet.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
I'm not convinced that wallet seed interoperability is such a great thing. There is a wide variability in the quality and security level of wallet implementations and platforms. Each new device and wallet software a user types their seed into increases their attack surface and exposure to flaws. Their security level is reduced to the lowest common denominator. I see the need for a "fire exit", certainly, but we must also remember that fire exits are potential entrances for intruders. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell wrote: > On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe > wrote: > > i guess you look at the glass half full :) > > even though what you say is true, we should aim for wallets not to > > require those instructions, by standardizing these things in BIPs. > > let's hope bitcoin doesn't fail in standards as our industries have in > > the past... > > There are genuine principled disagreements on how some things should > be done. There are genuine differences in functionality. > > We cannot expect and should not expect complete compatibility. If you > must have complete compatibility: use the same software (or maybe not > even then, considering how poor the forward compatibility of some > things has been..). > > What we can hope to do, and I think the best we can hope to do, is to > minimize the amount of gratuitous incompatibility and reduce the > amount of outright flawed constructions (so if there are choices which > must be made, they're at least choices among relatively good options). > > > -- > 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] Electrum 2.0 has been tagged
On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle wrote: > > BIP39 is beautiful. meh... the fact that you can't derive the seed phrase from the wallet seed, and that the password key stretching is so weak as to be ineffectual security theater bugs me. Feels like a pretty big compromise to work on current generation low power embedded devices when the next generation will be more than capable. But I understand the motivation for the compromise. Aaron Voisine co-founder and CEO breadwallet.com -- 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] Criminal complaints against "network disruption as a service" startups
Thanks Jan, we added several additional checks for non-standard protocol responses, and also made the client revert to DNS seeding more quickly if it runs into trouble, so it's now more robust against sybil/DOS attack. I mentioned in the coindesk article that I didn't think what your nodes were doing was intended to be malicious with respect to network disruption. It's our job to better handle non-standard or even malicious behavior from random p2p nodes. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Mar 16, 2015 at 1:44 AM, Jan Møller wrote: > What we were trying to achieve was determining the flow of funds between > countries by figuring out which country a transaction originates from. > To do that with a certain accuracy you need many nodes. We chose a class C > IP range as we knew that bitcoin core and others only connect to one node > in any class C IP range. We were not aware that breadwallet didn't follow > this practice. Breadwallet risked getting tar-pitted, but that was not our > intention and we are sorry about that. > > Our nodes DID respond with valid blocks and merkle-blocks and allowed > everyone connecting to track the blockchain. We did however not relay > transactions. The 'service' bit in the version message is not meant for > telling whether or how the node relays transactions, it tells whether you > can ask for block headers only or full blocks. > > Many implementations enforce non standard rules for handling transactions; > some nodes ignore transactions with address reuse, some nodes happily > forward double spends, and some nodes forward neither blocks not > transactions. We did blocks but not transactions. > > In hindsight we should have done two things: > 1. relay transactions > 2. advertise address from 'foreign' nodes > > Both would have fixed the problems that breadwallet experienced. My > understanding is that breadwallet now has the same 'class C' rule as > bitcoind, which would also fix it. > > Getting back on the topic of this thread and whether it is illegal, your > guess is as good as mine. I don't think it is illegal to log incoming > connections and make statistical analysis on it. That would more or less > incriminate anyone who runs a web-server and looks into the access log. > At lease one Bitcoin service has been collecting IP addresses for years > and given them to anyone visiting their web-site (you know who) and I > believe that this practise is very wrong. We have no intention of giving IP > addresses away to anyone, but we believe that you are free to make > statistics on connection logs when nodes connect to you. > > On a side note: When you make many connections to the network you see lots > of strange nodes and suspicious patterns. You can be certain that we were > not the only ones connected to many nodes. > > My takeaway from this: If nodes that do not relay transactions is a > problem then there is stuff to fix. > > /Jan > > On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn wrote: > >> That would be rather new and tricky legal territory. >> >> But even putting the legal issues to one side, there are definitional >> issues. >> >> For instance if the Chainalysis nodes started following the protocol >> specs better and became just regular nodes that happen to keep logs, would >> that still be a violation? If so, what about blockchain.info? It'd be >> shooting ourselves in the foot to try and forbid block explorers given how >> useful they are. >> >> If someone non-maliciously runs some nodes with debug logging turned on, >> and makes full system backups every night, and keeps those backups for >> years, are they in violation of whatever pseudo-law is involved? >> >> I think it's a bit early to think about these things right now. Michael >> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be >> interested to know their thoughts on all of this. >> >> >> -- >> 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] Block Size Increase
As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal. The best argument I've heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users' experience. When users pay too low a fee, they should: 1) See immediate failure as they do now with fees that fail to propagate. 2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future. The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future. We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach. Aaron Voisine co-founder and CEO breadwallet.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
This is a clever way to tie block size to fees. I would just like to point out though that it still fundamentally is using hard block size limits to enforce scarcity. Transactions with below market fees will hang in limbo for days and fail, instead of failing immediately by not propagating, or seeing degraded, long confirmation times followed by eventual success. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 8, 2015 at 1:33 PM, Mark Friedenbach wrote: > It is my professional opinion that raising the block size by merely > adjusting a constant without any sort of feedback mechanism would be a > dangerous and foolhardy thing to do. We are custodians of a multi-billion > dollar asset, and it falls upon us to weigh the consequences of our own > actions against the combined value of the entire bitcoin ecosystem. Ideally > we would take no action for which we are not absolutely certain of the > ramifications, with the information that can be made available to us. But > of course that is not always possible: there are unknown-unknowns, time > pressures, and known-unknowns where information has too high a marginal > cost. So where certainty is unobtainable, we must instead hedge against > unwanted outcomes. > > The proposal to raise the block size now by redefining a constant carries > with it risk associated with infrastructure scaling, centralization > pressures, and delaying the necessary development of a constraint-based fee > economy. It also simply kicks the can down the road in settling these > issues because a larger but realistic hard limit must still exist, meaning > a future hard fork may still be required. > > But whatever new hard limit is chosen, there is also a real possibility > that it may be too high. The standard response is that it is a soft-fork > change to impose a lower block size limit, which miners could do with a > minimal amount of coordination. This is however undermined by the > unfortunate reality that so many mining operations are absentee-run > businesses, or run by individuals without a strong background in bitcoin > protocol policy, or with interests which are not well aligned with other > users or holders of bitcoin. We cannot rely on miners being vigilant about > issues that develop, as they develop, or able to respond in the appropriate > fashion that someone with full domain knowledge and an objective > perspective would. > > The alternative then is to have some sort of dynamic block size limit > controller, and ideally one which applies a cost to raising the block size > in some way the preserves the decentralization and/or long-term stability > features that we care about. I will now describe one such proposal: > > * For each block, the miner is allowed to select a different difficulty > (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, > and this miner-selected difficulty is used for the proof of work check. In > addition to adjusting the hashcash target, selecting a different difficulty > also raises or lowers the maximum block size for that block by a function > of the difference in difficulty. So increasing the difficulty of the block > by an additional 25% raises the block limit for that block from 100% of the > current limit to 125%, and lowering the difficulty by 10% would also lower > the maximum block size for that block from 100% to 90% of the current > limit. For simplicity I will assume a linear identity transform as the > function, but a quadratic or other function with compounding marginal cost > may be preferred. > > * The default maximum block size limit is then adjusted at regular > intervals. For simplicity I will assume an adjustment at the end of each > 2016 block interval, at the same time that difficulty is adjusted, but > there is no reason these have to be aligned. The adjustment algorithm > itself is either the selection of the median, or perhaps some sort of > weighted average that respects the "middle majority." There would of course > be limits on how quickly the block size limit can adjusted in any one > period, just as there are min/max limits on the difficulty adjustment. > > * To prevent perverse mining incentives, the original difficulty without > adjustment is used in the aggregate work calculations for selecting the > most-work chain, and the allowable miner-selected adjustment to difficulty > would have to be tightly constrained. > > These rules create an incentive environment where raising the block size > has a real cost associated with it: a more difficult hashcash target for > the same subsidy reward. For rational miners that cost must be > counter-balanced by additional fees provided in the larger block. This > allows block size to increase, but only within the confines of a
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
That's fair, and we've implemented child-pays-for-parent for spending unconfirmed inputs in breadwallet. But what should the behavior be when those options aren't understood/implemented/used? My argument is that the less risky, more conservative default fallback behavior should be either non-propagation or delayed confirmation, which is generally what we have now, until we hit the block size limit. We still have lots of safe, non-controversial, easy to experiment with options to add fee pressure, causing users to economize on block space without resorting to dropping transactions after a prolonged delay. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach wrote: > On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine wrote: > >> This is a clever way to tie block size to fees. >> >> I would just like to point out though that it still fundamentally is >> using hard block size limits to enforce scarcity. Transactions with below >> market fees will hang in limbo for days and fail, instead of failing >> immediately by not propagating, or seeing degraded, long confirmation times >> followed by eventual success. >> > > There are already solutions to this which are waiting to be deployed as > default policy to bitcoind, and need to be implemented in other clients: > replace-by-fee and child-pays-for-parent. > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
> increasing the block size is simply not a solution, it's just kicking > the can down the road (while reducing the incentives to deploy real > solutions like payment channels). Placing hard limits on blocksize is not the right solution. There are still plenty of options to be explored to increase fees, resulting in users voluntarily economizing on block space. It's premature to resort to destroying the reliability of propagated transaction getting into blocks. Child-pays-for-parent is useful, but requires the recipient to spend inputs upon receipt, consuming even more block space. Replace-by-fee may also help, but users won't know the fee they are getting charged until after the fact, and it will make worse all the problems that tx malleability causes today. We have $3billion plus of value in this system to defend. The safe, conservative course is to increase the block size. Miners already have an incentive to find ways to encourage higher fees and we can help them with standard recommended propagation rules and hybrid priority/fee transaction selection for blocks that increases confirmation delays for low fee transactions. Aaron Voisine co-founder and CEO breadwallet.com On Wed, May 13, 2015 at 5:11 PM, Jorge Timón wrote: > On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen > wrote: > > I think long-term the chain will not be secured purely by proof-of-work. > I > > think when the Bitcoin network was tiny running solely on people's home > > computers proof-of-work was the right way to secure the chain, and the > only > > fair way to both secure the chain and distribute the coins. > > > > See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some > > half-baked thoughts along those lines. I don't think proof-of-work is the > > last word in distributed consensus (I also don't think any alternatives > are > > anywhere near ready to deploy, but they might be in ten years). > > Or never, nobody knows at this point. > > > I also think it is premature to worry about what will happen in twenty or > > thirty years when the block subsidy is insignificant. A lot will happen > in > > the next twenty years. I could spin a vision of what will secure the > chain > > in twenty years, but I'd put a low probability on that vision actually > > turning out to be correct. > > I think is very healthy to worry about that since we know it's > something that will happen. > The system should work without subsidies. > > > That is why I keep saying Bitcoin is an experiment. But I also believe > that > > the incentives are correct, and there are a lot of very motivated, smart, > > hard-working people who will make it work. When you're talking about > trying > > to predict what will happen decades from now, I think that is the best > you > > can (honestly) do. > > Lightning payment channels may be a new idea, but payment channels are > not, and nobody is using them. > They are the best solution to scalability we have right now, > increasing the block size is simply not a solution, it's just kicking > the can down the road (while reducing the incentives to deploy real > solutions like payment channels). > > Not worrying about 10 years in the future but asking people to trust > estimates and speculations about how everything will burn in 2 years > if we don't act right now seems pretty arbitrary to me. > One could just as well argue that there's smart hard-working people > that will solve those problems before they hit us. > > It is true that the more distant the future you're trying to predict > is, the more difficult it is to predict it, but any threshold that > separates "relevant worries" from "too far in the future to worry > about it" will always be arbitrary. > Fortunately we don't need to all share the same time horizon for what > is worrying and what is not. > What we need is a clear criterion for what is acceptable for a > hardfork and a general plan to deploy them: > > -Do all the hardfork changes need to be uncontroversial? How do we > define uncontroversial? > -Should we maintain and test implementation of hardfork whises that > seem too small to justify a hardfork on their own (ie time travel fix, > allowing to sign inputs values...) to also deploy them at the same > time that other more necessary hardforks? > > I agree that hardforks shouldn't be impossible and in that sense I'm > glad that you started the hardfork debate, but I believe we should be > focusing on that debate rather than the block size one. > Once we have a clear criteria, hopefully the block size debate should > become less noisy and more pro
Re: [Bitcoin-development] Long-term mining incentives
Conservative is a relative term. Dropping transactions in a way that is unpredictable to the sender sounds incredibly drastic to me. I'm suggesting increasing the blocksize, drastic as it is, is the more conservative choice. I would recommend that the fork take effect when some specific large supermajority of the pervious 1000 blocks indicate they have upgraded, as a safer alternative to a simple flag date, but I'm sure I wouldn't have to point out that option to people here. Aaron Voisine co-founder and CEO breadwallet.com On Wed, May 13, 2015 at 5:58 PM, Pieter Wuille wrote: > On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine wrote: > >> We have $3billion plus of value in this system to defend. The safe, >> conservative course is to increase the block size. Miners already have an >> incentive to find ways to encourage higher fees and we can help them with >> standard recommended propagation rules and hybrid priority/fee transaction >> selection for blocks that increases confirmation delays for low fee >> transactions. >> > > You may find that the most economical solution, but I can't understand how > you can call it conservative. > > Suggesting a hard fork is betting the survival of the entire ecosystem on > the bet that everyone will agree with and upgrade to new suggested software > before a flag date. > > -- > Pieter > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
> by people and businesses deciding to not use on-chain settlement. I completely agree. Increasing fees will cause people voluntary economize on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a known, upfront cost... unpredictable transaction failure in most cases will be a far higher, unacceptable cost to the user than the actual fee. The higher the costs of using the system, the lower the adoption as a store-of-value. The lower the adoption as store-of-value, the lower the price, and the lower the value of bitcoin to the world. > That only measures miner adoption, which is the least relevant. I concede the point. Perhaps a flag date based on previous observation of network upgrade rates with a conservative additional margin in addition to supermajority of mining power. Aaron Voisine co-founder and CEO breadwallet.com On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille wrote: > On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote: > >> Conservative is a relative term. Dropping transactions in a way that is >> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting >> increasing the blocksize, drastic as it is, is the more conservative choice. >> > > Transactions are already being dropped, in a more indirect way: by people > and businesses deciding to not use on-chain settlement. That is very sad, > but it's completely inevitable that there is space for some use cases and > not for others (at whatever block size). It's only a "things don't fit > anymore" when you see on-chain transactions as the only means for doing > payments, and that is already not the case. Increasing the block size > allows for more utility on-chain, but it does not fundamentally add more > use cases - only more growth space for people already invested in being > able to do things on-chain while externalizing the costs to others. > > >> I would recommend that the fork take effect when some specific large >> supermajority of the pervious 1000 blocks indicate they have upgraded, as a >> safer alternative to a simple flag date, but I'm sure I wouldn't have to >> point out that option to people here. >> > > That only measures miner adoption, which is the least relevant. The > question is whether people using full nodes will upgrade. If they do, then > miners are forced to upgrade too, or become irrelevant. If they don't, the > upgrade is risky with or without miner adoption. > > -- > Pieter > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
> I concede the point. Perhaps a flag date based on previous observation of network upgrade rates with a conservative additional margin in addition to supermajority of mining power. It occurs to me that this would allow for a relatively small percentage of miners to stop the upgrade if the flag date turns out to be poorly chosen and a large number of non-mining nodes haven't upgraded yet. Would be a nice safety fallback. Aaron Voisine co-founder and CEO breadwallet.com On Wed, May 13, 2015 at 6:31 PM, Aaron Voisine wrote: > > by people and businesses deciding to not use on-chain settlement. > > I completely agree. Increasing fees will cause people voluntary economize > on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a > known, upfront cost... unpredictable transaction failure in most cases will > be a far higher, unacceptable cost to the user than the actual fee. The > higher the costs of using the system, the lower the adoption as a > store-of-value. The lower the adoption as store-of-value, the lower the > price, and the lower the value of bitcoin to the world. > > > That only measures miner adoption, which is the least relevant. > > I concede the point. Perhaps a flag date based on previous observation of > network upgrade rates with a conservative additional margin in addition to > supermajority of mining power. > > > Aaron Voisine > co-founder and CEO > breadwallet.com > > On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille > wrote: > >> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote: >> >>> Conservative is a relative term. Dropping transactions in a way that is >>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting >>> increasing the blocksize, drastic as it is, is the more conservative choice. >>> >> >> Transactions are already being dropped, in a more indirect way: by people >> and businesses deciding to not use on-chain settlement. That is very sad, >> but it's completely inevitable that there is space for some use cases and >> not for others (at whatever block size). It's only a "things don't fit >> anymore" when you see on-chain transactions as the only means for doing >> payments, and that is already not the case. Increasing the block size >> allows for more utility on-chain, but it does not fundamentally add more >> use cases - only more growth space for people already invested in being >> able to do things on-chain while externalizing the costs to others. >> >> >>> I would recommend that the fork take effect when some specific large >>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a >>> safer alternative to a simple flag date, but I'm sure I wouldn't have to >>> point out that option to people here. >>> >> >> That only measures miner adoption, which is the least relevant. The >> question is whether people using full nodes will upgrade. If they do, then >> miners are forced to upgrade too, or become irrelevant. If they don't, the >> upgrade is risky with or without miner adoption. >> >> -- >> Pieter >> >> > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
On Sat, May 16, 2015 at 1:35 PM, Owen Gunden wrote: > > This strikes me as a leap. There are alternatives that still use bitcoin > as the unit of value, such as sidechains, offchain, etc. To say that > these are "not bitcoin" is misleading. > The only options available today and in the near future that I'm aware of are of the centralized custody variety, which is pretty bad in my opinion, but your point is taken. > > Are we sure that raising the block size is the only way to avoid > "unpredictable transaction failure"? If so, and it's as bad as you say > it is, aren't we screwed anyway when we inevitably start hitting the cap > (even if it's raised 10x or 20x)? And if that's the case, then don't we > do a disservice to users by continuing to pretend that we can make this > problem go away? > When we start bumping up against the block size limit, the transactions at the margins will experience failure in a way that will be unpredictable to current wallet software. We can slow blockchain growth by increasing fees alone, without introducing the additional cost of unpredictability around confirmation failure, which when it comes down to it is just another (extreme) way to keep usage low. Instead of fees and unpredictable confirmation, why not just have fees alone. A single, upfront, known cost. > > > On what do you base this? Gold has a very high cost of using (storage, > transport) and yet is perhaps the most widely accepted store of value. > I would argue that the reason gold is not the one world global currency that it once was is because of those costs. That's why people shifted over time to gold backed bank notes and eventually fiat. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
See the "first-seen-safe replace-by-fee" thread Aaron Voisine co-founder and CEO breadwallet.com On Tue, May 26, 2015 at 11:22 AM, Danny Thorpe wrote: > What prevents RBF from being used for fraudulent payment reversals? > > Pay 1BTC to Alice for hard goods, then after you receive the goods > broadcast a double spend of that transaction to pay Alice nothing? Your > only cost is the higher network fee of the 2nd tx. > > Thanks, > -Danny > > On Mon, May 25, 2015 at 5:10 PM, Peter Todd wrote: > >> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: >> > CPFP also solves it just fine. >> >> CPFP is a significantly more expensive way of paying fees than RBF, >> particularly for the use-case of defragmenting outputs, with cost >> savings ranging from 30% to 90% >> >> >> Case 1: CPFP vs. RBF for increasing the fee on a single tx >> -- >> >> Creating an spending a P2PKH output uses 34 bytes of txout, and 148 >> bytes of txin, 182 bytes total. >> >> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to >> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. >> I forget to click on the "priority fee" option, so it goes out with the >> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, >> creating a new transaction t2 that's 192 bytes in size. I want to pay >> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of >> transaction fees. >> >> On the other hand, had I use RBF, my wallet would have simply >> rebroadcast t1 with the change address decreased. The rules require you >> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new >> fee level, or 218uBTC of fees in total. >> >> Cost savings: 48% >> >> >> Case 2: Paying multiple recipients in succession >> >> >> Suppose that after I pay Alice, I also decide to pay Bob for his hard >> work demonstrating cryptographic protocols. I need to create a new >> transaction t2 spending t1's change address. Normally t2 would be >> another 226 bytes in size, resulting in 226uBTC additional fees. >> >> With RBF on the other hand I can simply double-spend t1 with a >> transaction paying both Alice and Bob. This new transaction is 260 bytes >> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth >> consumed broadcasting it, resulting in an additional 36uBTC of fees. >> >> Cost savings: 84% >> >> >> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet >> >> >> The above situation gets even worse with multisig. t1 in the multisig >> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC >> in fees. With RBF we rewrite t1 with an additional output, resulting in >> a 399 byte transaction, with just 36uBTC in additional fees. >> >> Cost savings: 90% >> >> >> Case 4: Dust defragmentation >> >> >> My wallet has a two transaction outputs that it wants to combine into >> one for the purpose of UTXO defragmentation. It broadcasts transaction >> t1 with two inputs and one output, size 340 bytes, paying zero fees. >> >> Prior to the transaction confirming I find I need to spend those funds >> for a priority transaction at the 1mBTC/KB fee level. This transaction, >> t2a, has one input and two outputs, 226 bytes in size. However it needs >> to pay fees for both transactions at once, resulting in a combined total >> fee of 556uBTC. If this situation happens frequently, defragmenting >> UTXOs is likely to cost more in additional fees than it saves. >> >> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 >> bytes in size, paying 374uBTC. Even better, if one of the two inputs is >> sufficiently large to cover my costs I can doublespend t1 with a >> 1-in-2-out tx just 226 bytes in size, paying 226uBTC. >> >> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF >> costs you more than you save >> >> -- >> 'peter'[:-1]@petertodd.org >> 134ce6577d4122094479f548b997baf84367eaf0c190bc9f >> >> >> -- >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
> miners would definitely be squeezing out transactions / putting pressure to increase transaction fees I'd just like to re-iterate that transactions getting "squeezed out" (failure after a lengthy period of uncertainty) is a radical change from the current behavior of the network. There are plenty of avenues to create fee pressure without resorting to such a drastic change in how the network works today. Aaron Voisine co-founder and CEO breadwallet.com On Thu, May 28, 2015 at 8:53 AM, Gavin Andresen wrote: > On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock > wrote: > >> Between all the flames on this list, several ideas were raised that did >> not get much attention. I hereby resubmit these ideas for consideration and >> discussion. >> >> - Perhaps the hard block size limit should be a function of the actual >> block sizes over some trailing sampling period. For example, take the >> median block size among the most recent 2016 blocks and multiply it by 1.5. >> This allows Bitcoin to scale up gradually and organically, rather than >> having human beings guessing at what is an appropriate limit. >> > > A lot of people like this idea, or something like it. It is nice and > simple, which is really important for consensus-critical code. > > With this rule in place, I believe there would be more "fee pressure" > (miners would be creating smaller blocks) today. I created a couple of > histograms of block sizes to infer what policy miners are ACTUALLY > following today with respect to block size: > > Last 1,000 blocks: > http://bitcoincore.org/~gavin/sizes_last1000.html > > Notice a big spike at 750K -- the default size for Bitcoin Core. > This graph might be misleading, because transaction volume or fees might > not be high enough over the last few days to fill blocks to whatever limit > miners are willing to mine. > > So I graphed a time when (according to statoshi.info) there WERE a lot of > transactions waiting to be confirmed: >http://bitcoincore.org/~gavin/sizes_357511.html > > That might also be misleading, because it is possible there were a lot of > transactions waiting to be confirmed because miners who choose to create > small blocks got lucky and found more blocks than normal. In fact, it > looks like that is what happened: more smaller-than-normal blocks were > found, and the memory pool backed up. > > So: what if we had a dynamic maximum size limit based on recent history? > > The average block size is about 400K, so a 1.5x rule would make the max > block size 600K; miners would definitely be squeezing out transactions / > putting pressure to increase transaction fees. Even a 2x rule (implying > 800K max blocks) would, today, be squeezing out transactions / putting > pressure to increase fees. > > Using a median size instead of an average means the size can increase or > decrease more quickly. For example, imagine the rule is "median of last > 2016 blocks" and 49% of miners are producing 0-size blocks and 51% are > producing max-size blocks. The median is max-size, so the 51% have total > control over making blocks bigger. Swap the roles, and the median is > min-size. > > Because of that, I think using an average is better-- it means the max > size will change (up or down) more slowly. > > I also think 2016 blocks is too long, because transaction volumes change > quicker than that. An average over 144 blocks (last 24 hours) would be > better able to handle increased transaction volume around major holidays, > and would also be able to react more quickly if an economically irrational > attacker attempted to flood the network with fee-paying transactions. > > So my straw-man proposal would be: max size 2x average size over last 144 > blocks, calculated at every block. > > There are a couple of other changes I'd pair with that consensus change: > > + Make the default mining policy for Bitcoin Core neutral-- have its > target block size be the average size, so miners that don't care will "go > along with the people who do care." > > + Use something like Greg's formula for size instead of bytes-on-the-wire, > to discourage bloating the UTXO set. > > > - > > When I've proposed (privately, to the other core committers) some dynamic > algorithm the objection has been "but that gives miners complete control > over the max block size." > > I think that worry is unjustified right now-- certainly, until we have > size-independent new block propagation there is an incentive for miners to > keep their blocks small, and we see miners creating small blocks even when > there are fee-paying transactions waiting to be confirmed. >
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
> or achieving less than great DOS protection Right now a bunch of redditors can DOS the network at the cost of a few thousand dollars per day, shared between them. Since the cost of validating transactions is far lower than current minimum relay fees, then increasing the block size increases the cost of DOSing the network. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 29, 2015 at 10:53 AM, Admin Istrator wrote: > What about trying the dynamic scaling method within the 20MB range + 1 > year with a 40% increase of that cap? Until a way to dynamically scale is > found, the cap will only continue to be an issue. With 20 MB + 40% yoy, > we're either imposing an arbitrary cap later, or achieving less than great > DOS protection always. Why not set that policy as a maximum for 2 years as > a protection against the possibility of dynamic scaling abuse, and see what > happens with a dynamic method in the mean time. The policy of Max(1MB, > (average size over previous 144 blocks) * 2) calculated at each block seems > pretty reasonable. > > As an outsider, the real 'median' here seems to be 'keeping the cap as > small as possible while allowing for larger blocks still'.We know > miners will want to keep space in their blocks relatively scarce, but we > also know that doesn't exclude the more powerful miners from > including superfluous transactions to increase their effective share of the > network. I have the luck of not being drained by this topic over the past > three years, so it looks to me as if its two poles of 'block size must > increase' and 'block size must not increase' are forcing what is the clear > route to establishing the 'right' block size off the table. > > --Andrew Len > (sorry if anybody received this twice, sent as the wrong email the first > time around). > > On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen > wrote: > >> What do other people think? >> >> >> If we can't come to an agreement soon, then I'll ask for help >> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a >> big increase now that grows over time so we may never have to go through >> all this rancor and debate again. >> >> I'll then ask for help lobbying the merchant services and exchanges and >> hosted wallet companies and other bitcoind-using-infrastructure companies >> (and anybody who agrees with me that we need bigger blocks sooner rather >> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they >> are running it. We'll be able to see uptake on the network by monitoring >> client versions. >> >> Perhaps by the time that happens there will be consensus bigger blocks >> are needed sooner rather than later; if so, great! The early deployment >> will just serve as early testing, and all of the software already deployed >> will ready for bigger blocks. >> >> But if there is still no consensus among developers but the "bigger >> blocks now" movement is successful, I'll ask for help getting big miners to >> do the same, and use the soft-fork block version voting mechanism to >> (hopefully) get a majority and then a super-majority willing to produce >> bigger blocks. The purpose of that process is to prove to any doubters that >> they'd better start supporting bigger blocks or they'll be left behind, and >> to give them a chance to upgrade before that happens. >> >> >> Because if we can't come to consensus here, the ultimate authority for >> determining consensus is what code the majority of merchants and exchanges >> and miners are running. >> >> >> -- >> -- >> Gavin Andresen >> >> >> -- >> >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
It could be done by agreeing on a data format and encoding it in an op_return output in the coinbase transaction. If it catches on it could later be enforced with a soft fork. For real up-to-the-minute fee calculations you're also going to want to look at the current mempool, how many transactions are waiting, what fees they're paying, etc, but of course that information is susceptible to sybil attack. In practice what we're doing for now is using services like blockcypher who's business is improving reliability of zero-conf to tell us what fee-per-kb is needed, and then putting a hard coded range around it to protect against the service being compromised. This is also the kind of thing being done for exchange rate data which is probably the bigger security risk until bitcoin becomes the standard unit of account for the planet. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox wrote: > [I'm currently wading through bitcoin-development. I'm still about a month > behind, so I apologize in advance for any noisy redundancy in this post.] > > While reading about blocksize, I've just finished Mike Hearn's blog post > describing expected systemic behavior as actual blocks approach the current > limit (with or without non-protocol-changing implementation improvements): > > https://medium.com/@octskyward/crash-landing-f5cc19908e32 > > > One detail Mike uses to argue against the "fee's will save us" line of > reasoning is that wallets have no good way to learn fee information. > > So, here's a proposal to fix that: put fee and (and perhaps block size, > UTXO, etc...) statistics into the locally-verifiable data available to SPV > clients (ie: block headers). > > > It's easy to imagine a hard fork that places details like per-block total > fees, transaction count, fee variance, UTXO delta, etc... in a each block > header. This would allow SPV clients to rely on this data with the same > PoW-backed assurances as all other header data. > > This mechanism seems valuable regardless of the outcome of blocksize > debate. So long as fees are interesting or important, SPV clients should > know about them. (Same for other stats such as UTXO count.) > > Upgrading the protocol without a hard-fork may be possible and is left as > an exercise for the reader. ;-) > > -- > Nathan Wilcox > Least Authoritarian > > email: nat...@leastauthority.com > twitter: @least_nathan > PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
> Sounds plausible, except SPV protocols would need to include this coinbase txn if it's going to help SPV clients. Yes you'd either need a way to add those transactions to the bloom filter, or add/modify a p2p message to request it specifically. > when you mention Sybil attack, I don't quite follow. I just mean that someone could spin up a bunch of malicious p2p nodes that lied about mempool data. It's a bit worse for SPV clients since they can't verify that unconfirmed transactions are valid. > I had previously believed fees were fairly static presently, I actually just added it the other day after getting blockcypher to include it in their api. The current release is still using a hard coded fee rate. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Jun 10, 2015 at 1:00 PM, Nathan Wilcox wrote: > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine wrote: > >> It could be done by agreeing on a data format and encoding it in an >> op_return output in the coinbase transaction. If it catches on it could >> later be enforced with a soft fork. >> >> > Sounds plausible, except SPV protocols would need to include this coinbase > txn if it's going to help SPV clients. (Until a softfork is activated, SPV > clients should not rely on this encoding, since until that time the results > can be fabricated by individual miners.) > > >> For real up-to-the-minute fee calculations you're also going to want to >> look at the current mempool, how many transactions are waiting, what fees >> they're paying, etc, but of course that information is susceptible to sybil >> attack. >> > > Hm, when you mention Sybil attack, I don't quite follow. > > When a client relies on any report of a mempool [*], this is already > outside the realm of locally-verifiable SPV information, so they are > already susceptible to the service making false claims. If that's > acceptable (and in many cases it may be) then this whole mechanism is moot, > because the client can ask the service for fee statistics for past blocks. > > >> In practice what we're doing for now is using services like blockcypher >> who's business is improving reliability of zero-conf to tell us what >> fee-per-kb is needed, and then putting a hard coded range around it to >> protect against the service being compromised. >> > > This is interesting for me, because I had previously believed fees were > fairly static presently, and also because I like hearing about real life > wallet implementations. > > So if this "SPV Fee Stats" feature were added, a wallet might rely on an > API for timely stats (aka "block height < 1") then verify that the API > isn't lying after doing SPV verification of fee stats for confirmed blocks. > > > This is also the kind of thing being done for exchange rate data which is >> probably the bigger security risk until bitcoin becomes the standard unit >> of account for the planet. >> >> > That makes sense, although there's no SPV equivalent for exchange data. > > > Aaron Voisine >> co-founder and CEO >> breadwallet.com >> >> On Wed, Jun 10, 2015 at 10:37 AM, Nathan Wilcox < >> nat...@leastauthority.com> wrote: >> >>> [I'm currently wading through bitcoin-development. I'm still about a >>> month behind, so I apologize in advance for any noisy redundancy in this >>> post.] >>> >>> While reading about blocksize, I've just finished Mike Hearn's blog post >>> describing expected systemic behavior as actual blocks approach the current >>> limit (with or without non-protocol-changing implementation improvements): >>> >>> https://medium.com/@octskyward/crash-landing-f5cc19908e32 >>> >>> >>> One detail Mike uses to argue against the "fee's will save us" line of >>> reasoning is that wallets have no good way to learn fee information. >>> >>> So, here's a proposal to fix that: put fee and (and perhaps block size, >>> UTXO, etc...) statistics into the locally-verifiable data available to SPV >>> clients (ie: block headers). >>> >>> >>> It's easy to imagine a hard fork that places details like per-block >>> total fees, transaction count, fee variance, UTXO delta, etc... in a each >>> block header. This would allow SPV clients to rely on this data with the >>> same PoW-backed assurances as all other header data. >>> >>> This mechanism seems valuable regardless of the outcome of blocksize >>> debate. So long as
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
The other complication is that this will tend to be a lagging indicator based on network congestion from the last time you connected. If we assume that transactions are being dropped in an unpredictable way when blocks are full, knowing the network congestion *right now* is critical, and even then you just have to hope that someone who wants that space more than you do doesn't show up after you disconnect. Aaron Voisine co-founder and CEO breadwallet.com On Wed, Jun 10, 2015 at 1:26 PM, Mike Hearn wrote: > I described an alternative way for SPV wallets to learn about fees some > time ago. It requires a new transaction version that embeds output values > into the signed data. Then an upgrade to the P2P protocol to send UTXO data > along with transactions when they are relayed. > > The idea is that the wallet sets a Bloom filter with an FP rate that > ensures it will see some random subset of all transactions being broadcast > on the network, and with the extra data, it can calculate the fee paid. > Once a transaction broadcast is observed the wallet includes that tx hash > in its next Bloom filter, thus it can see which block the tx confirmed in. > By measuring the amount of time that passed between a broadcast and it > appearing in a block, it can calculate its own tables of fee paid:time > taken. > > This has the advantage that you don't have to trust miners to publish data > accurately. However it requires some protocol upgrades and of course, a lot > of new code in SPV wallets. > > The way Bitcoin Wallet for Android handles fees currently is to just > update a hard coded value every so often. > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
> A Header-PoW-verifying client could still be given all transactions in a recent block, from which it can see the in-band fees directly. You don't know the fees paid by any given transaction unless you also have all it's inputs. Transaction inputs do not include an amount. You could however get the average fee-per-kb paid by all transactions in a block by looking at the coinbase transaction, subtracting the block reward, and dividing by the size of block minus the header. Aaron Voisine co-founder and CEO breadwallet.com On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox wrote: > On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd wrote: > >> On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote: >> > On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine >> wrote: >> > >> > > It could be done by agreeing on a data format and encoding it in an >> > > op_return output in the coinbase transaction. If it catches on it >> could >> > > later be enforced with a soft fork. >> > > >> > > >> > Sounds plausible, except SPV protocols would need to include this >> coinbase >> > txn if it's going to help SPV clients. (Until a softfork is activated, >> SPV >> > clients should not rely on this encoding, since until that time the >> results >> > can be fabricated by individual miners.) >> >> Fee stats can always be fabricated by individual miners because fees can >> be paid out-of-band. >> >> > This is a point I hadn't considered carefully before. I don't understand > the marketplace here or why miners would want to move fees outside of > explicit inband fees. Implicit in this proposal is that the statistics only > cover in-band data, because that's the scope of consensus rules, and thus > the proposal is only as useful as the information of in-band fees is useful. > > I've also noticed a detracting technical argument given a particular > tradeoff: > > A Header-PoW-verifying client could still be given all transactions in a > recent block, from which it can see the in-band fees directly. The > trade-off is the size of those transactions versus the need to alter any > consensus rules or do soft forks. > > Notice how this trade-off's costs change with maximum block size. > > > > >> -- >> 'peter'[:-1]@petertodd.org >> 1245bd2f5c99379ee76836227ded9c08324894faabc0d27f >> > > > > -- > Nathan Wilcox > Least Authoritarian > > email: nat...@leastauthority.com > twitter: @least_nathan > PGP: 11169993 / AAAC 5675 E3F7 514C 67ED E9C9 3BFE 5263 1116 9993 > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism
One possible solution that wallets could adopt when blocks fill up, would be to abandon the p2p network for transaction propagation altogether, and instead work directly with a handful of the largest miners and pools to get transactions into blocks. The miners could auction off space in their blocks with the guarantee that they will be included in the order accepted. We'd lose the peer-to-peer nature of sending transactions for a federated service operator style model, but avoid the problem of unpredictable transaction failure. Also, unlike replace-by-fee, this would allow for a send-and-forget usage pattern, as well as known up-front fees. Something like this is certainly what I imagine the large hosted wallet companies will end up moving to. Aaron On Thursday, June 11, 2015, Mike Hearn wrote: > > Re: "dropped in an unpredictable way" - transactions would be dropped >> > lowest fee/KB first, a completely predictable way. >> >> Quite agreed. > > > No, Aaron is correct. It's unpredictable from the perspective of the user > sending the transaction, and as they are the ones picking the fees, that is > what matters. > -- Aaron Voisine co-founder and CEO breadwallet.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
> > Yes, it does bother (some) people to see the consensus based system > because of the difficulties that can be associated with implementing > it. But that's the way it is. If you don't like consensus based > systems (or decentralized, distributed systems) this is probably the > wrong space for you. > If consensus must be reached to make any changes, that just means that changes of anything more than trivial consequence simply can't be made. Extreme bias toward the status-quo will only work if external factors affecting the network also remain static. Aaron Voisine co-founder and CEO breadwallet.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up, and allow wallet software to continue working with a send-and-forget use pattern, any of these would be enough to avoid the need for an XT only hard-fork. So far BIP100 is the only one that seems to actually be getting any sort of momentum toward consensus, and it was proposed... 2 days ago? When the XT fork was proposed as a last resort, it was when the opponents were (to my understanding) suggesting we just let blocks fill up, and hopefully things would just work out on their own. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman wrote: > Who is actually planning to move to Bitcoin-XT if this happens? > > Just Gavin and Mike? > > [image: image1.JPG] > > On Jun 15, 2015, at 6:17 PM, Faiz Khan wrote: > > I'm quite puzzled by the response myself, it doesn't seem to address some > of the (more serious) concerns that Adam put out, the most important > question that was asked being the one regarding personal ownership of the > proposed fork: > > "How do you plan to deal with security & incident response for the > duration you describe where you will have control while you are deploying > the unilateral hard-fork and being in sole maintainership control?" > > I do genuinely hope that whomever (now and future) wishes to fork the > protocol reconsider first whether they are truly ready to test/flex their > reputation/skills/resources in this way... Intuitively, to me it seems > counterproductive, and I don't fully believe it is within a single > developer's talents to manage the process start-to-finish (as it is > non-trivial to hard-fork successfully, others have rehashed this in other > threads)... > > That being said I think it appropriate if Adam's questions were responded > in-line when Mike is feeling up to it. I think that the answers are > important for the community to hear when such a drastic change is being > espoused. > > Faiz > > On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop wrote: > >> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn wrote: >> >>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be >>> non-technical, stupid, uninformed, etc OK, go ahead and show them the >>> error of their ways. Anyone can write blogs. >>> >> >> I worry that if this is the level of care you take with reading and >> (mis)interpreting Adam's messages, that you might not be taking extreme >> care with evaluating consensus changes, even while tired or sleeping. I >> encourage you to evaluate both messages and source code more carefully, >> especially in the world of bitcoin. However, this goes for everyone and not >> just you. Specifically, when Adam mentioned your conversations with >> non-technical people, he did not mean "Mike has talked with people who have >> possibly not made pull requests to Bitcoin Core, so therefore Mike is a >> non-programmer". Communication is difficult and I can understand that, but >> we really have to be more careful when evaluating each other's messages; >> technical miscommunication can be catastrophic in this context. On the >> topic of whether you are a programmer, I suspect that ever since you built >> CIA.vc we have all known you're a programmer, Mike. >> >> - Bryan >> http://heybryan.org/ >> 1 512 203 0507 >> >> >> -- >> >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> -- >> >> My regards, >> >> Faiz Khan >> >> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> > > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Thanks Alex, the work you've pointed out is helpful. Limiting mempool size should at least prevent nodes from crashing. When I looked a few days ago I only found a few old PRs that seemed to have fallen by the wayside, so this new one is encouraging. I can respond in the PR comments if it's more appropriate there, but I believe ejecting tx from mempools rather than preemptively refusing them according to standard network wide propagation rules will result in spotty, inconsistent tx propagation, and possibly a large increase in tx re-broadcasts, so if those haven't been addressed they will need to be. It would also be prudent to run some simulations to see what other issues are going to pop-up. We're currently using CPFP already in breadwallet when spending unconfirmed non-change inputs. A small percentage of hashing power is using it, but enough to get a transaction unstuck assuming breadwallet's fee calculation is better than the sender's. The problem with RBF is that there's currently no way to tell if your tx has been picked up by miners or not in order to know if you need to replace it. Miners broadcasting partial block solutions would be helpful in this regard, but only for tx in the currently-being-worked-on block, not for tx that won't be picked up until the block after. If miners were to eject tx that were previously being worked on in favor of higher fee tx, then that causes another set of problems for wallets that thought their tx was going to get in but then it doesn't. The other problem with RBF is that users don't know up front what fee they're actually going to pay which is a big blow to real world usability. Also mobile wallets will have to sign lots of tx up front and rely on a service to replace as necessary. And this is all just on the send side. On the receive side it's much worse since you can't rely on the sender to do the replacing. The real problem seems to be the fact that RBF is an interactive iterative process rather than a send-and-forget one. What you really need is some way to tell up-front, is a transaction going to get mined with a high probability? That problem seems really difficult to solve with fixed-size blocks that are full. If the goal is simply to reduce or limit the growth of the blockchain, then there are much simpler solutions, which is why I've advocated for the blocksize increase, followed by tx selection and propagation rule changes to create fee pressure. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos wrote: > Aaron, > > My understanding is that Gavin and Mike are proceeding with the XT fork, I > hope that understanding is wrong. > > As for improving the non-consensus code to handle full blocks more > gracefully. This is something I'm very interested in, block size increase > or not. Perhaps I shouldn't hijack this thread, but maybe there are others > who also believe this would ameliorate some of the time pressure for > deciding on a block size increase. > > What is it that you would like to see improved? > The fee estimation code that is included for 0.11 will give much more > accurate fee estimates, which should allow adding the correct fee to a > transaction to see it likely to be confirmed in a reasonable time. For > further improvements: > - There has recently been attention to overhauling the block creation and > mempool limiting code in such a way that actual outstanding queues to be > included in a block could also be incorporated in fee estimation. See > https://github.com/bitcoin/bitcoin/pull/6281. > - CPFP and RBF are candidates for inclusion in core soon, both of which > could be integrated into transaction processing to handle the edge cases > where a priori fee estimation fails. See > https://github.com/bitcoin/bitcoin/pull/1647 and > https://github.com/bitcoin/bitcoin/pull/6176 > > I know there has been much discussion of fee estimation not working for > SPV clients, but I believe several independent servers which were serving > the estimates from full nodes would go a long way towards allowing that > information to be used by SPV clients even if its not a completely > decentralized solution. See for example > http://core2.bitcoincore.org/smartfee/latest.json > > > > On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine wrote: > >> Wasn't the XT hard fork proposed as a last resort, should the >> bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants >> to go that route. An alternate hard-fork proposal like BIP100 that gets >> consensus, or a modified version of gavin's that ups the limit to 8Mb >> instead of 20Mb, or hell even some major changes to the non-consunsus code >> to make it adequately handle the situation when blocks fill up, an
Re: [Bitcoin-development] The Bitcoin Node Market
We're planning to run our own full nodes to take load off the volunteer network as breadwallet use increases, and also contribute any SPV serving performance optimizations we can make to bitcoin-core. Just want to let people know we share these concerns and have plans to mitigate any negative impact on the network. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene wrote: > > > On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr wrote: > >> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote: >> > Would SPV wallets have to pay to connect to the network too? From the >> > user's perspective, it would be somewhat upsetting (and confusing) to >> see >> > your balance slowly draining every time you open your wallet app. It >> would >> > also tie up outputs every time you open up your wallet. You may go to >> pay >> > for something in a coffee shop, only to find that you can't spend your >> > bitcoin because the wallet had to create a transaction to pay to sync >> with >> > the network. >> > >> > Also, users of centralized wallet services like Coinbase would not have >> to >> > pay that fee; but users of native wallets like breadwallet would have no >> > such option. This incentivizes users to use centralized wallets. >> > >> > So this is kind of imposing a worse user experience on users who want to >> > use bitcoin the "right" way. That doesn't seem like a good thing to me >> :/ >> >> SPV isn't the "right" way either ;) >> > > Hah, fair enough, there is no such thing as the "right" way to do > anything. But I still think punishing users who use SPV wallets is a > less-than-ideal way to incentive people to run full nodes. Right now SPV is > the best way that exists for mobile phones to participate in the network in > a decentralized way. This proposal makes the user experience for mobile > wallets a little more confusing and annoying. > > >> >> If you're running a full node (the real "right way"), you should be able >> to >> earn more bitcoins than you pay out. >> >> Luke >> > > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who > would provide the nodes they would need connect to? The SPV wallet author would if they wanted their wallet to function. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 10:28 PM, wrote: > On 2015-06-16 03:49, Kevin Greene wrote: > > Hah, fair enough, there is no such thing as the "right" way to do > > anything. But I still think punishing users who use SPV wallets is a > > less-than-ideal way to incentive people to run full nodes. Right now > > SPV is > > the best way that exists for mobile phones to participate in the > > network in > > a decentralized way. This proposal makes the user experience for mobile > > wallets a little more confusing and annoying. > > Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who > would provide the nodes they would need connect to? The decentralization > fairy? > > There's absolutely no reason that paying for connectivity would be any > more confusing or annoying than transaction fees are. > > If some full nodes in the network started offering paid connection > slots, that would just mean that users who checked the "pay subscription > fee" box in their wallet configuration would have an easier time > connecting than the users who did't, just like how your transaction > might eventually get mined without a fee but paying one makes it faster > and more probable. > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
With their money, if they were to take advantage of optional additional financial services, like, as one example, comsumer protection insurance. Aaron On Tuesday, June 16, 2015, wrote: > On 2015-06-16 07:55, Aaron Voisine wrote: > >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who >>> would provide the nodes they would need connect to? >>> >> >> The SPV wallet author would if they wanted their wallet to function. >> > > How will the SPV wallet users pay for this service? With their money, or > with their privacy? > -- Aaron Voisine co-founder and CEO breadwallet.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
Alternate funding strategy: With 1billion users, mr roger ver is now among the worlds first $trillionaires, and he generously donates to the non-profit organization responsible for both the wildly popular wallet, and his new found largess. On Tuesday, June 16, 2015, justusranv...@riseup.net < justusranv...@riseup.net> wrote: > On 2015-06-16 07:55, Aaron Voisine wrote: > >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who >>> would provide the nodes they would need connect to? >>> >> >> The SPV wallet author would if they wanted their wallet to function. >> > > How will the SPV wallet users pay for this service? With their money, or > with their privacy? > -- Aaron Voisine co-founder and CEO breadwallet.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
> What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. Aaron Voisine co-founder and CEO breadwallet.com On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach wrote: > What retail needs is escrowed microchannel hubs (what lightning provides, > for example), which enable untrusted instant payments. Not reliance on > single-signer zeroconf transactions that can never be made safe. > > On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson > wrote: > >> I have some experience here. If you are seriously suggesting these >> measures, you might as well kill retail transactions altogether. >> >> In practice, if a retail place starts to accept bitcoin they have a >> similar situation as with cash, only that the fraud potential is much >> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) >> and the fraud frequency is also much lower. >> >> 0-conf concerns were never a problem in practice. except for 2-way atms >> i have never heard of a problem that was caused by double spends. >> while adding these measures is generally positive, requiring them means >> excluding 99.9% of the potential users. so you might as well not do it. >> >> RBF as implemented by F2Pool just flat out lowers Bitcoins utility >> value. So it's a bad thing. >> >> for any online or automated system, waiting for a handful of >> confirmations was always recommended practice. >> >> Am 19.06.2015 um 22:39 schrieb Matt Whitlock: >> > Retail POS merchants probably should not be accepting vanilla Bitcoin >> > payments, as Bitcoin alone does not (and cannot) guarantee the >> > irreversibility of a transaction until it has been buried several >> > blocks deep in the chain. Retail merchants should be requiring a >> > co-signature from a mutually trusted co-signer that vows never to sign >> > a double-spend. >> >> >> >> -- >> >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
We should use relay and default tx selection rules to raise the cost of double spend attacks as far as it is easy and practical to do so. This increases the value of the bitcoin network by making it practical to use in more situations for more people. Merchants of course can't rely on them being cryptographically safe, but the safer they are, the more useful. The argument that since they can't be made perfectly safe, they should be as easy as possible to reverse so that merchants learn not to rely on them, is an incorrect one that reduces the usefulness and value of bitcoin. Merchants will learn very quickly what the costs of accepting bitcoin payments are, and the lower they are, the greater bitcoin merchant adoption will be. Aaron Voisine co-founder and CEO breadwallet.com On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo wrote: > One more thing I would like to add to this thread: I want to make it > unequivocally clear that I believe what is making double-spends easier has > relatively little to do with the protocol and almost everything to do with > poor software and poor security policy on the merchant end. Perhaps it > isn’t prudent to push out changes to the relay policy that make these > exploits even easier right now - but we NEED to be applying some kind of > pressure on the merchant end to upgrade their stuff to be more resilient so > that we have more room for changes on things like relay policy without > significant disruption to the network. > > - Eric Lombrozo > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?
On github I commented on the BIP43 pull request about adding a "purpose" of 0' which would correspond to the BIP32 recommended tree structure for a single account wallet. (m/0'/chain) This will allow for backwards compatibility and interoperability at least for existing single account BIP32 implementations like my own. The only issue is that it would involve a new BIP, and it wouldn't follow the BIP43 recommendation of using the BIP number as the "purpose number", unless I can get BIP0. :) Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, Apr 25, 2014 at 8:49 AM, Mike Hearn wrote: > I generally agree, but I wonder how popular cloning wallets between devices > will be in future. Right now if someone wants to have a wallet shared > between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell > them they're out of luck and they need to pick one, or split their funds up > manually. > > But probably a lot of people would like to use different UI's to access the > same wallets. Sharing key trees is a part of that, though full blown wallet > metadata sync would also be needed. > > So I guess we're going to end up with some kind of fairly complex > compatibility matrix. But I agree it may be unavoidable. > > -- > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
I'm also a big fan of standardizing on microBTC as the standard unit. I didn't like the name "bits" at first, but the more I think about it, the more I like it. The main thing going for it is the fact that it's part of the name bitcoin. If Bitcoin is the protocol and network, bits are an obvious choice for the currency unit. I would like to propose using Unicode character U+0180, lowercase b with stroke, as the symbol to represent the microBTC denomination, whether we call bits or something else: http://www.fileformat.info/info/unicode/char/0180/index.htm Another candidate is Unicode character U+2422, the blank symbol, but I prefer stroke b. http://www.fileformat.info/info/unicode/char/2422/index.htm Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers > On Apr 21, 2014 5:41 AM, "Pieter Wuille" wrote: > >>On Apr 21, 2014 3:37 AM, "Un Ix" wrote: >> >> Something tells me this would be reduced to a single syllable in common >> usage I.e. bit. > > What units will be called colloquially is not something developers will > determine. It will vary, depend on language and culture, and is not > relevant to this discussion in my opinion. > > It may well be that people in some geographic or language area will end up > (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as > "official" name in software would be very strange and potentially confusing > in my opinion. As mentioned by others, that would seem to me like calling > dollars "bucks" in bank software. Nobody seems to have a problem with > having colloquial names, but "US dollar" or "euro" are far less ambiguous > than "bit". I think we need a more distinctive name. > > -- > Pieter -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 implementation guidance
At the moment BIP70 specifically requires that a request be rejected if validation fails, so that should be fixed that sooner rather than later: "The recipient must verify the certificate chain according to [RFC5280] and reject the PaymentRequest if any validation failure occurs." Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 8:39 AM, Mike Hearn wrote: > A bunch of different people either have implemented or are implementing > BIP70 at the moment. Here's a bunch of things I've been telling people in > response to questions. At some point I'll submit a pull req with this stuff > in but for now it's just an email. > > Error handling during signature checking > > I've had queries around the right behaviour here. BIP 70 is underspecified > and we should fix it IMO. If PKI checking fails you should just treat the > request as if it's unsigned. The reason is that there is no incentive for an > attacker to break the signature instead of just removing it entirely, so an > attacker would never trigger any error flows you put in. However, someone > who is signing their request with an unknown CA or using an upgraded version > of the protocol that isn't entirely backwards compatible could trigger > signature checking failure. > > Therefore, in order to make introducing new (possibly community run) CA's or > new variations on signing possible, please treat any errors as if there was > no signature at all. This is not what browsers do, but browsers have an > advantage - they were already given an identity and told to expect a secure > protocol when the user typed in the web address with an https:// prefix (or > clicked a link). Unfortunately a Bitcoin wallet has no context like this. > > One person asked me whether this makes the whole scheme pointless because a > MITM can just delete the signature. The answer is no - downgrade attacks are > always possible on systems that start out insecure. The solution is to train > users to expect the upgrade and refuse to go ahead if it's not there. > Training users to expect signed payment requests will be a big task similar > to the way the browser industry trained users to look for the padlock when > typing in credit card details, but it must be done. > > Because wallets lack context there's no equivalent to HSTS for us either. So > in your GUI's try to train the user - when showing a signed payment request, > tell them to expect the recipient name to appear in future and that they > should not proceed if it doesn't. This gives us a kind of mental HSTS. > > Extended validation certs > > When a business is accepting payment, showing the name of the business is > usually better than showing just the domain name, for a few reasons: > > Unless your domain name is your business name like blockchain.info, it looks > better and gives more info. > > Domain names are more phishable than EV names, e.g. is the right name > bitpay.com or bit-pay.com or bitpay.co.uk? > > More important: Someone who hacks your web server or DNS provider can > silently get themselves a domain name SSL cert issued, probably without you > noticing. Certificate transparency will eventually fix that but it's years > away from full deployment. It's much harder for a hacker to get a bogus EV > cert issued to them because there's a lot more checking involved. > > EV certs still have the domain name in the CN field, but they also have the > business name in the OU field. > > In theory we are supposed to have extra code to check that a certificate > really was subject to extended validation before showing the contents of > this field. In practice either bitcoinj nor Bitcoin Core actually do, they > just always trust it. It'd be nice to fix that in future. > > You should show the organisation data instead of the domain name if you find > it, for EV certs. > > pki=none > > Signing is optional in BIP 70 for good reasons. One implementor told me they > were considering rejecting unsigned payment requests. Do not do this! A MITM > can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all. > > Even though today most (all?) payment requests you'll encounter are signed, > it's important that signing is optional because in future we need individual > people to start generating payment requests too, and many of them won't have > any kind of memorisable digital identity. Plus other people just won't want > to do it. BIP70 is about lots of features, signing is only one. > > S/MIME certs > > Email address certs look a bit different to SSL certs. You can get one for > free from here > > https://comodo.com/home/email-security/free-email-certificate.php > > In these certs the display name can be found in the Subject Alternative Name > field with a type code of 1. Example code: > > > https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d > > You won't encounter many of these today except on G
Re: [Bitcoin-development] moving the default display to mbtc
It will also be important to chose the currency symbol for "bits" at the same time. Lowercase stroke "b" I think is the obvious choice. Unicode U+0180 Aaron On Friday, May 2, 2014, Alan Reiner wrote: > I've been a strong supporter of the 1e-6 unit switch since the beginning > and ready to do whatever I can with Armory to help ease that transition. > I'm happy to prioritize a release that updates the Armory interface to make > "bits" the default unit, when the time is right. I think it makes sense to > get as many apps and services to upgrade nearly simultaneously. > > My plan is to have a popup on the first load of the new version that > briefly introduces the change, and mentions that they can go back to the > old way in the settings, but make them work to do it. For the transient > period (6 months?) all input boxes will auto-update nearby labels with the > converted-to-BTC value as they type, so that they don't have to do any math > in their head. Similarly, all displayed BTC values will show both. But > the 1e-6 unit will always be default or first unless they explicitly change > it in the interface. > > > > > On 5/2/2014 8:54 PM, Ben Davenport wrote: > > I fully support this (it's what I suggested over a year ago), but what it > comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting > together, agreeing what they're going to use, and doing a little joint > customer education campaign around it. If there's community momentum around > "bits", great. > > My only addition is that I think we should all stop trying to attach SI > prefixes to the currency unit. Name me another world currency that uses SI > prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at > least in the US is , i.e. $63k or $3M. > That may not be accepted form everywhere, but in any case it's an informal > format, not a formal one. The important point is there should be one base > unit that is not modified with SI prefixes. And I think the arguments are > strong for that unit being = 100 satoshi. > > Ben > > > > > On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik > > > wrote: > >> >> >> Related: >> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html >> >> -- >> Jeff Garzik >> Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ >> >> >> -- >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for > free."http://p.sf.net/sfu/SauceLabs > > > > ___ > Bitcoin-development mailing listbitcoin-developm...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
I have to agree with Mike. Human language is surprisingly tolerant of overloading and inference from context. Neurotypical people have no problem with it and perceive a software engineer's aversion to it as being pedantic and strange. Note that "bits" was a term for a unit of money long before the invention of digital computers. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr wrote: > [resend - apologies if duplicate] > > Microbitcoin is a good-sized unit, workable for everyday transaction > values, with room-to-grow, and a nice relationship to satoshis as 'cents'. > > But "bits" has problems as a unit name. > > "Bits" will be especially problematic whenever people try to graduate > from informal use to understanding the system internals - that is, when > the real "bits" of key sizes, hash sizes, and storage/bandwidth needs > become important. The "bit" as "binary digit" was important enough that > Satoshi named the system after it; that homage gets lost if the word is > muddied with a new retconned meaning that's quite different. > > Some examples of possible problems: > > * If "bit" equals "100 satoshis", then the natural-language unpacking of > "bit-coin" is "100 satoshi coin", which runs against all prior usage. > > * If people are informed that a "256-bit private key" is what ultimately > controls their balances, it could prompt confusion like, "if each key > has 256-bits, will I need 40 keys to hold 10,000.00 bits?" > > * When people learn that there are 8 bits to a byte, they may think, > "OK, my wallet holding my 80,000.00 bits will then take up 10 kilobytes". > > * When people naturally extend "bit" into "kilobits" to mean "1000 > bits", then the new coinage "kilobits" will mean the exact same amount > (100,000 satoshi) as many have already been calling "millibits". > > I believe it'd be best to pick a new made-up single-syllable word as a > synonym for "microbitcoin", and I've laid out the case for "zib" as that > word at <http://zibcoin.org>. > > 'Zib' also lends itself to an expressive unicode symbol, 'Ƶ' > (Z-with-stroke), that remains distinctive even if it loses its stroke or > gets case-reversed. (Comparatively, all 'b'-derived symbols for > data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts > where subtleties of casing/stroking are lost.) > > (There's summary of more problems with "bit" in the zibcoin.org FAQ at: > <http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins>.) > > - Gordon > > On 5/1/14, 3:35 PM, Aaron Voisine wrote: >> I'm also a big fan of standardizing on microBTC as the standard unit. >> I didn't like the name "bits" at first, but the more I think about it, >> the more I like it. The main thing going for it is the fact that it's >> part of the name bitcoin. If Bitcoin is the protocol and network, bits >> are an obvious choice for the currency unit. >> >> I would like to propose using Unicode character U+0180, lowercase b >> with stroke, as the symbol to represent the microBTC denomination, >> whether we call bits or something else: >> http://www.fileformat.info/info/unicode/char/0180/index.htm >> >> Another candidate is Unicode character U+2422, the blank symbol, but I >> prefer stroke b. >> http://www.fileformat.info/info/unicode/char/2422/index.htm >> >> Aaron >> >> There's no trick to being a humorist when you have the whole >> government working for you -- Will Rodgers >> >>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" wrote: >>> >>>> On Apr 21, 2014 3:37 AM, "Un Ix" wrote: >>>> >>>> Something tells me this would be reduced to a single syllable in common >>>> usage I.e. bit. >>> >>> What units will be called colloquially is not something developers will >>> determine. It will vary, depend on language and culture, and is not >>> relevant to this discussion in my opinion. >>> >>> It may well be that people in some geographic or language area will end up >>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using that as >>> "official" name in software would be very strange and potentially confusing >>> in my opinion. As mentioned by others, th
Re: [Bitcoin-development] "bits": Unit of account
Bit by bit, it's become clear that it's a bit much to worry even a little bit that overloading the word "bit" would be every bit as bad as a two bit horse with the bit between it's teeth that bit the hand that feeds it, or a drill bit broken to bits after just a bit of use. Aaron There's no trick to being a humorist when you have the whole government working for you -- Will Rodgers On Sat, May 3, 2014 at 10:18 PM, Drak wrote: > +1 > > On 4 May 2014 02:06, "Chris Pacia" wrote: >> >> Absent a concerted effort to move to something else other than 'bits', I >> would be willing to bet the nomenclature moves in that direction anyway. >> 'Bits' is just a shorten word for 'millibits' (or microbits, if you >> will). It's easier to say and my guess is people would tend to use it >> naturally own their own. Kind of like 'bucks' for dollars. >> >> The other synergies are: >> -bit is part of the word Bitcoin. The currency unit bit is part of a >> whole bitcoin. >> -bit symbolically represents the tech nature of the bitcoin. >> -bit used to be a unit of money way back when. This largely reclaims it. >> -when used as money bit when in references to a precession metal coin. >> The name 'bitcoin' references that as well as the mimicking of the gold >> standard in the protocol rules. >> >> All around I don't think there is a better fit. I doubt people will get >> confused by it. The context it's used in will distinguish it from other >> uses of the word. >> >> On 05/03/2014 12:27 PM, Mike Caldwell wrote: >> > I agree with the sentiment that most people don't understand either >> > computer science or Bitcoin. The goal of getting people to understand >> > enough about Bitcoin to use it is achievable and a goal that is "in scope" >> > of our efforts. Getting them to understand computer science at large at the >> > same time, less so. >> > >> > The fact that people routinely confuse RAM and hard drive sizes has much >> > to do with the fact that the average lay person has little need to >> > prioritize this as something to keep in the forefront. They don't get >> > "horribly" confused, they just simply don't get worked up over what looks >> > to >> > them like a rounding error, much to the dismay of anyone who believes that >> > everyone should be an expert at computer science. The average joe may >> > assess (accurately from his perspective) that the distinction isn't >> > important enough to merit significant mental resources and he is justified >> > in not expending them that way even if someone else thinks he should. >> > >> > Poor understanding is precisely what a proper effort to name this would >> > be to avoid. It is not frill or aesthetics, it is a planned targeting of >> > language to achieve the clearest communication to the widest possible >> > target >> > audience using the language most likely to be understood by them in light >> > of >> > our objectives. It's marketing. >> > >> > Mike >> > >> > Sent from my iPhone >> > >> >> On May 3, 2014, at 9:49 AM, "Christophe Biocca" >> >> wrote: >> >> >> >> Context as a disambiguator works fine when the interlocutors >> >> understand the topics they're talking about. >> >> Not a day goes by without me seeing "neurotypical people" get horribly >> >> confused between RAM and Hard Drive sizes, because they share the same >> >> units (not that that can be helped, as the units are supposed to be >> >> the same, base 1000 vs 1024 notwithstanding). >> >> >> >> Bit (as a unit) is already really confusing for anyone who doesn't >> >> deal with it on a regular basis. I think people who don't see an issue >> >> are making an assumption based on their own lack of confusion. We >> >> understand computer science AND Bitcoin. Most people have zero >> >> understanding of either. >> >> >> >> Bitcoin already has a ton of issues with terrible names for things: >> >> >> >> - Mining (for transaction validation). >> >> - Addresses (which are meant to be one-time use, and don't even really >> >> exist at the network level). >> >> - Wallets (which don't hold your bitcoins, can be copied, and all >> >> backups can be stolen from equally). >> >> >> >> I end up having to make the distinctions obvious every time I explain >> >> Bitcoin to someone new to it. There's an acceptable tradeoff here, >> >> because there were arguably no better words to assign to these >> >> concepts (although I'd argue mining is a really awful metaphor, and is >> >> the one that prompts the most questions from people). Then add to the >> >> pile a bunch of third parties naming themselves after parts of the >> >> protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've >> >> definitiely seen average people get confused between "the blockchain" >> >> and "blockchain.info" (not so much Coinbase, because that name doesn't >> >> come up in beginner explanations). >> >> >> >> It seems downright masochistic to add >> >> yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile >> >> for no
