Bitcoin Forum
November 21, 2017, 04:33:34 PM *
News: Latest stable version of Bitcoin Core: 0.15.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 ... 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 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2010874 times)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
July 09, 2015, 12:24:26 AM
 #28501

Spammer only spends money 1x during lifetime, but miner has to keep bigger disk-space forever (2 hard disc consume more electricity than single one)

OK.  Provide me with your estimates for the following (and explain how you arrived at your numbers) and I'll update my table using your numbers:

1.  The cost per node to store 1 GB of additional blockchain data for 5 years, assume the outputs are spent.
2.  The cost per node to store 1 GB of additional blockchain data for 5 years, assuming the outputs are unspent.



I'm sorry, I have no estimates. I know that bloat-chain is not solution  There are better solutions how to organize blockchain.

My full node just crashed ... all data are lost ... downloading 6 years 25 weeks.  ... hmm I hope that it is only me and there will remain some copy of blockchain. :-)  (not joking)

your data management systems need updating if you lost the data. Bitcoin is a $3B network and if you dont have an invested interest in keeping the blockchain to prove you own X coin or care enough to manage the responsibility you shouldn't be dictating how we should use it. not everyone who can't backup data or doesn't want to should be running a node. I have friends who dont trust digital photos because they trust paper copies more. I'm surprised to find you fit the profile.

I also think you're not weighting the cost and benefits correctly, the cost of 2 hard disc consuming more electricity than single one, is an inconsequential cost at the scale of executing this same attack with an 8MB block. (hell its inconsequential at the cost of the attack on the 1MB block.)

limiting block space is not going to save anyone except you a little bandwidth because you dont back up.


Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
1511282014
Hero Member
*
Offline Offline

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

1511282014
Report to moderator
1511282014
Hero Member
*
Offline Offline

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

1511282014
Report to moderator
1511282014
Hero Member
*
Offline Offline

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

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

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

1511282014
Report to moderator
1511282014
Hero Member
*
Offline Offline

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

1511282014
Report to moderator
1511282014
Hero Member
*
Offline Offline

Posts: 1511282014

View Profile Personal Message (Offline)

Ignore
1511282014
Reply with quote  #2

1511282014
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 09, 2015, 01:25:48 AM
 #28502

I just want to highlight the comments here from bitcoin-dev today, which seem to indicate that these spamming attacks would have been 5.5x more expensive if a dust threshold software change had not been made. Perhaps there are deeper insights someone else has on this...?

Quote
16:53   wangchun   why can those spam get confirmed. 0.00001 BTC vout below dust threshold right?
16:54   phantomcircuit   wangchun, iirc the dust threshold is 546 satoshis
16:54   wangchun   not 5460 satoshis? changed?
16:54   aschildbach   wangchun: Yes it was cut by 10 a few months ago.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 02:12:12 AM
 #28503

The point I'm trying to make is that if CreateNewBlock is super-linear in mempool size, then it would not be surprising to see more empty blocks (what Cypher was calling "defensive blocks") when mempool swells (the miners are mining on an empty block for longer while waiting for CreateNewBlock to finish).  This was Cypher's point from the very beginning that many people, including myself, were suggesting was probably not the case!  

that is exactly what i was saying w/o knowing anything about CNB.  it was just intuitive that constructing a new block would take longer for a large mempool so i deduced that a miner might decide "f*ck it" that he doesn't want to not only spend additional time validating a large incoming block but also not want to spend additional time creating a large new block so instead just automatically switch to 0 block mining upon arrival of a large block.  the thing none of us anticipated was that he would not validate that incoming large block at all and switch to SPV mining while >50% of the network would also be SPV mining (Discus, Antpool, BTCGuild) and trigger an invalid SPV longest chain.

that's some wild shit going on.

given this newly recognized scenario, i still conclude however that this is all a result of the block size limit being hit continuously by attacking spammers and secondarily intentionally causing a bloated mempool which then causes these unanticipated defensive strategies and more intentionally, user disruption.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 02:55:42 AM
 #28504

I just want to highlight the comments here from bitcoin-dev today, which seem to indicate that these spamming attacks would have been 5.5x more expensive if a dust threshold software change had not been made. Perhaps there are deeper insights someone else has on this...?

Quote
16:53   wangchun   why can those spam get confirmed. 0.00001 BTC vout below dust threshold right?
16:54   phantomcircuit   wangchun, iirc the dust threshold is 546 satoshis
16:54   wangchun   not 5460 satoshis? changed?
16:54   aschildbach   wangchun: Yes it was cut by 10 a few months ago.

i don't think it really matters, does it?

since most of the mined blocks are filled with real demand trying to get into blocks with or without spamming, the only difference being that with spamming the real demand has to pay significantly higher fees to get in, the cost to fill up the rest of the block with spam is minimal as is the minimal cost to bloat the mempool to extraordinary levels (94K 0confs as i write).  i say minimal cost for the mempool b/c most of it gets turned over after 24h deletion allowing that spam to be recycled w/o having to pay.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 03:59:27 AM
 #28505

all the yearly silver and mining stocks have that sick top left to bottom right chart configuration. this is a horrible leading indicator for both gold and stocks:

silver futures:



SLW:



PAAS:



silverbox's GPL:

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 09, 2015, 04:08:36 AM
 #28506

When miner's mempool exceeds block size by some backlog factor, they need to send out a message to the peers they are connected to saying "don't propagate transactions to me with smaller than X fee per kilobyte until further notice". This will mitigate the impact that spam-that-can-never-be-added-to-a-block can have on the network, but it won't entirely eliminate it, because as the mempool backlog reduces, the miner will need to back off the notice to some unknown lower fee threshold. The miner could guess but it will never be 100% accurate. So spam will get verified and rejected. But perhaps those estimates can be close enough that the losses the spammers takes in fees for transactions it sends that do get into a block will be greater than the gains it values from effective spamming (what ever those gains are  Huh). Appears to me the issue can be fixed.

Afaik, the reason incoming transactions are verified before it is known whether they will be in a new block, is because it is considered spam to propagate (send out again to another peer) invalid transactions that would be rejected and never appear in a block.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 04:27:03 AM
 #28507

When miner's mempool exceeds block size by some backlog factor, they need to send out a message to the peers they are connected to saying "don't propagate transactions to me with smaller than X fee per kilobyte until further notice". This will mitigate the impact that spam-that-can-never-be-added-to-a-block can have on the network, but it won't entirely eliminate it, because as the mempool backlog reduces, the miner will need to back off the notice to some unknown lower fee threshold. The miner could guess but it will never be 100% accurate. So spam will get verified and rejected. But perhaps those estimates can be close enough that the losses the spammers takes in fees for transactions it sends that do get into a block will be greater than the gains it values from effective spamming (what ever those gains are  Huh). Appears to me the issue can be fixed.

Afaik, the reason incoming transactions are verified before it is known whether they will be in a new block, is because it is considered spam to propagate (send out again to another peer) invalid transactions that would be rejected and never appear in a block.

gmax already told us to use minrelaytxfee.
tvbcof
Legendary
*
Offline Offline

Activity: 2324


View Profile
July 09, 2015, 04:47:58 AM
 #28508

Spammer only spends money 1x during lifetime, but miner has to keep bigger disk-space forever (2 hard disc consume more electricity than single one)

OK.  Provide me with your estimates for the following (and explain how you arrived at your numbers) and I'll update my table using your numbers:

1.  The cost per node to store 1 GB of additional blockchain data for 5 years, assume the outputs are spent.
2.  The cost per node to store 1 GB of additional blockchain data for 5 years, assuming the outputs are unspent.


I'm sorry, I have no estimates. I know that bloat-chain is not solution  There are better solutions how to organize blockchain.

My full node just crashed ... all data are lost ... downloading 6 years 25 weeks.  ... hmm I hope that it is only me and there will remain some copy of blockchain. :-)  (not joking)

Don't worry.  According to Mike Hearn Bitcoin can survive just fine with 4 or 6 (forgot which) copies of the blockchain worldwide.


domob
Legendary
*
Offline Offline

Activity: 983


View Profile WWW
July 09, 2015, 05:28:52 AM
 #28509

Yes, but the ongoing spam shows clearly that all full nodes are handling the traffic just fine. We were told that they would crash and burn from overloaded memory. Not true.

Wait, wasn't that exactly Hearn's main argument in his "the sky is falling if we don't increase the blocksize" blog post?  So why do you see the fact that it did not prove true so far as supporting your position of increasing the block size?

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Peter R
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 09, 2015, 05:37:00 AM
 #28510

Yes, but the ongoing spam shows clearly that all full nodes are handling the traffic just fine. We were told that they would crash and burn from overloaded memory. Not true.

Wait, wasn't that exactly Hearn's main argument in his "the sky is falling if we don't increase the blocksize" blog post?  So why do you see the fact that it did not prove true so far as supporting your position of increasing the block size?

It provided evidence that the network can handle the increased load, and it confirmed that people do get frustrated by the confirmation delays. 

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

Activity: 1638


View Profile
July 09, 2015, 07:43:52 AM
 #28511

Let's face it If we want adoption by a cb we need more tx/s however we can solve other probs first before raising limit to efficiently come to that conclusion.

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2338



View Profile
July 09, 2015, 09:36:30 AM
 #28512

I just want to highlight the comments here from bitcoin-dev today, which seem to indicate that these spamming attacks would have been 5.5x more expensive if a dust threshold software change had not been made. Perhaps there are deeper insights someone else has on this...?
Quote
16:53   wangchun   why can those spam get confirmed. 0.00001 BTC vout below dust threshold right?
16:54   phantomcircuit   wangchun, iirc the dust threshold is 546 satoshis
16:54   wangchun   not 5460 satoshis? changed?
16:54   aschildbach   wangchun: Yes it was cut by 10 a few months ago.
i don't think it really matters, does it?
since most of the mined blocks are filled with real demand trying to get into blocks with or without spamming,
Unfortunately, the majority in the blocks I checked earlier today have been the DOS attack-- e.g. transactions tracable from outputs of this transaction https://blockchain.info/tx/3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  and a few others. ... though the attack style has been shifting to evade filtering by miners.

The change mentioned in the chat above is https://github.com/bitcoin/bitcoin/pull/3305 (you might find the comments there interesting), it's one of Mikes couple contributions to Bitcoin Core.

Bitcoin will not be compromised
awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
July 09, 2015, 10:43:47 AM
 #28513

Unfortunately, the majority in the blocks I checked earlier today have been the DOS attack-- e.g. transactions tracable from outputs of this transaction https://blockchain.info/tx/3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  and a few others. ... though the attack style has been shifting to evade filtering by miners.

The change mentioned in the chat above is https://github.com/bitcoin/bitcoin/pull/3305 (you might find the comments there interesting), it's one of Mikes couple contributions to Bitcoin Core.

So miners are filtering out the spam? What are they filtering for?
sickpig
Legendary
*
Offline Offline

Activity: 1218


View Profile
July 09, 2015, 12:19:55 PM
 #28514

Jeff Garzik has just posted 2 pull requests for bitcoin core on github:

https://github.com/bitcoin/bitcoin/pull/6405
Remove TX priority and free transaction area from mempool, block creator.

https://github.com/bitcoin/bitcoin/pull/6402
Floating network relay fee increase, if memory pool grows too large.

the latter will introduce, if merged, "a relay fee that adjusts to floods
which cause the memory pool to grow too large".

It seems that core devs start becoming aware of the lack of
of economic incentives for services provided by full nodes.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 09, 2015, 12:21:03 PM
 #28515

Unfortunately, the majority in the blocks I checked earlier today have been the DOS attack-- e.g. transactions tracable from outputs of this transaction https://blockchain.info/tx/3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  and a few others. ... though the attack style has been shifting to evade filtering by miners.

The change mentioned in the chat above is https://github.com/bitcoin/bitcoin/pull/3305 (you might find the comments there interesting), it's one of Mikes couple contributions to Bitcoin Core.

Goddammit, Peter Todd hits the nail on the head! Kudos to him.
Yes, that 10x reduction looks to be unwise in hindsight. I recall the painful and protracted debate on bct just getting the dust threshold at 5460 sats in the first place.

So miners are filtering out the spam? What are they filtering for?

Hey, nice to see you in this thread.
It appeared that BitFury was aggressively filtering by fee when producing small 138KB blocks, however they have just mined a 998KB block (364549) which I think is their first near this size.

TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
July 09, 2015, 01:30:20 PM
 #28516

It appeared that BitFury was aggressively filtering by fee when producing small 138KB blocks, however they have just mined a 998KB block (364549) which I think is their first near this size.
Nah, there were also 364354, 364383, 364393 and 364398

awemany
Newbie
*
Offline Offline

Activity: 28


View Profile
July 09, 2015, 01:49:34 PM
 #28517

So miners are filtering out the spam? What are they filtering for?

Hey, nice to see you in this thread.
It appeared that BitFury was aggressively filtering by fee when producing small 138KB blocks, however they have just mined a 998KB block (364549) which I think is their first near this size.

Hi! Yeah, I was always somewhat put off by the presentation here, too confusing, threads with too many pages. Have a couple of old accounts that I lost all login data for. On the other hand, Reddit is sometimes a bit shallow and fast scrolling...

So they did increase the fees then and not reduce their blocksize, it seems? That would make a lot more sense to me (from the miner's perspective).
newb4now
Hero Member
*****
Offline Offline

Activity: 658


View Profile
July 09, 2015, 02:14:38 PM
 #28518

In the short run, miners will keep putting up with spam transactions because most of their revenue (great majority) is coming from the BTC block reward. As rewards become less and less and transaction volume (spam or legitimate) continues to increase the balance will gradually start to change.

Eventually miners will start to ignore transactions without some minimum transaction fee (which will change over time based on block reward/transaction fee balance).

This is a self correcting problem which miners will correct on their own (by only verifying transactions with some minimum fee)

We all expected this from the beginning. The blockchain will eventually be supported by transactions fees as block reward keeps dropping. The only thing that has changed is that miners may respond sooner because of all these spam transactions. Spam will stop once the miners raise the minimum fee enough (or spam transactions will continue but never be confirmed)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 02:46:24 PM
 #28519

Jeff Garzik has just posted 2 pull requests for bitcoin core on github:

https://github.com/bitcoin/bitcoin/pull/6405
Remove TX priority and free transaction area from mempool, block creator.

https://github.com/bitcoin/bitcoin/pull/6402
Floating network relay fee increase, if memory pool grows too large.

the latter will introduce, if merged, "a relay fee that adjusts to floods
which cause the memory pool to grow too large".

It seems that core devs start becoming aware of the lack of
of economic incentives for services provided by full nodes.


i hate to bring up an analogy from medicine since it may not be appropriate but i'll try nonetheless.

one of the greatest things i learned during my internship btwn med school and residency in eyes, is that too much intervention can cause problems for patients.  every 3 mo i'd rotate onto a new ward with responsibilities for about a couple of dozen gorked out patients.  i say gorked out b/c invariably all of them had at least a dozen meds onboard for a variety of reasons most of which had to do with sedation, pain, or anti-anxiety.  problem was, these meds unbeknownst to their previous physicians were preventing these ppl from getting better.  this was a repeating problem.  so the first thing i would do would be to cocentrate on stripping off as many of these unnecessary meds as possible.  much to everyone's amazement, these pts would perk up, turn around and start walking again, interacting with staff, feeling better, be more alert, and generally just get better to the pt i could discharge them.  and this experience happened over and over for me.  twas a great personal accomplishment for me and one i will never forget; don't over do it.

pt being, i still think the block size cap is the fundamental problem here.  more rules and limits that core dev piles on simply complicates the code and makes it more complex.  if anything, we should be stripping off rules and limits so that the free mkt can come to bear on many of these problems we are currently seeing.  the miners and users are perfectly capable of regulating the size of blocks and fees on their own.  if we lift the cap, the spam can actually help the network.  as long as spammers have to pay fees any spam attempts will line the pockets of miners and go back to growing the hashrate.  that would be a good thing and the last thing the spammers want to do.  no doubt they will try at first so we should expect even greater higher level attacks initially but in the long run, they will die off.  that's b/c their real objective is to disrupt new user growth which w/o a cap will be short circuited.  any further spam then will just help the tx mkt to grow, miners to profit, and yes, full nodes will eventually develop their own fee mkt too.  yes, full node capacities will have to grow but that should be viewed as a good thing b/c on the other end that will mean that miners are prospering (which is ok Greg) and user growth will be skyrocketing along with the price.  more merchants will come on board with new user growth and they will want and probably have a fiduciary responsibility to run their own full nodes which will add to network capacity.

so strip off rules and limits within reason, not add, and let BitcoinRun!
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 09, 2015, 03:01:29 PM
 #28520

Unfortunately, the majority in the blocks I checked earlier today have been the DOS attack-- e.g. transactions tracable from outputs of this transaction https://blockchain.info/tx/3bad15167c60de483cd32cb990d1e46f0a0d8ab380e3fc1cace01afc9c1bb5af  and a few others. ... though the attack style has been shifting to evade filtering by miners.

The change mentioned in the chat above is https://github.com/bitcoin/bitcoin/pull/3305 (you might find the comments there interesting), it's one of Mikes couple contributions to Bitcoin Core.

So miners are filtering out the spam? What are they filtering for?

good question.  how do they distinguish? 

like i said above, w/o a block size cap, spam fees can actually pay to help grow the network and user base long term before it dies off. 
Pages: « 1 ... 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 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 ... 1558 »
  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!