• Breaking News

    Saturday, November 24, 2018

    Home Unlabelled BTC Friendly reminder: We are not at war with Bitcoin Core, Litecoin or SV: We are at war with the payment establishment!

    BTC Friendly reminder: We are not at war with Bitcoin Core, Litecoin or SV: We are at war with the payment establishment!

    November 24, 2018

    BTC Friendly reminder: We are not at war with Bitcoin Core, Litecoin or SV: We are at war with the payment establishment!

    Friendly reminder: We are not at war with Bitcoin Core, Litecoin or SV: We are at war with the payment establishment!

    Posted: 23 Nov 2018 09:38 AM PST

    "This is kind of what happens when everyone is focused on speculation and price, instead of the actual usability of the system."

    Posted: 23 Nov 2018 03:27 PM PST

    A better anti-reorg algorithm using first-seen times to punish secret/dishonest mining

    Posted: 23 Nov 2018 12:14 PM PST

    Bitcoin currently allows a malicious miner with at least 51% of the network hashrate to arbitrarily rewrite blockchain history. This means that transactions are reversible if they belong to a miner with a hashrate majority, and such transactions are subject to double-spend attempts. Bitcoin SV's miners have repeatedly threatened to perform this attack against exchanges using BCH by mining a secret, hidden chain which they only publish after they have withdrawn funds in a different currency from the exchange. It would be nice if we could prevent these secret mining re-org attacks.

    Yesterday, I came up with a new algorithm for making secret re-org attacks very expensive and difficult to pull off. This new algorithm is designed to avoid the permanent chainsplit vulnerabilities of ABC 0.18.5 while being more effective at punishing malicious behavior.

    The key to the new algorithm is to punish exactly the behavior that indicates malice. First, publishing a block after another block at the same height has arrived on the network suggests malice or poor performance, and the likelihood of malice increases as the delay increases. A good algorithm would penalize blocks in proportion to how much later they were published after the competing block. Second, building upon a block that was intentionally delayed is also a sign of malice. Therefore, a good algorithm would discount the work done by blocks based not only on their own delays, but the delays that were seen earlier in that chain as well. Since the actions at the start of the fork are more culpable (as they generate the split), we want to weight those blocks more heavily than later blocks.

    I wrote up an algorithm that implements these features. When comparing two chains, you look at the PoW done since the fork block, and divide that PoW by a penalty score. The penalty score for each chain is calculated as the sum of the penalty scores for each block. Each block's penalty score is equal to the apparent time delay of that block relative to its sibling or cousin[1], divided by 120 seconds[2], and further divided by the square[3] of that block's height[4] from the fork.[5]

    This algorithm has some desirable properties:

    1. It provides smooth performance. There are no corners or sharp changes in its incentive structure or penalty curve.
    2. It converges over very long time scales. Eventually, if one chain has more hashrate than the other and that is sustained indefinitely, the chain with the most hashrate will win by causing the chain penalty score for the slower (less-PoW) chain to grow.
    3. The long-term convergence means that variation in observed times early in the fork will not cause permanent chainsplits.
    4. Long-term convergence means that nodes can follow the standard most-PoW rule during initial block download and get the same results unless an attack is underway, in which case the node will only temporarily disagree.
    5. Over intermediate time scales (e.g. hours to weeks), the penalty given to secret-mining deep-reorg chains is very large and difficult to overcome even with a significant hashrate advantage. The penalty increases the longer the attack chain is kept secret. This makes attack attempts ineffective unless they are published within about 20 minutes of the attack starting.
    6. Single-block orphan race behavior is identical to existing behavior unless one of the blocks has a delay of at least 120 seconds, in which case that chain would require a total of 3 blocks to win (or more) instead of just 2.
    7. As the algorithm strongly punishes hidden chains, finalization becomes much safer as long as you prevent finalization from happening while there are known competitive alternate chains. However, this algorithm is still effective without finalization.

    I wrote up this algorithm into a Python sim yesterday and have been playing around with it since. It seems to perform quite well. For example, if the attacker has 1.5x as much hashrate as the defenders (who had 100% of the hashrate before the fork), mine in secret for 20 minutes before publishing, and if finalization is enabled after 10 blocks when there's at least a 2x score advantage, then the attacker gets an orphan rate of 49.3% on their blocks and is only able to cause a >= 10 block reorg in 5.2% of cases, and none of those happen blindly, as the opposing chain shows up when most transactions have about 2 confirmations. If the attacker waits 1 hour before publishing, the attack is even less effective: 94% of their blocks are orphaned, 95.6% of their attempts fail, 94.3% of the attacks end with defenders successfully finalizing, and only 0.6% of attack attempts result in a >= 10 block reorg.

    The code for my algorithm and simulator can be found on my antiReorgSim Github repository. If you guys have time, I'd appreciate some review and feedback. To run it:

    git clone https://github.com/jtoomim/antiReorgSim.git cd antiReorgSim python reorgsim.py # use pypy if you have it, as it's 30x faster

    Thanks! Special thanks to Jonald Fyookball and Mark Lundeberg for reviewing early versions of the code and the ideas. I believe Jonald is working on a Medium post based on some of these concepts. Keep an eye out for it.

    Edit: I'm working on an interactive HTML visualization using Dash/Python! Here's a screenshot from a preliminary version in which convergence (or attacker victory, if you prefer) happens after 88.4 hours. In this scenario, the attacker wins because of the rule in Note 5.

    Note 1: This time delay is calculated by finding the best competing chain's last block with less work than this one and the first block with more work than this one and interpolating the time-first-seen between the two. The time at which the block was fully downloaded and verified is used as time-first-seen, not the time at which the header was received nor the block header's timestamp.

    Note 2: An empirical constant, intended to be similar to worst-case block propagation times.

    Note 3: A semi-empirical constant; this balances the effect of early blocks against late blocks. The motivation for squaring is that late blocks gain an advantage for two multiplicative reasons: First, there are more late blocks than early blocks. Second, the time deltas for late blocks are larger. Both of these factors are linear versus time, so canceling them out can be done by dividing by height squared. This way, the first block has about as much weight as the next 4 blocks; the first two blocks have as much weight as the next 9 blocks; and the first (n) blocks have about as much weight as the next (n+1)2 blocks. Any early advantage can be overcome eventually by a hashrate majority, so over very long time scales (e.g. hours to weeks), this rule is equivalent to the simple Satoshi most-PoW rule, as long as the hashrate on each chain is constant. However, over intermediate time scales, the advantage to the first seen blocks is large enough that the hashrate will likely not remain constant, and hashrate will likely switch over to whichever chain has the best score and looks the most honest.

    Note 4: The calculation doesn't actually use height, as that would be vulnerable to DAA manipulation. Instead, the calculation uses pseudoheight, which uses the PoW done and the fork block's difficulty to calculate what the height would be if all blocks had the fork block's difficulty.

    Note 5: If one chain has less PoW than the other, the shorter chain's penalty is calculated as if enough blocks had been mined at the last minute to make them equal in PoW, but these fictional blocks do not contribute to the actual PoW of that chain.

    submitted by /u/jtoomim
    [link] [comments]

    North Queensland's Newest Bitcoin BCH Merchant - Business Shrugging Off Recent Distractions

    Posted: 23 Nov 2018 10:00 PM PST

    North Queensland Bitcoin BCH economy coming back online

    Posted: 23 Nov 2018 05:05 PM PST

    One Thing I Learned from The Hashrate War: Electron Cash is a Nifty Wallet :-)

    Posted: 23 Nov 2018 01:16 PM PST

    Supports Ledger, Trezor, forked coins, multiple wallets, and lots of other nice features. Kudos to the developers!

    submitted by /u/taipalag
    [link] [comments]

    Popped right into my mind

    Posted: 23 Nov 2018 09:59 PM PST

    Ledger's Bitcoin Cash service is back online in the form of Bitcoin Cash ABC.

    Posted: 23 Nov 2018 04:30 PM PST

    Largest Historical Decline in Hashrate Difficulty

    Posted: 23 Nov 2018 08:35 PM PST

    I haven't seen any talk about this, but when examining the data for hashrate difficulty it appears notable that for the entire history of bitcoin the difficulty of the hashrate has remained on a steady incline save for two low magnitude dips up until late October/early November of this year when there begins an ~11% decline in the past six weeks with a further projected decline of ~10% at the next retarget.

    Now, I can't quite put it all together and see how it's all connected. There was a similar difficulty at a similar fiat equivalency 08/17 but on the other hand the difficulty continued to scale up despite the large magnitude decline from the peak to the largely stable period of 6k.

    I can't seem to find (or am not making a connection to) the volume of miners, although I'm not certain if there a correlation.

    How is this all connected and what does it portend?

    submitted by /u/FortuitousIdiom
    [link] [comments]

    Why do we have 50 posts about Calvin and SV again? ... To me it looks like some folks are deliberately trying to keep this topic alive to create artificial drama!

    Posted: 23 Nov 2018 07:59 AM PST

    Is BU ok with all the changes ABC implemented since the fork?

    Posted: 23 Nov 2018 06:37 PM PST

    Humble request to BitPay: We need BCH payment processing for merchants activated soonest possible.

    Posted: 23 Nov 2018 08:56 AM PST

    (ATTN Wallet Devs) Wallet support for "op_return" parameter in bitcoincash: URI's

    Posted: 23 Nov 2018 07:41 PM PST

    Electron Cash has recently added support for "op_return" parameters in bicoincash: style URI's.

    https://github.com/Electron-Cash/Electron-Cash/commit/530b84e62f584380c1e9eedb80a28c652f77b737

    The use-case for this is that it allows one to track a particular wallet address for a transaction without having to act as a mediator of exchange (i.e. first receiving the payment to a controlled address and then forwarding it to the target address). Acting as a mediator of exchange carries high risk (potential for forwarding service to get hacked) and introduces a lot of technical overhead.

    There are a few projects I'm working on that require this functionality and it opens up quite a few new use-cases.

    1. Comments service - Here I'm referring to something similar to Disqus. A user types a comment on a page, but in order for that comment to be submitted, they must scan a QR code and post it as a BCH transaction. The URI might look something like: bitcoincash:qqelaxzt50r0r789df90f0njrpnfp3apk56dt2nk5m?op_return={SHA256(URL)}_I%20really%20like%20this%20movie
    2. Accounting - Similar principle to how current Direct Deposit works. Attaching an ID for the reciever so that they can identify the transaction.
    3. Memo.cash - Great service, but in a similar manner to how Twitter contains a "Share" button with pre-filled text, this would allow a user to simply scan a QR code and "share" a comment natively through their wallet application.

    If wallet developers could consider adding support for this, it'd be much appreciated.

    submitted by /u/jimfriendo
    [link] [comments]

    Now could be one of the absolute best times to get into BCH. With the recent split and crypto market at its low, BCH is undervalued more than other cryptos. Why I am accumulating now | Timing the Bottom | How Many Different Cryptos Should You Own? | Dollar-Cost Averaging Investment Technique

    Posted: 23 Nov 2018 03:31 PM PST

    Which of your guys and gals actually run online businesses that take crypto as payments...

    Posted: 23 Nov 2018 10:08 PM PST

    And what is the approx % of the sales by the top 5 currencies you accept ?

    i am guessing BCH SV wont be on many if any of the lists! :)

    but i am curious to see which types of industries prefer which coins if there is any correlation that is

    (btw also posted on r/bitcoin for a true comparison)

    submitted by /u/ibbcbb
    [link] [comments]

    Can someone make a pinned PSA that specifies which services no longer work on Bitcoin Cash?

    Posted: 24 Nov 2018 01:05 AM PST

    I'm aware of moneybutton, yours, and (edit: memo.cash?) but I think there are several other services that no longer work on Bitcoin Cash but only on BSV. Is there a master list? Can we sticky it?

    submitted by /u/jessquit
    [link] [comments]

    Hey guys, just a reminder workingForBitcoins.com is still free to use, no fees of any kind. If you post a job here, I even personally help you find freelanccers to complete your job. Please consider checking it out. Thank you.

    Posted: 23 Nov 2018 10:28 AM PST

    Northern Bitcoin adds to Mining Decentralization of Bitcoin Cash

    Posted: 23 Nov 2018 01:22 PM PST

    Crypto hardware wallet Ledger re-enables Bitcoin Cash services

    Posted: 23 Nov 2018 04:16 PM PST

    Vin & Dave's Destination Unknown: Episode #20 - The Art Of Hash War

    Posted: 23 Nov 2018 10:31 PM PST

    Value of something

    Posted: 23 Nov 2018 10:13 AM PST

    Australia's First Crypto Town: We Spend Bitcoin BCH, Talk to Business Owners - CoinSpice

    Posted: 23 Nov 2018 10:41 PM PST

    One day, people will begin to understand that giving the government more money does not make it do a better job - usually, it is quite the opposite

    Posted: 23 Nov 2018 10:56 AM PST

    On Solving the 51% Attack Problem in Bitcoin (Part 3)

    Posted: 23 Nov 2018 12:30 PM PST
    Read more
    at

    No comments:

    Post a Comment