https://99bitcoins.com/segwit2x-uasf-and-the-upcoming-fork-guidelines-heres-what-you-need-to-know/


This is an English translation of the Israeli Bitcoin Association's guidelines in Hebrew.

If you've been following what's happening it will probably not be much news to you, but you may consider using it as a reference for people who inquire about this.

Note that originally I was told that BitcoinABC is Bitmain's contingency plan for the case that UASF succeeds, and thus irrelevant if NYA succeeds. Since the time I wrote the original post there have been more talk about BitcoinABC, which can happen regardless of NYA, and thus the prospects of a split are more likely.

By the way, our name in Hebrew for UASF is Yossef / Joseph.

A friend has kept a substantial amount of money in a hosted mobile wallet by freewallet.org, and is now unable to access it. He has sent an outgoing transaction which has been deducted from his account but does not appear on the blockchain.

The money has been stuck for a day, and he has tried contacting their support on multiple channels to no avail.

Is Freewallet legit? Is anyone in touch with its owners? Did other people encounter similar problems?

Are they simply experiencing overload as do all Bitcoin services currently? Or have they performed an exit scam?

Update: Interpol was contacted, they managed to track the owner, my friend has received his money back, and I hope other victims will get their money soon too.

[Technical merit]

(Cross-post from my blog)

If you're reading this, you probably know that the Bitcoin community is amidst a civil war.

And you might also know that for almost 2 years, I've been advocating the position that if no agreement or compromise can be reached, the best course of action is to have a clean split of the network into two incompatible, competing currencies.

However, I also said that a compromise is the better outcome if at all possible. And I also said that for a split to work it must be done properly, and my fear that this will not be the case is growing.

Which is why I think we should give diplomacy another shot and pursue a genuine compromise, and why I urge people from both sides of the fence to be more receptive to it. And yes, compromise does mean giving up things that you hold dear.

I will not go into exact detail about what such a compromise could consist in. But overall, two key components will almost certainly have to be activation of Soft-Fork SegWit as soon as possible, together with a hard fork to increase the block size further (perhaps with a built-in growth schedule) without more delay than is necessary.

My own side in the debate is no secret - I believe that the best technical solution is to activate SegWit immediately, and figure out later whether we need a hard fork, and which.

But I support a compromise along the aforementioned general lines, for several reasons which I will explain.

Technical merit

I've said before that I didn't really personally experience the dreaded datageddon that others reported, with slowly confirming transactions and prohibitive fees. Transactions still confirmed quickly and with relatively cheap fees. This made me question the need to rush the scaling solutions.

But time has passed and I'm sad to report this is no longer the case. Bitcoin has experienced another burst of explosive growth, and so did demand for space in the blockchain. I've observed firsthand that getting transactions confirmed within reasonable time requires fees upwards of a dollar. I don't care too much about my own costs, but I'm beginning to feel embarrassed to praise the merits of Bitcoin as I have always done.

This leads to two conclusions: First, we need to resolve the situation, we can't remain in the current situation indefinitely. If a compromise is what it takes to move forward, so be it.

Second, if previously I thought that SFSW is good enough for now - now I think that SFSW is probably sorta kinda good enough for now. If growth continues as it has so far, we'll need a more aggressive blocksize increase sooner rather than later. So despite all the risks and disruptions, an expedited movement towards a hard fork starts to sound like not such a terrible idea.

The other technical issue is that I think we should be more open to the concept of a hard fork. When I got into Bitcoin I didn't sign up to the idea that a hard fork would occur only whenever a mule foals. There are many much-needed upgrades to the protocol which can only be done by way of a hard fork. If we can't even change a well-understood parameter, it doesn't inspire confidence that we'll be able to handle the bigger changes ahead.

Conservativeness in forks is important, but there is such a thing as too much conservatism, and we might be approaching that point. Which is why, again, expediting the hardfork schedule might not be such a bad idea.

For people, by people

More important than the technical reasons why a compromise is palatable, are the social reasons why we need it.

I don't see Bitcoin as a piece of art, an engineering wonder that I can put on display and marvel at its technical correctness. It is a tool created by people with the goal of benefiting people. If it fails at this purpose, it should be fixed.

And right now Bitcoin is stuck, and what's important is to unstick it, not to pat ourselves on the back for how rigorous our technical development methodology is.

Furthermore, Bitcoin is not as robust as some people might think - it is always at the risk of attack by a determined attacker of means. Its security is based on a combination of its own technical defense mechanisms, together with making sure it has as few enemies as possible. Bitcoin has enough enemies from without to worry about. It doesn't need infighting and the threat of some segments of the Bitcoin community attacking others, which may well be the case if we go for the more militant methods of resolving the conflict. Bitcoin is strongest when all its proponents are allied, and this is what a compromise aspires to achieve.

But the issue goes much deeper than that.

The debate, it seems, becomes more and more divisive every passing day. People who express disagreement are labeled as sellouts or traitors to the Bitcoin cause. Demonization, personal attacks and mudslinging are rampant. People have picked sides. Propaganda has succeeded. It's sad and doesn't further a solution.

It is becoming clear that people have firmly tethered their identity to their side on the debate. And this is bad news. As Paul Graham eloquently explains, you can't have a rational, civil debate when people's identities are on the line. People adopt new ideas and resist others not for their underlying merit, but for which side the idea is associated with. This can quickly escalate (and in our case, already has), as people become more and more entrenched in their position, and the more vile a person is perceived just for expressing a dissenting position.

I miss the times when all Bitcoiners were on the same boat. When we could discuss technical topics based on their technical merits. When you could express an opinion without being painted as belonging to one camp or another, or having your opinion ignored just because you are already perceived as belonging to the wrong camp. When ideas were just ideas, not "the ideas of this side" and "the ideas of that side".

But despite our sad state of affairs, I hope that we can reach a compromise. That we will each make sacrifices and rally behind the same banner. If we can do that... Then I hope it will take us back to those better times. That it will diffuse all the tension that has been built up over the years, and take the sting out of the debate. That we will be able to trust each other once more and spend our energies not on quarreling, but on moving forward and furthering solutions.

That, I believe, is a vision worth fighting for.

http://www.bitcoin.org.il/files/IBA_Statement-Hashrate_Attacks.pdf

"
We, the Israeli Bitcoin Association, pursue the goal of maximizing the benefit that Israel’s population obtain from the Bitcoin technology - which strongly depends on Bitcoin’s worldwide success.

We believe that, as a currency, Bitcoin is subject to the network effect, and that it is strongest when its community and industry, brought together by both ideology and practicality, are united in a single network; and that rifts and separation should be avoided if at all possible.

We also believe that Bitcoin is voluntary money; people use it because they choose to, not because they are coerced. As such, people can also choose to fork Bitcoin’s open source code and use an alternative currency with similar underlying principles.

We recognize that there may be different views about what Bitcoin is, and a time may come where those differences cannot be reconciled. It might then be unavoidable to experience a split of the currency into two separate networks, each sharing a blockchain history and - at least temporarily - the Bitcoin brand.

We believe that all these different currencies have a right to coexist peacefully and compete fairly. We oppose any attempt of supporters of one currency to inflict damage on a different currency, in a way which achieves no purpose other than denying others the right to use the currency of their choice.

It saddens us that lately we have heard people planning just such attacks. In particular, in the event of a split of the Bitcoin network to two, both using the same PoW hash function, proponents of the network with majority hashrate might exploit known vulnerabilities of the Bitcoin protocol against the smaller network - such as the well-known >50% attack or a more sophisticated attack commonly known as “selfish mining”. By mining malicious blocks in secret (which double-spend or deny service) and releasing them strategically, they can effectively erase blocks mined by the honest network, and render the currency unusable.

We believe such attacks are in stark opposition to Bitcoin’s spirit and we condemn anyone who supports them. We invite others to publicly condemn and shun these deplorable, hostile plans.

We believe that in so doing, we can help promote a healthier atmosphere, where would-be attackers realize they would only ostracize themselves by carrying out such an attack - thus allowing an open, decentralized ecosystem where people may choose between alternatives and the best currencies may thrive.
"

(Cross-post from my blog)

A year ago, I’ve written How I learned to stop worrying and love the fork, espousing my view that a split of Bitcoin into two networks is possible, and might even be good under the right circumstances and with proper preparations.

Half a year ago, I’ve followed up with I disapprove of Bitcoin splitting, but I’ll defend to the death its right to do it, which elaborated a bit and aimed to refute some misinformation.

I’ve been meaning to write another followup to address some questions that have been raised…

And then Ethereum Classic happened.

For those of you who’ve been living under a rock, a recap: Ethereum is an alternative cryptocurrency featuring Turing-Complete smart contracts. One such contract, theDAO, raised an investment of $150M. Unfortunately, Ethereum makes it easy to write buggy contracts, and theDAO had a serious bug that caused invested funds to be stolen. The Ethereum Foundation decided to roll back the theft, and dissenters who believe in decentralization refused to accept the rollback, leading the Ethereum network to split in two – the version promoted by the Ethereum Foundation, and another version which received the name “Ethereum Classic”.

Ethereum classic has been running for 2 weeks; some alt exchanges have enabled trading in it, and it now goes for a third of the price of the “official” Ethereum. This is well beyond the “momentary split that will immediately coalesce”, and deep into “short-term split” territory.

The story is still unfolding, but there are already multiple lessons to learn from it.

First, if anyone had any doubts that such a thing is possible – it’s possible. It’s happened.

You might be wondering how a split in Ethereum proves anything when the original debate was about Bitcoin. I firmly believe that Bitcoin is not just Bitcoin, and that any cryptocurrency or decentralized technology is within the realm of the general sense of the term “Bitcoin”. And Ethereum, specifically, is similar enough to Bitcoin in the senses that matter so that insights from it are directly applicable. There is, though, one important difference which I will soon address.

Now is as good a time as any to mention that I had predicted in advance that Ethereum would split – or rather, that it could. At a talk I gave at the virtual OnChain Scaling conference on June 27 (Video, Script), back when the rollback was uncertain speculation, I mentioned that if a rollback would indeed take place, it could possibly lead to disagreement and a split of the network, into a part which believes in rollbacks and one which does not. Basically, exactly what’s happening right now.

In that talk I’ve also explicitly defined a classification of splits according to their length, which I will repeat here as it was absent from previous posts:

In a short-term split, one of the networks soon realizes that it has virtually no support at all. Everyone is using the other currency. Due to the network effect, even those who prefer the protocol of Bitcoin A will be unable to use it. After a few days or a few weeks, even the supporters of Bitcoin A will abandon it, and reluctantly start using Bitcoin B. Bitcoin A will die, and Bitcoin B – the network which has an economic majority – will emerge as the one true Bitcoin.

In a medium-term split, both networks have significant support and they coexist for a while. But after several months or years, it becomes apparent that the protocol of Bitcoin A is problematic. It doesn’t function as well as the network of Bitcoin B, and over time, people switch from one to the other. Here, too, Bitcoin B will ultimately emerge as the one true Bitcoin.

In a long-term split, neither of the networks is clearly superior. Each has its own advantages and disadvantages, and each has its supporters and preferred use cases. This will result in two different currencies, that will coexist indefinitely, which were both spawned from the same original coin.

With only two weeks on its belt, I don’t yet consider the Ethereum split a medium-term one. So it has not yet been proven conclusively that medium-term and long-term splits are possible, but it certainly starts to seem more likely.

Moving on, one important aspect of my posts on the matter, which I’ve written before in comments but for emphasis I will write in the post in bold, is that for the most part, my analysis is not descriptive, it is normative. It doesn’t aspire to say what will happen, but what should happen. I am advocating the view that the right to split is bigger than the details of any particular argument we could be splitting over. The right to split is bigger than the question of 1MB vs. 20MB, it’s even bigger than the question of allowing rollbacks vs. not allowing rollbacks. Personally I’m with the “no rollbacks” side (if I wanted rollbacks, I’d stick with the banks), but who cares what I think? As long as there are people who believe in rollbacks and people who do not, they have a sacred right to split off. I bear no ill will (well, not a lot) towards those who choose a different side.

I’ve been criticized with the argument that a split will never happen, because the majority side will >50% attack the minority and kill it. Sure, it could happen, and I can’t give any guarantees that it won’t happen. But why should it happen? Miners on the majority side might think they are morally justified in attacking the minority. I am here to say that, no, the minority has a right to coexist, and you are no more morally justified to attack it than banks are justified in attacking Bitcoin in general. They might also think they are financially incentivized to attack the minority, to keep their own favorite chain stronger. I am here to say that, no, they’d be cutting down the branch on which they’re sitting – by condoning attacks on minority splits, they are promoting a version of Bitcoin (again, “Bitcoin” is not just Bitcoin) were splitting is frowned upon, a version with tyranny of the majority and without the potential to evolve – a version of Bitcoin which is weaker overall.

In other words – I am afraid that split attempts will fail, and that is exactly why I try to convince people that splits are ok and they shouldn’t fight against them – to prevent the splits from failing!

Well, it turns out I was wrong. There’s no need for people like me who tell everyone that splitting is ok. If a split needs to happen, it will just happen. No ado, no fuss, no worries, and not much planning either – people cared deeply enough that they just choose to ignore the reigning authority’s version of the code, and viola, a split is born. (I’m only 40% serious here – despite everything, I still think posts like this are important.)

It’s interesting to note – but not very surprising to me, though – that apparently, there haven’t been attempts to commit a hashrate attack against Ethereum Classic.

Now, mining can be problematic even if the miners are not malicious but mere-profit seekers. If a network like Bitcoin were to split, with the two sides using the same hash function (and hence, the same hardware), then assuming pure profit-seeking miners, the ecosystem would suffer from a severe oscillation problem. What would happen is this – at any point in time, one network will happen to have a higher price/difficulty ratio. All miners will mine on this network, and none on the other network. After a week, the difficulty in the first network will retarget and double, making it less profitable. Then everyone will switch to the other network; after a week, everyone will switch back, and so on. This means that for each network, one week out of two, there will be no blocks at all, making transaction confirmation impossible. The retarget mechanism isn’t effective at balancing this, because difficulty retargeting requires blocks, and there will be no blocks in nobody mines, which is the case if the difficulty is too high and there is an immediate, better alternatives.

In reality not literally everyone will switch so readily, but many will, leading to big fluctuations in hashrate and processing rate for each of the networks. My suggestions for combating this were choosing a different hash function when doing a split, and/or improving Bitcoin’s retarget mechanism.

Ethereum itself already has an (ostensibly) improved retarget mechanism, and as far as I can tell retargets every block. Combined with faster block times, this should create a much more immediate response to hashrate changes, leading to a stable equilibrium rather than wild oscillations. By the way, this also is not a problem in pure PoS chains, which Ethereum plans to become.

This technical detail, in my opinion, is a key part of what makes the Ethereum split viable. In Bitcoin it would have been much more difficult, and without proper preparations could lead to dire consequences.

Speaking of preparations, my earlier posts advocated the position that some must be made for a split to be executed harmlessly, and it doesn’t seem many were made for Ethereum classic. It seems there have been indeed issues of ETC coins being misappropriated by some exchanges, due to either malice or incompetence. But I’ve yet to hear about trouble with locally held coins. So it seems the split is faring well, its relative haste notwithstanding. Perhaps some aspects of Ethereum’s inner workings (of which many are unknown to me), like the retarget method mentioned above, helped facilitate this. And perhaps such a hasty split is perilous after all, and we have simply not yet seen the extent of the troubles it could cause.

The only question that remains is – are splits good? It’s still too early to tell. I believe that given the rift between people upset over losing $150M, and people who actually believe in decentralization, it’s good that the split happened. It’s good that everyone got to pick sides and enjoy the chain he believes in. It’s good that splits have proven to be viable, at least short-term. But again, we do not yet know what kind of ripples will propagate from this fracture, and it could end up being too divisive and harmful.

But even if the split proves detrimental to Ethereum, I still believe the split is good for the cryptocurrency ecosystem in general. There’s so much we can learn from it, and we will thrive on this knowledge.

מסיבה ענקית לכבוד אירוע נדיר הקורה אחת ל-4 שנים! אסור לפספס!
כל הפרטים ב - https://www.facebook.com/events/167233333680024/.

https://bitcoil.co.il/files/BlockParty.pdf

For all of you organizing block parties and wondering about the best ways to estimate the exact time, this paper might help.

[Meni Rosenfeld, Israeli Bitcoin Association]

https://youtu.be/LF23hHqdgGg

This is the video from an event that took place on February 4th 2016. The event's goal was to spread awareness of a variety of issues concerning Bitcoin's scalability and governance, and to come up with new insights for tackling the challenges Bitcoin faces.

The event had 3 main parts:

40 minutes of short lectures
45 minutes of moderated round table discussions with the event's participants
Summary and conclusions of the discussions

The lectures are spoken in Hebrew with English subtitles. The summaries are spoken in English. Glimpses of the round table discussions are also featured in the video.

Lectures were given by:

Meni Rosenfeld, Israeli Bitcoin Association - intro, embracing the possibility of splitting to two currencies
Aviv Zohar, Hebrew University of Jerusalem, Israel - the tradeoff between volume and security
Ron Gross, former Mastercoin executive director - technological progress and democracy
Nadav Ivgi, Bitrated founder - the importance of consensus
Adlai Chandrasekhar - Giving users a choice
Guy Corem, Spondoolies-Tech CEO - how Bitcoin Core can survive a contentious hard fork

Discussion moderators included Ron, Adlai, Guy, Nadav and also:

Ayal Yona Segev, Bitcoin emBassy in Tel Aviv founder
Jonathan Klinger, Advocate

If you'd rather read a written transcript, it's available here. (Does not include English-spoken summaries at the end)

If you found this interesting, you might also be interested in a panel discussion we've had half a year ago: https://www.reddit.com/r/Bitcoin/comments/3su8xj/the_looming_fork_english_subtitles_panel/

(Cross-post from my blog)

In a slideshow published by Brian Armstrong, CEO of Coinbase, he promotes the view that Bitcoin is currently undergoing a winner-takes-all elections, and that variety in Bitcoin protocols is a akin to variety in web browsers.

I find this incorrect, misleading and destructive.

Unlike physical currencies, governed by the laws of nature, and centralized currencies, governed by the whims of their issuers, it’s not at all obvious what ultimately governs a decentralized digital currency such as Bitcoin. There’s the protocol and the code, of course, but those are mutable and thus adhere to a higher authority.

This authority is the agreement between people – as long as users agree to use a currency with a specific protocol, this currency exists and is usable and valuable. If users agree to collectively switch to a different protocol, so be it.

But a core part of Bitcoin’s vision is that users can also agree to disagree. If a group of users wants to use a specific protocol, they have the right to do so, regardless of what anyone else says. Nobody can force a user to adopt a specific protocol. Bitcoin is not, and never has been, a democracy, governed by majority vote. It is something much better, a plurality – the ability of everyone to choose their own path.

Of course, if the advocates of a specific protocol are too few, this will make their currency less usable. So if at all possible, users have an incentive to go with the flow, join the majority and enjoy the network effects. But if it’s not possible – if the disagreement is too severe – they have the sacred, inviolable right to split off; and it is important that everyone remembers they have this right, and not be fooled by anyone who wants them to think they must settle for the view which is dominant at the time.

I used to think this was meant to be only a theoretical possibility, something that exists to keep everyone working together, and protect against rogue developers. But it’s no longer theoretical – I believe we have reached the point of no return, where we have 2 warring camps disagreeing on so many levels that a compromise will not be found. So we should split, let each faction live in peace, and make sure we do it as cleanly as possible. My views on this matter have not changed considerably since I wrote this post to the same effect half a year ago.

So much for the vision. As far as technical details go, there is indeed an instability inherent in having multiple major currencies based on the same PoW hash function. This can be alleviated by one of the sides switching to a different hash function – but in any case, it’s important to first understand the vision, then work out the technical details.

It has been suggested that in past instances of a hard fork, the network quickly collapsed on one of the sides. But this is of course ridiculous. There was never anything in the history of cryptocurrencies that even remotely resembled the situation we have now. There is no past experience to draw from. All we have is the realization that there are powerful forces on all sides of the debate which are *not* going to simply capitulate.

Finally, it’s important not to be confused between variety of protocols, and variety of software implementing a given protocol. I can use Thunderbird to send an email to someone using Outlook. I can browse a web page and see more or less the same thing whether I’m using Firefox, Chrome or IE. Analogously, I can use Bitcoin Core to send bitcoins to someone who uses Electrum – this is because both programs adhere to the same underlying Bitcoin protocol, and are thus compatible and interoperable. But the situation is very different if the sender and receiver obey different protocols – because what I am able to send is different from what the other party is able to receive.

The situation is much worse than with traditional software, because what I’m sending is not just information, but rather tokens of value. So any compatibility layer will be fundamentally financial in nature, not programmatical. Perhaps one day we will have the infrastructure for seamless conversion between different digital currencies. But until then, we should see the multiplicity in protocols for what it is – a hard split into incompatible currencies – and not muddy the discussion with naive, broken analogies to web browsers.

It would make me quite happy if a compromise is found that will allow all current Bitcoin proponents to be part of the same network. But if not, I like having the option to split, and will defend our right to do so. You should too.

[Hebrew]

On November 25, 2015 we will be holding the annual conference of the Israeli Bitcoin Association, covering all aspects of Bitcoin and the Blockchain technology.

The talks will be given in Hebrew and range from economics, law and politics to technology, entrepreneurship and research. The conference will also feature an exhibit hall and plenty of networking opportunity.

Details at http://www.meetup.com/bitcoin-il/events/226535373/ and conference@bitcoin.org.il.

This is more of an FYI - the conference is local and most readers here are not the target audience.

[having two networks coexist side-by-side is a real possibility, that it is not the end of the world, and that we should spend more energy on preparing for this contingency]

(Cross-post from my blog)

It’s hot in Israel in August, but not nearly as hot as the global debate surrounding the release of Bitcoin-XT and the contentious hard fork that would ensue if enough people adopt it. It seems that both proponents and opponents of Bitcoin-XT dread the possibility of the network splitting in two, and focus on making sure everyone switches to their side to prevent this from happening. Contrary to this post’s title, I don’t actually like the prospect of a fork; but I do claim that having two networks coexist side-by-side is a real possibility, that it is not the end of the world, and that we should spend more energy on preparing for this contingency.



It’s possible

Let’s start with the feasibility of this. The ways this could unfold, in decreasing order of my estimate for their likelihood, are:

1. Bitcoin-XT will not reach the threshold required to actually diverge from the current Bitcoin on the blockchain level within a reasonable time, and we will meet again for round two of the debate.
2. Bitcoin-XT will form a separate blockchain and network in or near January 2016.
3. A compromise will be reached which will make Bitcoin-XT obsolete as a separate initiative.
4. Bitcoin users will, virtually unanimously, switch to Bitcoin-XT.

Option #4 was included for completeness, but in my opinion is pretty much impossible. There is too much disagreement about the technical issues, the change in governance, and the bold forking attempt for everyone to just drop everything and tag along. The prospects for compromise (#3) look grim at the moment, the gap in philosophies seems to large to bridge. #1 is highly likely – Bitcoin-XT has support, but I don’t think enough to pass the 75% threshold. But if it does have enough… We find ourselves in scenario #2 – the unprecedented event of a significant cryptocurrency having its network, blockchain and community split in two.

It’s (relatively) safe

Is it bad? Well, yeah. First, Vires in Numeris – Bitcoin is subject to strong network effects, and two networks of roughly half the size are not as strong as one big network. Second, there’s bound to be confusion all around, with two separate currencies each claiming to be the one true Bitcoin. Third, people will think that it is bad (for both real and imagined reasons) and lose faith, stunting Bitcoin’s growth.

How bad? Let’s analyze the short-term effects from the point of view of three types of Bitcoin users:

1. The merchant that accepts Bitcoin payments. He doesn’t have to do anything about this, at all. He teams up with his favorite payment processor, as he did before, and let the processor, and the Bitcoin enthusiast that will pay him, work out the details.
2. The Bitcoin investor. If she bought bitcoins before the fork, she needn’t do anything at all. If she bought 1000 bitcoins, she will now have 1000 coins on the Bitcoin core network and 1000 coins on the Bitcoin-XT network. Whether the currency that will survive is one, the other, or both, her investment is safe.
3. The Bitcoin enthusiast. He will probably have to carry two Bitcoin wallets around (or a special wallet that separately manages funds for both networks), and whenever he wants to pay with Bitcoin, he may have to figure out which version of Bitcoin the recipient expects. That’s extra work and trouble. But it’s okay, he can deal with it. He’s an enthusiast.

I will talk more about longer-term prospects in the section about preparing for the fork. But for now I’d like to say a few more words about confusion. Often I’m frustrated by the obscene amount of misinformation about Bitcoin that is spread around, and then I realize that… That’s not a unique problem for Bitcoin. The world is full of ignorance, misinformation, disinformation, persistent myths, propaganda, misnomers, downright confusion, and simply people who are wrong. Humanity still haven’t figured out an efficient way to organize the world’s knowledge in a way that is accessible and reliable. And yet earth hasn’t exploded yet. We get by. We study the things we truly care about, we understand meaning from context, and we make the most out of the information available to us. So I doubt making the Bitcoin ecosystem a bit more confusing will make it collapse.

This and other concerns will, of course, have a negative impact – but they’re little more than bumps on Bitcoin’s road to success, of which Bitcoin has already had plenty and will have many more.

Furthermore, a fork was in some ways inevitable. Remember that nothing like Bitcoin was ever done before. We had physical currencies, where the rules were determined by physical laws; and we had centralized currencies, where the rules were set by a predetermined, trusted (even if untrustworthy) 3rd party. But a decentralized digital currency? That’s a strange beast, and we all signed up to the notion that what keeps it intact is consensus among people. But it is presumptuous to expect that all of humanity will agree on all the rules all the time. There are differing opinions and philosophies, and when those manifest, camps will part ways. Much like living organisms, cryptocurrencies will replicate. They will compete. They will die. They will survive. They will evolve. And in so doing, they will become stronger.

And I’m not saying, of course, that it’s good that we’re forking right now. We should still try to prevent it if at all possible. But a fork is bound to happen sometime (even if for wholly unrelated reasons), so we may as well gain some experience about the process. We could learn that forks are terrible and we should never let them happen again… Or that forks are great and we should do them all the time… We could learn how to prevent or prepare for future forks, Or we may learn something else entirely. It may be more chaotic than hoping that the mere fear of a fork will keep everyone together, but it’s certainly less rigid and fragile, and more flexible.

We should prepare

So how should the fork unfold? Ideally, the changed version (Bitcoin-XT in this case) will have a different transaction structure for txs that take place after the blockchain split, so that transactions on one network will never be valid on the other, and vice versa. Unfortunately, I have seen no indication that such a thing exists or is planned for Bitcoin-XT (a major red mark for its developers, by the way, assuming there is nothing I missed), so things might get a bit messier. Left to their own devices, transactions might be accepted by one network, the other, or both, and it’s difficult to control which.

A prudent user will consider the currencies as separate, starting from the block where the chain splits. Each will have its own balances, its own exchange rate against other currencies, its own list of places that accept it, etc. But he will need to be careful not to send currency A, and have his transaction accidentally picked up by network B, which will result in him losing his coins B without compensation from the receiver, who never requested coins B.

To do this he will need to decouple his coins into their components. The way to do this is to get some coins generated as coinbase in a post-split block (or coins that can have some trace of those) – those will function as a collapse agent, since they are valid in only one of the networks, say A. Then he will send all his coins – both pre-split UTXOs with his savings, and the post-split collapse agent – to himself. This transaction will only be vaild in network A, so in the receiving address he will have a coin (UTXO) with the total of his balance, that is strictly of currency A. Once this transaction is confirmed, his original UTXO is collapsed into currency B, since in network A they were already spent. Then he can manage his currency with two separate wallets, knowing for certain which currency he sends at any given time.

If he stores coins in a paper wallet, he needn’t worry about it at first. He can extract and decouple the coins at any time. Waiting has the added benefit that one of the networks might die by then, meaning he can claim the coins in the only network that matters without extra effort.

Of course, all of this might be too cumbersome for typical users. Ideally, there will be exchanges and wallet services supporting both currencies which can facilitate the process. Users of these services will have a separate balance for coin A and coin B. The user can simply send coins to his deposit address for the service. The wallet will credit the user’s balance for coin A, B or both depending on which networks acknowledge the transaction. The wallet will then hold superposed coins, and will decouple them as above. When the user wishes to withdraw funds, he will separately withdraw each currency to different wallets, and the service will make to sure to send him only decoupled coins. Then, again, he can know for certain which coins he has in which wallet, and use each to pay when appropriate.

If the user has strong beliefs favoring one currency or another, he can use the exchange to sell just the other currency. He can then even use the funds to buy more of his favorite currency.

The Bitcoin URI for requesting payments should include information about which coin is expected. This will be used by merchants and so on, according to the preference of their payment services provider. The user who wishes to pay can use the information to pay with the correct wallet.

Ideally, smart wallets will be developed which hold both coins A and coins B, and when given a payment request, automatically send the correct type. For example, if we are buying a product worth $280, a bitcoin A is worth $140, and a Bitcoin B is worth $70, the merchant will display either a request for 2 bitcoins A (worth $280) or a request for 4 bitcoins B (worth $280), according to the merchant’s preference. The user will just scan it as normal and have the wallet send it. Users doesn’t really need to worry about it – it suffices to make sure he always carries around both types, assuming he’s expecting to find merchants accepting either type.

Going forward, one of two things can happen:

1. One the currencies will be significantly less popular than the other. It will see less merchants accepting it, its exchange rate will drop, and its technology will develop slowly. Users will be disillusioned by this and migrate to the other currency. Eventually it will for all intents and purposes disappear, and the popular currency will rise as the one true pretender to the Bitcoin throne.
2. Both currencies will enjoy a significant following, forever (or until the heat death of the universe, or whatever). Each will have its own advantages and disadvantages, and people can freely choose between using one, the other, or both. In this case, it is not sufficient to have software and services to handle the plurality seamlessly – the name ambiguity should be resolved, and it will be prudent for the less popular currency (measured by market cap if no better metric is found) to give way, change its name, and finish its cycle of separating from the other currency.

It will be a bit messy, but we can handle it. A fork in the road is not the end of the world.

[tl; dr: I propose replacing the hard cap on the data size of a block (1MB, 20MB, or whatever it is) with an elastic one, where resistance to larger blocks accumulates progressively. Miners will be required to pay a superlinear penalty for large blocks, to be paid into a rollover fee pool. This will greatly increase Bitcoin's robustness to a situation where the block cap is approached, and allow a healthy fee market.]

tl; dr: I propose replacing the hard cap on the data size of a block (1MB, 20MB, or whatever it is) with an elastic one, where resistance to larger blocks accumulates progressively. Miners will be required to pay a superlinear penalty for large blocks, to be paid into a rollover fee pool. This will greatly increase Bitcoin's robustness to a situation where the block cap is approached, and allow a healthy fee market.

Background
In these days there is heated debate about whether the block size limit of 1 MB should be relaxed. Many arguments are being discussed, but the most common one is the classic tradeoff:

Bigger blocks -> Harder to run a node -> Less nodes -> More centralization
Smaller blocks -> Less payments can be done directly as transactions on the blockchain -> More reliance on payment processing solutions involving 3rd parties -> More centralization

Most agree that there is some optimal value for this tradeoff, and the debate is about what it is, how to determine it, how to make decisions revolving it, etc. And most assume that if the blocks are too small, we'll get a "heads up" in the form of increasing tx fees.

However, Mike argues, and I tend to agree, that this is not how it will work. Rather, if the block limit is too small for the transaction demand, the Bitcoin network will crash. The gist of his argument, as I see it, is - market forces should find a fee equilibrium where transaction supply matches demand, whatever they are. However, market forces don't react fast enough to fluctuations, creating buildups that technically can't be handled by the software.

Mike argues also that since we don't know when we'll reach the limit - and once we do, we will have catastrophic failure without warning - we must hurry to raise the limit to remain safe. That part I have an issue with - if Bitcoin can't gracefully degrade in the face of rising transaction volume, we will have problems no matter what the current block size limit is. We should instead focus on fixing that problem.

In this post I will introduce a protocol modification that might eliminate this problem. I will describe the suggestion and analyze how it can help. With it in place, we no longer run the risk of a crash landing, only rising fees - giving us an indication that something should be changed.

And then, we can go back to arguing what the block size should be, given the tradeoff above.

Rollover fee pool
This suggestion requires, as a prerequisite, the use of a rollover fee pool. I first introduced the concept here - this post is worth a read, but it used the concept for a different purpose than we have here.

The original idea was that fees for a transaction will not be paid to the one miner of the block which includes it - rather, fees would be paid into a pool, from which the funds will gradually be paid to future miners. You could have, for example, that in each block, the miner is entitled to 1% of the current funds in the pool (in addition to any other block rewards).

In the current suggestion, we will use such a pool that is paid out over time - but it will not be the users who put money into the pool. Transaction fees will be paid to the miner who found the block as normal.

Edit: Saying again for clarity - In the current proposal, fees from transactions will be paid to the miner of the current block instantly and in full. The miners can't gain anything by accepting tx fees out of band. The one paying into the rollover pool is the miner himself, as explained below.

Elastic block cap
The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.

This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). (graph)

This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.

Analysis
I assume we do want scarcity in the blockchain - this prevents useless transactions that bloat the blockchain and make it harder to run nodes, and incentivizes users to fund the Bitcoin infrastructure. A block size limit creates scarcity - but only if there ever really are situations where we reach the limit. But as things stand, reaching the limit creates technical malfunctions.

Mike calls the problem "crash landing", but to me it's more like hitting a brick wall. Transaction demand runs towards the limit with nothing slowing it down, until it painfully slams into it. One minute there is spare room in the blocks, and no reason to charge tx fees - and the next, there's no room, and we run into problems.

If more transactions enter the network than can be put in blocks, the queue will grow ever larger and can take hours to clear, meaning that transactions will take hours to confirm. Miners can use fees to signal to the market to ease up on new transactions, but the market will be too slow to react. First, because the software isn't optimized to receive this signal; and second, because transaction demand is inelastic in short time scales. If, over sustained periods of time, transaction fees are high, I will stop looking for places to pay with Bitcoin, I will sign up to a payment facilitation service, etc. But short-term, if I have a transaction I'm set on sending right now (e.g. a restaurant tab), I'll be willing to pay very high fees for it if I must. So fees are not effective in controlling the deluge of transactions.

Enter an elastic cap. When tx demand exceeds the target block value, a backlog doesn't accumulate - miners simply include the extra in the block. They will start to require a bit of extra fees to compensate for the penalty, but can still clear the queue at the rate it is filling. If the incoming tx rate continues to increase, the marginal penalty miners have to pay per tx will increase, so fees will become higher - but since the process is more gradual, clients will be in a better position to understand what fee they need to pay for quick confirmation. The process will resemble climbing a hill rather than running into a brick wall. As we push the limits, the restoring force will grow stronger until we reach an equilibrium.

On longer time scales, the market will have an understanding of the typical fees, and make decisions accordingly. It can also analyze times of the day/week when fees are lower, and use those for any non-time-sensitive transactions.

With a hard cap, the queue of transactions can only clear at a specific rate. Below this rate there is no fee tension, and above it there is instability. With an elastic cap, a longer queue cause transaction fees to be higher, encouraging miners to include more in a block, increasing the speed at which the queue clears. This is a stable equilibrium that prevents the queue from growing unboundedly, while always maintaining some fee tension.

Incidentally, the current system is a special case of this suggestion, with f(x) = If (x<T, 0, Infinity). We assume that an invalid block is equivalent to an infinite penalty.

The way forward
I believe there is very little downside, if any, to implementing this method. It can prove useful even if the crash landing scenario isn't as grave as Mike suggests. And the primitives will be handy for other possible protocol improvements. I believe it is an essentially simple and fully fleshed-out idea. As such, I hope it can be accepted without much controversy.

It is however a major change which may require some significant coding. When discussing this idea with Gavin, he explained he'd be in a better position to evaluate it if given working, testable code. Writing code isn't my thing, though. If anyone is interested in implementing this, I'll be happy to provide support.

Related work
A similar system exists in CryptoNote, see e.g. section 6.2.3 of https://cryptonote.org/whitepaper.pdf.

Greg Maxwell proposed a similar system with variable mining effort instead of reward penalty - see e.g. http://sourceforge.net/p/bitcoin/mailman/message/34100485/ for discussion.

This proposal is not directly related to floating block limit methods, where the limit parameters are determined automatically based on recent history of transaction demand.

פורסמו תוצאות הבחירות לאיגוד הביטקוין הישראלי.

הצביעו 113 חברי איגוד המהווים 78% מתוך סה"כ 145 חברים בעלי זכות הצבעה. מספר הקולות שקיבל כל מועמד הוא:

לועד המנהל:
94 מני רוזנפלד**
74 אדן שוחט**
71 רון גרוס**
63 גיתי זך**
52 אלי בז'רנו*
31 נימרוד להבי*
26 נמרוד גרובר*
26 ליבי קורן
21 יקיר רטנר
17 שלום כהן
15 אלכס כהן
15 עמוס מאירי
2 רועי גורודיש

לועדת הביקורת:
81 יונתן רואש**
75 עופר רותם**
53 עמיחי פרץ קלופשטוק*
31 ליאור טסמן*

מועמדים המסומנים ב-** נכנסים לתפקיד לתקופת כהונה של שנתיים. מועמדים המסומנים ב-* נכנסים לתקופת כהונה של שנה. מקרי שוויון הוכרעו ע"י הגרלה המוסכמת על הצדדים המעורבים.

ברכות לזוכים!

The Israeli Bitcoin Association is a nonprofit organization, founded in July 2013 and legally registered in March 2014. Its goal is to maximize the benefit that Israel's population gains from the Bitcoin technology.

Its homepage (in Hebrew) is at http://iba.bitcoin.org.il/.

[היום]

מחר תתחלנה הבחירות לועד המנהל וועדת הביקורת של איגוד הביטקוין הישראלי. פרטים נוספים נמצאים ב -http://iba.bitcoin.org.il/?p=162.

התאריך האחרון להגשת מועמדות הוא היום (יום שלישי 23.12.2014). ההגשה מתבצעת בטופס goo.gl/forms/R1HfbHo3rb.

מחר (יום רביעי 24.12) תתקיים אסיפה כללית של חברי האיגוד - http://www.meetup.com/bitcoin-il/events/219228842/.

• רשימת חלפני ביטקוין בארץ
• רשימת עסקים המקבלים ביטקוין בארץ
• איגוד הביטקוין הישראלי
• אתר תוכן
• קבוצת פייסבוק
• קבוצת מפגשים
• ערוץ יוטיוב
• שגרירות הביטקוין
• קבוצת גוגל
• ערוץ IRC

We are in the midst of the Inside Bitcoins Tel Aviv 2014 conference, and one interesting thing to report is that a Bitcoin-themed painting made by a local artist, which was placed on display in the conference, has been sold for 35 BTC (about 10,000 EUR) to Yoshi Goto from Bitmain. This is possibly the largest purchase of merchandise for Bitcoin in Israel so far.

The following issue is very general, but to spare you the abstractions I will describe it by way of presenting the situation I have at hand.

We at the Israeli Bitcoin Association will soon have our first elections to our board of directors. Many details are TBD but basically, members get to vote and the directors who received the most votes are chosen.

A problem exists if there are ties. Let's say there are 7 members, and the vote counts from high to low are 66, 55, 45, 36, 28, 15, 15, 15, 10, ... . Then places 6-8 are shared by people who got 15 votes, and the method doesn't determine which 2 of them to admit.

Some voting systems resolve this with an additional tiebreaking voting round, but this creates a lot of overhead and is not mathematically elegant. Game-theoretically, a better way is to randomly choose the winners; but then we have a problem of ensuring the random choice was done fairly.

A natural way to resolve this would be to use the blockchain. Hashes of future blocks are more or less random and not easy to manipulate. So we can announce in advance that ties will be broken based on the hash of the first block with a timestamp of at least Nov 30 2014 00:00:00. However, I don't want to reinvent the specific way to use the hash to make the selection.

So my question is - is there some standard, deterministic way to use the blockchain to resolve ties? Is there some website which gives results based on this standard? If not, how do we go about creating such a standard?

Note that to address the general problem, the method needs to return a permutation - since we have a number of results which a priori are all equivalent, and we would like to order them somehow. So basically, the method will accept a date (or block height) designation, and a list of text items, and return a randomly permuted list of the items. Some ideas I had is to take the block hash modulo n! and choose a result from the n! permutations, ordered lexicographically, based on the result. Or to use the hash as a random seed which is input to a simple permutation-finding program.

Optionally, the standard would allow using the hashes of multiple blocks, to make it harder to mine blocks specifically to manipulate the system.

[Special guest lectures:]

As you may know, Israel has a very active Bitcoin community. One of its biggest hubs is the Meetup group, holding various events including monthly lectures. Most of the content is in Hebrew, however occasionally we host a lecture in English. This thread will share videos of these lectures.

Special guest lectures:
Quantum Computing and Bitcoin (Vitalik Buterin, November 2013)
Fungibility, Privacy & Identity (Adam Back, February 2014)
Politics and the Bitcoin Protocol (Peter Todd, May 2014)
Tel Aviv Special Bitcoin Meetup July 2014 (lectures by Jack Liao and Marco Krohn)
What Bitcoin Private Keys say to Each Other (Nicolas T. Courtois, October 2015)
Bitsquare: The decentralized bitcoin exchange (Manfred Karrer, May 2016)

English lectures by Israelis:
TechAviv Founders Club Dec 2013: The Bitcoin Revolution
Zerocash (Eli Ben-Sasson, April 2014)
Bitcoin vs. Quantum Money (Or Sattath, August 2014)
IOTAFEST Day 2 - Bitcoin track (May 2015) - 4 sessions. One of them in Hebrew, you can skip with the time markers.
Advanced Concepts in Blockchain Design (Lior Yaffe, July 2016)

Israel Bitcoin Think Tank:
Bitcoin Israel Think Tank - Episode 1 (Meni Rosenfeld, Vitalik Buterin, Ron Gross, Dominik Weil and Eli Sklar)

[O Bitcoinisvelut solisstatu variabilis,semper ortusaut occasus;mercatus odiosus,nunc bovariuset tunc ursus,numquam inconcussus;egestatem,potestatemdissolvit ut glaciem.]

O Bitcoinis
velut solis
statu variabilis,
semper ortus
aut occasus;
mercatus odiosus,
nunc bovarius
et tunc ursus,
numquam inconcussus;
egestatem,
potestatem
dissolvit ut glaciem.

The song "O Fortuna" appeared in "Carmina Burana", a 13th century colletcion of about 250 songs, many of which are a satire of the Catholic Church. The song would have probably remained obscure, it it wasn't for the dramatic composition created for it (and several other songs from the collection) the German composer Carl Orff in 1936 - which made it "mandatory" in every Television work requiring a cataclysmic background music.

The song laments on the turbulence of fate, the good fortune that comes and goes, the ease at which a man can fall down from the top of the world to a deep hole - and vice versa. On the face of it, The song merely regrets this sad state of affairs, but I believe it carries with it a message - that we should realize this is our reality, and accordingly show a certain degree of indifference. Since both the good and the bad are destined to quickly pass, we should not be sorry for our misfortune, but also not to be excessively joyous if fortune has smiled upon us.

Many parameters measure the success of Bitcoin, but the most salient and most talked about is of course the exchange rate. When the rate goes up the press covers the topic enthusiastically and the community is filled with excitement, and when the rate goes down we see worry and despair. But it is the nature of the rate to always go up and down, and thus we should not take to heart every fluctuation in the rate.

This is the message I tried to carry across with this song, which is a paraphrase of the first verse of "O Fortuna". I've tried to remain true to the original, but I have placed several significant changes. I do not speak Latin; I've done a bit of research and exercised judgement, but my main source is Google Translate so there are no guarantees. Casually translated to English, the song's words are:

O Bitcoin
like the sun
you are changing,
always rising
or setting;
hateful market,
now bullish
and then bearish,
never stable;
poverty,
power,
melt like ice.