MIT's Bitcoin-Inspired 'Enigma' Lets Computers Mine

CMV: the current hype about blockchain exists only because of the speculative cryptocurrency bubble

This is not against the blockchain technology, which I think is interesting and for sure useful for certain applications. It's just against the exaggerated hype about it, labelling it as a technology that will change the world, or trigger a ground-breaking revolution.
Let's be honest: if there wasn't this bitcoin bubble, nobody would know about blockchain, and the topic would be completely boring to 95% of people. It's cryptography, and it allows to do something that's already done today in a cryptographically secured way. That's interesting for cryptography researchers, but for normal people, who tend to abstract away from such highly technical aspects like cryptography, and just care about what they can do with technology (e.g. transfer money, paying a bill), this is quite irrelevant.
Let's take for example homomorphic encryption. This is an equally amazing technology, which allows to perform arithmetic operations on ciphertexts without decrypting them first. But nobody else than cryptographers know about it. Why? Because it's not associated to anything with headline potential (like a speculation bubble where you can make a lot of money). It's just some boring complicated mathematics. So it never featured in newspaper and HackerNoon articles, and never came to the ears of the average Joe and average nerd.
Therefore: the current hype about blockchain is caused mainly by a speculation bubble, and not by the actual potential of the technology itself.
A note about the views that the real value of blockchain is that it allows to get rid of the dependency on "evil" centralized institutions like banks and governments ("them") for managing transactions and money, by allowing the common people ("we") to do it ourselves: bitcoin is already extremely centralized today. A small group of individuals and mining companies hold most of the assets and run the needed computational infrastructure. Is this really the antithesis of today's system, or is it not already developing to exactly the same with another technology? A bunch of the original "crypto-liberators" (part of "us") becoming the new centralized power ("them") that must be fought back? At least, it's a known pattern from history that after nearly every revolution, instead of utopia arriving, a bunch of the old liberators become the new tyrants, and the story repeats.
This is a footnote from the CMV moderators. We'd like to remind you of a couple of things. Firstly, please read through our rules. If you see a comment that has broken one, it is more effective to report it than downvote it. Speaking of which, downvotes don't change views! Any questions or concerns? Feel free to message us. Happy CMVing!
submitted by damp-ocean to changemyview [link] [comments]

Greg Maxwell /u/nullc (CTO of Blockstream) has sent me two private messages in response to my other post today (where I said "Chinese miners can only win big by following the market - not by following Core/Blockstream."). In response to his private messages, I am publicly posting my reply, here:

Note:
Greg Maxell nullc sent me 2 short private messages criticizing me today. For whatever reason, he seems to prefer messaging me privately these days, rather than responding publicly on these forums.
Without asking him for permission to publish his private messages, I do think it should be fine for me to respond to them publicly here - only quoting 3 phrases from them, namely: "340GB", "paid off", and "integrity" LOL.
There was nothing particularly new or revealing in his messages - just more of the same stuff we've all heard before. I have no idea why he prefers responding to me privately these days.
Everything below is written by me - I haven't tried to upload his 2 PMs to me, since he didn't give permission (and I didn't ask). The only stuff below from his 2 PMs is the 3 phrases already mentioned: "340GB", "paid off", and "integrity". The rest of this long wall of text is just my "open letter to Greg."
TL;DR: The code that maximally uses the available hardware and infrastructure will win - and there is nothing Core/Blockstream can do to stop that. Also, things like the Berlin Wall or the Soviet Union lasted for a lot longer than people expected - but, conversely, the also got swept away a lot faster than anyone expected. The "vote" for bigger blocks is an ongoing referendum - and Classic is running on 20-25% of the network (and can and will jump up to the needed 75% very fast, when investors demand it due to the inevitable "congestion crisis") - which must be a massive worry for Greg/Adam/Austin and their backers from the Bilderberg Group. The debate will inevitably be decided in favor of bigger blocks - simply because the market demands it, and the hardware / infrastructure supports it.
Hello Greg Maxwell nullc (CTO of Blockstream) -
Thank you for your private messages in response to my post.
I respect (most of) your work on Bitcoin, but I think you were wrong on several major points in your messages, and in your overall economic approach to Bitcoin - as I explain in greater detail below:
Correcting some inappropriate terminology you used
As everybody knows, Classic or Unlimited or Adaptive (all of which I did mention specifically in my post) do not support "340GB" blocks (which I did not mention in my post).
It is therefore a straw-man for you to claim that big-block supporters want "340GB" blocks. Craig Wright may want that - but nobody else supports his crazy posturing and ridiculous ideas.
You should know that what actual users / investors (and Satoshi) actually do want, is to let the market and the infrastructure decide on the size of actual blocks - which could be around 2 MB, or 4 MB, etc. - gradually growing in accordance with market needs and infrastructure capabilities (free from any arbitrary, artificial central planning and obstructionism on the part of Core/Blockstream, and its investors - many of whom have a vested interest in maintaining the current debt-backed fiat system).
You yourself (nullc) once said somewhere that bigger blocks would probably be fine - ie, they would not pose a decentralization risk. (I can't find the link now - maybe I'll have time to look for it later.) I found the link:
https://np.reddit.com/btc/comments/43mond/even_a_year_ago_i_said_i_though_we_could_probably/
I am also surprised that you now seem to be among those making unfounded insinuations that posters such as myself must somehow be "paid off" - as if intelligent observers and participants could not decide on their own, based on the empirical evidence, that bigger blocks are needed, when the network is obviously becoming congested and additional infrastructure is obviously available.
Random posters on Reddit might say and believe such conspiratorial nonsense - but I had always thought that you, given your intellectual abilities, would have been able to determine that people like me are able to arrive at supporting bigger blocks quite entirely on our own, based on two simple empirical facts, ie:
  • the infrastructure supports bigger blocks now;
  • the market needs bigger blocks now.
In the present case, I will simply assume that you might be having a bad day, for you to erroneously and groundlessly insinuate that I must be "paid off" in order to support bigger blocks.
Using Occam's Razor
The much simpler explanation is that bigger-block supporters believe will get "paid off" from bigger gains for their investment in Bitcoin.
Rational investors and users understand that bigger blocks are necessary, based on the apparent correlation (not necessarily causation!) between volume and price (as mentioned in my other post, and backed up with graphs).
And rational network capacity planners (a group which you should be in - but for some mysterious reason, you're not) also understand that bigger blocks are necessary, and quite feasible (and do not pose any undue "centralization risk".)
As I have been on the record for months publicly stating, I understand that bigger blocks are necessary based on the following two objective, rational reasons:
  • because I've seen the graphs; and
  • because I've seen the empirical research in the field (from guys like Gavin and Toomim) showing that the network infrastructure (primarily bandwidth and latency - but also RAM and CPU) would also support bigger blocks now (I believe they showed that 3-4MB blocks would definitely work fine on the network now - possibly even 8 MB - without causing undue centralization).
Bigger-block supporters are being objective; smaller-block supporters are not
I am surprised that you no longer talk about this debate in those kind of objective terms:
  • bandwidth, latency (including Great Firewall of China), RAM, CPU;
  • centralization risk
Those are really the only considerations which we should be discussing in this debate - because those are the only rational considerations which might justify the argument for keeping 1 MB.
And yet you, and Adam Back adam3us, and your company Blockstream (financed by the Bilderberg Group, which has significant overlap with central banks and the legacy, debt-based, violence-backed fiat money system that has been running and slowing destroying our world) never make such objective, technical arguments anymore.
And when you make unfounded conspiratorial, insulting insinuations saying people who disagree with you on the facts must somehow be "paid off", then you are now talking like some "nobody" on Reddit - making wild baseless accusations that people must be "paid off" to support bigger blocks, something I had always thought was "beneath" you.
Instead, Occams's Razor suggests that people who support bigger blocks are merely doing so out of:
  • simple, rational investment policy; and
  • simple, rational capacity planning.
At this point, the burden is on guys like you (nullc) to explain why you support a so-called scaling "roadmap" which is not aligned with:
  • simple, rational investment policy; and
  • simple, rational capacity planning
The burden is also on guys like you to show that you do not have a conflict of interest, due to Blockstream's highly-publicized connections (via insurance giant AXA - whose CED is also the Chairman of the Bilderberg Group; and companies such as the "Big 4" accounting firm PwC) to the global cartel of debt-based central banks with their infinite money-printing.
In a nutshell, the argument of big-block supporters is simple:
If the hardware / network infrastructure supports bigger blocks (and it does), and if the market demands it (and it does), then we certainly should use bigger blocks - now.
You have never provided a counter-argument to this simple, rational proposition - for the past few years.
If you have actual numbers or evidence or facts or even legitimate concerns (regarding "centralization risk" - presumably your only argument) then you should show such evidence.
But you never have. So we can only assume either incompetence or malfeasance on your part.
As I have also publicly and privately stated to you many times, with the utmost of sincerity: We do of course appreciate the wealth of stellar coding skills which you bring to Bitcoin's cryptographic and networking aspects.
But we do not appreciate the obstructionism and centralization which you also bring to Bitcoin's economic and scaling aspects.
Bitcoin is bigger than you.
The simple reality is this: If you can't / won't let Bitcoin grow naturally, then the market is going to eventually route around you, and billions (eventually trillions) of investor capital and user payments will naturally flow elsewhere.
So: You can either be the guy who wrote the software to provide simple and safe Bitcoin scaling (while maintaining "reasonable" decentralization) - or the guy who didn't.
The choice is yours.
The market, and history, don't really care about:
  • which "side" you (nullc) might be on, or
  • whether you yourself might have been "paid off" (or under a non-disclosure agreement written perhaps by some investors associated the Bilderberg Group and the legacy debt-based fiat money system which they support), or
  • whether or not you might be clueless about economics.
Crypto and/or Bitcoin will move on - with or without you and your obstructionism.
Bigger-block supporters, including myself, are impartial
By the way, my two recent posts this past week on the Craig Wright extravaganza...
...should have given you some indication that I am being impartial and objective, and I do have "integrity" (and I am not "paid off" by anybody, as you so insultingly insinuated).
In other words, much like the market and investors, I don't care who provides bigger blocks - whether it would be Core/Blockstream, or Bitcoin Classic, or (the perhaps confusingly-named) "Bitcoin Unlimited" (which isn't necessarily about some kind of "unlimited" blocksize, but rather simply about liberating users and miners from being "limited" by controls imposed by any centralized group of developers, such as Core/Blockstream and the Bilderbergers who fund you).
So, it should be clear by now I don't care one way or the other about Gavin personally - or about you, or about any other coders.
I care about code, and arguments - regardless of who is providing such things - eg:
  • When Gavin didn't demand crypto proof from Craig, and you said you would have: I publicly criticized Gavin - and I supported you.
  • When you continue to impose needless obstactles to bigger blocks, then I continue to criticize you.
In other words, as we all know, it's not about the people.
It's about the code - and what the market wants, and what the infrastructure will bear.
You of all people should know that that's how these things should be decided.
Fortunately, we can take what we need, and throw away the rest.
Your crypto/networking expertise is appreciated; your dictating of economic parameters is not.
As I have also repeatedly stated in the past, I pretty much support everything coming from you, nullc:
  • your crypto and networking and game-theoretical expertise,
  • your extremely important work on Confidential Transactions / homomorphic encryption.
  • your desire to keep Bitcoin decentralized.
And I (and the network, and the market/investors) will always thank you profusely and quite sincerely for these massive contributions which you make.
But open-source code is (fortunately) à la carte. It's mix-and-match. We can use your crypto and networking code (which is great) - and we can reject your cripple-code (artificially small 1 MB blocks), throwing it where it belongs: in the garbage heap of history.
So I hope you see that I am being rational and objective about what I support (the code) - and that I am also always neutral and impartial regarding who may (or may not) provide it.
And by the way: Bitcoin is actually not as complicated as certain people make it out to be.
This is another point which might be lost on certain people, including:
And that point is this:
The crypto code behind Bitcoin actually is very simple.
And the networking code behind Bitcoin is actually also fairly simple as well.
Right now you may be feeling rather important and special, because you're part of the first wave of development of cryptocurrencies.
But if the cryptocurrency which you're coding (Core/Blockstream's version of Bitcoin, as funded by the Bilderberg Group) fails to deliver what investors want, then investors will dump you so fast your head will spin.
Investors care about money, not code.
So bigger blocks will eventually, inevitably come - simply because the market demand is there, and the infrastructure capacity is there.
It might be nice if bigger blocks would come from Core/Blockstream.
But who knows - it might actually be nicer (in terms of anti-fragility and decentralization of development) if bigger blocks were to come from someone other than Core/Blockstream.
So I'm really not begging you - I'm warning you, for your own benefit (your reputation and place in history), that:
Either way, we are going to get bigger blocks.
Simply because the market wants them, and the hardware / infrastructre can provide them.
And there is nothing you can do to stop us.
So the market will inevitably adopt bigger blocks either with or without you guys - given that the crypto and networking tech behind Bitcoin is not all that complex, and it's open-source, and there is massive pent-up investor demand for cryptocurrency - to the tune of multiple billions (or eventually trillions) of dollars.
It ain't over till the fat lady sings.
Regarding the "success" which certain small-block supports are (prematurely) gloating about, during this time when a hard-fork has not happened yet: they should bear in mind that the market has only begun to speak.
And the first thing it did when it spoke was to dump about 20-25% of Core/Blockstream nodes in a matter of weeks. (And the next thing it did was Gemini added Ethereum trading.)
So a sizable percentage of nodes are already using Classic. Despite desperate, irrelevant attempts of certain posters on these forums to "spin" the current situation as a "win" for Core - it is actually a major "fail" for Core.
Because if Core/Blocksteam were not "blocking" Bitcoin's natural, organic growth with that crappy little line of temporary anti-spam kludge-code which you and your minions have refused to delete despite Satoshi explicitly telling you to back in 2010 ("MAX_BLOCKSIZE = 1000000"), then there would be something close to 0% nodes running Classic - not 25% (and many more addable at the drop of a hat).
This vote is ongoing.
This "voting" is not like a normal vote in a national election, which is over in one day.
Unfortunately for Core/Blockstream, the "voting" for Classic and against Core is actually two-year-long referendum.
It is still ongoing, and it can rapidly swing in favor of Classic at any time between now and Classic's install-by date (around January 1, 2018 I believe) - at any point when the market decides that it needs and wants bigger blocks (ie, due to a congestion crisis).
You know this, Adam Back knows this, Austin Hill knows this, and some of your brainwashed supporters on censored forums probably know this too.
This is probably the main reason why you're all so freaked out and feel the need to even respond to us unwashed bigger-block supporters, instead of simply ignoring us.
This is probably the main reason why Adam Back feels the need to keep flying around the world, holding meetings with miners, making PowerPoint presentations in English and Chinese, and possibly also making secret deals behind the scenes.
This is also why Theymos feels the need to censor.
And this is perhaps also why your brainwashed supporters from censored forums feel the need to constantly make their juvenile, content-free, drive-by comments (and perhaps also why you evidently feel the need to privately message me your own comments now).
Because, once again, for the umpteenth time in years, you've seen that we are not going away.
Every day you get another worrisome, painful reminder from us that Classic is still running on 25% of "your" network.
And everyday get another worrisome, painful reminder that Classic could easily jump to 75% in a matter of days - as soon as investors see their $7 billion wealth starting to evaporate when the network goes into a congestion crisis due to your obstructionism and insistence on artificially small 1 MB blocks.
If your code were good enough to stand on its own, then all of Core's globetrotting and campaigning and censorship would be necessary.
But you know, and everyone else knows, that your cripple-code does not include simple and safe scaling - and the competing code (Classic, Unlimited) does.
So your code cannot stand on its own - and that's why you and your supporters feel that it's necessary to keep up the censorship and and the lies and the snark. It's shameful that a smart coder like you would be involved with such tactics.
Oppressive regimes always last longer than everyone expects - but they also also collapse faster than anyone expects.
We already have interesting historical precedents showing how grassroots resistance to centralized oppression and obstructionism tends to work out in the end. The phenomenon is two-fold:
  • The oppression usually drags on much longer than anyone expects; and
  • The liberation usually happens quite abruptly - much faster than anyone expects.
The Berlin Wall stayed up much longer than everyone expected - but it also came tumbling down much faster than everyone expected.
Examples of opporessive regimes that held on surprisingly long, and collapsed surpisingly fast, are rather common - eg, the collapse of the Berlin Wall, or the collapse of the Soviet Union.
(Both examples are actually quite germane to the case of Blockstream/Core/Theymos - as those despotic regimes were also held together by the fragile chewing gum and paper clips of denialism and censorship, and the brainwashed but ultimately complacent and fragile yes-men that inevitably arise in such an environment.)
The Berlin Wall did indeed seem like it would never come down. But the grassroots resistance against it was always there, in the wings, chipping away at the oppression, trying to break free.
And then when it did come down, it happened in a matter of days - much faster than anyone had expected.
That's generally how these things tend to go:
  • oppression and obstructionism drag on forever, and the people oppressing freedom and progress erroneously believe that Core/Blockstream is "winning" (in this case: Blockstream/Core and you and Adam and Austin - and the clueless yes-men on censored forums like r\bitcoin who mindlessly support you, and the obedient Chinese miners who, thus far, have apparently been to polite to oppose you) ;
  • then one fine day, the market (or society) mysteriously and abruptly decides one day that "enough is enough" - and the tsunami comes in and washes the oppressors away in the blink of an eye.
So all these non-entities with their drive-by comments on these threads and their premature gloating and triumphalism are irrelevant in the long term.
The only thing that really matters is investors and users - who are continually applying grassroots pressure on the network, demanding increased capacity to keep the transactions flowing (and the price rising).
And then one day: the Berlin Wall comes tumbling down - or in the case of Bitcoin: a bunch of mining pools have to switch to Classic, and they will do switch so fast it will make your head spin.
Because there will be an emergency congestion crisis where the network is causing the price to crash and threatening to destroy $7 billion in investor wealth.
So it is understandable that your supports might sometimes prematurely gloat, or you might feel the need to try to comment publicly or privately, or Adam might feel the need to jet around the world.
Because a large chunk of people have rejected your code.
And because many more can and will - and they'll do in the blink of an eye.
Classic is still out there, "waiting in the wings", ready to be installed, whenever the investors tell the miners that it is needed.
Fortunately for big-block supporters, in this "election", the polls don't stay open for just one day, like in national elections.
The voting for Classic is on-going - it runs for two years. It is happening now, and it will continue to happen until around January 1, 2018 (which is when Classic-as-an-option has been set to officially "expire").
To make a weird comparison with American presidential politics: It's kinda like if either Hillary or Trump were already in office - but meanwhile there was also an ongoing election (where people could change their votes as often as they want), and the day when people got fed up with the incompetent incumbent, they can throw them out (and install someone like Bernie instead) in the blink of an eye.
So while the inertia does favor the incumbent (because people are lazy: it takes them a while to become informed, or fed up, or panicked), this kind of long-running, basically never-ending election favors the insurgent (because once the incumbent visibly screws up, the insurgent gets adopted - permanently).
Everyone knows that Satoshi explicitly defined Bitcoin to be a voting system, in and of itself. Not only does the network vote on which valid block to append next to the chain - the network also votes on the very definition of what a "valid block" is.
Go ahead and re-read the anonymous PDF that was recently posted on the subject of how you are dangerously centralizing Bitcoin by trying to prevent any votes from taking place:
https://np.reddit.com/btc/comments/4hxlquhoh_a_warning_regarding_the_onset_of_centralised/
The insurgent (Classic, Unlimited) is right (they maximally use available bandwidth) - while the incumbent (Core) is wrong (it needlessly throws bandwidth out the window, choking the network, suppressing volume, and hurting the price).
And you, and Adam, and Austin Hill - and your funders from the Bilderberg Group - must be freaking out that there is no way you can get rid of Classic (due to the open-source nature of cryptocurrency and Bitcoin).
Cripple-code will always be rejected by the network.
Classic is already running on about 20%-25% of nodes, and there is nothing you can do to stop it - except commenting on these threads, or having guys like Adam flying around the world doing PowerPoints, etc.
Everything you do is irrelevant when compared against billions of dollars in current wealth (and possibly trillions more down the road) which needs and wants and will get bigger blocks.
You guys no longer even make technical arguments against bigger blocks - because there are none: Classic's codebase is 99% the same as Core, except with bigger blocks.
So when we do finally get bigger blocks, we will get them very, very fast: because it only takes a few hours to upgrade the software to keep all the good crypto and networking code that Core/Blockstream wrote - while tossing that single line of 1 MB "max blocksize" cripple-code from Core/Blockstream into the dustbin of history - just like people did with the Berlin Wall.
submitted by ydtm to btc [link] [comments]

GMaxwell in 2006, during his Wikipedia vandalism episode: "I feel great because I can still do what I want, and I don't have to worry what rude jerks think about me ... I can continue to do whatever I think is right without the burden of explaining myself to a shreaking [sic] mass of people."

https://en.wikipedia.org/w/index.php?title=User_talk:Gmaxwell&diff=prev&oldid=36330829
Is anyone starting to notice a pattern here?
Now we're starting to see that it's all been part of a long-term pattern of behavior for the last 10 years with Gregory Maxwell, who has deep-seated tendencies towards:
After examining his long record of harmful behavior on open-source software projects, it seems fair to summarize his strengths and weaknesses as follows:
(1) He does have excellent programming skills.
(2) He likes needs to be in control.
(3) He always believes that whatever he's doing is "right" - even if a consensus of other highly qualified people happen to disagree with him (who he rudely dismisses "shrieking masses", etc.)
(4) Because of (1), (2), and (3) we are now seeing how dangerous is can be to let him assume power over an open-source software project.
This whole mess could have been avoided.
This whole only happened because people let Gregory Maxwell "be in charge" of Bitcoin development as CTO of Blockstream;
The whole reason the Bitcoin community is divided right now is simply because Gregory Maxwell is dead-set against any increase in "max blocksize" even to a measly 2 MB (he actually threatened to leave the project if it went over 1 MB).
This whole problem would go away if he could simply be man enough to step up and say to the Bitcoin community:
"I would like to offer my apologies for having been so stubborn and divisive and trying to always be in control. Although it is still my honest personal belief that that a 1 MB 'max blocksize' would be the best for Bitcoin, many others in the community evidently disagree with me strongly on this, as they have been vehement and unrelenting in their opposition to me for over a year now. I now see that any imagined damage to the network resulting from allowing big blocks would be nothing in comparison to the very real damage to the community resulting from forcing small blocks. Therefore I have decided that I will no longer attempt to force my views onto the community, and I shall no longer oppose a 'max blocksize' increase at this time."
Good luck waiting for that kind of an announcement from GMax! We have about as much a chance of GMax voluntarily stepping down as leader of Bitcoin, as Putin voluntarily stepping down as leader of Russia. It's just not in their nature.
As we now know - from his 10-year history of divisiveness and vandalism, and from his past year of stonewalling - he would never compromise like this, compromise is simply not part of his vocabulary.
So he continues to try to impose his wishes on the community, even in the face of ample evidence that the blocksize could easily be not only 2 MB but even 3-4 MB right now - ie, both the infrastructure and the community have been empirically surveyed and it was found that the people and the bandwidth would both easily support 3-4 MB already.
But instead, Greg would rather use his postion as "Blockstream CTO" to overrule everyone who supports bigger blocks, telling us that it's impossible.
And remember, this is the same guy who a few years ago was also telling us that Bitcoin itself was "mathematically impossible".
So here's a great plan get rich:
(1) Find a programmer who's divisive and a control freak and who overrides consensus and who didn't believe that Bitcoin was possible and and doesn't believe that it can do simple "max blocksize"-based scaling (even in the face of massive evidence to the contrary).
(2) Invest $21+55 million in a private company and make him the CTO (and make Adam Back the CEO - another guy who also didn't believe that Bitcoin would work).
(3) ???
(4) Profit!
Greg and his supporters say bigblocks "might" harm Bitcoin someday - but they ignore the fact that smallblocks are already harming Bitcoin now.
Everyone from Core / Blockstream mindlessly repeats Greg's mantra that "allowing 2 MB blocks could harm the network" - somehow, someday (but actually, probably not: see Footnotes [1], [2], [3], and [4] below).
Meanhwhile, the people who foolishly put their trust in Greg are ignoring the fact that "constraining to 1 MB blocks is harming the community" - right now (ie, people's investments and businesses are already starting to suffer).
This is the sad situation we're in.
And everybody could end up paying the price - which could reach millions or billions of dollars if people don't wake up soon and get rid of Greg Maxwell's toxic influence on this project.
At some point, no matter how great Gregory Maxwell's coding skills may be, the "money guys" behind Blockstream (Austin Hill et al.), and their newer partners such as the international accounting consultancy PwC - and also the people who currently hold $5-6 billion dollars in Bitcoin wealth - and the miners - might want to consider the fact that Gregory Maxwell is so divisive and out-of-touch with the community, that by letting him continue to play CTO of Bitcoin, they may be in danger of killing the whole project - and flushing their investments and businesses down the toilet.
Imagine how things could have been right now without GMax.
Just imagine how things would be right now if Gregory Maxwell hadn't wormed his way into getting control of Bitcoin:
There is a place for everyone.
Talented, principled programmers like Greg Maxwell do have their place on software development projects.
Things would have been fine if we had just let him work on some complicated mathematical stuff like Confidential Transactions (Adam Back's "homomorphic encryption") - because he's great for that sort of thing.
(I know Greg keeps taking this as a "back-handed (ie, insincere) compliment" from me nullc - but I do mean it with all sincerity: I think he have great programming and cryptography skills, and I think his work on Confidential Transactions could be a milestone for Bitcoin's privacy and fungibility. But first Bitcoin has to actually survive as a going project, and it might not survive if he continues insist on tring to impose his will in areas where he's obviously less qualified, such as this whole "max blocksize" thing where the infrastructure and the market should be in charge, not a coder.)
But Gregory Maxwell is too divisive and too much of a control freak (and too out-of-touch about what the technology and the market are actually ready for) to be "in charge" of this software development project as a CTO.
So this is your CTO, Bitcoin. Deal with it.
He dismissed everyone on Wikipedia back then as "shrieking masses" and he dismisses /btc as a "cesspool" now.
This guy is never gonna change. He was like this 10 years ago, and he's still like this now.
He's one of those arrogant C/C++ programmers, who thinks that because he understands C/C++, he's smarter than everyone else.
It doesn't matter if you also know how to code (in C/C++ or some other langugage).
It doesn't matter if you understand markets and economics.
It doesn't matter if you run a profitable company.
It doesn't even matter if you're Satoshi Nakamoto:
Satoshi Nakamoto, October 04, 2010, 07:48:40 PM "It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit / It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete."
https://np.reddit.com/btc/comments/3wo9pb/satoshi_nakamoto_october_04_2010_074840_pm_it_can/
Gregory Maxwell is in charge of Bitcoin now - and he doesn't give a flying fuck what anyone else thinks.
He has and always will simply "do whatever he thinks is right without the burden of explaining himself to you" - even he has to destroy the community and the project in the process.
That's just the kind of person he is - 10 years ago on Wikipedia (when he was just one of many editors), and now (where he's managed to become CTO of a company which took over Satoshi's respository and paid off most of its devs).
We now have to make a choice:
Footnotes:
[1]
If Bitcoin usage and blocksize increase, then mining would simply migrate from 4 conglomerates in China (and Luke-Jr's slow internet =) to the top cities worldwide with Gigabit broadban - and price and volume would go way up. So how would this be "bad" for Bitcoin as a whole??
https://np.reddit.com/btc/comments/3tadml/if_bitcoin_usage_and_blocksize_increase_then/
[2]
"What if every bank and accounting firm needed to start running a Bitcoin node?" – bdarmstrong
https://np.reddit.com/btc/comments/3zaony/what_if_every_bank_and_accounting_firm_needed_to/
[3]
It may well be that small blocks are what is centralizing mining in China. Bigger blocks would have a strongly decentralizing effect by taming the relative influence China's power-cost edge has over other countries' connectivity edge. – ForkiusMaximus
https://np.reddit.com/btc/comments/3ybl8it_may_well_be_that_small_blocks_are_what_is/
[4]
Blockchain Neutrality: "No-one should give a shit if the NSA, big businesses or the Chinese govt is running a node where most backyard nodes can no longer keep up. As long as the NSA and China DON'T TRUST EACH OTHER, then their nodes are just as good as nodes run in a basement" - ferretinjapan
https://np.reddit.com/btc/comments/3uwebe/blockchain_neutrality_noone_should_give_a_shit_if/
submitted by ydtm to btc [link] [comments]

BIP 101 = KISS ("Keep It Simple, Stupid")

It's better (ie: safer) to just...
... rather than inventing a whole new level-1 protocol such as Lightning Network.
BIP 100 is more complicated than BIP 101 in terms of game theory, economics, or predictability - which means that BIP 101 is better - ie safer - than BIP 100.
LN is a non-trivial engineering task, with no guarantee of success. LN might be a great idea and we should be happy that people are working on it - but it sure ain't KISS.
Evolving viewpoints
A few years ago, I was actually suspicious of Mike (because of proof-of-passport) and Gavin (because of that meeting with the CIA) - and I preferred the idealistic and speculative mathematical and game-theory scenarios discussed by guys like Adam Back and Peter Todd. It was just so much more “clever” and hence more appealing to the side of me that likes complicated puzzles and idealized solutions in the realms of mathematics and programming.
I have the greatest respect for Adam Back as a cryptographer, mathematician and innovator. For example, his proposals for "homomorphic encryption" which he shared on bitcointalk.org could provide the groundwork someday for much more anonymity in Bitcoin.
And I have read and liked a lot of stuff from Peter Todd - from back when he dumped a bunch of his coins when cex.io got close to triggering a 51% mining threat, and his more complicated stuff regarding RBF. I like math and programming and I like clever complicated solutions!
But, after reading everything I could find in the past few months on both sides of the block size debate, I've finally been getting some serious reminders about how starry-eyed and idealistic and impractical mathematicians and programmers can be. (I include myself in this group by the way – although I’m not great at math or programming, I have studied and worked a lot in these areas.)
Mike has a lot of practical experience dealing with security and scaling at Google (plus also implementing LevelDB in Bitcoin, and implementing a Java client BitcoinJ paving the way for clients on Android), and Gavin has a lot of practical experience from his time as the lead maintainer of the original Bitcoin client - and they both show the kind of maturity and practicality and common sense (and understanding of scaling and game theory and economics and threat modeling) which are most important for ensuring the success of an open-source project.
Some reference material
If you have time, I recommend perusing Mike's posts at the link below, where you see that not only has he done some important coding on Bitcoin (changing from Berkeley DB to LevelDB, writing BitcoinJ) but he also has a solid experience and understanding of how to prioritize issues involved in major programming projects:
https://www.reddit.com/useMike_Hearn
And I also recommend the recent video from Gavin, where he shows a clear understanding of governance and consensus on open-source projects:
https://www.youtube.com/watch?v=B8l11q9hsJM
Meanwhile, although I was enthralled for a while with some of the innovative mathematical ideas from Adam and exotic game-theory threats from Peter, I no longer think that these things should be prioritized - to use a word which occurs frequently in Mike Hearn's discussion of threat models on Google Groups:
https://groups.google.com/forum/#!searchin/bitcoin-xt/threat$20model/bitcoin-xt/zbPwfDf7UoQ/4uySXHVZCAAJ
I myself can get heavily into mathematics and programming (and can often spend way too much time pursuing things in those areas which are not a priority), so I appreciate the "managerial" common sense and maturity displayed by people like Mike and Gavin to establish priorities and deal with the most important things first.
I also think that Mike and Gavin have a much more realistic and practical understanding of "governance" and "consensus": namely, for a network running open-source code, there is no such thing as "developer consensus". Anyone (including an anonymous developer - anyone remember Satoshi Nakamoto?) can release anything they want - and then it is up to the network to decide to adopt it or not. This is the only real meaning of consensus.
And, as Mike has stated elsewhere: if the code cannot be forked, then it's not open-source.
The biggest priority in the short term (for the next few years at least) is to provide a simple scaling solution to support more user adoption, making maximal leverage of the stuff we already have: the existing code base and the available hardware and infrastructure. This is the direction that Gavin and Mike have been focusing on.
(By the way, as Mike has also pointed out elsewhere: user adoption itself is a very important metric of decentralization. If hundreds of millions more people start using the block chain directly in the next few years, this grassroots popularity really strengthens the system against many significant threats, such as interference from hostile state or corporate actors.)
Meanwhile, I think Adam's work on LN is something which could be important for the longer term - while some of the areas which Peter have focused on (such as RBF and "scorched earth") might be merely marginal improvements - or might actually make the system worse.
Shower thought: What if Adam had been more of an early adopter?
The other day I had a "shower thought" where I wondered what would happen if 1,000 people all donated 1 BTC each to Adam Back right now.
Evidently Adam, while being a fine mathematician / cryptographer and the inventor of the Bitcoin forerunner HashCash, was actually not a big-time early adopter of Bitcoin, so he apparently doesn't have very much "skin in the game" in terms of actual stake as a holder on the current level-0 block chain.
I sometimes wonder how things would be now if Adam had "gotten in on the ground floor" as an early "hodler". It might make him more inclined to work on providing improvements to level-0 (the block chain), instead of going off in some other direction trying to invent some complicated new level-1 system (Lightning Network).
KISS
Regarding the block size debate, we should apply the "KISS" principle here: "Keep It Simple, Stupid".
BIP 101 follows this KISS approach, while LN and BIP 100 (and side-chains and other interesting proposed projects such as RBF) are non-KISS, and hence more risky, and hence should be deprioritized (or perhaps even deprecated). This is simply practical common sense based on the experience of successful managers of big projects including scaling open-source software.
In a nutshell: if space on the block chain is starting to look like it might get congested in the near future, and more hardware and infrastructure are available right now and in the foreseeable future, then we have a choice between...
...then it's a no-brainer that the first option is the safer choice to scale the network in the short term.
Yes I've heard all the arguments that increasing the maximum block size could lead to more centralization - but this is something we can keep an eye on in advance.
https://getaddr.bitnodes.io/nodes/
Meanwhile, LN represents in some sense a kind of "hard fork" of an entirely different (ie much more complex) nature: Instead of simply changing just a single parameter while keeping 99% of the code and throwing more hardware at the problem, LN proposes making deep, major, "clever", non-KISS and unstudied changes in the architecture and topology (and game theory and economics) of the whole system itself.
And BIP 100 proposed a more-complicated voting procedure - giving miners too much say regarding the block size, and introducing more unpredictability (since the votes could lead to a wildly fluctuating max block size over the years).
Managers (and users and venture capitalists) love simple solutions where you can get 10x - 1000x - 10,000x scaling for the next few years (or decades) simply by throwing some more hardware and infrastructure at the problem, while leaving the existing codebase 99% unchanged. This is what BIP 101 does, and this is why people will adopt it instead of unproven, untried, untested, un-coded (vaporware) alternatives such as LN - or more complicated, unproven, untried, untested, riskier game-theory approaches such as BIP 100.
TL;DR: BIP 101 = KISS = Keep It Simple Stupid.
Just change a parameter and throw some more hardware at the problem and don't change anything else - ie, go with BIP 101.
submitted by ydtm to bitcoinxt [link] [comments]

A summary of Hadron's whitepaper

Hadron

submitted by shrieko to HadronCoin [link] [comments]

Intergalactic Money: The deep impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain federation

Intergalactic Money: The deep impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain federation
Prologue: This article is a strategic response to the following crypto-related papers published in 2017: 1. “An (Institutional) Investor’s Take on Cryptoassets” by John Pfeffer of Pfeffer Capital and 2. “Plasma: Scalable Autonomous Smart Contracts” by Joseph Poon of Lightning Network and Vitalik Buterin of Ethereum Foundation.
John Pfeffer in his paper titled “An (Institutional) Investor’s Take on Cryptoassets” claims that “scaling solutions for blockchains in particular and decentralized networks including (implied) DAG-based networks such as PoS, Sharding, etc. are bullish for adoption and users/consumers but bearish for token value/investors. Even without those technology shifts, the cost of using decentralized protocols is deflationary, since the cost of processing power, storage and bandwidth are deflationary.” Farther he states “ It’s a mistake to compare monopoly network effects of Facebook or other centralized platforms to blockchain protocols because blockchain protocols can be forked to a functionally identical blockchain with the same history and users up to the moment if a parent chain persists in being arbitrarily expensive to use(i.e. rent-seeking). Like TCP/IP but unlike Facebook, blockchain protocols are open-source software that anyone can copy or fork freely.” Add regulatory pressures on bitcoin and public permissionless currency and its negative impact.

https://preview.redd.it/zjyhwcacmml11.jpg?width=636&format=pjpg&auto=webp&s=ea21ea7e6957cb39dfbb57fa3193e5805578d38d

It’s obvious from his statements; John is not aware of latest R&D projects focused on improving decentralized networks and advances in decentralized protocols especially “Unforkable Realtime Blockchains” such as Algorand, Bitlattice and Orch.Network based on Recursive STARKs and FHE/SHE. He is also ignorant of the fact that there are several projects working on self-evolving censor-proof quantum safe protocols such as Orch Network (token symbol: ORC and URL: https://orch.network/). These protocols have adopted a continuous development strategy while getting ready for next paradigm shifts in technology e.g. practical quantum computing and quantum internet. He also does not understand that a futuristic protocol token with infinite-divisibility integrated with a hybrid quantum-classical computational infrastructure can easily counteract and neutralize the deflationary nature of its own tokens and its limited supply hardcap making it infinitely scalable and elastic.
While I agree with his following statement: “A non-sovereign, non-fiat, trustless, censorship-resistant cryptoasset would be a far better alternative for most foreign currency international reserves. IMF SDRs are already a synthetic store of value, so could also be easily and sensibly replaced by such a cryptoasset.”, this necessarily does not make BTC the right candidate for several reasons: 1. BTC is not a self-improving self-evolvable fully censorship-resistant cryptoasset which is a must for it to qualify as a viable reserve asset and appeal to long-term institutional and high networth investors.
Bitcoins miners are mostly corporate entities having large investments in ASIC-based mining equipments. It’s not impossible to corner 51% mining power by a centralized resourceful entity compromising double spending protection and other trustless security measures built-in. So BTC is not truly decentralized. 2. The underlying hash algorithm and encryption protocol of BTC known as SHA-256 can be broken by multi-qubit quantum circuits and quantum computers under active development in labs across the world. So BTC is not future-proof and its very existence is threatened unless its core developers continuously modify and improve its underlying security model and technology. 3. Bitcoin is not infinitely-divisible that’s it’s not only upwardly non-scalable, the same is true for its downward scalability. In fact BTC has only 8 decimal places known as Satoshis(1 satoshi = 0.00000001 BTC)
Futuristic protocol tokens such as infinitely scalable minerless Orch(ORC) should be more attractive to long-term investors looking for an alternative non-sovereign, non-fiat, and trustless, censorship-resistant privacy preserving high-velocity cryptoasset.
In their paper titled “Plasma: Scalable Autonomous Smart Contracts” Joseph Poon and Vitalik Buterin defines their proposal as “Plasma is a proposed framework for incentivized and enforced execution of ‘smart contracts’ which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.” Now first thing is it’s not clear what do they mean by “Autonomous Smart Contracts” and what specifically autonomous component in Plasma it refers to. For example, an autonomous weapon would set the target and hit it on its own without any humans in the loop or an autonomous self-driving car would drive down to a destination point without any human navigating it.
Now contrary to their claims, their off-chain and second-layer scaling solution with Ethereum(ETH) as the root blockchain is neither censor-proof nor truly scalable as this requires state-channel based masternodes/validators. So it’s not a feasible solution at all as trust issues will crop up at every moment.
Moreover, Scalable Multi-Party Computation is feasible only in a platform that guarantees functional encryption i.e. query, exchange and computation between encrypted objects, data and entities which is possible only via recursive STARKs and Lattice-based FHE(Fully Homomorphic Encryption). A second-layer protocol like Plasma does not have the capability of providing functional encryption to all distributed anonymous parties having zero mutual trusts.
There is a repeated effort to push some dangerous products under a guise of advanced blockchains and decentralized platforms. For instance, hidden external oracles and corporate entity-controlled decentralized platforms. Blockchain applications live in their own digital realm, totally orthogonal to the real world and environment we live in. Be it decentralized application or a smart contract, their reach is limited to the space they can control. Any use case projection in our reality eventually confronts the following hard fact: how can an app efficiently and securely interact with the physical world? Now hidden external oracles like that of oraclize.it and hardware pythias are being marketed as the solutions to this problem. But (IMHO) internal encrypted entities of Orch (ORC) platform known as Degents having access to cryptographically reliable external software/hardware sensors-actors will transparently and securely interact with the external world/environment.
Only minerless future-proof general-purpose decentralized networks such as Orch(ORC) designed from scratch as an MPC(Multiparty Computation) platform can deliver truly scalable MPC solutions flawlessly and reliably to millions of consumers simultaneously without compromising on security and trustlessness.
The far reaching impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain with built-in quantum safe privacy and multicompute features will be immeasurable and profound.
It would transform the whole universe of blockchain and decentralized networks inlcuding all blockchain-based and blockchainfree platforms such as DAG-based and DHT-based platforms e.g. IOTA, Nano and Holochain.
Orch Network (native token symbol: ORC and URL: https://orch.network) will enable and power following dapps and user-cases:

  1. Privacy-preserving Infinitely-divisible Hypercurrency and Confidential Global Payment System with integrated encrypted decentralized chat service
  2. Unmanned Decentralized Cryptoasset Exchanges
  3. Large-scale Federated IoT Networks
  4. Decentralized DNS Clusters
  5. Anonymous trading of Tokenized Financial Assets and Derivatives Contracts
  6. Automated Hedge Funds
  7. Crypto darkpools
  8. Temporal Insurance Products
  9. Global Supply chain and unmanned cargo ships and drones
  10. Realtime Encrypted Video Communication capable Anonymous Web Infrastructure
  11. High-velocity Non-sovereign Reserve Asset
  12. Near-Perfect Coin Mixer
  13. Decentralized Marketplace App
  14. Transparent Robust Stable Coins
  15. Decentralized P2P Storage of functionally encrypted data
  16. Permissionless ICO Platforms
  17. Decentralized and Encrypted Facebook, gmail, Twitter and google-like search/answer engines
  18. Decentralized CDNs
  19. Customizable Decentralized Governance System for blockchains and dapps
Another important thing that will boost the price and value of Orch Network token ORC is its integrated Turing Incomplete cyber contract protocol running Turing Incomplete cyber contracts written in Crackcity(a Turing Incomplete language derived from Crack and Simplicity) that runs on top of Crack Machine(s). Crack machines are Orch’s blockchain virtual machines.
Ethereum’s main deficiency and Achilles’ heel is its Turing Complete smart contract programming language Solidity.

  1. Turing-complete languages are fundamentally inappropriate for writing “smart contracts” — because such languages are inherently undecidable, which makes it impossible to know what a “smart contract” will do before running it.
(2) We should learn from Wall Street’s existing DSLs (domain-specific languages) for financial products and smart contracts, based on declarative and functional languages such as Ocaml and Haskell — instead of doing what the Web 2.0 programmers” behind Solidity did, and what Peter Todd is also apparently embarking upon: ie, ignoring the lessons that Wall Street has already learned, and “reinventing the wheel”, using less-suitable languages such as C++ and JavaScript-like languages (Solidity), simply because they seem “easier” for the “masses” to use.
(3) We should also consider using specification languages (to say what a contract does) along with implementation languages (saying how it should do it) — because specifications are higher-level and easier for people to read than implementations which are lower-level meant for machines to run — and also because ecosystems of specification/implementation language pairs (such as Coq/Ocaml) support formal reasoning and verification tools which could be used to mathematically prove that a smart contract’s implementation is “correct” (ie, it satisfies its specification) before even running it.
Turing-complete languages lead to “undecidable” programs (ie, you cannot figure out what you do until after you run them)
One hint: recall that Gödel’s incompleteness theorem proved that any mathematical system which is (Turing)-complete, must also be inconsistent incomplete [hat tip] — that is, in any such system, it must be possible to formulate propositions which are undecidable within that system.
This is related to things like the Halting Problem.
And by the way, Ethereum’s concept of “gas” is not a real solution to the Halting Problem: Yes, running out of “gas” means that the machine will “stop” eventually, but this naïve approach does not overcome the more fundamental problems regarding undecidability of programs written using a Turing-complete language.
The take-away is that:
When using any Turing-complete language, it will always be possible for someone (eg, the DAO hacker, or some crook like Bernie Madoff, or some well-meaning but clueless dev from slock.it) to formulate a “smart contract” whose meaning cannot be determined in advance by merely inspecting the code: ie, it will always be possible to write a smart contract whose meaning can only be determined after running the code.
Take a moment to contemplate the full, deep (and horrifying) implications of all this.
Some of the greatest mathematicians and computer scientists of the 20th century already discovered and definitively proved (much to the consternation most of their less-sophisticated (naïve) colleagues — who nevertheless eventually were forced to come around and begrudgingly agree with them) that: Given a “smart contract” written in a Turing-complete language, it is impossible to determine the semantics / behavior of that “smart contract” in advance, by mere inspection — either by a human, or even by a machine such as a theorem prover or formal reasoning tool (because such tools unfortunately only work on more-restricted languages, not on Turing-complete languages — for info on such more-restricted languages, see further below on “constructivism” and “intuitionistic logic”).
The horrifying conclusion is that: the only way to determine the semantics / behavior of a “smart contract” is “after-the-fact” — ie, by actually running it on some machine (eg, the notorious EVM) — and waiting to see what happens (eg, waiting for a hacker to “steal” tens of millions of dollars — simply because he understood the semantics / behavior of the code better than the developers did.
Last but not the least, increasing regulatory pressures on Bitcoin, Ethereum and other permissionless public cryptocurrencies/cryptotokens will impact their prices negatively in the medium to long-term.
The need for a hyperfast private zero-knowledge proof cryptocurrency that keeps payer-payee and payment data private and secure along with a decentralized scalable multicomputation platform can’t be overemphasized.
submitted by OrchNetwork to u/OrchNetwork [link] [comments]

Intergalactic Money: The deep impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain federation

Intergalactic Money: The deep impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain federation
Prologue: This article is a strategic response to the following crypto-related papers published in 2017: 1. “An (Institutional) Investor’s Take on Cryptoassets” by John Pfeffer of Pfeffer Capital and 2. “Plasma: Scalable Autonomous Smart Contracts” by Joseph Poon of Lightning Network and Vitalik Buterin of Ethereum Foundation.
John Pfeffer in his paper titled “An (Institutional) Investor’s Take on Cryptoassets” claims that “scaling solutions for blockchains in particular and decentralized networks including (implied) DAG-based networks such as PoS, Sharding, etc. are bullish for adoption and users/consumers but bearish for token value/investors. Even without those technology shifts, the cost of using decentralized protocols is deflationary, since the cost of processing power, storage and bandwidth are deflationary.” Farther he states “ It’s a mistake to compare monopoly network effects of Facebook or other centralized platforms to blockchain protocols because blockchain protocols can be forked to a functionally identical blockchain with the same history and users up to the moment if a parent chain persists in being arbitrarily expensive to use(i.e. rent-seeking). Like TCP/IP but unlike Facebook, blockchain protocols are open-source software that anyone can copy or fork freely.” Add regulatory pressures on bitcoin and public permissionless currency and its negative impact.
It’s obvious from his statements; John is not aware of latest R&D projects focused on improving decentralized networks and advances in decentralized protocols especially “Unforkable Realtime Blockchains” such as Algorand, Bitlattice and Orch.Network based on Recursive STARKs and FHE/SHE. He is also ignorant of the fact that there are several projects working on self-evolving censor-proof quantum safe protocols such as Orch Network (token symbol: ORC and URL: https://orch.network/). These protocols have adopted a continuous development strategy while getting ready for next paradigm shifts in technology e.g. practical quantum computing and quantum internet. He also does not understand that a futuristic protocol token with infinite-divisibility integrated with a hybrid quantum-classical computational infrastructure can easily counteract and neutralize the deflationary nature of its own tokens and its limited supply hardcap making it infinitely scalable and elastic.

https://preview.redd.it/lj2bgefhmml11.jpg?width=636&format=pjpg&auto=webp&s=ce282da0942d65464d7edf2c822fff4737f0aa87
While I agree with his following statement: “A non-sovereign, non-fiat, trustless, censorship-resistant cryptoasset would be a far better alternative for most foreign currency international reserves. IMF SDRs are already a synthetic store of value, so could also be easily and sensibly replaced by such a cryptoasset.”, this necessarily does not make BTC the right candidate for several reasons: 1. BTC is not a self-improving self-evolvable fully censorship-resistant cryptoasset which is a must for it to qualify as a viable reserve asset and appeal to long-term institutional and high networth investors.
Bitcoins miners are mostly corporate entities having large investments in ASIC-based mining equipments. It’s not impossible to corner 51% mining power by a centralized resourceful entity compromising double spending protection and other trustless security measures built-in. So BTC is not truly decentralized. 2. The underlying hash algorithm and encryption protocol of BTC known as SHA-256 can be broken by multi-qubit quantum circuits and quantum computers under active development in labs across the world. So BTC is not future-proof and its very existence is threatened unless its core developers continuously modify and improve its underlying security model and technology. 3. Bitcoin is not infinitely-divisible that’s it’s not only upwardly non-scalable, the same is true for its downward scalability. In fact BTC has only 8 decimal places known as Satoshis(1 satoshi = 0.00000001 BTC)
Futuristic protocol tokens such as infinitely scalable minerless Orch(ORC) should be more attractive to long-term investors looking for an alternative non-sovereign, non-fiat, and trustless, censorship-resistant privacy preserving high-velocity cryptoasset.
In their paper titled “Plasma: Scalable Autonomous Smart Contracts” Joseph Poon and Vitalik Buterin defines their proposal as “Plasma is a proposed framework for incentivized and enforced execution of ‘smart contracts’ which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.” Now first thing is it’s not clear what do they mean by “Autonomous Smart Contracts” and what specifically autonomous component in Plasma it refers to. For example, an autonomous weapon would set the target and hit it on its own without any humans in the loop or an autonomous self-driving car would drive down to a destination point without any human navigating it.
Now contrary to their claims, their off-chain and second-layer scaling solution with Ethereum(ETH) as the root blockchain is neither censor-proof nor truly scalable as this requires state-channel based masternodes/validators. So it’s not a feasible solution at all as trust issues will crop up at every moment.
Moreover, Scalable Multi-Party Computation is feasible only in a platform that guarantees functional encryption i.e. query, exchange and computation between encrypted objects, data and entities which is possible only via recursive STARKs and Lattice-based FHE(Fully Homomorphic Encryption). A second-layer protocol like Plasma does not have the capability of providing functional encryption to all distributed anonymous parties having zero mutual trusts.
There is a repeated effort to push some dangerous products under a guise of advanced blockchains and decentralized platforms. For instance, hidden external oracles and corporate entity-controlled decentralized platforms. Blockchain applications live in their own digital realm, totally orthogonal to the real world and environment we live in. Be it decentralized application or a smart contract, their reach is limited to the space they can control. Any use case projection in our reality eventually confronts the following hard fact: how can an app efficiently and securely interact with the physical world? Now hidden external oracles like that of oraclize.it and hardware pythias are being marketed as the solutions to this problem. But (IMHO) internal encrypted entities of Orch (ORC) platform known as Degents having access to cryptographically reliable external software/hardware sensors-actors will transparently and securely interact with the external world/environment.
Only minerless future-proof general-purpose decentralized networks such as Orch(ORC) designed from scratch as an MPC(Multiparty Computation) platform can deliver truly scalable MPC solutions flawlessly and reliably to millions of consumers simultaneously without compromising on security and trustlessness.
The far reaching impact of a self-evolving infinitely-scalable general-purpose realtime unforkable public blockchain with built-in quantum safe privacy and multicompute features will be immeasurable and profound.
It would transform the whole universe of blockchain and decentralized networks inlcuding all blockchain-based and blockchainfree platforms such as DAG-based and DHT-based platforms e.g. IOTA, Nano and Holochain.
Orch Network (native token symbol: ORC and URL: https://orch.network) will enable and power following dapps and user-cases:

  1. Privacy-preserving Infinitely-divisible Hypercurrency and Confidential Global Payment System with integrated encrypted decentralized chat service
  2. Unmanned Decentralized Cryptoasset Exchanges
  3. Large-scale Federated IoT Networks
  4. Decentralized DNS Clusters
  5. Anonymous trading of Tokenized Financial Assets and Derivatives Contracts
  6. Automated Hedge Funds
  7. Crypto darkpools
  8. Temporal Insurance Products
  9. Global Supply chain and unmanned cargo ships and drones
  10. Realtime Encrypted Video Communication capable Anonymous Web Infrastructure
  11. High-velocity Non-sovereign Reserve Asset
  12. Near-Perfect Coin Mixer
  13. Decentralized Marketplace App
  14. Transparent Robust Stable Coins
  15. Decentralized P2P Storage of functionally encrypted data
  16. Permissionless ICO Platforms
  17. Decentralized and Encrypted Facebook, gmail, Twitter and google-like search/answer engines
  18. Decentralized CDNs
  19. Customizable Decentralized Governance System for blockchains and dapps
Another important thing that will boost the price and value of Orch Network token ORC is its integrated Turing Incomplete cyber contract protocol running Turing Incomplete cyber contracts written in Crackcity(a Turing Incomplete language derived from Crack and Simplicity) that runs on top of Crack Machine(s). Crack machines are Orch’s blockchain virtual machines.
Ethereum’s main deficiency and Achilles’ heel is its Turing Complete smart contract programming language Solidity.

  1. Turing-complete languages are fundamentally inappropriate for writing “smart contracts” — because such languages are inherently undecidable, which makes it impossible to know what a “smart contract” will do before running it.
(2) We should learn from Wall Street’s existing DSLs (domain-specific languages) for financial products and smart contracts, based on declarative and functional languages such as Ocaml and Haskell — instead of doing what the Web 2.0 programmers” behind Solidity did, and what Peter Todd is also apparently embarking upon: ie, ignoring the lessons that Wall Street has already learned, and “reinventing the wheel”, using less-suitable languages such as C++ and JavaScript-like languages (Solidity), simply because they seem “easier” for the “masses” to use.
(3) We should also consider using specification languages (to say what a contract does) along with implementation languages (saying how it should do it) — because specifications are higher-level and easier for people to read than implementations which are lower-level meant for machines to run — and also because ecosystems of specification/implementation language pairs (such as Coq/Ocaml) support formal reasoning and verification tools which could be used to mathematically prove that a smart contract’s implementation is “correct” (ie, it satisfies its specification) before even running it.
Turing-complete languages lead to “undecidable” programs (ie, you cannot figure out what you do until after you run them)
One hint: recall that Gödel’s incompleteness theorem proved that any mathematical system which is (Turing)-complete, must also be inconsistent incomplete [hat tip] — that is, in any such system, it must be possible to formulate propositions which are undecidable within that system.
This is related to things like the Halting Problem.
And by the way, Ethereum’s concept of “gas” is not a real solution to the Halting Problem: Yes, running out of “gas” means that the machine will “stop” eventually, but this naïve approach does not overcome the more fundamental problems regarding undecidability of programs written using a Turing-complete language.
The take-away is that:
When using any Turing-complete language, it will always be possible for someone (eg, the DAO hacker, or some crook like Bernie Madoff, or some well-meaning but clueless dev from slock.it) to formulate a “smart contract” whose meaning cannot be determined in advance by merely inspecting the code: ie, it will always be possible to write a smart contract whose meaning can only be determined after running the code.
Take a moment to contemplate the full, deep (and horrifying) implications of all this.
Some of the greatest mathematicians and computer scientists of the 20th century already discovered and definitively proved (much to the consternation most of their less-sophisticated (naïve) colleagues — who nevertheless eventually were forced to come around and begrudgingly agree with them) that: Given a “smart contract” written in a Turing-complete language, it is impossible to determine the semantics / behavior of that “smart contract” in advance, by mere inspection — either by a human, or even by a machine such as a theorem prover or formal reasoning tool (because such tools unfortunately only work on more-restricted languages, not on Turing-complete languages — for info on such more-restricted languages, see further below on “constructivism” and “intuitionistic logic”).
The horrifying conclusion is that: the only way to determine the semantics / behavior of a “smart contract” is “after-the-fact” — ie, by actually running it on some machine (eg, the notorious EVM) — and waiting to see what happens (eg, waiting for a hacker to “steal” tens of millions of dollars — simply because he understood the semantics / behavior of the code better than the developers did.
Last but not the least, increasing regulatory pressures on Bitcoin, Ethereum and other permissionless public cryptocurrencies/cryptotokens will impact their prices negatively in the medium to long-term.
The need for a hyperfast private zero-knowledge proof cryptocurrency that keeps payer-payee and payment data private and secure along with a decentralized scalable multicomputation platform can’t be overemphasized.
submitted by OrchNetwork to u/OrchNetwork [link] [comments]

New Coin Idea - POW exclusively brute forcing Satoshi's Private Key

I like the idea of a Coin that does work, other than just recording transactions. I see this as the future of cryptocoins.
This is just an example of "a-coin-does-work", using the community's familiarity/interst in the eventual payout to boost adoption rate:
This model can be used to brute force any Bitcoin private key...but is only useful if you can be sure the coins won't be moved to a new key 20 yrs down the line.
I'm not quite sure how the "payout script" would work...perhaps some implementation of Homomorphic encryption: https://en.wikipedia.org/wiki/Homomorphic_encryption
Any ideas/pitfalls welcome.
submitted by psofe to Cryptocoin [link] [comments]

Redefining Democracy by Max Kaye & Nathan Spataro

https://voteflux.org/pdf/Redefining%20Democracy%20-%20Kaye%20&%20Spataro%201.0.2.pdf
This paper is not block chain per se, it's about a new form of democracy that results in decentralising government to voters, keeping democracy in tact and in fact, improving it. It's called Issue Based Direct Democracy (IBDD)
The people who authored this article are developing a blockchain based voting application. which can implement the ideas of IBDD, at the moment it's just used for facilitating voting. Max was on the original Ethereum team and contributed on the scalability and smart contract side. Nathan is the CEO of SecureVote. The way the protocol works is quite novel.
I'd also like to mention this is not a shill post, as the only way to gain exposure to this company is to invest in it. there are no tokens to buy unless you want to buy Ethereum (this will be explained)
The paper looks at our current democratic system, notes its flaws e.g. corruption. looks at the 3 main types of democracy and grabs the best ideas from all of them. Which gives us IDBB.
Since this is a cryptotechnology sub, ill divulge what i know about the blockchain implementation of the protocol. I was briefly involved with https://secure.vote/ in Sydney.
I was able to chat to Max and discuss the protocol. Privacy of mine was a huge concern with this protocol so I wanted to know more about how it worked e.g. homomorphic encryption, zeroproofs, ECDH etc. When I first heard about it, I figured it was just a dApp running on eth, neo etc. which highlighted other concerns. The implementation is nothing like that.
It's been a while since I discussed this with Max, and i do not have a white paper, it was him speaking to me, telling me how the protocol worked. Max is brilliant at what he does. The conversation was basically a white paper explained to me in an hour. its hard to remember everything from a conversation. He speaks fast and is very knowledgeable.
High level overview of how this blockchain protocol works
The stress test was 18k votes / sec (able to be audited live from a desktop pc) but they claim it could be bumped up to 150k votes / sec on a desktop (though that requires 10 mb/s downlink consistently)
The https://voteflux.org/ party in Australia is trying to promote the ideas of IBDD.
I asked Max if he would like to do an AMA on this subreddit and he is interested. I certainly am, i hope you all are also.
EDIT: If you have any questions for Max in his AMA, please list them here. it will give him some time to prepare. Allways_Wrong already asked some good ones, so you're not always_wrong ;)
e.g.
submitted by Neophyte- to CryptoTechnology [link] [comments]

Ethereum Research Directions

Hello potential research collaborator! Rumour has it that you, a researcher or manager of researchers, are interested in joint research with the Ethereum Foundation. Below are the primary topics the Foundation will be thinking about for the next 2-3 years. If you, like us, enjoy the prospect of thinking about one or more of these topics for the majority of your waking hours, do get in touch. The Foundation does have money to pay the salaries/stipend of those undertaking high-value research.
We have topics in both pure research and applied research. The Foundation as well as the larger Ethereum community seek help on both. Typical outputs from researchers are: peer-reviewed academic papers, technical reports, and/or implementations (prototypes as well as production-ready).
Questions in Fundamental Research Q1: Can we create a theory of cryptoeconomic mechanisms? There are certain patterns that are often used in cryptoeconomic mechanisms. These can be studied in the abstract independently of any specific use case. Security deposits (see also proof of stake) How do we model capital lockup costs? Dual-use of security deposits Challenge-response games (one group of actors is given the opportunity to submit evidence that fact X is false, and if no one submits evidence within some period of time, then X is assumed to be true). See also challenge-response authentication. Channels State channels How do we minimize the vulnerability of challenge-response games and channels to liveness or censorship faults of the underlying blockchain? Escalation games Cross-chain interoperability (see the R3 interoperability paper ) Relays Hash timelock atomic swaps Q2: What is the role of cryptoeconomics in distributed systems? What is the role of economics in cryptography? Can we formalize how algorithmic incentives (“cryptoeconomics”) can enhance information security?
Modeling behavior of participants in mechanisms
Simple (crash) faults Byzantine faults (arbitrary) Byzantine-Altruistic-Rational (BAR) model Uncoordinated majority (e.g., as in selfish mining) Coordinated choice Bribing attacker (as in P+epsilon attacks or iceman) Behavioral economics models (prospect theory, endowment effect, loss aversion, morality, etc.) Complex game-theoretic interactions
Blackmail Quantifying cooperative interactions among agents (e.g. dynamic coalition formation) Evolution and enforcements of group norms Q3: How do distributed systems influence current economics? On net, when and how much does decentralization lower transaction costs? No obvious answer. Decentralization _decreases_transaction costs because of: Reduced number of counterparties and reduced need for building trust Yet decentralization increases transaction costs because of: increased technical overhead, Decreased usability, increased responsibility. Are Transaction costs = transaction fees + coordination costs? Q4: Within game-theory, can we quantify coordination costs? for players running a particular protocol for players executing a particular strategy Q5: What are ways we can manipulate (e.g., guarantee/minimize) coordination costs? For example, we can reduce risk by increasing coordination costs. Coordination costs are costs from multiple-agents coordinating. For example: Discovering potential peers, agreeing on computing coalition strategies, synchronization required for execution, costs of proving to the coalition that players followed coalition strategies, cost of getting rid of individual incentives to deviate Q6: What protocols have better fault attribution? A protocol fault is uniquely attributable if there is evidence that could be used to umambiguously convince any observer which actor caused the protocol fault. If a fault is non-uniquely-attributable, the blame for the fault can often at least be narrowed down to within N specific actors.
Fault attributability in various consensus algorithms
Chain-based (synchronous) consensus Partially synchronous consensus (see minimal slashing conditions) Common coins in asynchronous consensus Attributability of censorship or liveness faults.
Translating fault attributions into penalties
Shapley values Q7: What are decentralization’s fundamental limits? Building on hundreds of impossibility results. E.g., 1 and 2, or even fundamental limits from other areas of computer science.
What centralized protocols can be decentralized (while preserving guarantees)? At what cost in protocol overhead? Are there limits to scalability? For Bitcoin: On Scaling Decentralized Blockchains Only because of the requirement for shared state? At what cost in incentivization? What are the limits to incentivization? Limits to attribution Limits to mechanism budgets With how much security (against coordinated choice, trusted majority required)? Limits to fault tolerance e.g. in objective protocols and subjective protocols Objectives in Applied Research Also knows as Pasteur’s Quadrant.
Right now our primary topics in applied research are: plasma, sharding, and Casper.
  1. Base Layer (core protocols) 1.1 Plasma and Sharding [49%] Goal: Allow Ethereum transaction capacity to scale to better than linear with computational capacity of the n nodes.
Sharding FAQ
Stateless clients
State channels
Plasma implementation
Data availability proofs [65%]
A note on data availability and erasure coding Effective state-space partitioning / Cross-shard communication [15%]
Vitalik’s R3 paper, particularly Section “scalability” (p20-30). The whole paper also has a three-page executive summary. High-Level-Languages [20%]
Topic: Developing a language that knows to send the cross-shard asynchronous messages whenever contracts are located on different shards. Topic: Applying prior theory from multicore CPUs/parallel threading to sharding.
1.2 Proof of Stake [70% complete] Goal: Fully transition Ethereum from Proof-of-work to Proof-of-stake.
Casper the Friendly Finality Gadget
Cryptocurrencies without Proof of Work
Proof of stake FAQ
Economic Incentive analysis [49%]
Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol Minimum Slashing Conditions Slasher Ghost, and Other Developments in Proof of Stake Least Authority Performs Incentive Analysis For Ethereum Demystifying incentives in the consensus computer On Stake Safety Under Dynamic Validator Sets Delegation protocols (or Voting Pool for PoS) [20%]
Using trusted hardware Formal Verification [45%]
Formal methods on some PoS stuff A mechanized safety proof with dynamic validators Formal methods on another Casper Securify.ch Testing and Implementation [20%]
History of Casper: Chapters 1, 2, 3, 4, and 5 Stage 1 CASPER contract and JSON RPC demo 1.3 Protocol Economics [50%] Goal: Increase economic incentive confluence in all aspects of the Ethereum protocol.
Gas Limit Policy / state-resource pricing
A theory of Blockchain Resoure Pricing [not ready for release; ask Virgil for link to pre-release] Topic: Validatominer economic policy—how much should we pay out?
1.4 Stategies for efficaciously hardforking for upgrades [40%] Goal: Smart-contracts are new territory and the best ideas in the space remain undiscovered. When we discover them, we must be able to roll them out gracefully.
Hard Forks, Soft Forks, Defaults and Coercion
The beautiful Vlad Zamfir on Soft forks, hard forks, and the Ethereum Social Contract
Topic: Hardforking the EVM
1.5 Ethereum Virtual Machine (EVM) upgrades and optimization [100%] Goal: Have a fast, efficient virtual machine optimized for processing cryptographic operations and smart-contracts. Update: Solved! We’re moving to eWASM!
  1. Layer 2 2.1 On-chain Random Number Generation [63%] Goal: This is an important special-case necessary for many applications. We wish to solve it.
Implementation Ethereum’s RANDAO A candidate alternative design from Vitalik Bitcoin Beacon On Bitcoin as a public randomness source NIST Randomness Beacon Bitcoin Beacon — Princeton Bitcoin seminar final project Tor project’s attempt at the same. 2.2 Privacy [40%] Goal: Allow apps to benefit from the transparency of blockchain-execution while preserving author privacy and the confidentiality of zer data. One solution, among several, is homomorphic encryption.
General: Privacy on the Blockchain
Mixers [30%] Bitcoin mixing remains an unsolved problem. As what’s possible in Ethereum is a strict superset of Bitcoin, solving for either case is sufficient. Incentivized Mixing?
Princeton Bitcoin course: Anonymity (Lecture 6) An Empirical Analysis of Linkability in the Monero Blockchain CoinParty: Secure Multi-Party Mixing of Bitcoins Secure and Anonymous Decentralized Bitcoin Mixing Decentralized Mixer based on RingSignature Laundromat: Mixing via ring signatures Voting [10%]
A Smart Contract for Boardroom Voting with Maximum Voter Privacy Zero knowlege proofs [30%]
ZK-Snarks Other
Confidential assets 2.3 Decentralized exchanges [50%] Goal: We wish to minimize the necessity of trusted third parties in currency exchanges.
Atomic swap on-chain decentralized exchanges mkr market etherdelta 2.4 High-level-languages (HLLs) [40%] Goal: Coding contracts (especially secure ones!) is hard. It should be easier. Please help us.
Our packet for recruiting PLT researchers.
Languages
Solidity Viper Pact Composing contrats: an adventure in finanial engineering Ivy Bamboo functional-solidity-language Pax Codex Hammurabi Project in Wolfram Language Formal Verification of HLLs [15%]
Formal Certification of a Compiler Back-end or: Programming a Compiler with a Proof Assistant Short Paper: Formal Verification of Smart Contracts Other programming language techniques to analyse smart contracts
Oyente, a symbolic execution based analyser for smart contracts Using Oyente to optimize smart contracts Defensive programming [30%]
Step by Step Towards Creating a Safe Smart Contract: Lessons and Insights from a Cryptocurrency Lab A Programmer’s Guide to Ethereum and Serpent A survey of attacks on Ethereum smart contracts Thinking About Smart Contract Security Ethereum Contract Security Techniques and Tips 2.5 Better Tokens, better token sales Goal: Understand how to design and manipulate tokens for specific properties, particularly paying attention to better ICOs
Vitalik on his Interactive Coin Offering The MiniMe/ERC223 talk from DEVCON3 An Optimal ICO mechanism Better ICOs category on ethresear.ch All about DAICOs Appendix Ethereum’s old list of open problems. Relevant Conferences Research communities whose interests intersect with Ethereum’s research include (in alphabetical order, non-exhaustive):
Algorithmic Game Theory. ACM Conference on Economics and Computation, Conference on Web and Internet Economics, Symposium on Algorithmic Game Theory, International Conference on Game Theory Blockchain. Annual Blockchain Summit, Coinfest, Consensus, Internet of Things World, Workshop on Bitcoin and Blockchain Research Computer Security. ACM Conference on Computer and Communications Security, IEEE Computer Security Foundations Symposium, USENIX Security Symposium Cryptography. CRYPTO (International Association for Cryptologic Research), EUROCRYPT (Annual International Conference on the Theory and Applications of Cryptographic Techniques) Distributed Computation. ACM Symposium on Principles of Distributed Computing, ACM Symposium on Parallelism in Algorithms and Architectures Multi-Agent Systems. International Conference on Autonomous Agents and Multiagent Sytems, AAAI Conference on Artificial Intelligence, International Joint Conference on Artificial Intelligence
http://notes.eth.sg/s/rkxpeG0ff
submitted by gwood333 to stellar1 [link] [comments]

Adam Back & Greg Maxwell are experts in mathematics and engineering, but not in markets and economics. They should not be in charge of "central planning" for things like "max blocksize". They're desperately attempting to prevent the market from deciding on this. But it *will*, despite their efforts.

Adam Back apparently missed the boat on being an early adopter, even after he was personally informed about Bitcoin in an email from Satoshi.
So Adam didn't mine or buy when bitcoins were cheap.
And he didn't join Bitcoin's Github repo until the price was at an all-time high.
He did invent HashCash, and on his Twitter page he proudly claims that "Bitcoin is just HashCash plus inflation control."
But even with all his knowledge of math and cryptography, he obviously did not understand enough about markets and economics - so he missed the boat on Bitcoin - and now he's working overtime to try to make up for his big mistake, with $21+55 million in venture-capital fiat backing him and his new company, Blockstream (founded in November 2014).
Meanwhile, a lot of the rest of us, without a PhD in math and crypto, were actually smarter than Adam about markets and economics.
And this is really the heart of the matter in these ongoing debates we're still forced to keep having with him.
So now it actually might make a certain amount of economic sense for us to spend some of our time trying to get adam3us Adam Back (and nullc Gregory Maxwell) to stop hijacking our Bitcoin codebase.
Satoshi didn't give the Bitcoin repo to a couple of economically clueless C/C++ devs so that they could cripple it by imposing artificial scarcity on blockchain capacity.
Satoshi was against central economic planners, and he gave Bitcoin to the world so that it could grow naturally as a decentralized, market-based emergent phenomenon.
Adam Back didn't understand the economics of Bitcoin back then - and he still doesn't understand it now.
And now we're also discovering that he apparently has a very weak understanding of legal concepts as well.
And that he also has a very weak understanding of negotiating techniques as well.
Who is he to tell us we should not do simple "max blocksize"-based scaling now - simply because he might have some pie-in-the-sky Rube-Goldberg-contraption solution months or years down the road?
He hasn't even figured out how to do decentralized path-finding in his precious Lightning Network.
So really what he's saying is:
I have half a napkin sketch here for a complicated expensive Rube-Goldberg-contraption solution with a cool name "Lightning Network"...
which might work several months or years down the road...
except I'm still stuck on the decentralized path-finding part...
but that's only a detail!
just like that little detail of "inflation control" which I was also too dumb to add to HashCash for years and years...
and which I was also too dumb to even recognize when someone shoved a working implementation of it in my face and told me I might be able to get rich off of it...
So trust me...
My solution will be much safer than that "other" ultra-simple KISS solution (Classic)...
which only involved changing a 1 MB to a 2 MB in some code, based on empirical tests which showed that the miners and their infrastructure would actually already probably support as much as 3 MB or 4 MB...
and which is already smoothly running on over 1,000 nodes on the network!
That's his roadmap: pie-in-the-sky, a day late and a dollar short.
That's what he has been trying to force on the community for over a year now - relying on censorship of online forums and international congresses, relying on spreading lies and FUD - and now even making vague ridiculous legal threats...
...but we still won't be intimidated by him, even after a year of his FUD and lies, with his PhD and his $21+55 million in VC backing.
Because he appears to be just plain wrong again.
Just like he was wrong about Bitcoin when he first heard about it.
Adam Back needs to face the simple fact that he does not understand how markets and economics work in the real world.
And he also evidently does not understand how negotiating and law and open-source projects work in the real world.
If he didn't have Theymos theymos supporting him via censorship, and austindhill Austin Hill and the other venture capitalists backing him with millions of dollars, then Adam Back would probably be just another unknown Bitcoin researcher right now, toiling away over yet another possible scaling solution candidate which nobody was paying much attention to yet, and which might make a splash a few months or years down the road (provided he eventually figures out that one nagging little detail about how to add the "decentralized path-finding"!).
In the meantime, Adam Back has hijacked our code to use as his own little pet C/C++ crypto programming project, for his maybe-someday scaling solution - and he is doing everything he can to suppress Satoshi's original, much simpler scaling plan.
Adam is all impeding Bitcoin's natural growth in adoption and price, through:
Transactions vs. Price graph showed amazingly tight correlation from 2011 to 2014. Then Blockstream was founded in November 2014 - and the correlation decoupled and the price stagnated.
Seriously, look closely at the graph in that imgur link:
https://imgur.com/jLnrOuK
What's going on in that graph?
So it seems logical to formulate the following hypothesis:
This, in a nutshell, is the hypothesis which the market is eager to test.
Via a hard-fork.
Which was not controversial to anyone in the Bitcoin community previously.
Including Satoshi Nakamoto:
Satoshi Nakamoto, October 04, 2010, 07:48:40 PM "It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit / It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete."
https://np.reddit.com/btc/comments/3wo9pb/satoshi_nakamoto_october_04_2010_074840_pm_it_can/
Including adam3us Adam Back:
Adam Back: 2MB now, 4MB in 2 years, 8MB in 4 years, then re-assess
https://np.reddit.com/Bitcoin/comments/3ihf2b/adam_back_2mb_now_4mb_in_2_years_8mb_in_4_years/
Including nullc Greg Maxwell:
"Even a year ago I said I though we could probably survive 2MB" - nullc
https://np.reddit.com/btc/comments/43mond/even_a_year_ago_i_said_i_though_we_could_probably/):
Including theymos Theymos:
Theymos: "Chain-forks [='hardforks'] are not inherently bad. If the network disagrees about a policy, a split is good. The better policy will win" ... "I disagree with the idea that changing the max block size is a violation of the 'Bitcoin currency guarantees'. Satoshi said it could be increased."
https://np.reddit.com/btc/comments/45zh9d/theymos_chainforks_hardforks_are_not_inherently/).
And the market probably will test this. As soon as it needs to.
Because Bitstream's $21+55 million in VC funding is just a drop in the bucket next to Bitcoin's $5-6 million dollars in market capitalization - which smart Bitcoin investors will do everything they can to preserve and increase.
The hubris and blindness of certain C/C++ programmers
In Adam's mind, he's probably a "good guy" - just some innocent programmer into crypto who thinks he understands Bitcoin and "knows best" how to scale it.
But he's wrong about the economics and scaling of Bitcoin now - just like he was wrong about the economics and scaling of Bitcoin back when he missed the boat on being an early adopter.
His vision back then (when he missed the boat) was too pessimistic - and his scaling plan right now (when he assents to the roadmap published by Gregory Maxwell) is too baroque (ie, needlessly complex) - and "too little, too late".
A self-fulfilling prophecy?
In some very real sense, there is a risk here that Adam's own pessimism about Bitcoin could turn into a self-fulfilling prophecy.
In other words, he never thought Bitcoin would succeed - and now maybe it really won't succeed, now that he has unfairly hijacked its main repo and is attempting to steer it in a direction which Satoshi clearly never intended.
It's even quite possible that there could be a subtle psychological phenomenon at play here: at some (unconscious) level, maybe Adam wants to prove that he was "right" when he missed the boat on Bitcoin because he thought it would never work.
After all, if Bitcoin fails (even due to him unfairly hijacking the code and the debate), then in some sense, it would be a kind of vindication for him.
Adam Back has simply never believed in Bitcoin and supported it the way most of the rest of us do. So he may (subconsciously) actually want to see it fail.
Subconscious "ego" issues may be at play.
There may be some complex, probably subconscious "ego" issues at play here.
I know this is a serious accusation - but after years of this foot-dragging and stonewalling from Adam, trying to strangle Bitcoin's natural growth, he shouldn't be surprised if people start accusing him (his ego, his blindness, his lack of understanding of markets and economics) of being one of the main risk factors which could seriously hurt Bitcoin.
This is probably a much more serious problem than he himself can probably ever comprehend. For it goes to one of his "blind spots" - which (by definition), he can never see - but the rest of the community can.
He thinks he's just some smart guy who is trying to help Bitcoin - and he is smart about certain things and he can help Bitcoin in certain ways.
For example, I was a big fan of Adam's back when I read his posts on bitcointalk.org about "homomorphic encryption" (which I guess now has been renamed as "Confidential Transactions" - "CT").
But, regarding his work on the so-called "Lightning Network", many people are still unconvinced on a few major points - eg:
  • LN would be quite complex and is still unproven, so we actually have no indication of whether it might not contain some minor but fatal flaw which will prevent it from working altogether;
  • In particular, there isn't even a "napkin sketch" or working concept for the most important component of LN - "decentralized path-finding":
https://np.reddit.com/bitcoin_uncensored/comments/3gjnmd/lightning_may_not_be_a_scaling_solution/
https://np.reddit.com/btc/comments/43sgqd/unullc_vs_buttcoiner_on_decentralized_routing_of/
https://np.reddit.com/btc/comments/43oi26/lightning_network_is_selling_as_a_decentralized/
  • It is simply unconscionable for Adam to oppose simpler "max blocksize"-based, on-chain scaling solutions now, apparently due to his unproven belief that a more complex off-chain and still-unimplemented scaling solution such as LN later would somehow be preferable (especially when LN still lacks a any plan for providing the key component of "decentralized path-finding").
Venture capitalists and censors have made Adam much more important than he should be.
If this were a "normal" or "traditional" flame war on a dev mailing list (ie, if there were no censorship from Theymos helping Adam, and no $21-55 million in VC helping Adam) - then the community would be ignoring Adam.
He'd be just another lonely math PhD toiling away on some half-baked pet project, ignored by the community instead of "leading" it.
So Adam (and Greg) are not smart about everything.
In particular, they do not appear to have a deep understanding how markets and economics work.
And we have proof of this - eg, in the form of:
Satoshi was an exception. He knew enough about markets and math, and enough about engineering and economics, to release the Bitcoin code which has worked almost flawlessly for 7 years now.
But guys like Adam and Greg are only good at engineering - they're terrible at economics.
As programmers, they have an engineer's mindset, where something is a "solution" only if it satisfies certain strict mathematical criteria.
But look around. A lot of technologies have become massively successful, despite being imperfect from the point of view of programming / mathematics, strictly speaking.
Just look at HTML / JavaScript / CSS - certainly not the greatest of languages in the opinions of many serious programmers - and yet here we are today, where they have become the de facto low-level languages which most of the world uses to interact on the Internet.
The "perfect" is the enemy of the "good".
The above saying captures much of the essence of the arguments continually being made against guys like Adam and Greg.
They don't understand how a solution which is merely "good enough" can actually take over the world.
They tend to "over-engineer" stuff, and they tend to ignore important issues about how markets and programs can interact in the real world.
In other words, they fail to understand that sometimes it's more important to get something "imperfect" out the door now, instead of taking too long to release something "perfect"...
... because time and tide waits for no man, and Bitcoin / Blockstream / Core are not the only cryptocurrency game in town.
If Adam and Greg can't provide the scaling which the market needs, when it needs it, then the market can and will look elsewhere.
This is why so many of us are arguing that (as paradoxical and deflating as it may feel for certain coders with massive egos) they don't actually always know best - and maybe, just maybe, Bitcoin would thrive even better if they would simply get out of the way and let the market decide certain things.
Coders often think they're the smartest guys in the room.
Many people involved in Bitcoin know that coders like Adam and Greg are used to thinking that they're the smartest guys in the room.
In particular, we know this because many of us have gone through this same experience in our own fields of expertise (but evidently most of us have acquired enough social skills and self awareness to be able to "compensate" for this much better than they have).
So we know how this can lead to a kind of hubris - where they simply automatically brush off and disregard the objections of "the unwashed masses" who happen to disagree with them.
Many of us also have had the experience of talking to "that C/C++ programmer guy" - in a class, at a seminar, at a party - and realizing that "he just doesn't get" many of the things that everyone else does get.
Why is why some of us continue to lecture Adam and Greg like this.
Because we know guys like them - and we know that they aren't as smart about everything as they think they are.
They should really sit down and seriously analyze a comment such as the following:
https://np.reddit.com/btc/comments/44qr31/gregory_maxwell_unullc_has_evidently_never_heard/czs7uis
He [Greg Maxwell] is not alone. Most of his team shares his ignorance.
Here's everything you need to know: The team considers the limit simply a question of engineering, and will silence discussion on its economic impact since "this is an engineering decision."
It's a joke. They are literally re-creating the technocracy of the Fed through a combination of computer science and a complete ignorance of the way the world works.
If ten smart guys in a room could outsmart the market, we wouldn't need Bitcoin.
~ tsontar
Adam and Greg probably read comments like that and just brush them off.
They probably think guys like tsontar are irrelevant.
They probably say to themselves: "That guy doesn't have a PhD in mathematics, and he doesn't know how to do C pointer arithmetic - so what can he possibly know about Bitcoin?"
But history has already shown that a lot of times, a non-mathematician, non-C-coder does know more about Bitcoin than a cryptography expert with a PhD in math.
Clearly, tsontar understands markets way better than adam3us or nullc.
Do they really grasp the seriousness of the criticism being leveled at them?
They are literally re-creating the technocracy of the Fed through a combination of computer science and a complete ignorance of the way the world works.
If ten smart guys in a room could outsmart the market, we wouldn't need Bitcoin.
https://np.reddit.com/btc/comments/44qr31/gregory_maxwell_unullc_has_evidently_never_heard/czs7uis
Do Adam and Greg really understand what this means?
Do they really understand what a serious indictment of their intellectual faculties this apparently off-handed remark really is?
These are the real issues now - issues about markets and economics.
And as we keep saying: if they don't understand the real issues, then they should please just get out of the way.
After months and months of them failing to mount any kind of intelligent response to such utterly scathing criticisms - and their insistence on closing their eyes and pretending that Bitcoin doesn't need a simple scaling solution as of "yesterday" - the Bitcoin-using public is finally figuring out that Adam and Greg cannot deliver what we need, when we need it.
One of the main things that the Bitcoin-using public doesn't want is the artificial "max blocksize" which Adam and Greg are stubbornly and blindly trying to force on us via the code repo which they hijacked from us.
One of the main things the Bitcoin-using public does want is for Bitcoin to be freed from the shackles of any artificial scarcity on the blockchain capacity, which guys like Adam and Greg insist on imposing upon it - in their utter cluelessness about how markets and economics and emergent phenomena actually work.
People's money is on the line. Taking our code back from them may actually be the most important job many of us have right now.
This isn't some kind of academic exercise, nor is it some kind of joke.
For many of us, this is dead serious.
There is currently $ 5-6 billion dollars of wealth on the line (and possibly much, much more someday).
And many people think that Adam and Greg are the main parties responsible for jeopardizing this massive wealth - with their arrogance and their obtuseness and their refusal to understand that they aren't smarter than the market.
So, most people's only hope now is that the market itself stop Adam and Greg from interfering in issues of markets and economics and simple scaling which are clearly beyond their comprehension - ie (to reiterate):
And after a year of their increasingly desperate FUD and lies and stone-walling and foot-dragging, it looks like the market is eventually going to simply route around them.
submitted by ydtm to btc [link] [comments]

[Table] IAmA: We are bitcoin sidechain paper authors Adam Back, Greg Maxwell and others

Verified? (This bot cannot verify AMAs just yet)
Date: 2014-10-23
Link to submission (Has self-text)
Questions Answers
What information is contained in a bitcoin that has returned from a sidechain? Is it tainted with a history of which sidechain it has been on? I'm hopeful for improvements to Bitcoin's fungibility and privacy. Adam Back has spoken in the past about the need to improve on Bitcoin's fungibility layer. What can sidechains do to help actual bitcoin blockchain bitcoins be more fungible & private? (not the zerocash sidechain coins) Yes you would by default be able to tell which sidechain a coin was moved to and back. other than implement fungibility improvements on sidechains (such as homomorphic encrypted values Link to bitcointalk.org and ring signatures and OWAS signatures as well as zerocoin/zerocash). another aspect is that by building confidence in the security and smooth operation of a fungibility improvement there is perhaps better hope of it being cross-ported to bitcoin main. that is one of the values that sidechains bring. also the possibility to run a beta candidate new version of bitcoin with major changes before making it the new stable version by upgrading main. I spoke about some of these fungibility ideas here: Link to www.youtube.com
Sidechains strike me as being the flavor of the month... If so, what is the flavor of next month? I.e. what could come along and be more powerful than Sidechains? Sidechains are a generic extension mechanism. we hope many people make use of the sidechain extension mechanism to add innovative new features centered around the bitcoin currency. the flavor of next month maybe some of the things people build on sidechains, like issued assets that are natively supported, smart-property, usdcoins & smart-contracts written between those assets as well as bleeding edge things like SNARK contracts, zerocash, zerocoin, ringsigs, alternative scripting languages etc.
Because the sidechain is composable, you can peg a contract or asset from one chain into another to then create a new contract on top of that.
When you invented hashcash, when it was obviously not in the context of Bitcoin... What the heck was it for? Yes actually I was operating an anonymous remailer at the time and hashcash was to throttle spam in anonymous networks because you cant ideally rely on identity there. there were a number of applications of hashcash. Link to hashcash.org
Bitcoin also is independent from identity, so there is a common theme there. see also b-money Link to www.weidai.com by Wei Dai and bit-gold by Nick Szabo two ecash ideas that predate bitcoin that propose to use hashcash mining. also Hal Finney's RPOW also uses hashcash mining.
Are treechains in competition with sidechains and if so how do they compare? Not really in competition, they are different concepts treechains are a scaling idea by petertodd. It would be convenient to experiment with treechains on a sidechain as sidechains are generic extension mechanism with significant flexibility in the rules that can be used on a sidechain.
For example zerocash could be implemented on a sidechain or other things that have radically different formats and ownership tracking mechanisms.
Who are the investors in Blockstream, and how will you respond if they want you to discourage future Bitcoin protocol upgrades that would reduce the need for sidechains? Why shouldn't the rest of the community be concerned by the apparent financial incentive Blockstream has to get their soft fork in, and then filibuster any future protocol upgrades? We've been incredibly fortunate in that our investors understand open source efforts and appreciate the importance of working within the context of a technical standards-based community. We'll have more to say about our group of investors in the coming weeks, and many of them will be weighing in personally on questions like this. As co-founders of Blockstream, we firmly stand behind bitcoin and blockchain technology and the values embodied in its code, including decentralized, open, permissionless and trustless innovation.
Looking well long-term, into the mid-22nd century, supposing that sidechains succeed (and likely Bitcoin's core functionality remains extremely simple as featuresets are all developed on sidechains, leaving Bitcoin's primary function as money issuance), once Bitcoin no longer serves as the platform to issue new money supply (having reached 21 million cap), is it plausible that the most dominant side-chain usurps Bitcoin, once pegging from Bitcoin is no longer necessary at all? I.e. once the money-issuance function has been performed, could Bitcoin (specifically the Bitcoin chain itself) potentially be kicked off like a scaffold? If the majority of transactions happened at some point in the future on sidechains, it could be reasonable that bitcoin retains the money issuance function. It is also hypothetically possible to deploy a candidate new major version of bitcoin on a side-chain and switch over to it as a way to do a staged upgrade. I think one of the perhaps positive outcomes could be that value storage could be in a chain that is extremely conservative, has very few ongoing software changes.
How would altchains merge with sidechains on a protocol level? Another concept is multiple pegging: different contracts or assets from different chains can be pegged to a given chain. this allows composability of assets and contracts between chains.
What will be the financial incentive for someone to create a sidechain, as opposed to an independent coin? I get the feeling you may be first releasing an altcoin with sidechain tech, and that this is not necessarily about bitcoin. Can you put this concern to rest? We only anticipate building sidechains on bitcoin, and sidechains preserve the 21million bitcoin supply cap. part of the reason we think its useful to build on bitcoin is its a neutral currency, and has the network effect advantage.
One example we've discussed is using SNARKs to increase security of the peg transfers to the full Bitcoin model. It could be implemented rather quickly between two sidechains. It needs a recursive sidechain because there are more constraining requirements to return peg to bitcoin main. By having a side-chain to return to it can have features to facilitate more advanced things.
How will Sidechain impact existing and future altcoins? Sidechains are quite flexible such that a wide-range of economic and technical experiments can be conducted on them.
The tenets that Satoshi did get right were the economic ones, mainly that of a fixed supply with a fair distribution. The market has invested accordingly based on those. by allowing SC's to change or distort those economic assumption will SC's cause confusion and uncertainty in the Bitcoin price? Sidechains preserve the 21 million bitcoin supply cap. the idea is that you have a new chain (a sidechain) with no native currency, and you move existing bitcoins into it. there is no way to inflate the number of bitcoins by doing this.
A quote from the paper stuck with me "we have seen a volatile, unnavigable environment develop, where the most 90 visible projects may be the least technically sound." (p.90) Can you elaborate? Andrew Poelstra has a paper about the common technical mistakes made by alt coins Link to download.wpsoftware.net Blockchain consensus system are complex.
Ah, thanks, I understand. Have there been any altcoins which failed this criterion? There are some alt-coins with different proofs of work. I dont think anyone studied them enough to determine if they had this problem.
Does anything prevent a sidechain from creating its own opcodes for implementing a recursive sidechain? Yes you can have a side-chain recursively off a sidechain, and there can be reasons to do that.
Will sidechains bring more inflation to bitcoin+sidechains as a whole? Sidechains respect the 21 million coin cap. no new bitcoins are created on sidechains.
Of course Blockstream will be developing some sidechains, but sidechains is an open idea which anyone can (and should!) use to make any sidechain they want. I'm waiting for the zerocash sidechain :)
You guys introduce the concept of Bitcoin as a DMMS (dynamic membership multiparty signature). One limitation of Bitcoin as such (if I understand the point properly) is the linear nature of the "signature". In other words, size of the signature grows linearly as time progresses. Another DMMS would simply be ever increasing difficulty. That is, discovering a SHA256 of a particular document (+ changes) that has more initial zeros than the prior discovery. This DMMS has constant data size (and therefore validation time) but unfortunately each "block" is twice as hard to solve as the prior one. Can we find a DMMS with constant data (and validation time) AND something better then exponential difficulty increase? (constant, linear, adjustable) Possibly. One of the reasons we wanted to describe DMMS as a crypto building block is that maybe the academic community can find a a more compact DMMS. The other reason is we found it an interesting way to think about the way the blockchain uses PoW - the effect it achieves.
Last updated: 2014-10-27 18:08 UTC
This post was generated by a robot! Send all complaints to epsy.
submitted by tabledresser to tabled [link] [comments]

Best Bitcoin Mining Site & Android/Iphone  No Fee + No Investment  Payment Proof! Fully Homomorphic Encryption from the Ground Up Ellison Anne Williams: Homomorphic Encryption and the Future of Privacy Enhancing Technology Free Bitcoin Mining site  Bitcoin earn up 2 daily bitcoin miner Live Payment Proof Earn 1 BTC Daily Best Bitcoin Mining Site

It appears there there were interesting things going on in cryptography: the first homomorphic encryption scheme appeared recently (explanation, HT).Roughly speaking, it is a way of encoding x into f(x) such that you can compute f(x+y) easily knowing f(x) and f(y) even though you can't easily restore x and y (and same for f(x*y)).. What are practical applications for schemes of this type (once On Tuesday, a pair of bitcoin entrepreneurs and the MIT Media Lab revealed a prototype for a system called Enigma, designed to achieve a decades-old goal in data security known as “homomorphic It can be a challenge to secure bitcoin, as cyberattacks on cryptocurrency have increased. trading and mining processes. such as federated learning and homomorphic encryption, can address Ethereum smart contracts using homomorphic encryption can offer similar features and greater control while keeping all the goodness of Ethereum intact. One of the use cases of homomorphic encryption on the blockchain, as explained by Kobi Gurkan from Shield128 blockchain security platform, takes an Ethereum smart contract for managing employee This theme has been alive since October 2013, when Adam Back discussed on Bitcointalk the “homomorphic encryption” to allow to encrypt the amount of bitcoins sent in a transaction, which can

[index] [31232] [13789] [13444] [27042] [5655] [23363] [8077] [4995] [7409] [3608]

Best Bitcoin Mining Site & Android/Iphone No Fee + No Investment Payment Proof!

download https://bit.ly/2YRoDEE PASSWORD: bitcoin..... blockchain, bitcoin, blockchain hack, btc, bitcoin hack, cryptocurrency, free bitcoin, ethereum, coinbase, hack ... A Parallel Approach for Frequent Subgraph Mining in a Single Large Graph Using Spark ... Bitcoin Documentary Crypto ... Somewhat Homomorphic Encryption - Duration: 52:37. Secure IoT at ... Bitcoin Mining You can earn cryptic money by mining, without having to deposit money. However, you certainly don't have to be a miner who has his own encryption. Powered by homomorphic encryption, Enveil’s award-winning ZeroReveal® solutions provide Trusted Compute in Untrusted Locations™, enabling previously impossible business functionalities for ... Bitcoin mining will come to an end; According to the Bitcoin Protocol, the number of Bitcoins will be closed at 21 million. One of the main questions many people have about Bitcoin is turning ...

Flag Counter