The proposed solution doesn't give the website any means to verify that coins were received before delivering the goods or services. So you would have to query your node for this.

No. No relation. I was unaware when I created my accounts that there was an infamous "cypherdoc". I would have likely chosen a different name or at least capitalized differently if I had realized that.

Hmm, I know this is your favorite topic, but can you please agree on the minor point that your original comment with gavin's email was not in the form of a commit message, even if it was only briefly in this original form before being edited?

The evidence is still here: https://ceddit.com/r/btc/comments/5g3weu/blockstreams_creator_changes_bitcoin_network/

Also since it was, for however brief a time, not in the form of a commit message, you may not want to rely on that so forcefully as somehow validating that the comment should be allowed. Sorry if I can't let that go.

To help convince you I'm acting in good faith here, look at this little discussion with BitcoinXio on the most recent suspension where I both confronted him on his lame accusations and revealed that he doesn't know that the report button on reddit comments can alert reddit admins directly. Which by the way might have been what happened. Might not have been rbtc mods, but I can't tell either way.

If everything is in one data center then there may only be one entry/exit point for all data. If someone were to infiltrate the main router or other network appliance there, then they can remove packets inbound from certain IP addresses and block outgoing packets to some IP addresses. Hence communication disruption. So it is just easier when there is one data center and fewer things to infect/control.

Think like Stuxnet or something.

In separate data centers??

Hmm, was sort of hoping some other folks would take a look. That is why I started the thread, wanted to see if I was missing or misinterpreting something. If you are just going off of my summary, regurgitation, then something could be missed. Please review the source material if you can.


Well for bitcoin, this would might mean at least a 20 minute delay for 1 confirmation. "20 minute" because if you are splitting the hash rate pretty evenly then sending your merchandise transactions to one side, then on average it would take 20 minutes for 1/2 the hash rate to mine one block. So that is a 20 minute "delay". I would call it a 20 minute disruption. But let's not get caught on semantics unless I'm misunderstanding something.



Someone familiar with mining pools should be able to answer this. If indeed remote miners (outside of the pool's network) are contributing to a pool, who announces the found block to the bitcoin network? It is the mining pool isn't it? I don't think the individual miners even know what transactions are included, they are using the block header only. So centralized mining pool is what announces the found block. Correct?

Yes the attack still may be difficult. We must take 4 mining pools, allow them to connect to each other's nodes (or get blocks over relay network), but prevent them from reaching other nodes (or getting relay network blocks) that are connected to the other side. Because mining pools are centralized in one geographic area (China) this would seem to make the task somewhat more feasible. Still a challenge no doubt.

If you look at this hashrate chart, you can see that by just targeting the 4 largest pools you could split the hashrate into 2 equal groups. So much easier than splitting internet in half. Now still there is the requirement of isolating a merchant node, so that it is only seeing blocks from one side. But problem seems halfway solved with 4 pool attack.
http://i.imgur.com/iebKjrg.png

I think the point is that it would work with great certainty if you are able to achieve the requirements (insert long delay/disruption between 2 groups of miners and isolate a merchant node to one side). In fact given a long enough time period the certainty approaches 100%.


Yeah that is the entire point, of the attack.

Anyway, my questions surrounding this attack are:

* Why does the paper call for making an even split between 2 groups of miners, as it's starting point? Wouldn't any division 10%/90% work just as well if you were able to isolate a merchant to the 10%?
* Does this paper highlight anything new? (it seems obvious that comm disruption between groups will cause chain separation and removing disruption will cause one chain to get orphaned).
* For blockchains like Ethereum with short times between blocks I guess the term "delay" is appropriate, but really we are causing a complete comm disruption, for the time under which the attack takes place, between the groups, no?

Any thoughts on this paper https://arxiv.org/pdf/1612.09426.pdf ?

It describes a "Balance Attack" against bitcoin and ethereum where you split the miners into 2 equal groups by causing a communications delay between them. Then you mine with one group while submitting transactions (for merchandise, services, etc) to nodes connected only to the other group (and you can send same coins to yourself on your mining branch). When the communications delay is lifted the chain being worked on by the group you were mining with should be longer than the other group's chain, so consensus will then cause your spent merchandise transactions to get undone, while spends to yourself from your mined chain will persist. Thus a double-spend.

Authors were focused on Ethereum and private R3 implementation but they also think their work extends to Bitcoin as well.

Why do miners have to be evenly split to start with?  Also, they use "communications delay" but for bitcoin, this would be more of a disruption between the 2 groups right? Also the need to isolate the node you are purchasing goods from to one side.

So definitely a few challenges pulling it off. Still with small number of mining pools controlling most of hash rate, it doesn't seem crazy that they could be split into 2 groups.

I'm just 'catching up' with POS so apologies in advance.

For #1, if I mine on one fork, doesn't that fork immediately become the one that will get most likely get accepted by the network? If so why even bother with mining on both?  Unless of course my blocks are getting delayed in the network so much that there is risk another POS miner would be selected due to some timeout, then it might make sense to mine on multiple forks in the hope that one of those blocks makes it to the rest of the network in time. But with proper timeouts, this seems unlikely. Plus don't some proposals punish this multiple fork mining behavior?

For #2, when is this attack used, during initial block download? Is the idea to use this stake to try to perform a stake grinding attack in advance and send those blocks to a syncing node instead of real chain?

For #3, I can't obtain access to 50% of coins without exchanging for other tokens, fiat or goods/services can I (with the exception of #2)? Those are sunk costs that I can't recover if I cause problems with POS chain.

Speaking of malleability, I assume that the wtxid doubleSHA256([nVersion][marker][flag][txins][txouts][witness][nLockTime]) is now malleable but that is handled appropriately? Not sure if BIP 147 was meant to address part of this issue.

Don't forget, every soft fork changes the consensus rules. For instance we could soft fork to make the max block size 500kb. We can soft fork, to make it impossible for un upgraded nodes to validate transactions but have them still think they are valid.

Only transactions that are in a block on the blockchain are permanent (and really only for sure if there are a few blocks on top of the block the tx is in). So when you broadcast a transaction it does not go immediately into a block. It sits in what is called the mempool of bitcoin nodes that receive that broadcast. Only later when the transaction has been put into a block and the block has been broadcasted and accepted by the network does the transaction become fixed and typically after a few blocks have been made on top of that block do we consider it permanent and irreversible.

Technically this is incorrect. Blocks produced by non updated Miners will be forked if they come after 95% blocks are updated to new version. New nodes will not accept these blocks, old nodes will.

From the BIP:

So if 5% of the miners don't upgrade, and produce a block (which will have nVersion<5), non-updated nodes will accept that block, but updated nodes will not. Once this happens, non-updated nodes will only accept new blocks from the 5% since the 95% will not be building off that
EDIT:
amaclin corrected me below, no hardfork because, duh, old nodes will still see blocks from the 95% as valid, so even if they receive a 5% block first, the 95% will quickly build a longer valid chain, thus 'orphaning' this 5% block. So no fork really just orphaned/stale blocks. 5% miners will lose money though in wasted electricity and no block rewards.

Yes I don't dispute this. But what is unclear is if adding additional "network only" nodes (is "relay nodes" a better term?) improves that situation.

For example how do SPV wallets determine what nodes they get information from? Do they always connect to the same one? Is it random and they get messages from many nodes (from the whole network??)? If they get messages from many nodes then having more network nodes (and assuming the majority are honest nodes) somewhat increases the security of SPV wallets.

If you have more info on how SPV wallets get their info (typically from one node or whole network?) then that might help. I'm not that familiar with SPV wallet protocol.

But there are no SPV "nodes" in this scenario. There are SPV wallets connected to a full node (and lets assume it is one they trust or have some control over for now), there are mining full nodes, and there wallets with nodes running on same machine.


But any full node (mining, wallet node) then would reject it.

Anyway I don't really doubt you are correct. This has always been my assumption and part of why I run a full network node myself. However I see things like https://twitter.com/adam3us/status/683678942398644224 and it makes me wonder (note: vps nodes worth zero), whether my assumption is flawed.

Maybe you could point me to some more info on how the checkpoints and forking issues you mentioned. Have there been any simulations done for this, or detailed write-ups on the exploits? On the one hand, yes it seems fairly obvious that full nodes improve security. On the other hand if everyone with a wallet is already directly connected to a full node, then it is less clear how the exploits progress.


This part makes sense. As well as your comments about the government shutdown.

Maybe a more technical way of phrasing the question is: what is the minimum number of network nodes needed to protect against current known attacks?

Lots of people are running full nodes that are not used for mining, not using a bitcoin core wallet with it, and not using an SPV wallet linked directly to that node. In other words it is a network node (is there another name for this?) that validates transactions and validates blocks, and interacts with other network and non-network nodes.

Are these needed? How do they improve overall security of bitcoin?  I'm really asking here, not really sure one way or the other what effect they have.

If we had no network nodes and only mining nodes and nodes directly connected to wallets would bitcoin be less safe, more safe or the same? Like we might end up with just 100 nodes or something (1 for each large mining pool, a few for the large bitcoin service providers like coinbase, etc, and a bunch for people using their nodes with the bitcoin core wallet, and a handful of SPV users. Maybe 100 is a bit too small a number (what would the number be?).

This is pretty funny regardless of whether you like RBF or not:

https://www.reddit.com/r/Bitcoin/comments/3zju81/rbf_optin_a_man_walk_in_a_bar_order_a_coffe_drink/cymp40r

>I consider that a large amount of revenue, because mining profit is marginal

How can $60 be considered a lot of revenue compared to like $15,000 for solving a block? It does add up if you are a mining pool but it is still very minimal compared to the block reward. So overall, I would say right now, transaction fees are largely meaningless and it is weird that we are even paying them at all.

There's really not much of a financial incentive for individual miners to include a lot or even any transactions, since at this time the transaction fees are so small. However, a mining pool would have greater incentive. Some of the large pools might be getting 30% of all the blocks found in one day. Current charts show that total transaction fees per day, summed across all blocks for that day, are around 10BTC. So 30% of that is 3BTC or a little over $1800/day at todays exchange, or a nice $675,000 per year at these levels.

Of course if that pool is splitting those fees up amongst a ton of miners who participated in solving those blocks, then it still amounts to very little per miner. But maybe they keep it for themselves??