GitHub - bitcoinjs/bitcoinjs-lib: A javascript 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]

This is the definition of FUD. How to subvert consensus and turn bitcoin into something else.

We have a problem. We now have a small group of core devs who are now developing an altcoin under the guise that it is still bitcoin.
This is what it has got to. A bunch of unsubstantiated opinions and logical fallacies with the sole intent of creating FUD.
Lets go through and dissect this.
Gavin Andresen has been advocating strongly that Bitcoin’s blocks need to be permitted to be much larger. Earlier this year, he announced plans to release code that implements larger block sizes via a “hard fork” — a non-backwards-compatible change — against the wishes of most other Bitcoin Core developers, and encourage miners and merchants to adopt his code.
This makes it seem like people are not asking for this change, which they are.
Yesterday, he released a draft BIP, a proposal for how the protocol should change, along with draft code that implements his proposal. But even if one agrees with Gavin’s vision for what the technical features of Bitcoin ought to be, his proposal is an irresponsibly risky path forward.
If everyone agrees, how is it irresponsible?
This has nothing to do with what block sizes should be, but instead about Bitcoin’s much greater experiment: in the absence of a central authority, can people come to agreement on what money to use?
Here we see they try and move the goal post to try and say the debate is actually not about block size limit (since they already lost debate before it started).
It’s useful to step back and think about why anyone might ascribe any value at all to a virtual currency. There are certainly many technical features a currency must have to be a candidate for being worth anything (if you can’t transact it, or if there’s no way to secure it, or there is an infinite amount of it, it’s probably not very useful). But looking past the technical issues, the more fundamental test you’d apply when deciding whether to use a given coin as money is whether you think everyone else will treat it as money too. In particular, if at some point in the future you worried that what you thought was money was not actually considered money by others, then you would probably choose something else to be a store of value.
He is trying to insinuate that bitcoin with a larger block size limit will be worthless. No evidence of course.
This is the most important lens through which we should view Gavin’s proposal. If you have a money that other people accept, under what circumstances should you change it to be a different, new money? That is exactly what a hard fork entails: Gavin is asking 75% of miners to switch to a new currency with new and different properties. If they do so, then they will trigger a permanent change to the consensus rules for those running Gavin’s software. The idea is that if everyone goes along with it and changes their software to match, then we can still call it Bitcoin, and the lack of backwards compatibility is a non-issue (since no one will be around running incompatible code).
So why might everyone switch to a new currency? One reason is if the current one is clearly broken — something like the March 2013 fork, where a latent bug in the reference implementation caused the network to split. In that situation, it was clear to everyone there was a problem, and running software that is buggy was clearly not in anyone’s interest (whether or not others kept running the buggy software). If a hard fork is required to make your money have any utility at all, you’re likely to choose to do it (as long as you believe your solution is the same one everyone else will be deploying!).
But if what you’re using isn’t clearly broken or if there are multiple incompatible choices of code to use to implement a bug fix, the decision is much more difficult. Somehow you have to coordinate your actions with everyone else. And what if there are dissenters? Is it worth risking splitting the network in two (or more)? Under what circumstances is that risk worth taking? Naively, we might reason that a majority in favor of a given hard-fork proposal might refrain from advancing it if they believe there’s a meaningful minority opposed to it, because splitting the network makes the currency less valuable for everyone.
Bitcoin is broken though. It's just that a problem has not arisen from it yet. It can be likened to a tooth on a gear in a large complex machine being broken. The machine works perfectly until that tooth is needed and then it stops working properly. Just because we haven't got to that tooth yet doesn't mean the machine doesn't need fixing.
However, the majority might employ some game theory of their own, and reason that if there are enough of them, then perhaps the minority will feel coerced into going along with a change, because the minority risks the same downsides to splitting the network that the majority does. By proposing a miner vote with a 75% trigger to hard fork the network, Gavin’s proposal is a big game of chicken — with no good outcome for anyone.
This is completely opinion. It is my opinion that not changing the protocol because of an extreme minority is an even larger problem for bitcoin. This is what I would call 'real centralisation' rather than the completely ludicrous meaning of centralisation you come up with later on.
I think this is the existential question for Bitcoin (or any other decentralized digital currency). If splitting the network in two is an easy thing for a majority to decide to do in the face of obvious opposition, then each of us must worry that we might someday be on the wrong side of a future split. Equally, one could interpret such an outcome differently: if Bitcoin’s network can split because there exists some person or people who are able to change the currency against the wishes of others, then perhaps it’s incorrect to think of it as lacking a central authority.
This is such a stupid way of framing this I don't even know where to begin. Firstly, the very fact that this argument has been going on for YEARS now shows that it is the opposite of "easy". You seem to have just swapped the word "possible" with "easy". "if Bitcoin’s original concept and functionality can be co opted because there exists some person or people who are able to change the currency against the wishes of others, then perhaps it’s incorrect to think of it as lacking a central authority." FTFY
Taking either of these interpretations to their logical conclusion suggests that Bitcoin would be an essentially failed experiment. Because however you look at it, it would make much more sense to trust a known authority to run your digital currency (whether that’s a company or a government): many of the technical advantages of Bitcoin could remain and, indeed, future improvements could be more efficient to deploy, if we could jettison the technical baggage that comes from working on a decentralized currency. Of course, you also lose whatever hope you might have had that Bitcoin would be better than any currency backed by a central authority. Still, there could be something beneficial to society even in this case, and maybe Bitcoin could morph into a much better version of Paypal or Visa, and maybe that’s the local maximum that Gavin’s path forward could lead to. This may even be a net win for society compared with the status quo; however it would be an obviously disappointing outcome for many who have different, longer-term aspirations for the technology.
This argument is literally "central authority = vast majority of bitcoin miners, community and nodes deciding for themselves rather than a very small group of specific devs".
It’s fair to ask, if 75% of miners voting on what the hard fork should be is a bad idea, then what is a better trigger? This is a central challenge with hard forking changes to Bitcoin — I don’t think anyone knows the answer to that question. Pieter Wuille brought up this topic on the bitcoin-development mailing list and pointed out that any trigger using miner voting as a component should have a 100% threshold for the vote, because the whole point is that hard forks should not happen before everyone has had a chance to upgrade, so if some miners clearly haven’t upgraded their software, then it’s risky to change consensus while blocks may still be mined on the deprecated chain (which could cause confusion for users who haven’t upgraded). I think that is a reasonable point of view, and Gavin’s response to that appears to be (from the draft BIP):
Sure, so a single person can decide on what the decision is for the entire bitcoin network. What was that about "centralisation" again?
This statement leaves me wondering whether an increase in mining centralization might cause Gavin or others, when proposing a future hard fork, to reduce this trigger down further? Could a 60% miner vote be appropriate the next time someone presses for a hard fork if there’s a 38% hash-rate mining pool in existence?
100% baseless conjecture. "What if next time Gavin wants to add in a contract that allows him to eat your first born child?"
The problem is more complex than this, because miners shouldn’t want to vote in favor of a hard fork if they don’t believe that users will want to switch. But we also don’t have a great way of knowing what code users want to be running
I call this the "we can't know anything" argument. It is used when something that it is pretty self evident cannot be proved as a 100% fact.
(users themselves are likely not aware of the technical details that go into Bitcoin, and so sensibly rely on the advice of technical experts to decide what software is worth running).
What he is saying he is "even if users do want a larger block size limit, they are all too stupid to decide". Which is obviously completely ignorant to that fact that a large percentage of the bitcoin community have been around for a while and in fact DO understand a lot about the technical details of bitcoin.
Still, miners shouldn’t want to trigger a hard fork unless there is obviously no meaningful dissent, for the reasons above — and surely a 24.99% hash power mining operation represents significant risk of the network splitting in a meaningful way.
Maybe. So discuss the merits of realistic alternatives to the threshold rather than attempting to make the fork more contentious.
And that is not taking into account the already clear dissent from the people who are most expert in the field. Under some circumstances it may be difficult to tell whether there is unanimity or near-unanimity amongst people that a particular change to Bitcoin may be a good idea (say, to fix a known bug), but this isn’t one of those situations.
Actually it has been pretty clear we have moved a lot closer to consensus within the technical community of bitcoin in the past weeks. The only dissent that is left is from people who are refusing to budge an inch. Screaming for 100% consensus while refusing to budge an inch is logically the equivalent of saying "do what I say".
However, Gavin has a high profile, and as the technical leader of the project until last year, many still view him as the face of Bitcoin. He may have the power to sway users, merchants, and miners to go along with his code change against the advice of the other technical leaders. I urge rejection of consensus code changes that have not been accepted into Bitcoin Core, and in particular I would urge rejection of Gavin’s proposed code.
People support Gavin not because he is the face of bitcoin but because he has actually made excellent well thought out arguments on all different levels; technical, economic and conceptual. He was worked to make a fair compromise which takes everyones opinions into account (other than people who are not working towards anything) while still trying to progress bitcoin as it was originally intended.
This is contrary to yourself who has not provided a single relevant, technical argument and has only provide extremely weak logical arguments.
Much of the block size debate has been about technical tradeoffs, and especially concerns about scaling versus decentralization.
This is the only technical argument I have ever heard from you and it is based on the false dilemma fallacy that;
Block Size Limit > 1MB = 100% centralisation
OR
Block Size Limit > 1MB = more centralisation
The first argument is obviously false. The second argument is less obviously false. It is likely that running a node requiring extra resources could decrease the percentage of nodes from users, but allowing bitcoin to scale will increase the number of users and therefore increase the number of nodes. At best this isn't an argument for either side since it's just speculation.
Virtually everyone working on the project appears to believe it is important and valuable to figure out how to scale the network’s capacity, but there are differing opinions about how to go about it. I expect we’ll see technical consensus ultimately reached about deploying a different solution to increase block sizes, to give us a way forward with a much lower risk of splitting the network. But whether or not you agree with Gavin’s technical view on block sizes, the philosophy behind decentralized currencies is fundamentally incompatible with deploying his code in the way that he proposes.
Again, this is the "my way or the highway" approach.
I originally thought that these devs were well intentioned. After reading this (and all the other posts), without seeing a single valuable argument against raising the block size limit, I have come to the conclusion that there are specifically deployed FUD tactics at hand to prevent or delay it from happening to turn bitcoin into the vision that they have for it. Back to my original point; these two devs /nullc and /adam3us plus a handful of what I call "helpers" are purposely trying to spread Fear, Uncertainty and Doubt. These are not intelligent or logical arguments even though they are coming from intelligent and logical people. The tactic is to call for 100% consensus while at the same time trying to create as much contention as possible, for example using the title "How the Bitcoin experiment might fail".
What these people want is for users to solely rely on the lightning network and for bitcoin to become inaccessible to the average user. They will try to delay and prevent bitcoin being upgraded as long as possible and as soon bitcoin starts to reach it's transaction limit they will then use this to accelerate development of the lightning network and say that it is the only option. This is the reason why they are calling for the lightning network to be implemented first than the block size limit increase, because it would not be as successful if it was released afterwards. If you don't believe this what they want bitcoin to become as soon as possible, ask them.
submitted by singularity87 to Bitcoin [link] [comments]

IRC Log from Ravencoin Open Developer Meeting - Aug 24, 2018

[14:05] <@wolfsokta> Hello Everybody, sorry we're a bit late getting started
[14:05] == block_338778 [[email protected]/web/freenode/ip.72.214.222.226] has joined #ravencoin-dev
[14:06] <@wolfsokta> Here are the topics we would like to cover today • 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] == Chatturga changed the topic of #ravencoin-dev to: 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] <@wolfsokta> Daben, could you mention what we have done to communicate the need for the 2.0.4 upgrade?
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:07] <@wolfsokta> Others here are free to chime in where they saw the message first.
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has quit [Client Quit]
[14:08] Whats up bois
[14:08] hi everyone
[14:08] hi hi
[14:08] <@wolfsokta> Discussing the 2.0.4 update and the need to upgrade.
[14:08] <@Chatturga> Sure. As most of you are aware, the community has been expressing concerns with the difficulty oscillations, and were asking that something be done to the difficulty retargeting. Many people submitted suggestions, and the devs decided to implement DGW.
[14:09] <@Tron> I wrote up a short description of why we're moving to a new difficulty adjustment. https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:09] <@Chatturga> I have made posts on discord, telegram, bitcointalk, reddit, and ravencointalk.org from testnet stages through current.
[14:10] <@Chatturga> If there are any other channels that can reach a large number of community members, I would love to have more.
[14:10] <@wolfsokta> Thanks Tron, that hasn't been shared to the community at large yet, but folks feel free to share it.
[14:10] When was this decision made and by whom and how?
[14:10] <@Chatturga> I have also communicated with the pool operators and exchanges about the update. Of all of the current pools, only 2 have not yet updated versions.
[14:11] <@wolfsokta> The decision was made by the developers through ongoing requests for weeks made by the community.
[14:12] <@wolfsokta> Evidence was provided by the community of the damages that could be caused to projects when the wild swings continue.
[14:12] So was there a meeting or vote? How can people get invited
[14:12] <@Tron> It was also informed by my conversations with some miners that recommended that we make the change before the coin died. They witnessed similar oscillations from which other coins never recovered.
[14:13] only two pools left to upgrade is good, what about the exchanges? Any word on how many of those have/have not upgraded?
[14:13] <@wolfsokta> We talked about here in our last meeting Bruce_. All attendees were asked if they had any questions or concerns.
[14:13] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has joined #ravencoin-dev
[14:13] == roshii [[email protected]/web/freenode/ip.41.251.25.100] has joined #ravencoin-dev
[14:13] sup roshii long time no see
[14:14] <@Chatturga> Bittrex, Cryptopia, and IDCM have all either updated or have announced their intent to update.
[14:14] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:15] sup russki
[14:15] what's the status here?
[14:15] I don’t think that was at all clear from the last dev meeting
[14:15] I can’t be the only person who didn’t understand it
[14:15] <@wolfsokta> Are there any suggestions on how to communicate the need to upgrade even further? I am concerned that others might also not understand.
[14:17] I’m not sold on the benefit and don’t understand the need for a hard fork — I think it’s a bad precedent to simply go rally exchanges to support a hard fork with little to no discussion
[14:17] so just to note, the exchanges not listed as being upgraded or have announced their intention to upgrade include: qbtc, upbit, and cryptobridge (all with over $40k usd volume past 24 hours according to coinmarketcap)
[14:18] <@wolfsokta> I don't agree that there was little or no discussion at all.
[14:19] <@wolfsokta> Looking back at our meeting notes from two weeks ago "fork" was specifically asked about by BrianMCT.
[14:19] If individual devs have the power to simple decide to do something as drastic as a hard fork and can get exchanges and miners to do it that’s got a lot of issues with centralization
[14:19] <@wolfsokta> It had been implemented on testnet by then and discussed in the community for several weeks before that.
[14:19] == under [[email protected]/web/freenode/ip.72.200.168.56] has joined #ravencoin-dev
[14:19] howdy
[14:19] Everything I’ve seen has been related to the asset layer
[14:19] I have to agree with Bruce_, though I wasn't able to join the last meeting here. That said I support the fork
[14:20] Which devs made this decision to do a fork and how was it communicated?
[14:20] well mostly the community made the decision
[14:20] Consensus on a change is the heart of bitcoin development and I believe the devs have done a great job building that consensus
[14:20] a lot of miners were in uproar about the situation
[14:20] <@wolfsokta> All of the devs were supporting the changes. It wasn't done in isolation at all.
[14:21] This topic has been a huge discussion point within the RVN mining community for quite some time
[14:21] the community and miners have been having issues with the way diff is adjusted for quite some time now
[14:21] Sure I’m well aware of that -
[14:21] Not sold on the benefits of having difficulty crippled by rented hashpower?
[14:21] The community saw a problem. The devs got together and talked about a solution and implemented a solution
[14:21] I’m active in the community
[14:22] So well aware of the discussions on DGW etc
[14:22] Hard fork as a solution to a problem community had with rented hashpower (nicehash!!) sounds like the perfect decentralized scenario!
[14:23] hard forks are very dangerous
[14:23] mining parties in difficulty drops are too
[14:23] <@wolfsokta> Agreed, we want to keep them to an absolute minimum.
[14:23] But miners motivation it’s the main vote
[14:24] What would it take to convince you that constantly going from 4 Th/s to 500 Gh/s every week is worse for the long term health of the coin than the risk of a hard fork to fix it?
[14:24] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[14:24] This hardfork does include the asset layer right? if so why is it being delayed in implementation?
[14:24] <@wolfsokta> Come back Tron!
[14:24] coudl it have been implement through bip9 voting?
[14:24] also hard fork is activated by the community! that's a vote thing!
[14:24] @mrsushi to give people time to upgrade their wallet
[14:25] @under, it would be much hard to keep consensus with a bip9 change
[14:25] <@wolfsokta> We investigated that closely Under.
[14:25] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[14:25] <@wolfsokta> See Tron's post for more details about that.
[14:25] <@spyder_> Hi Tron
[14:25] <@wolfsokta> https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:25] Sorry about that. Computer went to sleep.
[14:26] I'm wrong
[14:26] 2 cents. the release deadline of october 31st puts a bit of strain on getting code shipped. (duh). but fixing daa was important to the current health of the coin, and was widely suppported by current mining majority commuity. could it have been implemented in a different manner? yes . if we didnt have deadlines
[14:27] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has quit [Quit: Page closed]
[14:27] sushi this fork does not include assets. it's not being delayed though, we're making great progress for an Oct 31 target
[14:28] I don’t see the urgency but my vote doesn’t matter since my hash power is still CPUs
[14:28] <@wolfsokta> We're seeing the community get behind the change as well based on the amount of people jumping back in to mine through this last high difficulty phase.
[14:28] So that will be another hardfork?
[14:28] the fork does include the asset code though set to activate on oct 30th
[14:28] yes
[14:29] <@wolfsokta> Yes, it will based on the upgrade voting through the BIP9 process.
[14:29] I wanted to ask about burn rates from this group: and make a proposal.
[14:29] we're also trying hard to make it the last for awhile
[14:29] Can you clear up the above — there will be this one and another hard fork?
[14:29] <@wolfsokta> Okay, we could discuss that under towards the end of the meeting.
[14:30] If this one has the asset layer is there something different set for October
[14:30] <@wolfsokta> Yes, there will be another hard fork on October 31st once the voting process is successful.
[14:31] <@wolfsokta> The code is in 2.0.4 now and assets are active on testnet
[14:31] Bruce, the assets layer is still being worked on. Assets is active on mainnet. So in Oct 31 voting will start. and if it passes, the chain will fork.
[14:31] this one does NOT include assets for mainnet Bruce -- assets are targeted for Oct 31
[14:31] not***
[14:31] not active****
[14:31] correct me if I'm wrong here, but if everyone upgrades to 2.0.4 for this fork this week, the vote will automatically pass on oct 31st correct? nothing else needs to be done
[14:31] Will if need another download or does this software download cover both forks?
[14:31] <@wolfsokta> Correct Urgo
[14:32] thats how the testnet got activated and this one shows "asset activation status: waiting until 10/30/2018 20:00 (ET)"
[14:32] Will require another upgrade before Oct 31
[14:32] thank you for the clarification wolfsokta
[14:32] <@wolfsokta> It covers both forks, but we might have additional bug fixes in later releases.
[14:32] So users DL one version now and another one around October 30 which activates after that basically?
[14:33] I understand that, but I just wanted to make it clear that if people upgrade to this version for this fork and then don't do anything, they are also voting for the fork on oct 31st
[14:33] Oh okay — one DL?
[14:33] Bruce, Yes.
[14:33] Ty
[14:33] well there is the issue that there maybe some further consensus bugs dealing with the pruneability of asset transactions that needs to be corrected between 2.0.4 and mainnet. so i would imagine that there will be further revisions required to upgrade before now and october 31
[14:33] @under that is correct.
[14:34] I would highly recommend bumping the semver up to 3.0.0 for the final pre 31st release so that the public know to definitely upgrade
[14:34] @under +1
[14:35] out of curiosity, have there been many bugs found with the assets from the version released in july for testnet (2.0.3) until this version? or is it solely a change to DGW?
[14:35] <@wolfsokta> That's not a bad idea under.
[14:35] <@spyder_> @under good idea
[14:35] @urgo. Bugs are being found and fixed daily.
[14:35] Any time the protocol needs to change, there would need to be a hard fork (aka upgrade). It is our hope that we can activate feature forks through the BIP process (as we are doing for assets). Mining pools and exchanges will need to be on the newest software at the point of asset activation - should the mining hash power vote for assets.
[14:35] blondfrogs: gotcha
[14:35] There have been bugs found (and fixed). Testing continues. We appreciate all the bug reports you can give us.
[14:36] <@wolfsokta> Yes! Thank you all for your help in the community.
[14:37] (pull requests with fixes and test coverage would be even better!)
[14:37] asset creation collision is another major issue. current unfair advantage or nodes that fore connect to mining pools will have network topologies that guarantee acceptance. I had discussed the possibility of fee based asset creation selection and i feel that would be a more equal playing ground for all users
[14:38] *of nodes that force
[14:38] <@wolfsokta> What cfox said, we will always welcome development help.
[14:38] So just to make sure everyone know. When assets is ready to go live on oct 31st. Everyone that wants to be on the assets chain without any problems will have to download the new binary.
[14:39] <@wolfsokta> The latest binary.
[14:39] under: already in the works
[14:39] excellent to hear
[14:39] == UserJonPizza [[email protected]/web/freenode/ip.24.218.60.237] has joined #ravencoin-dev
[14:39] <@wolfsokta> Okay, we've spent a bunch of time on that topic and I think it was needed. Does anybody have any other suggestions on how to get the word out even more?
[14:40] maybe preface all 2.0.X releases as pre-releases... minimize the number of releases between now and 3.0 etc
[14:41] <@wolfsokta> Bruce_ let's discuss further offline.
[14:41] wolfsokta: which are the remaining two pools that need to be upgraded? I've identified qbtc, upbit, and cryptobridge as high volume exchanges that haven't said they were going to do it yet
[14:41] so people can help reach out to them
[14:41] f2pool is notoriously hard to contact
[14:41] are they on board?
[14:42] <@wolfsokta> We could use help reaching out to QBTC and Graviex
[14:42] I can try to contact CB if you want?
[14:42] <@Chatturga> The remaining pools are Ravenminer and PickAxePro.
[14:42] <@Chatturga> I have spoken with their operators, the update just hasnt been applied yet.
[14:42] ravenminer is one of the largest ones too. If they don't upgrade that will be a problem
[14:42] okay good news
[14:42] (PickAxePro sounds like a Ruby book)
[14:43] I strongly feel like getting the word out on ravencoin.org would be beneficial
[14:44] that site is sorely in need of active contribution
[14:44] Anyone can volunteer to contribute
[14:44] <@wolfsokta> Okay, cfox can you talk about the status of unique assets?
[14:44] sure
[14:45] <@wolfsokta> I'll add website to the end of our topics.
[14:45] code is in review and will be on the development branch shortly
[14:45] would it make sense to have a page on the wiki (or somewhere else) that lists the wallet versions run by pools & exchanges?
[14:45] will be in next release
[14:45] furthermore, many sites have friendly link to the standard installers for each platform, if the site linked to the primary installers for each platform to reduce github newb confusion that would be good as well
[14:46] likely to a testnetv5 although that isn't settled
[14:46] <@wolfsokta> Thanks cfox.
[14:46] <@wolfsokta> Are there any questions about unique assets, and how they work?
[14:47] after the # are there any charachters you cant use?
[14:47] will unique assets be constrained by the asset alphanumeric set?
[14:47] ^
[14:47] <@Chatturga> @Urgo there is a page that tracks and shows if they have updated, but it currently doesnt show the actual version that they are on.
[14:47] a-z A-Z 0-9
[14:47] <@Chatturga> https://raven.wiki/wiki/Exchange_notifications#Pools
[14:47] There are a few. Mostly ones that mess with command-line
[14:47] you'll be able to use rpc to do "issueunique MATRIX ['Neo','Tank','Tank Brother']" and it will create three assets for you (MATRIX#Neo, etc.)
[14:47] @cfox - No space
[14:48] @under the unique tags have an expanded set of characters allowed
[14:48] Chatturga: thank you
[14:48] @UJP yes there are some you can't use -- I'll try to post gimmie a sec..
[14:49] Ok. Thank you much!
[14:49] 36^36 assets possible and 62^62 uniques available per asset?
[14:49] <@spyder_> std::regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$");
[14:50] regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$")
[14:50] oh thanks Mark
[14:51] <@wolfsokta> Okay, next up. I want to thank everybody for helping test the iOS wallet release.
[14:51] <@wolfsokta> We are working with Apple to get the final approval to post it to the App Store
[14:51] @under max asset length is 30, including unique tag
[14:51] Does the RVN wallet have any other cryptos or just RVN?
[14:52] == BruceFenton [[email protected]/web/freenode/ip.67.189.233.170] has joined #ravencoin-dev
[14:52] will the android and ios source be migrated to the ravenproject github?
[14:52] I've been adding beta test users. I've added about 80 new users in the last few days.
[14:52] <@wolfsokta> Just RVN, and we want to focus on adding the asset support to the wallet.
[14:53] == Bruce_ [[email protected]/web/freenode/ip.67.189.233.170] has quit [Ping timeout: 252 seconds]
[14:53] <@wolfsokta> Yes, the code will also be freely available on GitHub for both iOS and Android. Thank you Roshii!
[14:53] Would you consider the iOS wallet to be a more secure place for one's holdings than say, a Mac connected to the internet?
[14:53] will there be a chance of a more user freindly wallet with better graphics like the iOS on PC?
[14:53] the android wallet is getting updated for DGW, correct?
[14:53] <@wolfsokta> That has come up in our discussion Pizza.
[14:54] QT framework is pretty well baked in and is cross platform. if we get some qt gurus possibly
[14:54] Phones are pretty good because the wallet we forked uses the TPM from modern phones.
[14:54] Most important is to write down and safely store your 12 word seed.
[14:54] TPM?
[14:54] <@wolfsokta> A user friendly wallet is one of our main goals.
[14:55] TPM == Trusted Platform Module
[14:55] Ahhh thanks
[14:55] just please no electron apps. they are full of security holes
[14:55] <@spyder_> It is whats makes your stuffs secure
[14:55] not fit for crypto
[14:55] under: depends on who makes it
[14:55] The interface screenshots I've seen look like Bread/Loaf wallet ... I assume that's what was forked from
[14:55] ;)
[14:56] <@wolfsokta> @roshii did you see the question about the Android wallet and DGW?
[14:56] Yes, it was a fork of breadwallet. We like their security.
[14:56] chromium 58 is the last bundled electron engine and has every vuln documented online by google. so unless you patch every vuln.... methinks not
[14:56] Agreed, great choice
[14:57] <@wolfsokta> @Under, what was your proposal?
[14:58] All asset creation Transactions have a mandatory OP_CHECKLOCKTIMEVERIFY of 1 year(or some agreed upon time interval), and the 500 RVN goes to a multisig devfund, run by a custodial group. We get: 1) an artificial temporary burn, 2) sustainable community and core development funding for the long term, after OSTK/Medici 3) and the reintroduction of RVN supply at a fixed schedule, enabling the removal of the 42k max cap of total As
[14:58] *im wrong on the 42k figure
[14:58] <@wolfsokta> Interesting...
[14:59] <@wolfsokta> Love to hear others thoughts.
[14:59] Update: I posted a message on the CryptoBridge discord and one of their support members @stepollo#6276 said he believes the coin team is already aware of the fork but he would forward the message about the fork over to them right now anyway
[14:59] Ifs 42 million assets
[14:59] yep.
[15:00] I have a different Idea. If the 500 RVN goes to a dev fund its more centralized. The 500 RVN should go back into the unmined coins so miners can stay for longer.
[15:01] *without a hardfork
[15:01] <@wolfsokta> lol
[15:01] that breaks halving schedule, since utxos cant return to an unmined state.
[15:01] @UJP back into coinbase is interesting. would have to think about how that effects distribution schedule, etc.
[15:01] only way to do that would be to dynamicaly grow max supply
[15:02] and i am concerned already about the max safe integer on various platforms at 21 billion
[15:02] js chokes on ravencoin already
[15:02] <@wolfsokta> Other thoughts on Under's proposal? JS isn't a real language. ;)
[15:02] Well Bitcoin has more than 21 bn Sats
[15:02] Is there somebody who wants to volunteer to fix js.
[15:02] hahaha
[15:03] I honestly would hate for the coins to go to a dev fund. It doesn't seem like Ravencoin to me.
[15:03] Yep, but we're 21 billion x 100,000,000 -- Fits fine in a 64-bit integer, but problematic for some languages.
[15:03] <@wolfsokta> Thanks UJP
[15:04] <@wolfsokta> We're past time but I would like to continue if you folks are up for it.
[15:04] Yeah no coins can go anywhere centrality contorted like a dev fund cause that would mean someone has to run it and the code can’t decide that so it’s destined to break
[15:05] currently and long term with out the financial backing of development then improvements and features will be difficult. we are certainly thankful for our current development model. but if a skunkworks project hits a particular baseline of profitability any reasonable company would terminate it
[15:05] Yes let’s contibue for sure
[15:05] the alternative to a dev fund in my mind would be timelocking those funds back to the issuers change address
[15:06] But we can’t have dev built in to the code — it has to be open source like Bitcoin and monero and Litecoin - it’s got drawbacks but way more advantages- it’s the best model
[15:06] Dev funding
[15:06] i highly reccommend not reducing the utility of raven by removing permanently the supply
[15:07] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has joined #ravencoin-dev
[15:07] timelocking those funds accompllishes the same sacrifice
[15:07] @under timelocking is interesting too
[15:07] How exactly does timelocking work?
[15:07] <@wolfsokta> ^
[15:07] I mean you could change the price of assets with the Block reward halfing.
[15:07] == Roshiix [[email protected]/web/freenode/ip.105.67.2.212] has joined #ravencoin-dev
[15:08] funds cant be spent from an address until a certain time passes
[15:08] but in a what magical fairy land do people continue to work for free forever. funding development is a real issue... as much as some might philosphically disagree. its a reality
[15:08] You’d still need a centralized party to decide how to distribute the funds
[15:08] even unofficially blockstream supports bitcoin devs
[15:08] on chain is more transparent imho
[15:09] == Tron_ [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[15:09] @UJP yes there are unlimited strategies. one factor that I think is v important is giving application developers a way to easily budget for projects which leads to flat fees
[15:09] If the project is a success like many of believe it will be, I believe plenty of people will gladly done to a dev fund. I don't think the 500 should be burned.
[15:09] *donate
[15:09] centralized conservatorship, directed by community voting process
[15:10] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[15:10] <@wolfsokta> Thanks Under, that's an interesting idea that we should continue to discuss in the community. You also mentioned the existing website.
[15:10] It would need to be something where everyone with a QT has a vote
[15:10] think his computer went to sleep again :-/
[15:10] I agree UJP
[15:10] with the website
[15:10] No that’s ico jargon — any development fund tied to code would have to be centralized and would therefor fail
[15:11] ^
[15:11] ^
[15:11] ^
[15:11] dashes model for funding seems to be pretty decentralized
[15:11] community voting etc
[15:11] Once you have a dev fund tied to code then who gets to run it? Who mediates disputes?
[15:11] oh well another discussion
[15:11] Dash has a CEO
[15:12] <@wolfsokta> Yeah, let's keep discussing in the community spaces.
[15:12] Dash does have a good model. It's in my top ten.
[15:12] having the burn go to a dev fund is absolute garbage
[15:12] These dev chats should be more target than broad general discussions — changing the entire nature of the coin and it’s economics is best discussed in the RIPs or other means
[15:13] <@wolfsokta> Yup, let's move on.
[15:13] just becuase existing implementation are garbage doesnt mean that all possible future governance options are garbage
[15:13] <@wolfsokta> To discussing the website scenario mentioned by under.
[15:13] the website needs work. would be best if it could be migrated to github as well.
[15:13] What about this: Anyone can issue a vote once the voting feature has been added, for a cost. The vote would be what the coins could be used for.
[15:14] features for the site that need work are more user friendly links to binaries
[15:14] <@wolfsokta> We investigated how bitcoin has their website in Github to make it easy for contributors to jump in.
[15:14] that means active maintenance of the site instead of its current static nature
[15:15] <@wolfsokta> I really like how it's static html, which makes it super simple to host/make changes.
[15:15] the static nature isn’t due to interface it’s due to no contributors
[15:15] no contribution mechanism has been offered
[15:15] github hosted would allow that
[15:16] We used to run the Bitcoin website from the foundation & the GitHub integration seemed to cause some issues
[15:16] its doesnt necessarily have to be hosted by github but the page source should be on github and contributions could easily be managed and tracked
[15:17] for example when a new release is dropped, the ability for the downlaods section to have platform specific easy links to the general installers is far better for general adoption than pointing users to github releases
[15:18] <@wolfsokta> How do people currently contribute to the existing website?
[15:18] they dont?
[15:18] We did that and it was a complete pain to host and keep working — if someone wants to volunteer to do that work hey can surely make the website better and continually updated — but they could do that in Wordpress also
[15:19] I’d say keep an eye out for volunteers and maybe we can get a group together who can improve the site
[15:19] == digitalvap0r-xmr [[email protected]/web/cgi-irc/kiwiirc.com/ip.67.255.25.134] has joined #ravencoin-dev
[15:19] And they can decide best method
[15:20] I host the source for the explorer on github and anyone can spin it up instantly on a basic aws node. changes can be made to interface etc, and allow for multilingual translations which have been offered by some community members
[15:20] there are models that work. just saying it should be looked at
[15:20] i gotta run thank you all for your contributions
[15:20] <@wolfsokta> I feel we should explore the source for the website being hosted in GitHub and discuss in our next dev meeting.
[15:21] <@Chatturga> Thanks Under!
[15:21] == under [[email protected]/web/freenode/ip.72.200.168.56] has quit [Quit: Page closed]
[15:21] <@wolfsokta> Thanks, we also need to drop soon.
[15:21] There is no official site so why care. Someone will do better than the next if RVN is worth it anyway. That's already the case.
[15:21] <@wolfsokta> Let's do 10 mins of open Q&A
[15:22] <@wolfsokta> Go...
[15:23] <@Chatturga> Beuller?
[15:24] No questions ... just a comment that the devs and community are great and I'm happy to be a part of it
[15:24] I think everyone moved to discord. I'll throw this out there. How confident is the dev team that things will be ready for oct 31st?
[15:24] <@wolfsokta> Alright! Thanks everybody for joining us today. Let's plan to get back together as a dev group in a couple of weeks.
[15:25] thanks block!
[15:25] <@wolfsokta> Urgo, very confident
[15:25] Please exclude trolls from discord who havent read the whitepaper
[15:25] great :)
[15:25] "things" will be ready..
[15:25] Next time on discord right?
[15:25] woah why discord?
[15:25] some of the suggestions here are horrid
[15:25] this is better less point
[15:25] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has quit [Quit: Page closed]
[15:25] Assets are working well on testnet. Plan is to get as much as we can safely test by Sept 30 -- this includes dev contributions. Oct will be heavy testing and making sure it is safe.
[15:26] people
[15:26] <@wolfsokta> Planning on same time, same IRC channel.
[15:26] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has quit [Quit: Page closed]
[15:26] @xmr any in particular?
[15:27] (or is "here" discord?)
[15:27] Cheers - Tron
[15:27] "Cheers - Tron" - Tron
submitted by Chatturga to Ravencoin [link] [comments]

Great interview questions for bitcoin engineers

From here...
https://bitcointalk.org/index.php?topic=5006583.0
Questions. Chapter 1: Introduction 1. What are the main Bitcoin terms? 2. What is a Bitcoin address? 3. What is a Bitcoin transaction? 4. What is a Bitcoin block? 5. What is a Bitcoin blockchain? 6. What is a Bitcoin transaction ledger? 7. What is a Bitcoin system? What is a bitcoin (cryptocurrency)? How are they different? 8. What is a full Bitcoin stack? 9. What are two types of issues that digital money have to address? 10. What is a “double-spend” problem? 11. What is a distributed computing problem? What is the other name of this problem? 12. What is an election? 13. What is a consensus? 14. What is the name of the main algorithm that brings the bitcoin network to the consensus? 15. What are the different types of bitcoin clients? What is the difference between these clients? Which client offers the most flexibility? Which client offers the least flexibility? Which client is the most and least secure? 16. What is a bitcoin wallet? 17. What is a confirmed transaction and what is an unconfirmed transaction? Chapter 2: How Bitcoin works. 1. What is the best way to understand transactions in the Bitcoin network? 2. What is a transaction? What does it contain? What is the similarity of a transaction to a double entry ledger? What does input correspond to? What does output correspond to? 3. What are the typical transactions in the bitcoin network? Could you please name three of such transactions and give examples of each type of the transaction? 4. What is a QR and how it is used in the Bitcoin network? Are there different types of QRs? If so, what are the different types? Which type is more informational? What kind of information does it provide? 5. What is SPV? What does this procedure check and what type of clients of the Bitcoin network usually use this procedure? Chapter 3: The Bitcoin client. 1. How to download and install the Core Bitcoin client? 2. What is the best way to test the API available for the Core Bitcoin client without actually programming? What is the interface called? 3. What are the major areas of operations in the Bitcoin client? What can we do with the client? 4. What are the available operations for the Bitcoin addresses? 5. What are the available read operations for the Bitcoin transactions? How is a transaction encoded in the Bitcoin network? What is a raw transaction and what is a decoded transaction? 6. If I want to get information about a transaction that is not related to any address in my own wallet, do I need to change anything in the Bitcoin client configuration? If yes, which option do I need to modify? 7. What are the available read operation for the Bitcoin blocks? 8. What are the available operations for the creation of the transactions in the Bitcoin network? 9. How do you normally need to address the unspent output from the previous transaction in order to use it as an input for a new transaction? 10. What is the mandatory operation after creating a new transaction and before sending this new transaction to the network? What state does the wallet have to be in order to perform this operation? 11. Is the transaction ID immutable (TXID)? If not why, if yes, why and when? 12. What does signing a transaction mean? 13. What are the other options for Bitcoin clients? Are there any libraries that are written for some specific languages? What types of clients do these libraries implement? Chapter 4: Keys, Addresses and Wallets. 1. What is a PKC? When it was developed? What are the main mathematical foundations or functions that PKC is using? 2. What is ECC? Could you please provide the formula of the EC? What is the p and what is the Fp? What are the defined operations in ECC? What is a “point to infinity”? 3. What is a Bitcoin wallet? Does this wallet contain coins? If not, what does it contain then? 4. What is a BIP? What it is used for? 5. What is an encrypted private key? Why would we want to encrypt private keys? 6. What is a paper wallet? What kind of storage it is an example of? 7. What is a nondeterministic wallet? Is it a good wallet or a bad wallet? Could you justify? 8. What is a deterministic wallet? 9. What is an HD wallet? 10. How many keys are needed for one in and out transaction? What is a key pair? Which keys are in the key pair? 11. How many keys are stored in a wallet? 12. How does a public key gets created in Bitcoin? What is a “generator point”? 13. Could you please show on a picture how ECC multiplication is done? 14. How does a private key gets created in Bitcoin? What we should be aware of when creating a new private key? What is CSPRNG? What kind of input should this function be getting? 15. What is a WIF? What is WIF-Compressed? 16. What is Base58 encoding and what is Base58Check encoding? How it is different from Base64 encoding? Which characters are used in Base58? Why Base58Check was invented? What kind of problems does it solve? How is Base58Check encoding is created from Base58 encoding? 17. How can Bitcoin addresses be encoded? Which different encodings are used? Which key is used for the address creation? How is the address created? How this key is used and what is the used formula? 18. Can we visually distinguish between different keys in Base58Check format? If yes, how are they different from each other? What kind of prefixes are used? Could you please provide information about used prefixes for each type of the key? 19. What is an index in HD wallets? How many siblings can exist for a parent in an HD wallet? 20. What is the depth limitation for an HD wallet key hierarchy? 21. What are the main two advantages of an HD wallet comparing to the nondeterministic wallets? 22. What are the risks of non-hardened keys creation in an HD wallet? Could you please describe each of them? 23. What is a chain code in HD wallets? How many different chain code types there are? 24. What is the mnemonic code words? What are they used for? 25. What is a seed in an HD wallet? Is there any other name for it? 26. What is an extended key? How long is it and which parts does it consist of? 27. What is P2SH address? What function are P2SH addresses normally used for? Is that correct to call P2SH address a multi-sig address? Which BIP suggested using P2SH addresses? 28. What is a WIF-compressed private key? Is there such a thing as a compressed private key? Is there such a thing as a compressed public key? 29. What is a vanity address? 30. What is a vanity pool? 31. What is a P2PKH address? What is the prefix for the P2PKH address? 32. How does the owner prove that he is the real owner of some address? What does he have to represent to the network to prove the ownership? Why a perpetrator cannot copy this information and reuse it in the next transactions? 33. What is the rule for using funds that are secured by a cold storage wallet? How many times you can send to the address that is protected by the private key stored in a cold storage? How many times can you send funds from the address that is protected by the private key stored in a cold storage? Chapter 5: Transactions. 1. What is a transaction in Bitcoin? Why is it the most important operation in the Bitcoin ecosystem? 2. What is UTXO? What is one of the important rules of the UTXO? 3. Which language is used to write scripts in Bitcoin ecosystem? What are the features of this language? Which language does it look like? What are the limitations of this language? 4. What is the structure of a transaction? What does transaction consists of? 5. What are the standard transactions in Bitcoin? How many standard transactions there are (as of 2014)? 6. What is a “locking script” and what is an “unlocking script”? What is inside these scripts for a usual operation of P2PKH? What is a signature? Could you please describe in details how locking and unlocking scripts work and draw the necessary diagrams? 7. What is a transaction fee? What does the transaction fee depend on? 8. If you are manually creating transactions, what should you be very careful about? 9. Could you please provide a real life scenario when you might need a P2SH payment and operation? 10. What is the Script operation that is used to store in the blockchain some important data? Is it a good practice? Explain your answer. Chapter 6: The Bitcoin Network. 1. What is the network used in Bitcoin? What is it called? What is the abbreviation? What is the difference between this network architecture and the other network architectures? Could you please describe another network architecture and compare the Bitcoin network and the other network architectures? 2. What is a Bitcoin network? What is an extended Bitcoin network? What is the difference between those two networks? What are the other protocols used in the extended Bitcoin network? Why are these new protocols used? Can you give an example of one such protocol? What is it called? 3. What are the main functions of a bitcoin node? How many of them there are? Could you please name and describe each of them? Which functions are mandatory? 4. What is a full node in the Bitcoin network? What does it do and how does it differ from the other nodes? 5. What is a lightweight node in the Bitcoin network? What is another name of the lightweight node? How lightweight node checks transactions? 6. What are the main problems in the SPV process? What does SPV stand for? How does SPV work and what does it rely on? 7. What is a Sybil attack? 8. What is a transaction pool? Where are transaction pools stored in a Bitcoin network client? What are the two different transaction pools usually available in implementations? 9. What is the main Bitcoin client used in the network? What is the official name of the client and what is an unofficial name of this client? 10. What is UTXO pool? Do all clients keep this pool? Where is it stored? How does it differ from the transaction pools? 11. What is a Bloom filter? Why are Bloom filters used in the Bitcoin network? Were they originally used in the initial SW or were they introduced with a specific BIP? Chapter 7: The Blockchain. 1. What is a blockchain? 2. What is a block hash? Is it really a block hash or is it a hash of something else? 3. What is included in the block? What kind of information? 4. How many parents can one block have? 5. How many children can one block have? Is it a temporary or permanent state of the blockchain? What is the name of this state of the blockchain? 6. What is a Merkle tree? Why does Bitcoin network use Merkle trees? What is the advantage of using Merkle trees? What is the other name of the Merkle tree? What kind of form must this tree have? 7. How are blocks identified in the blockchain? What are the two commonly used identities? Are these identities stored in the blockchain? 8. What is the average size of one transaction? How many transactions are normally in one block? What is the size of a block header? 9. What kind of information do SPV nodes download? How much space do they save by that comparing to what they would need if they had to download the whole blockchain? 10. What is a usual representation of a blockchain? 11. What is a genesis block? Do clients download this block and if yes – where from? What is the number of the genesis block? 12. What is a Merkle root? What is a Merkle path? Chapter 8: Mining and Consensus. 1. What is the main purpose of mining? Is it to get the new coins for the miners? Alternatively, it is something else? Is mining the right or good term to describe the process? 2. What is PoW algorithm? 3. What are the two main incentives for miners to participate in the Bitcoin network? What is the current main incentive and will it be changed in the future? 4. Is the money supply in the Bitcoin network diminishing? If so, what is the diminishing rate? What was the original Bitcoin supply rate and how is it changed over time? Is the diminishing rate time related or rather block related? 5. What is the maximum number of Bitcoins available in the network after all the Bitcoins have been mined? When will all the Bitcoins be mined? 6. What is a decentralized consensus? What is a usual setup to clear transactions? What does a clearinghouse do? 7. What is deflationary money? Are they good or bad usually? What is the bad example of deflationary spiral? 8. What is an emergent consensus? What is the feature of emergent consensus? How does it differ from a usual consensus? What are the main processes out of which this emergent decentralized consensus becomes true? 9. Could you please describe the process of Independent Transaction Verification? What is the list of criteria that are checked against a newly received transaction? Where can these rules be checked? Can they be changed over time? If yes, why would they be changed? 10. Does mining node have to be a full node? If not, what are the other options for a node that is not full to be a mining node? 11. What is a candidate block? What types of nodes in the Bitcoin network create candidate blocks? What is a memory pool? Is there any other name of the memory pool? What are the transactions kept in this memory pool? 12. How are transactions added to the candidate block? How does a candidate block become a valid block? 13. What is the minimum value in the Bitcoin network? What is it called and what is the value? Are there any alternative names? 14. What is the age of the UTXO? 15. How is the priority of a transaction is calculated? What is the exact formula? What are the units of each contributing member? When is a transaction considered to be old? Can low priority transactions carry a zero fee? Will they be processed in this case? 16. How much size in each block is reserved for high priority transactions? How are transactions prioritized for the remaining space? 17. Do transactions expire in Bitcoin? Can transactions disappear in the Bitcoin network? If yes, could you please describe such scenario? 18. What is a generation transaction? Does it have another name? If it does, what is the other name of the transaction? What is the position of the generation transaction in the block? Does it have an input? Is the input usual UTXO? If not – what is the input called? How many outputs there are for the generation transaction? 19. What is the Coinbase data? What is it currently used for? 20. What is little-endian and big-endian formats? Could you please give an example of both? 21. How is the block header constructed? Which fields are calculated and added to the block header? Could you please describe the steps for calculation of the block header fields? 22. What is a mantissa-exponent encoding? How is this encoding used in the Bitcoin network? What is the difficulty target? What is the actual process of mining? What kind of mathematical calculation is executed to conduct mining? 23. Which hash function is used in the Bitcoin mining process? 24. Could you describe the PoW algorithm? What features of the hash function does it depend on? What is the other name of the hash function? What is a nonce? How can we increase the difficulty of the PoW calculation? What do we need to change and how do we need to change this parameter? 25. What is difficulty bits notation? Could you please describe in details how it works? What is the formula for the difficulty notation? 26. Why is difficulty adjustable? Who adjusts it and how exactly? Where is the adjustment made? On which node? How many blocks are taken into consideration to predict the next block issuance rate? What is the change limitation? Does the target difficulty depend on the number of transactions? 27. How is a new block propagated in the network? What kind of verification does each node do? What is the list of criteria for the new block? What kind of process ensures that the miners do not cheat? 28. How does a process of block assembly work? What are the sets of blocks each full node have? Could you please describe these sets of blocks? 29. What is a secondary chain? What does each node do to check this chain and perhaps to promote it to the primary chain? Could you please describe an example when a fork occurs and what happens? 30. How quickly forks are resolved most of the time? Within how many new block periods? 31. Why the next block is generated within 10 minutes from the previous? What is this compromise about? What do designers of the Bitcoin network thought about when implementing this rule? 32. What is a hashing race? How did Bitcoin hashing capacity has changed within years from inception? What kind of hardware devices were initially used and how did the HW utilization evolved? What kind of hardware is used now to do mining? How has the network difficulty improved? 33. What is the size of the field that stores nonce in the block header? What is the limitation and problem of the nonce? Why was an extra nonce created? Was there any intermediate solution? If yes, what was the solution? What are the limitations of the solution? 34. What is the exact solution for the extra nonce? Where does the new space come from? How much space is currently used and what is the range of the extra nonce now? 35. What is a mining pool? Why was it created? How are normally such pools operated? Do they pay regularly to the pool participants? Where are newly created Bitcoins distributed? To which address? How do mining pools make money? How do the mining pools calculate the participation? How are shares earned calculated? 36. What is a managed pool? How is the owner of the pool called? Do pool members need to run full nodes? Explain why or why not? 37. What are the most famous protocols used to coordinate pool activities? What is a block template? How is it used? 38. What is the limitation of a centralized pool? Is there any alternative? If yes, what is it? How is it called? How does it work? 39. What is a consensus attack? What is the main assumption of the Bitcoin network? What can be the targets of the consensus attacks? What can these attacks do and what they cannot do? How much overall capacity of the network do you have to control to exercise a consensus attack? Chapter 9: Alternative Chains, Currencies and Applications. 1. What is the name of alternative coins? Are they built on top of the Bitcoin network? What are examples of them? Is there any alternative approach? Could you please describe some alternatives? 2. Are there any alternatives to the PoW algorithm? If yes – what are the alternatives? Could you please name two or three? 3. What is the operation of the Script language that is used to store a metadata in Bitcoin blockchain? 4. What is a coloured coin? Could you please explain how it is created and how it works? Do you need any special SW to manage coloured coins? 5. What is the difference between alt coins and alt chains? What is a Litecoin? What are the major differences between the Bitcoin and Litecoin? Why so many alt coins have been created? What are they usually based on? 6. What is Scrypt? Where is it used and how is it different from the original algorithm from which it has been created? 7. What is a demurrage currency? Could you please give an example of one blockchain and crypto currency that is demurrage? 8. What is a good example of an alternative algorithm to PoW? What is it called and how is it different from the PoW? Why the alternatives to Bitcoin PoW have been created? What is the main reason for this? What is dual-purpose PoW algorithms? Why have they been created? 9. Is Bitcoin “anonymous” currency? Is it difficult to trace transactions and understand someone’s spending habits? 10. What is Ethereum? What kind of currency does it use? What is the difference from Bitcoin? Chapter 10: Bitcoin security. 1. What is the main approach of Bitcoin security? 2. What are two common mistakes made by newcomers to the world of Bitcoin? 3. What is a root of trust in traditional security settings? What is a root of trust in Bitcoin network? How should you assess security of your system? 4. What is a cold storage and paper wallet? 5. What is a hardware wallet? How is it better than storing private keys on your computer or your smart phone?
submitted by 5tu to BitcoinTechnology [link] [comments]

Hijacking Bitcoin: Routing Attacks on Cryptocurrencies

arXiv:1605.07524
Date: 2017-03-24
Author(s): Maria Apostolaki, Aviv Zohar, Laurent Vanbever

Link to Paper


Abstract
As the most successful cryptocurrency to date, Bitcoin constitutes a target of choice for attackers. While many attack vectors have already been uncovered, one important vector has been left out though: attacking the currency via the Internet routing infrastructure itself. Indeed, by manipulating routing advertisements (BGP hijacks) or by naturally intercepting traffic, Autonomous Systems (ASes) can intercept and manipulate a large fraction of Bitcoin traffic. This paper presents the first taxonomy of routing attacks and their impact on Bitcoin, considering both small-scale attacks, targeting individual nodes, and large-scale attacks, targeting the network as a whole. While challenging, we show that two key properties make routing attacks practical: (i) the efficiency of routing manipulation; and (ii) the significant centralization of Bitcoin in terms of mining and routing. Specifically, we find that any network attacker can hijack few (<100) BGP prefixes to isolate ~50% of the mining power---even when considering that mining pools are heavily multi-homed. We also show that on-path network attackers can considerably slow down block propagation by interfering with few key Bitcoin messages. We demonstrate the feasibility of each attack against the deployed Bitcoin software. We also quantify their effectiveness on the current Bitcoin topology using data collected from a Bitcoin supernode combined with BGP routing data. The potential damage to Bitcoin is worrying. By isolating parts of the network or delaying block propagation, attackers can cause a significant amount of mining power to be wasted, leading to revenue losses and enabling a wide range of exploits such as double spending. To prevent such effects in practice, we provide both short and long-term countermeasures, some of which can be deployed immediately.

References
[1] “A Next-Generation Smart Contract and Decentralized Application Platform ,” https://github.com/ethereum/wiki/wiki/White-Paper.
[2] “Bitcoin Blockchain Statistics,” https://blockchain.info/.
[3] “bitnodes,” https://bitnodes.21.co/.
[4] “Bitnodes. Estimating the size of Bitcoin network,” https://bitnodes.21.co/.
[5] “CAIDA Macroscopic Internet Topology Data Kit.” https://www.caida.org/data/internet-topology-data-kit/.
[6] “Dyn Research. Pakistan hijacks YouTube.” http://research.dyn.com/2008/02/pakistan-hijacks-youtube-1/.
[7] “FALCON,” http://www.falcon-net.org/.
[8] “FIBRE,” http://bitcoinfibre.org/.
[9] “Litecoin ,” https://litecoin.org.
[10] “RIPE RIS Raw Data,” https://www.ripe.net/data-tools/stats/ris/ris-raw-data.
[11] “Routeviews Prefix to AS mappings Dataset (pfx2as) for IPv4 and IPv6.” https://www.caida.org/data/routing/routeviews-prefix2as.xml.
[12] “Scapy.” http://www.secdev.org/projects/scapy/.
[13] “The Relay Network,” http://bitcoinrelaynetwork.org/.
[14] “ZCash,” https://z.cash/.
[15] A. M. Antonopoulos, “The bitcoin network,” in Mastering Bitcoin. O’Reilly Media, Inc., 2013, ch. 6.
[16] H. Ballani, P. Francis, and X. Zhang, “A Study of Prefix Hijacking and Interception in the Internet,” ser. SIGCOMM ’07. New York, NY, USA: ACM, 2007, pp. 265–276.
[17] A. Boldyreva and R. Lychev, “Provable Security of S-BGP and Other Path Vector Protocols: Model, Analysis and Extensions,” ser. CCS ’12. New York, NY, USA: ACM, 2012, pp. 541–552.
[18] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “Sok: Research perspectives and challenges for bitcoin and cryptocurrencies,” in Security and Privacy (SP), 2015 IEEE Symposium on. IEEE, 2015, pp. 104–121.
[19] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese et al., “P4: Programming protocol-independent packet processors,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 87–95, 2014.
[20] C. Decker and R. Wattenhofer, “Information propagation in the bitcoin network,” in Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on. IEEE, 2013, pp. 1–10.
[21] ——, Bitcoin Transaction Malleability and MtGox. Cham: Springer International Publishing, 2014, pp. 313–326. [Online]. Available: http://dx.doi.org/10.1007/978-3-319-11212-1_18
[22] M. Edman and P. Syverson, “As-awareness in tor path selection,” in Proceedings of the 16th ACM Conference on Computer and Communications Security, ser. CCS ’09, 2009.
[23] I. Eyal, “The miner’s dilemma,” in 2015 IEEE Symposium on Security and Privacy. IEEE, 2015, pp. 89–103.
[24] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” in Financial Cryptography and Data Security. Springer, 2014, pp. 436–454.
[25] N. Feamster and R. Dingledine, “Location diversity in anonymity networks,” in WPES, Washington, DC, USA, October 2004.
[26] J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and applications,” in Advances in Cryptology-EUROCRYPT 2015. Springer, 2015, pp. 281–310.
[27] A. Gervais, G. O. Karama, V. Capkun, and S. Capkun, “Is bitcoin a decentralized currency?” IEEE security & privacy, vol. 12, no. 3, pp. 54–60, 2014.
[28] A. Gervais, H. Ritzdorf, G. O. Karame, and S. Capkun, “Tampering with the delivery of blocks and transactions in bitcoin,” in Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’15. New York, NY, USA: ACM, 2015, pp. 692–705.
[29] P. Gill, M. Schapira, and S. Goldberg, “Let the Market Drive Deployment: A Strategy for Transitioning to BGP Security,” ser. SIGCOMM ’11. New York, NY, USA: ACM, 2011, pp. 14–25.
[30] S. Goldberg, M. Schapira, P. Hummon, and J. Rexford, “How Secure Are Secure Interdomain Routing Protocols,” in SIGCOMM, 2010.
[31] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg, “Eclipse attacks on bitcoin’s peer-to-peer network,” in 24th USENIX Security Symposium (USENIX Security 15), 2015, pp. 129–144.
[32] Y.-C. Hu, A. Perrig, and M. Sirbu, “SPV: Secure Path Vector Routing for Securing BGP,” ser. SIGCOMM ’04. New York, NY, USA: ACM, 2004, pp. 179–192.
[33] J. Karlin, S. Forrest, and J. Rexford, “Pretty Good BGP: Improving BGP by Cautiously Adopting Routes,” in Proceedings of the Proceedings of the 2006 IEEE International Conference on Network Protocols, ser. ICNP ’06. Washington, DC, USA: IEEE Computer Society, 2006, pp. 290–299.
[34] E. K. Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford, “Enhancing bitcoin security and performance with strong consistency via collective signing,” in 25th USENIX Security Symposium (USENIX Security 16). Austin, TX: USENIX Association, 2016, pp. 279–296.
[35] J. A. Kroll, I. C. Davey, and E. W. Felten, “The economics of bitcoin mining, or bitcoin in the presence of adversaries.” Citeseer.
[36] A. Miller, J. Litton, A. Pachulski, N. Gupta, D. Levin, N. Spring, and B. Bhattacharjee, “Discovering bitcoin’s public topology and influential nodes.”
[37] S. J. Murdoch and P. Zielinski, “Sampled traffic analysis by Internet- ´ exchange-level adversaries,” in Privacy Enhancing Technologies: 7th International Symposium, PET 2007, N. Borisov and P. Golle, Eds. Springer-Verlag, LNCS 4776, 2007, pp. 167–183.
[38] K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,” IACR Cryptology ePrint Archive, vol. 2015, p. 796, 2015.
[39] T. Neudecker, P. Andelfinger, and H. Hartenstein, “A simulation model for analysis of attacks on the bitcoin peer-to-peer network,” in IFIP/IEEE International Symposium on Internet Management. IEEE, 2015, pp. 1327–1332.
[40] P. v. Oorschot, T. Wan, and E. Kranakis, “On interdomain routing security and pretty secure bgp (psbgp),” ACM Trans. Inf. Syst. Secur., vol. 10, no. 3, Jul. 2007.
[41] A. Pilosov and T. Kapela, “Stealing The Internet. An Internet-Scale Man In The Middle Attack.” DEFCON 16.
[42] Y. Rekhter and T. Li, A Border Gateway Protocol 4 (BGP-4), IETF, Mar. 1995, rFC 1771.
[43] M. Rosenfeld, “Analysis of hashrate-based double spending,” arXiv preprint arXiv:1402.2009, 2014.
[44] A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining strategies in bitcoin,” CoRR, vol. abs/1507.06183, 2015.
[45] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, “Zerocash: Decentralized anonymous payments from bitcoin,” in 2014 IEEE Symposium on Security and Privacy. IEEE, 2014, pp. 459–474.
[46] B. Schlinker, K. Zarifis, I. Cunha, N. Feamster, and E. Katz-Bassett, “Peering: An as for us,” in Proceedings of the 13th ACM Workshop on Hot Topics in Networks, ser. HotNets-XIII. New York, NY, USA: ACM, 2014, pp. 18:1–18:7.
[47] J. Schnelli, “BIP 151: Peer-to-Peer Communication Encryption,” Mar. 2016, https://github.com/bitcoin/bips/blob/mastebip-0151.mediawiki.
[48] X. Shi, Y. Xiang, Z. Wang, X. Yin, and J. Wu, “Detecting prefix hijackings in the Internet with Argus,” ser. IMC ’12. New York, NY, USA: ACM, 2012, pp. 15–28.
[49] Y. Sompolinsky and A. Zohar, “Secure high-rate transaction processing in bitcoin,” in Financial Cryptography and Data Security. Springer, 2015, pp. 507–527.
[50] Y. Sun, A. Edmundson, L. Vanbever, O. Li, J. Rexford, M. Chiang, and P. Mittal, “RAPTOR: Routing attacks on privacy in TOR.” in USENIX Security, 2015.
[51] A. Tonk, “Large scale BGP hijack out of India,” 2015, http://www.bgpmon.net/large-scale-bgp-hijack-out-of-india/.
[52] ——, “Massive route leak causes Internet slowdown,” 2015, http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/.
[53] L. Vanbever, O. Li, J. Rexford, and P. Mittal, “Anonymity on quicksand: Using BGP to compromise TOR,” in ACM HotNets, 2014.
[54] Z. Zhang, Y. Zhang, Y. C. Hu, and Z. M. Mao, “Practical defenses against BGP prefix hijacking,” ser. CoNEXT ’07. New York, NY, USA: ACM, 2007.
[55] Z. Zhang, Y. Zhang, Y. C. Hu, Z. M. Mao, and R. Bush, “iSPY: Detecting IP prefix hijacking on my own,” IEEE/ACM Trans. Netw., vol. 18, no. 6, pp. 1815–1828, Dec. 2010.
submitted by dj-gutz to myrXiv [link] [comments]

Echoes of the Past: Recovering Blockchain Metrics From Merged Mining

Cryptology ePrint Archive: Report 2018/1134
Date: 2018-11-22
Author(s): Nicholas Stifter, Philipp Schindler, Aljosha Judmayer, Alexei Zamyatin, Andreas Kern, Edgar Weippl

Link to Paper


Abstract
So far, the topic of merged mining has mainly been considered in a security context, covering issues such as mining power centralization or crosschain attack scenarios. In this work we show that key information for determining blockchain metrics such as the fork rate can be recovered through data extracted from merge mined cryptocurrencies. Specifically, we reconstruct a long-ranging view of forks and stale blocks in Bitcoin from its merge mined child chains, and compare our results to previous findings that were derived from live measurements. Thereby, we show that live monitoring alone is not sufficient to capture a large majority of these events, as we are able to identify a non-negligible portion of stale blocks that were previously unaccounted for. Their authenticity is ensured by cryptographic evidence regarding both, their position in the respective blockchain, as well as the Proof-of-Work difficulty.
Furthermore, by applying this new technique to Litecoin and its child cryptocur rencies, we are able to provide the first extensive view and lower bound on the stale block and fork rate in the Litecoin network. Finally, we outline that a recovery of other important metrics and blockchain characteristics through merged mining may also be possible.

References
  1. C. Decker and R. Wattenhofer, “Information propagation in the bitcoin network,” in Peer-to-Peer Computing (P2P), 2013 IEEE Thirteenth International Conference on. IEEE, 2013, pp. 1–10. [Online]. Available: http://diyhpl.us/∼bryan/papers2/bitcoin/Information% 20propagation%20in%20the%20Bitcoin%20network.pdf
  2. A. Gervais, G. O. Karame, K. Wust, V. Glykantzis, H. Ritzdo rf, and S. Capkun, “On the ¨ security and performance of proof of work blockchains,” in Proceedings of the 2016 ACM SIGSAC. ACM, 2016, pp. 3–16.
  3. A. E. Gencer, S. Basu, I. Eyal, R. van Renesse, and E. G. Sirer, “Decentralization in bitcoin and ethereum networks,” in Proceedings of the 22nd International Conference on Financial Cryptography and Data Security (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/preproceedings/75.pdf
  4. I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” in Financial Cryptography and Data Security. Springer, 2014, pp. 436–454. [Online]. Available: http://arxiv.org/pdf/1311.0243
  5. K. Nayak, S. Kumar, A. Miller, and E. Shi, “Stubborn mining: Generalizing selfish mining and combining with an eclipse attack,” in 1st IEEE European Symposium on Security and Privacy, 2016. IEEE, 2016. [Online]. Available: http://eprint.iacr.org/2015/796.pdf
  6. A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining strategies in bitcoin,” http://arxiv.org/pdf/1507.06183.pdf, 2015, accessed: 2016-08-22. [Online]. Available: http://arxiv.org/pdf/1507.06183.pdf
  7. J. Bonneau, “Why buy when you can rent? bribery attacks on bitcoin consensus,” in BITCOIN ’16: Proceedings of the 3rd Workshop on Bitcoin and Blockchain Research, February 2016. [Online]. Available: http://fc16.ifca.ai/bitcoin/papers/Bon16b.pdf
  8. K. Liao and J. Katz, “Incentivizing blockchain forks via whale transactions,” in International Conference on Financial Cryptography and Data Security. Springer, 2017, pp. 264–279. [Online]. Available: http://www.cs.umd.edu/∼jkatz/papers/whale-txs.pdf
  9. P. McCorry, A. Hicks, and S. Meiklejohn, “Smart contracts for bribing miners,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final14.pdf
  10. A. Zamyatin, N. Stifter, A. Judmayer, P. Schindler, E. Weippl, and W. J. Knottebelt, “(Short Paper) A Wild Velvet Fork Appears! Inclusive Blockchain Protocol Changes in Practice,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: https://eprint.iacr.org/2018/087.pdf
  11. Blockchain.com, “Blockchain.com orphaned blocks,” https://www.blockchain.com/btc/orphaned-blocks, Blockchain.com, accessed: 2018-09-25.
  12. BitcoinChain.com, “Bitcoinchain bitcoin block explorer,” https://bitcoinchain.com/blockexplorer, BitcoinChain.com, accessed: 2018-09-25.
  13. ChainQuery.com, “A web based interface to the bitcoin api json-rpc,” http://chainquery.com/bitcoin-api, ChainQuery.com, accessed: 2018-09-25.
  14. L. Project, “Litecoin,” https://litecoin.org/, accessed: 2016-03-29.
  15. Y. Sompolinsky and A. Zohar, “Accelerating bitcoin’s transaction processing. fast money grows on trees, not chains,” p. 881, 2013. [Online]. Available: http://eprint.iacr.org/2013/881.pdf
  16. A. Miller and L. JJ, “Anonymous byzantine consensus from moderately-hard puzzles: A model for bitcoin,” https://socrates1024.s3.amazonaws.com/consensus.pdf, 2014, accessed: 2016-03-09. [Online]. Available: https://socrates1024.s3.amazonaws.com/consensus.pdf
  17. J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin backbone protocol: Analysis and applications,” in Advances in Cryptology-EUROCRYPT 2015. Springer, 2015, pp. 281–310. [Online]. Available: http://courses.cs.washington.edu/courses/cse454/15wi/papers/bitcoin765.pdf
  18. R. Pass and E. Shi, “Fruitchains: A fair blockchain,” http://eprint.iacr.org/2016/916.pdf, 2016, accessed: 2016-11-08. [Online]. Available: http://eprint.iacr.org/2016/916.pdf
  19. R. Pass, L. Seeman, and a. shelat, “Analysis of the blockchain protocol in asynchronous networks,” http://eprint.iacr.org/2016/454.pdf, 2016, accessed: 2016-08-01. [Online]. Available: http://eprint.iacr.org/2016/454.pdf
  20. K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, and E. Gun, “On scaling decentralized blockchains,” in ¨ 3rd Workshop on Bitcoin and Blockchain Research, Financial Cryptography 16, 2016. [Online]. Available: http://www.tik.ee.ethz.ch/file/74bc987e6ab4a8478c04950616612f69/main.pdf
  21. A. Kiayias and G. Panagiotakos, “On trees, chains and fast transactions in the blockchain.” http://eprint.iacr.org/2016/545.pdf, 2016, accessed: 2017-02-06. [Online]. Available: http://eprint.iacr.org/2016/545.pdf
  22. Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “Spectre: A fast and scalable cryptocurrency protocol,” Cryptology ePrint Archive, Report 2016/1159, 2016, accessed: 2017-02-20. [Online]. Available: http://eprint.iacr.org/2016/1159.pdf
  23. Y. Sompolinsky and A. Zohar, “Phantom: A scalable blockdag protocol,” Cryptology ePrint Archive, Report 2018/104, 2018, accessed:2018-01-31. [Online]. Available: https://eprint.iacr.org/2018/104.pdf
  24. Bitcoin community, “Bitcoin-core source code,” https://github.com/bitcoin/bitcoin, accessed: 2018-09-25.
  25. A. Miller, J. Litton, A. Pachulski, N. Gupta, D. Levin, N. Spring, and B. Bhattacharjee, “Discovering bitcoin’s public topology and influential nodes,” http://cs.umd.edu/projects/coinscope/coinscope.pdf, May 2015, accsessed: 2016-03-09. [Online]. Available: http://cs.umd.edu/projects/coinscope/coinscope.pdf
  26. chainz.cryptoid.info/, “Chainz blockchain explorers,” chainz.cryptoid.info/, chainz.cryptoid.info/, accessed: 2018-09-25.
  27. Narayanan, Arvind and Bonneau, Joseph and Felten, Edward and Miller, Andrew and Goldfeder, Steven, “Bitcoin and cryptocurrency technologies,” http://bitcoinbook.cs.princeton.edu/, 2016, accessed: 2016-03-29. [Online]. Available: https://d28rh4a8wq0iu5.cloudfront.net/bitcointech/readings/princeton bitcoin book.pdf
  28. A. Judmayer, A. Zamyatin, N. Stifter, A. G. Voyiatzis, and E. Weippl, “Merged mining: Curse or cure?” in CBT’17: Proceedings of the International Workshop on Cryptocurrencies and Blockchain Technology, Sep 2017. [Online]. Available: https://eprint.iacr.org/2017/791.pdf
  29. M. Jakobsson and A. Juels, “Proofs of work and bread pudding protocols,” in Secure Information Networks. Springer, 1999, pp. 258–272. [Online]. Available: https://link.springer.com/content/pdf/10.1007/978-0-387-35568-9 18.pdf
  30. A. Judmayer, N. Stifter, K. Krombholz, and E. Weippl, “Blocks and chains: Introduction to bitcoin, cryptocurrencies, and their consensus mechanisms,” Synthesis Lectures on Information Security, Privacy, and Trust, 2017.
  31. A. Kiayias, A. Miller, and D. Zindros, “Non-interactive proofs of proof-of-work,” Cryptology ePrint Archive, Report 2017/963, 2017, accessed:2017-10-03. [Online]. Available: https://eprint.iacr.org/2017/963.pdf
  32. Namecoin community, “Namecoin source code - chainparams.cpp,” https://github.com/namecoin/namecoin-core/blob/fdfb20fc263a72acc2a3c460b56b64245c1bedcb/src/chainparams.cpp#L123, accessed: 2018-09-25.
  33. ——, “Namecoin source code - auxpow.cpp,” https://github.com/namecoin/namecoincore/blob/fdfb20fc263a72acc2a3c460b56b64245c1bedcb/src/auxpow.cpp#L177-L200, accessed: 2018-09-25.
  34. I0Coin community, “I0coin source code,” https://github.com/domob1812/i0coin, accessed: 2018-09-25.
  35. S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https://bitcoin.org/bitcoin.pdf, Dec 2008, accessed: 2015-07-01. [Online]. Available: https://bitcoin.org/bitcoin.pdf
  36. N. T. Courtois and L. Bahack, “On subversive miner strategies and block withholding attack in bitcoin digital currency,” arXiv preprint arXiv:1402.1718, 2014, accessed: 2016-07-04. [Online]. Available: https://arxiv.org/pdf/1402.1718.pdf
  37. J. Gobel, P. Keeler, A. E. Krzesinski, and P. G. Taylor, “Bitcoin blockchain dynamics: the ¨ selfish-mine strategy in the presence of propagation delay,” http://arxiv.org/pdf/1505.05343.pdf, 2015, accessed: 2015-03-01. [Online]. Available: http://arxiv.org/pdf/1505.05343.pdf
  38. N. Developers, “Neo4j,” 2012.
  39. Gavin Andresen, “Bitcoin improvement proposal 34 (bip34): Block v2, height in coinbase,” https://github.com/bitcoin/bips/blob/mastebip-0034.mediawiki, accessed: 2018-09-25. [Online]. Available: https://github.com/bitcoin/bips/blob/mastebip-0034.mediawiki
  40. Matt Corello, “Fast internet bitcoin relay engine,” http://bitcoinfibre.org/, accessed: 2018-09-25. [Online]. Available: http://bitcoinfibre.org/
  41. Suhas Daftuar, “sendheaders message,” https://github.com/bitcoin/bips/wiki/Comments:BIP-0130, accessed: 2018-09-25. [Online]. Available: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130
  42. R. Bowden, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor, “Block arrivals in the bitcoin blockchain,” 2018. [Online]. Available: https://arxiv.org/pdf/1801.07447.pdf
  43. GeistGeld community, “Geistgeld source code,” https://github.com/Lolcust/GeistGeld, accessed: 2018-09-25.
  44. A. P. Ozisik, G. Bissias, and B. Levine, “Estimation of miner hash rates and consensus on blockchains,” arXiv preprint arXiv:1707.00082, 2017, accessed:2017-09-25. [Online]. Available: https://arxiv.org/pdf/1707.00082.pdf
  45. E. Duffield and D. Diaz, “Dash: A payments-focused cryptocurrency,” https://github.com/dashpay/dash/wiki/Whitepaper, Aug 2013, accessed: 2018-09-25. [Online]. Available: https://github.com/dashpay/dash/wiki/Whitepaper
  46. N. Van Saberhagen, “Cryptonote v 2.0,” https://cryptonote.org/whitepaper.pdf, Oct 2013. [Online]. Available: https://cryptonote.org/whitepaper.pdf
  47. G. Hall, “Guide: Merge mining 6 scrypt coins at full hashpower, simultaneously,” https://www.ccn.com/guide-simultaneously-mining-5-scrypt-coins-full-hashpowe, Apr 2014, accessed: 2018-09-25. [Online]. Available: https://www.ccn.com/guide-simultaneouslymining-5-scrypt-coins-full-hashpowe
  48. united-scrypt coin, “[ann][usc] first merged minable scryptcoin unitedscryptcoin,” https://bitcointalk.org/index.php?topic=353688.0, Nov 2013, accessed: 2018-09-25. [Online]. Available: https://bitcointalk.org/index.php?topic=353688.0
  49. J. A. D. Donet, C. Perez-Sola, and J. Herrera-Joancomart ´ ´ı, “The bitcoin p2p network,” in Financial Cryptography and Data Security. Springer, 2014, pp. 87–102. [Online]. Available: http://fc14.ifca.ai/bitcoin/papers/bitcoin14 submission 3.pdf
  50. M. Bartoletti and L. Pompianu, “An analysis of bitcoin op return metadata,” https://arxiv.org/pdf/1702.01024.pdf, 2017, accessed: 2017-03-09. [Online]. Available: https://arxiv.org/pdf/1702.01024.pdf
  51. R. Matzutt, J. Hiller, M. Henze, J. H. Ziegeldorf, D. Mullmann, O. Hohlfeld, and K. Wehrle, ¨ “A quantitative analysis of the impact of arbitrary blockchain content on bitcoin,” in Proceedings of the 22nd International Conference on Financial Cryptography and Data Security (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/preproceedings/6.pdf
  52. M. Grundmann, T. Neudecker, and H. Hartenstein, “Exploiting transaction accumulation and double spends for topology inference in bitcoin,” in 5th Workshop on Bitcoin and Blockchain Research, Financial Cryptography and Data Security 18 (FC). Springer, 2018. [Online]. Available: http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final10.pdf
  53. A. Judmayer, N. Stifter, P. Schindler, and E. Weippl, “Pitchforks in cryptocurrencies: Enforcing rule changes through offensive forking- and consensus techniques (short paper),” in CBT’18: Proceedings of the International Workshop on Cryptocurrencies and Blockchain Technology, Sep 2018. [Online]. Available: https://www.sba-research.org/wpcontent/uploads/2018/09/judmayer2018pitchfork 2018-09-05.pdf
submitted by dj-gutz to myrXiv [link] [comments]

A Small Modification to Segwit | Jimmy Song | Apr 07 2017

Jimmy Song on Apr 07 2017:
Hey everyone, This is an idea that I had about Segwit and Gregory's
proposal from yesterday that I wanted to run by everyone on this list. I'm
not at all sure what this would mean for non-upgraded nodes on the network
and would like feedback on that. This is not a formal BIP as it's a
modification to a previously submitted one, but I'm happy to formalize it
if it would help.
MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
that it only precludes the covert version of ASICBoost. He specifically
left the overt version alone.
Overt ASICBoost requires grinding on the version bits of the Block header
instead of the Merkle Root. This is likely more efficient than the Merkle
Root grinding (aka covert ASICBoost) and requires way less resources (much
less RAM, SHA256 calculations, no tx shuffling, etc).
If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
slight modification, this should, in theory, make ASICBoost a lot more
useful to miners and appeal to their financial interests.
The Modification
Currently, the version bits (currently 4 bytes, or 32 bits) in the header
are used for BIP9 signaling. We change the version bits to a nonce-space so
the miners can use it for overt ASICBoost. The 32-bits are now moved over
to the Coinbase transaction as part of the witness commitment. The witness
commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
as the version bits in the block header previously. The witness commitment
becomes required as per Gregory Maxwell’s proposal.
Reasoning
First, this brings ASICBoost out into the open. Covert ASICBoost becomes
much more costly and overt ASICBoost is now encouraged.
Second, we can make this change relatively quickly. Most of the Segwit
testing stays valid and this change can be deployed relatively quickly.
Note on SPV clients
Currently Segwit stores the witness commitment in the Coinbase tx, so
lightweight clients will need to get the Coinbase tx + Merkle proof to
validate segwit transactions anyway. Putting block version information in
the Coinbase tx will not impose an extra burden on upgraded light clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/93c88127/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014076.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

BIP99½ - An Optimized Procedure to Increase the Block Size Limit

BIP: 99½
Title: An Optimized Procedure to Increase the Block Size Limit
Author: Jorge Stolfi jstolfi
Status: Crufty Draft
Created: 2015-08-30
EDIT: Changed the critical block number from 385000 to 390000 (~2016-01-02).
EDIT2: Slight wording changes ("hopefully" "assuming" as per tsontar).
EDIT3: Changed again critical block number to 395000 (~2016-02-06). Note that the traffic has increased faster than expected, so all predictions would have to be updated.
ABSTRACT
This BIP proposes setting the maximum block size to 8 MB starting with block number 395000.
MOTIVATION
This proposal aims to postpone by a few years the imminent congestion of the Bitcoin network, which is expected to occur in 2016 if traffic continues to increase at the present rate. It also aims to reduce the risk of a crippling "spam attack", that could delay a large fraction of the legitimate traffic for hours or days at a relatively modest cost for the attacker.
Congestion
The current average traffic T is ~120'000 transactions issued by all clients, per day (~1.38 tx/s, ~0.45 MB/block, ~830 tx/block assuming ~530 bytes/tx).
The maximum network capacity C with 1 MB blocks, revealed by the recent "stress tests", is ~200'000 tx/day (~2.32 tx/s, ~0.75 MB/block, ~1390 tx/block). Presumably, the main reason why it is less than 1 MB/block is because certain shortcuts taken by miners often force them to mine empty blocks. Note that the traffic now is 60% of the effective capacity.
Since the traffic rate has weekly, daily, and random fluctuations by several tens of percent, recurrent "traffic jams" (when T is higher than C for several tens of minutes) will start to occur when the average daily traffic is still well below the capacity -- say 80% (160'000 tx/day) or even less. For transactions issued during a traffic jam, the average wait time for first confirmation, which is normally 10-15 minutes, will jump to hours or even days. Fee adjustments may change the order in which individual transactions are confirmed, but the average delay will not be reduced by a single second.
Over the past 12 months, the traffic has approximately doubled, from ~60'000 tx/day. The growth seems to be linear, at the rate of 5000 tx/day per month. If the growth continues to be linear, it should reach 160'000 tx/day in ~8 months (before May 2016). If the growth is assumed to be exponential, it should reach that level in ~5 months, in February 2016.
If the maximum block size were lifted to 8 MB, assuming that empty and partial blocks would continue to be mined in about the same proportion as today, the effective capacity of the network should rise in proportion, to ~6 MB/block (1'600'000 tx/day, 5.90 tx/s). Based on last year's growth, the 80% capacity level (1'280'000 tx/day) will be reached in ~19 years assuming linear growth, and ~3.4 years assuming exponential growth.
Spam attacks
An effective spam attack would have to generate enough spam transactions, with suitable fees, to reduce the effective capacity of the network to a fraction of the legitimate traffic. Then the fraction of the traffic that cannot be serviced will pile up in the queues, forming a growing backlog until the spam attack ends; and the backlog will then clear at the rate limited by the free capacity C - T.
With the current capacity C (200'000 tx/day) and traffic T (120'000 tx/day) a spam attack that blocks half the legitimate traffic would require a spam rate S of at least C - T/2 = 140'000 tx/day (1.62 tx/s, 0.52 MB/block). The fee F per kB offered by those transactions would have to be larger than all but the top ~420 transactions in the queue. If that fee were to be 1 USD/tx, the attack may cost as little as 140'000 USD/day. The backlog of legitimate transactions would grow at the rate of T/2 = ~2500 tx/hour, and, when the attack stops, will be cleared at the maximum rate C - T = ~3300 tx/hour.
With 8 MB block limit, assuming that the effective capacity C will be 1.6 M tx/day and traffic T at 60% of the capacity (like today; expected to be the case 3 years from now), a spam attack that blocks half the traffic would require C - T/2 = 1.12 M tx/day of spam (8 times what an attack would require today). If the required fee F were to be 1 USD/tx, the attack would cost 1.12 million USD per day (ditto).
DEPLOYMENT
The maximum block size would be programmed to be 1 MB until block number 394999, and 8 MB starting with block 395000; which, at 144 blocks/day, is expected to be mined around 2016-02-06.
On the test network, the increase will start with block 390000, which is expected to be mined around 2016-01-02.
In the interest of a quick and uneventful passage through that block number, major miners should publicly state their approval or rejection of it as soon as possible.
If and when the plan is approved by miners comprising a majority of the hashpower, all miners and clients should be alerted and urged to upgrade or modify their software so that it accepts blocks up to 8 MB after the stated block number.
If and when the plan is rejected by miners comprising a majority of the hashpower, all miners and clients shoudl be alerted and warned that this BIP will not be implemented.
RATIONALE
The proposal should have a good chance to be approved and implemented, since the five largest Chinese miners (who have more than 50% of the total hash rate) have already stated in writing that they would agree to an increase of the limit to 8 MB by the end of the year, even theough they did not approve futher increases (in particular, the doublings specified by BIP101). Several major services and other miners have expressed approval for such an increase in the net.
OBJECTIONS TO THIS PROPOSAL
There have been claims that increasing the block size beyond 1 MB would have negative consequences for the health of the network. However, no serious effects were demonstrated, by argument or experimentally. There are worrisome trends in sme parameters, such as the number of full nodes and and the centralization of mining; but those trends obviously are not related to the block size limit, and there is no reason to expect that they would be halted or reversed by imposing a 1 MB cap on the block size starting next year.
It should be noted that the increase is only on the block size limit; the actual block sizes will continue to be determined by the traffic. Even with optimistic forecasts, the average block size should not exceed the 1 MB limit before the end of 2016. If any harmful effects of larger blocks are demonstrated until then, the limt can be reduced again by decision of a majority of the miners.
It has been claimed that netowrk congestion would be beneficial since it would create a "fee market" whereby clients would compete for space in the blocks by paying higer transaction fees. It has been claimed that those fees would compensate for the drop in miners revenue that will follow the next reward halving in 2016. It has also been claimed that the higher fees will inhibit spam and other undesirable uses of the blockchain. However, the "fee market" would be a fundamental totally untested change in the client view of the system. It proposes a novel pricing mecanism that is not used by any existing commercial service, physical or internet-based. There is no evidence that the "fee market" would work as claimed, or that it would achieve any of its expected results. (Rather, there are arguments that it would not.) Congestion would defintely put a cap on usage of the protocol, reduce its value as a payment system, and drive away much legitimate traffic. Congestion, and the unpredictable delays that result from it, are also unlikely to make bitcoin attractive to high-value non-payment uses, such as settlements of other networks or notarization of asset trades. And, mainly, there is no reason to expect that the fee market will generate enough fees to cover the 500'000 USD/day that the miners will lose with the next halving.
COMPATIBILITY
If this change to the Bitcoin protocol gets implemented by a majority of the miners, all players will have to replace or modify their software so that it accepts blocks up to 8 MB after block 395000.
Miners who fail to do so may soon find themselves mining a minority branch of the blockchain, that grows at a much slower rate, will probably be congested from the start, and will probably die soon. That branch will probably be ignored by all major services, therefore any rewards that they earn on that branch will probably be worthless and soon unspendable.
Clients who fail to upgrade or fix their software will not "see" the majority-mined chain once someone creates a block with more than 1 MB. Then, those clients will either be unable to move their coins until they fix their software, or may see only the minority branch above. Transactions that they issue before the fix may get confirmed on the main branch, but may appear to remain unconfirmed on the minority chain. Useof tools like replace-by-fee or child-pays-for-parent while in that state may give confusing results.
DISCLAIMER
The author has never owned or used bitcoin, and has a rather negative view of it. In fact, he is a regular contributor to /buttcoin. While he sees bitcoin as a significant advance toward its stated goal ("a peer-to-peer payment system that does not depend on trusted third parties"), and finds bitcoin interesting as a computer science experiment, he is quite skeptical about its chances of widespread adoption. He also deplores the transformation of bitcoin into a negative-sum pyramid investment schema, which not only has spread much misery and distress allover the world, but has also spoiled the experiment by turning mining into an industrial activity controlled by half a dozen large companies. He hopes that the pyramid will collapse as soon as possible, and that the price will drop to the level predicted by the money velocity equation, so that the aberrant mining industry will disappear. (However, he does not think that this BIP will help to achieve this goal; quite the opposite, unfortunately.)
submitted by jstolfi to bitcoin_uncensored [link] [comments]

Buy a Keyois Capsule, less than 50 available

*This thread is no longer updated, please see: https://bitcointalk.org/index.php?topic=1659001.0 for current information *
The Keyois Capsule is a tamper evident yet stylish way to keep a secret key. Only fifty (50) of these first edition capsules will be made. If you guys like them another fifty might get made.
Benefits over a conventional paper cold storage wallet include:
What's wrong with my current cold storage?
At current rate you can order one of these for 0.1947 btc You can get one delivered for $111USD when sales officially open in mid-October; or $100 US if you order before I have get someone with a real camera to take some pictures. I am sorry it costs so much but it wasn't cheap to make. PM me and we will work out the details!
I am not transmitting you any money, I am engraving your key for you and putting it in this cool thing. You have to supply me with you bitcoin address and BIP38 encrypted key, you also have to promise you understand what you are doing and that you made a good pass phrase. These are not for beginners, if you don't understand how and why to make a strong BIP38 encrypted pass phrase then these are not for you. If you desperately want me to make you an unencrypted capsule I suppose I can do it but I will berate you for the poor decision to trust me (I don't trust you, why should you trust me).
There are 4 total powder coated black end pieces, there is also the possibility to powder coat more pieces however there are some logistical difficulties in that so I would need at least ten people who want the same color or someone willing to pay a lot more for colored caps.
For added security, I recommend you add a dab of glitter nail polish over the drilled out screw heads and take a high resolution photograph; you can use that for a comparison in the future if you ever fear an elaborate scheme has taken place to drill out your capsule, break apart your rings, and replace it all without your knowledge.
See how it was made, sort of
Please re-read BIP38 and do some research on password strength
There are some variations/customizations that you can chose from which include: Most notably, the center piece. Lab-created corundum, this is the mineral rubies and sapphires are made out of. 21 red ruby stones remain
21 blue sapphire stones remain
Assorted Sunstones 1 2 3 4
Assorted Opals 1 2 still 2 [3](
Half opal and sunstone
A mix of tourmaline gems
Some crystal rods 2 skinny quartz rods 1 2 1 fatter quartz rod 1 1 extra skinny selenite rod 1
Glowing vials are not available for sale online; they come in a few colors including: white green - gone green - gone green light blue - gone blue pink orange yellow red - gone purple
These items themselves are not numbered, in fact I purposely made them nice and smooth without any words or websites printed on them.
To arrange creation of your own Keyois capsule please comment here or send me a personal message before you send funds. Please be prepared to sign a message with your key.
There can be no refunds - pay to [this address](13kqk3uk2b577KBSjZuwKQT3MGD9mEaVJC) only - $111 USD worth of BTC

13kqk3uk2b577KBSjZuwKQT3MGD9mEaVJC

There are 50 capsules that will be made for this first edition. To get the ball rolling I have made seven capsules available that are already ready-to-go that are available for sale without providing me with a encrypted key and address; I'll send you everything already generated and secured.
  1. Not for sale - Green vial
  2. Pre-ordered - Green vial / red O-ring
  3. Already ready - Ruby
  4. Already ready - Sapphire
  5. Already ready - Ruby
  6. Already ready - Sapphire
  7. Not for sale - Red vial
  8. Already ready - Ruby
  9. Already ready - Sapphire
  10. Already ready - Ruby
  11. Already ready - Sapphire / brown O-ring - Not for sale
  12. Reserved for testing purposes - TBD
  13. Reserved for testing purposes - TBD
They aren't as prefect and blemish proof as I wanted so I am sorry if there are tiny imperfections on the item, however they should still be a pretty and useful btc piggy bank.
Also I have been playing with (and kind of scratching) 13 or the available 50. Two of those are the black powder coated capsules (with some imperfections). These scratched capsules (the ones used in the pictures) I will sell for a slight (10%) discount.
submitted by ProfBitcoin to Keyois [link] [comments]

BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD Best Free Bitcoin mining  earn up to 0.025 BTC every day  Automated miner BetterHash 1 click miner easy crypto mining 2020 BTC GENERATOR FREE. BITCOIN MINER 2020 100%. LEGIT BITCOIN MONEY GENERATOR.

Why BIP 38? BIP 38 is a good standard, a well-tested and very secure way to encrypt a private key. It is also implemented in the NBitcoin library, which is used by Wasabi.Additionally, there is no standard way (BIP) to encrypt HD wallets. Take into account that it is not only encryption what BIP 38 provides but also a brute-force protection. Typically we support the Node Maintenance LTS version.If in doubt, see the .travis.yml for what versions are used by our continuous integration tests.. WARNING: We presently don't provide any tooling to verify that the release on npm matches GitHub. As such, you should verify anything downloaded by npm against your own verified copy.. Usage. Crypto is hard. Track bitcoin and ether price anywhere with bitcoin price charts, bitcoin price ticker, and price alerts Check balance, transaction history and transaction details for all your accounts in a glance Send bitcoin, and ether via email, QR code, with zero transaction fees (Terms and condition applies, not really zero.) The money not specifically sent somewhere goes to the miner. When you pay for a $15.65 dinner, provide a $20, and say "keep the change", you give $15.65 to the business owner and $4.35 as a tip to the server. With Bitcoin, if you have 20BTC, send someone 15.65 BTC, and do nothing else the miner gets the extra 4.35BTC. People wishing to submit BIPs, first should propose their idea or document to the [email protected] mailing list. After discussion, please open a PR. After copy-editing and acceptance, it will be published here.

[index] [22969] [27111] [25358] [15708] [2502] [3447] [24381] [28310] [4225] [22583]

BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD

BTC GENERATOR FREE. BITCOIN MINER 2020 100%. LEGIT BITCOIN MONEY GENERATOR. Go Site Btc Generator: https://bit.ly/2CQQXyk Go Site Btc Generator: https://bit.ly/2CQQXyk Crypto BTC generator. Free ... FREE CRYPTO MINING APPS - Cryptocurrency For Beginners BITCOIN & MORE (2020) Pi Network iOS Android - Duration: 8:06. Side Hustles - Making Money Online 36,009 views 8:06 Best free Bitcoin mining earn up to 0.025 BTC every day Automated miner boost miner is an reliable Bitcoin mining pool. All of the mining power is backed up by physical miners. How to install and setup Better Hash - Bitcoin Mining Software 2019 - Duration: 21:38. Bitcoin Mining Software 2019 2,343 views. 21:38. Language: English Location: United States BITCOIN GENERATOR FREE BITCOIN MINER 2020 100% LEGIT BITCOIN MONEY ADD Crypto BTC / ETH generator. Free to use. . ... 13:38. VoskCoin 364,349 views. 13:38. The most important lesson from 83,000 ...

Flag Counter