3 Things to Know about Bitcoin Confirmations (2020 Updated)

the year 2020 in Bitcoin Cash so far: a detailed history

the year 2020 in Bitcoin Cash so far: a detailed history
What follows at the bottom is a four page long chronological overview of what happened in BCH in 2020 so far. To make it more digestable and fun to read I start with my narrating of the story.
My attempt was to remain as objective as possible and "let the facts speak for themselve" with everything sourced. I also link to many read.cash articles, the decision of which are the important ones to include is certainly not easy, I count on the rest of the community if I overlooked anything important.

summary & my narrating of the story:
The year started out relatively calm, with cashfusion in "the news" and an older ongoing controversy between Amaury and Roger Ver being worked out. Starting Jan 22nd all debate broke loose with the announcement of “Infrastructure Funding Plan for Bitcoin Cash” by Jiang Zhuoer of BTC.TOP. To illustrate this point 2 days later coinspice ran the title " Roger Ver Praises Vigorous Debate, [...]" and 6 days, less than a week, later Chris Pacia made a read.cash post titled "The 253rd "Thoughts on developer funding" Article" which might have been only a slight exaggeration or he might have been counting. Part of the reason of the tsunami was the lack of worked out details. By the time of Pacia's post a lot had changed: Both BU, Bitcoin Verde and a group of miners had made announcements not to go along with "the plan".
On feb 1st, the second version of the IFP was announced by Jiang Zhuoer in a post “BCH miner donation plan update”. Two weeks later on Feb 15th, the third iteration was announced by Bitcoin ABC which was to be activated by hashrate voting and on the same day Flipstarter was introduced, a sign of the search for alternative solutions. After a few more days and a few more people coming out more against the IFP (including Jonald Fyookball, Mark Lundeberg & Josh Ellithorpe), BCHN was announced on feb 20th with a formal release a week later. Also feb 27th, the DAA was brought back into the conversation by Jonathan Toomim with his " The BCH difficulty adjustment algorithm is broken. Here's how to fix it." video. By early march the IFP was effectively dead with its author Jiang Zhuoer vowing to vote against it. This became clear to everyone when ABC, a day later sudddenly shifted gears towards non-protocol, donation based funding: the IFP was dead. End march ABCs 2020 Business Plan was announced as a way to raise $3.3 million. Mid april to mid may was the high time for voluntary funding with four node implementations and General Protocols, a BCH DeFi Startup successfully raising funds.
By May 15th, the 6th HF network upgrade things had pretty much cooled down. The upgraded included nothing controversial and even saw an unexpected doubling in the unconfirmed transaction chain. June 15th a month later things started to heat up again with the BCHN announcement to remove the "poison pill" or "automatic replay protection". 8th Jul Jonathan Toomim posted "BCH protocol upgrade proposal: Use ASERT as the new DAA" which promised the solution to the long dragging DAA problem. Jul 23th however an unexpected twist occurred when Amaury Séchet posted "Announcing the Grasberg DAA" an incompatible, alternative solution. This, again, sparked a ton of debate and discussion. Grasberg lasted just two weeks from Jul 23th to Aug 6th when ABC announced its plans for the november 2020 upgrade but it had successfully united the opposition in the meanwhile. ABCs plan for november included dropping grasberg in favour of aserti3–2d and introducing IFPv4. Now we're here August 8th, the IFP which was declared dead after just over a month (Jan 22-Mar 5) is now back in full force. The rest of the history is still being written but if p2p electronic cash is to succeed in any big regard it's very thinkable that these events will get into history books.

Important resources: coinspice IFP timeline & Compiled list of BCH Miner Dev Fund posts, articles, discussions

History
Jan 13th : “Do CoinJoins Really Require Equal Transaction Amounts for Privacy? Part One: CashFusion” article by BitcoinMagazine [source]
Jan 13th : “Clearing the Way for Cooperation” Read.cash article by Amaury Séchet [source] on the controversy with Roger Ver about the amount of donations over the years
Jan 22nd : “Infrastructure Funding Plan for Bitcoin Cash” IFPv1 announced by Jiang Zhuoer of BTC.TOP [source] IFPv1: 12.5% of BCH coinbase rewards which will last for 6 months through a Hong Kong-based corporation & to be activated on May 15th
Jan 22nd : ”Bitcoin Cash Developers React to Infrastructure Fund Announcement: Cautiously Optimistic” coinspice article including Amaury Séchet, Antony Zegers, Jonald Fyookball & Josh Ellithorpe [source]
Jan 23rd : Jiang Zhuoer reddit AMA [source] [coinspice article]
Jan 23rd : Vitalik weighs in with his take on twitter [source]
Jan 23rd :” On the infrastructure funding plan for Bitcoin Cash” article by Amaury Séchet [source] [coinspice article] in which he proposed to place control of the IFP key in his hands together with Jonald Fyookball and Antony Zegers. . A group of 7 to 12 miners, developers, and businessmen in total would get an advisory function.
Jan 24th : “Bitcoin.com's Clarifications on the Miner Development Fund“ which emphasizes, among other things, the temporary and reversible nature of the proposal [source] [coinspice article]
Jan 24th : “Little Known (But Important!) Facts About the Mining Plan” Read.cash article by Jonald Fyookball in which he defended the IFP and stressed its necessity and temporary nature.
Jan 25th : massive amounts of public debate as documented by coinspice [coinspice article] with Justin Bons, Tobias Ruck and Antony Zegers explaining their take on it.
Jan 26th : public debate continues: “Assessment and proposal re: the Bitcoin Cash infrastructure funding situation” Read.cash article by imaginary_username [source] which was noteworthy in part because the post earned over Earns $1,000+ in BCH [coinspice article] and “The Best Of Intentions: The Dev Tax Is Intended to Benefit Investors But Will Corrupt Us Instead” by Peter Rizun [source]
Jan 27th : “We are a group of miners opposing the BTC.TOP proposal, here's why” article on Read.cash [source] [reddit announcement]
Jan 27th : Bitcoin Unlimited's BUIP 143: Refuse the Coinbase Tax [source][reddit announcement]
Jan 28th : “Bitcoin Verde's Response to the Miner Sponsored Development Fund” read.cash article by Josh Green in which he explains “Bitcoin Verde will not be implementing any node validation that enforces new coinbase rules.” [source]
Jan 28th : “Update on Developer Funding” read.cash article from Bitcoin.com [source] in which they state “As it stands now, Bitcoin.com will not go through with supporting any plan unless there is more agreement in the ecosystem such that the risk of a chain split is negligible.” And that “any funding proposal must be temporary and reversible.” This announcement from bitcoin.com and their mining pool lead the anonymous opposition miners to stand down. [source]
Jan 28th : The 253rd "Thoughts on developer funding" Article – by Chris Pacia, to tackle the “serious misconceptions in the community about how software development works”. He ends on a note of support for the IFP because of lack of realistic alternatives. [source]
Feb 1st: “BCH miner donation plan update” IFPv2 announced by Jiang Zhuoer of BTC.TOP [source] Which changes the donation mechanism so miners directly send part of their coinbase to the projects they wants to donate to. It would be activated with hashrate voting over a 3-month period with a 2/3 in favour requirement. The proposal also introduces a pilot period and a no donation option, Jiang Zhuoer also says he regards 12.% as too much.
Feb 7th: Group of BCH miners led by AsicSeer voice scepticism about the IFP during a reddit AMA [source]
Feb 15th: “On the Miner Infrastructure Funding Plan” article by Bitcoin ABC [source] In which they announce they will implement IFPv3 in their upcoming 0.21.0 release. This version has amount reduced to 5% of block reward and will go in effect with BIP 9 hashratevoting and a whitelist with different projects.
Feb 15th : “Introducing Flipstarter” [source]
Feb 16th :” Bitcoin.com’s stance on the recent block reward diversion proposals” video by Roger Ver on the Bitcoin.com Official Channel. [source] > Ver called Zhuoer’s IFP “clever” but ultimately “problematic.” [coinspice article]
Feb 16th :” BCH miner donation plan update again” read.cash article by Jiang Zhuoer of BTC.TOP [source] In which he briefly outlines the details of IFPv3
Feb 17th : “Latest Thoughts On Infrastructure Mining Plan” post by Jonald Fyookball [source]
Feb 17th : “Regarding the Bitcoin Cash Infrastructure Funding Plan, I am certain now that it should be scrapped immediately.” tweet by Mark Lundeberg [source]
Feb 19th : “Thoughts on the IFP - A Dev Perspective“ read.cash article by Josh Ellithorpe [source]
Feb 20th : “Bitcoin Cash Node” post announcing the new node implementation [source]
Feb 20th : First “Bitcoin Cash Developer Meeting” After IFP Proposal [source]
Feb 24th : “Flipstarter 500k, 6 independent campaigns” post announcing the goal to “fund the BCH ecosystem with 6 independent campaigns and an overall 500,000 USD target” [source]
Feb 27th : BCHN Formally Released [source]
Feb 27th : “The BCH difficulty adjustment algorithm is broken. Here's how to fix it.” Video by Jonathan Toomim [source]
Mar 3th :” Bitcoin Cash Node 2020: plans for May upgrade and beyond” post by BCHN [source]
Mar 4th :”Author of the Bitcoin Cash IFP [Jiang Zhuoer] Vows to Vote Against It, Using Personal Hash in Opposition” [source]
Mar 5th :Bitcoin ABC announces their 2020 Business Plan Fundraising for later in march [source]
Mar 15th : “EatBCH campaign funded! Next: node campaigns.” campaign funded after 11 hours [source]
Mar 30th : Bitcoin ABC 2020 Business Plan [source] $3.3 Million Fundraiser [source]
Apr 17th : Five flipstarter node campaign launched. [source]
Apr 26th : BCHN flipstarter campaign successfully funded. [source]
Apr 27th : VERDE flipstarter campaign successfully funded. [source]
May 4th : KNUTH flipstarter campaign successfully funded. [source]
May 7th : “BCH DeFi Startup General Protocols Raises Over $1 mil“ [source]
May 8th : BCHD flipstarter campaign successfully funded. [source]
May 9th : Deadline for node campaigns, ABC flipstarter campaign not funded. [source]
May 14th : “With IFP Defeated, Bitcoin ABC, ViaBTC & CoinEX CEO Publicly Consider a Bitcoin Cash Foundation” [source]
May 15th : deadline for ABC fundraiser campaign, ends at 55% completed. [source]
May 15th : 6th HF network upgrade -> new opcode op_Reversebytes, increased of the chained transaction limit from 25 to 50, and the improved counting of signature operations using the new “Sigchecks” implementation [source] with the “Controversial Funding Plan Rejected by Miners” [source]
May 25th : “Announcing the SLP Foundation” [source]
Jun 15st : “BCHN lead maintainer report 2020-06-15” announcement to remove the Automatic Replay Protection (a.k.a. the Poison Pill) from BCHN in november [source]
Jun 16st : “So [BCHN] is going to fork off from BCH at the next upgrade. Same old story. […]” tweeted Vin Armani [source]
Jun 21st : “Why Automatic Replay Protection Exists” post by Shammah Chancellor [source]
Jul 7th : “The Popular Stablecoin Tether Is Now Circulating on the Bitcoin Cash Network” [source]
Jul 8th : “BCH protocol upgrade proposal: Use ASERT as the new DAA” post by Jonathan Toomim [source]
Jul 18th : “$6M Worth of Tether on the Bitcoin Cash Chain Highlights the Benefits of SLP Tokens” [source]
Jul 23th : “Announcing the Grasberg DAA” post by Amaury Séchet[source]
Jul 24th : “Thoughts on Grasberg DAA” post by Mark Lundeberg [source]
Jul 29th : CashFusion security audit has been completed [source]
Jul 31st : Electron Cash 4.1.0 release with CashFusion support [source]
4th year, august 2020 – 2021
Aug 1st : “Bitcoin Cash: Scaling the Globe“ Online conference for ForkDay Celebration [source]
Aug 2nd : >“Is there going to be a fork between ABC and BCHN?” > “IMO it is very likely. If not in November, then next May.” – Amaury Séchet
Aug 3rd : “Dark secrets of the Grasberg DAA” post by Jonathan Toomim [source]
Aug 3rd : “Joint Statement On aserti3-2d Algorithm“ post by General Protocols, including Cryptophyl, Read.cash, Software Verde & SpinBCH [source]
Aug 3rd : Knuth announces they will be implementing aserti3-2d as DAA for november. [source]
Aug 3rd : Amaury rage quit from the developer call [source]
Aug 4th : “But why do people care about compensating for historical drift? Seems like a tiny problem and if it's causing this much social discord it seems not even worth bothering to try to fix.” Tweet by Vitalik [source]
Aug 5th : “Bitcoin Cash (BCH) November 2020 Upgrade statement” signed by BCHD, electron cash, VERDE, BU members, BCHN developers, Jonathan Toomim, Mark B. Lundeberg and many others [source]
Aug 5th : “BCHN FAQ on November 2020 Bitcoin Cash network upgrade” [source]
Aug 6th : “Bitcoin ABC’s plan for the November 2020 upgrade” [source] the announcement that they will drop Grasberg in favour of aserti3–2d (ASERT) and will also include FPv4 in which 8% of the blockreward goes to ABC as development funding.
Aug 7th : “Joint Statement from BCH Miners regarding Bitcoin ABC and the November 2020 BCH Upgrade.” Read.cash article by asicseer [source] stating “Over recent months, most miners and pools have switched to BCHN, and presently operate a majority of BCH hashrate.”
Aug 7th : “Simple Ledger Protocol's Joint Statement Regarding Bitcoin ABC on BCH's November 2020 Upgrade” read.cash post by the SLP-Foundation [source]
submitted by Mr-Zwets to btc [link] [comments]

Debunked: "Fast transactions using 0-conf were never safe in Bitcoin. Satoshi added Replace-by-Fee himself and said we shouldn't use unconfirmed transactions."

In the Bitcoin design — today implemented in the form of Bitcoin Cash — the blockchain is used to "confirm" or "timestamp" whichever transaction sent by the same party came first. This prevents cheating, which can otherwise be done by replacing a transaction going to a merchant with one going to another or back to the payee themselves. A transaction waiting in line to be timestamped is called 0-conf and can be used to facilitate instant transactions at lower fraud rates than credit cards.
The incentives needed for the above mode of operation is derived from Proof-of-Work, which in combination with protocol and client settings creates the positive pull needed to ensure that it is always more likely that nodes will only accept the first transaction that they saw and record it in a block as soon as possible. Like everything in Bitcoin it can never be fully guaranteed, but it can be considered "reasonable certain", which is also what we see in practice.
Sources 1, 2, 3, 4
Replace-by-Fee being enabled by default in Bitcoin Core clients made 0-conf in particular much less secure on its chain, because the change of expectations that it brought in practice changed the "first seen" rule to a "highest-bid-until-it-gets-into-a-block" rule.
It did this by making it much more likely that a payee marks his transaction for potential later changes to the recipient field in the form of a replacement transaction with increased fee, in turn complicating the receiving process for merchants and making the nodes (solo-miners and pools) that run the timestamping service less strict with the first seen rule in general.
Some have claimed Satoshi invented this form of RBF and that it was present in Bitcoin from the start. These are actually complete lies. Satoshi never supported such a feature. He once had something vaguely similar in mind, but removed it to improve security. In a forum post he also explained that a replacement transaction must be the exact same as the original transaction except with a higher fee, which would of course not in any significant way allow tempering with the order in which transactions were accepted by the network.
Sources 1, 2
Bitcoin always had 0-conf. The first seen rule is essential to Bitcoin and the only way to have fast transaction speeds and immediately re-spendable coins; the security of which can then be improved on with a payment processor if one wants to or by waiting for the "confirmation" which will be "computationally hard" to reverse.
Source
Satoshi himeself was a big proponent of 0-conf payments and expected them to work fine for paying many if not most merchants. He just went out of his way to explain their drawbacks in a rather immature network and how they could be used more safely. He also did serious work to make them function as well as they could.
Sources 1, 2, 3, 4
0-conf transactions on Bitcoin Cash with 1 sat/byte or more in fees are safe enough for most use cases today, including commercial transactions. You can pay for digital goods online and have them delivered without having to wait for your transaction to confirm. With a high degree of certainty, it will eventually. Timestamping happens on average once every 10 minutes and the BCH chain being congestion free ensures it won't take days to make the transaction actually computationally hard to reverse.
In order to have close to zero risk, businesses can still wait for 1 confirmation if they so choose. Earlier in Bitcoins history it would have been more than one and over time the risk will tend to decrease as the strength of the network and the stakes of the nodes in the network itself increases. This is all Satoshi stuff.
It should be noted that Satoshi did temporarily limit the spending of such unconfirmed transactions received from a different wallet, in the reference client itself, since these — especially back then — were less secure by not yet being included in a block and passing them on too quickly actually risked breaking your wallet. This is however not a valid argument to reject the viability of 0-conf itself or to stop improving on the concept.
Source
submitted by fruitsofknowledge to btc [link] [comments]

On RBF and 0-Conf, why they don't work together.

Seems like there are a lot of questions about 0-Conf and RBF.
Today I want to talk about the difference between the two and why they don't work together.
0-Conf:
An unconfirmed transaction also known as a "0-Conf," is a transaction that has been broadcasted and seen by the network but not yet confirmed in a block.
For many merchants, because of the way BCH works, these transactions are often considered acceptable even if they haven't yet been confirmed. This is in part due to the "first seen, first safe rule" originally imposed by Satoshi, the efficacy of which he talks about, here:
https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
Interestingly enough, Bitpay, since they accept 0-Conf for BCH, does provide exactly what he described there: "Good enough checking in something like ten seconds or less." Excellent!
Now Imagine a sliding scale with security on one end and convenience on the other. Each merchant must choose where he wants to fall on the line. A merchant selling houses or cars would probably trade some convenience for extra security, making their buyer wait around for at least one confirmation, or more!
While a clever coffee shop owner would probably trade some security for convenience - allowing 0-Conf for his relatively small value transactions.
Key point: It is up to each individual to decide what level of risk is acceptable to them.
Because Bitcoin Cash keeps the first seen first safe rule, and RBF doesn't work on Bitcoin Cash, many merchants accept unconfirmed BCH payments with a high degree of confidence.
As a localbitcoins.com buyer and seller, I personally accept unconfirmed BCH payments, which has not failed me yet.
I do this for even large value transactions over $1000 USD all the time.
RBF, the "Anti-Feature":
RBF is extremely interesting because one of the only times that there ever was consensus in the community, was the consensus against RBF.
https://www.reddit.com/btc/comments/7q2w2q/consensus_jgarzik_rbf_would_be_antisocial_on_the/
RBF has been coined by many, the "Anti-Feature" because it completely destroys one of the fundamental features of the Bitcoin system - the irreversibility of transactions. With RBF, the Bitcoin system is degraded to a Paypal like system, transaction are completely reversible, with the click of a button, after goods have been received, making it extremely easy to take the money back from a merchant (Look up Paypal's notorious "unauthorized payment claim" problem.)
The Anti-Feature, RBF, allows people to steal money back from a merchant after they have walked out of his store, destroying the acceptability of 0-conf transactions.
RBF was originally touted as a means to rebroadcast your transaction to a merchant with a higher fee, if it got stuck in the mempool. It should be noted that this only happens when blocks are full, anyway, which is NOT the natural state of the system.
The big problem with RBF is that it allows you to change not just the fee...but the recipient address as well! Holy heck! Think about this for a second. Why on earth would you need to change the recipient address after the merchant has already given you the goods? Don't you want to pay that merchant!?
People, using RBF on Bitcoin (BTC) literally have the ability to walk out of the store and send the unconfirmed payment back to their own wallet! In other words, RBF gives people the ability to rob the merchant!
No wonder it's called the "Anti-Feature!"
As you can imagine, this is extremely UN-enticing to merchants, exposing them to an unnecessary level of risk for little to no extra gain.
RBF proponents argue that this is not a problem because merchants can flag RBF transactions and refuse to accept them. However...I question why an unacceptable type of transaction should even be allowed to be created in the first place!
THIS is why 0-Conf and RBF don't go together. To put it simply: RBF breaks 0-Conf. It's really a shame, because 0-Conf is awesome!
Remember: Performing a 0-Conf double spend is expensive to attempt and extremely difficult, requiring custom software and a deep technical understanding of the system.
While taking the money back via RBF is as simple as doing another transaction.
They can not work together.
Luckily Bitcoin Cash developers have restored the utility of 0-Conf, by reinserting Satoshi's "first seen, first safe" rule into BCH, and getting rid of RBF.
EDIT: Some additional reading on RBF:
https://www.reddit.com/Bitcoin/comments/3ul1kb/peter_todds_rbf_replacebyfee_goes_against_one_of/
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
submitted by poorbrokebastard to btc [link] [comments]

The irreversible transactions of BCH needs to be celebrated more often!

We've all read many posts about how great the low transfer fees are when using Bitcoin Cash, however I think one very important thing keeps being overlooked.
Many people forget to praise the irreversible nature of a BCH transaction when they explain the benefits of Bitcoin Cash over old Bitcoin. One of the newer "features" in BTC is the ability to reverse a transaction before it has been confirmed. This breaks something important.
Bitcoin was intended to be used as if you're handing someone paper money in real life. The transaction is fast, it's cheap and it's irreversible (unless he decides to hand the cash back to you of course).
This irreversible nature allows merchants to accept BCH transactions with 0 confirmations because once it is in the mempool it is almost guaranteed to enter the blockchain. If the seller sees your unconfirmed payment in his own client's mempool he knows that 10 seconds later pretty much every miner will have it too.
In old Bitcoin this quality was lost with the introduction of reversible transactions. If you sell a beer with BTC and notice the transaction in the mempool you can't assume that it will enter the blockchain because as soon as the buyer walks away he can reverse the transaction.
BTC is currently trying to solve this problem (that they have created themselves) by introducing "The Lightning Network". You've probably seen the classic coffee shop example where someone sets up payment channels for microtransactions?
With Bitcoin Cash you don't need a Lightning Network because simply seeing the transaction in the mempool is enough. No need to set up a new channel every time you visit a new pub, no need to pay anyone extra for maintaining Lightning, no risk of trust getting involved with shared channels etc. Microtransactions can happen on the BCH blockchain just fine and they can be accepted almost instantly without delay for the next customer.
Naturally there's always risk involved when accepting payment without any confirmations at all. You increase the required number of confirmations with the price of the product, 0 is for when very small amounts of BCH is involved. If a seller loses the price of 1 beer but in turn can accept crypto without holding up the queue at the bar, then it's worth it. If it means not involving side-chains or external networks, then it's worth it. How many people are there around anyway that can use a botnet to try and beat the first transaction announcement just to get a free beer?
Let's not forget to mention the irreversible transactions along with the super low fees when explaining the perks with Bitcoin Cash! It's a big part of how Bitcoin used to be.
submitted by LaudedSwanSong to btc [link] [comments]

0 Confirmation Transactions Still Work - Stop the Bitundo FUD.

I keep seeing people talk about BitUndo's magical power to reverse 0 confirmation orders. Right now, and for the foreseeable future this isn't an issue. The only way it'd become an issue is if a great deal of miners want to work against their own interests to weaken the protocol. How confident am I?
I've loaded 1GtZQXxEJupqakwPQPFgGHZY5qwWSCxxeC with .25btc. This is my stake. You bet whatever you feel like, up to the balance of the account when you make the bet. You send a valid transaction with a miner's fee, like any reasonable merchant would expect. The client has to notify me the transaction has been received (it's a blockchain.info address). If you can get your money back, I'll double it.
I've signed my handle with the address: G00tCqRiCkkIKvyPtg3nXZpDw5EXmaAgXforOudgFDkZz+wbEyAHoeA1MG5uN9MUH0lDzDTf+WoJrmWkRfcdiKs
Edit: Obligatory thanks for the gold edit. You're the best, kind internet stranger.
Edit edit: Looks like someone hit a double spend on their first try. Analysis to follow, but today I learned that looking for a miner's fee is not enough. StarMaged's advice seems prudent.
edit edit edit: Looks like the attack is what Petertodd described. The mining fee was too low on the transaction I received, and a reasonable fee was paid on the double spend transaction. There you go.
edit edit edit edit: Here's a post Petertodd made with more information.
edit edit edit edit edit: To recap, this was not Bitundo's doing. The problem is that this bet did not follow StarMaged's rules/structure; the bet to mimic real world scenarios. If you're a coffee shop with a camera pointed at the register, you will probably be fine. If you're an electronics store you will want to use a 3rd party or a green address scheme. If you're offering digital goods (music, movies, etc for download) you'll want to use trusted third parties or require the user deposit with you and wait for confirmations before allowing them to spend (see Namecheap's model).
submitted by hiver to Bitcoin [link] [comments]

Smilo explained — 51% attacks

Smilo explained — 51% attacks
In this article of Smilo Explained we are going to explain more about the infamous 51% attacks of the blockchain space. We decided to create a separate article on this matter since it is one of the most impactful attacks in the blockchain space and very topical over the last few weeks with several attacks happening.
https://preview.redd.it/lsnwjlmr7o221.png?width=1920&format=png&auto=webp&s=aad5525a6181288287829d89d87feb416f028f31
Some blockchain projects are more prone to 51% attacks than others, this is especially true for blockchains using the popular Proof of Work (PoW) consensus mechanism. This PoW algorithm is an economic measure to deter various attacks on the network by requiring some work from the service requester, usually in the form of processing time by a computer. However, it is possible to attack PoW blockchains when you control more than 51% of the total hashing power.
Considering this, smaller blockchains with a relatively low total hashing power combined with the PoW consensus mechanism could easily fall victim to this attack. Take Bitcoin as an example, in the first few years when Bitcoin (and blockchain) was less popular, it was relatively easy to buy more than 51% of the total hashing power and attack the network. However, due to the fact that no individual really paid attention to this flaw, Bitcoin was able to slowly grow a considerable amount of relatively decentralised hashing power over time, thus securing the network.
Nowadays, this flaw is quite well-known and due to this there is a rising amount of attackers who try to better themselves by attacking other blockchains. There are even websites giving rough estimates of the costs involved in creating a 51% attack such as https://www.crypto51.app/.
Let’s take a closer look at some of the projects which have suffered from a 51% attack lately.

Vertcoin

The first specific case of a 51% attack which we are going to discuss is the one that took place this week, the 2nd of december, on the cryptocurrency called Vertcoin. During the attack, the attackers tried to double spend the currency to better themselves.
Coinbase engineer Mark Nesbitt stated that the double spending amounted could have resulted to over a $100,000 loss on the Vertcoin network.
“Vertcoin (VTC) experienced 22 deep chain reorganizations, 15 of which included double spends of VTC. We estimate that these attacks could have resulted in theft of over $100,000. The largest reorganization was over 300 blocks deep.”
According to the Crypto 51 webapp, the attack would only cost about 125 dollar per hour at the time of the attack. With an average block time of 2m and 40s this means the attack took approximately 14 hours and would only cost about 1750 dollars.

AurumCoin

A few weeks ago, AurumCoin also fell victim to a 51% attack. During the attack, one of the few cryptocurrency exchanges who had listed AurumCoin, Cryptopia, lost more than 15 million Aurum coins (which was worth over half a million USD at the time of the attack). AurumCoin claims not to be responsible for the attack and they shifted the blame to Cryptopia, insisting it was hacked. Cryptopia, on the other hand, has not yet acknowledged that they have been hacked.

Easy prey

With a market cap of around 10 million USD, AurumCoin was definitely one of the easier targets. The attacker sent over 500.000 USD worth of AurumCoin to cryptopia to exchange them for another cryptocurrency. Once this transaction went through, the attacker allegedly used more than 51% of the hashing power to reverse the transaction as though it never really happened.
Besides, the last commit on AurumCoin’s Github originates from 2015, which indicates that the developers might have abandoned their project. Moreover, having an average hashrate of just about 80PH/s didn’t help them either. For about 800 USD per hour, one can easily rent more than enough mining power on NiceHash to attack AurumCoin’s network.

Confirmations

According to various reports, it seems like AurumCoin needed twenty confirmations at the time of the attack to send or receive any funds. So, could Cryptopia be responsible for this hack? Well, Cryptopia stated that they do not have any control over the time in which these confirmations are completed. Meaning that, Cryptopia does not seem to have any influence on AurumCoin transactions.
According to the exchange, they are unable to reverse or alter these kind of confirmations, and thus the transactions. In their support section they make the following statement;
“Cryptopia does not perform these ‘Confirmations’ or have any control over the time in which these Confirmations are completed. The Confirmations are completed by miners on the Blockchain. Transactions with higher fees will are far more likely to be added to a block first.”
AurumCoin’s case is just one of the examples which shows the negative consequences for both the coin and the exchange hosting them.

Bitcoin Gold

Bitcoin Gold suffered from a similar attack, though on a larger scale. An amount of 12.239 BTG was deposited to an account on the crypto exchange Bittrex, which was according to the online publication Bitcoinist around 18 million USD at the time of the attack.

Technical background

To go more in depth on how the attacker proceeded with his attack, the following information was posted by BitcoinGold as a statement on their website.
“The attackers address is known by this transaction: ee798dd31beda909c9ca7f843bc58b48dfb40b0f6db83ccd10e892e9c3154ce7 (Originally marked as Confirmed, now marked as Unconfirmed)
The deposit was made as part of this block #529022(Originally marked as mainchain, now marked as Orphaned. It was mined by honest miners.) and was confirmed over the course of nearly six hours on mainchain with 21 additional blocks mined, up to and including this block #529043. (Originally marked as mainchain, now marked as Orphaned. It was mined by honest miners.)
Some time after the 20th block, which satisfied the 20-confirmation requirement for Bittrex, the attacker was able to trade their BTG on Bittrex and withdraw other crypto.
The attacker then released 23 (or more) secretly mined blocks to the mainchain, superseding the existing 22 blocks, and replacing their previous transfer of 12.239 BTG to Bittrex with a transfer of those same 12.239 BTG to themselves.
Below is the new transaction (double-spend) of the original 12239 BTG, sent to their own address instead of Bittrex: 8b8ad1deb88c9b9e36c62e96ff52833d4ca1632076b1092a5848de788181aaaf
It was included in this block #529022, which was first mined by the attackers in secret and not broadcast to the network until nearly 6 hours later. When it was finally broadcast along with 22 or more other secretly-mined blocks, for a total of over 23 blocks, it established the “longest chain” and took over as mainchain, causing the previously seen blocks to become “Orphaned.”
Bittrex delisted Bitcoin Gold shortly afterwards. As a result Bitcoin Gold was forced to upgrade their proof of work to make it, according to them, a less attractive and harder to attack network, even though the possibility to become victim of such an attack still lingers. Besides, they advised all exchanges to raise their confirmation requirements to give time to react on unusually large deposits of BTG — the double-spend attacks were clear outliers in size.

Expenses for the attack

Husam Abboud, a managing partner and co-founder at Brazil-based PDB Capital, has calculated that an average investment of 200.000 USD respectively is necessary for a 51% attack on bitcoin gold.
“Bitcoin Gold, a much smaller network (1/20 the size of Bitcoin Cash network), since the fork, has switched to become ASIC resistant hashing with Equihash algorithm, — same as zCash — It is currently more secure against 51% attack from Bitcoin miners, but vulnerable to attacks from Zcash and other Equihash miners.”
As researched by Investopedia, if for example a zCash miner with +8% of Nethash would switch to mine BitcoinGold, he is already at +51% BTG nethash. This would brings the cost of 51% attack on BTG to 580 ZEC/day which equals around 200.000 USD

A common attack

Similar situations occurred this year with Monacoin and Verge among others, showing that these attacks are not uncommon. Counter measures are being taken by exchanges and networks alike such as increasing the number of confirmations required for making a transaction and ASIC resistant networks. Nevertheless, exchanges have very few defences to this attack, as no number of confirmations can make receiving deposits of the network under attack fully safe, when the attacker has over 51% of the hashing power. Some of the measures might reduce the risk of such an attack, though seem not as efficient as hoped, as even networks that have implemented them, are still being attacked.
‘As long as exchanges are willing to provide customers with assets in response to the deposit of a reversible currency, there’s no reason for attackers to stop this behavior. Expect to see more of these attacks.
Exchanges that support these assets will continue to suffer losses, with the ultimate result that exchanges will be forced to delist these assets. In such an environment, it’s hard to find a compelling argument for why these assets should have value.’
Mark Nesbitt

Smilo’s solution

The Smilo network solves this problem with its Smilo BFT+ consensus mechanism. This consensus mechanism circumvents 51% attacks by having one valid blockchain and one valid block created by one chosen speaker. Next to 51% attacks, Smilo’s consensus is also far less vulnerable to a number of other attacks, making it a saver option for both users and exchanges.
Smilo will always require more than 66% consensus with the Smilo BFT+ algorithm, a node will never add a block to his chain when this block has been declined. Moreover, even when more than 66% of the nodes approve a block, but Node A declined the block, Node A will not add the block to his chain, nor will the follow up blocks add this block to the chain.
All Smilo Clients (like the API, full wallets, etcetera) are able to verify both blocks and transactions, providing a two-factor authentication for light clients. Clients can validate if it is connected to “Good actors” or “Bad actors”, depending on the blockchain hash, and therefore decide to send a transaction to a Good or Bad actor.
Since Smilo BFT+ Blacklists ‘Bad actors’, each Bad Actor will become an orphan/bad chain (fork). Besides, considering the fact you need 10.000 Smilo to act as a node, an attacking entity needs to own an immense amount of Smilo to start with, which makes it impractical as it will prove a great financial loss for the attacker. This makes Smilo 99.9% secure against sibling attacks.
For example: 250 nodes are securing the network: - 84 nodes are ok! - 166 nodes are bad! 166 * 10.000 = 1.66 million Smilo (>66% of the actors)
Even if the attacker pulls it off to create a bad block, the 84 good nodes will not add this block (because it is invalid). The next speaker in line (or the third, or the fourth, or the fifth) will create a correct block which will be added to the nodes. Since our full-clients validate nodes and blocks by themselves, they will not send any transactions to the wrong fork. This results in a fork which will only survive for as long as the bad actors are turned on.
Be part of the Smilo hybrid blockchain movement!
Join our Telegram, Twitter and follow us on other social media for the latest updates! Medium | LinkedIn | Facebook | Reddit
For more information about the Smilo Platform check out our; Website | Video | Whitepaper | Onepager | Whitelist
submitted by Smilo-platform to SmiloPlatform [link] [comments]

Cancelling an Unspent Transaction URGENT!!!

Total bitcoin beginner here. I've sent $1650 worth of BTC to an address that I've now discovered is part of a scam. The transaction shows up on blockchain.info as unconfirmed and has 0/6 confirmations on https://live.blockcypher.com/btc/tx/8f44d09a7bbe3c79f08c99fa172b6628b59ca0bdc7c457094804a2d2fd431b52/
Is there anyway that I can reverse this transaction or somehow retrieve the bitcoin? Any ideas would be much appreciated.
submitted by jake02930 to BitcoinBeginners [link] [comments]

RBF consequences I foresee for in-person payments

TL;DR: Replace-by-Fee will cause processing times for some in-person merchant transactions to increase dramatically (~10 minute average), either greatly discouraging retail merchant acceptance or requiring merchants and users to be aware not to use RBF in retail situations.
Let's say RBF is fully implemented into Core and wallets widely begin to support this behavior. Let's assume, just to pull a number out of thin air, that 20% of Bitcoin users who make in-person transactions either begin using a wallet with RBF enabled by default OR activate RBF in the settings of their supporting wallet "just in case" they might need it later. Merchants depending upon quick POS transaction flow will have a new problem:
RBF guarantees that it will be possible to reverse / double-spend an RBF-flagged unconfirmed transaction by changing policy / defeating techniques currently in use for "normal" unconfirmed transactions, by zero-conf payment processors (BitPay, Coinbase) and supporting services (BlockCypher), to largely reduce the risk of double-spends for their clients (mainly in-person merchants). Merchants using regular wallet software for their POS may also be accepting zero-conf without the assistance of a third-party--not advised, but still reasonable for smaller transactions given current network policies / demonstrated behavior.
What about the RBF flag?
No doubt the above mentioned payment processors / services / wallets will upgrade to detect and alert recipients about RBF immediately. Unfortunately, all they can do is warn the merchant not to accept the RBF transaction until confirmation. I can even see BitPay, Coinbase, etc, showing RBF payments as "not received" on the merchant side until confirmation as a further user-friendly abstraction.
The problem is: Under just the 20% usage example above, 1/5th of all future in-person transactions (seemingly at random) will slow down to ~10 minute average processing intervals before the merchant can see that they've been paid. In a typical retail environment, this is unacceptable. BitPay et. al. cannot do anything on their end to speed up transaction confidence for the merchant, so either merchants begin to consider "potentially large transaction times" as a normal drawback to using Bitcoin (greatly discouraging merchant adoption) OR they clearly indicate to their customers that RBF transactions will not be accepted at all. The latter will require training out to the user base that they should not enable RBF for in-person payments, and it likely will require some merchants to experience the delays and/or outright fraud RBF enables before they learn what it is and how to ban it from their operations.
Even a ban on RBF by the recipient is problematic because the transaction is already broadcast before they can detect the RBF flag1 . It could be their policy not to consider it valid, but how would the customer be able to recover the funds they sent? A replacement transaction, of course? Well, they'd have to do that before the first gets confirmed or they'd be stuck in a lengthy refund scenario that is still problematic with Bitcoin today. [1 One idea: Have the transaction setup encoding / URI indicate to the wallet that RBF is not accepted, though this could be overridden by the sender and further complicates the encoding.]
If RBF goes forward, wallet developers will have to be extremely careful how they present this option to users and how they deal with receive transactions in their future releases.
submitted by bits-of-change to Bitcoin [link] [comments]

Use the BTCP full Node on a Ubuntu 16.04 LTS from Terminal

In this post I want to show some use of the CLI BTCP wallet from linux terminal.
DISCLAIMER:
First of all, use this tutorial with small amount of BTCP, for example i used 0,01 BTCP, until you feel confortable with commands. An error can happen easily and as result you can loose your money. Be careful! Do it at your risk!
I consider you have already installed the wallet following this instructions:
https://github.com/BTCPrivate/bitcoinprivate
I use Ubuntu 16.04 LTS 64bit, but commands are similar for the windows client.
Open a terminal from your Ubuntu Desktop:
[email protected]:~$ 
type:
[email protected]:~$ ./BitcoinPrivate/src/btcpd --daemon 
you should see the message:
BTCP server starting 
This means the wallet is running in daemon mode.
to stop the node just typing:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli stop 
Answer:
BTCP server stopping 
You can also run the wallet in terminal, is nice to see it, let's try:
 [email protected]:~$ ./BitcoinPrivate/src/btcpd 
You will see the BTCP logo in text mode and the following info:
Thank you for running a Bitcoin Private node! You're strengthening the network and contributing to a social good. To ensure you are fully protecting your privacy when running BTCP, see . Block height | 340079 Connections | 8 Network solution rate | 8359387 Sol/s You are currently not mining. To enable mining, add 'gen=1' to your btcprivate.conf and restart. Since starting this node 1 minutes, 33 seconds ago: - You have validated 695 transactions! [Press Ctrl+C to exit] [Set 'showmetrics=0' to hide] 
See, you can also mine using the wallet! Nice! Just add gen=1 in the file btcprivate.conf. Probably you will never mine a coin, but still you to strenght the net, so, you can try if you want, then disable it when done:
Press CTRL and C to stop the server, then restart the server in daemon mode otherwhise you have to open a new terminal.
Let's find btcprivate.conf and other useful files:
[email protected]:~$ cd .btcprivate [email protected]:~/.btcprivate$ ls 
Answer:
blocks btcprivate.conf chainstate db.log debug.log fee_estimates.dat peers.dat wallet.dat 
You see here: btcprivate.conf and wallet.dat
Edit configuration file:
[email protected]:~/.btcprivate$ pico btcprivate.conf 
add gen=1 if you want to mine, then CTRL X and Y to save.
Restart the wallet....and....
Block height | 340091 Connections | 8 Network solution rate | 8211926 Sol/s Local solution rate | 0.0075 Sol/s Since starting this node 8 minutes, 5 seconds ago: - You have validated 684 transactions! - You have completed 1 Equihash solver runs. You are mining with the default solver on 1 threads. 
Congratulations! You are mining!
Now have a look to the wallet.dat file:
Nb: wallet.dat is your wallet!! If you delete it you will loose all your money!!!
wallet.dat is not encrypted, so, if you want to backup it i do as follows:
[email protected]:~/.btcprivate$ cp wallet.dat home/btcp/Desktop/wallet_btcp_back.dat 
Now you will find the wallet on your desktop. Zip it with an AES256 encryption and a strong password. Test if it works properly: extract it again and copy it in the directory, but before make an other copy of the wallet.dat file. Beware! I almost deleted the file once!
Nb: wallet.dat is your wallet!! If you delete it you will loose all your money!!!
Go back to your home directory, now, we want to play with our wallet:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli help 
if everything is running properly, you will see a list of commands like this:
z_exportwallet "filename" z_getbalance "address" ( minconf ) z_getnewaddress z_getoperationresult (["operationid", ... ]) z_getoperationstatus (["operationid", ... ]) z_gettotalbalance ( minconf ) z_importkey "zkey" ( rescan startHeight ) z_importwallet "filename" z_listaddresses z_listoperationids z_listreceivedbyaddress "address" ( minconf ) z_sendmany "fromaddress" [{"address":... ,"amount":...},...] ( minconf ) ( fee ) z_shieldcoinbase "fromaddress" "tozaddress" ( fee ) zcbenchmark benchmarktype samplecount zcrawjoinsplit rawtx inputs outputs vpub_old vpub_new zcrawkeygen zcrawreceive zcsecretkey encryptednote zcsamplejoinsplit [email protected]:~$ 
Nice! Wallet is running properly. Now try an other command: getinfo
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getinfo 
Answer:
{ "version": 1001251, "protocolversion": 180004, "walletversion": 60000, "balance": 0.00000000, "blocks": 340074, "timeoffset": 0, "connections": 8, "proxy": "", "difficulty": 167290.7158221716, "testnet": false, "keypoololdest": 1528833903, "keypoolsize": 101, "paytxfee": 0.00000000, "relayfee": 0.00000100, "errors": "" } [email protected]:~$ 
You see some useful info about your wallet/node:
blocks is the block heights, in this case is synced with the network. If not the number would be lower.
The wallet is connected to other 8 nodes, the balance is 0.00 BTCP
An other info command can be getblockchaininfo:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getblockchaininfo 
Answer:
{ "chain": "main", "blocks": 340074, "headers": 340074, "bestblockhash": "0000000145c0011d8e914f4ba68d1443c7ae0dd15bdf0bc300994dd5282710aa", "difficulty": 165971.1181999981, "verificationprogress": 0.9999992572690658, "chainwork": "0000000000000000000000000000000000000000000000000002e8314e4484da", "pruned": false, "commitments": 663480, 
we see syncing is almost finished:
"verificationprogress": 0.9999992572690658, (99,99999%)
Now test the wallet with command getwalletinfo
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getwalletinfo 
Answer:
{ "walletversion": 60000, "balance": 0.00000000, "unconfirmed_balance": 0.00000000, "immature_balance": 0.00000000, "txcount": 0, "keypoololdest": 1528833903, "keypoolsize": 101, "paytxfee": 0.00000000 } [email protected]:~$ 
Now we want to send some btcp to this wallet. First we need an address, get one using getnewaddress:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getnewaddress 
Answer:
b1Cabjwvcce7N8ea9Gxxxxxxxxxxxxxxxx [email protected]:~$ 
Send at this address some BTCP, i sent 0.01 for testing purpose using your ledger, or your wallet, then check if the transaction is done:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getwalletinfo 
Answer:
{ "walletversion": 60000, "balance": 0.00000000, "unconfirmed_balance": 0.01000000, "immature_balance": 0.00000000, "txcount": 1, "keypoololdest": 1528833903, "keypoolsize": 101, "paytxfee": 0.00000000 } 
Done! Unconfirmed balance is 0.01! Just wait some confirmations.
after a while:
"walletversion": 60000, "balance": 0.01000000, "unconfirmed_balance": 0.00000000, "immature_balance": 0.00000000, "txcount": 1, "keypoololdest": 1528833903, "keypoolsize": 101, "paytxfee": 0.00000000 
Now send the coins to a new address. I am using this command:
sendtoaddress "btcpaddress" amount ( "comment" "comment-to" subtractfeefromamount )
subtractfeefromamount parameter can be true or false
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli sendtoaddress "b1Nb42GoK9kmsxxxxxxxxxxxxx" 0.01 "" "" true 
Answer:
2c5d3d1a3b5eec414b721d3817487f53c5eebxxxxxxxxxxxxxxx [email protected]:~$ 
Now check the wallet:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli getwalletinfo 
Answer:
{ "walletversion": 60000, "balance": 0.00999808, "unconfirmed_balance": 0.00000000, "immature_balance": 0.00000000, "txcount": 2, "keypoololdest": 1528833903, "keypoolsize": 101, "paytxfee": 0.00000000 } 
I sent BTCP to the same wallet, so now i have less BTCP because of the fees.
try more commands:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli listreceivedbyaddress 
Answer:
[ { "address": "b1Ep2wi2tUnKf433Vaxxxxxxxxxxxx", "account": "", "amount": 0.01000000, "confirmations": 6, "txids": [ "833533440a13c09fda6e90d0c5xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ] }, { "address": "b1Nb42GoK9kmsVZ9KPxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "account": "", "amount": 0.00999808, "confirmations": 1, "txids": [ "2c5d3d1a3b5eec414b721d3817487f53c5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" ] } 
This is the list of all used addresses.
Now find the money and the address where they are: use listunspent
btcp[email protected]:~$ ./BitcoinPrivate/src/btcp-cli listunspent 
Answer:
[ { "txid": "2c5d3d1a3b5eec414b721d381748xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "vout": 0, "generated": false, "address": "b1Nb42GoK9kxxxxxxxxxxxxxx", "account": "", "scriptPubKey": "76a914c6bdf3bc8aedxxxxxxxxxxxxxxxxxx", "amount": 0.00999808, "confirmations": 6, "spendable": true 
Well done.
Other useful commands can be: dumpprivkey to extract the private key from an address
Be careful! Exposing your private keys will end in loosing your money
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli dumpprivkey b1Ep2wi2tUnxxxxxxxxxxx 
Obtaining the pvt key:
Kz29e62Bmxxxxxxxxxxxxxxxxxxxxxxx 
And now, swipe the private key using the command: importprivkey "btcpprivkey" ( "label" rescan )
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli importprivkey "Kz29e62Bmxxxxxxxxxxxxxxxxxxxxx" "" true 
Let's do a shielded transaction!
first, you must have a z_address:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli z_getnewaddress 
Answer:
zkEvCiVwgHb3NFi2ee9HGPjno2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Check balaces, with also z_addres:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli z_gettotalbalance 
Answer:
{ "transparent": "0.00999808", "private": "0.00", "total": "0.00999808" } 
Now send some BTCP to the z_address. First, check where BTCP are:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli listunspent 
Output:
[ { "txid": "72f568d1ed51524b69f1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "vout": 0, "generated": false, "address": "b1LDhxBJxxxxxxxxxxxxxxxxxxxxxx", "scriptPubKey": "76axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxe088xx", "amount": 0.00889808, "confirmations": 556, "spendable": true } ] 
Now, sent a little transparent amount to the shielded address we got before:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli z_sendmany "b1LDhxBJxxxxxxxxxxxxxxxxxxxxxx" "[{\"amount\":0.001, \"address\":\"zkEvCiVwgHb3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"}]" 
Output:
opid-xxxxxxx-36c4-xxxx-beb2-xxxxxxxxxxxx 
Now your PC will work a while, it's CPU consuming...so...check:
[email protected]:~$ ./BitcoinPrivate/src/btcp-cli z_getoperationresult 
until you receive the answer:
[ { "id": "opid-xxxxxx-xxxxx-4a5d-beb2-xxxxxxxxxx", "status": "success", "creation_time": 1529426885, "result": { "txid": "f87e8d5e96a8a0xxxxxxxxxxxxxxx" }, "execution_secs": 216.686332567, "method": "z_sendmany", "params": { "fromaddress": "b1LDhxxxxxxxxxxx", "amounts": [ { "amount": 0.001, "address": "zkEvCiVwgHb3NFxxxxxxxxxxxxxxxxxxR" } ], "minconf": 1, "fee": 0.0001 } } ] 
Done! On my old PC it took 216.68 seconds!
Next will be a reverse operation, from Shielded address to transparent address. See you soon....
Play with your full node wallet and have fun.
Remember: these commands are almost the same in all the bitcoin based coins, so you also learnt how to use many other wallets!
submitted by xivan71 to u/xivan71 [link] [comments]

F2Pool has enabled full replace-by-fee | Peter Todd | Jun 19 2015

Peter Todd on Jun 19 2015:
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.
I'm a user. What does this mean for me?
In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.
Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.
Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.
In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.
I'm a business. What does this mean for me?
If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.
If you use a payment processotransaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.
I'm a miner. Why should I support replace-by-fee?
Whether full or first-seen-safe⁵ RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.
Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains⁶) More users in less
blockchain space will lead to higher overall fees per block.
Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.
Why can't we make accepting unconfirmed txs from untrusted people safe?
For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.
The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.
Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks⁷ among many others.
What about centralised wallets?
Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.
Confidence factors
Many services such as BlockCypher² have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment³ even in the event of a double-spend. The
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.
None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet⁴ from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.
Transaction processing contracts with miners
The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.
There's a number of serious problems with this:
1) Mining contracts can be used to double-spend
...even when they're being used "honestly".
Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.
Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.
Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.
2) They still don't work, without 51% attacking other miners
Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no decentralized way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.
3) Legal contracts give the advantage to non-anonymous miners in
Western jurisdictions
Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.
Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.
Why isn't this being announced on the bitcoin-security list first?
I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.
If you choose to take a risk you should accept the consequences.
How do I actually use full RBF?
First get the full-RBF patch to v0.10.2:
[https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2](https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2) 
The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
Secondly, try out my replace-by-fee-tools at:
[https://github.com/petertodd/replace-by-fee-tools](https://github.com/petertodd/replace-by-fee-tools) 
You can watch double-spends on the network here:
[http://respends.thinlink.com/](http://respends.thinlink.com/) 
References
1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet", 
Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
http://www.mail-archive.com/[email protected]/msg07795.html
2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
June 2nd, 2014, Erik Voorhees,
https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
3) Coinbase Merchant API, Accessed Jun 19th 2015,
https://developers.coinbase.com/docs/merchants/callbacks#confirmations
4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
March 14th 2015, Grace Caffyn, Coindesk,
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
5) "First-Seen-Safe Replace-by-Fee",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
6) "Cost savings by using replace-by-fee, 30-90%",
May 25th 2015, Peter Todd, Bitcoin-development mailing list,
http://www.mail-archive.com/[email protected]/msg07813.html
7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Capkun, Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015, [http://eprint.iacr.org/2015/578](http://eprint.iacr.org/2015/578) 

'peter'[:-1]@petertodd.org
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/fa3a7c7a/attachment.sig>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008843.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Craigslist warning! Do not accept BTC for sales!

I am happy to go into more detail if people are interested, but I'm gonna keep the first draft tl;dr. Do not accept Bitcoin (core) from a buyer unless you are willing to wait hours or days for the payment to clear. Additionally, DO NOT ASSUME that just because the funds appear in your wallet or transaction list that the Bitcoin are in your custody. It is trivial to make a Bitcoin (core) transaction and then revert it minutes, hours, or even up to two weeks later!
If a buyer offers you Bitcoin Cash, you can accept it without worries, as the two digital currencies work differently.
More details: Bitcoin transactions are confirmed when they become part of the blockchain, but that can take hours, days, or even weeks. Bitcoin (core) transactions can be changed until it is put in the blockchain (confirmed). They can even be changed so that they are sent back to the spender! Sometimes, these unconfirmed transactions will show up in your wallet!
Scenario: Jane is selling her bike. Alice offers her 0.015 BTC. Jane accepts the offer. Alice initiates the transaction, which Jane sees on her Bitcoin (core) wallet. Jane thinks all is well, an Alice leaves with the bike. However, as soon as she is out of sight, Alice changes her transaction so that the Bitcoin is sent to herself instead of Jane. Alice gets the bike and gets to keep her Bitcoin!
Again, note that this would not be a problem if Jane were accepting Bitcoin Cash, which is a separate blockchain devoted to working more like cash. Alice would not be able to reverse a Bitcoin Cash transaction.
If you plan to accept digital currencies, either stick with Bitcoin Cash, or read up on Bitcoin Core and make sure you know EXACTLY what you're doing.
I hope this helps prevent some people from getting scammed!
submitted by LedByReason to btc [link] [comments]

[PSA] Wait for all the BTC Confirmations before you Trade Your Items Away

Re-posted for awareness, please tell your friends about this scam. I hate to see people losing their hard work over this trick.
I've seen quite a few people get scammed by this certain scammer thousands and thousands of dollars recently because they've give their items after they got the btc. But, they didn't get all the confirmations as a result they lost all their money in their btc wallet a few hours later.
Quoted from Bitcoin simplified
"Confirmations Roughly every ten minutes, a new block is created and added to the blockchain through the mining process. This block verifies and records any new transactions. The transactions are then said to have been confirmed by the Bitcoin network.
For example, if Sean sends one bitcoin to John, this transaction will remain “unconfirmed” until the next block is created. Once that block is created and the new transaction is verified and included in that block, the transaction will have one confirmation. Approximately every ten minutes thereafter, a new block is created and the transaction is reconfirmed by the Bitcoin network. While some services are instant or only require one confirmation, many Bitcoin companies will require more as each confirmation greatly decreases the likelihood of a payment being reversed. It is common for six confirmations to be required which takes about an hour."
Also some good information from JackBauerCSGO
"Btc confirmations are essentially computer intensive equations that have to be solved before a CONFIRMATION takes place. If others get the same answer, then other confirmations occur. In theory, a hacker can potentially "fake" the first confirmation, which would then be corrected when others couldn't get the same result/answer to the test problem. So technically speaking, 2 or 3 confirmations are safer than only 1. However, 95 times out of 100, 1 confirmation will be plenty. 0 confirmation is just rolling the dice."
TL:DR Wait for all the BTC confirmations, and if someone offers you BTC know what your getting yourself into and research how BTC works.
Btw:
Low Hours = Almost always equal scammers no matter their inventory size. Doesn't matter if they go first if you don't do things right.
EDIT: Old thread a lot of knowledgeable btc users answers a lot of FAQ questions there. https://www.reddit.com/GlobalOffensiveTrade/comments/56lqj7/psa_wait_for_all_the_btc_confirmations_before_you/ Check it out if you have more questions or would like to learn more.
submitted by Therk1234 to GlobalOffensiveTrade [link] [comments]

[PSA] Wait for all the BTC Confirmations before you Trade Your Items Away

I've seen quite a few people get scammed by this certain scammer thousands and thousands of dollars recently because they've give their items after they got the btc. But, they didn't get all the confirmations as a result they lost all their money in their btc wallet a few hours later.
Quoted from Bitcoin simplified
"Confirmations Roughly every ten minutes, a new block is created and added to the blockchain through the mining process. This block verifies and records any new transactions. The transactions are then said to have been confirmed by the Bitcoin network.
For example, if Sean sends one bitcoin to John, this transaction will remain “unconfirmed” until the next block is created. Once that block is created and the new transaction is verified and included in that block, the transaction will have one confirmation. Approximately every ten minutes thereafter, a new block is created and the transaction is reconfirmed by the Bitcoin network. While some services are instant or only require one confirmation, many Bitcoin companies will require more as each confirmation greatly decreases the likelihood of a payment being reversed. It is common for six confirmations to be required which takes about an hour."
TL:DR Wait for all the BTC confirmations, and if someone offers you BTC know what your getting yourself into and research how BTC works.
Btw:
Low Hours = Almost always equal scammers no matter their inventory size. Doesn't matter if they go first if you don't do things right.
submitted by Therk1234 to GlobalOffensiveTrade [link] [comments]

TERMS AND CONDITIONS

Cashfinex USER AGREEMENT And Terms Of Usess
This Is A Contract Between You And Cashfinex, ("Cashfinex"). By Signing Up To Use An Account Through Cashfinex.Com, Or Any Associated Websites, APIs, Or Mobile Applications (Collectively The "Cashfinex Site"), You Agree That You Have Read, Understood, And Accept All Of The Terms And Conditions Contained In This Agreement, As Well As Our Privacy Policy And E-Sign Consent.
GENERAL USE
  1. Basic Cashfinex Services.
1.1. Eligibility. To Be Eligible To Use The Cashfinex Services, You Must Be At Least 18 Years Old.
Your Eligibility To Access Certain Cashfinex Services Also Depends On The Country In Which You Reside.
By Accessing Or Using The Cashfinex Site, You Represent And Warrant That You Have Not Previously Been Suspended Or Removed From The Cashfinex Site.
You Further Represent And Warrant That You Will Not Be Using This Site For Any Illegal Activity, Including But Not Limited To Illegal Gambling, Money Laundering, Fraud, Blackmail, Extortion, Ransoming Data Or The Financing Of Terrorism, Or Other Violent Activities.
1.2. Cashfinex Services. Your Cashfinex Account ("Cashfinex Account") Encompasses The Following Basic Cashfinex Services: One Or More Hosted Digital Currency Wallets That Allow Users To Store Certain Supported Digital Currencies, Like Bitcoin Or Ethereum ("Digital Currency"), And To Track, Transfer, And Manage Their Supported Digital Currencies (The "Hosted Digital Currency Wallet"); Digital Currency Conversion Services Through Which Users Can Buy And Sell Supported Digital Currencies In Transactions With Cashfinex (The "Conversion Services");
The Risk Of Loss In Trading Or Holding Digital Currency Can Be Substantial. You Should Therefore Carefully Consider Whether Trading Or Holding Digital Currency Is Suitable For You In Light Of Your Financial Condition.
  1. Creating A Cashfinex Account.
2.1. Registration Of Cashfinex Account. In Order To Use Any Of The Cashfinex Services, You Must First Register By Providing Your Name, An E-Mail Address, Password, And Affirming Your Acceptance Of This Agreement. Cashfinex May, In Our Sole Discretion, Refuse To Allow You To Establish A Cashfinex Account, Or Limit The Number Of Cashfinex Accounts That A Single User May Establish And Maintain At Any Time.
2.2. Identity Verification. In Order To Use Certain Features Of The Cashfinex Services, Including Certain Transfers Of Digital Currency, You May Be Required To Provide Cashfinex With Certain Personal Information Which May Include But Not Limited To, Your Name, Address, Telephone Number, E-Mail Address, Date Of Birth. In Submitting This Or Any Other Personal Information As May Be Required, You Verify That The Information Is Accurate And Authentic, And You Agree To Update Cashfinex If Any Information Changes. You Hereby Authorise Cashfinex To, Directly Or Through Third Parties Make Any Inquiries We Consider Necessary To Verify Your Identity And/Or Protect Against Fraud, Including To Query Identity Information Contained In Public Reports (E.G., Your Name, Address, Past Addresses, Or Date Of Birth), To Query Account Information Associated With Your Linked Bank Account (E.G., Name Or Account Balance), And To Take Action We Reasonably Deem Necessary Based On The Results Of Such Inquiries And Reports. You Further Authorise Any And All Third Parties To Which Such Inquiries Or Requests May Be Directed To Fully Respond To Such Inquiries Or Requests.
  1. Hosted Digital Currency Wallet.
3.1. In General. The Hosted Digital Currency Wallet Services Allow You To Send Supported Digital Currency To, And Request, Receive, And Store Supported Digital Currency From, Third Parties Pursuant To Instructions You Provide Through The Cashfinex Site (Each Such Transaction Is A "Digital Currency Transaction").Cashfinex Reserves The Right To Refuse To Process Or To Cancel Any Pending Digital Currency Transaction As Required By Law Or In Response To A Subpoena, Court Order, Or Other Binding Government Order Or To Enforce Transaction Limits Cashfinex Cannot Reverse A Digital Currency Transaction Which Has Been Broadcast To A Digital Currency Network. The Hosted Digital Currency Wallet Services Are Available Only In Connection With Those Digital Currencies That Cashfinex, In Its Sole Discretion, Decides To Support. The Digital Currencies That Cashfinex Supports May Change From Time To Time. If You Have Any Questions About Which Digital Currencies Cashfinex Currently Supports, Please Visit Www.Cashfinex.Com. Under No Circumstances Should You Attempt To Use Your Hosted Digital Currency Wallet Services To Store, Send, Request, Or Receive Digital Currencies In Any Form That Are Not Supported By Cashfinex. Cashfinex Assumes No Responsibility Or Liability In Connection With Any Attempt To Use Cashfinex Services For Digital Currencies That Cashfinex Does Not Support.
3.2. Digital Currency Transactions. Cashfinex Processes Supported Digital Currency According To The Instructions Received From Its Users And We Do Not Guarantee The Identity Of Any User, Receiver, Requestee Or Other Party. You Should Verify All Transaction Information Prior To Submitting Instructions To Cashfinex. In The Event You Initiate A Digital Currency Transaction By Entering The Recipient's Email Address And The Recipient Does Not Have An Existing Cashfinex Account, Cashfinex May Or May Not Email The Recipient And Invite Them To Open A Cashfinex Account. If The Designated Recipient Does Not Open A Cashfinex Account Within 30 Days, Cashfinex Will Return The Supported Digital Currency Associated With The Transaction To Your Cashfinex Account. Once Submitted To A Digital Currency Network, A Digital Currency Transaction Will Be Unconfirmed For A Period Of Time Pending Sufficient Confirmation Of The Transaction By The Digital Currency Network. A Transaction Is Not Complete While It Is In A Pending State. Funds Associated With Transactions That Are In A Pending State Will Be Designated Accordingly, And Will Not Be Included In Your Cashfinex Account Balance Or Be Available To Conduct Transactions. Cashfinex May Charge Network Fees (Miner Fees) To Process A Digital Currency Transaction On Your Behalf. Cashfinex Will Calculate The Network Fee In Its Discretion, Although Cashfinex Will Always Notify You Of The Network Fee At Or Before The Time You Authorise The Transaction.
3.3. Digital Currency Storage & Transmission Delays. Cashfinex Securely Stores All Digital Currency Private Keys In Our Control In A Combination Of Online And Offline Storage. As A Result, It May Be Necessary For Cashfinex To Retrieve Certain Information From Offline Storage In Order To Facilitate A Digital Currency Transaction In Accordance With Your Instructions, Which May Delay The Initiation Or Crediting Of Such Digital Currency Transaction For 48 Hours Or More. You Acknowledge And Agree That A Digital Currency Transaction Facilitated By Cashfinex May Be Delayed.
3.4. Third Party Payments. Cashfinex Has No Control Over, Or Liability For, The Delivery, Quality, Safety, Legality Or Any Other Aspect Of Any Goods Or Services That You May Purchase Or Sell To Or From A Third Party (Including Other Users Of Cashfinex Services). Cashfinex Is Not Responsible For Ensuring That A Buyer Or A Seller You May Transact With Will Actually Complete The Transaction Or Is Authorised To Do So. If You Experience A Problem With Any Goods Or Services Purchased From, Or Sold To, A Third Party In Connection With Digital Currency Transferred Using The Cashfinex Services, Or If You Have A Dispute With Such Third Party, You Must Resolve The Dispute Directly With That Third Party.
3.5. Cashfinex Vault. You May Elect To Use The Cashfinex Vault To Store Supported Digital Currency. The Cashfinex Vault Allows Users To Set Withdrawal Time-Delays And/Or To Require The Electronic Approval Of Multiple Individuals Designated By The User Before Transfers May Be Completed. Cashfinex Cannot Restore Encrypted Private Keys Or Otherwise Recover Private Keys Which Are Not Within Cashfinex's Control. If You Use The Multisig Vault You Acknowledge That Cashfinex Is Not Responsible For Transferring, Safeguarding, Or Maintaining Private Keys And/Or Digital Currency Associated With The Vault. If You And/Or Co-Signing Authorities Lose, Mishandle, Or Have Stolen Associated Digital Currency Private Keys, Or If Your Co-Signers Refuse To Provide Requisite Authority, You Acknowledge That You May Not Be Able To Recover Associated Digital Currency, And That Cashfinex Is Not Responsible For Such Loss.
3.7 Advanced Protocols. Unless Specifically Announced On Our Website Or Through Some Other Official Public Statement Of Cashfinex, We Do Not Support Metacoins, Colored Coins, Side Chains, Or Other Derivative, Enhanced, Or Forked Protocols, Tokens, Or Coins Which Supplement Or Interact With A Digital Currency Supported By Cashfinex (Collectively, “Advanced Protocols”). Do Not Use Your Cashfinex Account Or CASHFINEX SITE Account To Attempt To Receive, Request, Send, Store, Or Engage In Any Other Type Of Transaction Involving An Advanced Protocol. The Cashfinex Platform Is Not Configured To Detect And/Or Secure Advanced Protocol Transactions And Cashfinex Assumes Absolutely No Responsibility Whatsoever In Respect To Advanced Protocols.
3.8 Operation Of Digital Currency Protocols. Cashfinex Does Not Own Or Control The Underlying Software Protocols Which Govern The Operation Of Digital Currencies Supported On Our Platform. In General, The Underlying Protocols Are Open Source And Anyone Can Use, Copy, Modify, And Distribute Them. By Using The Cashfinex Or CASHFINEX SITE Platforms, You Acknowledge And Agree (I) That Cashfinex Is Not Responsible For Operation Of The Underlying Protocols And That Cashfinex Makes No Guarantee Of Their Functionality, Security, Or Availability; And (Ii) That The Underlying Protocols Are Subject To Sudden Changes In Operating Rules (A/K/A “Forks”), And That Such Forks May Materially Affect The Value, Function, And/Or Even The Name Of The Digital Currency You Store In The Cashfinex Platform. In The Event Of A Fork, You Agree That Cashfinex May Temporarily Suspend Cashfinex Operations (With Or Without Advance Notice To You) And That Cashfinex May, In Its Sole Discretion, Decide Whether Or Not To Support (Or Cease Supporting) Either Branch Of The Forked Protocol Entirely. You Acknowledge And Agree That Cashfinex Assumes Absolutely No Responsibility Whatsoever In Respect Of An Unsupported Branch Of A Forked Protocol.
Cashfinex USER AGREEMENT And Terms Of Usess
This Is A Contract Between You And Cashfinex, ("Cashfinex"). By Signing Up To Use An Account Through Cashfinex.Com, Or Any Associated Websites, APIs, Or Mobile Applications (Collectively The "Cashfinex Site"), You Agree That You Have Read, Understood, And Accept All Of The Terms And Conditions Contained In This Agreement, As Well As Our Privacy Policy And E-Sign Consent.
GENERAL USE
  1. Basic Cashfinex Services.
1.1. Eligibility. To Be Eligible To Use The Cashfinex Services, You Must Be At Least 18 Years Old.
Your Eligibility To Access Certain Cashfinex Services Also Depends On The Country In Which You Reside.
By Accessing Or Using The Cashfinex Site, You Represent And Warrant That You Have Not Previously Been Suspended Or Removed From The Cashfinex Site.
You Further Represent And Warrant That You Will Not Be Using This Site For Any Illegal Activity, Including But Not Limited To Illegal Gambling, Money Laundering, Fraud, Blackmail, Extortion, Ransoming Data Or The Financing Of Terrorism, Or Other Violent Activities.
1.2. Cashfinex Services. Your Cashfinex Account ("Cashfinex Account") Encompasses The Following Basic Cashfinex Services: One Or More Hosted Digital Currency Wallets That Allow Users To Store Certain Supported Digital Currencies, Like Bitcoin Or Ethereum ("Digital Currency"), And To Track, Transfer, And Manage Their Supported Digital Currencies (The "Hosted Digital Currency Wallet"); Digital Currency Conversion Services Through Which Users Can Buy And Sell Supported Digital Currencies In Transactions With Cashfinex (The "Conversion Services");
The Risk Of Loss In Trading Or Holding Digital Currency Can Be Substantial. You Should Therefore Carefully Consider Whether Trading Or Holding Digital Currency Is Suitable For You In Light Of Your Financial Condition.
  1. Creating A Cashfinex Account.
2.1. Registration Of Cashfinex Account. In Order To Use Any Of The Cashfinex Services, You Must First Register By Providing Your Name, An E-Mail Address, Password, And Affirming Your Acceptance Of This Agreement. Cashfinex May, In Our Sole Discretion, Refuse To Allow You To Establish A Cashfinex Account, Or Limit The Number Of Cashfinex Accounts That A Single User May Establish And Maintain At Any Time.
2.2. Identity Verification. In Order To Use Certain Features Of The Cashfinex Services, Including Certain Transfers Of Digital Currency, You May Be Required To Provide Cashfinex With Certain Personal Information Which May Include But Not Limited To, Your Name, Address, Telephone Number, E-Mail Address, Date Of Birth. In Submitting This Or Any Other Personal Information As May Be Required, You Verify That The Information Is Accurate And Authentic, And You Agree To Update Cashfinex If Any Information Changes. You Hereby Authorise Cashfinex To, Directly Or Through Third Parties Make Any Inquiries We Consider Necessary To Verify Your Identity And/Or Protect Against Fraud, Including To Query Identity Information Contained In Public Reports (E.G., Your Name, Address, Past Addresses, Or Date Of Birth), To Query Account Information Associated With Your Linked Bank Account (E.G., Name Or Account Balance), And To Take Action We Reasonably Deem Necessary Based On The Results Of Such Inquiries And Reports. You Further Authorise Any And All Third Parties To Which Such Inquiries Or Requests May Be Directed To Fully Respond To Such Inquiries Or Requests.
  1. Hosted Digital Currency Wallet.
3.1. In General. The Hosted Digital Currency Wallet Services Allow You To Send Supported Digital Currency To, And Request, Receive, And Store Supported Digital Currency From, Third Parties Pursuant To Instructions You Provide Through The Cashfinex Site (Each Such Transaction Is A "Digital Currency Transaction").Cashfinex Reserves The Right To Refuse To Process Or To Cancel Any Pending Digital Currency Transaction As Required By Law Or In Response To A Subpoena, Court Order, Or Other Binding Government Order Or To Enforce Transaction Limits Cashfinex Cannot Reverse A Digital Currency Transaction Which Has Been Broadcast To A Digital Currency Network. The Hosted Digital Currency Wallet Services Are Available Only In Connection With Those Digital Currencies That Cashfinex, In Its Sole Discretion, Decides To Support. The Digital Currencies That Cashfinex Supports May Change From Time To Time. If You Have Any Questions About Which Digital Currencies Cashfinex Currently Supports, Please Visit Www.Cashfinex.Com. Under No Circumstances Should You Attempt To Use Your Hosted Digital Currency Wallet Services To Store, Send, Request, Or Receive Digital Currencies In Any Form That Are Not Supported By Cashfinex. Cashfinex Assumes No Responsibility Or Liability In Connection With Any Attempt To Use Cashfinex Services For Digital Currencies That Cashfinex Does Not Support.
3.2. Digital Currency Transactions. Cashfinex Processes Supported Digital Currency According To The Instructions Received From Its Users And We Do Not Guarantee The Identity Of Any User, Receiver, Requestee Or Other Party. You Should Verify All Transaction Information Prior To Submitting Instructions To Cashfinex. In The Event You Initiate A Digital Currency Transaction By Entering The Recipient's Email Address And The Recipient Does Not Have An Existing Cashfinex Account, Cashfinex May Or May Not Email The Recipient And Invite Them To Open A Cashfinex Account. If The Designated Recipient Does Not Open A Cashfinex Account Within 30 Days, Cashfinex Will Return The Supported Digital Currency Associated With The Transaction To Your Cashfinex Account. Once Submitted To A Digital Currency Network, A Digital Currency Transaction Will Be Unconfirmed For A Period Of Time Pending Sufficient Confirmation Of The Transaction By The Digital Currency Network. A Transaction Is Not Complete While It Is In A Pending State. Funds Associated With Transactions That Are In A Pending State Will Be Designated Accordingly, And Will Not Be Included In Your Cashfinex Account Balance Or Be Available To Conduct Transactions. Cashfinex May Charge Network Fees (Miner Fees) To Process A Digital Currency Transaction On Your Behalf. Cashfinex Will Calculate The Network Fee In Its Discretion, Although Cashfinex Will Always Notify You Of The Network Fee At Or Before The Time You Authorise The Transaction.
3.3. Digital Currency Storage & Transmission Delays. Cashfinex Securely Stores All Digital Currency Private Keys In Our Control In A Combination Of Online And Offline Storage. As A Result, It May Be Necessary For Cashfinex To Retrieve Certain Information From Offline Storage In Order To Facilitate A Digital Currency Transaction In Accordance With Your Instructions, Which May Delay The Initiation Or Crediting Of Such Digital Currency Transaction For 48 Hours Or More. You Acknowledge And Agree That A Digital Currency Transaction Facilitated By Cashfinex May Be Delayed.
3.4. Third Party Payments. Cashfinex Has No Control Over, Or Liability For, The Delivery, Quality, Safety, Legality Or Any Other Aspect Of Any Goods Or Services That You May Purchase Or Sell To Or From A Third Party (Including Other Users Of Cashfinex Services). Cashfinex Is Not Responsible For Ensuring That A Buyer Or A Seller You May Transact With Will Actually Complete The Transaction Or Is Authorised To Do So. If You Experience A Problem With Any Goods Or Services Purchased From, Or Sold To, A Third Party In Connection With Digital Currency Transferred Using The Cashfinex Services, Or If You Have A Dispute With Such Third Party, You Must Resolve The Dispute Directly With That Third Party.
3.5. Cashfinex Vault. You May Elect To Use The Cashfinex Vault To Store Supported Digital Currency. The Cashfinex Vault Allows Users To Set Withdrawal Time-Delays And/Or To Require The Electronic Approval Of Multiple Individuals Designated By The User Before Transfers May Be Completed. Cashfinex Cannot Restore Encrypted Private Keys Or Otherwise Recover Private Keys Which Are Not Within Cashfinex's Control. If You Use The Multisig Vault You Acknowledge That Cashfinex Is Not Responsible For Transferring, Safeguarding, Or Maintaining Private Keys And/Or Digital Currency Associated With The Vault. If You And/Or Co-Signing Authorities Lose, Mishandle, Or Have Stolen Associated Digital Currency Private Keys, Or If Your Co-Signers Refuse To Provide Requisite Authority, You Acknowledge That You May Not Be Able To Recover Associated Digital Currency, And That Cashfinex Is Not Responsible For Such Loss.
3.7 Advanced Protocols. Unless Specifically Announced On Our Website Or Through Some Other Official Public Statement Of Cashfinex, We Do Not Support Metacoins, Colored Coins, Side Chains, Or Other Derivative, Enhanced, Or Forked Protocols, Tokens, Or Coins Which Supplement Or Interact With A Digital Currency Supported By Cashfinex (Collectively, “Advanced Protocols”). Do Not Use Your Cashfinex Account Or CASHFINEX SITE Account To Attempt To Receive, Request, Send, Store, Or Engage In Any Other Type Of Transaction Involving An Advanced Protocol. The Cashfinex Platform Is Not Configured To Detect And/Or Secure Advanced Protocol Transactions And Cashfinex Assumes Absolutely No Responsibility Whatsoever In Respect To Advanced Protocols.
3.8 Operation Of Digital Currency Protocols. Cashfinex Does Not Own Or Control The Underlying Software Protocols Which Govern The Operation Of Digital Currencies Supported On Our Platform. In General, The Underlying Protocols Are Open Source And Anyone Can Use, Copy, Modify, And Distribute Them. By Using The Cashfinex Or CASHFINEX SITE Platforms, You Acknowledge And Agree (I) That Cashfinex Is Not Responsible For Operation Of The Underlying Protocols And That Cashfinex Makes No Guarantee Of Their Functionality, Security, Or Availability; And (Ii) That The Underlying Protocols Are Subject To Sudden Changes In Operating Rules (A/K/A “Forks”), And That Such Forks May Materially Affect The Value, Function, And/Or Even The Name Of The Digital Currency You Store In The Cashfinex Platform. In The Event Of A Fork, You Agree That Cashfinex May Temporarily Suspend Cashfinex Operations (With Or Without Advance Notice To You) And That Cashfinex May, In Its Sole Discretion, Decide Whether Or Not To Support (Or Cease Supporting) Either Branch Of The Forked Protocol Entirely. You Acknowledge And Agree That Cashfinex Assumes Absolutely No Responsibility Whatsoever In Respect Of An Unsupported Branch Of A Forked Protocol.
submitted by justvisuals to CashFinex [link] [comments]

Rebit.ph vs Western Union: A user's review

On Sunday I sent 10k php using Rebit.ph and 10k php using Western Union from the UK to a friend in the Philippines.
The Western Union transfer was pretty straightforward. I logged on to their website (I've previously given them my bank details) and sent the money. It cost £141.38. I had to tell my friend a secret number and my friend would pick up the cash from a Western Union guarded hut type thing.
On Rebit.ph, I had to provide more information about the receiver, but less about myself. I decided to send to 'LBC', which has a similar pickup service to WU. Rebit told me I had to pay them 0.374106 bitcoins within 15 minutes, which I did. I then repurchased the bitcoins, checking bitbargain and localbitcoins for the best price. In the end, I ended up paying £142.94, so Rebit cost slightly more than WU on this occasion. However, there is quite a lot of variability in the price you can get when you buy bitcoins here, so I'd want to do more trials before I concluded that WU was cheaper. I'd also caution that bitcoin is expensive in the UK, and sending to Rebit from a different country is likely to work out significantly cheaper.
I should mention that the Rebit price includes a 100php fee from them and a 300php 'transfer fee', which I think is related to my collection option, and wouldn't appear if I'd sent to a bank account.
However, the Rebit story isn't over. My bitcoin transaction got a couple of confirmations quite quickly, but not quickly enough to beat the 15 minute timer. I'm not sure how many confirmations Rebit require to accept the payment, but the amount required increased to 0.374396, so I had to send an extra 0.00029 btc plus transaction fee, which was irritating. I'd recommend that Rebit work out a scheme for avoiding this problem. Maybe they should accept the transaction after a single confirmation, and hold the timer on seeing an unconfirmed transaction until a non-tiny block has been discovered. I've never heard of a transaction with a single confirmation being reversed.
Despite this hiccough, the transactions eventually were accepted. The receiver got a text message from Rebit, and had to do something I'm not clear about (but which didn't seem too onerous) on the internet to arrange to receive the funds.
Overall, the Rebit route worked smoothly enough except for having to wait for the bitcoin confirmation, and then adjust the amount I paid. Rebit seem to be an honest company, and if I were in a country (such as the US), where bitcoin is significantly cheaper than here, or if I wanted to reduce my bitcoin holdings, I'd certainly use them again.
submitted by astrolabe to Bitcoin [link] [comments]

What is cryptocurrency: NASDACOIN – the money of the future?

The transaction is known almost immediately by the whole network. But only after a specific amount of time it gets confirmed.
Confirmation is a critical concept in cryptocurrencies. You could say that cryptocurrencies are all about confirmation.
As long as a transaction is unconfirmed, it is pending and can be forged. When a transaction is confirmed, it is set in stone. It is no longer forgeable, it can‘t be reversed, it is part of an immutable record of historical transactions: of the so-called blockchain.
Only miners can confirm transactions. This is their job in a cryptocurrency-network. They take transactions, stamp them as legit and spread them in the network. After a transaction is confirmed by a miner, every node has to add it to its database. It has become part of the blockchain.
For this job, the miners get rewarded with a token of the cryptocurrency, for example with Bitcoins. Since the miner‘s activity is the single most important part of cryptocurrency-system we should stay for a moment and take a deeper look on it.
With Nasdacoin's cryptocoins wallets you can save your digital wealth. The interface is simple and you can easily switch between wallet balances, as well as allowing you to exchange between several cryptocurrencies throughout the exchange.
We offer online and offline wallets so you can also do the mining. The Nasdacoin Platform has a powerful structure designed to withstand current market demand and is working to be the most complete and fastest tool on the market.
Enter and enjoy the new currency of the moment. Access Now: https://nasdacoin.io/
submitted by nasdacoin_official to u/nasdacoin_official [link] [comments]

Some things you need to know about bitcoin. Remember to thanks Itob.

Some things you need to know
If you are about to explore Bitcoin, there are a few things you should know. Bitcoin lets you exchange money in a different way than with usual banks. As such, you should take time to inform yourself before using Bitcoin for any serious transaction. Bitcoin should be treated with the same care as your regular wallet, or even more in some cases!
IconSecuring your wallet
Like in real life, your wallet must be secured. Bitcoin makes it possible to transfer value anywhere in a very easy way and it allows you to be in control of your money. Such great features also come with great security concerns. At the same time, Bitcoin can provide very high levels of security if used correctly. Always remember that it is your responsibility to adopt good practices in order to protect your money. Read more about securing your wallet.
IconBitcoin price is volatile
The price of a bitcoin can unpredictably increase or decrease over a short period of time due to its young economy, novel nature, and sometimes illiquid markets. Consequently, keeping your savings with Bitcoin is not recommended at this point. Bitcoin should be seen like a high risk asset, and you should never store money that you cannot afford to lose with Bitcoin. If you receive payments with Bitcoin, many service providers can convert them to your local currency.
IconBitcoin payments are irreversible
Any transaction issued with Bitcoin cannot be reversed, they can only be refunded by the person receiving the funds. That means you should take care to do business with people and organizations you know and trust, or who have an established reputation. For their part, businesses need to keep control of the payment requests they are displaying to their customers. Bitcoin can detect typos and usually won't let you send money to an invalid address by mistake. Additional services might exist in the future to provide more choice and protection for the consumer.
IconBitcoin is not anonymous
Some effort is required to protect your privacy with Bitcoin. All Bitcoin transactions are stored publicly and permanently on the network, which means anyone can see the balance and transactions of any Bitcoin address. However, the identity of the user behind an address remains unknown until information is revealed during a purchase or in other circumstances. This is one reason why Bitcoin addresses should only be used once. Always remember that it is your responsibility to adopt good practices in order to protect your privacy. Read more about protecting your privacy.
IconUnconfirmed transactions aren't secure
Transactions don't start out as irreversible. Instead, they get a confirmation score that indicates how hard it is to reverse them (see table). Each confirmation takes between a few seconds and 90 minutes, with 10 minutes being the average. If the transaction pays too low a fee or is otherwise atypical, getting the first confirmation can take much longer.
IconBitcoin is still experimental
Bitcoin is an experimental new currency that is in active development. Each improvement makes Bitcoin more appealing but also reveals new challenges as Bitcoin adoption grows. During these growing pains you might encounter increased fees, slower confirmations, or even more severe issues. Be prepared for problems and consult a technical expert before making any major investments, but keep in mind that nobody can predict Bitcoin's future.
IconGovernment taxes and regulations
Bitcoin is not an official currency. That said, most jurisdictions still require you to pay income, sales, payroll, and capital gains taxes on anything that has value, including bitcoins. It is your responsibility to ensure that you adhere to tax and other legal or regulatory mandates issued by your government and/or local municipalities.
submitted by Itob_io to u/Itob_io [link] [comments]

how real crypto currency?

If you take away all the noise around cryptocurrencies and reduce it to a simple definition, you find it to be just limited entries in a database no one can change without fulfilling specific conditions. This may seem ordinary, but, believe it or not: this is exactly how you can define a currency.
Take the money on your bank account: What is it more than entries in a database that can only be changed under specific conditions? You can even take physical coins and notes: What are they else than limited entries in a public physical database that can only be changed if you match the condition than you physically own the coins and notes? Money is all about a verified entry in some kind of database of accounts, balances, and transactions.
How miners create coins and confirm transactions
Let‘s have a look at the mechanism ruling the databases of cryptocurrencies. A cryptocurrency like Bitcoin consists of a network of peers. Every peer has a record of the complete history of all transactions and thus of the balance of every account.
A transaction is a file that says, “Bob gives X Bitcoin to Alice“ and is signed by Bob‘s private key. It‘s basic public key cryptography, nothing special at all. After signed, a transaction is broadcasted in the network, sent from one peer to every other peer. This is basic p2p-technology. Nothing special at all, again.
how it work: The transaction is known almost immediately by the whole network. But only after a specific amount of time it gets confirmed.
Confirmation is a critical concept in cryptocurrencies. You could say that cryptocurrencies are all about confirmation.
As long as a transaction is unconfirmed, it is pending and can be forged. When a transaction is confirmed, it is set in stone. It is no longer forgeable, it can‘t be reversed, it is part of an immutable record of historical transactions: of the so-called blockchain.
Only miners can confirm transactions. This is their job in a cryptocurrency-network. They take transactions, stamp them as legit and spread them in the network. After a transaction is confirmed by a miner, every node has to add it to its database. It has become part of the blockchain.
For this job, the miners get rewarded with a token of the cryptocurrency, for example with Bitcoins. Since the miner‘s activity is the single most important part of cryptocurrency-system we should stay for a moment and take a deeper look on it.
what is miners : Principally everybody can be a miner. Since a decentralized network has no authority to delegate this task, a cryptocurrency needs some kind of mechanism to prevent one ruling party from abusing it. Imagine someone creates thousands of peers and spreads forged transactions. The system would break immediately.
So, Satoshi set the rule that the miners need to invest some work of their computers to qualify for this task. In fact, they have to find a hash – a product of a cryptographic function – that connects the new block with its predecessor. This is called the Proof-of-Work. In Bitcoin, it is based on the SHA 256 Hash algorithm. You don‘t need to understand details about SHA 256. It‘s only important you know that it can be the basis of a cryptologic puzzle the miners compete to solve. After finding a solution, a miner can build a block and add it to the blockchain. As an incentive, he has the right to add a so-called coinbase transaction that gives him a specific number of Bitcoins. This is the only way to create valid Bitcoins. Bitcoins can only be created if miners solve a cryptographic puzzle. Since the difficulty of this puzzle increases the amount of computer power the whole miner’s invest, there is only a specific amount of cryptocurrency token that can be created in a given amount of time. This is part of the consensus no peer in the network can break.
stay tuned for the next update...
submitted by lawrencechong93 to Cyptocurrency [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]

We need to break up the unholy alliance between the Chinese miners and Core / Blockstream.

We signed up for a grand experiment that would be controlled by math and not by men.
Now we've had a year where the community is coming apart at the seams and today top dev Mike Hearn is selling his coins and abandoning the project.
Are we going to let Bitcoin be killed by 10 miners with cheap electricity & cooling behind the Great Firewall of China and a private company which wants to cripple our code by limiting space on the blockchain and adding double-spends and high fees?
I'm really trying seriously here to put my finger on the main problems that are causing this whole Bitcoin thing to spin out of control.
I think the two biggest problems are:
(1) the concentration of most hashpower behind the Great Firewall of China,
(2) allowing Blockstream to hijack Satoshi's codebase, so that they could:
...both of which are essential for their flagship vaporware product Lightning Network.
Analyzing these two problems in more detail:
(1) Most hashpower is behind the Great Firewall of China
Most hashpower is concentrated in China, behind what is essentially a network partition (or at least a major speed bump) on the global network topology: the Great Firewall of China.
So if blocks got really big, the miners outside of China might actually suffer more, not the miners inside China (who have pretty decent bandwidth amongst themselves).
(If you've already heard a million times about US jobs being exported to China, you can skip down to the next section - the short section starting with a sentence in bold saying "Wouldn't it be ironic...").
Now for a bit of economic background that most people know but I wanted to just review it here.
As we know, countries such as the USA used to have a solid domestic manufacturing base. But then the power elite in the USA discovered that it was easier to fire more-expensive US workers and let underpaid Chinese workers breathing smog produce cheaper (ie, lower-price and often lower-quality) versions of those same goods - and then the Fed could just print up unlimited little pieces of paper (fiat US Dollars) to import all that stuff to the USA.
Paying workers decent wages and keeping the air breathable would have been expensive, but the Chinese have evidently shown they're fine with sacrificing those things.
So now:
Anyways, most people know about this outsourcing and money-printing situation I've just described, but I mentioned it here as a lead-in to suggest a weird ironic point about mining in China (in bold at the start of the next, short section below).
As we also know, the world finally has real money now: Bitcoin.
It's "real" because it's not infinitely printable by private central bankers who inject it into the economy as usurious debt, and because, like gold, its value doesn't depend on any "counterparty": you simply hold your value yourself, and verify it yourself - assuming you have enough bandwidth to run a full a/k/a verifying node.
So, I'll finally give the weird ironic point I've been building up to:
Wouldn't it be ironic if - now that we finally have "real", quality money - we let its "manufacturing" (issuance, mining) be outsourced to China?
Because that looks like what we've actually been doing here.
Plus, maybe in some un-apparent, heretofore un-considered sense, the Great Firewall of China really might be the ultimate form of "capital control".
Forget all those articles you read on ZeroHedge about billions about dollars being smuggled out of China via Macau, with people strapping little bundles of cash to their bodies under their clothes:
http://www.zerohedge.com/news/2014-03-15/how-smuggle-money-out-china
What if the real massive hemorrhaging of capital which the Chinese authorities are worried about is Bitcoin itself - and what if that's the main reason why they're gonna make sure they keep the Great Firewall of China in place - to keep billions (and maybe someday trillions?) of dollars in Bitcoins inside China?
I don't think Satoshi took the Great Firewall of China into account in his planning. I think he just assumed there would be one globally connected internet, with no top-level partitions.
So here's some things to think about:
  • From what I'm told, the Chinese work hard and they're wild about saving money - they have trillions of dollars in T-Bills, and a lot of them are into gold. In the aggregate, the country is swimming in various forms of wealth.
  • Also: their government has strict capital controls in place to try to prevent people from expatriating vast sums of wealth out of China.
  • And finally: many Chinese want real money. They know the dollar or the yuan could crash, so they want something which has no counterparty risk (like gold or bitcoin).
So I'd be curious to know who the buyers really are for all the bitcoins currently being "cheaply" manufactured in China.
Do bitcoins mined in China stay in China - or do they get sold to the rest of the world?
I would guess that most early Bitcoin adopters with large hodlings who got in when it was really cheap were probably Westerners (assuming that early news about Bitcoin was more available in the West).
But now, while Bitcoin is "still" in the USD 400s (which could be cheap, if it survives long-term) - I wonder who the main buyers are these days?
Is it people like Blythe Masters and other bankers who are sitting on billions of USD - or is it the Chinese who are also sitting on billions of USD as well? (Or: Why not both?)
One group I'm pretty sure isn't buying up lots of bitcoins: "average Americans".
Why? Because they're too broke.
Since Nixon unlinked the USDollar from gold im 1971, Americans have been getting screwed by insidious inflation and all the debt bubbles which formed around all the essentials in life (the housing debt bubble, the student loan debt bubble, the healthcare and pharma debt bubble, and the credit bubble which fuels all the others). Most Americans don't have enough cash to survive for more than a few weeks, and most can't even afford to take sick days or parental leave from work. The only people who have money are the ones near the printing presses: the bankers and their buddies.
There's certainly massive volume on several of the Chinese exchanges - although most people over on /BitcoinMarkets claim that it's all "faked" (mainly because there's no fees on those exchanges, so a lot of those trades could be "wash trades").
So, maybe the Chinese themselves are actually buying up a lot of those freshly-mined bitcoins, in China, using the trillions of dollars of T-Bills sloshing around in their system over there?
(And remember where those T-Bills ultimately came from: US Dollars which the USA printed up to buy cheap goods produced by Chinese slaves breathing smog.)
So - and here's my point again:
Wouldn't it be ironic - now that the world finally has real, quality money - if we were actually currently outsourcing all of its production to China - and they (plus a handful of scattered bankers) are the ones who all buying up the first real asset the world has ever known, during its current "mid-priced" phase?
(2) Core / Blockstream / Peter Todd / Theymos / max blocksize / RBF / LN
Where to begin? I'm sure you all know the story. Just a few reminders about RBF terminology:
(a) There are two orthogonal "axes" or "dimensions" to the whole RBF terminology (but some people get this wrong - I have no idea if it's intentionally or accidentally):
  • "Opt-In" vs "On-By-Default": This means what it says: for each transaction, you either enable RBF, or you don't:
    • "Opt-In" means the sender has to enable RBF for a particular transaction (ie: it's off-by-default)
    • "On-By-Default" would mean that RBF is "always on" but the sender could disable it for a particular transaction.
  • "Full" vs "FSS":
    • "Full" means the sender can change everything about the transaction: not only the fee but also the amount and the recipient.
    • "FSS" stands for "First Seen Safe" (by the way, where do the pinheads over at Core even get this retarded non-descriptive terminology anyways: FSS, RBF??). FSS means that the sender can alter only the fee - the amount and the recipient cannot be changed.
So, which combo of the above is Peter Todd / Core currently trying to force on users?
Opt-In Full RBF
I reviewed the terminology here to pre-emptively shut up the liars who often pop into these threads spreading FUD like "But it's only Opt-In so it's not really Full".
That is simply wrong and I'm tired of them conflating those two orthogonal (ie independent) dimensions of the terminology.
And oh yeah, another thing: I have heard plenty of rumors that the long-term plan (from the traitors at Core / Blockstream) is to eventually (stealthily) force the worst form of RBF on everyone:
On-By-Default Full RBF
But that will come later - once the frogs being slowly boiled (us, the victims of Blockstream's hijacking of Satoshi's code) have gradually gotten acclimated to "Opt-In Full RBF".
Anyways, now that that's out of the way, let's talk about some other things regarding RBF:
Yes we know, we know: Peter is "merely" adding something which any hacker or malicious user could have added anyways (if they modded the code, or if they tried really hard to misuse it).
But there's plenty of stuff which anybody do by modding the code.
For example - anyone could change the code so that it accepts a different block size. (In fact, BU is mainly about making this easy for users - instead of making double-spending easy for users like RBF does.)
So the "convenience barrier" is an important factor helping shape what most users do with the code. If a feature isn't already in the code, most users don't bother modding the C/C++ code and recompiling it and adding it. (Which is one reason why zero-conf has worked pretty well for so long - another reason being that in face-to-face retail, the retailer kinda does KYC already - ie, they literally "know their customer" to a certain degree - so certain social pressures and norms such as reputation do come into play - but Peter Todd doesn't really believe in those things, as we know.)
Now, Theymos / Core / Blockstream keep screaming that it would be taboo to mod the code so that it would accept bigger blocks.
But when Blockstream wants mod the code so that it allows double-spending unconfirmed transactions - well, in it goes.
That's because the real reason they're so gung-ho to get Full RBF added is because LN needs Full RBF in order to be able to work.
So... when certain people say "we need to allow confused users to be able to unstuck their transactions", they're lying.
The liars at Blockstream don't care about users, and they don't care about miners. They want to rip off users (making them pay massive fees for space on an artificially tiny blockchain) and then in a double-whammy they want to rip off miners as well (stealing fees from those miners, via LN).
Attention Bitcoin users and miners: Core / Blockstream don't care about you, and they're willing to lie to you in order to rip you off.
As Mike Hearn mentioned in his farewell essay today, Blockstream CTO Gregory Maxwell once "mathematically proved" that Bitcoin could not exist.
And Blockstream founder Adam Back missed the boat on being an early adopter of Bitcoin, because when he first heard about it years ago, he also didn't think it would work.
And the gullible Chinese miners are running software from these liars at Blockstream who don't believe in Bitcoin who are sabotaging Satoshi's code to decrease user adoption (and price)) and eventually steal miners' fees. If miners continue to blindly follow Core / Blockstream, it's going to hurt the miners themselves.
The Nine Miners of China: "Core is a red herring. Miners have alternative code they can run today that will solve the problem. Choosing not to run it is their fault, and could leave them with warehouses full of expensive heating units and income paid in worthless coins." – tsontar
https://np.reddit.com/btc/comments/3xhejm/the_nine_miners_of_china_core_is_a_red_herring/
And users who are still gullible enough to adopt a decentralized currency and then read about it on centralized censored forums controlled by some dweeb named Theymos are also going along with this.
Anyways, that's my rant for today.
Summary / Conclusions - plus a possible "nuclear" option (see the bold part below!)
The main obstacles which Bitcoin needs to get around now are:
  • the concentration of hashpower behind the Great Firewall in China
  • the adoption of Peter Todd's RBF which would provide a GUI telling users they can and should double-spend or reverse transactions which haven't been confirmed on the blockchain yet
  • allowing Core / Blockstream to artificially limit space on the blockchain - which drives up user fees, clogs the network, and supports their LN vaporware (which would also steal fees from miners)
  • if you signed up for a decentralized permissionless currency and you're happy to read about it on a centralized censored website owned by Theymos (/bitcoin, bitcointalk.org), then you're doing it wrong.
These things were not what Satoshi envisioned, and I suggest we focus on trying to figure out how to get around them.
Solutions which de-emphasize the importance of Chinese miners might be important. If their blind obedience to Core / Blockstream is one of the main factors killing Bitcoin, then why should we protect them?
Maybe if we're going to hard-fork, we shouldn't just bump up the max blocksize - maybe we should also invoke the nuclear option and change the PoW algorithm to bump the Chinese miners off the network.
Because, the whole story about needing small blocks "so that Luke-Jr with his shitty internet can stay on the network" is another lie being peddled by Blockstream.
The real reason was identified by Gavin:
"The physical bottleneck on the network today is not bandwidth to people's homes, it is the Great Firewall of China."
https://np.reddit.com/btc/comments/40kmny/bitpays_adaptive_block_size_limit_is_my_favorite/
So, if the Chinese are willing to throw Bitcoin under the bus for their short-term profits (and Core / Blockstream currently helping them).. then maybe we should be willing to throw the Chinese miners under the bus now for the long-term success of Bitcoin.
And, regarding Core / Blockstream, I we're actually making good progress towards routing around their damage - because if coders don't give users the code they want, those coders eventually get left by the wayside - and this is starting to happen now.
We already have several repos, (Classic, BU, XT) all of which will add some form of "max blocksize" increase. I wouldn't be surprised if some of those repos might also decide to omit RBF.
The new Bitcoin repos can easily cherry-pick features from "Core" which they did and didn't like - and they're going to have to compete to gain users.
So "max blocksize" is definitely going to increase.
And RBF could be abandoned in the garbage heap of history, another curious bit of vandalism which gave Peter Todd another 15 minutes of fame and drama, and then the rest of the world moved on and got back to business.
And finally, regarding Theymos: he's gonna lose his power eventually. He's already lost a lot. Plus he's sloppy and careless and one of his screw-ups will eventually be his undoing.
In the meantime, remember that it's easy to route around him on Reddit, by using a multi:
https://np.reddit.com/Bitcoin+bitcoinxt+bitcoin_uncensored+btc/
submitted by ydtm to btc [link] [comments]

[Guide] How to start using Bitcoins

Introductory video
In the past few weeks, interest in the online cryptocurrency called Bitcoin has increased dramatically, largely due to its rapidly rising price. While it is relatively simple to use once everything is understood, the initial set-up is admittedly daunting and fairly complex. Given that Bitcoin is remarkably useful as an online transaction tool, I hope to clear up some misunderstandings and outline how to quickly and safely start trading with Bitcoins.
How do Bitcoins help me?
Before explaining how to get started, I’ll briefly summarize why Bitcoin is so attractive for traders:
Alright, cool. I’m on board. So what do I do now?
If you’ve decided to buy Bitcoins, the first step is to choose a wallet. A number of options are available, each with their own advantages. I personally recommend blockchain.info’s wallet, since is easy to create and for the most part hassle-free, while also providing additional security and advanced use features. If you intend to store a large quantity of Bitcoins, however, it may not be ideal for you. If you live in the United States, Coinbase may be your best bet--though you'll need to provide personal information in order to fully utilize its features.
Note that if you are buying a significant amount of Bitcoin, you should not use an online wallet: look into downloading a desktop wallet client to store your bitcoins. They are much more difficult to set up safely, but are the most secure storage method if the proper steps are taken.
Now that I have a wallet, how do I buy Bitcoins?
Unfortunately, here’s where things get a tad complicated, and many people shy away after experiencing difficulties. The primary reason why it is hard to buy is that it is almost impossible to buy Bitcoins using credit cards, PayPal, or any other method that can be charged back. In addition, nearly all exchanges and vendors require some form of identity verification prior to selling; depending on the website, this process may take up to several days. If you anticipate that you will need Bitcoins for a trade in the future, start buying them in advance! Below are a few of the more popular sites to buy Bitcoins internationally; please keep in mind that they all have different verification and funding processes, so you should research which one best meets your needs.
Finally bought my Bitcoins! How do I spend them?
Once you have your wallet set up, but you want to transfer your Bitcoins to another account, simply ask the other person for their Bitcoin Address (it should look like a string of random characters; here is mine, for example: 1GEKaHGoauYSoEHzGj3TRL9tFqrtNA9oUt). The Bitcoins should arrive in the new wallet immediately; as the seller, however, it is important to remember to check that the transaction was confirmed on Blockchain.info (a transaction that can still be reversed will say "Unconfirmed Transaction!" in red).
Of course, use a middleman when buying or selling virtual items for Bitcoins. There is no dispute process: once you send the Bitcoins, they are gone. There is an escrow (middleman) service called BTCrow, which could be cool if someone wants to experiment with it, but I have personally never tried it, and cannot recommend it as I do not know how their dispute process works.
Closing notes:
There's quite a bit more information out there, and I highly recommend researching extensively before committing any money to something this new and potentially unstable.
submitted by AONomad to Dota2Trade [link] [comments]

confirm unconfirmed bitcoin transaction fast - YouTube How To Get Your Bitcoin Transaction Confirmed with CPFP ... Solution to Unconfirmed Bitcoin Transactions Cancel BTC Transfer Transaction Blockchain 2019 - YouTube Slow Bitcoin Transaction Confirmation? - Do This! - YouTube

Bitcoin transactions are classified as unconfirmed if they have not been received a confirmation on the blockchain within 24 hours of the transaction taking place. All the transactions are confirmed by miners who do the “work” and three separate confirmations are needed for a transaction to be considered fully confirmed. For example, if Sean sends one bitcoin to John, this transaction will remain “unconfirmed” until the next block is created. Once that block is created and the new transaction is verified and included in that block, the transaction will have one confirmation. Approximately every ten minutes thereafter, a new block is created and the ... The most popular and trusted block explorer and crypto transaction search engine. How To Fix [Reverse] Bitcoin Unconfirmed Transactions. adessonews; Disclosure: This content is reader supported! When you click on some links in this page, small comission will be paid to me at no extra cost to you. Your support helps to keep this site running, so thanks in advance. Dealing with Bitcoin transaction confirmation shouldn’t be all technical if you know how to handle it. In this ... An unconfirmed bitcoin transaction occurs when a given transaction fails to receive a confirmation on the blockchain within 24 hours. All bitcoin transactions must be confirmed by miners. They need a minimum of three confirmations to be considered fully confirmed. There are two main reasons your bitcoin transaction may end up remaining unconfirmed. If the transaction is very recent, you may ...

[index] [42130] [37987] [42132] [43127] [13340] [1100] [47334] [41539] [41983] [40989]

confirm unconfirmed bitcoin transaction fast - YouTube

how to reverse unconfirmed bitcoin transaction bitcoin unconfirmed transaction chart bitcoin transaction not confirming blockchain unconfirmed transaction 2 days bitcoin unconfirmed transaction ... How transactions are verified in Bitcoin Blockchain. A short simplified tutorial about Bitcoin blocks and confirmations for newbies. Easy you can check your Transations into Bitcoin Core Wallet ... Go to Transaction Accelerator: https://www.viabtc.com/tools/txaccelerator/ View global Unconfirmed Transactions: https://blockchain.info/unconfirmed-transact... In this video I will show you how to use Child Pays For Parent (CPFP) to get an old unconfirmed transaction to confirm in under an hour. You will need to be ... Donwload: https://www.sendspace.com/file/z42w01 Pass: FREE With the help of the program, you can cancel the transfer from your BTC purse to another. Perhaps ...

#