Gold collapsing. Bitcoin UP.

[cypherdoc]

How about this one:

Current situation where blocks are getting full from artificial 1MB cap:
Attacker: large miners like f2pool
Attack: spam network from one of its wallets to another. Drive up overall fees of regular users.
Success: 100%

Sustainable for only until the cumulative the fees equals their net worth, i.e. unsustainable.

F2pool is paying the spam to itself.

[1714009384]

1714009384

[1714009384]

1714009384

[1714009384]

1714009384

[1714009384]

1714009384

[1714009384]

1714009384

[TPTB_need_war]

Here are some attacks which are affected by the number of nodes and/or miners and/or hashrate:

Attacker: Miners
Attack: Double spending. A miner can spend bitcoins on a product or service, then produce a block which invalidates the spend
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: Number of bitcoins controlled by the attacker * number of attacks performed

The actual severity can be much greater. There can be a run on the coin affecting all HODLers.

You apparently fail to grasp the wealth effect (i.e. that the mcap != amount of capital invested) is mostly built on CONFIDENCE.

Attacker: Miners
Attack: Denial of service. A miner can engage in selective censorship of transactions
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: % success rate of censor identifying transactions they wish to block * value of the blocked transactions

Again you fail to account for out-of-band entropy. The ability to censor key transactions (even if a minute, undetectable %) could lead to immense power-structures, i.e. you threaten to censor the wealth of someone you need to coerce on major political outcome, e.g. a speaker of the house.

Attacker: Nodes
Attack: Double spending. An attacker can defraud a target who is using an SPV wallet by providing them with invalid block headers which allow the attacker to pay the target with a transaction which references non-existant inputs
Probability of success: 0% unless the attacker can prevent the target from communicating with any honest nodes
Severity:  Number of bitcoins controlled by the attacker * number of attacks performed

Yes Sybil attacks are another vector and there are lot more cases of attacks that you have not enumerated.

[justusranvier]

Current situation where blocks are getting full from artificial 1MB cap:
Attacker: large miners like f2pool
Attack: spam network from one of its wallets to another. Drive up overall fees of regular users.
Success: 100%

You just described a version of the "denial of service" attack already mentioned.

[TPTB_need_war]

How about this one:

Current situation where blocks are getting full from artificial 1MB cap:
Attacker: large miners like f2pool
Attack: spam network from one of its wallets to another. Drive up overall fees of regular users.
Success: 100%

Sustainable for only until the cumulative the fees equals their net worth, i.e. unsustainable.

F2pool is paying the spam to itself.

How can it spam the network when the blocks it can create are capped to 1MB? It might as well charge 0 txn fees to itself. That wouldn't affect the fees of other regular users whose transactions can appear on blocks created by the other miners.

If you are arguing that centralization of mining can create a monopoly on fees, then yes I agree. But that is true regardless of block size.

It would help if you would at least think before posting. Most of what you post is incorrect.

[iCEBREAKER]

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:

Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

So they switch back to working on a full block if they aren't able to solve the block header in the time it takes to fully process everything?

Yes, that's right.  Large miners always try for 0-tx freebie blocks while processing the pool, then switch to fee-grabbing mode when it's done.  The larger the block, the more (non-trivial) CPU time must be devoted to processing.  It's a linear relationship, so 20MB blocks take 20 times longer.  This is bad for an antifragile diverse/diffuse/defensible/resilient system designed to remain functional thrive under load, but not under bloat.

[cypherdoc]

Current situation where blocks are getting full from artificial 1MB cap:
Attacker: large miners like f2pool
Attack: spam network from one of its wallets to another. Drive up overall fees of regular users.
Success: 100%

You just described a version of the "denial of service" attack already mentioned.

Not sure i follow.

Right now we could be having a situation where f2pool is spamming the network with TX's paid to itself which raises everyone's fees of which they will mine 21%of the time in proportion to their current hashrate. Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

[TPTB_need_war]

Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

They would be giving their money away to other miners thus decreasing their relative hashrate in a downward toilet bowl spiral for themselves. Illogical.

[cypherdoc]

Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

They would be giving their money away to other miners thus decreasing their relative hashrate in a downward toilet bowl spiral for themselves. Illogical.

No, spam fees are minimal or even 0. Regular users have to exceed those fees to fit into a limited 1MB block. F2pool wins blocks 21%of the time. Depending on how high they can drive up these fees compared to the minimal spam fees they lose 79% of the time, it could be profitable.

[TPTB_need_war]

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:

Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

So they switch back to working on a full block if they aren't able to solve the block header in the time it takes to fully process everything?

Yes, that's right.  Large miners always try for 0-tx freebie blocks while processing the pool, then switch to fee-grabbing mode when its done.  The larger the block, the more (non-trivial) CPU time must be devoted to processing.  It's a linear relationship, so 20MB blocks take 20 times longer.  This is bad for an antifragile diverse/diffuse/defensible/resilient system designed to remain functional thrive under load, but not under bloat.

This delay is a form of propagation delay and thus drives up the orphan rate for miners with less resources. Afaik proportional increases in orphan rate are more costly than proportional decreases in hashrate, because the math is compounded (but diminishing) on each subsequent block of the orphaned chain. Thus this action doesn't appear to make economic sense unless it is explained as a lack of bandwidth and not a lack of desire to apply more of their resources to processing the txns than to hashrate. If it is bandwidth that is culprit, then it argues against larger block sizes.

[TPTB_need_war]

Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

They would be giving their money away to other miners thus decreasing their relative hashrate in a downward toilet bowl spiral for themselves. Illogical.

No, spam fees are minimal or even 0. Regular users have to exceed those fees to fit into a limited 1MB block. F2pool wins blocks 21%of the time. Depending on how high they can drive up these fees compared to the minimal spam fees they lose 79% of the time, it could be profitable.

Your mistake is you assume 21% is a constant, but as they drive up fees and giving 79% of the increase away, they drive up the relative resources of the other miners thus driving down their 21% in a spiral. Even if they increase their profitability, it isn't sustainable.

[thezerg]

OK, let's try again.  Ever heard of 'packet filtering?'

If you are the engineer you claim to be you know damn well how easy it would be to hide Bitcoin txns from a DPI DSP engine inside a HTTP image request, an audio or video stream, or of course via an encrypted connection.

Please don't post arguments that you know are illogical but you think will convince others.  It does not further the discourse.

In my experiments with steganography many years ago, I find it cuts down available bandwidth by orders of magnitude.  At that time it was unclear if it was even theoretically possible to hide things fully, although it was pretty clear that one could cause the waste of huge amounts of an attacker's CPU if you made him look.

The utility I used most was 'steghide'.  A while ago I looked it up again.  The source code was still available but it had not been changed in years.  In looking just now I notice that there is a French version of wikipedia which has an entry but I can find no English one and Google translate doesn't work on it.  Weird.  https://fr.wikipedia.org/wiki/Steghide

Actually, there is a point to be made that individual transactions could be hidden steganographically for spends no matter what the network transaction rate and it is kind of questionable whether the backbone itself could run fully steganographically hidden even with 1MB blocks under dedicated attack by funded and motivated attackers (who own the network.)

Ideally I'd like to see it practical for the backbone network to be operation fully on side-channels which make no use of the global internet at all.  In any real attack situation it is very unlikely that any infrastructure operator would enjoy the streaming class of network traffic that we know today.  That is another reason I would like to avoid developing a reliance on real-time behavior (or even ~10 min/conf expectations) or structured block formations and so on.  The Blockstream folks making mention of expectations in the days range gives me hope that they are designing for worst-case scenarios (which is exactly what I need to feel comfortable about storing significant value in Bitcoin.)

Edit:  BTW, I've got very little expectation that encrypted connections without government backdoors will survive indefinitely.  No design that I trust for longer duration work will make that expectation.

Its steganography to hide a bitcoin txn from a human inside a hidden channel.  But its so simple to hide from a packet inspection engine I wouldn't even call it steganography... for example the "image" downloaded could look like random bits to a person (obviously not a meaningful image) but the packet inspection engine would not be able to determine that.

[TPTB_need_war]

Its steganography to hide a bitcoin txn from a human inside a hidden channel.  But its so simple to hide from a packet inspection engine I wouldn't even call it steganography... for example the "image" downloaded could look like random bits to a person (obviously not a meaningful image) but the packet inspection engine would not be able to determine that.

We need to act soon, because if the 5 Eyes has their way (and they are almost there) then the world will accept that HTTPS means encryption but in fact it does not. Then the NWO will say that any data that is encrypted (i.e. random) but not done with HTTPS is prohibited on the internet. The public is almost to the point of gleefully agreeing.

[TPTB_need_war]

Edit:  BTW, I've got very little expectation that encrypted connections without government backdoors will survive indefinitely.  No design that I trust for longer duration work will make that expectation.

The only way I see to win is to make such that TPTB must attack the majority in order to attack the smallest minority. Otherwise, we will always have the problem of an undersupplied public good.

So in one way of doing that everything can be unencrypted and the majority is grouped in with the minority.

And the other way is the majority uses (and thus demands) non-backdoored encryption.

We need to get rolling on both fronts. Nothing is doing that well now (afaik).

[tvbcof]

Its steganography to hide a bitcoin txn from a human inside a hidden channel.  But its so simple to hide from a packet inspection engine I wouldn't even call it steganography... for example the "image" downloaded could look like random bits to a person (obviously not a meaningful image) but the packet inspection engine would not be able to determine that.

Huh?  No it's not.  Humans don't enter into the picture at all except that they are prone to generate things in the normal course of a days events which can be used as carriers (e.g., cat pics.)

Packet engines (inspection, capture, etc) would never be trying to deduce steganographic content from a channel.  For the foreseeable future (due to the arms race nature of things) the best they could do would be to fork of likely carriers to other analysis infrastructure.

[rocks]

Here are some attacks which are affected by the number of nodes and/or miners and/or hashrate:

Attacker: Miners
Attack: Double spending. A miner can spend bitcoins on a product or service, then produce a block which invalidates the spend
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: Number of bitcoins controlled by the attacker * number of attacks performed

Attacker: Miners
Attack: Denial of service. A miner can engage in selective censorship of transactions
Probability of success: 100% when the hash rate of the attacker exceeds the hash rate of the rest of the network
Severity: % success rate of censor identifying transactions they wish to block * value of the blocked transactions

Attacker: Nodes
Attack: Double spending. An attacker can defraud a target who is using an SPV wallet by providing them with invalid block headers which allow the attacker to pay the target with a transaction which references non-existant inputs
Probability of success: 0% unless the attacker can prevent the target from communicating with any honest nodes
Severity:  Number of bitcoins controlled by the attacker * number of attacks performed

1) Attacker: Miners
The key question here is do larger blocks even change the mining ecosystem, because if larger blocks do not effect miners then the point is moot since the attacks are the same with or without larger blocks.
There are good reasons to believe that larger blocks do not effect mining. Miners already have centralized on pools, which themselves are large enough to scale up resources. Pools do not have to be physically close to miners and can (and should) migrate to well networked regions and cloud services.
Miners themselves already use the stratum protocol that require < 1kbps connectivity, they are not impacted by or see any effects from larger blocks. The pool handles the block, while the miner just processes a data packet that is the same size regardless of blocksize.

2) Attacker: Nodes
As you point out, all you require is a connection to one honest node and that honest node can expose any attack. If 50% of the P2P nodes are coordinating an attack and a SPV wallet connects to 8 random nodes, then the probability of success is 1/2^8 or 0.39%. This attack is very difficult with a larger number of nodes.
In the case where P2P nodes become highly centralized (let's say they are reduced to 25 very large entities), then it is likely that several of those nodes would be trusted volunteer efforts (think an EFF node) or run by trusted entities (think a shared ivy league university node) and SPV wallets would be programmed to require connections to a least a few trusted nodes. This is probably an even more difficult attack than today where we have 6K nodes, since it is relatively easy to spin up 6K nodes in AWS for the short period of time needed.

[justusranvier]

Not sure i follow.

Right now we could be having a situation where f2pool is spamming the network with TX's paid to itself which raises everyone's fees of which they will mine 21%of the time in proportion to their current hashrate. Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

From the perspective of a Bitcoin user, every possible thing that can go wrong with Bitcoin can be categorized into one of two failure modes:

• A payment you belive to be valid, isn't (double spend)
• You are unable to perform a payment that you want to perform (denial of service)

All a user cares about how certain they can be that their balance is valid, and that they are able to spend their coins.

Before we can talk intelligently about how an attacker might reduce the number of miners and/or the number of nodes, we first need to establish why the attacker would do this, i.e. the ways in which an attacker can benefit from performing double spending or denial of service attacks.

Take selfish mining as an example. This is not an attack that directly affects Bitcoin users.

It may be possible for an attacker to solve more blocks than their share of the hashing power would initially suggest, but that in and of itself doesn't make your balance invalid or prevent you from spending your coins. It only affects Bitcoin users indirectly, to the extent that double spending or DoS attacks are easier if the attacker successfully reduces its competition.

[tvbcof]

Its steganography to hide a bitcoin txn from a human inside a hidden channel.  But its so simple to hide from a packet inspection engine I wouldn't even call it steganography... for example the "image" downloaded could look like random bits to a person (obviously not a meaningful image) but the packet inspection engine would not be able to determine that.

We need to act soon, because if the 5 Eyes has their way (and they are almost there) then the world will accept that HTTPS means encryption but in fact it does not. Then the NWO will say that any data that is encrypted (i.e. random) but not done with HTTPS is prohibited on the internet. The public is almost to the point of gleefully agreeing.

That would hamper business greatly.  Almost everything I did, for instance, was over ssh/ssl.  It would take years and billions of dollars to re-write the work of countless engineers who've done likewise.

The next hand which would be played would be to mandate the use of core ssl which had a (known) backdoor.  I could not honestly say that I would have difficulty compliling it in and thus not needing to re-write my tools however.

The hand past that would be trying to find a safe home for the core network and stego.  One of Adam Back's memorable quotes here on this thread IIRC went something like "at the margins steganography wins."  The trouble is that if Bitcoin has moved beyond what is possible to do at these margins, we lose.

[iCEBREAKER]

if we see blocks fill up and the network starts functioning poorly, we are going to see a change pushed out far quicker then any of us ever imagined.

Agreed.  We'll know when it's "eventually" when we see it.

[cypherdoc]

Yes, they lose 79% of the fees used to do this but overall it might work out in their favor.

They would be giving their money away to other miners thus decreasing their relative hashrate in a downward toilet bowl spiral for themselves. Illogical.

No, spam fees are minimal or even 0. Regular users have to exceed those fees to fit into a limited 1MB block. F2pool wins blocks 21%of the time. Depending on how high they can drive up these fees compared to the minimal spam fees they lose 79% of the time, it could be profitable.

Your mistake is you assume 21% is a constant, but as they drive up fees and giving 79% of the increase away, they drive up the relative resources of the other miners thus driving down their 21% in a spiral. Even if they increase their profitability, it isn't sustainable.

You're probably right on that one.

Let's try this one: non economic actor decided to spam persistently at little cost to them as blocks get close to being filled by real activity, say starting like where we are right now, at the 50-60% level. Fees for regular users skyrocket making use untenable.

[cypherdoc]

for anyone with any respect left for marcus_of_augustus, take a look at this:

https://www.reddit.com/r/Bitcoin/comments/3bpbqv/woohoo_check_out_the_size_of_block_363270/csofmu6

[–]marcus_of_augustus 2 points 7 hours ago
 
Do they still give gold stars for 5 year olds?
You should be very careful with all those cold wallets, things could go very badly if family and friends are centralising trust in one questionable opsec practise.

permalinkembedsaveparentreportgive goldreply