Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
What prevents you from writing a bad check using today's systems? On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.tho...@gmail.com 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 p...@petertodd.org 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+ 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 -- 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.
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
I am not the one presenting this as some kind of novel attack on transactions in general. On Tue, May 26, 2015 at 1:43 PM, Raystonn rayst...@hotmail.com wrote: Trust, regulation, law, and the threat of force. Are you serious? On 26 May 2015 11:38 am, Allen Piscitello allen.piscite...@gmail.com wrote: What prevents you from writing a bad check using today's systems? On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.tho...@gmail.com 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 p...@petertodd.org 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+ 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] replace-by-fee v0.10.0rc4
You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It does, and there are incentives to use it by miners. These are the bounds we have to deal with and the world we must adapt to. On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 05:24 PM, Oleg Andreev wrote: I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can get away with 0-confirms but it's only because most people arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double spend or forcing people into privacy/security sacrifices. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4 bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45 RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232 FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8 XjbkwrkFIuKfUJyfIuR+ =ony0 -END PGP SIGNATURE- -- 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.
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Nothing will stop that. Bitcoin needs to deal with those issues, not stick our heads in the sand and pretend they don't exist out of benevolence. This isn't a pet solution, but the rules of the protocol and what is realistically possible given the nature of distributed consensus. Relying on altruism is a recipe for failure. On Thu, Feb 12, 2015 at 1:34 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:15 PM, Alan Reiner wrote: I'll add fuel to the fire here, and express that I believe that replace-by-fee is good in the long-term. Peter is not breaking the zero-conf, it was already broken, and not admitting it creates a false sense of security. I don't want to see systems that are built on the assumption that zero-conf tx are safe solely because it has always appeared safe. You can argue about rational miner behaviors all day, but in a decentralized system you have no idea what miners consider rational, or speculate about their incentives. As noted elsewhere in the thread, there are two problems with this analysis: 1. It asserts that zero-confirmation transactions are in a binary state of safe/broken instead of recognizing that relying on them is a non-binary risk analysis on the part of a merchant. 2. Assumptions about what is profitable for miners are based on all miners having short time horizons for calculating profits. In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? Punishing Bitcoin users for not adopting somebody's pet solution to a problem neither responsible nor ethical. Child-pays-for-parent allows for stuck transactions to be cleared from the mempool, and allows recipients of zero-conf transactions to adjust their risk exposure as much or as little as they like. It's a solution that gives Bitcoin users more freedom, instead of trying to coerce them into pre-determined directions. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99 kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/ F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5 sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0 F9dKdL5zCGofvU/U5BVq =kEMr -END PGP SIGNATURE- -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Is there a way to estimate the maximum number of transactions per minute Bitcoin can handle as it is today?
You are assuming that the only way to use Bitcoin is on-chain transactions and that is the only way for it to scale. This is a mistake. On Fri, Jan 30, 2015 at 6:48 PM, Angel Leon gubat...@gmail.com wrote: On the Chinese Single's Day (sort of like the american Black Friday) according to MIT's Tech Review http://www.technologyreview.com/news/534001/alipay-leads-a-digital-finance-revolution-in-china/ magazine Alipay handled up to 2.85 million transactions per minute, and 54 percent of its transactions are made via mobile device. For a few weeks I've been reading the conversations about block sizes and the experiments being done on the subject with larger blocks. On the day with the most transactions, the Bitcoin block chain averages about 73 transactions per minute. I kept wondering what blocksize we'd need for handling 100,000 transactions per minute, and estimated that roughly we'd need a blocksize of about 1300x times larger than what we have now, so bigger than 1Gb block... but seeing the numbers Alipay gets to handle just in China make me wonder how scalable is Bitcoin if it were to truly compete with worldwide financial services. If you were to include double the number Alipay can handle, you'd be shooting about 6 million transactions per minute, or roughly 60 million transactions per block. If you average every transaction around 250 bytes, then you'd need ~15 Gigabytes per block to be broadcast and hashed by all the full nodes every 10 minutes, eating good 2Tb of storage daily... do miners have enough bandwidth and CPU power to handle this? are my scalability concerns absurd? http://twitter.com/gubatron -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
The idea was to use the magic number as the source for cointype. If it's too big, as Tamas showed, perhaps a hash of it, and for coins without a magic number, a hash of their name (or some unique identifier). That being said, I agree with Andreas that something that is 90% inter-operable seems very dangerous and will give people false expectations when they miss the corner cases. If the structure isn't going to be shared completely and have all support shared, having it completely incompatible along with a mechanism for converting part of it to another wallet seems superior. The worst types of losses will occur when someone tests out something with a limited use case, sees that it appears to work, makes dangerous assumptions, then gets burned when it's too late. -Allen On Thu, Mar 27, 2014 at 11:06 AM, Pavol Rusnak st...@gk2.sk wrote: On 03/27/2014 04:57 PM, Allen Piscitello wrote: Don't most of these coins have a magic number already assigned that is unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for Litecoin, etc...). This seems like a good candidate for identifying coins, and also supports Testnet cases well. Maybe there are some alts without such a magic number that might prevent that? That magic number is something I find very unfortunate and superflous in BIP-32 design. Its only purpose is to distinguish BIP-32 trees for various altcoins, but it doesn't make sense at all once you start storing various altcoins in the same tree using the proposed /m/cointype/reserved'/account'/change/n scheme. I would love to see that removed from BIP-32 and use always 0x0488B21E/0x0488ADE4 (xpub/xpriv), but that is for different discussion I guess. -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk -- ___ 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] New BIP32 structure
The benefit I see is avoiding reuse of keys between coins while not having each wallet implementation have to know about each coin in order to scan for transactions. Wallet X supports Doge and Bitcoin. If both used a shared sequence of keys, say the first two end up Bitcoin, then 10 Doge, then some more Bitcoin. If you took this seed to Wallet Y, which only supports Bitcoin (either the wallet's support or what is installed on the system it's being used), it will see a gap of 10 addresses, and presume no more scanning with a 5 gap limit. The alternative is to reuse keys for each coin. It also seems like a solution might be to only expect interoperability on a single sequence, and provide backups of each final sequence to use between different wallet implementations. This allows flexibility in hierarchies depending on needs and support of wallet, but allows sharing. The short seed would only be useful for the same wallet, but sharing between wallets would use the longer keys. That will give predictable behavior for users (although less friendly) and lead to less errors. -Allen On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille pieter.wui...@gmail.comwrote: On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote: Cointype in path is for separation purposes, not for identification. I don't understand what that gains you. -- Pieter -- ___ 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] New BIP32 structure
For every branch (say multiple accounts), how would a new wallet be able to know how many sequence items to scan? It seems like not only do you need to have standard rules for the hierarchy, but how the usage can be detected. The other scanning seems pretty straightforward. For accounts, it seems like you could have a situation where you want to initially set up 10 different accounts, but only account #10 gets any transactions. If a new wallet was trying to scan with this seed, it would have to know to keep scanning each account until it found the account. The user would have to be responsible for knowing how many accounts there are, or some rules would need to be in place to not allow creating accounts until earlier accounts can be proven to have existed in the blockchain. Or I am missing something. -Allen On Wed, Mar 26, 2014 at 3:49 PM, Mike Hearn m...@plan99.net wrote: Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure. Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with: /m/cointype/reserved'/account'/change/n The extra levels require some explanation: - cointype: This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't. More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the raw money and it will just ignore/not see the keys used in more complex transactions. - reserved is for other stuff. I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas? - account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that. - change is 0 for receiving addresses, 1 for change addresses. - n is the actual key index For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible. The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support. Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one. -- ___ 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] moving the default display to mbtc
Fairly useless experiment, since the vast majority of users will almost always stay at the default. The winner will always be whatever was selected as the default initially. This might work if the default was randomly chosen, and you see what actually annoyed users enough to switch off of it most often. On Fri, Mar 14, 2014 at 11:51 AM, Ricardo Filipe ricardojdfil...@gmail.comwrote: so much discussion for a visual update... make this a user experiment: -give the user the possibility to use BTC/mBTC/uMTC -retrieve the results after some time -make the default the most used option 2014-03-14 16:15 GMT+00:00 Alex Morcos mor...@gmail.com: I think Mark makes some good arguments. I realize this would only add to the confusion, but... What if we did relabel 100 satoshis to be some new kind of unit (bit or whatever else), with a proper 3 letter code, and then from a user standpoint, where people are using mBTC, they could switch to using Kbits (ok thats obviously bad, but you get the idea) at the same nominal price. But accounting backends and so forth would operate in the bit base unit with 2 decimals of precision. On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach m...@monetize.io wrote: A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude numbers in both Chinas, Thailand, and other economically important East Asian countries. Expect to pay hundreds of rupees in India, or thousands of rupees in Indonesia. This concept that money should have low, single digits for everyday prices is not just Western-centric, it's English-centric. An expresso in Rome would have cost you a few (tens of?) thousand lira in recent memory. It was pegging of the Euro to the U.S. dollar that brought European states in line with the English-speaking world (who themselves trace lineage to the pound sterling). No, there is no culturally-neutral common standards for currency and pricing. But there are ill-advised, ill-informed standards in accounting software that we nevertheless must live with. These software packages do not handle more than two decimal places gracefully. That gives technical justifications for moving to either uBTC or accounting in Satoshis directly. An argument for uBTC is that it retains alignment with the existing kBTC/BTC/mBTC/uBTC conventions. However another limitation of these accounting software practices is that they do not always handle SI notation very well, particularly sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully compliant with any software accounting package out there. We are still very, very early in the adoption period. These are changes that could be made now simply by a few big players and/or the bitcoin foundation changing their practice and their users following suit. On 03/14/2014 07:49 AM, Andreas Schildbach wrote: How much do you pay for an Espresso in your local currency? At least for the Euro and the Dollar, mBTC 3.56 is very close to what people would expect. Certainly more familiar than µBTC 3558 or BTC 0.003578. Anyway, I was just sharing real-world experience: nobody is confused. On 03/14/2014 03:14 PM, Tamas Blummer wrote: You give them a hard to interpret thing like mBTC and then wonder why they rather look at local currency. Because the choices you gave them are bad. I think Bitcoin would have a better chance to be percieved as a currency of its own if it had prices and fractions like currencies do. 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be. Tamas Blummer Bits of Proof On 14.03.2014, at 15:05, Andreas Schildbach andr...@schildbach.de wrote: btw. None of Bitcoin Wallet's users complained about confusion because of the mBTC switch. In contrast, I get many mails and questions if exchange rates happen to differ by 10%. I suspect nobody looks at the Bitcoin price. It's the amount in local currency that matters to the users. On 03/13/2014 02:40 PM, Andreas Schildbach wrote: Indeed. And users were crying for mBTC. Nobody was asking for µBTC. I must admit I was not aware if this thread. I just watched other wallets and at some point decided its time to switch to mBTC. On 03/13/2014 02:31 PM, Mike Hearn wrote: The standard has become mBTC and that's what was adopted. It's too late to try and sway this on a mailing list thread now. On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: The MultiBit HD view is that this is a locale-sensitive presentation issue. As a result we offer a simple configuration panel giving pretty much every possible combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT, mXBT, μXBT, sat along with settings for
Re: [Bitcoin-development] moving the default display to mbtc
Mike is making an assumption that is not necessary, which is the price of the most commonly used unit should be between is $.50 and $1000. The issue to revisit or not shouldn't require $1,000,000 Bitcoin price. Typing a ton of decimals is incredibly annoying. Doing the mental math in my head is annoying. Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying than 3123.45 uBTC. The points that people liked mBTC better than BTC doesn't mean anything when comparing uBTC to mBTC. Many people just stopped thinking at the mBTC level, do not understand the implications involved in switching to uBTC, or even considered uBTC. The idea that we can just poll what people want to give them the ideal experience is also flawed, in that users often don't know what they want until they have it in front of them. There is basically no downside to uBTC, except a few places already switched to mBTC. For exchanges, which are dealing with decimals since they will do BTC/USD rather than the opposite, it might make sense for them to continue to use mBTC or BTC. For wallets and prices for users, especially when there are large decimals since the price is still based on more stable currencies, then converted to Bitcoin, let's switch to what is easiest. I haven't seen a single good argument for keeping it in mBTC (other than some people already did it). On the other hand, I've seen numerous great reasons for switching to uBTC. My two cents. On Thu, Mar 13, 2014 at 11:39 AM, Melvin Carvalho melvincarva...@gmail.comwrote: On 13 March 2014 16:50, Mike Hearn m...@plan99.net wrote: On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik jgar...@bitpay.com wrote: Such hand-wavy, data-free logic is precisely why community coordination is preferred to random apps making random decisions in this manner. That ship sailed months ago. If you wanted a big push for uBTC, then would have been the time. Though given that it'd have made lots of normal balances incredibly huge, perhaps it's a good thing that didn't happen. Also milli is a unit people encounter in daily life whereas micro isn't. Is it milli / micro / nano or milli / nano / micro? I bet a lot of people would get that wrong. If you have to export to financial packages that can't handle fractional pennies, then by all means represent prices in whatever units you like for that purpose, but in software designed for ordinary people in everyday life mBTC is a pretty good fit. Besides, fractional pennies crop up in existing currencies too (the famous Verizon Math episode showed this), so if a financial package insists on rounding to 2dp then I guess it may sometimes do the wrong thing in some business cases already. Fundamentally, more than two decimal places tends to violate the Principle Of Least Astonishment with many humans, and as a result, popular software systems have been written with that assumption. Lots of people use currencies that don't have any fractional components at all ! So perhaps all prices should be denominated in satoshis to ensure that they're not surprised :) The (number) line has to be drawn somewhere. Wallets are free to suppress more than 2dp of precision and actually Andreas' app lets you choose your preferred precision. So I think in the end it won't matter a whole lot, if the defaults end up being wrong people can change them until wallet authors catch up. +1 agree with Mike on everything A couple of points: 1. bitcoinity already switched to mbtc aka millitbits ( https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved, they got quite a few donations 2. If you watch Gavin's talk at the CFR he suggests the community comes to a consensus through implementations rather than top down decision making (If I understood correctly) I think it's up to wallet maintainers whether to switch the default. -- 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/13534_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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] moving the default display to mbtc
It certainly is not subjective, in that people are far more used to dealing with whole numbers than decimals. Try reading the first one, then reading the second one. Tell those numbers to someone else, have them write it down, and see how many people screw up the first vs. the second. This has nothing to do with whether it looks expensive. There are reasons for wanting the numbers to be higher as well, as evidenced by the number of Dogecoin enthusiasts who like having more, even if it doesn't matter. That part gets more subjective, but still favors micros in most cases. Sure, 3000 may sound like a lot, but if you have a lot more, it's all a different scale. If the argument is for keeping things based on what is already done, why even switch to millis? After all, everyone is used to full Bitcoins, why even change to millis? Whatever your arguments are there, for switching base bitcoins to millis, try to see why they fail at micros (other than the subjective argument that I'm used to decimal units of currency being worth a cup of coffee, even though numerous people all over the world don't have that conditioning). On Thu, Mar 13, 2014 at 12:13 PM, Mike Hearn m...@plan99.net wrote: Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying than 3123.45 uBTC. This is subjective though. To me the first price looks like the price of a cup of coffee (or I just mentally double it). The second looks like the price of an expensive holiday. If users really find this so terrible, merchants have a simple solution: do the rounding before presenting the price. Then the price looks like 3.12 mBTC which is sort of what I'd expect it to look like. But some wallets already make digits 2dp smaller so visually you can get precision whilst still looking similar to what you might expect (this is what Bitcoin Wallet does). I haven't seen a single good argument for keeping it in mBTC (other than some people already did it). That's the good argument! -- 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/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
This is somewhat problematic in my use case since some parts need to be in the chain earlier than others and have the same ID as expected. https://bitcointalk.org/index.php?topic=260898.10 I haven't gone back to see if there are any ways around it, but the main problem here is I need the Contract TX to be in the chain much earlier than redeeming, but I need the refund transaction to be in the chain much earlier. Perhaps there are some tricks to pull off to get it to work, but I haven't been working on this for a while so I'm a bit rusty in that area. This might be helpful enough to help a lot of use cases, but shouldn't be final. -Allen On Wed, Feb 19, 2014 at 6:22 PM, Natanael natanae...@gmail.com wrote: Regarding chains of transactions intended to be published at once together, wouldn't it be easier to add a only-mine-with-child flag? That way the parent transactions aren't actually valid unless spent together with the transaction that depends on it, and only the original will have a child referencing it. Then malleability is not an issue at all for transaction chains if you only need to broadcast your full transaction chain once, and don't need to extend it in two or more occasions, *after* broadcasting subchains to the network, from the same set of pregenerated transactions. If you need to broadcast pregenerated subchains separately, then you need the last child in the chain to be non-malleable. This would require all miners to start to respect it at once in order to avoid forking the network. - Sent from my phone Den 19 feb 2014 22:13 skrev Pieter Wuille pieter.wui...@gmail.com: On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager grona...@mac.com wrote: I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions. Just to be clear: this change is not directly intended to avoid incidents. It will take way too long to deploy this. Software should deal with malleability. This is a longer-term solution intended to provide non-malleability guarantees for clients that a) are upgraded to use them b) willing to restrict their functionality. As there are several intended use cases for malleable transactions (the sighash flags pretty directly are a way to signify what malleabilities are *wanted*), this is not about outlawing malleability. While we could right now make all these rules non-standard, and schedule a soft fork in a year or so to make them illegal, it would mean removing potential functionality that can only be re-enabled through a hard fork. This is significantly harder, so we should think about it very well in advance. About new transaction and block versions: this allows implementing and automatically scheduling a softfork without waiting for wallets to upgrade. The non-DER signature change was discussed for over two years, and implemented almost a year ago, and we still notice wallets that don't support it. We can't expect every wallet to be instantly modified (what about hardware wallets like the Trezor, for example? they may not just be able to be upgraded). Nor is it necessary: if your software only spends confirmed change, and tracks all debits correctly, there is no need. -- Pieter -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
While that solution does work for many use cases, it does make it much harder to do anything needing chained transactions. Granted, this is the short term solution for current implementations, but having a transaction identifier that does not change does open up other use cases. For example, Alice wants to send coins to a multisignature address with Bob, such that both parties are required to spend the coins. Alice also requires for Bob to send coins to this address as well before they will proceed. Alice cannot guarantee that Bob will cooperate (and vice versa), so before she broadcasts the transaction to send to A+B, she sends Bob a transaction that spends her incoming transaction back to herself, but has a time lock of far into the future. Bob signs this, returns it to Alice, and she broadcasts her funding transaction. At this point, Bob disappears, loses his key, or just decides to spite Alice and her coins are locked. Since she has a refund transaction, she can broadcast it in a month and get her coins back. Except her funding transaction has been modified such that the txhash is different, so her refund is now invalid. She would need Bob to issue a new refund as soon as her funding transaction hits the blockchain if it is modified, which defeats the point of the trustless refund transaction. Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. Obviously this is a difficult problem to solve and cannot be implemented without breaking changes, but it would be a nice goal to be able to completely remove malleability. There are other important use cases where having a unique identifier just for internal accounting is insufficient. -Allen On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner etothe...@gmail.com wrote: I think the solution is simply to encourage Bitcoin software developers to design their software to use this static ID, instead of the full transaction hash.If MtGox had talked those IDs instead of the TX ID, their software would've correctly identified the mutated transactions and there would be no problem. Armory is slightly different, since it doesn't deal with the same stuff as exchanges do. But it didn't have any problems with malleability because it doesn't track anything by ID, it only pays attention to whether inputs and outputs are related to your wallets. It's not necessarily hard to do it this way, people just have to be aware of it. -Alan Sent from my overpriced smartphone On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote: Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9 and BitcoinJ already implement it, though) and potentially invalidate some script functionality. However, these new rules remain optional and controlled by an nVersion increase. Comments please! You should probably add making CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE; verifying that in the transaction itself is laborious. A more subtle example is we may want both CHECKSIG and CHECKMULTISIG to fail the transaction if the signature is invalid but not exactly equal to OP_FALSE; some transaction forms are significantly more
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 41
No, you don't get it, and it's been explained clearly to you twice. Take it to bitcointalk, this does not belong on this list. Your cure is worse than the disease. On Wed, Dec 25, 2013 at 12:53 AM, Ryan Carboni ryan.jc...@gmail.com wrote: You just completely ignored my point. I'm not sure who's trying to insult whom, or if you're attempting an argumentum ad hominem. My idea is completely valid. The only way to man in the middle to have such a large percentage of hash power is to either a) attack a pool (which people would notice when their withdrawals go nowhere), b) attack a large number of nodes, which must have enough combined hash power to mine four blocks within three days for people to notice (I think it is unlikely for Bitcoin point of sale nodes to have significant hash power), or c) the attacker himself has 1% of the hash power and is diverting it to conduct a man in the middle attack against one single person (as opposed to a major retailer who has a round the clock IT staff). In order for a large number of nodes to be attacked, it must be by someone who either is a state actor or an ISP, at which point you've already lost. It's really simple math, it require on even the most optimistic estimates a tenth of a percent of the total network hash power to mine 4 blocks within three days with good luck. Or maybe this single person is on vacation, then it would take a hundredth of a percent of the total hash power over two weeks. I think very few people even have a hundredth of a percent of the total hash power, which goes to show how secure the network is, and how little my proposal would weaken network security. I'll concede that difficulty could be reduced only by 80% if only four blocks were mined in 3 days, which would provide sufficient margin against these proposed man in the middle attacks, because block-chain growth would be noticeably reduced. But I repeat myself. Repeatedly. I wish you would understand my points. I'm making a good faith effort to provide an original idea before it's possibly too late. But fine. I have nothing more to add, and it's the holidays. On Tue, Dec 24, 2013 at 2:47 AM, bitcoin-development-requ...@lists.sourceforge.net wrote: An attacker with some small hashpower isolates you (as an individual) from the network by MITMing your network. You just switch the the attackers chain as if nothing happened because of the network rule that defines it as OK. Today, you will see that you're behind and warn the user. Was it really so hard to write a three-sentence paragraph to clarify the attack instead of insulting people? Still, posting ideas here without spending time to ensure you understand the Bitcoin network well is frowned upon. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
Ryan, Why do you continue to try to correct people who clearly have put more thought into this than you? Everyone understood you just fine, you just seem to have trouble comprehending why your ideas are terrible. On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni ryan.jc...@gmail.com wrote: I think you misunderstood my statement. If time 3 days, and after 4 blocks have been mined, then difficulty would be reset. In theory, one would have to isolate roughly one percent of the Bitcoin network's hashing power to do so. Which would indicate an attack by a state actor as opposed to anything else. Arguably, the safest way to run Bitcoin is through a proprietary dial-up network. On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach m...@monetize.iowrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan, these sort of adjustments introduce security risks. If you were isolated from the main chain by a low-hashpower attacker, how would you know? They'd need just three days without you noticing that network block generation has stalled - maybe they wait for a long weekend - then after that the block rate is normal but completely controlled by the attacker (and isolated from mainnet). There are fast acting alternative difficulty adjustment algorithms being explored by some alts, such as the 9-block interval, 144-block window, Parks-McClellan FIR filter used by Freicoin to recover from just such a mining bubble. If it were to happen to bitcoin, there would be sophisticated alternative to turn to, and enough time to make the change. On 12/22/2013 07:10 PM, Ryan Carboni wrote: I think Bitcoin should have a sanity check: after three days if only four blocks have been mined, difficulty should be adjusted downwards. This might become important in the near future. I project a Bitcoin mining bubble. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3 hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8 IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN DOTF7jpt0ZmCm7uhG9z7 =5Q2H -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
I've got a better idea. Ben Bernake needs a new job. Let's just let him set the block reward. On Mon, Dec 9, 2013 at 5:23 PM, Jameson Lopp jameson.l...@gmail.com wrote: To piggyback on Jeff, Any proposal that is going to add reliance upon data from third parties outside of the Bitcoin network itself is likely going to be rejected outright. This opens far too many potential vulnerabilities. The exchanges that are kept track of could be hard coded into Bitcoin or the miner could choose, how this works is not something I'm personally focused on. Yeah... you can't just gloss over a little detail like that. There must be consensus between the miners, otherwise a solved block will be rejected by a miner's peers. -- Jameson Lopp Software Engineer Bronto Software, Inc On 12/09/2013 06:10 PM, Jeff Garzik wrote: On Mon, Dec 9, 2013 at 7:23 PM, Ryan Carboni ryan.jc...@gmail.com wrote: It is not a violation of the trust of those holding the currency. Many people bought Bitcoin in the hopes that it's value in the relation of other currencies will increase, not because there's a fixed money supply. The majority of people using Bitcoin as a currency in exchange for real goods are using the exchanges. Your proposal has been met with widespread laughter. Were I not ill with the flu, mockery would ensue as well. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
Obviously the answer is to just display all fees and trading rates as BTC or MBTC (.005 MBTC fee? how cheap!). On a more serious note, the transition should definitely be thought out well as it could be very damaging to have this confusion, but I would prefer to do it only once rather than twice. On Thu, Nov 14, 2013 at 4:00 PM, Alan Reiner etothe...@gmail.com wrote: Just keep in mind it will be a little awkward that 54.3 uBTC is the smallest unit that can be transferred [easily] and the standard fees are 500 uBTC.It's not a deal breaker, it's just something that needs to be taken into consideration when it comes to user perception (which is one of the reasons we would make such a change in the first place). Holy crap these fees are huge! I thought Bitcoin didn't have fees! On 11/14/2013 04:55 PM, Allen Piscitello wrote: I also would prefer to go straight to uBTC as the standard wallet unit.It works out perfectly with Satoshi's being the decimal units. Something that costs $10USD would be 25000uBTC. This isn't a problem for a place like South Korea, where 10USD is about 10,000 Won, so we aren't even off on a scale of usable currencies in major economies. The downsides are obviously confusion (causing mistakes resulting in lost coins), and possibly from a psychological perspective on price (uBTC are worthless!). On the other hand, it also might help people feel like they are getting in on the ground floor still (I own 100,000 uBTC!), and reduce the perception the Bitcoins are not divisible (I have heard several people worry that 21 million is not enough units). Alan's ideas for compatibility with multiple fields will also be helpful to solving the confusion issue. On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach m...@monetize.io mailto:m...@monetize.io m...@monetize.io wrote: For this reason I'm in favor of skipping mBTC and moving straight to uBTC. Having eight, or even five decimal places is not intuitive to the average user. Two decimal places is becoming standard for new national currencies, and we wouldn't be too far from human scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very many people on this list would consider bitcoin overvalued in the long term perspective. Better to go through a confusing renumbering only once. Mark On 11/14/13 12:01 PM, Alan Reiner wrote: ... I'm also of the opinion that it's freakin' hard to change the base unit in such an established system. There is no easy way to do this that doesn't cause more heartache than it's worth... -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.netBitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign
Re: [Bitcoin-development] Message Signing based authentication
This was one of my concerns when implementing a scheme where you sign a refund transaction before the original transaction is broadcast. I originally tried to pass a hash and have the server sign it. However, I had no way to know that what I was signing wasn't a transaction that was spending my coins! So I changed the code to require sending the full transaction, not just the hash. The other way to mitigate this is through not having any unspent outputs from this key. For authentication, you could have both a user-generated and server-generated portion, so that you signed something that clearly had data from you, so even if the server-data was a hash of $EVIL_DOCUMENT, you have clear plausible deniability in that your data that is also signed is ATTEMPTING LOGIN TO XYZ.COM Hash($EVIL_DOCUMENT). On Sat, Nov 2, 2013 at 4:51 PM, Mark Friedenbach m...@monetize.io wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or SIGHASH of a transaction spending those coins or updating the SIN... On 11/2/13 2:14 PM, Johnathan Corgan wrote: On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote: Server provides a token for the client to sign. Anyone else concerned about signing an arbitrary string? Could be a hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own randomly generated nonce, sign that, then pass the nonce and the signature back to the server for verification. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2 ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y 3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU 5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd 6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6 i3+pzT5rMuiIZWLx7Msv =tAUY -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Message Signing based authentication
Required vs. strongly recommended is an important distinction. Satoshi Dice reuses EC Keys for every single transaction. Exchanges will have the same address you deposit in over and over, which gets reused. This is a best practice argument rather than a protocol requirement. On Sat, Nov 2, 2013 at 8:27 PM, Luke-Jr l...@dashjr.org wrote: On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote: I actually had a use case in my case where it was possible, and that was the check I used to get around it, just configured it so that I always generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx. It was either that or making sure I had no unspent outputs. The use case of doing it was laziness in just creating a single key. Use cases mean an actual use, not mere laziness. Bitcoin as a system has always required a unique EC key (and address) for each transaction. Luke -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP39 word list
The problem with this is that you might have word A which is similar to B,
but B is also similar to C. So we scrub B from the list, someone enters B,
and we have no way to know if it means A or C. It leads to a much more
complicated scheme to ensure that all errors are correctable.
Scrubbing A, B, and C is preferable, since it leads to no ambiguity and
there is no need to try to correct an error.
On Fri, Nov 1, 2013 at 3:14 PM, Brooks Boyd bo...@midnightdesign.ws wrote:
I was inspired to join the mailing list to comment on some of these
discussions about BIP39, which I think will have great use in the Bitcoin
community and outside it as a way to transcribe binary data.
The one thought I had as the discussions about similar characters are
resulting in culling words from the list, is that it only helps to validate
input, not help the user if it is incorrect.
For example, if both cat and eat were in the word list, and someone
wrote down eat, but later mis-translated it and put cat back into
translator, the result would be a checksum error; cat is a different
number, so the checksum would fail.
As it currently stands, cat would not be a valid word (eat is the real
word, and no other number is cat), so the translator can throw a
different error which is more helpful (i.e. 'cat' isn't a valid word
choice), but still doesn't get the user to the proper translation.
What about if the wordlist included those words that are so similar to
each other that we only kept one of them and had them all refer to the
same number? I propose the wordlist have the possibility of multiple words
on a single line, with the first word on the line being the primary or
real word to be used, with the other similar words be included so that a
translation program if it wanted to assist the user could fix their input
for them (verbosely or not), along the lines of 'cat' isn't a valid word
choice; assuming you meant 'eat', which is valid. You might still hit a
checksum error if that similar word is still the wrong word, but as it
stands now, I know you culled a bunch of words from the wordlist as too
similar, but if I want to try and help the user fix a bad input, I need to
write a translation program with a full english dictionary alongside the
BIP39 dictionary.
I'd be willing to create a pull request for such an update, but before I
delve into that, does this sound like a good idea? I could see it devolving
into a slippery slope if every number in the 2048 set had a dozen word
variations (misspellings, similar words, slang terms for the real word,
etc.) which could get confusing of how similar is similar enough to be
added as an alternate, and the standard would need to be clear that when
translating binary to words, you only use the main word for that row, not
any of the variations.
MidnightLightning
I've just pushed updated wordlist which is filtered to similar
characters taken from this matrix.
BIP39 now consider following character pairs as similar:
similar = (
('a', 'c'), ('a', 'e'), ('a', 'o'),
('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
('c', 'e'), ('c', 'g'), ('c', 'n'), ('c', 'o'), ('c', 'q'),
('c', 'u'),
('d', 'g'), ('d', 'h'), ('d', 'o'), ('d', 'p'), ('d', 'q'),
('e', 'f'), ('e', 'o'),
('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
('g', 'j'), ('g', 'o'), ('g', 'p'), ('g', 'q'), ('g', 'y'),
('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
('i', 'j'), ('i', 'l'), ('i', 't'), ('i', 'y'),
('j', 'l'), ('j', 'p'), ('j', 'q'), ('j', 'y'),
('k', 'x'),
('l', 't'),
('m', 'n'), ('m', 'w'),
('n', 'u'), ('n', 'z'),
('o', 'p'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
('p', 'q'), ('p', 'r'),
('q', 'y'),
('s', 'z'),
('u', 'v'), ('u', 'w'), ('u', 'y'),
('v', 'w'), ('v', 'y')
)
Feel free to review and comment current wordlist, but I think we're
slowly moving forward final list.
slush
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Android is increasing in popularity, but the open development platform that
developers love is also
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
I think formalizing the specification could go a long way and encouraging alternate implementations is going to be the best way to reduce unexpected small bugs having a bad effect except on the buggy node. That being said, it's a huge chicken and egg problem. No one wants to go off the reference client since it could lead to working on a forked chain as a miner or having bad data as a client. I don't know if there is a good way to try to take small pieces, get consensus, possibly have some type of universal test cases and running on testnet that would solve the problem. I wouldn't mind taking on parts of this when I have time, specifically transactions/scripting. Obviously if there are better qualified people who are interested, have at it! On Wed, Oct 23, 2013 at 4:07 PM, Pieter Wuille pieter.wui...@gmail.comwrote: On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd p...@petertodd.org wrote: On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote: On 23/10/13 21:40, Peter Todd wrote: The reference implementation is the specification - the specification on the wiki is best thought of as a set of Coles Notes on the real specification. If you don't already understand that and the nuance of that statement you should assume the protocol is fixed in stone and doesn't evolve at all; that statement is not quite true, but it's very close to the truth. Does that imply that the notes are deliberately obscured to force everyone to check the source code? What's on the wiki is mostly the work of people who aren't working on the reference implementation, so no, you can't say that. Indeed, I know of few people who are familiar with the source code that use the wiki. I do think that is a pity. The openness and transparency of the protocol is essential to trusting the system (and shouldn't be limited to those digging through the source code), and for that reason alone I think it needs to be well-documented. I also do agree with earlier comments, that due to the nature of the consensus problem Bitcoin solves, it will always be the network that dictates what the actual rules are - anything else can result in inresolvable forks. If a formal specification were written, and we would find out that the majority of nodes on the network deviate from it in a subtle way, those nodes would be buggy in the sense that they aren't doing what was expected, but it would be the specification that is incorrect for not following the rules of the network. In short, consistency is more important than correctness, and for that reason, writing alternate implementation will always be hard and dangerous. However, I do not think that making it hard to find information about the details of the system is the way to go. Alternate implementations are likely inevitable, and in the long run probably a win for the ecosystem. If effort is put into accurately describing the rules, it should indeed carry a strong notice about it being descriptive rather than normative. If someone is willing to work on that, I am (and likely many people in #bitcoin-dev are) available for any questions about the protocol and its semantics. -- Pieter -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
