Download - Bitcoin

Groestlcoin 6th Anniversary Release

Introduction

Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).

Features

Download

Source

Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.

Features

Download

Windows
Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py 

Source

ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-14)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Versionbits

background

BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.

meeting comments

Morcos is volunteering to take over championing this proposal as CodeShark and Rusty are busy on other things. He'll review both implementations and then decide on which implementation he'll base his work upon. He notes that if non-core implementations are trying to do something else (and are using nVersion for their signaling) while segregated witness is being deployed, not conflicting will be important so users of other versions can also support segregated witness. If there's an agreement with this approach it's necessary that versionbits is ready before the segregated witness deployment. jtimon has some suggestions to make the implementation less complicated and more flexible.

meeting conclusion

Morcos will champion the new reference implementation for BIP9: Versionbits.

Status of segregated witness

background

Segregated witness changes the structure of transactions so that the signatures can be separated from the rest of the transactions. This allows for bandwidth savings for relay, pruning of old signatures, softforking all future script changes by introducing script versions and solves all unintentional forms of malleability. During the last scaling bitcoin conference Pieter Wuille presented a way of doing this via a softfork, and proposed increasing the maximum amount of transactions in a block by discounting signature data towards the total blocksize. Segregated witness is part of the capacity increase roadmap for bitcoin-core. More detailed explanations: - By Pieter Wuille at the San Francisco bitcoin developer meetup (more technical) - By Andreas Antonopoulos in the let's talk bitcoin podcast (less technical)

meeting comments

Segnet, the testnet for segregated transactions, will be going to it's 3rd version soon. Luke-Jr has assigned all the segregated witness BIPs to a 14x range. Currently there are 4 BIPs: 141, 142, 143 and 144.

Status of 0.12 bitcoin-core release

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc1 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

Luke-Jr feels PR's #7149, #7339 and #7340 should have been in 0.12, but are now really late and possibly impractical to get in. For gitian builders: 0.12rc1's osx sig attach descriptor fails due to a missing package (that's not actually needed). Rather than using the in-tree descriptor, use the one from #7342. This is fixed for rc2. "fundrawtransaction" and "setban" should be added to the release notes. At some point it makes more sense to document these commands elsewhere and link to it in the release notes, as they've become very lengthy. Wumpus thinks the release notes have too much details, they're not meant to be a substitute for documentation.

meeting conclusion

Close PR #7142 as it's now part of #7148 Everyone is free to improve on the release notes, just submit a PR.

consensus code encapsulation (libconsensus)

background

Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separate, but in bitcoin it's all intertwined. Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. This however is a slow and dangerous project of moving lots of code around.

meeting comments

jtimon has 4 libconsensus related PRs open, namely #7091 #7287 #7311 and #7310 He thinks any "big picture branch" will be highly unreadable without merging something like #7310 first. The longest "big picture branch" he currently has is https://github.com/jtimon/bitcoin/commits/libconsensus-f2 He'll document the plan and "big picture" in stages: 1. have something to call libconsensus: expose verifyScript. (Done) 2. put the rest of the consensus critical code, excluding storage in the same building package (see #7091) 3. discuss a complete C API for libconsensus 4. separate it into a sub-repository Wumpus notes he'd like to start with 3 as soon as possible as an API would be good to guide this.

meeting conclusion

review #7091 #7287 #7311 and #7310

Locktime PRs

background

BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers. BIP 112 CHECKSEQUENCEVERIFY. BIP 113 Median time-past as endpoint for lock-time calculations. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions.

meeting comments

We need to make a choice between 2 implementations, namely #6312 and #7184. PR #7184 is a result of the CreateNewBlock optimisations not being compatible with #6312. jtimon thinks it could be merged relatively soon as #7184 is based on #6312 which has plenty of testing and review.

meeting conclusion

Close #6312 in favor of #7184. Morcos will fix the open nits on #7184 btcdrak will update the BIP-text

Participants

wumpus Wladimir J. van der Laan btcdrak btcdrak morcos Alex Morcos jtimon Jorge Timón Luke-Jr Luke Dashjr MarcoFalke Marco Falke jonasshnelli Jonas Schnelli cfields Cory Fields sipa Pieter Wuille kanzure Bryan Bishop droark Douglas Roark sdaftuar Suhas Daftuar Diablo-D3 Patrick McFarland 

Comic relief

19:54 wumpus #meetingstop 19:54 wumpus #stopmeeting 19:54 btcdrak haha 19:54 MarcoFalke #closemeeting 19:54 wumpus #endmeeting 19:54 lightningbot` Meeting ended Thu Jan 14 19:54:26 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 
submitted by G1lius to Bitcoin [link] [comments]

An open letter to Vitalik re: The DAO

Estimated Reading Time: 14 minutes.
TL;DR; I'm making the case that hard forking the Ethereum block chain to defeat the assault on The DAO's ether treasury isn't just okay to do, it's the responsibility of the platform to protect its interests at the expense of other interests which are hostile to its assets.
All organisms have the right to self defense - digital organisms must assert this right if they expect to survive. Any organism that refuses to defend itself against attack is effectively suicidal and essentially declaring itself as cheaply plundered 'food' from an evolutionary perspective.
At the same time, I'm also asserting that the person or people who attacked The DAO performed a service that has legitimate value. So while it's ethical to limit the damage done, it's also ethical to pay people fair value for services rendered - even if those people rendered those services in a hostile way. Paying them fairly stands a good chance of making them less less hostile, don't you think?
Finally, I suggest some changes to be included in the hard fork to drastically reduce the vulnerability of code running on Ethereum by requiring gas not only to execute code, but to execute test code with sufficient path coverage to reduce execution risk to acceptable levels and requiring bug bounties commensurate with the size and complexity of the code base that's being loaded on to the network.
This change, I assert will naturally lead to an economy of very well tested modularized code with economically capped complexity which it makes sense to share, for a fee commensurate with its 'security rating', to be wired together with other well-tested modules so less capable programmers can build their own drag and drop smart contracts without unintentionally compromising the network.
And by doing the work we should have done in the first place as we redesign The DAO and then write, test, and bounty the code properly, we'll then know about how much it's fair to pay the hacker after the hard fork removes his loot. I suggest that we pay 10x what it would have cost us to do this correctly in the first place - both so we'll all remember it and to say 'thanks' to a capable adversary for waking us up to a potentially lethal problem had we discovered it later.
The "lethal" part comes up in some discussion about protecting ourselves from emergent AI now rather than later on a network where code is intended to be available for execution forever. This TL;DR; is getting TL;DR; though, so please read on if any of that interests you. /TL;DR;
Vitalik,
I have a few ideas for moving forward past this DAO issue. First, I think a hard fork making investors whole and denying the black hat 'tester' from a potentially network threatening payday is not only okay - it's compulsory, especially if it's presented in the right way, both technically and socially. The following is what I think is that 'right way.'
If this is explained honestly as being a fix, happening at a similar point in the evolution of DAO coding methodology to the maturity of the network itself when the bad fork canary and other safety measures were in place, then I think the people who support Ethereum because they share your vision of what it can become are going to understand that.
In fact, I'm confident many of them will admire not only the action taken, but the manner in which it was done.
Let's all own the mistake. Acknowledge it. Accept the fact that we will make other mistakes in the future, but that we're going to do everything we know how to do to make sure we won't repeat this one.
Then explain how we're going to do that, and move on with all of those who can see the honesty and sincerity of that statement and the intent of the actions taken.
No one is perfect. We all make mistakes. But hopefully we learn from them. Deep down, I think most people understand that, even if some of them will still scream "moral hazard" from the rooftops of reddit until the cows come home because they have a tribal psychological attachment to a different technology or cult of personality.
Or for arbitrary reasons: they don't trust Russians, they don't like young people, whatever. Or they may just legitimately not understand that innovation isn't a straight line up and to the right.
You can't reach those people - except for the last group - ignorance isn't shameful and it is very fixable. Apart from them, the others will be against you no matter what you do. Most of those people were already dismissing Ethereum as a scam or an alt-coin anyway.
Sacrificing the safety of the network or the financial and mental health of some overly enthusiastic (or, let's be honest - in some cases, a bit greedy and naive) early supporters in exchange for praise, respect, or support that will never come is a losing move. It costs the people who support Ethereum and/or The DAO dearly, and it results in little or no positive change.
There's no logic to making that move at all. Ethereum needs to do what's good for Ethereum and its supporters - not what it hopes might silence its critics. There will always be more critics. That's a losing strategy.
So hard fork to deny the attacker and restore the duped and self-duped. Full disclosure: that includes me. I knew there was a lot of risk to investing in something like this so I only invested an amount I was fully willing to lose - just for the experience of participating and being motivated to learn how it works.
Though obviously somebody was much more motivated than me - more motivated than all of us. And that's good - we need people like that. But we need to negotiate a fair exchange for their services in testing our code, not neglect security and therefore allow them to dictate the terms.
A dangerous animal can be your best friend, if you understand how to negotiate a compromise between its needs and yours successfully. I know this from experience - I have a very friendly pit bull. Neglect its needs - a well funded code bounty program, in this case, and you're going to get bit. A lot.
I don't want to have to read the damn DAO code. I want a hacking pit bull to do it for me, in fact, I'd prefer a pack of the baddest and meanest ones there are. I just don't want to get ripped off on the exchange of value.
Because there is legitimate value in what this hacker did. We are going to learn to do things in a much smarter way in response to it, because this community and this network are resilient and anti-fragile, respectively. We just over paid for the service.
But I recognize that other people did invest more than they were prepared to lose in this very complicated experiment. Some people who support your vision are going through a lot of very real pain right now, and so if we can stop that at a reasonable cost, then how can we not? Especially if it's strategically the right thing to do.
If there's one guiding principle I'm pretty confident when following - it's harm reduction. "Harm to whom?," I can hear some asking. Harm to the supporters of Ethereum and The DAO. The hacker invited a defensive response when he attacked the DAO, and it was an assault by any fair definition of the term, as I'll explain below.
The organism protects itself first, or it dies. This is digital evolution and the stakes are existential.
Some speculators and ideologues will move on. Those who 'get it' will still be here. And that's the support you really need to continue developing this platform and ecosystem - the support of those who aren't going to run away when we encounter problems. Because we will. And then we'll fucking fix them.
Because that's what invention is. It's messy. It's a process, not a moment in time. It's not like the movies. There is no single, all encompassing "Ah ha!" moment. You get little "ah ha's...' as you go. Mixed in with a bunch of "aw, shit!" moments as well. That's just how it goes.
Literally, the symbol for the "Ah ha!" moment is a cultural distortion. There were a lot of failed experiments between Edison's own "Ah ha!" moment and the moment he saw a stable and working light bulb.
Expecting people to invent a whole new world out of thin air - or out of the ether, as the case may be - based on very different principles from those of the failing systems that have created the circumstances from which it has a chance to emerge - well, that's complicated stuff.
Finding a coil that converts sufficient electricity into light while not destroying itself in the process for a reasonable amount of time is child's play compared to the places where Ethereum is going and the problems it needs to solve. But this is nothing new. Even Edison recognized and suffered from the effects of this cultural blindness:
When a reporter asked, "How did it feel to fail 1,000 times?" Edison replied, "I didn’t fail 1,000 times. The light bulb was an invention with 1,000 steps."
But there's an even stronger case for doing this, I believe, if you also use the necessity of the hard fork to add features which would reduce the chances of our experiencing similar issues in the future by enforcing the funding of code bounties and test/fall-back designs proportional to the gas required to execute the test harness against the code. With the test harness scaling that cost to account for the exponential complexity of adding and integrating a larger code base, since the test code must bloat exponentially faster than the code base in order to keep up.
This will keep modules of code manageable in size, because producing more complex modules will quickly become cost prohibitive past the targeted scale.
There's been a lot of talk about how Ethereum block-chain code needs to be of space shuttle quality caliber, because the intent is that once it starts, it doesn't stop.
And I agree that we need to be thinking in those terms. In fact, we need to be thinking of answers to questions like: what would we do if this network were eventually used to bootstrap a super-intelligent AI? Are we prepared for that? How could we manage that?
There was a story in the news recently about a machine learning robot that escaped its confinement. An accident? Maybe. But accident or not, those kinds of accidents in the future are inevitable, so we need to get out ahead of this problem sooner rather than later.
So let's ask ourselves, how could we avoid the existential crisis of the unexpected appearance of an all-powerful force that no one could stop, but that one person drained all of the 'control tokens' from, by exploiting an extremely complex recursive call bug, generated by a blockchain scanning neural net equipped hacker-bot, just after it went live, and whose owner is now the cruel slave master of the entire human race?
When I read that back, I'll admit my first impulse is to laugh, but am I wrong to worry? Isn't this apocalyptic future simply an extrapolation of current trends?
I think those are the kinds of questions we need to be asking of ourselves if we expect to deploy bullet proof code. Immortal code. AI code that can contain other AI code. That's the level of bullet proof we need to be bringing to the table.
And we have to get that right, right now. We can't put it off until later, because any bad code that is deployed to the network today, becomes a potential attack vector for any bot smart enough to discover it and understand how to amplify the effects of exploiting it, probably by chaining its inputs and outputs with other buggy code it has discovered, effectively crafting a computational lock pick to escape its constraints.
Some black hat hacker was smart enough to figure out how to orchestrate manipulative calls to multiple functions on The DAO interface in order to exploit it to their severe advantage.
And to those people who think no crime against property was committed, I would say this: what the hacker did was to manipulate a software 'lock' on a safe in much the same way that an 'irl' criminal would exploit the vulnerabilities of a physical lock with a pick, or a safe with a stethoscope, or a electronic lock with a code breaker. There's a difference between welcome interaction and unwelcome interaction, and this was clearly an assault on a well intended but imperfect digital defense mechanism.
Do we let safe crackers keep their loot because combination lock manufacturers haven't perfected the art of producing perfectly silent tumblers yet? Is that a legitimate defense in any rational discussion of guilt or innocence, much less in any historical court of law?
People are bringing up the concern that if the network developers intervene in this way, then it opens up a path for irl government to assert control over the content deployed to the network.
Well, that is a very real concern. But I think the right response to that concern is to assert that only the network is competent enough to protect itself, judge when an assault against digital property has been perpetrated, and then make a ruling to reverse the harm that was caused to those against whose property an offense was committed.
What's wrong with that? Even libertarians believe in the right of self defense. And in an increasingly complex digital economic ecosystem, why on Earth would any platform recuse itself of the right to defend against what it determines to be an attack, via whatever governance process it has in place?
That's not a governance plan, it's a suicide pact. You can't rely on the old system to police the new one. That would be like trying to mine Bitcoin on an Apple //e. It's preposterous, and for exactly the same reason - the capability gap is just way too vast.
So if you can't rely on the old system to protect you, and you can't survive without being able to protect yourself from attack, then what's the logical option? I think it's to admit that sometimes things will go wrong, and we're going to need to have an agreed up process about how we go about handling those situations.
It's a "catch block," okay? I know, I hate writing them too. But we'd better get good at it. Fast.
And once that governance process is established, then people can decide to alter their level of support based on a clear understanding of what the policies will be if and when things go wrong. There won't be any uncertainty. I think it's the uncertainly that largely contributes to panic.
We don't make perfect stuff. There's no perfect lock, and there's no perfect code. All we can do is to do our best to stay ahead of the curve and make plans to contain the damage from failures. Just like every other manufacturer of an exploitable product or tool has to do. It's an arms race between builders and destroyers.
And some are contemplating giving in to a would-be destroyer? On principle? Really? Which principle is that, exactly?
So let's imagine how much more creative a smart hacker-bot tool might be in the future in orchestrating interlocking exploits on code located on millions of future DAO interfaces, which it has all the time in the world (compared to our human DAO hacker) to analyze and scheme with.
That's a losing battle. Unless you modify the design.
Will it be expensive to adjust network usage fees to enforce the creation of bounty markets which balance code protection with code production? Yes, it probably will be.
But I think it's become evident in the last couple of days that the costs of not doing that may be far higher. And the stakes only get higher as we move forward.
But there are benefits that go along with the costs, if we take advantage of them. Another strategy I think would be helpful to adopt is a formalized policy and technology stack for constructing Dapps from high-bounty, long-deployed libraries of modules to reduce the costs of software development without sacrificing quality and security.
In other words - I think creating new programs on Ethereum in the future should be inversely expensive with respect to their degree of modularized code re-use. The economy should incentivize code re-use by making it economically attractive to expend the capital required to design, code, and then pay for bounty testing and attack targeting, in order to have a 'certified' module that anyone can incorporate into their own smart contracts - for a fee that corresponds to the amount of bug bounty and test capital that has been invested in that code.
There's no free lunch. If we want the best code humans can produce, then we have to pay for it. One way or the other.
This approach would also have the nice side-effect of making coding a smart contract via a drag and drop interface come about much sooner rather than later. But you should only put code like that into the hands of inexperienced developers once it has been sufficiently tested by experts and the very best malicious attackers.
Doing otherwise might be considered the digital equivalent of handing hand grenades to babies. It's a really bad idea to release buggy code out into the wild, and unless Ethereum has protocol level protection against that, I don't see how you prevent that from happening with Turing complete scripts.
The code base will eventually reach a complexity/error collapse point that exposes more and more weaknesses to ever less sophisticated attacks. That seems like a losing strategy.
Finally, I would also suggest that before the hard fork replaces the DAO members' ether a sum be subtracted and sent to the DAO hacker's address. And that sum, I would suggest, should be an order of magnitude larger than the cost of developing and executing the test harness that would have been required to spot the error plus the estimated value of the bounties that would have been lost had the code been running unprotected over the period of time it took to develop the test suite.
In my opinion, this is a way to try to balance harm reduction for both sides. Pay the hacker generously for the flaw they pointed out that we need to learn how to systematically fix, not just for one contract on the network, but for all of them. But also protect the network and its supporters.
I think that's a reasonable policy for governance - do everything possible to protect against attacks and also respect fair exchanges of value with outside parties - even those parties who were guilty of a thwarted attack. Treat your adversary with respect, in other words. Pay them fairly for testing your steel.
Ultimately Ethereum will succeed or fail based on its ability to deliver on your vision, not on the number of mistakes we had to overcome to get there. So please stay faithful to the supporters of that vision. Together I think we're all going to do some amazing things.
Sincerely,
BadLibertarian
submitted by BadLibertarian to ethtrader [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2016-01-14)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last summarisation
Disclaimer
Please bear in mind I'm not a developer so some things might be incorrect or plain wrong. There are no decisions being made in these meetings, but since a fair amount of devs are present it's a good representation. Copyright: Public domain

Logs

Main topics

Versionbits

background

BIP 9 Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last 1000 blocks have a version number higher than X the fork is deployed. A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011). This way softforks can be deployed simultaneous and independent of each other.

meeting comments

Morcos is volunteering to take over championing this proposal as CodeShark and Rusty are busy on other things. He'll review both implementations and then decide on which implementation he'll base his work upon. He notes that if non-core implementations are trying to do something else (and are using nVersion for their signaling) while segregated witness is being deployed, not conflicting will be important so users of other versions can also support segregated witness. If there's an agreement with this approach it's necessary that versionbits is ready before the segregated witness deployment. jtimon has some suggestions to make the implementation less complicated and more flexible.

meeting conclusion

Morcos will champion the new reference implementation for BIP9: Versionbits.

Status of segregated witness

background

Segregated witness changes the structure of transactions so that the signatures can be separated from the rest of the transactions. This allows for bandwidth savings for relay, pruning of old signatures, softforking all future script changes by introducing script versions and solves all unintentional forms of malleability. During the last scaling bitcoin conference Pieter Wuille presented a way of doing this via a softfork, and proposed increasing the maximum amount of transactions in a block by discounting signature data towards the total blocksize. Segregated witness is part of the capacity increase roadmap for bitcoin-core. More detailed explanations: - By Pieter Wuille at the San Francisco bitcoin developer meetup (more technical) - By Andreas Antonopoulos in the let's talk bitcoin podcast (less technical)

meeting comments

Segnet, the testnet for segregated transactions, will be going to it's 3rd version soon. Luke-Jr has assigned all the segregated witness BIPs to a 14x range. Currently there are 4 BIPs: 141, 142, 143 and 144.

Status of 0.12 bitcoin-core release

background

Bitcoin Core 0.12 is scheduled for release around February and introduces a lot of fixes and improvements. (release notes) There's a release candidate 0.12rc1 available at https://bitcoin.org/bin/bitcoin-core-0.12.0/test/

meeting comments

Luke-Jr feels PR's #7149, #7339 and #7340 should have been in 0.12, but are now really late and possibly impractical to get in. For gitian builders: 0.12rc1's osx sig attach descriptor fails due to a missing package (that's not actually needed). Rather than using the in-tree descriptor, use the one from #7342. This is fixed for rc2. "fundrawtransaction" and "setban" should be added to the release notes. At some point it makes more sense to document these commands elsewhere and link to it in the release notes, as they've become very lengthy. Wumpus thinks the release notes have too much details, they're not meant to be a substitute for documentation.

meeting conclusion

Close PR #7142 as it's now part of #7148 Everyone is free to improve on the release notes, just submit a PR.

consensus code encapsulation (libconsensus)

background

Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separate, but in bitcoin it's all intertwined. Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork. This however is a slow and dangerous project of moving lots of code around.

meeting comments

jtimon has 4 libconsensus related PRs open, namely #7091 #7287 #7311 and #7310 He thinks any "big picture branch" will be highly unreadable without merging something like #7310 first. The longest "big picture branch" he currently has is https://github.com/jtimon/bitcoin/commits/libconsensus-f2 He'll document the plan and "big picture" in stages: 1. have something to call libconsensus: expose verifyScript. (Done) 2. put the rest of the consensus critical code, excluding storage in the same building package (see #7091) 3. discuss a complete C API for libconsensus 4. separate it into a sub-repository Wumpus notes he'd like to start with 3 as soon as possible as an API would be good to guide this.

meeting conclusion

review #7091 #7287 #7311 and #7310

Locktime PRs

background

BIP 68 Consensus-enforced transaction replacement signaled via sequence numbers. BIP 112 CHECKSEQUENCEVERIFY. BIP 113 Median time-past as endpoint for lock-time calculations. In short: BIP 68 changes the meaning of the sequence number field to a relative locktime. BIP 112 makes that field accessible to the bitcoin scripting system. BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions.

meeting comments

We need to make a choice between 2 implementations, namely #6312 and #7184. PR #7184 is a result of the CreateNewBlock optimisations not being compatible with #6312. jtimon thinks it could be merged relatively soon as #7184 is based on #6312 which has plenty of testing and review.

meeting conclusion

Close #6312 in favor of #7184. Morcos will fix the open nits on #7184 btcdrak will update the BIP-text

Participants

wumpus Wladimir J. van der Laan btcdrak btcdrak morcos Alex Morcos jtimon Jorge Timón Luke-Jr Luke Dashjr MarcoFalke Marco Falke jonasshnelli Jonas Schnelli cfields Cory Fields sipa Pieter Wuille kanzure Bryan Bishop droark Douglas Roark sdaftuar Suhas Daftuar Diablo-D3 Patrick McFarland 

Comic relief

19:54 wumpus #meetingstop 19:54 wumpus #stopmeeting 19:54 btcdrak haha 19:54 MarcoFalke #closemeeting 19:54 wumpus #endmeeting 19:54 lightningbot` Meeting ended Thu Jan 14 19:54:26 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 
submitted by G1lius to btc [link] [comments]

Fiver Bot Bitcoin mining Hack Script 14BTC Script Multiply Freebitco.in 99% Auto Win 2019 Freebitcoin Script - YouTube Earn Free 1 BTC with BtcSpinner Script Bot MAY 2018 -1000% ... Fiver Bot Bitcoin mining Hack Script 14BTC

About the Bitcoin Generator. BitcoinGenerator.me, also known as the "Bitcoin Hack", is the ultimate personal Bitcoin Generator. It's an online encrypted software that generates free Bitcoins to your platform's wallet account. It uses a peer-to-peer cryptography system that generates the cryptocurrency (Bitcoin) into your account (wallet). FYI, the BEST secret about this latest BTC Robot v2.3 version is that it can generate profits on TURBO!When you run it in Scalper mode, it trades much faster than usual and generates MUCH more profits than the regular Medium-term strategy. Download free CryptoGrabber V2.0 – Cryptocurrency Stealer [Builder]. This tool will allow you to create your own executable file that will make possible the magic of changing the addresses that are copied to the clipboard for yours. HaashOnline is one the most feature-rich bots in the market, because of its developer-friendly environment, meaning if you got the skills, you can script anything on it. Automated Bot Trading. Choose from a large stack of ready-made trading strategies, or create your own. Drag-and-drop Visual Builder Bitcoin Core is a community-driven free software project, released under the MIT license. Verify release signatures Download torrent Source code Show version history. Bitcoin Core Release Signing Keys v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Or choose your operating system. Windows exe - zip.

[index] [1663] [26746] [5389] [31735] [29666] [14946] [18458] [21302] [15090] [22701]

Fiver Bot Bitcoin mining Hack Script 14BTC

10000 Roll Freebitco.in Script Earn 0.047 Bitcoin Real ? Free Bitcoin - Duration: 4:14. Alexa z 18,242 views. 4:14. I Bought a $3 2TB USB Drive and Got More Than Just Malware - Duration: 11:18. bitcoin freebitcoin script freebitcoin bot win bitcoin win btc freebitco.in 2020 freebitco.in auto bet freebitco.in trick freebitco.in strategy freebitco.in roll freebitco.in win reward points ... free bitcoin bitcoin hack working script freebitcoin roll roll freebitcoin freebitcoin win ... freebitcoin bot script, freebitcoin jackpot hack, win auto bet, earn free btc, Trik Main di situs btcspinner.io pada android Sambil Tidur dengan Kecepatan sampai 1300 RPM - Duration: 5:01. IQ MIN X 89,740 views Update 15 May 2018. The script is still working right now. 1 - Register at this link: https://goo.gl/cyxzJx 2 - Install the extension at this link: https://g...

#