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 m...@friedenbach.org 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 andr...@petersson.at 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] 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, justusranv...@riseup.net 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] 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 mor...@gmail.com 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 vois...@gmail.com 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, 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
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 brianchoff...@gmail.com 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 faizkha...@gmail.com 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 kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin 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] 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] 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 nat...@leastauthority.com wrote: On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd p...@petertodd.org 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 vois...@gmail.com 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
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 m...@plan99.net 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
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 nat...@leastauthority.com wrote: On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com 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 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 -- Nathan Wilcox Least Authoritarian email: nat...@leastauthority.com twitter: @least_nathan PGP: 11169993
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 gavinandre...@gmail.com wrote: On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock b...@mattwhitlock.name 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. I don't even think it will be a problem if/when we do have size-independent new block propagation, because I think the combination of the random timing of block-finding plus a dynamic limit as described above will create a healthy system. If I'm wrong, then it seems to me the miners will have a very strong incentive to, collectively, impose whatever rules are necessary (maybe a soft-fork to put a hard cap on block size
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 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] Long-term mining incentives
On Sat, May 16, 2015 at 1:35 PM, Owen Gunden ogun...@phauna.org 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] 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 pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine vois...@gmail.com 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
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 jti...@jtimon.cc wrote: On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen gavinandre...@gmail.com 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 productive. -- 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
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 pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine vois...@gmail.com 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
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 vois...@gmail.com 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 pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine vois...@gmail.com 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] 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 m...@friedenbach.org 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 self-supporting fee economy. When the subsidy goes away or is reduced to an insignificant fraction of the block reward, this incentive structure goes away. Hopefully at that time we would have sufficient information to soft-fork set a hard block size
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 m...@friedenbach.org wrote: On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com 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] 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 jan.mol...@gmail.com 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 m...@plan99.net 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 -- 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
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 gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@gmail.com 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 thashizn...@yahoo.com.au 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] 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=190641631iu=/4140/ostg.clktrk___ 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. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 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 pieter.wui...@gmail.com 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] 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 b...@mattwhitlock.name 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=154622311iu=/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 b...@mattwhitlock.name 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 b...@mattwhitlock.name 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=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 m...@plan99.net 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 m...@plan99.net 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=157508191iu=/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=157508191iu=/4140/ostg.clktrk ___ 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 m...@plan99.net 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 vois...@gmail.com javascript:_e(%7B%7D,'cvml','vois...@gmail.com'); 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 will.ya...@gmail.com javascript:_e(%7B%7D,'cvml','will.ya...@gmail.com'); wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com javascript:_e(%7B%7D,'cvml','gmaxw...@gmail.com'); 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 natanae...@gmail.com 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 m...@plan99.net: 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 vois...@gmail.com 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 m...@plan99.net 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 vois...@gmail.com 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 will.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com 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
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 ron.ohar...@gmail.com 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 javascript:; 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 will.ya...@gmail.com wrote: On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.com 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] 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 gmaxw...@gmail.com wrote: On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com 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
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 laa...@gmail.com wrote: On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net 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 gmaxw...@gmail.com wrote: On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine vois...@gmail.com 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] 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 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 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] 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 m...@ricmoo.com 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#174; Code Sight#153; - 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#174; Code Sight#153; - 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] 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 jgar...@bitpay.com 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] 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 d...@zikula.org wrote: +1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com 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 christophe.bio...@gmail.com 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 reason other than aesthetics. Are we actively trying to confuse people? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
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 m...@plan99.net 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 Gavin's test site, but in future people may wish to start creating and
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 etothe...@gmail.com 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 currency-symbolamountmodifier, 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 jgar...@bitpay.comjavascript:_e(%7B%7D,'cvml','jgar...@bitpay.com'); wrote: vendor hat: on 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.netjavascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','Bitcoin-development@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 goj...@gmail.com 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 pieter.wuille@gm... wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevnull@... 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 -- Accelerate Dev Cycles
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 pieter.wuille@gm... wrote: On Apr 21, 2014 3:37 AM, Un Ix slashdevnull@... 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] 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 m...@plan99.net 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
