Bitcoin Forum
December 10, 2016, 11:11:28 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 [1400] 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807767 times)
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
July 01, 2015, 02:23:41 AM
 #27981

One of the things that's missing from the block size debate is a usable threat model that would allow us to make objective and rational risk assessments of the various threats loosely defined as "centralization".

Before we know how worried we should be about larger blocks (potentially) reducing the number of nodes, we need to know exactly how an attacker benefits from this situation and what kinds of mitigating factors and/or countermeasures are applicable to each attack.

I haven't heard any kind of analysis along those lines yet.

Yes, excellent point.  Because there is not much AFAIK.  Really, the power is in the hands of the miners (mining pool operators), which is already ironically very centralized relative to nodes.  Off the top of my head, fewer nodes would make it easier mount a Sybil attack to isolate a node or SPV client and then feed it incorrect data.
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
1481368288
Hero Member
*
Offline Offline

Posts: 1481368288

View Profile Personal Message (Offline)

Ignore
1481368288
Reply with quote  #2

1481368288
Report to moderator
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 01, 2015, 02:32:17 AM
 #27982

Sort of cute:

https://www.reddit.com/r/Bitcoin/comments/3bpese/blocking_the_stream_the_blocksize_limit_debate_in/


Run Bitcoin Unlimited (www.bitcoinunlimited.info)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
July 01, 2015, 02:38:20 AM
 #27983

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

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 02:44:28 AM
 #27984


The only technically knowledgeable people who support this inane system design do so because they see clearly that it will consolidate the infrastructure into a form that is as easily controlled as fiat money is currently.  To many many people, this consolidation of control is a good thing.  Most people love Big Brother whether they realize it or not and have the reflexes trained to support him.

this is precisely why we disagree on everything.  i believe that the internet can allow the ppl to take back control of their money as it should be.  don't forget that central banks are still a relatively new concept in the modern age.  with that, i mean, going back 100 yrs or so.  

maybe it's naive, maybe not.  but it certainly is worth the effort and risk to try.  which is why i support lifting the block limit just to see what happens.  i believe we will cope.

Ever hear of Edward Snowden?  

actually, i have.  and he is precisely one of the reasons i think we're winning.

the NSA and 5 Eyes, i believe, are going to lose in the long run precisely b/c Snowden's leak shows they can't secure data.  everyone knows this now which is why Google and Apple have started encrypting as default, much to the chagrin of the gvt.  and this is happening all over the internet.

furthermore, with 21 Inc on the verge of releasing mini Asic chips that power devices, the chances for mass decentralization of Bitcoin goes up.  also, the Internet has never had it's own monetary system or means of conveniently and cheaply paying one another in realtime.  Bitcoin, for the first time in history, can provide that.

You apparently lack an economics education on the concept of an undersupplied public good, i.e. free-of-speech doesn't guarantee that participants will act unselfishly to avert catastrophic outcomes.

tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
July 01, 2015, 02:53:01 AM
 #27985


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.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 02:55:54 AM
 #27986


Here is the rebuttal in one image.


            /\  <------- privileged members of the TPTB that control the centralized public good
~~~~~~~~~~/    \~~~~~~~~~~~~~~~~> water level globally
        /        \
      /            \             so much "spam" down here, choking off the entropy of miners
    /                \
  /       TPTB         \             everybody else down here transacting perhaps,
/                        \           but fully submerged in totalitarianism

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 01, 2015, 02:57:27 AM
 #27987

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



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%
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:01:54 AM
 #27988

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.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 01, 2015, 03:10:36 AM
 #27989

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.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:12:41 AM
 #27990

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
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
July 01, 2015, 03:13:17 AM
 #27991

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:16:48 AM
 #27992

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
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
July 01, 2015, 03:17:19 AM
 #27993

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.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

"Hard forks cannot be co
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 01, 2015, 03:19:11 AM
 #27994

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:23:31 AM
 #27995

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 01, 2015, 03:28:44 AM
 #27996

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:39:57 AM
 #27997

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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:45:25 AM
 #27998

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
Legendary
*
Offline Offline

Activity: 1246


View Profile
July 01, 2015, 03:48:50 AM
 #27999


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
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 01, 2015, 03:54:19 AM
 #28000

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.

Pages: « 1 ... 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 [1400] 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 ... 1560 »
  Print  
 
Jump to:  

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!