Bitcoin Forum
October 21, 2018, 07:29:21 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 »
1  Alternate cryptocurrencies / Altcoin Discussion / The 0% PoS attack - possible? on: March 14, 2016, 09:38:25 AM
Why isn't this possible in a PoS system with bonded stake?

1. Short the coin
2. Pay 100% of on-line stakers to transfer their stake to themselves in one common block (12 o'clock midnight, for example)
3. The chain auto DoSes itself as no blocks get produced until the stake bonds again post transfer
4. Profit

How extensive is this damage? Can the chain recover at all since no blocks can be produced?
2  Bitcoin / Development & Technical Discussion / The timely confirmation incentive in a system with no mining rewards on: March 09, 2016, 11:28:59 AM
A consensus design which doesn't offer a mining reward is attractive in theory, because it prevents the system from centralising due to the compounding profits of the best miners.

In a consensus design utilising PoW with no mining reward (neither block reward nor fees) - is the incentive for timely confirmation enough to guarantee convergence of the system as a whole? Is timely confirmation even well defined in a system with no competition to mine?

The timely confirmation incentive is supposed to encourage the system to converge by having its participants build off the block/transaction with the best score - the idea being that if everybody does this, the chain selection rule will select in favour of them and their transactions will be confirmed more quickly than if they chose any other location to build their blocks.

This is all well and good except for the adversary problem. With no competition to mine, the maximum network hashing rate will be impossible to measure, since although transactions may be incoming at a high rate in a mature currency (and assuming a PoW must be submitted with the transaction) , this rate could still be vastly below that of even just one ASIC* such that any adversary looking to double spend would find the task relatively easy.

This also brings into question the entire way in which transaction acceptability can be bounded. In bitcoin the adversary's hashing power relative to the network as a whole is considered, yielding a probability of the best block being reversed, yet with no competition to mine, the maximum hashing rate of the network as a whole cannot be measured since adversaries have nothing to gain by participating in the network's nominal operations, instead they might chose to lie in wait.


*) AntMiner S5+ rated at 7,722,000Mh/s, compared to Xeon Phi 5100 rated at 140Mh/s is 55,000 times faster
3  Alternate cryptocurrencies / Altcoin Discussion / [ETH] Possible miner attack angle? on: March 05, 2016, 10:22:43 PM
Anybody know if this attack is possible in ethereum?

1. Miner creates a contract with a really, really high gas charge
2. Withdraw from an exchange wallet to the contract address
3. Miner mines the block, collects the gas
4. Repeat

4  Bitcoin / Development & Technical Discussion / Proof that Proof of Stake is either extremely vulnerable or totally centralised on: March 01, 2016, 09:51:48 AM

This is an very informal proof, because I wanted it to be as readable as possible for the majority of readers. I hope this will finally show why Proof of Stake (PoS) is not a viable consensus design.

This particular attack is called 'keys from the past', or the 'history attack' and is endemic to the design of PoS.

Recap of Proof of Stake

PoS requires bonded stake in order to generate a block. The more bonded stake, the higher the probability you can generate a block and this probability is linear in stake and is also a constant over any amount of time. It is possible for a majority stake holder to have a 100% probability of generating every block; this is something like 33% of all stake. The attack works like this:

The attack

1. The attacker simultaneously purchases a majority of old staking private keys, which were very recently used to stake with and are now empty and as such valueless to the seller(s)
2. He uses these historical keys to generate a new chain of history starting just before the keys were emptied and which is longer in cumulative difficulty than the canonical chain. He can do this first time with 100% probability since he has a majority of historical stake
3. He can then either steal the coins back to himself and carry on, or can bring the entire chain to a total halt by excluding all transactions.


By taking out a massive short on an exchange before he carries out this attack, he can make it even more profitable. He can also hold the chain to ransom by excluding transactions at will, or by charging extra fees to include them.


It doesn't even matter if the chain itself has a re-org depth limit because it is quite possible that he can generate this new history in under the limit of the reorg depth. Even if he can't, it doesn't matter because all syncing nodes will be vulnerable to accepting his fake history as genuine and since impersonating a general network node has ~0 cost, he can impersonate a majority of nodes such that any syncing node querying at random will find his fake nodes with fake history. Given sufficient time, his history becomes canonical.


The only mitigation for this attack is to enforce checkpoints from some trusted location. At this point, the currency has totally ceased to be decentralised, since the consensus result has been reduced to a consensus of one, which is the same as having no consensus at all. This is the antithesis of decentralisation.


The cost of this attack is very low since empty private keys have no value. All PoS chains are vulnerable to this attack because the cost of block production is close to zero, which is the chief reason this is possible. A reorg depth limit is ineffective at preventing this attack for the reasons described.
Checkpoints completely fail to be decentralised or trustless in any way; the network of nodes are reduced to simple database replication slaves in a system with far higher cost and inconvenience, lower performance and the same level of security as a centralised service.
5  Bitcoin / Development & Technical Discussion / Mining subsidy in a DAG on: February 09, 2016, 06:16:54 PM
I've noticed both public designs for a DAG were careful to avoid a mining subsidy. I'd like to discuss why this was the case, and if there would be any way around the problem.

One argument is that is rewarding every node in the DAG creates an incentive to widen the DAG; but I'm not entirely clear why this must be the case.

In bitcoin there is an incentive to mine on the best block of the chain, because you stand a greater chance of having your block orphaned by the majority hash rate if you do not.

Why can't the same be true for a DAG?
6  Bitcoin / Development & Technical Discussion / Branching-hard PoW? on: January 25, 2016, 11:57:31 AM
Branches are notoriously slow on GPU, and cost silicon space on ASIC chips, so if there was a PoW which required a lot of branches and which couldn't be simplified by using memory tables and precomputions, this would seem like a good alternative to memory-hard PoW.

Has there been any research into PoW algorithms which are branching-hard?
7  Alternate cryptocurrencies / Altcoin Discussion / Free transactions, spam, block reward and confirmation times on: January 17, 2016, 06:40:15 PM
Iota will be the first coin to have free transactions (that I know of). This discussion is not specifically about Iota, but relates to all coin's with 0 transaction fees and no block reward.

They prevent spam by requiring a Proof of Work (PoW) with each transaction. But, how will they set the difficulty of the PoW such that it actually prevents spam, but doesn't cause mobile devices to drain their battery?

If they set it to (for example) 1ms worth of generation, then a spammer can send 1000 spam transactions per second, which is clearly unacceptable. If they set it to 250ms, a spammer can only manage 4 spam transactions per second, but does this have a big negative impact on battery life for mobile devices?

In addition, a block reward provides a useful metric for when a transaction is safe to spend; in bitcoin, I need wait only 1 block to accept up to 25 BTC sent to me because any rational double spend attack is unprofitable up to that amount, since the attacking miner might as well take the block reward instead. However, in a PoW coin with no block reward and no fees what can we use as a similar metric for when to accept a transaction?
8  Alternate cryptocurrencies / Altcoin Discussion / Turning POW on its head on: December 19, 2015, 08:41:00 PM
Warning half baked ideas incoming:

The problem with consensus design in pseudonymous systems is sybil attack. You can't just have your nodes vote for transactions and weight by most signatures because creating multiple identities is trivially easy, such that a single individual can own multiple identities and therefore have a voting monopoly.

So, what if creating identities was not trivially easy? What if creating an identity was very hard indeed, and required expending a tremendous amount of POW effort?

In such a system miners would not generate blocks at all, but identities. Generated identities would then be able to vote on transactions, to include in blocks, with the weight of the vote being the amount of work which went into producing the identity. Identity generation would have a difficulty exactly like standard POW chains.

This would allow the block production to be decoupled from the POW solution generation, allowing for much quicker confirmations.

Of course, this does present a bit of a significant barrier to entry for the curious user, who might very well need to pay 25 BTC for an identity from a miner.

Anyway, that's about the size of it. Love to hear feedback and criticisms on whether this actually can decouple the block generation from the POW while maintaining comparable security of plain POW chains.
9  Alternate cryptocurrencies / Service Announcements (Altcoins) / [ANN] Metaexchange fee sharing! on: November 27, 2015, 10:56:52 AM
Hi everyone,

Metaexchange is the most innovative instant bitcoin exchange, so far we have processed 2963 BTC across 5 markets and we are the first and only instant exchange to offer limit orders, and the only instant exchange with integrated market makers to offer you the best prices.

We are now offering a chance to share in our success: METAFEES!

The METAFEES asset represents the fees we generate from running metaexchange. Our fees will be divided between the number of METAFEES which sell. For example, If there were 100 METAFEES sold in total, those 100 shares will get 50% of the fees we generate between them. There are 10000 for sale and 2000 are held by monsterer and shentist and backed with the already existing liquidity of 40 BTC. We hope to raise 200 BTC in total, pricing each share at 0.02 BTC.

We will buy back the METAFEES asset monthly with 50% of our collected fees on the open market, thereby raising the value of asset.

The first buy back already occured, you can read about it here:,20150.0.html

The fundraiser will run for a further 28 days, we have sold just under half of the METAFEES already.

How to buy

1. Create a Bitshares account, you can do so without installing any software, just go to the Bitshares web wallet ( and create an account, take note of your account name, come back here and purchase in any of the markets we offer, linked below. Or you can download the wallet ( and create an account if you prefer that option.

2. Buy METAFEES with BTC here:
Buy METAFEES with ETH here:
Buy METAFEES with NXT here:
Buy METAFEES with BTS here:

3. Note

The price of METAFEES in each market is calculated to have the same value as if you purchased from the BTC market. We have multiple markets to buy from because we have multiple market makers in metaexchange - for example, if you buy METAFEES using BTS, you will contribute toward ours BTS/BTC market.

To date we have processed 2963 BTC of transactions, resulting in fees of 8.9 BTC and we expect this to increase dramatically as we add extra liquidity, more markets, Bitshares UIA coin tokens and margin trading.

With only 40 BTC of bootstrapped liquidity we made trading fees of 8.16 BTC, so we're very excited about what we can do with 200 BTC!

Every month we will place market buy orders on the Bitshares DEX (where METAFEES trades) - we will buy back in BTC, NXT, ETH etc. This will lead to a constant buy pressure for the METAFEES asset, raising its value.

Our plans
We will use the funds raised only to increase the liquidity in the markets that we offer and to add new Bitshares UIAs representing each of the coin types we support, such as Bitcoin, Ethereum and Nxt, to give you a chance to trade these tokens on the Bitshares DEX with full redeemability to the real thing. So each METAFEES purchase that you make furthers Bitshares itself as well as metaexchange. Further, we will add Bitshares DEX market markers (using our propitiatory technology) to these new UIA token markets adding the liquidity that traders demand. For example we will create (BTC, NXT, ETH and any new coin we provide as an UIA) along with a market maker in the primary BTS market for each one.

We aim to become the number one instant exchange. We will achieve this by offering the best available liquidity in the markets we serve, combined with ground breaking features. We are already the only instant exchange in the world to offer limit orders and relative limit orders without requiring an account or registration.

In the future we plan to offer leveraged margin trading, which will allow anyone posting collateral to go long or short on their favourite coin with leverage without requiring an account. The funds we raise will allow us to achieve this by lending out our liquidity to margin traders, for a small lending fee (which will be paid, in part to holders of METAFEES) and our standard trading fee.

We will also share 50% of the fees we generate through UIA trading, any withdrawal fees, and Bitshares referrals.

Our main competition is who recently raised 1.2M in funding for 30% of their business, valuing them at 4M. They work using the reseller model, buying their inventories from major exchanges after each trade. This model relies on the liquidity of the exchanges they use and also has the associated counterparty risk of having a float in the exchange's wallet. Metaexchange works by making markets - we are a liquidity provider and as such, have the potential to offer far superior spreads without the associated counterparty risk.

As with any fund-raiser, there is associated risk. Particularly with digital currency services, the risk of being hacked is the primary concern. We use best practices in security, particularly with site/wallet separation and server hardening and have a running $500 bounty available for any discovered exploit. Even so, this risk is still present. Also, the regulatory environment could change unfavourably towards crypto-currency only exchanges. There is also market making risk; if our losses from market making exceed the amount we charge in fees, there will be a gap in fee payments.
If for any reason, metaexchange shuts down, we will use our liquidity pool to buy outstanding METAFEES back.


We make no guarantee about the future value or returns related to the METAFEES asset and all purchases are at the buyers risk. This is not an investment proposition, or a binding contract. We are not liable for any losses incurred, direct or indirect by participating in this fundraiser.

Any questions, please post them here, thanks for reading!

10  Bitcoin / Development & Technical Discussion / bitcoin core RPC compatible lite wallet proxy? on: October 31, 2015, 03:56:43 PM
Is there a bitcoin core RPC compatible lite wallet available which proxies onto a full node for the data?

Use case: multiple merchant wallets, one blockchain, one API on one machine without having to duplicate the blockchain.

I have a full node running, which is great, but I need multiple wallets... Having lite wallet(s) which would get their data from my full node would be awesome and not have any of the trust issues a lite wallet would normally have.

I don't want to have to implement another RPC wrapper, so this needs to be compatible with the core RPC API.

Cheers, Paul.
11  Alternate cryptocurrencies / Altcoin Discussion / Is centralisation unavoidable? on: October 19, 2015, 10:05:48 AM
Is it possible that centralisation is unavoidable?

In any system where there are gains to be made by specialising, the rational behaviour is to specialise. The best performing specialists dominate by outcompeting their competition.

This is true in nature, in businesses, in criminal organisations. But is it unavoidable?

The few with the most hashing power dominate in POW, the few with the most stake dominate in (D)POS. In both these cases there is disproportionate power available to those who dominate. This is at odds with the principle of security through decentralisation.
12  Bitcoin / Development & Technical Discussion / Why are transaction malleable in the first place? on: October 16, 2015, 09:55:28 AM
Dumb question, but why is it possible to change somebody else's transaction in any way? Shouldn't the entire contents of the transaction be signed in some way?
13  Bitcoin / Development & Technical Discussion / Reducing the orphan rate to 0 in a >100k TPS chain on: September 17, 2015, 03:08:23 PM
There are two main reasons we get orphaned blocks in blockchains:

1) N miners simultaneously solve a POW for a block, each submitting a new block with the same parent (which is what causes the fork)
2) Double spend attempts

1) occurs because we have linked list of blocks
2) occurs because of fraud, or broken wallets

Simply using a DAG instead of linked list (and one transaction per block) will improve the orphan rate because the number of allowable DAG heads is greater than 1, but this is still not optimal, since the orphan rate will only reduce by a factor of the number of heads.

Optimally (for orphan reduction), each unspent output is a DAG head. If you and only you can mine your own transactions, you can never get an orphaned block (except in the case of a double spend). This would lead to maximum possible transaction throughput.

The huge problem with this is that once you do this, you completely lose the chain of consensus, because you can't build on someone else's UTXOs. The question, then, is this: is there another way around this? Can you do something like have a parallel consensus chain consisting of only major miners collecting only the block reward and doing no transaction verification, or bundling. Then, when a transaction is sent, it is built referencing the best block of the consensus chain?

14  Alternate cryptocurrencies / Altcoin Discussion / Why Proof of Burn cannot work cleanly in practice on: September 17, 2015, 11:09:18 AM
Over the last few days I've been musing about a consensus design involving Proof of Burn (, whereby participants in the consensus process burn currency in competition for the block reward. In theory this has the same properties of Proof of Work, except that you can burn currency infinitely quickly, so block times would be fast.

However, I have come to the conclusion that this cannot be done cleanly. Rather than throw away all the work, I think it's informative to share my reasoning and conclusions here.

Here is the spec for design A, which attempts to mimic POW as closely as possible:

* participants P burn coins to compete for block reward
* once sum of coins burnt from burn transactions not yet in a block >= block reward the block closes
* the probability of any P winning the block reward is how much they burnt divided by the total amount burnt by all participants
* the hash of the block is used as a random number seed to decide which P wins the block reward
* in the case of multiple winners, only the highest burn winner receives the block reward
* in the case of no winners, the block is reopened and the round restarts
* the chain with the most burn is always selected in the case of forks
* a transaction is confirmed when it is buried under a equivalent amount of burn

It has the nice property (at first glance) that no double spend is profitable once the transaction is confirmed, because an attacker would need to burn an amount of currency equal to the transaction size in order to get a double spend confirmed.

There are two three major problems with this first design:

1) Randomness (or entropy) in a p2p system is bounded by the data present in the chain. What this means is that (at the very least) an attacker can know ahead of time whether he will win the block reward, because he has all data necessary to compute the result of the random function, no matter what components he is required to use. He can then chose not to participate if he will lose.

Simply adding a small POW to this random number generator would increase the entropy, but unless the difficulty of this POW is at maximum network difficulty, you can still sybil attack this result by precomputing many such POW and picking the most favourable and at this point you're basically doing full POW anyway, so POB becomes pointless.

2) Finney attack. It is completely trivial for an attacker to generate an infinite sequence of valid blocks in which he is the solo participant and is also the winner. Since the chain is ordered by maximum burn, this makes any double spend profitable because he can simply dump a massive pile of finney blocks on the fork containing his double spend. Using block timestamps to discard quickly submitted blocks is not a viable solution, since timestamps in a p2p system are unreliable.

3) Making the block reward equal to the burnt amount makes this functionally equivalent to Proof of Stake for the case of the single miner. However, if you don't make the block reward at least equal to the amount burnt, it is not profitable to mine.

You can try to work around these two three issues by using external randomness and trying to use a combination of POW and POB to reduce the finney probability, but these are not clean solutions IMO.

Cheers, Paul.
15  Alternate cryptocurrencies / Altcoin Discussion / Do unforgeable p2p random numbers rely on max difficulty POW? on: September 10, 2015, 08:07:17 AM
I've been musing about various different (non POW) consensus design mechanisms and have come across the need to use random numbers in order to select the winner of a block reward.

However, it strikes me that using something like the block hash or any other combination of things any given node could generate when attempting to submit a block would be subject to forgery - the node picks a particular hash, or combination of hashes which produce a winner for the random number generator.

Then I thought about including a small POW to make forging harder, but it then struck me that unless the POW is at maximum difficulty, this would only reduce the forgeability (since you could sybil attack it with many results if the POW was easy enough) not prevent it.

So, the question is: do unforgeable, node side random numbers rely on POW at maximum network difficulty? How do POS chains deal with this?
16  Alternate cryptocurrencies / Altcoin Discussion / Fixing ripple and other byzantine agreement models in the face of sybil attacks on: September 07, 2015, 12:42:47 PM
Byzantine agreement models generally work under the conditions that the number of byzantine failures is less than N, such as (N-1)/3, where N is the number of byzantine nodes.

Unfortunately, although these models do hold under that many 'disagreements' between consensus nodes, the actual cost of disagreeing is zero, so you can easily have the case where N is mostly nodes under the control of a single individual, hence the sybil attack and why most of these models are not generally trust-less.

There are also long range attacks possible whereby a node which is syncing with the network (which is no different to any other node at any time) has no chain selection rule with which to autonomously pick the correct fork to sync with, should it be presented with counterfeit chains.

I propose the following solution to the problem, taking ripple's ledger close consensus as an example:

1) The RNL is discarded completely, nodes participate in a trust free manor
2) Nodes continue to vote for transactions in the closing ledger, but they do so by solving a POW for each transaction
3) Transactions have a cumulative difficulty target, and so does the ledger as a whole, transactions are added to the closing ledger when their target is reached, and the ledger closes when it's overall target is reached
4) Add a chain selection rule which takes the chain with the most amount of work
5) Difficulty adjusts based on network participation
6) Optionally add a voting reward to incentivise participation

This already sounds very like how POW chains work. The main difference is that you can get immediate feedback on transaction confidence, since votes will stream in continuously for transactions (depending on how long it takes to solve a POW vote, of course) while the ledger is being 'closed'. Of course, a 'closed' ledger can still be replaced by one in a chain of greater work, but arguably that is even easier to achieve using trust based byzantine models, when that trust is broken.
17  Bitcoin / Development & Technical Discussion / Is there a way to make a double spend more expensive? on: September 07, 2015, 09:03:42 AM
In POW a double spender must wait until a merchant accepts his initial payment (at 1 confirmation, say), and then outpace the network to produce a longer fork and the cost is linear in the number of blocks.

Is a way to increase this cost somehow, to make it quadratic, or higher order in the number of blocks?
18  Bitcoin / Development & Technical Discussion / Towards more consistent block times on: September 03, 2015, 04:33:57 PM
What if blocks contained a set of N hashes which must be found where the difficulty of finding each one is the full difficulty / N?

That way, the law of averages should come into play leading to more consistent block times overall.
19  Alternate cryptocurrencies / Altcoin Discussion / Consensus survery on: September 02, 2015, 10:02:44 AM
Would be nice to get a list of the various consensus mechanisms, with links to papers... I'll start:





Please post your links and I'll keep this main post updated...
20  Economy / Service Announcements / ETH/BTC (Ethereum) market added to! on: August 14, 2015, 09:59:10 AM
Hi guys,

I've just added Ether to

Great for arbitrage, because we only have a 5 confirmation delay on Ether unlike polonix/shapeshift which has 720!

We are an instant exchange featuring limit, market and relative limit orders, all with no registration required!

Come give us a go!

Cheers, Paul.
Pages: [1] 2 3 4 5 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!