open source | Bitcoin Links

Primecoin

Primecoin is an innovative cryptocurrency, a form of digital currency secured by cryptography and issued through a decentralized mining market. Derived from Satoshi Nakamoto's Bitcoin, Primecoin introduces an unique form of proof-of-work based on searching for prime numbers.
[link]

Primecoin

Discussion about Primecoin and its infra. Primecoin is a very innovative cryptocurrency, being the 1st non Hash-Cash PoW crypto, naturally scarce (not artificially), with very fast confirmations (1min), elastic readjusting reward & a useful mining (byproducts are primes). Primecoin is sustainable (miners are guaranteed to have revenues), and decentralized (ASIC/FPGA are not particularly advantaged). Sidechain for decentralized data applications (e.g. Storj) currently in development.
[link]

TERA CRYPTO CURRENCY PROJECT

TERA is an open source and collaborative project. It means everyone can view and eventually modify its source code for hehis own needs. And it also means anyone is welcome to integrate its working community. The Tera community works to develop, deploy and maintain Tera nodes and decentralized applications that are part of the TERA Network.
The TERA technology serves the cryptocurrency concepts, trying to design a modern coins and contracts blockchain application : fast block generation, high transaction throughput and user-friendly application. It was officialy launched on 30th of June 2018 on the bitcointalk forum.
[Yuriy Ivanov](mailto:[email protected]) is the founder and core developer of the project. The Tera community is more familiar with the alias « vtools ».

USER FRIENDLY APPLICATION

In the aim to make this crypto currency project more friendly to end-users, some interesting innovations have been implemented in regards to the first generation of crpyto currency applications. The bitcoin and its thousands of child or fork, required a good level of IT skills in order to manage all the application chain from its own : from miners and its hardware, through stratum servers, proxies, to blockchain nodes. The Tera project intend to go one step further regarding crypto currency features integration into a single application : once installed, an efficient web application is available on localhost on port 8080. Then, any web browser supporting javascript may be able to access this application and to operate fully the Tera node.

MINING A CRYPTO CURRENCY

MINING CONCEPT

The mining activity consist in calling a mathematical procedure we can’t predict the result before we run it. But we intend to obtain a very specific result, which usually consist in a certain number of 0 as the first chars before any random answer. If we found the nonce (a random object) combined with the transaction data and the coin algorithm that produce such result, we’ll have solve a transaction block and we’ll get a reward for that. Thanks to this work, the transaction listed in the block will be added to the blockchain and anyone will be able to check our work. That’s the concept of ‘proof of work’ allowing anyone to replay the mathematical procedure with the nonce discovered by the node that solved the block and to confirm block inclusion into the blockchain.

POLITICAL AND ETHICAL CONSIDERATIONS

The Tera project is young. It will have to face the same problems is facing today the Bitcoin platform :
Any Crypto Currency Project with the goal its money and contracts to be used as any other historical money or service contract has to consider its political and ethical usage. Processes have to be imagined, designed and implemented in order to be able to fight against extortion, corruption and illegal activities threating crypto-currency development.

FAST BLOCK GENERATION AND HIGH THROUGHPUT

CLASSIC CRYPTO CURRENCY FEATURES

wallet, accounts, payments, mining, node settings and utilities, blockchain explorer and utilities…

DECENTRALIZED APP CATALOGUE

d-app : forum, stock exchange, payment plugins for third party platform, …

TECHNOLOGY DEPENDENCIES

Tera is entirely written in Java) over the NodeJS library as functional layer in order to take advantages of a robust and high level library designed to allow large and effective network node management.
The miner part is imported from an external repository and is written in C in order to get the best performances for this module.
Tera is actually officially supported on Linux and Windows.
If you start mining Tera thanks to this article, you can add my account 188131 as advisor to yours. On simple demand I’ll refund you half of the extra coins generated for advisors when you’ll solve blocks (@freddy#8516 on discord).

MINING TERA

Mining Tera has one major design constraint : you need one public IP per Tera node or miner. Yet, you can easily mine it on a computer desktop at home. The mining algorithm has been designed in order to be GPU resistant. In order to mine Tera coin you’ll need a multi-core processor (2 minimum) and some RAM, between 1 and 4GB per process that will mine. The mining reward level depends of the « power » used to solve a block (Top Tera Miners).

COST AND USAGE CONSIDERATIONS

There is two main cost centers in order to mine a crypto currency :
  1. the cost of the hardware and the energy required to make a huge amount of mathematical operations connected to the blockchain network through the Internet,
  2. the human cost in order to deploy, maintain and keep running miners and blockchain nodes.
As the speculation actually drives the value of crypto currencies, it is not possible to answer if the mining activity is profitable or not. Moreover, hardware, energy and human costs are not the same around the globe. To appreciate if mining a crypto currency is profitable we should take all indirect costs : nature cost (for hardware and energy production), human cost (coins and contracts usage, social rights of blockchain workers).

Original: https://freddy.linuxtribe.frecherche-et-developpement/blockchain-cryptocurrency-mining/tera-crypto-currency-project/
Author: Freddy Frouin, [email protected].
submitted by Terafoundation to u/Terafoundation [link] [comments]

Could Satoshi Nakamoto be Mike Hearn?

Could Satoshi Nakamoto be Mike Hearn?

There are many coincidences involving a Mike Hearn and Satoshi Nakamoto connection. Some of you will automatically reject the notion because you dislike Mike Hearn, although here on /btc I figured you may at least entertain the idea since he isn't as hated here. I have seen Mike Hearn on the long list of “Satoshi candidates” posted on bitcointalk but I have never seen anyone explore the idea.
Besides Mike being British and Satoshi using British English my first inclination to even consider Mike Hearn as being Satoshi Nakamoto was that Mike’s bitcointalk.org profile was created 1 day after Satoshi last logged in to the forum.
Satoshi’s profile: https://bitcointalk.org/index.php?action=profile;u=3 Mike’s profile: https://bitcointalk.org/index.php?action=profile;u=2700
Mike’s bitcointalk presence began 1 day 53 minutes and 13 seconds after Satoshi’s bitcointalk presence ended. Almost exactly 1 day separating their profiles seemed odd to me especially considering the impact Mike had in development later on.
Why would Satoshi Nakamoto hide his real identity?
The people who created the precursors to Bitcoin were not anonymous. Satoshi even referenced multiple influences by name in his whitepaper like Wei Dai, Ralph Merkle, and Adam Back. So why did the person behind Satoshi feel the need to remain anonymous? There doesn’t seem to be any precedent in the small niche of people who attempted to make digital/electronic cash. A lot of people are constantly regurgitating the idea that Satoshi knew how big Bitcoin would become and that Governments or nefarious people would want to hunt him down for his bitcoin holdings or for simply inventing bitcoin. In reality, Satoshi didn’t even know if his invention would gain traction. Satoshi didn’t know he would be one of a handful of users running bitcoin in the first year which would allow him to mine as many blocks as he did. Satoshi didn’t know how much bitcoin would actually be worth.
So I think the better question is why would Mike Hearn hide is identity?
Mike Hearn in mid August 2006 was hired on by Google as a Site Reliability Engineer (http://web.archive.org/web/20090514053312/http://mikehearn.wordpress.com:80/2006/08/)
Why would an employee of Google secretly develop something? Well, Google themselves sum it up pretty nicely here:
As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.
(https://opensource.google.com/docs/iarc/ )
Here Mike was indeed fully aware of Google’s policy when he released bitcoinj as a Google copyrighted project under the Apache 2 license: https://bitcointalk.org/index.php?topic=4236.msg61438#msg61438 https://bitcointalk.org/index.php?topic=4236.msg61658#msg61658
Then here he is emailing Satoshi (himself Wink) a few hours after the bitcointalk announcement: Quote:
From: Mike Hearn [email protected] Date: Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto [email protected] Hi Satoshi, I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: ….
https://pastebin.com/JF3USKFT
I have no idea how long it takes Google to vet an employee project and license it, but combine that with building bitcoinj and doing that all under 3 months seems fast. What do I know, maybe bitcoinj was a pretty simple project.
I wonder what Google would have done with Bitcoin had Satoshi been an employee of Google?
A silly little find was Mike claiming he supposedly “coined the term SPV”. Or, did he? Here is Peter Todd https://twitter.com/petertoddbtc/status/649413412158599168 and here is the reddit thread to go along with it: https://www.reddit.com/Bitcoin/comments/3n1ydp/peter_todd_on_twitter_mike_hearn_claiming_he/
The term “SPV” does not appear in the whitepaper but its meaning does. Simplified Payment Verification is section 8 of the whitepaper. Did Mike slip and just inadvertently hint to him being the real Satoshi? Upon further investigation Mike had claimed months earlier that he coined the term “SPV wallet”. https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e So he could have meant to say SPV wallet when Peter Todd was calling him out or maybe he did mean to say just “SPV”. Still not the smoking gun but interesting that he would throw that around knowing full well that Simplified Payment Verification was in the Whitepaper.
[After writing this up, Mike just released all his private Satoshi Emails through a user named CipherionX. Mike did show up in a reddit thread to confirm that they came from him and are indeed not fake. Bitcointalk link: https://bitcointalk.org/index.php?topic=2080206.0 Reddit link to Mike’s post: https://www.reddit.com/btc/comments/6t2ci2/never_before_seen_mike_hearn_satoshi_nakamoto/dliizv6/ ] It is very plausible that in order to remain separate from something, that someone would in fact have email conversations between himself and an alias as “proof” that they are completely different independent people. Of course this would only make sense if the emails were made public at some point. Well guess what? Mike just made them public and Mike also attempted to divulge them to Charles Hoskinson in 2013 who did not release them to the public.
If the dates can be trusted, Mike’s email leak serves as proof that he was there early on even if he was corresponding with himself Wink Besides the new email dump the only known public involvement that I could find was here on the sourceforge forum in October 2009: https://sourceforge.net/p/bitcoin/mailman/bitcoin-list/thread/f4cd80640910240804m64ba45f1g216905fc9db16a2%40mail.gmail.com/#msg23827020 .
Why did Mike not use Sourceforge as he posted openly so frequently in other project lists or forums? Are there posts that I haven’t seen from early on?
Mike did produce an email he sent to Satoshi In April of 2009 here in this thread: https://bitcoinfoundation.org/forum/index.php?/topic/54-my-first-message-to-satoshi/ which does correspond with the new email dump. An interesting thing I noticed in the above link is that Mike stated, Quote
Fun. Here's mine, 12th April 2009. Back then the only documentation was the white paper and hardly anyone had explored the code, so a lot of my questions were very newbie-ish. Also I capitalized Bitcoin wrong.
But Mike continued to capitalize Bitcoin as BitCoin not just in that email but until May 14, 2011. Why is that interesting? Well, every thread and post he responded to that mentioned the word bitcoin didn’t capitalize the “C” ever. It would seem like he was almost doing it on purpose to show what a noob he was to the project. Oh then he of course points out the fact that he was a newbie for capitalizing bitcoin that way. It is odd that he continued to use that spelling without regard to how everyone else was spelling it and then later direct people’s attention to the fact that he use to spell it that way early on.
Also, what is odd about Mike’s involvement early on is that it doesn’t really parallel with his natural online demeanor. He is very vocal and has an involved online presence yet he just really isn’t vocal during the early stages of Bitcoin. Even his personal blog posts came to a halt in early 2009. https://web.archive.org/web/20111130084418/http://mikehearn.wordpress.com:80/ For someone who is generally very active online before Bitcoin and then after Satoshi’s disappearence, I find it peculiar that there is a dead silence period from Mike Hearn while Satoshi existed online. Mike went Facebook silent from July 23, 2007 to March 8, 2011 which also coincides with Satoshi’s existence and pre-release development of Bitcoin. https://www.facebook.com/i.am.the.real.mike?lst=662933243%3A61203304%3A1502324015
The next step in my exploration of this idea was to create a calendar of time periods where Satoshi was silent on the forums. For example, Satoshi was silent on the forum from March 24, 2010 until May 16, 2010. I am guessing this is a period when Satoshi was away from his home travelling or vacationing. I was wanting to then correspond them with known dates when Mike was on vacations or at a conference, but as I stated above MIke wasn’t very public during Satoshi’s presence. If anyone knows of any of the potential Satoshis that were vacationing, hospitalized (Hal?), or travelling during that March to May gap in 2010, it would be a good link to the real Satoshi.
Hal Finney was also involved at the start only to leave and eventually return. He came back a month before Satoshi departed though. Hal was the recipient of bitcoins first transaction and helped Satoshi troubleshoot early problems [Suspicious link removed]j.com/public/resources/documents/finneynakamotoemails.pdf
Their correspondence lead me to believe that Satoshi may have had either a rapport or at the least some familiarity with Hal. I decided to search Mike Hearn and Hal Finney together which turned up a nice find. Here, https://sourceforge.net/p/tboot/mailman/tboot-devel/?style=threaded&viewmonth=200807 Mike and Hal are talking about Trusted Computing back in July 2008, just months before the bitcoin whitepaper surfaced. Unfortunately I don’t quite fully understand Trusted Computing and the reason Mike Hearn was inquiring about a trusted web browser or how it would relate to Bitcoin, Quote
I'd like to launch Firefox in a protected domain and have it usable for surfing the web. My vague, poorly thought out plan was to let the user pick a photo from a library as proof of the trusted path, then show it in a tab at startup. Once you saw the personal photo, you'd know you were interacting with a copy of the browser that'd be safe to use even on a malware-riddled machine.
However, I did also find this thread from Mike Hearn which Hal Finney later resurrected about TC: https://bitcointalk.org/index.php?topic=67508.0 And even more interesting, Hal Finney later wrote in his brief memoir of bitcoin, “Bitcoin and Me”, posted on the bitcointalk forum (https://bitcointalk.org/index.php?topic=155054.0) that he was currently “working on something Mike Hearn suggested, using the security features of modern processors, designed to support "Trusted Computing", to harden Bitcoin wallets.” Was Mike Hearn originally researching a use for trusted computing in Bitcoin but never implemented it only to later pass it on to Hal FInney as a “suggestion”? Mike on Google+ posted a link to Hal’s TC project when he learned Hal passed away and linked to Hal’s post on BTCtalk (https://plus.google.com/+MikeHearn ; https://bitcointalk.org/index.php?topic=154290.0 )
So,
here is Satoshi stating he started working on bitcoin in 2007 https://bitcointalk.org/index.php?topic=195.msg1617#msg1617, here Satoshi said he was done writing Bitcoin by July 2008 because that is when Google protocol buffers was made public”I looked at Google protocol buffers when they were released last year, but I had already written everything by then.” https://pastebin.com/Na5FwkQ4 and then above Mike Hearn in July 2008 is seeking guidance from Hal about trusted computing and then Hal working on trusted computing application on the suggestion of Mike for bitcoin. Ok why? Well bitcoin was already done by July 2008 when Mike was inquiring about TC and Hal was working on a TC application later, meaning that TC has some application not related to the core of bitcoin but rather to a peripheral of bitcoin and Mike may have been researching that possibility.
[Super Weak] Searching for more clues about Satoshi I came across a colloquial/slang term that he used. “Hack on” was used by Satoshi in the context of “work on”. https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206 I found multiple instances where Mike Hearn used the same exact term in the same context: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007779.html http://bitcoin-development.narkive.com/hczWIAby/bitcoin-development-cartographer https://web.archive.org/web/20170628004052/http://www.advogato.org/person/mikehearn/ https://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00031.html I do admit the “hack on” argument is lame evidence as it is somewhat common term. However, not everyone used it in that context (like Hal Finney didn’t) and it does add to the list of coincidences.
[Warning: Extreme Reaching] Another super weak semi-coincidence is Mike Hearns birthday. Mike’s birthday is April 17th, 1984. Satoshi’s birthday was chosen as April 5th, 1975. I don’t know about you, but a lot of times when I have to enter a birthday in a service where I don’t want them knowing the truth, I usually always use my real birth month with fake day and year. [More reaching] adding 1975’s digits equal adding 1984’s digits/ 7+5=12 and 8+4=12. I know, I know...
According to Mike Hearn, Satoshi “communicated with a few of the core developers before leaving. He told myself and Gavin that he had moved on to other things and that the project was in good hands.“ https://bitcointalk.org/index.php?topic=145850.msg1558053#msg1558053 This is also backed up by the new email release here: https://pastebin.com/syrmi3ET Mike- “I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?” Satoshi- “I've moved on to other things. It's in good hands with Gavin and everyone.” The above communication is supposedly the first time anyone heard that Satoshi was leaving for good and it was none other than Mike Hearn as the recipient. Then a few days later Satoshi told Gavin the same thing.
None of these things points or alludes to Mike being Satoshi by themselves. But I do think that all these things together do paint a possible connection. Mike denied being Satoshi when I emailed him and also didn’t seem to care that I would post these things online attempting to connect him to Satoshi.
submitted by SkyScraper_Farms to btc [link] [comments]

The Origins of the Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to Bitcoin [link] [comments]

Decentralized applications on TERA platform

Decentralized applications on TERA platform

Implementation of blockchain technologies provided a solution that allows to refuse of use of central servers for storing the database and to entrust them to a distributed registry. For the first time it was implemented through the example of digital currency – Bitcoin. Then enthusiastic programmers, who focused their attention on the opened opportunities, went further. They began to implement their ideas and supply new tools, laying the foundation for the digital system of the future. In such a way, smart contracts and decentralized applications appeared, presented to the user as software products for wide variety of spheres: business, entertainment, communication… Virtual blockchain began to obtain visual outlines.

https://preview.redd.it/utjl7ervb9u21.jpg?width=1080&format=pjpg&auto=webp&s=46f4ce45dbf1a3f3d84be8b027ebf10fb3374c30

Leaders in creation DApps

Ethereum became the first blockchain project that allows the creation of smart contracts and DApps.
But programmers faced difficulty - low transaction speed, which was limited to 20 tps. In 2017, EOS and TRON acted as projects that found a solution. They collected millions with the help of ICO and drove by roadmap.
On the one hand, indeed, the shown speed was significantly different and gave the opportunity to develop DApps (TRON - 1200 tps, EOS - 4000 tps). Although Ethereum took the lead in the number of created in its blockchain applications, taking a head start in two years, the competitors who appeared on the market began to drain-away developers to their platforms. For April 2019 EOS ranks the first in the number of unique users (171k) and transaction volume ($ 3 bln), TRON - the second (71k, 600 mln). This is despite the fact that more DApps allocated in Ethereum. The only thing is that transaction rate both TRON and EOS was obtained detriment of decentralization. Both projects work on the PoS consensus algorithm, and this is already a reason not to consider them decentralized. As for Ethereum, its blockchain with each fork also gradually moves towards the final transition to the PoS consensus. While the main developers justify their actions by that the PoW algorithm has already outlived itself and the distributed registry running on such a consensus cannot provide the characteristics, necessary for full-fledged DApps functionality.
That is not so!

Attractive advantage of TERA

In 2018 the TERA Foundation blockchain project was launched, which proved that it is too early to throw PoW into the past, if only because it copes brilliantly with security issues.
The author of TERA Yuri Ivanov by combining the sha3 and secp256k1 encryption algorithms in cryptography achieved excellent results, guaranteeing 1,000 transactions per second. And the architecture features of the TERA blockchain have higher capabilities - 5,000 tps. Moreover, this speed is not the limit, but without a network load test it’s early to talk about other numbers for the moment.
Anyway, we already see that currently provided speed allow the creators of DApps to embody their ideas. Language of smart contracts JavaScript facilitates the challenge. Some developers together with the creator of TERA did not waste time and for a relatively short time period of the platform’s existence placed into its space a number of really decentralized applications, that are now available to all wallet owners.

What DApps are on the TERA platform

So, what is currently available for use to members of the TERA community?

https://preview.redd.it/bf7o1dk6c9u21.jpg?width=1080&format=pjpg&auto=webp&s=3df9247705396f59b08155462029f65c5a1303b0
TERA decentralized exchange and a multi-currency wallet
The first decentralized platform for the cryptocurrency exchange is already in operation.
To be honest, for the present is only in one, but the most important direction - TERA / BTC.
Meaning that those who wish to purchase a coin can use the sellers' offers, placed on the platform, without turning to other exchanges where TERA has already passed listing.

https://preview.redd.it/69nclntcc9u21.jpg?width=1080&format=pjpg&auto=webp&s=354b5175186e5e684146cde489a02db0824a823f
Upon that, thanks to the latest update you can create a BTC account that will be bound to the main one. For sure increasing the number of cryptocurrencies for both trade and storage will increase the attractiveness. However, this is just a question of time and monitoring with what time intervals updates are released there is a confidence that it will not take long to wait. Moreover, to the topic of wallets and coins it pays to add that TERA allows you to issue your own tokens.

Services for business
Special attention is given to decentralized applications that help to conduct business activities and other dealings. For example, DApp "Promise" is available. By activating a smart contract the seller fixes his obligations with a bounded frozen account without money. The buyer studies the conditions and if they are suitable for him, he transfers the specified amount. Then goods are forwarded, or services are being provided. When deal is fulfilled, the buyer defrosts the seller’s account with the payment received. In case of refusal, the case is regarded by the escrow - the creator of the smart contract.

https://preview.redd.it/y8mp33tkc9u21.jpg?width=819&format=pjpg&auto=webp&s=28e7479c77264658a07ec5768d351cc7f4f8ddc9
There is a DApp "Frozen", where you can freeze funds on your own account until the specified date or until a specific block is generated.
A great way to avoid money wasting and to hodl some coins for a desired period.
Other applications are in the planning stage, that will facilitate business processes conducting on the blockchain directly between the parties, without intermediaries.

Gambling
Gambling admirers comprise a third of decentralized applications users. Therefore, among the DApps hosted on the TERA blockchain, entertainment from this area began to appear. There are a double bet game, a lottery and a one-armed bandit (slot machine). The slot machine evokes associations with the very first mechanical gambling machine of 1905.
It also has 3 drums and one pay line. But the functionality allows you to win the bonus round with 5 free spins and increased prize payout. Yet truth be told, you should be careful.
Personally, I’ve got the combination giving the jackpot x 200 bets, but as I later noticed the winning did not arrive in the account. Therefore, record the evidence of such things just to be on the safe side.

https://preview.redd.it/whioug4qc9u21.jpg?width=467&format=pjpg&auto=webp&s=b3f571ea0512678817bb7d31059fffcd816729a7
By the way, after the post about these errors in Discord (https://discordapp.com/invite/CvwrbeG), the reply followed immediately. The reason was that for the convenience of the player the slot does not wait for 8 seconds, which are necessary for the blockchain to confirm the block, but returns results earlier. But if there is a case of a lost block, an error occurs, where diamonds symbols are shown on the drum.
It was reported about the immediate update of the client version with the corrected drawbacks of previous one.

Online shop
The platform operates an online shop with toys on the game Minecraft subject. For TERA coins you can get soft toys, souvenirs and other goods with the next day delivery in Moscow and within 5 days to other cities of the Russian Federation.
But it will be no difficulty for other salesmen to join and offer their product range. Creating an online store does not require much time, cost or special efforts. It will take several minutes between the decision to open the goods sales point on a decentralized TERA platform and fully realized project. It is enough to load feed with an assortment and prices. Moreover, all data is stored on the blockchain, which excludes needs for hosting.

https://preview.redd.it/crh2an11d9u21.jpg?width=1000&format=pjpg&auto=webp&s=806c3d73766b9a212c1c3d15ed2d82d3cdb402a5
The buyer studies the product and if finds something interesting for himself, makes an order. A clear interface with a full functional basket is available to fulfill the order.
Payment is commission-free. The seller observes the process through the admin panel, which informs him about the state of affairs and reports the change of good statuses during all stages - from the moment of adding to the basket to delivery to the buyer.
The money paid for the goods is reserved on the buffer account at first and only after the buyer receives his order, the seller receive the amount of money to his account.

Other DApps
The first resources for communication appeared on the decentralized platform. This is a forum and dating chat.
Arcade games started to come in, like Floppy Birds. This game already was able to prove that for a poor little bird it’s so difficult to fly, even in the blockchain space!
Especially when the flight takes place in the neighborhood of a virtual industrial town, where there are more pipes than trees, and they grow right before our eyes (in the truest sense of the word!)

https://preview.redd.it/q071t2h8d9u21.jpg?width=1080&format=pjpg&auto=webp&s=8727324d966753ee57c323bd57ace6c6f07d3c27
Once again, I would like to remark that all this is really decentralized, it works and TERA is waiting for new developers, those who want to distribute and monetize their software products free, and what is more, in the most popular programming language – JavaScript.

What else would be nice to see on TERA

Virtual soil of TERA is just beginning to put out shoots of the first planted digital seeds, and in the blockchain space there is enough space for the flight of imagination when creating DApps. I will give as an example just the first that comes to mind, as well as taken from the statements of members of the TERA community on Discordapp.com.
Thus, would be great to see:
- platform for trading binary options, for a start at least on the same pair of TERA / BTC;
- browser for work with DApps and recommendations for building applications;
- a service for voting on the blockchain would provide transparency into the system of election in any sphere (such a proposal was received at Eurovision-2019, why not create it on TERA);
- author's rights patenting services for works of art, inventions and other intellectual property;
- a full-fledged forum where comments would be saved and could not be deleted (the foundation of such an application has already been laid);
- chess, backgammon, bingo, durak and other classic games;
- more games! Strategies, shooter games, exploration games... Suggest to take a deeper look to the hits of the 80s and 90s. Could be found what to remember and transfer to the decentralized platform TERA;
- fully functional casino with a wide range of entertainment: 3-line and 5-line Slot games, roulette, blackjack, poker, bets and other services of gambling industry;
- and so on and so forth.
If such ideas do not come to developers’ mind, feel free to contact the author of this article and he will share his own in the field of gaming and gambling, and help with their realization with the creative approach!
In the long run, what we need for everyday life? Tools to make money and ways to spend it.
The unique features of TERA blockchain make it possible to place both in it.
Plus they will be independent of any central administration and free of censorship.
To inspire developers for actions, the Chinese TERA community announced a contest with a prize fund of 165,000 coins.

https://preview.redd.it/ksrxovbbd9u21.jpg?width=720&format=pjpg&auto=webp&s=c2f16e877b7dac0cf2b4ef0bb249f98c0c6d0396
Those who are interested in placing their DApps on TERA will be helped by DApp Paper - https://docs.google.com/document/d/10yXAKxaU7YgrQnbdXu_L7WWovUoRtdJwo3tXXaGZGSQ/edit
And a couple of words to the developers: You can choose TRON platform, you can choose EOS or Ethereum. But what are your priorities? All these systems are in the hands of corporate owners, which leads away from decentralization. And those who want to get away from totalitarian control and give the fruits of their creativity complete freedom should consider the TERA platform.
The TERA Foundation website has a page with a special world map. It shows in real time how many full nodes support the blockchain operation- https://terafoundation.org/map.html. To be among the first means to participate in laying the foundation, that is able to withstand a powerful boost to the rapid development of future technologies. If there is no your city on the map, only a few minutes separates you from correcting it. Instructions for node installation will help to join the TERA community and make your contribution right now.
It can be found here: https://sourceforge.net/p/tera/code/ci/mastetree/README.md

https://preview.redd.it/zcq5ijbgd9u21.jpg?width=1246&format=pjpg&auto=webp&s=a3cdd4219a5904a89f5de59413d45d6769b07a54
Participation in the expansion of TERA encourages growth and development of the idea of freedom from central administration, which was stated when Bitcoin was launched.
These are not just fantasies or dreams, there are authoritative representatives of science who consider blockchains to be the basis for the economy of future, which will have no boundaries. And with the help of active participants full decentralization will come much faster. This development has no limits, since it is fueled by the independent striving, own free will and potential that is inherent in each of us.
submitted by evkara to u/evkara [link] [comments]

DECENT MINING SETUP & RESSOURCES SHORTCUT

To all DECENTants,
I would like to encourage you to become a seeder or witness (actually not miner) on DECENT.

SHORT INTRODUCTION ABOUT ME

As a pioneer with Bitcoin I truly believed in the DCT project and it's proposal. The first day of the ICO release I sent all my BTC balance to the DECENT. Not knowing when and what they will deliver. To participate in this great adventure means a lot to me. Another project from my home country I strongly encourage you to get familiar with is Ethereum. I have been an early CPU miner: before Crypto Currency I used to compute for sience projects grid for Clean Water and Cancer Research. If I hadn't bought Rainforest with the Ripple they distributed to all contributors, I'd be a rich man today. :P

DECENT SUPPORT

https://decent.ladesk.com/

DECENT WIKI

https://wiki.decent.ch/doku.php?id=decent:howto#build_decent_from_source

DECENT GITHUB

https://github.com/DECENTfoundation/DECENT-Network

BLOCK EXPLORER

https://explorer.decent.ch/

DECENT DB

https://decent-db.com/

GRAPHENE CLI Wallet Cookbook

https://github.com/bitshares/bitshares-core/wiki/CLI-Wallet-Cookbook

RESSOURCES

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04
http://www.hamvocke.com/blog/a-quick-and-easy-guide-to-tmux/
https://digitizor.com/create-swap-file-ubuntu-linux/

I - SERVER SETUP

A dedicated server with Linux Ubuntu 16.04 LTS is most recommend for 24/7 operation. I suggest you close the root and create a new user with SSH Key, secure the system with a firewall.

1. Create a new user

adduser bob 

2. Elevate him

usermod -aG sudo bob 

3. Generate a new keyset

ssh-keygen 

4- Bind the new keys

ssh-copy-id [email protected]_server_ip 
Copy the keys to your local drive. You'll need them to connect.

5. Change the config file

sudo nano /etc/ssh/sshd_config 
Change Line PasswordAuthentication no

6. Finish with

sudo systemctl reload sshd 

7. Login with your ssh key, user and password

ssh [email protected]_server_ip 

II - PREREQUISITES

1. Grab your tools

sudo apt-get update sudo apt-get install build-essential autotools-dev automake autoconf libtool make cmake checkinstall realpath gcc g++ flex bison doxygen gettext git qt5-default libqt5svg5-dev libreadline-dev libcrypto++-dev libgmp-dev libdb-dev libdb++-dev libssl-dev libncurses5-dev libboost-all-dev libcurl4-openssl-dev python-dev libicu-dev libbz2-dev 

2. Download and build Boost 1.60.0

mkdir -p ~/dev/DECENTfoundation/DECENT-Network-third-party cd ~/dev/DECENTfoundation/DECENT-Network-third-party rm -rf boost_1_60_0* boost-1.60.0* wget https://sourceforge.net/projects/boost/files/boost/1.60.0/boost_1_60_0.tar.gz tar xvf boost_1_60_0.tar.gz mkdir boost-1.60.0_prefix cd boost_1_60_0 export BOOST_ROOT=$(realpath ../boost-1.60.0_prefix) ./bootstrap.sh --prefix=$BOOST_ROOT ./b2 install cd .. rm -rf boost_1_60_0 boost_1_60_0.tar.gz 

III - INSTALLATION

1. Clone the repo

mkdir -p ~/dev/DECENTfoundation cd ~/dev/DECENTfoundation #via ssh $ git clone [email protected]:DECENTfoundation/DECENT-Network.git #via url $ git clone https://github.com/DECENTfoundation/DECENT-Network.git cd DECENT-Network git submodule update --init --recursive 

2. Build and install Decent

mkdir -p ~/dev/DECENTfoundation/DECENT-Network-build cd ~/dev/DECENTfoundation/DECENT-Network-build cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ~/dev/DECENTfoundation/DECENT-Network cmake --build . --target all -- -j -l 3.0 cmake --build . --target install 

IV - USE DECENT

You don't want your server to shut down the process when you lose connection or quit.
I use tmux. Though nohup is sufficient for infrequent access. Use it when you fire up decentd after miner setup.
nohup ./decentd & disown 

1. RUN decentd - On first run decentd will create .decent in the home directory.

~/dev/DECENTfoundation/DECENT-Network-build/artifacts/prefix/bin/decentd 
Always close it via Ctrl+C to save the current state Ctrl+S Freeze Ctrl+Q Resume

2. Get HELP

cd ~/dev/DECENTfoundation/DECENT-Network-build/artifacts/prefix/bin/ ./decentd -h 

3. RUN cli_wallet

~/dev/DECENTfoundation/DECENT-Network-build/artifacts/prefix/bin/cli_wallet 
Close it with Ctrl+D

4. USE cli_wallet

set_password xy unlock xy 

5. IMPORT your account

import_key decentgo_username your_private_key 

6. CREATE 3 sets of keys for your new account

suggest_brain_key 
write them down, don't use the ones below. ;)

1. new owner key

{ "brain_priv_key1": "UNBUSH ROAR CHKALIK STRUE PLATTEN DEMOB COLETIT DECAYER SPERONE SPASMED ANATASE LAGGARD BESPETE AXOID SERAL CHEKI", "wif_priv_key1": "5J4brX9bydADigEtsXZhCZ1YLVXkq8frp4xcKAREQ3Gh3P2DE7e", "pub_key1": "DCT5VNJni7HypYi159qiwazZ1WZUt4p2v7NLQmFCJPDvjBpW2oG8a" } 

2. new active key

{ "brain_priv_key2": "FUSION BLART JAIL FESTAL LAXNESS ROSTEL TITI VANADYL PUG BATATA KAIK ROSETY STUCCO TETE BEMUDDY WUDGE", "wif_priv_key2": "5HvsjRsokHSeeUdRkM88JgLzYJ6vnc2e35CzyZNRnmh1fvm91Jz", "pub_key2": "DCT7G7KeUnMPVKXN2y8M7BnyosLRE3LtSnNp7kbxtYd9xHiBoX6wd" } 

3. new public signing key

{ "brain_priv_key3": "DECESS LABBA PLAN DEHUSK FISTY MOSSER SPURTER SCORIAE INDART UNDYE MASTER STEIGH SAFROLE FLURR THAPSIA JOB", "wif_priv_key3": "5JgMsecySgt2BQsmmEE9QnwAGuudC9fGeZJhreyPatcu2TVY9bs", "pub_key3": "DCT6D7TLeVJmPQWR73XHvEhTVHzTDoG6oTSUyvfGa58nuc5wL96UH" } 

7. CREATE your new account

register_account new_username pub_key1 pub_key2 decentgo_username true 

8. SEND some DCT to your new account

transfer decentgo_username target_username 3.00 DCT "memo" true 

9. IMPORT the new account

import_key new_username wif_priv_key2 

10. Close the Wallet and edit the config.ini inside /root/.decent/data/decentd/

private-key = ["pub_key2","wif_priv_key2"] 

11. Launch again and create your miner

create_miner username "proposal URL" true 

12. Change your signing key to 3rd keypair from suggest_brain_key

update_miner username "proposal URL" public_key3 true 

13. Edit the config.ini again inside /root/.decent/data/decentd/

enable-stale-production = true miner-id = "1.4.X" private-key = ["pub_key3","wif_priv_key3"] 

Your Server is now ready to run a DECENT witness.

Be aware that you should not close your daemon at any time.

V - USEFUL COMMANDS

get_brain_key_info dump_private_keys get_private_key public-key get_account texxi get_miner texxi list_my_accounts list_account_balances texxi set_desired_miner_count username 99 

Now get some support for your miner and join the community!

https://decent-project.slack.com/

You can vote for me and I will gladly return the favor. Please make sure your server runs stable and you're not missing any blocks. Good Luck!

vote_for_miner username texxi true true

All voters will receive early preview access to my first cryptocurrency trading tool to be released in 2018. But remember: Always trade for good and invest in green.

submitted by Texxer to Decentplatform [link] [comments]

Bitcoinj 0.11 released

Mike Hearn posted this on the Bitcoin Developer Mailing List:
I'm pleased to announce the release of bitcoinj 0.11, a library for writing Bitcoin applications that run on the JVM. BitcoinJ is widely used across the Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced contracts research and more.
The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Additionally, this email is signed using DKIM and for the first time, a key that was ID verified by the Swiss government.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph: H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
Notable changes and new features
Smaller improvements
Notable bug fixes
API changes
New documentation
Announcement: https://groups.google.com/forum/?fromgroups#!topic/bitcoinj-announce/3LW0uXhlRZY
Message on Bitcoin Developer Mailing List: http://www.mail-archive.com/[email protected]/msg03873.html
Google Code: https://code.google.com/p/bitcoinj/
GitHub: https://github.com/bitcoinj/bitcoinj
Edit: Added links to articles about BIP39 and BIP70 which were included in the original announcement.
submitted by alsomahler to Bitcoin [link] [comments]

The circuit breaker and Satoshi... or why the one ring was forged and how to destroy it (Part 1)

First, I want to point out that I'm not trying to argue from authority in this post. In fact, I want to try to explore the reasons why Satoshi did what he did when it comes to MAX_BLOCK_SIZE.
Before you read any of my post please read this entire thread. It's only 11 comments, so it shouldn't take too long. I'll wait:
https://bitcointalk.org/index.php?topic=994.0 (THREAD #1)
OK one more thread:
https://bitcointalk.org/index.php?topic=1314.0 (THREAD #2)
Last one, I promise (don't read the whole thread, just first 2 or 3 pages):
https://bitcointalk.org/index.php?topic=1347 (THREAD #3)
Ok these are in chronological order (September 7, 2010; September 29th, 2010; October 3rd, 2010).
When did Satoshi lower the effective blocksize limit from 32 MB to 1 MB by introducing the MAX_BLOCK_SIZE limit? July 15th, 2010 - 2 months prior to those threads.
http://sourceforge.net/p/bitcoin/code/103/
Please note, the commit log only lists this: "disable minimize to tray on Linux because it has too many problems including a CPU peg bug"
Hidden in this commit is something that has caused so much pain and misery, yet it was introduced with no fanfare whatsoever. Why? Theymos explains in prior /bitcoin thread I found while researching this post: https://www.reddit.com/Bitcoin/comments/3giend/citation_needed_satoshis_reason_for_blocksize/ctygzmi
Satoshi never used IRC, and he rarely explained his motivations for anything. In this case, he kept the change secret and told people who discovered it to keep it quiet until it was over with so that controversy or attackers wouldn't cause havok with the ongoing rule change.
Why would someone that was developing open source software be so clandestine? There's only a few reasons that makes sense: Sabotage (unlikely as this was Satoshi's own project) or security1 (very likely). There's been a few other times (that I know of) where devs have kept things quiet until after a fix was published. One example: BIP66 fixed a problem that could have caused a hardfork if deliberately triggered. Sipa did not disclose this bug to the public until after BIP66 enforcement was in place. So why was it so important that Satoshi get this into the code without there being a public debate on it? I would posit for very similar reasons.
I'm going to hold off speculating too much what was in Satoshi's head at the time of this commit. I do think linking to his profile at that time helps give context though: https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=340
The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. **It does not need to trust a node to verify payments, it can still verify them itself.
The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.
At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.
This particular comment was July 14th, 2010 (a day before the MAX_BLOCK_SIZE commit). Interestingly, he also discussed the runaway CPU fix in the next comment (July 16th, 2010).
OK, the undocumented switch "-minimizetotray" which re-enables the option.
I uploaded the change to SVN.
To further complicate things, the "slashdotting" (analogous to the reddit hug-of-death) occurred on July 11th, 2010.
To summarize:
The journey through Mordor... or how to destroy the one ring
I'll hoping to make another post in a few days that will be a little more... expository and speculative.
1 I'd like to make an aside here. To me, transaction spam is a DOS attack on the Bitcoin network even if unsuccessful or unintentional (much like the reddit hug of death). Satoshi spent a lot of time (especially after the slashdotting) trying to plug DOS vectors. In fact, his last public comment was talking about how many DOS vectors still existed. Funny thing is, we aren't finished... SigOps exhaustion and the quadratic verification times for high input transactions still exists. I'm sure there are many more.
Edit: Thanks for gold and the tips.
submitted by throckmortonsign to Bitcoin [link] [comments]

The Origins of the (Modern) Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to sound8bits [link] [comments]

Dash is a planned instamine, it wasn't an accident

The official story about the instamine: https://dashdot.io/alpha/?page_id=118
Evan Duffield:“The instamine happened, there is no one disputing that fact. The crypto-community at large has no problem with this except a few who think it’s trying to be hidden in some way. In fact, I posted multiple times about the instamine, first in “The Birth Of Darkcoin” which is an account of the first few weeks of the launch and the mistakes that were made. Recently I also posted spoke about the Instamine in the video “Virtual Corporation”, which considers the concept that it might have been key to Dash’s success, which I believe now.
It’s also important to note, I was working a very challenging day job while working on Dash in the first couple weeks. So I was putting out fires every night, keeping tabs on Dash during the day (while getting yelled at by my boss when he caught me a couple times). Eventually I quit when I got Dash stable enough to work on full time and decided I really wanted to explore what I could do with it. “
In my opinion, it was a planned instamine. This wasn't mentioned before launch.
The features of this coin were also not public at launch.
=> Nobody was really interested in the coin at launch, making this instamine more a kind of "stealth launched premine". In my books, that's a scam. Please don't ignore the facts:
2013-12-29: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03557.html
2 guys from Hawk Financial Group, Evan & Kyle, are asking on the Bitcoin Dev mailing list for "1 or 2 really good C++ programmer that is familiar with the bitcoin internals to help with a for-profit startup". They are planning to build a unique coin that is "not just a clone of the original Bitcoin code" but in stead "a merge-mined altcoin that will provide a very useful service to the whole crypto-coin ecosystem". They claim to have "detailed plans on how to implement it".
2014-01-18: https://bitcointalk.org/index.php?topic=421615.msg4596809#msg4596809
There were some issues at launch, so Evan said he would postpone the launch and would "definitely not" launch it in the next hours. But he did launch it a few hours later.
2014-01-19: https://chainz.cryptoid.info/dash/block.dws?000007d91d1254d60e2dd1ae580383070a4ddffa4c64c2eeb4a2f9ecc0414343.htm
Xcoin was launched. This was the emission in the first 72 hours of the coins existence: https://i.gyazo.com/fef5818649a839bb091c29e8b3722b7e.png This was the emission of the first 100 days: https://i.gyazo.com/3acc6ea5d90db13e51d95dac0e4b8fa2.png
At the moment, there are about 6 million DASH in circulation. There would be 84 million Xcoins eventually. (https://bitcointalk.org/index.php?topic=421615.msg4588082#msg4588082) Note that in the first hour, 500k Xcoins were mined. Due to the "quick fix" of the bug, not many people expected to launch a few hours after Evan said he would "definitely not" launch in the next hours.
2014-01-19: https://bitcointalk.org/index.php?topic=421615.msg4594074#msg4594074
Right after the launch, there were problems with the window binaries. Evan clearly was mining right from the start, as he offered 5000 Xcoin as a bounty for compiling the binaries.
2014-01-20: https://bitcointalk.org/index.php?topic=421615.msg4629218#msg4629218
After the emission of almost 2 million coins, Evan said that "now that everything is stable, I'll be posting later about the vision of this project and milestones!". Up until this point, only the "X11 hashing algoritm" was a known feature. According to him, it was "time to move on to actually implementing what I set out to do".
2014-01-22: https://bitcointalk.org/index.php?topic=421615.msg4654183#msg4654183
Evan releases his plans for XCoin. At this point, more than 2 million coins were mined.
Xcoin rebranded to Darkcoin and eventually to DASH later on.
Later on, some contradictions surfaced:
Conclusions:
  • Evan isn't acting alone, he had/has a team behind him right from the start. It wasn't a hobby. he had a plan to make a profit.
  • Evan had plans for his coin right from the start, but didn't release them until after the instamine
  • 1.5 million coins were mined in the first 8 hours. Most of these coin ended up in his (and his friends) hands. It's very likely the 500k in the first hour were only mined by him with cloudhosting services.
  • He lowered the emission later on, to make his relative share of coins bigger.
How can this be all an accident (like Evan is always saying) and NOT be intentional? Evan was looking for c++ devs for a "for profit startup" at the end of 2013 for the launch of an altcoin.
Question:
How can you make a profit by launching an altcoin (and be sure to be able to pay your devs)?
Answer:
by premining and/or instamining.
How he did it is pretty easy:
  • telling people the release would definitely not be in the next couple of hours and after that do launch it a few hours later
  • buggy windows binaries
  • a "code error" creating 500k coins in the first hour, >1.5 million in the first 8 hours.
=> DASH was clearly a planned premine/instamine.
submitted by dnale0r to CryptoCurrency [link] [comments]

Could Satoshi Nakamoto be Mike Hearn?

Is Satoshi Nakamoto Mike Hearn?

There are many coincidences involving a Mike Hearn and Satoshi Nakamoto connection. Though many of you will automatically reject the notion because you dislike Mike Hearn, I would suggest you at least entertain the idea’s possibility. I have seen Mike Hearn on the long list of “Satoshi candidates” posted on bitcointalk but I have never seen anyone explore the idea.
Besides Mike being British and Satoshi using British English my first inclination to even consider Mike Hearn as being Satoshi Nakamoto was that Mike’s bitcointalk.org profile was created 1 day after Satoshi last logged in to the forum.
Satoshi’s profile: https://bitcointalk.org/index.php?action=profile;u=3 Mike’s profile: https://bitcointalk.org/index.php?action=profile;u=2700

Mike’s bitcointalk presence began 1 day 53 minutes and 13 seconds after Satoshi’s bitcointalk presence ended. Almost exactly 1 day separating their profiles seemed odd to me especially considering the impact Mike had in development later on.

Why would Satoshi Nakamoto hide his real identity?
The people who created the precursors to Bitcoin were not anonymous. Satoshi even referenced multiple influences by name in his whitepaper like Wei Dai, Ralph Merkle, and Adam Back. So why did the person behind Satoshi feel the need to remain anonymous? There doesn’t seem to be any precedent in the small niche of people who attempted to make digital/electronic cash. A lot of people are constantly regurgitating the idea that Satoshi knew how big Bitcoin would become and that Governments or nefarious people would want to hunt him down for his bitcoin holdings or for simply inventing bitcoin. In reality, Satoshi didn’t even know if his invention would gain traction. Satoshi didn’t know he would be one of a handful of users running bitcoin in the first year which would allow him to mine as many blocks as he did. Satoshi didn’t know how much bitcoin would actually be worth.
So I think the better question is why would Mike Hearn hide is identity?
Mike Hearn in mid August 2006 was hired on by Google as a Site Reliability Engineer (http://web.archive.org/web/20090514053312/http://mikehearn.wordpress.com:80/2006/08/)
Why would an employee of Google secretly develop something? Well, Google themselves sum it up pretty nicely here: “As part of your employment agreement, Google most likely owns intellectual property (IP) you create while at the company. Because Google’s business interests are so wide and varied, this likely applies to any personal project you have. That includes new development on personal projects you created prior to employment at Google.“ (https://opensource.google.com/docs/iarc/ )
Here Mike was indeed fully aware of Google’s policy when he released bitcoinj as a Google copyrighted project under the Apache 2 license: https://bitcointalk.org/index.php?topic=4236.msg61438#msg61438 https://bitcointalk.org/index.php?topic=4236.msg61658#msg61658
Then here he is emailing Satoshi (himself Wink) a few hours after the bitcointalk announcement: Quote From: Mike Hearn [email protected] Date: Mon, Mar 7, 2011 at 2:13 PM To: Satoshi Nakamoto [email protected]
Hi Satoshi,
I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: …. https://pastebin.com/JF3USKFT
I have no idea how long it takes Google to vet an employee project and license it, but combine that with building bitcoinj and doing that all under 3 months seems fast. What do I know, maybe bitcoinj was a pretty simple project.
I wonder what Google would have done with Bitcoin had Satoshi been an employee of Google?

Mike claiming he supposedly “coined the term SPV”. Or, did he? Here is Peter Todd https://twitter.com/petertoddbtc/status/649413412158599168 and here is the reddit thread to go along with it: https://www.reddit.com/Bitcoin/comments/3n1ydp/peter_todd_on_twitter_mike_hearn_claiming_he/
The term “SPV” does not appear in the whitepaper but its meaning does. Simplified Payment Verification is section 8 of the whitepaper. Did Mike slip and just inadvertently hint to him being the real Satoshi? Upon further investigation Mike had claimed months earlier that he coined the term “SPV wallet”. https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e So he could have meant to say SPV wallet when Peter Todd was calling him out or maybe he did mean to say just “SPV”. Still not the smoking gun but interesting that he would throw that around knowing full well that Simplified Payment Verification was in the Whitepaper.
[After writing this up, Mike just released all his private Satoshi Emails through a user named CipherionX. Mike did show up in a reddit thread to confirm that they came from him and are indeed not fake. Bitcointalk link: https://bitcointalk.org/index.php?topic=2080206.0 Reddit link to Mike’s post: https://www.reddit.com/btc/comments/6t2ci2/never_before_seen_mike_hearn_satoshi_nakamoto/dliizv6/ ] It is very plausible that in order to remain separate from something, that someone would in fact have email conversations between himself and an alias as “proof” that they are completely different independent people. Of course this would only make sense if the emails were made public at some point. Well guess what? Mike just made them public and Mike also attempted to divulge them to Charles Hoskinson in 2013 who did not release them to the public.
If the dates can be trusted, Mike’s email leak serves as proof that he was there early on even if he was corresponding with himself Wink Besides the new email dump the only known public involvement that I could find was here on the sourceforge forum in October 2009: https://sourceforge.net/p/bitcoin/mailman/bitcoin-list/thread/f4cd80640910240804m64ba45f1g216905fc9db16a2%40mail.gmail.com/#msg23827020 .
Why did Mike not use Sourceforge as he posted openly so frequently in other project lists or forums? Are there posts that I haven’t seen from early on?
Mike did produce an email he sent to Satoshi In April of 2009 here in this thread: https://bitcoinfoundation.org/forum/index.php?/topic/54-my-first-message-to-satoshi/ which does correspond with the new email dump. An interesting thing I noticed in the above link is that Mike stated, Quote Fun. Here's mine, 12th April 2009. Back then the only documentation was the white paper and hardly anyone had explored the code, so a lot of my questions were very newbie-ish. Also I capitalized Bitcoin wrong.

But Mike continued to capitalize Bitcoin as BitCoin not just in that email but until May 14, 2011. Why is that interesting? Well, every thread and post he responded to that mentioned the word bitcoin didn’t capitalize the “C” ever. It would seem like he was almost doing it on purpose to show what a noob he was to the project. Oh then he of course points out the fact that he was a newbie for capitalizing bitcoin that way. It is odd that he continued to use that spelling without regard to how everyone else was spelling it and then later direct people’s attention to the fact that he use to spell it that way early on.

Also, what is odd about Mike’s involvement early on is that it doesn’t really parallel with his natural online demeanor. He is very vocal and has an involved online presence yet he just really isn’t vocal during the early stages of Bitcoin. Even his personal blog posts came to a halt in early 2009. https://web.archive.org/web/20111130084418/http://mikehearn.wordpress.com:80/ For someone who is generally very active online before Bitcoin and then after Satoshi’s disappearence, I find it peculiar that there is a dead silence period from Mike Hearn while Satoshi existed online. Mike went Facebook silent from July 23, 2007 to March 8, 2011 which also coincides with Satoshi’s existence and pre-release development of Bitcoin. https://www.facebook.com/i.am.the.real.mike?lst=662933243%3A61203304%3A1502324015
The next step in my exploration of this idea was to create a calendar of time periods where Satoshi was silent on the forums. For example, Satoshi was silent on the forum from March 24, 2010 until May 16, 2010. I am guessing this is a period when Satoshi was away from his home travelling or vacationing. I was wanting to then correspond them with known dates when Mike was on vacations or at a conference, but as I stated above MIke wasn’t very public during Satoshi’s presence. If anyone knows of any of the potential Satoshis that were vacationing, hospitalized (Hal?), or travelling during that March to May gap in 2010, it would be a good link to the real Satoshi.

Hal Finney was also involved at the start only to leave and eventually return. He came back a month before Satoshi departed though. Hal was the recipient of bitcoins first transaction and helped Satoshi troubleshoot early problems [Suspicious link removed]j.com/public/resources/documents/finneynakamotoemails.pdf
Their correspondence lead me to believe that Satoshi may have had either a rapport or at the least some familiarity with Hal. I decided to search Mike Hearn and Hal Finney together which turned up a nice find. Here, https://sourceforge.net/p/tboot/mailman/tboot-devel/?style=threaded&viewmonth=200807 Mike and Hal are talking about Trusted Computing back in July 2008, just months before the bitcoin whitepaper surfaced. Unfortunately I don’t quite fully understand Trusted Computing and the reason Mike Hearn was inquiring about a trusted web browser or how it would relate to Bitcoin, Quote - I'd like to launch Firefox in a protected domain and have it usable for surfing the web. My vague, poorly thought out plan was to let the user pick a photo from a library as proof of the trusted path, then show it in a tab at startup. Once you saw the personal photo, you'd know you were interacting with a copy of the browser that'd be safe to use even on a malware-riddled machine. However, I did also find this thread from Mike Hearn that Hal Finney later resurrected about TC: https://bitcointalk.org/index.php?topic=67508.0 And even more interesting, Hal Finney later wrote in his brief memoir of bitcoin, “Bitcoin and Me”, posted on the bitcointalk forum (https://bitcointalk.org/index.php?topic=155054.0) that he was currently “working on something Mike Hearn suggested, using the security features of modern processors, designed to support "Trusted Computing", to harden Bitcoin wallets.” Was Mike Hearn originally researching a use for trusted computing in Bitcoin but never implemented it only to later pass it on to Hal FInney as a “suggestion”? Mike on Google+ posted a link to Hal’s TC project when he learned Hal passed away and linked to Hal’s post on BTCtalk (https://plus.google.com/+MikeHearn ; https://bitcointalk.org/index.php?topic=154290.0 )
So,
here is Satoshi stating he started working on bitcoin in 2007 https://bitcointalk.org/index.php?topic=195.msg1617#msg1617, here Satoshi said he was done writing Bitcoin by July 2008 because that is when Google protocol buffers was made public”I looked at Google protocol buffers when they were released last year, but I had already written everything by then.” https://pastebin.com/Na5FwkQ4

and then above Mike Hearn in July 2008 is seeking guidance from Hal about trusted computing and then Hal working on trusted computing application on the suggestion of Mike for bitcoin. Ok why? Well bitcoin was done by July 2007 when Mike was inquiring about TC and Hal was working on a TC application later, meaning that TC has some application not related to the core of bitcoin but rather to a peripheral of bitcoin.

[Weak] Searching for more clues about Satoshi I came across a colloquial/slang term that he used. “Hack on” was used by Satoshi in the context of “work on”. https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206 I found multiple instances where Mike Hearn used the same exact term in the same context: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007779.html http://bitcoin-development.narkive.com/hczWIAby/bitcoin-development-cartographer https://web.archive.org/web/20170628004052/http://www.advogato.org/person/mikehearn/ https://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00031.html

I do admit the “hack on” argument is lame evidence as it is somewhat common term. However, not everyone used it in that context (like Hal Finney didn’t) and it does add to the list of coincidences.

[Warning: Reaching] Another super weak semi-coincidence is Mike Hearns birthday. Mike’s birthday is April 17th, 1984. Satoshi’s birthday was chosen as April 5th, 1975. I don’t know about you, but a lot of times when I have to enter a birthday in a service where I don’t want them knowing the truth, I usually always use my real birth month with fake day and year. [More reaching] adding 1975’s digits equal adding 1984’s digits/ 7+5=12 and 8+4=12.

According to Mike Hearn, Satoshi “communicated with a few of the core developers before leaving. He told myself and Gavin that he had moved on to other things and that the project was in good hands.“ https://bitcointalk.org/index.php?topic=145850.msg1558053#msg1558053 This is also backed up by the new email release here: https://pastebin.com/syrmi3ET Mike- “I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?” Satoshi- “I've moved on to other things. It's in good hands with Gavin and everyone.” The above communication is supposedly the first time anyone heard that Satoshi was leaving for good and it was none other than Mike Hearn as the recipient. Then a few days later Satoshi told Gavin the same thing.
None of these things points or alludes to Mike being Satoshi by themselves. But I do think that all these things together do paint a possible connection. Mike denied being Satoshi when I emailed him and also didn’t seem to care that I would post these things online attempting to connect him to Satoshi.
submitted by SkyScraper_Farms to MikeHearnIsSatoshi [link] [comments]

Setting up a Block Explorer for your coin How to get 100% FREE UNLIMITED Bitcoin in 2020!  New Easy Working Method What is a Bitcoin Block Explorer #22 Decentralize Data NOW! (Formerly Open Source Block Explorers Now!) #1 Open Source Blockchain Explorer NOW! - March 23, 2018

Checking your Bitcoin address at www.AllPrivateKeys.com for private key leak is safe for you, because this information is available and it cannot perform any problems. And if your private key is secure, we can monitor and notify you about any leaks by email. Our database has more than 2 million rows of potential leake Monitor & auto-restart bitcore node blockstack/blockstack-explorer#27. Closed Copy link Quote reply larrysalibra commented Jan 17, 2017. @michelem09 this Please reply. I am stuck here, whenever i hit bitcore-node start command , it starts bitcoind and sync with bitcoin block chain. SharpSpring is a comprehensive marketing automation platform with robust features, functionality and performance. SharpSpring is one of the most flexible platforms on the market, offering powerful, behavior-based email marketing, native or 3rd party CRM integration, dynamic forms, landing page and blog builders, social media management, universal CMS compatibility, and integration with directly extracted from the Bitcoin blockchain using a block explorer service, The official Bitcoin client is called Bitc oin Core, and it is av ailable from sourceforge.net [22]. Bitcoin Block Explorer is an open source web tool that allows you to view information about the blocks, addresses, and transactions created by Bitcoin. SourceForge and other sources of code and historical data that might be useful to BTC traders for automated trading, backtesting or sentiment analysis.

[index] [25026] [27347] [6299] [22895] [3950] [25022] [8816] [3575] [881] [17305]

Setting up a Block Explorer for your coin

DFINITY Explorer is an open-source block explorer built by the DFINITY community. We recently implemented a dashboard layout following Material Design principles, with both dark and light modes. How Cryptocurrency Transactions Work - Blockchain Explorer Tutorial In today's educational tutorial I will talk about how cryptocurrency transactions work. We will cover Bitcoin, Litecoin, Bitcoin ... Giveth is trying to bring them all together so that we can get an Open Source Blockchain Explorer NOW! Explorer by POA Network ... #3 Open Source Block Explorers NOW! ... The Bitcoin Rabbi 1,421 ... Bitcoin Explained Lab 1: Block Chain Explorer - Duration: 3:42. Emeka aka On1 Productions 2,048 views. 3:42. Multi Machine Hyperledger Fabric/Composer/Explorer (Orgs in separate machines) ... 21 videos Play all Learn Bitcoin with 2 Minute Videos 99Bitcoins Blockchain Basics Explained - Hashes with Mining and Merkle trees - Duration: 3:24. Chainthat 241,667 views

Flag Counter