Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Yeah, but increasing block-size is not a longterm solution. Are you sure? That sort of statement is hard to answer because it doesn't say what you think long term is, or how much you expect Bitcoin to grow. Satoshi thought it was a perfectly fine long term solution because he thought hardware would get cheaper as fast or faster than Bitcoin would grow. You may disagree with him, but as we're talking about the future are you 100% certain he was wrong? I did calculations a long time ago that suggested even with today's hardware (+some software optimisations) it would be feasible to keep up with Visa. Hardware improvements can be unintuitive. There's a spreadsheet here that lets you play with various parameters. https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128 (note: the spreadsheet says avg txn size is 250 bytes, but if you check the formula for the middle column, it does actually use 500 bytes as the multiplier hard coded). Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a mechanism which matches supply and demand. That's not clear either, I'm afraid. Remember that there's an upper limit on how high Bitcoin fees can go. When fees become higher than what the banking system charges, many users won't use Bitcoin for moving money around anymore. Fees cannot really go much higher than that even if you assume the currency is still attractive for other reasons, because people would just sell their coins for fiat, move the fiat, and buy back the coins the other side. The way mining will be funded in future is an open question. There are differing proposals. Still, even with a higher hard block size limit, miners can always refuse to mine transactions that don't include a particular fee. So if you're worried about this, miners aren't being forced into any particular policy. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Hi Adam, I am still confused about whether you actually support an increase in the block size limit to happen right now. As you agree that this layer 2 you speak of doesn't exist yet, and won't within the next 10-12 months (do you agree that actually?), can you please state clearly that you will support Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but does/soon will have some code associated with it. But if we do no RD on layer2, and insist that clients can never change to become layer2 aware, and layer2 is too hard etc I think there's been some confusion here. I, at least, have never argued that other systems can *never* happen. Never is a long time, and I myself maintain a payment channels implementation. These things have their place. The argument is solely around the need to raise the block size *now* and not allow the existing layer 1 to gum up and fall over. If Stroem or Lightning or other block chains or Coinbase or secure hardware tokens or whatever take off and people start moving bitcoins around that way - fine. If they're choosing it of their own free will I have no issue with that, nor does anyone else, I suspect. However you don't seem fully confident that people actually will choose whatever is being cooked up as layer 2, if left to their own devices. Indeed it's impossible for anyone to know that, as no layer 2 actually exists. Any such implementation could have all sorts of flaws that lead to it not gaining traction. No offence but please find a way to gracefully stop and rejoin the constructive process. You can disagree on factors and points and be collaborative others disagree frequently and have done productive work cordially for years under the BIP process. As you know from the discussion with myself and Gavin a few days ago on IRC, neither of us believe any such constructive process exists. There is another thread to discuss the lack of such a process. - Did you accept payment from companies to lobby for 20MB blocks? Oh please. Conspiracy theories, now, Adam? My position has been consistent for years. I don't care whether the figure is 20 or something else (looks like it'll be lucky 8 instead), but I have always been clear that the limit must rise. But for the avoidance of doubt: the answer is no. Gavin is paid by MIT. The MIT deal gives Gavin complete independence. I am currently self employed and most of income comes from a client that is actually interested in Lighthouse. Luckily they have given me some leeway to do general Bitcoin development as well, which this business falls under. I would *much* rather be working on Lighthouse than this, and so would they. But seeing as you've gone there - let me flip this around. Blockstream has a very serious conflict of interest in this situation. I am by no means the first to observe this. You are building two major products: 1. Sidechains, a very complex approach to avoid changing the Bitcoin consensus rules to add new features. 2. Lightning, a so-called layer two system for transaction routing No surprise, the position of Blockstream employees is that hard forks must never happen and that everyone's ordinary transactions should go via some new network that doesn't yet exist. The problem is that rather than letting the market decide between ordinary Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin protocol because you don't trust people to spontaneously realise that they should be using your companies products. I know that many of you guys had these views before joining Blockstream. I am not saying you are being paid to have views you didn't previously have. I realise that birds of a feather flock together. Regardless, that conflict of interest DOES exist, whether you like it or not, because if you succeed in running Bitcoin out of capacity your own company stands to benefit from selling consulting and services around your preferred solutions. With respect to user rights: all the polling done so far suggests users who are paying attention strongly support increasing the block size. For example: Q: Should the bitcoin block size be raised in the next two years A: 92% yes http://www.poll-maker.com/results329839xee274Cb0-12#tab-2 Additionally, many Bitcoin users have explicitly delegated handling the technical details to someone else, like a payment processor or their wallet developers. Those people are nearly all sure that the block size limit should rise too. So please don't engage in idle speculation about users vs companies. They aren't some kind of opposing forces. Companies live for their users, and many of those companies were formed by long time Bitcoin users. And finally, the Bitcoin social contract is not defined by whatever random state the code was in at the time Gavin decided to focus on research. Both Gavin and I have been working on Bitcoin longer than you, Gregory or Peter Todd. The social contract was and still is defined by the
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether that happens in some kind of stable organised way or (as with the current code) a fairly chaotic way doesn't change the fundamental truth: *some users will find their bitcoin savings have become uneconomic to spend*. Here's a recent user complaint that provides a preview of coming attractions: https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/ Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) onto a paper wallet. When I try to send it, a window pops up stating insufficient funds for bitcoin network fee, reduce payment amount by 1,389 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50. These sorts of complaints will get more frequent and more extreme in the coming months. I realise that nobody at Blockstream is in the position of running an end user facing service, but many of us are and we will be the ones that face the full anger of ordinary users as Bitcoin hits the wall. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
We already removed the footer because it was incompatible with DKIM signing. Keeping the [Bitcoin-dev] prepend tag in subject is compatible with DKIM header signing only if the poster manually prepends it in their subject header. I still see footers being added to this list by SourceForge? Opinions? I've asked Jeff to not use his @bitpay.com account for now. The only real fix is to use a mailing list operator that is designed to operate correctly with DKIM/DMARC, either by not modifying messages in transit, or by re-sending (and ideally re-signing) under their own identity. Though I'm sure this won't be an issue for the Linux Foundation, the latter approach is dangerous because it means the list operator takes full responsibility for any spamming that occurs from that domain. If the mail server is ever hacked or spammers start posting to the lists themselves, all that spam will be seen as originating from the listserv itself and the reputation will be degraded. It can end with everyone's mail going to the spam folder. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mailman incompatibility with DKIM ...
The new list currently has footers removed during testing. I am not pleased with the need to remove the subject tag and footer to be more compatible with DKIM users. Lists can do what are effectively MITM attacks on people's messages in any way they like, if they resign for the messages themselves. That seems fair to me! :) I'm guessing DKIM enforcement is not very common because of issues like this? DKIM is used by most mail on the internet. DMARC rules that publish in DNS statements like All mail from bitpay.com is signed correctly so trash any that isn't are used on some of the worlds most heavily phished domains like google.com, PayPal, eBay, and indeed BitPay. These rules are understood and enforced by all major webmail providers including Gmail. It's actually only rusty geek infrastructure that has problems with this, I've never heard of DKIM/DMARC users having issues outside of dealing with mailman. The vast majority of email users who never post to technical mailing lists benefit from it significantly. Really everyone should use them. Adding cryptographic integrity to email is hardly a crazy idea :) It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's. It's not SourceForge, it's your spam filter. His mail gets through to me but it's all in the spam folder. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
And allegations that the project is run like wikipedia or an edit war are verifyably untrue. Check the commit history. This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it. And I fully believe he would do so! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
If you think it's not clear enough, which may explain why you did not even attempt to follow it for your block size increase, feel free to make improvements. As the outcome of a block size BIP would be a code change to Bitcoin Core, I cannot make improvements, only ask for them. Which is what I'm doing. I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany his patch, because BIPs are best when they describe working code, and BIP 1 *is* at least clear about that. Otherwise it can turn out during implementation that something was different to what was anticipated. I'm sure you agree with this. So a BIP is coming. However, BIP 1 also says this: Vetting an idea publicly before going as far as writing a BIP is meant to save the potential author time and BIP authors are responsible for collecting community feedback on a BIP before submitting it for review OK. Gavin has been vetting the idea publicly and collecting community feedback. Note that the entire Bitcoin community is not on this list, so he published a series of blog posts to get wider feedback, and then was criticised for not doing it all here instead. But anyway - so far, so good. The procedure is being followed. What happens once a BIP is written? The process says: For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. Once a BIP has been accepted, the reference implementation must be completed. This is where the problem starts. The BIP process you refer to *does not state how acceptance will happen*. It merely sets out a few minimum requirements like making some sort of sense, having code. It's also full of extremely vague descriptions like must represent a net improvement. Improvement according to who? That's left unexplained. And then it says what happens once a BIP is accepted. The middle bit is missing. When there is disagreement over a consensus BIP, how are decisions made? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
So then: make a proposal for a better process, post it to this list. Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after What belongs in a successful BIP?. Let me know what you think. The following section applies to BIPs that affect the block chain consensus rules or the peer to peer protocol and thus require changes to Bitcoin Core. Once a draft BIP has been submitted to bitcoin-development for consideration, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict within three weeks. This verdict may be informed by the debate that has taken part in the previous three weeks. If more time is required, the maintainer is required to request an extension from the BIP author, who may then elect to force an immediate decision (risking a no), or choosing to allow more time. The verdict will meet the following criteria: - It will address the latest version of the BIP at the time the verdict is rendered. - In case of a rejection, it will spell out and describe the technical rationale for this decision. Opinions held by other people are not considered technical rationales: if the maintainer agrees with a technical point made during discussion, he must own that opinion for himself. Therefore no BIP will be rejected on grounds of controversy, disagreement, lack of consensus or otherwise. - In case of rejection, the maintainer will provide a clear, specific list of actionable steps the BIP author can take next. For example, a list of what changes would address the technical objections raised. In case the maintainer believes no change could ever make the BIP acceptable, the list must consist of instructions for how to create a patch set and, in the case of changes to the consensus rules, how to initiate a hard fork. A BIP, even once rejected, may live on in the BIPS repository, though its entry in the index may be sorted below others. The BIP author may update the BIP with a summary of any resulting discussion. As such a summary may be inherently contentious in case of a dispute, the authors wording of that summary is final and may not be subject to meta-debate. -- ___ 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
Hi Bryan, 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. Yes, my comment was prickly and grumpy. No surprises, I did not sleep well last night. I am upset about this constant insistence from Adam, Gregory and others that the technical community or technical majority agree with them and anyone who doesn't is non technical or not a contributor or not an expert or not had things properly explained to them. This is not true and needs to stop. Gavin and I have both been working on Bitcoin in substantial ways for longer than Gregory and Adam have been in the community at all. We are extremely technical, as are many of the people who want us to release XT+larger blocks. We cannot make progress in any kind of negotiation if one side constantly blows off the other and refuses to take anything they say seriously, which has been a feature of this debate from the start. In contrast Gavin and I have written vast amounts of analysis on the concerns raised by larger blocks. So many hours were spent, we could probably fill a small book by now. We have carefully read and addressed *dozens* of points raised by the 1mb camp. We have also done our best to open this debate to the whole community. So it would be nice if the people who are so keen on 1mb blocks show the same respect to us. -- ___ 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
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? How do we plan to deal with security incident response - exactly the same way as before. Remember that XT is basically Core plus a few patches. Gavin and myself are both on the bitcoin-security mailing list and have been for years. Both of us have experience of responding to very serious and tight-deadline security incidents, for example, the accidental bdb hard fork and (in my case) when we discovered that Android phones had so little entropy in them that different devices were actually generating the same keys! That one required co-ordinated crash rollouts of multiple wallets across the Bitcoin ecosystem because there was a parallel investigation into key collisions taking place in an open forum and they were not far from discovering the truth about how badly the Android RNG was broken (I knew because at the time I had access to the Google internal Android bug tracker). I organised the whole thing. So I think we'll manage. But I don't expect things to exist in a state of disjointness for very long. XT will rebase on top of Core and follow it's releases for as long as there seems to be interest in bigger blocks and as long as I have the time/energy/interest. If the 1mb chain wins then Core will have to adopt the new ruleset or simply stop being relevant, as it will have no users. That wouldn't make much sense. Now, there have been concerns raised that a hard fork is unbelievably risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I don't believe it's anywhere near that risky. The patch Gavin is working on requires both a miner majority *and* also has a date trigger in it. Much like previous forks, in fact. So nobody should be taken by surprise if/when bigger blocks appear, because it will have been known for a long time beforehand that there was sufficiently strong consensus, there will have been messages printed to the node logs, announcements in various places and so on. Does that help clear things up? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
are only connected to each other through a slow 2 Mbit/s link. That's very slow indeed. For comparison, plain old 3G connections routinely cruise around 7-8 Mbit/sec. So this simulation is assuming a speed dramatically worse than a mobile phone can get! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed
Sure, and you did indeed say that. -- ___ 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
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. Yeah, my proposal is not intended to function correctly with full blocks, as Bitcoin cannot work at all in such a state. It assumes that fees only change slowly and that transactions are being cleared normally. -- ___ 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
Re: dropped in an unpredictable way - transactions would be dropped lowest fee/KB first, a completely predictable way. Quite agreed. No, Aaron is correct. It's unpredictable from the perspective of the user sending the transaction, and as they are the ones picking the fees, that is what matters. -- ___ 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
1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. Yet Bitcoin has got worse by all these metrics: there was a time before mining pools when there were ~thousands of people mining with their local CPUs and GPUs. Now the number of full nodes that matter for block selection number in the dozens, and all the other miners just follow their blocks blindly. If you really believe that decentralisation is, itself, the end, then why not go use an ASIC resistant alt coin with no SPV or web wallets which resembles Bitcoin at the end of 2009? That'd be a whole lot more decentralised than what you have now. The *percentage* of the community that mines is totally irrelevant, it's the absolute number of (independent) people that matters. So usage does matter, then? You'd rather have a coin that has power concentrated in a far smaller elite, proportionally, but has overall more usage? If there are say, 5000 full nodes today, and in ten years there are 6000, and they all run in vast datacenters and are owned by large companies, you'll feel like Bitcoin is more decentralised than ever? (n.b. I do not think this situation will ever happen, it's just an example). That's not the vibe I'm getting from most people on this list. What I'm seeing is complaints about how in the good old days back when Core was the only wallet and ASICs hadn't been made, there were lots of nodes and lots of people mining solo and since then it's all been downhill and woe is us ... and let's throw on the brakes in case it gets worse. Not for the first time, these discussions remind me very strongly of the old desktop Linux/free software debates. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DevCore London
Hi there, I got some requests to re-record the tutorial talk I gave at DevCore 2015, How to build a timestamping smart contracts app in 30 minutes. It's now available here: https://bitcoinj.github.io/document-timestamp-app It covers: - How to customise the wallet-template app for this use case - How to construct a complex multi-stage SPV proof of block chain inclusion - How to save and then verify proof files - How to bind transaction confidence state to the user interface - How to create a Mac DMG bundle with a custom icon I hope someone finds it enjoyable! On Thu, Apr 9, 2015 at 10:23 PM, Mike Hearn m...@plan99.net wrote: Next week on April 15th Gavin, Wladimir, Corey and myself will be at DevCore London: https://everyeventgives.com/event/devcore-london If you're in town why not come along? It's often the case that conferences can be just talking shops, without much meat for real developers. So in the afternoon I'll be doing two things: 1. Running a hackathon/workshop type event. The theme is contracts, but we can hack on whatever you all feel like. 2. My talk will actually be a live coding event. Writing contracts apps has become a lot easier in the past few years, and to prove it to you I will write a decentralised cross-platform Tor supporting document timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30 minutes, on stage. Don't think it can be done? Turn up and see for yourself. See you there! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements‏
But the majority of the hashrate can now perform double spends on your chain! They can send bitcoins to exchanges, sell it, extract the money and build a new longer chain to get their bitcoins back. Obviously if the majority of the mining hash rate is doing double spending attacks on exchanges then the Bitcoin experiment is resolved as a failure and it will become abandoned. This has been known since day one: it's in the white paper. The basic assumption behind Bitcoin is that only a minority of actors are dishonest - if the majority are then Satoshi's scheme does not work. So you are not stating anything new here. -- ___ 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
It's surprising to see a core dev going to the public to defend a proposal most other core devs disagree on, and then lobbying the Bitcoin ecosystem. I agree that it is a waste of time. Many agree. The Bitcoin ecosystem doesn't really need lobbying - my experience from talking to businesses and wallet developers months ago is they virtually all see raising capacity as a no brainer ... and some of them see this debate as despair-inducing insanity. What's happened here is that a small number of people have come to believe they have veto power over changes to Bitcoin, and they have also become *wildly* out of step with what the wider community wants. That cannot last. So, short of some sudden change of heart that lets us kick the can down the road a bit longer, a fork is inevitable. Just be glad it's Gavin driving this and not me ... or a faceless coalition of startups. Decentralization is the core of Bitcoin's security model and thus that's what gives Bitcoin its value. No. Usage is what gives Bitcoin value. It's kind of maddening that I have to point this out. Decentralisation is a means to an end. I first used Bitcoin in April 2009 and it was perfectly decentralised back then: every wallet was a full node and every computer was capable of mining. So if you believe what you just wrote, I guess Bitcoin's value has gone down every day since. On the other hand, if you believe the markets, Bitcoin's value has gone up. Apparently the question of what gives Bitcoin its value is a bit more complicated than that. : to incentive layer 2 and offchain solutions to scale Bitcoin : there are promising designs/solutions out there (LN, ChainDB, OtherCoin protocole, ...), but most don't get much attention, because there is right now no need for them. And, I am sure new solutions will be invented. I have seen this notion a few times. I would like to dispose of it right now. I am one of the wallet developers you would be trying to incentivise by letting Bitcoin break, and I say: get real. Developers are not some bottomless fountain of work that will spit out whatever you like for free if you twist their arms badly enough. The problems that incentivised the creation of Bitcoin existed for decades before Bitcoin was actually invented. Incentives are not enough. Someone has to actually do the work, too. All proposals on the table would: - Involve enormous amounts of effort from many different people - Be technically risky (read: we don't know if they would even work) - Not be Bitcoin The last point is important: people who got interested in Bitcoin and decided to devote their time to it might not feel the same way about some network of payment hubs or whatever today's fashion is. Faced with their work being broken by armchair developers on some mailing list, they might just say screw it and walk away completely. After all, as the arguments for these systems are not particularly logical, they might slave over hot keyboards for a year to support the Lightning Network or whatever and then discover that it's no longer the fashionable thing ... and that suddenly an even more convoluted design is being incentivised. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Ignorant. You seem do not understand the current situation. We suffered from orphans a lot when we started in 2013. It is now your turn. Then please enlighten me. You're unable to download block templates from a trusted node outside of the country because the bandwidth requirements are too high? Or due to some other problem? With respect to now it's your turn. Let's imagine the hard fork goes ahead. Let us assume that almost all exchanges, payment processors and other businesses go with larger blocks, but Chinese miners do not. Then you will mine coins that will not be recognised on trading platforms and cannot be sold. Your losses will be much larger than from orphans. This can happen *even* if Chinese miners who can't/won't scale up are 50% hashrate. SPV clients would need a forced checkpoint, which would be messy and undesirable, but it's technically feasible. The smaller side of the chain would cease to exist from the perspective of people actually trading coins. If your internet connectivity situation is really so poor that you cannot handle one or two megabits out of the country then you're hanging on by your fingernails anyway: your connection to the main internet could become completely unusable at any time. If that's really the case, it seems to me that Chinese Bitcoin is unsustainable and what you really need is a China-specific alt coin that can run entirely within the Chinese internet. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I don't see this as an issue of sensitivity or not. Miners are businesses that sell a service to Bitcoin users - the service of ordering transactions chronologically. They aren't charities. If some miners can't provide the service Bitcoin users need any more, then OK, they should not/cannot mine. Lots of miners have come and gone since Bitcoin started as different technology generations came and went. That's just business. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] soft-fork block size increase (extension blocks)
(at reduced security if it has software that doesnt understand it) Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change. A 1MB client wont even understand the difference between a 1MB and 8MB out payment. Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no? Can you walk through the UX for each case? If I am not misremembering, I think you've sided typically with the huge block, big data center only end of the spectrum. It would be Satoshi, that argued that. I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011: https://en.bitcoin.it/wiki/Scalability It says: *The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. * By much higher rates I meant VISA scale and by high end server I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream. And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app. So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth. -- ___ 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
By the time a hard fork can happen, I expect average block size will be above 500K. Yes, possibly. Would you support a rule that was larger of 1MB or 2x average size ? That is strictly better than the situation we're in today. It is, but only by a trivial amount - hitting the limit is still very likely. I don't want to see this issue come up over and over again. Ideally never. We shouldn't be artificially throttling organic growth of the network, especially not by accident. IMO it's not even clear there needs to be a size limit at all. Currently the 32mb message cap imposes one anyway, but if miners can always just discourage blocks over some particular size if they want to. But I can get behind a 20mb limit (or 20mb+N) as it represents a reasonable compromise: the limit still exists, it's far below VISA capacity etc, but it should also free up enough space that everyone can get back to what we *should* be focusing on, which is user growth! -- ___ 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
If the plan is a fix once and for all, then that should be changed too. It could be set so that it is at least some multiple of the max block size allowed. Well, but RAM is not infinite :-) Effectively what these caps are doing is setting the minimum hardware requirements for running a Bitcoin node. That's OK by me - I don't think we are actually going to exhaust the hardware abilities of any reasonable computer any time soon, but still, having the software recognise the finite nature of a computing machine doesn't seem unwise. That system can send a block of any size. It would require a change to the processing of any merkleblocks received. Not any size because, again, the remote node must buffer things up and have the transaction data actually in memory in order to digest it. But a much larger size, yes. However, that's a bigger change. -- ___ 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
The measure is miner consensus. How do you intend to measure exchange/merchant acceptance? Asking them. In fact, we already have. I have been talking to well known people and CEOs in the Bitcoin community for some time now. *All* of them support bigger blocks, this includes: - Every wallet developer I have asked (other than Bitcoin Core) - So far, every payment processor and every exchange company I know Gavin has also been talking to people about this. There's a feeling on this list that there's no consensus, or that Gavin and myself are on the wrong side of it. I'd put it differently - there's very strong consensus out in the wider community and this list is something of an aberration. -- ___ 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
And looking at the version (aka user-agent) strings of publicly reachable nodes on the network. (e.g. see the count at https://getaddr.bitnodes.io/nodes/ ) Yeah, though FYI Luke informed me last week that I somehow managed to take out the change to the user-agent string in Bitcoin XT, presumably I made a mistake during a rebase of the rebranding change. So the actual number of XT nodes is a bit higher than counting user-agent strings would suggest. I sort of neglected XT lately. If we go ahead with this then I'll fix things like this. -- ___ 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
Twenty is scary. To whom? The only justification for the max size is DoS attacks, right? Back when Bitcoin had an average block size of 10kb, the max block size was 100x the average. Things worked fine, nobody was scared. The max block size is really a limit set by hardware capability, which is something that's difficult to measure in software. I think I preferred your original formula that guesstimated based on previous trends to one that just tries to follow some average. As noted, many miners just accept the defaults. With your proposed change their target would effectively *drop* from 1mb to 800kb today, which seems crazy. That's the exact opposite of what is needed right now. I am very skeptical about this idea. I don't think us developers should be deciding things like whether or not fees are too high, too low, Miners can already attempt to apply fee pressure by just not mining transactions that they feel don't pay enough. Some sort of auto-cartel that attempts to restrict supply based on everyone looking at everyone else feels overly complex and prone to strange situations: it looks a lot like some kind of Mexican standoff to me. Additionally, the justification for the block size limit was DoS by someone mining troll blocks. It was never meant to be about fee pressure. Resource management inside Bitcoin Core is certainly something to be handled by developers. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
The prior (and seemingly this) assurance contract proposals pay the miners who mines a chain supportive of your interests and miners whom mine against your interests identically. The same is true today - via inflation I pay for blocks regardless of whether they contain or double spend my transactions or not. So I don't see why it'd be different in future. There is already a mechanism built into Bitcoin for paying for security which doesn't have this problem, and which mitigates the common action problem of people just sitting around for other people to pay for security: transaction fees. The article states quite clearly that assurance contracts are proposed only if people setting transaction fees themselves doesn't work. There's some reasonably good arguments that it probably won't work, but I don't assign very high weight to game theoretic arguments these days so it wouldn't surprise me if Satoshi's original plan worked out OK too. Of course, by the time this matters I plan to be sipping a pina colada on my private retirement beach :) It's a problem the next generation can tackle, as far as I am concerned. Considering the near-failure in just keeping development funded, I'm not sure where the believe this this model will be workable comes from Patience :) Right now it's a lot easier to get development money from VC funds and rich benefactors than raising it directly from the community, so unsurprisingly that's what most people do. Despite that, the Hourglass design document project now has sufficient pre-pledges that it should be possible to crowdfund it successfully once I get around to actually doing the work. And BitSquare was able to raise nearly half of their target despite an incredibly aggressive deadline and the fact that they hadn't shipped a usable prototype. I think as people get better at crafting their contracts and people get more experience with funding work this way, we'll see it get more common. But yes. Paying for things via assurance contracts is a long term and very experimental plan, for sure. one time cost. I note that many existing crowdfunding platforms (including your own) do not do ongoing costs with this kind of binary contract. Lighthouse wasn't written to do hashing assurance contracts, so no, it doesn't have such a feature. Perhaps in version 2. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. Yes indeed they were. Satoshis mechanism was more general than micropayment channels and could do HFT between any set of parties. As it happens, this cannot be made safe in the bitcoin protocol as deployed today, as there is no enforcement of the rule that miners include the most recent transaction in their blocks. Safe is relative - this is the same logic the original replace-by-fee argument uses. There's no enforcement that miners use any particular ordering of transactions. As I believe out of all proposed protocols Satoshi's is still the most powerful, I would suggest that any change to the semantics on nSequence be gated by a high bit or something, so the original meaning remains available if/when resource scheduling and update flood damping are implemented. That way people can try it out and if miners are breaking things too frequently by ignoring the chronological ordering people can abandon protocols that rely on it, and if they aren't they can proceed and benefit from the greater flexibility. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Mike, this proposal was purposefully constructed to maintain as well as possible the semantics of Satoshi's original construction. Higher sequence numbers -- chronologically later transactions -- are able to hit the chain earlier, and therefore it can be reasonably argued will be selected by miners before the later transactions mature. Did I fail in some way to capture that original intent? Right, but the original protocol allowed for e.g. millions of revisions of the transaction, hence for high frequency trading (that's actually how Satoshi originally explained it to me - as a way to do HFT - back then the channel concept didn't exist). As you point out, with a careful construction of channels you should only need to bump the sequence number when the channel reverses direction. If your app only needs to do that rarely, it's a fine approach.And your proposal does sounds better than sequence numbers being useless like at the moment. I'm just wondering if we can get back to the original somehow or at least leave a path open to it, as it seems to be a superset of all other proposals, features-wise. -- ___ 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 wrote an article that explains the hashing assurance contract concept: https://medium.com/@octskyward/hashing-7d04a887acc8 (it doesn't contain an in depth protocol description) -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
Very interesting Matt. For what it's worth, in future bitcoinj is very likely to bootstrap from Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily working towards Tor by default. So this approach will probably stop working at some point. As breaking PorcFest would kind of suck, we might want a ZeroConf/Rendezvous solution in place so local LANs can capture Bitcoin traffic away from Tor (with some notification to the user, presumably). On Tue, May 26, 2015 at 7:47 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote: On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote: On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote: Do any wallets actually do this yet? Not that I know of, but they do seed their address database via DNS, which you can poison if you control the LAN's DNS resolver. I did this for a Bitcoin-only Wi-Fi network I operated at a remote festival. We had well over a hundred lightweight wallets, all trying to connect to the Bitcoin P2P network over a very bandwidth-constrained Internet link, so I poisoned the DNS and rejected all outbound connection attempts on port 8333, to force all the wallets to connect to a single local full node, which had connectivity to a single remote node over the Internet. Thus, all the lightweight wallets at the festival had Bitcoin network connectivity, but we only needed to backhaul the Bitcoin network's transaction traffic once. Interesting! What festival was this? The Porcupine Freedom Festival (PorcFest) in New Hampshire last summer. I strongly suspect that it's the largest gathering of Bitcoin users at any event that is not specifically Bitcoin-themed. There's a lot of overlap between the Bitcoin and liberty communities. PorcFest draws somewhere around 1000-2000 attendees, a solid quarter of whom have Bitcoin wallets on their mobile devices. The backhaul was a 3G cellular Internet connection, and the local Bitcoin node and network router were hosted on a Raspberry Pi with some Netfilter tricks to restrict connectivity. The net result was that all Bitcoin nodes (lightweight and heavyweight) on the local Wi-Fi network were unable to connect to any Bitcoin nodes except for the local node, which they discovered via DNS. I also had provisions in place to allow outbound connectivity to the API servers for Mycelium, Blockchain, and Coinbase wallets, by feeding the DNS resolver's results in real-time into a whitelisting Netfilter rule utilizing IP Sets. For your amusement, here's the graphic for the banner that I had made to advertise the network at the festival (*chuckle*): http://www.mattwhitlock.com/bitcoin_wifi.png -- 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. 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] Scaling Bitcoin with Subchains
Hi Andrew, Your belief that Bitcoin has to be constrained by the belief that hardware will never improve is extremist, but regardless, your concerns are easy to assuage: there is no requirement that the block chain be stored on hard disks. As you note yourself the block chain is used for building/auditing the ledger. Random access to it is not required, if all you care about is running a full node. Luckily this makes it a great fit for tape backup. Technology that can store 185 terabytes *per cartridge* has already been developed: http://www.itworld.com/article/2693369/sony-develops-tape-tech-that-could-lead-to-185-tb-cartridges.html As you could certainly share costs of a block chain archive with other people, the cost would not be a major concern even today. And it's virtually guaranteed that humanity will not hit a storage technology wall in 2015. If your computer is compromised then all bets are off. Validating the chain on a compromised host is meaningless. -- 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
Hi Thomas, My problem is that this seems to lacks a vision. Are you aware of my proposal for network assurance contracts? There is a discussion here: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07552.html But I agree with Gavin that attempting to plan for 20 years from now is ambitious at best. Bitcoin might not even exist 20 years from now, or might be an abandoned backwater a la USENET. -- 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] A suggestion for reducing the size of the UTXO database
some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you can only spend confirmed UTXOs. I can't tell you how aggravating it is to have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for the last transaction I did to confirm first. All the more aggravating because I know, if I have multiple UTXOs in my wallet, I can make multiple spends within the same block. Andreas' wallet hasn't done that for years. Are you repeating this from some very old memory or do you actually see this issue in reality? The only time you're forced to wait for confirmations is when you have an unconfirmed inbound transaction, and thus the sender is unknown. -- 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] No Bitcoin For You
If capacity grows, fewer individuals would be able to run full nodes. Hardly. Nobody is currently exhausting the CPU capacity of even a normal computer currently and even if we did a 20x increase in load overnight, that still wouldn't even warm up most machines good enough to be always on. The reasons full nodes are unpopular to run seem to be: 1. Uncontrollable bandwidth usage from sending people the chain 2. People don't run them all the time, then don't want to wait for them to catch up The first can be fixed with better code (you can already easily opt out of uploading the chain, it's just not as fine-grained as desirable), and the second is fundamental to what full nodes do and how people work. For merchants, who are the most important demographic we want to be using full nodes, they can just keep it running all the time. No biggie. Therefore miners and other full nodes would depend on it, which is rather critical as those nodes grow closer to data-center proportions. This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down right now, but I showed years ago that you could keep up with VISA on a single well specced server with today's technology. Only people living in a dreamworld think that Bitcoin might actually have to match that level of transaction demand with today's hardware. As noted previously, too many users is simply not a problem Bitcoin has and may never have! -- 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] A suggestion for reducing the size of the UTXO database
Wallets are incentivised to do a better job with defragmentation already, as if you have lots of tiny UTXOs then your fees end up being huge when trying to make a payment. The reason they largely don't is just one of manpower. Nobody is working on it. As a wallet developer myself, one way I'd like to see this issue be fixed by making free transactions more reliable. Then wallets can submit free transactions to the network to consolidate UTXOs together, e.g. at night when the user is sleeping. They would then fit into whatever space is available in the block during periods of low demand, like on Sunday. If we don't do this then wallets won't automatically defragment, as we'd be unable to explain to the user why their money is slowly leaking out of their wallet without them doing anything. Trying to explain the existing transaction fees is hard enough already (I thought bitcoin doesn't have banks etc). There is another way: as the fee is based on a rounded 1kb calculation, if you go into the next fee band adding some more outputs and making a bigger change output becomes free for another output or two. But wallets don't exploit this today. -- 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] Virtual Notary.
Very nice Emin! This could be very useful as a building block for oracle based services. If only there were opcodes for working with X.509 ;) I'd suggest at least documenting in the FAQ how to extract the data from the certificate: openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -passin pass: | openssl x509 -text|less That's good enough to get started, but I note two issues: 1. X.509 is kind of annoying to work with: example code in popular languages/frameworks to extract the statement would be useful. 2. The stock price plugin, at least, embeds the data as text inside the X.509 certificate. That's also not terribly developer friendly and risks parsing errors undermining security schemes built on it. The way I'd solve this is to embed either a protocol buffer or DER encoded structure inside the extension, so developers can extract the notarised data directly, without needing to do any additional parsing. -- 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] A suggestion for reducing the size of the UTXO database
CPFP also solves it just fine. -- 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] Block Size Increase Requirements
* Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road from 1mb to 20mb where miners felt a need to throttle their block sizes artificially, for the exact reason you point out: propagation delays. But we don't *need* to have fancy protocol upgrades implemented right now. All we need is to demolish one bottleneck (the hard cap) so we can then move on and demolish the next one (whatever that is, probably faster propagation). Scaling is a series of walls we punch through as we encounter them. One down, onto the next. We don't have to tackle them all simultaneously. FWIW I don't think the GFW just triggers packet loss, these days. It's blocked port 8333 entirely. * I'd very much like to see someone working on better scaling technology ... I know StrawPay is working on development, So this request is already satisfied, isn't it? As you point out, expecting more at this stage in development is unreasonable, there's nothing for anyone to experiment with or commit to. They have code here, by the way: https://github.com/strawpay You can find their fork of MultiBit HD, their implementation library, etc. They've contributed patches and improvements to the payment channels code we wrote. * I'd like to see some better conclusions to the discussion around long-term incentives within the system. What are your thoughts on using assurance contracts to fund network security? I don't *know* if hashing assurance contracts (HACs) will work. But I don't know they won't work either. And right now I'm pretty sure that plain old fee pressure won't work. Demand doesn't outstrip supply forever - people find substitutes. -- 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] Block Size Increase
Alan argues that 7 tps is a couple orders of magnitude too low By the way, just to clear this up - the real limit at the moment is more like 3 tps, not 7. The 7 transactions/second figure comes from calculations I did years ago, in 2011. I did them a few months before the sendmany command was released, so back then almost all transactions were small. After sendmany and as people developed custom wallets, etc, the average transaction size went up. -- 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
There are certainly arguments to be made for and against all of these proposals. The fixed 20mb cap isn't actually my proposal at all, it is from Gavin. I am supporting it because anything is better than nothing. Gavin originally proposed the block size be a function of time. That got dropped, I suppose to make the process of getting consensus easier. It is the simplest thing that can possibly work. I would like to see the process of chain forking becoming less traumatic. I remember Gavin, Jeff and I once considered (on stage at a conference??) that maybe there should be a scheduled fork every year, so people know when to expect them. If everything goes well, I see no reason why 20mb would be the limit forever. -- 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] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY
Looks like a neat solution, Tier. -- 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] Block Size Increase
Hey Matt, OK, let's get started However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Probably because this list is not a good place for making progress or reaching decisions. Those are triggered by pull requests (sometimes). If you're wondering why now, that's probably my fault. A few days ago Wladimir posted a release timeline. I observed to Wladimir and Gavin in private that this timeline meant a change to the block size was unlikely to get into 0.11, leaving only 0.12, which would give everyone only a few months to upgrade in order to fork the chain by the end of the winter growth season. That seemed tight. Wladimir did not reply to this email, unfortunately. Perhaps he would like the issue to go away. It won't - if Bitcoin continues on its current growth trends it *will* run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. I'm afraid I have come to disagree. I no longer believe this community can reach consensus on anything protocol related. Some of these arguments have dragged on for years. Consensus isn't even well defined - consensus of who? Anyone who shows up? And what happens when, inevitably, no consensus is reached? Stasis forever? Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. I disagree. When the money supply eventually dwindles I doubt it will be fee pressure that funds mining, but as that's a long time in the future, it's very hard to predict what might happen. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). Many do because free transactions are broken - the relay limiter means whether a free transaction actually makes it across the network or not is basically pot luck and there's no way for a wallet to know, short of either trying it or actually receiving every single transaction and repeating the calculations. If free transactions weren't broken for all non-full nodes they'd probably be used a lot more. This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. I have two huge problems with this line of thinking. Firstly, no, the Bitcoin ecosystem is not well funded. Blockstream might be, but significant numbers of users are running programs developed by tiny startups, or volunteers who don't have millions in venture capital to play with. Arm-twisting the ecosystem into developing complicated Rube Goldberg machines in double quick time, just to keep the Bitcoin show on the road, is in fact the opposite of decentralisation - it will effectively exclude anyone who isn't able to raise large amounts of corporate funding from writing code that uses the Bitcoin network. Decentralisation benefits from simplicity, and bigger blocks are (in Gavin's words) the simplest thing that will work. My second problem is the claim that everyone is playing pretend about Bitcoin, except you guys. I would put it another way - I would say those people are building products and getting users, by making reasonable engineering tradeoffs and using systems that work. Yes, one day those systems might have to change. That's the nature of scaling. It's the nature of progress. But not today. Probably not tomorrow either. What I would like to see from Blockstream is a counter-proposal. So far you have made lots of vague comments that we all agree with - yes, decentralisation is good, yes some block size limit must exist, if only because computers are finite machines. What I don't see from you yet is a *specific and credible plan* that fits within the next 12 months and which allows Bitcoin to keep growing. Not some vague handwave like let's all use the Lightning network (which does not exist), or let's do more research (Gavin has done plenty of research), or but what about the risks (Bitcoin is full of risks). A plan, with dates attached, and a strong chance of actually being deployed in time. -- 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
Re: [Bitcoin-development] Block Size Increase
The only answer to this that anyone with a clue should give is it will very, very likely be able to support at least 1MB blocks roughly every 10 minutes on average for the next eleven years, and it seems likely that a block size increase of some form will happen at some point in the next eleven years, anything else is dishonest. Matt, you know better than that. Gavin neither lacks clue nor is he dishonest. He has been working on the assumption that other developers are reasonable, and some kind of compromise solution can be found that everyone can live with. Hence trying to find a middle ground, hence considering and writing articles in response to every single objection raised. Hence asking for suggestions on what to change about the plan, to make it more acceptable. What more do you want, exactly? And I'll ask again. Do you have a *specific, credible alternative*? Because so far I'm not seeing one. -- 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] Block Size Increase
I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. I have explained why I believe there is some urgency, whereby some urgency I mean, assuming it takes months to implement, merge, test, release and for people to upgrade. But if it makes you happy, imagine that this discussion happens all over again next year and I ask the same question. -- 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] Block Size Increase
These statements may even be true, but they're no logical conclusions even if they seem obvious to you. I don't think those claims are strictly true, specially because they involve predictions about what people will do. But if they're true they require some proof or at least some explanation. Thank you for your patience, Jorge. I have written up an explanation of what I think will happen if we run out of capacity: https://medium.com/@octskyward/crash-landing-f5cc19908e32 Now I'm going to go eat some dinner :) -- 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] Block Size Increase
The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public So your concern is just about the ordering and process of things, and not about the change itself? I have witnessed many arguments in IRC about block sizes over the years. There was another one just a few weeks ago. Pieter left the channel for his own sanity. IRC is not a good medium for arriving at decisions on things - many people can't afford to sit on IRC all day and conversations can be hard to follow. Additionally, they tend to go circular. That said, I don't know if you can draw a line between the ins and outs like that. The general public is watching, commenting and deciding no matter what. Might as well deal with that and debate in a format more accessible to all. If, instead, there had been an intro on the list as I think we should do the blocksize increase soon, what do people think? There have been many such discussions over time. On bitcointalk. On reddit. On IRC. At developer conferences. Gavin already knew what many of the objections would be, which is why he started answering them. But alright. Let's say he should have started a thread. Thanks for starting it for him. Now, can we get this specific list of things we should do before we're prepared? A specific credible alternative to what? Committing to blocksize increases tomorrow? Yes, doing more research into this and developing software around supporting larger block sizes so people feel comfortable doing it in six months. Do you have a specific research suggestion? Gavin has run simulations across the internet with modified full nodes that use 20mb blocks, using real data from the block chain. They seem to suggest it works OK. What software do you have in mind? -- 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] Block Size Increase
Can you please elaborate on what terrible things will happen if we don't increase the block size by winter this year? I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article: https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d It's a fairly simple estimate based on previous growth patterns. Because I love wild guesses and mine is that full 1 MB blocks will not happen until June 2017. OK, it could be. But do you think this debate will play out significantly differently if you are right, I am wrong, and we have this discussion next summer instead? Because in several years of watching these debates, I haven't seen much change in them. We've successfully reached consensus for several softfork proposals already. Are you sure about that? What if Gavin popped up right now and said he disagreed with every current proposal, he disagreed with side chains too, and there would be no consensus on any of them until the block size limit was raised. Would you say, oh, OK, guess that's it then. There's no consensus so might as well scrap all those proposals, as they'll never happen anyway. Bye bye side chains whitepaper. I just hope that by What we need to see right now is leadership you don't mean something like when Gaving and Mike agree it's enough to deploy a hardfork when you go from vague to concrete. No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is Bitcoin Core will wait and watch the fireworks when blocks get full, that would be showing leadership . albeit I believe in the wrong direction. It would, however, let people know what's what and let them start to make longer term plans. This dillydallying around is an issue - people just make vague points that can't really be disagreed with (more nodes would be nice, smaller pools would also be nice etc), and nothing gets done. no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present. I never said Bitcoin is broken in the long term. Far from it - I laid out my ideas for what will happen when the block subsidy dwindles years ago. But yes, it's hard for me to care overly much about what happens 30 years from now, for the same reason you probably care more about what happens tomorrow than what happens after you are dead. The further into the future you try and plan, the less likely your plans are to survive unscathed. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future. I think I see one of the causes of disagreement now. I will write more on the topic of what will happen if we hit the block size limit soon, maybe this evening. I have some other tasks to do first. Regardless, I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment that pushes traffic back below the pressure threshold and those users will most likely not come back any time soon. Ok, this is my plan: we wait 12 months, hope that your estimations are correct (in case that my guess was better than yours, we keep waiting until June 2017) and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. I disagree that'd be the outcome, but good, this is progress. Now we need to hear something like that from Wladimir, or whoever has the final say around here. With respect to the fee market: I think it's fairer to say Gavin wants a market to exist, and he also wants supply to be plentiful. 20mb limit doesn't actually mean every block will be 20mb the day after, no more than they're all 1mb today. Miners may discover that if they go beyond 5mb they have too many orphans and then propagation speed will have to be optimised to break through the next bottleneck. Scaling is always about finding the next bottleneck and removing it, ideally, before you hit it. -- 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] Block Size Increase
If his explanation was I will change my mind after we increase block size, I guess the community should say then we will just ignore your nack because it makes no sense. Oh good! We can just kick anyone out of the consensus process if we think they make no sense. I guess that means me and Gavin can remove everyone else from the developer consensus, because we think trying to stop Bitcoin growing makes no sense. Do you see the problem with this whole notion? It cannot possibly work. Whenever you try and make the idea of developer consensus work, what you end up with is I believe in consensus as long as it goes my way. Which is worthless. One thing is the Bitcoin core project where you could argue that the 5 committers decide (I don't know why Wladimir would have any more authority than the others). Because he is formally the maintainer. Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the patch. Game over. You cannot have committers fighting over what goes in and what doesn't. That's madness. There must be a single decision maker for any given codebase. Ok, so in simple terms, you expect people to have to pay enormous fees and/or wait thousands of blocks for their transactions to get included in the chain. Is that correct? No. I'll write an article like the others, it's better than email for more complicated discourse. As others have said, if the answer is forever, adoption is always the most important thing then we will end up with an improved version of Visa. This appears to be another one of those fundamental areas of disagreement. I believe there is no chance of Bitcoin ending up like Visa, even if it is wildly successful. I did the calculations years ago that show that won't happen: https://en.bitcoin.it/wiki/Scalability Decentralisation is a spectrum and Bitcoin will move around on that spectrum over time. But claiming we have to pick between 1mb blocks and Bitcoin = VISA is silly. Peter: your hypocrisy really is bottomless, isn't it? You constantly claim to be a Righteous Defender of Privacy, but don't even hesitate before publishing hacked private emails when it suits you. Satoshi's hacker had no illusions about your horrible personality, which is why he forwarded that email to you specifically. He knew you'd use it. You should reflect on that fact. It says nothing good about you at all. -- 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] Block Size Increase
What gives Bitcoin value aren't its technical merits but the fact that people believe in it. Much of the belief in Bitcoin is that it has a bright future. Certainly the huge price spikes we've seen were not triggered by equally large spikes in usage - it's speculation on that future. I quite agree that if people stop believing in Bitcoin, that will be bad. A fast way to bring that about will be to deliberately cripple the technology in order to force people onto something quite different (which probably won't be payment channel networks). I'd argue that if we didn't force through a 20MB fork now, and we ran into major network difficulties a year from now and had no other technical solutions, that maybe we would get nearly universal agreement I doubt it. The disagreement seems more philosophical than technical. If Bitcoin fell off a cliff then that'd just be taken as more evidence that block chains don't work and we should all use some network of payment hubs, or whatever the fashion of the day is. Or anyone who doesn't want to pay high fees is unimportant. See all the other justifications Gavin is working his way through on his blog. That's why I conclude the opposite - if there is no fork, then people's confidence in Bitcoin will be seriously damaged. If it's impossible to do something as trivial as removing a temporary hack Satoshi put in place, then what about bigger challenges? If the community is really willing to drive itself off a cliff due to political deadlock, then why bother building things that use Bitcoin at all? -- 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] Block Size Increase
It is an argument against my admittedly vague definition of non-controversial change. If it's an argument against something you said, it's not a straw man, right ;) Consensus has to be defined as agreement between a group of people. Who are those people? If you don't know, it's impossible to decide when there is consensus or not. Right now there is this nice warm fuzzy notion that decisions in Bitcoin Core are made by consensus. Controversial changes are avoided. I am trying to show you that this is just marketing. Nobody can define what these terms even mean. It would be more accurate to say decisions are vetoed by whoever shows up and complains enough, regardless of technical merit. After all, my own getutxo change was merged after a lot of technical debate (and trolling) . then unmerged a day later because it's a shitstorm. So if Gavin showed up and complained a lot about side chains or whatever, what you're saying is, oh that's different. We'd ignore him. But when someone else complains about a change they don't like, that's OK. Heck, I could easily come up with a dozen reasons to object to almost any change, if I felt like it. Would I then be considered not a part of the consensus because that'd be convenient? I'm sure that's not what the proponents of the size increase want, and I'm not defending 1 MB as a sacred limit or anything, but my question is where is the limit for them? 20mb is an arbitrary number, just like 1mb. It's good enough to keep the Bitcoin ecosystem operating as it presently does: gentle growth in usage with the technology that exists and is implemented. Gavin has discussed in his blog why he chose 20mb, I think. It's the result of some estimates based on average network/hardware capabilities. Perhaps one day 20mb will not be enough. Perhaps then the limit will be raised again, if there is sufficient demand. You are correct that no limit at all is a possible answer. More precisely, in that case miners would choose. Gavin's original proposal was 20mb+X where X is decided by some incrementing formula over time, chosen to approximate expected improvements in hardware and software. That was cool too. The 20mb figure and the formula were an attempt to address the concerns of people who are worried about the block size increase: a meet-in-the-middle compromise. Unfortunately it's hard to know what other kinds of meet-in-the-middle compromise could be made here. I'm sure Gavin would consider them if he knew. But the concerns provided are too vague to address. There are no numbers in them, for example: - We need more research - how much more? - I'm not against changing the size, just not now - then when? - I'm not wedded to 1mb, but not sure 20mb is right - then what? - Full node count is going down - then what size do you think would fix that? 100kb? - It will make mining more centralised - how do you measure that and how much centralisation would you accept? and so on. -- 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] Block Size Increase
Dear list, Apparently my emails are being marked as spam, despite being sent from GMail's web interface. I've pinged our sysadmin. It's a problem with the mailing list software, not your setup. BitPay could disable the phishing protections but that seems like a poor solution. The only real fix is to send from a non @bitpay.com email address. Gmail or Hotmail will work, I think. Yahoo won't: they enforce the same strict policies than bitpay does. -- 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] Block Size Increase
It is a trivial *code* change. It is not a trivial change to the economics of a $3.2B system. Hmm - again I'd argue the opposite. Up until now Bitcoin has been unconstrained by the hard block size limit. If we raise it, Bitcoin will continue to be unconstrained by it. That's the default continue as we are position. If it's not raised, then ... well, then we're in new territory entirely. Businesses built on the assumption that Bitcoin could become popular will suddenly have their basic assumptions invalidated. Users will leave. The technical code change would be zero, but the economic change would be significant. -- 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] Reusable payment codes
1. There will be a 1:1 relationship between a payment code owner and their identity. Bear in mind, the spec defines identity to mean: *Identity is a particular extended public/private key pair. * So that's not quite what is meant normally by identity. It's not a government / real name identity or an email address or phone number kind of identity. -- 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] Fwd: Reusable payment codes
Could you maybe write a short bit of text comparing this approach to extending BIP70 and combining it with a simple Subspace style store-and-forward network? -- 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
[Bitcoin-development] DevCore London
Next week on April 15th Gavin, Wladimir, Corey and myself will be at DevCore London: https://everyeventgives.com/event/devcore-london If you're in town why not come along? It's often the case that conferences can be just talking shops, without much meat for real developers. So in the afternoon I'll be doing two things: 1. Running a hackathon/workshop type event. The theme is contracts, but we can hack on whatever you all feel like. 2. My talk will actually be a live coding event. Writing contracts apps has become a lot easier in the past few years, and to prove it to you I will write a decentralised cross-platform Tor supporting document timestamping app that uses OP_RETURN outputs and has a nice GUI . in 30 minutes, on stage. Don't think it can be done? Turn up and see for yourself. See you there! -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Build your own nHashType
I don't think it's quite a blank check, but it would enable replay attacks in the form of sending the money to the same place it was sent before if an address ever receives coins again. Right, good point. I wonder if this sort of auto forwarding could even be a useful feature. I can't think of one right now. It's hard, though, because there is different data needs to be signed for each input. Yes but is that fundamental or is there a way to avoid it? That's what I'm getting at. Another possibility would be to put the previous scriptPubKey and previous output value at the END of the serialized transaction, so that you could make use of some sort of a signature hash midstate. Interesting idea! I don't agree it's messy. If anything it should be simpler than what we have today - the need to edit a transaction *in the middle* means that sighash computation involves constantly reserializing a transaction before it even gets to be hashed. Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Consider what happens with very large transactions, like a big assurance contract that might have thousands of inputs and be multiple megabytes in size. Obviously such large transactions cannot happen today, but there is user demand for giant contracts (or at least, users tell me there is, whether they'd actually do it for real is a bit unclear). -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Double spending and replace by fee
I've written a couple of blog posts on replace by fee and double spending mitigations. They sum up the last few years (!) worth of discussions on this list and elsewhere, from my own perspective. I make no claim to be comprehensive or unbiased but I keep being asked about these topics so figured I'd just write up my thoughts once so I can send links instead of answers :) And then so can anyone who happens to agree. (1) Replace by fee scorched earth, a counter argument: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d This article lays out the case against RBF-SE and argues it is harmful to Bitcoin. (2) Double spending and how to make it harder: https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 This article summarises a couple of double spending incidents against merchants and then discusses the following techniques: 1. Risk analysis of transactions 2. Payment channels 3. Countersigning by a trusted third party 4. Remote attestation 5. ID verification 6. Waiting for confirmations 7. Punishment of double spending blocks I hope the material is useful / interesting. -- 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] BIP32 Index Randomisation
It sounds like the main issue is this is a web wallet server of some kind. If the clients were SPV then they'd be checking their own balances and downloading their own tx history, which would mean the coordination tasks could be done by storing encrypted blobs on the server rather than the server itself having insight into what's going on (see: Subspace). So whilst you might be able to use some scheme to avoid the server knowing the xpubkey, if the server still knows all addresses and all transactions because the clients are web wallets . is there any point? It seems like maybe going from server knows everything to server knows 95% of everything: maybe not worth the engineering cost. -- 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] Proof of Payment
As soon as that PaymentRequest leaves the wallet on its way to the hotel server, it is up for grabs Is it? I'm assuming TLS is being used here. And the hotel server also has a copy of the PaymentRequest, as the hotel actually issued it and that's how they're deciding the receipt is valid. So I don't know how it could be stolen unless the attacker can break TLS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violation? If so, what about blockchain.info? It'd be shooting ourselves in the foot to try and forbid block explorers given how useful they are. If someone non-maliciously runs some nodes with debug logging turned on, and makes full system backups every night, and keeps those backups for years, are they in violation of whatever pseudo-law is involved? I think it's a bit early to think about these things right now. Michael Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be interested to know their thoughts on all of this. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
I'm not talking about keeping logs, I mean purporting to be a network peer in order to gain a connection slot and then not behaving as one (not relaying transactions) That definition would include all SPV clients? I get what you are trying to do. It just seems extremely tricky. -- 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] Proof of Payment
Hi Kalle, I think you're thinking along the right lines, but I am skeptical that this protocol adds much. A saved payment request is meant to be unique per transaction e.g. because the destination address is unique for that payment (for privacy reasons). Where would you store the signed payment request? Probably in the wallet. You could just extract the metadata that's useful for UI rendering into a separate structure and then encrypt the original full payment request under the wallet key. At least this is how I imagine it would work. So then, if someone can steal a payment request they can probably steal the wallet signing keys too, and thus signing a challenge with the wallet keys doesn't add much. It means the wallet doesn't have to store the PaymentRequest encrypted. But AFAICT that's about all it does. Do you agree with this analysis? -- 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] BIP32 Index Randomisation
You are killing us Mike! :) We really don't like to think that BWS is a webwallet. Note that private keys are not stored (not even encrypted) at the server. Sure, sorry, by web wallet I meant a blockchain.info/CoPay type setup where the client has the private keys and signs txns, but otherwise relies on the server for learning about the wallet contents. I tend to call wallets where the server has the private key BitBanks but I don't know if anyone else uses this terminology. It might just be a personal quirk of my own ;) we think having some visibility of the wallet by the multisig facilitator will make the user experience much better (e.g: mobile notifications). Fair enough. Yes, push notifications to mobiles in a decentralised way is rather a hard problem. I think what Gregory suggested is then the best approach for you to do what you want. Whether it's worth the additional complexity is something I don't have any feedback on, only you can judge that. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
Don't SPV clients announce their intentions by the act of uploading a filter? Well they don't set NODE_NETWORK, so they don't claim to be providing network services. But then I guess the Chainalysis nodes could easily just clear that bit flag too. What I'd actually like to see is for network users to pay for the node resources that they consume It's not quite pay-as-you-go, but I just posted a scheme for funding of network resources using crowdfunding contracts here: https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064 That comment doesn't have any kind of provision for access control, but group signatures could be extended in both directions: the server proves it was a part of the group that was funded by the contract, and the client proves it was in group that funded the contract, but it's done in a (relatively) anonymous way. Then any client can use any node it funded, or at least, buy priority access. But it's rather complicated. I'd hope that nodes can be like email accounts: yes they have a cost but in practice people everyone gets one for free because of random commercial cross-subsidisation, self hosting and other things. -- 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
b) Creation date is just a short-term hack. I agree, but we need things to be easy in the short term as well as the long term :) The long term solution is clearly to have the 12 word seed be an encryption key for a wallet backup with all associated metadata. We're heading in that direction one step at a time. Unfortunately it will take time for wallets to start working this way, and all the pieces to fall into place. Restoring from the block chain will be a semi regular operation for users until then. WRT version number I have no real strong feelings about this. But representing short pieces of binary data as words is so convenient, it seems likely that it could be similar to addresses: people find other uses for this mechanism beyond just storing a raw private key. Bitcoin addresses have versions and that's proven to be useful several times, even though in theory an address is just a hash of a pubkey. -- 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] BIP for standard multi-signature P2SH addresses
bitcoinj also uses this convention. -- 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
Sigh. The wallet words system is turning into kind of a mess. I thought the word list is in fact not a fixed part of the spec, because the entropy is a hash of the words. But perhaps I'm misunderstanding something. The main problem regular SPV wallets have with BIP39 is that there is no birth time included in the data. Therefore we must ask users to write down a timestamp as well, so we know where to start rescanning the chain. It sounds like the Electrum version doesn't fix this, so now we have at least FIVE incompatible results from a 12 word list: - Electrum v2 with a version number but no date - myTREZOR with no version and no date and BIP44 key derivation. Some seeds I believe are now being generated with 24 words instead of 12. - MultiBit HD with no version and a date in a custom form that creates non-date-like codes you are expected to write down. I think BIP32 and BIP44 are both supported (sorta). - GreenAddress with no version, no date and BIP32 - Other bitcoinj based wallets, with no version and a date written down in normal human form, BIP32 only. I really hope we can recover from this somehow because otherwise all wallets will have to provide the user with a complicated matrix of possibilities and software combinations, and in practice many won't bother so these word combinations will actually end up being wallet specific for no particularly good reason, just very minor details like the presence or absence of single fields. It feels like we somehow fell flat on our faces just before the finishing line. This is deeply unfortunate. Compatibility and UX consistency is important! Currently, I don't have any bright ideas for how to get everyone back onto the same page with a fully compatible system that is acceptable to all. If anyone else has suggestions, I'm all ears. -- 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
I'd like to offer that the best practice for the shared wallet use case should be multi-device multi-sig. Sure. But in practice people will want to have a pool of spending money that they can spend when they are out and about, and also with one click from their web browser on their primary computer, and maybe also on their games console, etc etc. I don't think we can realistically tell people to *always* use clever multi-device wallets - there will always be a desire to have a convenient hot wallet that's synchronised between different devices. -- 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
Users will want to have wallets shared between devices, it's as simple as that, especially for mobile/desktop wallets. Trying to stop them from doing that by making things gratuitously incompatible isn't the right approach: they'll just find workarounds or wallet apps will learn how to import seeds from other apps. Better to just explain the risks and help people mitigate them. On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine vois...@gmail.com wrote: 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 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
Nice, Andrew. Just one minor point. SPV clients do not need to maintain an ever growing list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and thus has O(1) disk usage. Re-orgs past the event horizon cannot be processed but are assumed to be sufficiently rare that manual intervention would be acceptable. On Mon, Mar 2, 2015 at 8:48 AM, Andrew Miller amil...@cs.umd.edu wrote: We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have written a “systemization” paper about Bitcoin-related research. It’s going to appear in the Oakland security conference later this year (IEEE Security and Privacy) but we wanted to announce a draft to this community ahead of time. http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf One of the main goals of our work is to build a bridge between the computer science research community and the cryptocurrency community. Many of the most interesting ideas and proposals for Bitcoin come from this mailing list and forums/wikis/irc channels, where many academic researchers simply don’t know to look! In fact, we started out by scraping all the interesting posts/articles we could find and trying to figure out how we could organize them. We hope our paper helps some of the best ideas and research questions from the Bitcoin community bubble up and inspires researchers to build on them. We didn’t limit our scope to Bitcoin, but we also decided not to provide a complete survey of altcoins and other next-generation cryptocurrency designs. Instead, we tried to explain all the dimensions along which these designs differ from Bitcoin. This effort has roughly been in progress over two years, though it stopped and restarted several times along the way. If anyone has comments or suggestions, we still have a week before the final version is due, and regardless we plan to continue updating our online version for the forseeable future. -- 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
Congrats Thomas! Glad to see Electrum 2 finally launch. * New seed derivation method (not compatible with BIP39). Does this mean a 12 words wallet created by Electrum won't work if imported into some other wallet that supports BIP39? Vice versa? This seems unfortunate. I guess if seeds are being represented with 12 words consistently, people will expect them to work everywhere. -- 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
Does this not also require the BT publication of the script for a P2SH address? You mean if the URI you're serving is like this? bitcoin:3aBcD?bt= Yes it would. I guess then, the server would indicate both the script, and the key within that script that it wanted to use. A bit more complex but would still work to save URI space. -- 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] Providing Payment Request within URI
Andreas' wallet supports this, but don't do it. Payment requests can get larger in future even without signing. Exploding the capacity of a QR code is very easy. Instead, take a look at the Bluetooth/NFC discussion happening in a different thread. On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev olega...@gmail.com wrote: Hi, I wonder if there is a standard way to put Payment Request data into bitcoin: URI or directly into QR code. The goal is to allow device to generate a multi-output payment request on its own, without relying on the server and x509 certificates. When scanned via QR code from, say, POS, it's pretty secure, so no additional authentication needed. I'd like something like this: bitcoin:?r=data://base64url-encoded-payment-request If there's no standard for that, would it be a good idea to extend BIP72 this way? -- 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] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)
This happened to one of the merchants at the Bitcoin 2013 conference in San Jose. They sold some T-shirts and accepted zero-confirmation transactions. The transactions depended on other unconfirmed transactions, which never confirmed, so this merchant never got their money. Beyond the fact that this risk can be priced in when enough data is available, I'd be interested to talk to this merchant and dig into what happened a bit. For example: 1. Was the dependent tx non-standard? 2. Was it double spent? 3. Could a wallet have co-operated with the P2P network to detect and flag whatever the issue was? My own experience has been that when this happens, it's usually not the result of outright maliciousness (especially not at a Bitcoin t-shirt seller at a Bitcoin conference!) but rather something messed up somewhere and the software in use just didn't detect it well enough. -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
DHKE will not improve the situation. Either we use a simple method to transfer a session key or a complex method. You're right that just sending the session key is simpler. I originally suggested doing ECDHE to set up an encrypted channel for the following reasons: 1. URIs are put in QR codes more often than NFC tags. QR codes have limited space. The more stuff you pack into them, the slower and flakier the scanning process becomes. For normal wallets, doing ECDH over secp256k1 to derive a session key means we can reuse the address that was put in the URI already for pre-BIP70 wallets, thus we don't have to expand the URI at all except perhaps to flag that crypted Bluetooth connections are supported. Win! 2. If the wallet is a watching wallet, this won't work and in that case you would need to put a separate key into the URI. However, this key is ephemeral and does not need to be very strong. So we can generate a regular secp256k1 key and then put say 5-8 prefix bytes into the URI as a new parameter. The public key can then be provided in full in the clear over the Bluetooth connection and the session key derived. If we put the session key into the URI in full, then we could not use this trick. Win! 3. It's quite common in low tech scenarios like little coffee shops to just print a QR code and put it in the menu, or sticky tape it to the back wall of the shop. In these cases, it's possible that the device is actually hanging around in the shop somewhere but having the QR code somewhere larger and more accessible than the shop devices screen is highly convenient. However it means the data is entirely static. Putting/reusing an identity key from the URI means the session keys are always unique and known only to both devices, even though the bootstrap data is public. 4. Doing ECDHE to derive the keys means we can derive a MAC key as well as an AES key. Otherwise you have the issue of exchanging both, which again uses up valuable bootstrap space. So for a small increase in session setup complexity we potentially avoid troubling problems down the line where people the same functionality from NFC and QR code based bootstrap, but we can't provide it. These discussions keep coming up. I think the next step is for someone to upgrade Andreas' wallet to support encrypted connections and the TBIPs, to see what happens. Re: the h= parameter. I only objected to requiring this when the payment request is also signed. It adds complexity, uses space, and the rationale was the PKI can't be trusted even though it's been used to protect credit card payments for 20 years without any issues. In the case of unsigned payment requests, sure ... but with a proper implementation of an encrypted Bluetooth channel it'd be unnecessary as the channel establishment process would guarantee authenticity anyway. But don't let me hold you guys back! I'd rather see something that works than an endless debate about the perfect arrangement of hashes and URI parameters :) -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
I read from your answer that even if we use ECDHE, we can't use it for every situation. Which situations do you mean? I think it can be used in every situation. It's the opposite way around - a fixed session key in the URI cannot be used in every situation. -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
At the moment I'm also modifying BitPay's memo field to contain 'ack', as Andreas' wallet otherwise reports a failure if I transmit the original via Bluetooth. :-) Huh? -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
But via Bluetooth it checks for 'ack' directly: We need a BIP70 conformance suite really. There are so many deviations from the spec out there already and it's brand new :( -- 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback
I don't see how you propose to treat the bitcoin address as a secp256k1 public key, or do you mean something else? Sorry, I skipped a step. I shouldn't make assumptions about what's obvious. The server would provide the public key and the client would convert it to address form then match against the URI it has scanned. If it didn't match, stop at that point. -- 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] bloom filtering, privacy
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No, I think it's less efficient (for the client).
Quick sums: blocks with 1500 transactions in them are common today. But
Bitcoin is growing. Let's imagine a system 10x larger than today. Doesn't
seem implausible to reach that in the next 5-10 years, so 15,000
transactions. Each transaction has multiple elements we might want to match
(addresses, keys, etc).
Let's say the average tx contains 5 unique keys/elements. That's the base
case of {1 input, 2 outputs} without address reuse, plus fudged up a bit
for multi-sends then down a bit again for address reuse.
15,000*5=75,000 unique elements per block. With an FP rate of 0.1% we get:
http://hur.st/bloomfilter?n=75000p=0.001
131.63KB per block extra overhead.
144 blocks in a day, so that's 18mb of data per day's worth of sync to pull
down over the network. If you don't start your wallet for a week that's 126
megabytes of data just to get started.
Affordable, yes (in the west). Fast enough to be competitive? Doubtful. I
don't believe that even in five years mobiles will be pulling down and
processing that much data within a few seconds, not even in developed
countries.
But like I said, I don't see why it matters. Anyone who is watching the
wire close to you learns which transactions are yours, still, so it doesn't
stop intelligence agencies. Anyone who is running a node learns which
transactions in the requested block were yours and thus can follow the tx
chain to learn which other transactions might be yours too, no different to
today. If you connect to a single node and say give me the transactions
sending money to key A in block N, it doesn't matter if you then don't
request block N+6 from the same peer - they know you will request it
eventually anyway, just by virtue of the fact that one of the transactions
they gave you was spent in that block.
--
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] bloom filtering, privacy
For downloading transactions unless you frequently receive transactions you wont be fetching every block. Or are you assuming bloom filters dialled up to the point of huge false positives? You said otherwise. Well, what I mean is, bitcoinj already gets criticised for having very low FP rates, but even with those rates we're applying them to hundreds of thousands of transactions per sync. So it's still enough FPs to trigger at least one per block, often several, yet people tell us this isn't enough to give meaningful privacy. Relatedly I think bitcoin could do with a store-and-forward message bus with privacy and strong reliability via redundancy (but less redundancy maybe than consensus all-nodes must receiving and agree and store forever). Yup, see here: https://www.bitcoinauthenticator.org/subspace/ https://groups.google.com/forum/#!topic/bitcoinj/_S15jo5mcDI Subspace looks like it's developing into what we need. You seem to be saying at one point that Tor is useless against pervasive eavesdropper threat model No, Tor is effective against in that threat model. What I meant is that without Tor, someone doing wire intercepts isn't going to be fazed by using multiple peers together, and with Tor it's not clear that syncing from multiple peers in parallel gives much an additional win. Also, getting Tor practical enough to activate by default is tricky. Though the same people who are doing Subspace are trying it out to see what happens. secondly that other types of attackers are disinterested (how do we know that?) or maybe that you dont care about privacy vs them (maybe some users do!) Some of my opinions are based on experience of HTTPS deployments, where many of the same issues apply. It would certainly be nice to get real privacy from a wider range of attackers but nothing (current situation) is clearly worse; using block bloom filters we'd make the pervasive case harder work, and the nosy full node learn nothing. Yes, but what's the best way to fix that? The calculation goes like this: we have ~80 hours of hacking time to spend on privacy this quarter. Do we: a) Do wire encryption b) Make Bloom filter clients smarter c) Optimise Tor d) Do a new PIR protocol from scratch and possibly run out of time having failed to launch Of these (d) is the least appealing to me, especially because I don't feel like submitting SPV related stuff to Bitcoin Core any more. If I were to work on the protocol it'd be in the context of Bitcoin XT, which rules out consensus changes or other things that rely on miners. Wire encryption would probably raise the bar for our spooky friends quite a lot, with minimal effort. The ROI looks good, compared to more complex PIR. -- 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] Bitcoin ATM
Hi Fikret, This is the wrong mailing list for such questions. Most Bitcoin ATM's are commercial products anyway and don't accept contributors. If you find one that is different, it's better to contact them directly. On Fri, Feb 20, 2015 at 5:19 PM, Fikret AKIN i...@fikretakin.com wrote: Hello, I want to improve the Bitcoin ATM, which way do you think I should continue Do you have suggestions? Thanks, Fikret AKIN -- 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 -- 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] bloom filtering, privacy
Ah, I see, I didn't catch that this scheme relies on UTXO commitments (presumably with Mark's PATRICIA tree system?). If you're doing a binary search over block contents then does that imply multiple protocol round trips per synced block? I'm still having trouble visualising how this works. Perhaps you could write down an example run for me. How does it interact with the need to download chains rather than individual transactions, and do so without round-tripping to the remote node for each block? Bloom filtering currently pulls down blocks in batches without much client/server interaction and that is useful for performance. Like I said, I'd rather just junk the whole notion of chain scanning and get to a point where clients are only syncing headers. If nodes were calculating a script-(outpoint, merkle branch) map in LevelDB and allowing range queries over it, then you could quickly pull down relevant UTXOs along with the paths that indicated they did at one point exist. Nodes can still withhold evidence that those outputs were spent, but the same is true today and in practice this doesn't seem to be an issue. The primary advantage of that approach is it does not require a change to the consensus rules. But there are lots of unanswered questions about how it interacts with HD lookahead and so on. -- 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] bloom filtering, privacy
This is talking about a committed bloom filter. Not a committed UTXO set. I read the following comment to mean it requires the UTXO commitments. Otherwise I'm not sure how you prove absence of withholding with just current block structures+an extra filter included in the block: but with the bloom commitment (and UTXO trie organised commitment) he can verify that the positive hits are correct via the merkle path, and that the false positives are not being wrongly withheld by obtaining merkle path proof that they are not in the trie -- 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] bloom filtering, privacy
So now they ask a full node for merkle paths + transactions for the addresses from the UTXO set from the block(s) that it was found in. This is the part where I get lost. How does this improve privacy? If I have to specify which addresses are mine in this block, to get the tx data, the node learns which addresses are mine at this point, no? Also, are you saying each block needs a record of the entire UTXO set at the time the block was made? I'm not sure how to parse this sentence. Could you please walk me through precisely what happens and what data is sent, once I learn that a block has interesting data in it? -- 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] bloom filtering, privacy
It's a straight forward idea: there is a scriptpubkey bitmap per block which is committed. Users can request the map, and be SPV confident that they received a faithful one. If there are hits, they can request the block and be confident there was no censoring. OK, I see now, thanks Gregory. You're right, the use of UTXO set in that context was confusing me. If I go back to when we first did Bloom filtering and imagine the same proposal being made, I guess I would have been wondering about the following issues. Perhaps they have solutions: 1. Miners have to upgrade to generate the per-block filters. Any block that doesn't have such a filter has to be downloaded in full, still. So it would have taken quite a while for the bandwidth savings to materialise. 2. If checking the filter isn't a consensus rule, any miner who builds a wrong filter breaks the entire SPV userbase. With per-node filtering, a malicious or wrong node breaks an individual sync, but if the wallet user notices they don't seem to be properly synchronised they can just press Rescan chain and most likely get fixed. In practice broken nodes have never been reported, but it's worth considering. 3. Downloading full blocks is still a lot of data. If you have a wallet that receives tips a couple of times per day, and you open your wallet once per week, then with 1mb blocks you would be downloading ~14mb of data each time. Pretty pokey even on a desktop. Much sadness if you're on mobile. 4. Header size is constant, but per-block filters wouldn't be. So even the null sync would download more data as the network got busier. Of course Bloom filtering has the same scaling problem, but only between hard disk - RAM - CPU rather than across the network. 5. Is it really more private? Imagine we see a hit in block 100, so we download the full block and find our transaction. But now we must also learn when that transaction is spent, so we can keep the wallet-local UTXO set up to date. So we scan forward and see another hit in block 105, so now we download block 105. The remote node can now select all transactions in block 105 that spend transactions in block 100 and narrow down which txs are ours. If we are watching a wallet that does multi-sends then it feels like this problem gets much worse. I'd really like to find a solution that has O(1) scaling on sync. If we see nodes just as sources of UTXO data then shovelling the client (tx, existing merkle path) pairs keyed off script prefixes would (with one additional index) be O(1) and provide the same security guarantees as Bloom filtering today. It creates lots of other problems to solve, but at least it would scale into the forseeable future. -- 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] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
He didn't said a project for all possible language bindings, just java bindings. Other languages' bindings would be separate projects. Yes/no/sorta. Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages like Scala, Kotlin, Ceylon, etc. It makes more sense to talk about bindings to particular runtimes these days, rather than particular languages. -- 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] replace-by-fee v0.10.0rc4
history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. How many thousands of BTC must be stolen by miners before you'd agree that it has, in fact, happened? (https://bitcointalk.org/index.php?topic=321630.0) Hmm. I think this is a disagreement over the term massive. I was meaning we don't see double spending like we see carding fraud in the traditional online payments world. We can talk about Finney attacks by linking to specific discussions of specific events, because they are very rare, which is why merchants generally ignore the possibility. I didn't mean the numeric value of lost coins added up so far. -- 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] replace-by-fee v0.10.0rc4
You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Fraudulent in what sense? If you mean the legal term, then you'd use the legal beyond reasonable doubt test. You mined a double spend that ~everyone thinks came 5 minutes later once? OK, that could be a fluke. Reasonable doubt. You do it 500 times in a row? Probably not a fluke. If you mean under a technical definition then I think Tom Harding has been researching this topic, though I've only kept half an eye on it. I guess it's some statistical approximation of the above, i.e. sufficient to ensure good incentives with only small false positive losses. Sort of like how the block chain algorithm already works w.r.t orphans. -- 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] replace-by-fee v0.10.0rc4
1. They won't be attacking Bitcoin, they will attack merchants who accept payments with 0 confirmations. Which is basically all of them other than exchanges. Any merchant that uses BitPay or Coinbase, for instance, or any physical shop. If you want to play word games and redefine Bitcoin to be something other than what people are actually using, go right ahead. You will win the argument under your own definitions which nobody else is using. In your scenario I won't be able to get hamburgers for free because people will stop selling them for ordinary bitcoin transactions. Most will say, you know what, just pay me with Visa instead. And a few might knuckle down and set up some network of PKI-like trusted third parties that interacts with the block chain in some way. Though eventually, if that were to happen, cunning merchants will notice that having received a transaction counter-signed by a TTP they don't actually have to broadcast it or pay miner fees at all. They can just keep it around in their wallet and pass it along to the next guy when they purchase something with those coins. Eventually whoever ends up not being able to find a matching TTP gets to be the sucker who pays all the miner fees at once, because he is the only one who actually needs their services. -- 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] replace-by-fee v0.10.0rc4
You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. There have been lots of e-cash schemes proposed in the academic literature that work like this, or variants of it. Schemes where participants are anonymous until they double spend are popular. Let's re-write your proposal but substituting the word notary for miner: To profit, the *miner* would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. That's the exact argument we're having. The assertion is that a rational notary would kill his own business to increase his profits in the next few hours. So you're just arguing that a notary is different to a miner, without spelling out exactly why. Does the notary have to make a big up front investment? If so, why is that different to mining investment? Is the notary non-anonymous and afraid of being charged with payment fraud? If so, note that big miners do lots of non-anonymous things too, like renting warehouses and importing specialised equipment. Is it because of the big up front collateral they're meant to have lying around? If so, how do you ensure a fluid market for notaries? -- 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] replace-by-fee v0.10.0rc4
But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as 1 of 10 hamburgers are free if they have 10% of the total hashpower. Yes, like any P2P network Bitcoin cannot work if a sufficiently large number of miners decide to attack it. This is an ancient argument. It came up the moment Bitcoin was first invented. But this argument could have been made at any time in Bitcoin's entire history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. Perhaps the system is not as simple as you boil it down to be. Anyway, what would happen in that event is within a few days some people would stop selling Bitcoin for hamburgers, others would find workarounds, and the fees collected from the double spends would be worth very little. Nobody wins. So would you take a responsibility for pushing the approach which isn't game-theoretically sound? The approach is how Bitcoin has always worked. People have been using game theory to predict the imminent demise of Bitcoin since I first found it. Just one example: Bitcoin will collapse when the 50-25 BTC drop happens was promoted as a dead cert thing by game theorists. Every miner becomes unprofitable and stops at once! So far game theory based predictions tend to be proven wrong by reality, so this sort of argument doesn't impress me much. Anyway, going around this loop again is pointless. I brought up the counter argument so people who see this thread don't mistakenly think Peter's position is some kind of de-facto consensus about how Bitcoin should work. Not because I love rehashing the same arguments every six months ad nauseum. -- 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] replace-by-fee v0.10.0rc4
Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks. -- 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] replace-by-fee v0.10.0rc4
So you're just arguing that a notary is different to a miner, without spelling out exactly why. I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you are saying because notaries have identity, brand awareness and because they have big up front bonds, that means they will be trustworthy. Well, sure. It's the same model governments use and is why being a money transmitter in the USA is so difficult: you need to put up large sums of money as collateral and have your fingerprints taken 48 times. *Then* you can start advertising to get customers! The reason mining is such a nice model is it doesn't have these sorts of requirements. As notaries can be small operations . [snip] .. (almost every large organization in the world have some unallocated funds somewhere). Which is it? Are notaries small operations or large operations? I think exploring new consensus models with semi-trusted notaries is interesting, but it's not Bitcoin. Depending on that which isn't guaranteed is bd, and breaking other people's assumptions is by itself NOT an attack if there never was a guarantee or even as little as an implicit understanding it is safe. Please don't try and apply this logic in the real world :( Rephrased: *That's a nice house. I noticed it's made of wood. I'm going to start fires until it burns down, because there is no guarantee your house won't burn down in future and it's important you understand that wooden houses aren't safe. Really I'm just doing you a favour*. Don't get me wrong. I'm all for what *you're* doing - please do continue to research and explore alternative trust configurations! This is helpful and useful work. Perhaps we will find something that solves the burger problem in a way that satisfies everyone. I'm really not a fan of Peter's approach, which is hey let's try and cause as many problems as possible to try and prove a point, without having created any solutions. Replace-by-fee-scorched-earth doesn't work and isn't a solution. Miners can easily cut payment fraudsters in on the stolen money, and as they'd need to distribute custom double-spending wallets to make the scheme work it'd be very easy to do. Your also ssume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Why? You think ability to make payments in a few seconds is some irrelevant curiousity? Let's put it this way. If BitPay's business model evaporates tomorrow, along with all the merchants they support, do you think that'd have any effect on Bitcoin's value? If not, why not? -- 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] replace-by-fee v0.10.0rc4
So anyway, in my opinion, it is actually great that Bitcoin is still relatively small: we have an opportunity to analyze and improve things. But you seem to be hostile to people who do that (and who do not share your opinion), which is kinda uncool. To clarify once more, I'm all for people researching and building ways to make Bitcoin better and safer. And debating that here is cool too. The replace by fee patches don't do this; as you said yourself the whole scorched earth thing makes no sense. It's not a solution to anything and it's important people realise that. Perhaps it will help if I spell out why this whole approach won't work (but can easily damage bitcoin a lot along the way). Normal Bitcoin nodes pick which transaction to put into a block by simply selecting whichever they saw arrive first, as determined by the arrival order of network packets. This rule is simple and has multiple advantages for people using Bitcoin to buy and sell things. Replace-by-fee changes this so nodes select whichever chain of unconfirmed transactions pays the highest miner fees. Up until the point that a transaction appears in a block, anyone can broadcast a double spend (or a spend of an unconfirmed transaction) which pays higher fees than before, causing that tx chain to become the candidate for chain inclusion. Peter argues that this is stable and makes unconfirmed transactions safe because a fraudster can buy something, walk out of the shop, and broadcast a double spend with a higher fee. But then the merchant can re-spend the original payment back to themselves with an *even* higher fee than that. Then the fraudster can re-spend their double spend with an *even* higher fee than that, and so on back and forth, until *all* the money has been spent to miner fees. Thus the merchant loses their goods but the fraudster has still paid in some sense because they don't get the money either. This argument makes no sense for two reasons. The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a double spend this button, to make the scheme work the dishonest miners must create and distribute such a wallet that implements the whole scorched-earth protocol. At that point it's easy for miners to reward the payment fraudster with some of the stolen money the merchant lost, meaning it now makes sense for the fraudster to always do this. The situation isn't stable at all. The second is that it incentivises competitors to engage in payment fraud against each other. A big rich coffee shop chain that is facing competition from a small, scrappy newcomer can simply walk into the new shop and buy things, then trigger the scorched earth. Even with no miner collaboration, this means the big company is down the cost of the product *but* so is the little company who lost everything. Whoever can outspend the other wins. We don't really need game theory to tell us that this plan is a bad idea. Just imagine trying to explain it to an actual shop keeper. They would think you were crazy. Bitcoin is already a hard enough concept to understand without throwing into the mix anyone can burn the money they gave you after walking out of the shop. -- 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] replace-by-fee v0.10.0rc4
I see no fundamental difference in outcome from miner collusion in scorched-fee (which isn't guaranteed to pay the right pool!) and miner collusion in knowingly mining a doublespend transaction. Well, they're the same thing. Replace-by-fee *is* miner collusion in knowingly mining a double spend, just triggered in a certain way. Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. Zero-conf needs something else for security. A guarantee it can not be doublespent in the relevant time frame. I think this is the core point which many of these debates revolve around. No payment system provides *guarantees*, though some are stronger than others. All they do is manage risk. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
If you're interested in working on mining decentralisation, chipping away at getblocktemplate support would be a better path forward. It's possible to have decentralised pooled mining - I know it sounds like a contradiction but it's not. I wrote about some of the things that can be done in this blog post: https://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/ -- 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] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)
We can certainly imagine many BIP70 extensions, but for things like auto-filling shipping addresses, is the wallet the best place to do it? My browser already knows how to fill out this data in credit card forms, it would make sense to reuse that for Bitcoin. It sounds like you want a kind of Star-Trek negotiation agent thing, where your computer knows how to seek out the best deal because all the metadata is standardised. Such a thing would be an interesting project, but it's probably not best done in BIP70 given how it's deployed and used today. Rather, I'd suggest looking at the various HTML5 data standards which would allow merchants to advertise things like where they ship to in a machine readable and crawlable form. -- 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] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
BLE meets a different use case than regular Bluetooth. BLE is designed to allow always-on broadcast beacons which are conceptually similar to NFC tags, with very low power requirements. The tradeoff for this ultra-low power consumption and always on nature is the same as with NFC tags: you get very little space for data, and they are essentially one way. That's why a common use case for it is to trigger some other mechanism like a classical Bluetooth socket or HTTPS connection. I think BLE has a role to play in Bitcoin payments, but probably not for actually transferring payment data. Rather, a merchant should be able to drop a BLE beacon in their shop, and then wallet apps can use that to learn where to download a payment request/upload a payment message. But the actual data transfer would still take place over Bluetooth, Wifi or the internet. That leads to the question of what the beacon broadcasts. A bitcoin URI is the obvious answer: the problem is a URI contains an address. No problem for the throw money at a live performer use case but a problem for the cafe use case. If we are willing to mandate BIP70 and remove the static address part from the URI the we get a uri that points to a url which is a bit inefficient but at least lets us distinguish bitcoin beacons from other kinds. That still leaves the fundamental question raised by the Airbitz spec - how does your wallet download the right payment request? Unfortunately that's a tough UI problem. I don't think comparing long hex strings manually is a good way to go. This seems less user friendly than a QR code. Once we solve that problem, how BLE beacons can trigger payments will all fall into place. The tech part isn't the hard part. -- 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
