Bitcoin Forum
December 04, 2016, 06:16:15 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 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 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804003 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 05, 2015, 03:31:27 AM
 #28181

I'd love to see you show with mathematics that under certain assumptions the mining will centralize. Why don't you give it a try?

Just model the relative ROI even assuming same costs per hash (even exacerbate by applying the selfish mining attack math) with the orphan rate higher for those who don't have as much bandwidth and verification resources as centralized mining (which can amortize those fixed size per block costs over greater hashrate). If you want, insert IBLT to rectify that orphan rate disparity which is obfuscated centralization (e.g. in terms of your upthread definition of "entity" and not "node").

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

Posts: 1480832175

View Profile Personal Message (Offline)

Ignore
1480832175
Reply with quote  #2

1480832175
Report to moderator
1480832175
Hero Member
*
Offline Offline

Posts: 1480832175

View Profile Personal Message (Offline)

Ignore
1480832175
Reply with quote  #2

1480832175
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 05, 2015, 04:01:12 AM
 #28182

it looks like the average time these pools are mining empty blocks is 16 seconds (F2Pool) and 35 seconds (AntPool) before switching to non-empty blocks.  Like you said, why are these numbers so big if processing the blocks is so fast?

I think these metrics should specifically exclude the two pools above as they are the ones who were SPV mining and not switching to using a validated block-header as soon as possible.

Don't get put-off from posting by Greg's feedback as it is easy to be silenced by someone-who-knows-best and let them run the show.
My big takeaway from his comment is how you got him into arguing from a position that big blocks are OK (handclap and kudos to you). In fact, I have learnt now that even 7.5GB blocks are today theoretically tolerable in at least one respect (validation where tx are pre-validated), although l suspect not in quite a number of other crucial respects.
Wasn't Gavin's doubling end-point 8GB in 2036? Effectively the same end-point!

I am reminded of Mike Hearn's words of wisdom:
Quote
Scaling Bitcoin can only be achieved by letting it grow, and letting people tackle each bottleneck as it arises at the right times. Not by convincing ourselves that success is failure.

One less bottleneck to expect with larger blocks.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 05, 2015, 04:26:29 AM
 #28183

I am reminded of Mike Hearn's words of wisdom:
Quote
Scaling Bitcoin can only be achieved by letting it grow, and letting people tackle each bottleneck as it arises at the right times. Not by convincing ourselves that success is failure.

One less bottleneck to expect with larger blocks.

This is an example of myopic, one-dimensional 'thinking' (illogic) that is promulgated widely by n00bs.

Centralization isn't a bottleneck. Monopolies don't restrict degrees-of-freedom. Neither are an outcome of increasing orphan rate by increasing blocksize relative to block period.

generalizethis
Hero Member
*****
Online Online

Activity: 826


cryptokingdom.me


View Profile WWW
July 05, 2015, 04:55:50 AM
 #28184

And yet people criticize me for not spilling the beans before the software is cooked.


Wrong assertion of why people (at least me and some observable others) are criticizing you. Maybe, someone is, but certainly not everyone....

Gene Siskel, the better half of the movie critic duo Siskel and Ebert, was asked about if he ever wanted to direct--since he was so knowledgeable and his love of films was evident. He stated that he did want to direct, but as long as he was a critic, thought any directing efforts would be a conflict of interest. To put it more simply, he knew he could game his fans into believing his techniques were the best techniques and didn't want the potential to delude himself or the audience--even if his efforts were a sincere and earnest attempt at making a great film.

Rarely, do good critics make better artist. ATM Ben Jonson, the poet/critic is the only example I can think of, but that is more of a tie than him being better at one or the other.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 05, 2015, 06:11:01 AM
 #28185

Rarely, do good critics make better artist.

Except I've already proven three times in my history (twice as main author and the last and most successful as the ONLY* author), that I am also builder of popular software.

https://www.google.com/search?q=neocept+wordup (late 80s and early 90s)
http://relativisticobserver.blogspot.com/2012/01/illustrated-evolution-of-painter-ui.html (mid 90s)
https://www.google.com/search?q=3Dize+coolpage (late 90s and early 00s)

I fell off the cliff in the mid-00s due to mostly what I can summarize as "Philippines" and family background. The details are blinding (see light & dark only) an eye, lost marriage, mid-life crisis, severe STD infection in last week of May 2006 (leading to M.S. by now) and murder of my only non-step sister in last week May 2006, etc..

I really hate this being incited to talk about myself. I know people are going to use this against me. Besides I am interested in creating new things, not the past.

P.S. Armstrong's 8.6 cycle (1000 x Pi days) added to last week of May 2006, is Feb 2015. That was exactly when I began coding a social network which I did ship. First software I've shipped since 2006. Note in 2008 - 2011 period I got off into learning new programming languages such as Haxe, Haskell, and Scala and completely new ways to think about programming. In that period I messed around with numerous projects without shipping any, which maybe was a required gestation period for the new insights and to recharge artistic inspiration. I also got acutely ill (ER, ICU) in May 2012 and chronically hence.

Edit: I am not really acting as a critic, i.e. I haven't changed what I've always done. I am doing engineering analysis for design work. I just happen to share it, which turns out to be critical against inferior engineering.

* except for the 2-3 weeks of coding for the Objects window, for which I paid $30,000 in 2001 (inflation-adjust that!) to a former programmer of Borland C (because I was face down in the bed with gas in my eye to hold the 100% detached retina in place so the lasered joins could solidify).

sickpig
Legendary
*
Offline Offline

Activity: 1106


View Profile
July 05, 2015, 06:44:22 AM
 #28186

interesting, isn't it?

We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China.

Another very good reason people should not mine on Chinese pools.  This is EXTREMELY bad for the Bitcoin network.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
generalizethis
Hero Member
*****
Online Online

Activity: 826


cryptokingdom.me


View Profile WWW
July 05, 2015, 06:54:33 AM
 #28187

Rarely, do good critics make better artist.

Except I've already proven three times in my history (twice as main author and the last and most successful as the ONLY* author), that I am also builder of popular software.

https://www.google.com/search?q=neocept+wordup (late 80s and early 90s)
http://relativisticobserver.blogspot.com/2012/01/illustrated-evolution-of-painter-ui.html (mid 90s)
https://www.google.com/search?q=3Dize+coolpage (late 90s and early 00s)

I fell off the cliff in the mid-00s due to mostly what I can summarize as "Philippines" and family background. The details are blinding (see light & dark only) an eye, lost marriage, mid-life crisis, severe STD infection in last week of May 2006 (leading to M.S. by now) and murder of my only non-step sister in last week May 2006, etc..

I really hate this being incited to talk about myself. I know people are going to use this against me. Besides I am interested in creating new things, not the past.

P.S. Armstrong's 8.6 cycle (1000 x Pi days) added to last week of May 2006, is Feb 2015. That was exactly when I began coding a social network which I did ship. First software I've shipped since 2006. Note in 2008 - 2011 period I got off into learning new programming languages such as Haxe, Haskell, and Scala and completely new ways to think about programming. In that period I messed around with numerous projects without shipping any. I also got acutely ill (ER, ICU) in May 2012 and chronically hence.

Edit: I am not really acting as a critic, i.e. I haven't changed what I've always done. I am doing engineering analysis for design work. I just happen to share it, which turns out to be critical against inferior engineering.

* except for the 2-3 weeks of coding for the Objects window, for which I paid $30,000 in 2001 (inflation-adjust that!) to a former programmer of Borland C (because I was face down in the bed with gas in my eye to hold the 100% detached retina in place so the lasered joins could solidify).

...inciting to talk about myself--LOL.

Until you offer your own coin for peer review, you're going to sound like that know-it-all brat on the basketball court who points out the flaws in everyone else's game, goes on endlessly about how great he is, but never picks up a ball and backs up the talk. Since your American, you've probably heard this: Put up or shut up.

Again, it's not that you are criticizing or refusing peer review, it's that you are simultaneously criticizing and refusing to put your project up for peer review--it may be a good (or even correct) strategy, but don't bitch when others point out its annoyance factor.

Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 05, 2015, 07:28:42 AM
 #28188

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

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

Activity: 1246



View Profile
July 05, 2015, 07:59:28 AM
 #28189

My point about my personal preference where I employed the word "clusterfuck" to describe the hundreds of Cryptonote clones and that Monero's marketing (on these forums) to some extent had to vilify other CN clones in order to assert its dominance of CN clones

I can see why one might want to spin it that way. In fact Monero's dominance was largely assured by the fact that it was the first (even remotely) fairly launched cryptonote coin. The 82% ninja premine fraud was never going to fly. None of the others were sufficiently better in terms of features, leadership, community or anything else, to overcome that lead.

Quote
is instead I would have preferred to add features to CN that would naturally assert dominance over other CN clones.

Again, the dominance was never really in question, but it also isn't clear that "features" are needed (or at least  they don't need to be rushed out in some sort of race) or that a feature war is that way to go. A large part of the user base simply wants a non-transparent blockchain with a credibly reviewed, sufficiently refined, and well maintained (and therefore for these three reasons relatively secure and stable) code base.

Quote
It would behove Monero to be the first CN coin to apply my suggested fix to insure combinatorial analysis of partially overlapping rings can't occur

There is an ongoing question (requiring actually analysis and research, not just forum posts) whether this change to the privacy model is needed or desired. It is being considered.
tvbcof
Legendary
*
Online Online

Activity: 1974


View Profile
July 05, 2015, 08:13:11 AM
 #28190

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

I personally don't see much wrong with replace-by-fee, but I'm old-school and believe that everyone who uses native Bitcoin should do so based on confirmations and tuning the number of confirmations one needs based on the value and importance of a given transaction, operational aspects of the functioning system at a given time, etc. This was, to me, always a fundamental concept of Bitcoin.  Trying to mold Bitcoin into a real-time system has resulted in the problems and hassles which simply do not need to exist, and that is even more the case when sidechains can proxy Bitcoin via a more purpose-oriented instant transaction solutions.

RBF has been described as 'vandalism'.  I don't see it that way as much as a timely and necessary lesson delivered in a way that will make more people perk up their ears and listen before it is to late (if it is not already.)  Irrespective of Satoshi's writings I consider SPV to be fraught with risks and dangers.

The only possible upside here is that perhaps these dick-head miners will pay the ultimate price and that we'll be more-or-less forced to entirely re-do (and more closely tie) the mining and transfer functions of the network.  In doing so, throwing sha256 out on it's ass as an side-effect would be quite positive to my way of thinking.


Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 05, 2015, 08:15:17 AM
 #28191

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

Are they mining on the blockheader during the short time it takes to validate the block, or are they simply skipping validation entirely?

Miners are supposed to secure the network, ehh? If they are just blindly mining on whatever they are fed, they aren't doing a very good job, are they?

Clearly F2Pool messed up.  And they lost 100 BTC because of it.  But that wasn't for SPV mininig during the short amount of time it takes to process the previous block; it was for not bothering to validate the previous block at all.

SPV mining while the previous block is being verified is the profitable strategy, as shown here.  It also serves to produce "defensive blocks" that limit the effective blocksize without the need for a protocol-enforced blocksize limit, as discussed here.

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

Activity: 938



View Profile
July 05, 2015, 08:25:45 AM
 #28192

Clearly F2Pool messed up.  And they lost 100 BTC because of it.  But that wasn't for SPV mininig during the short amount of time it takes to process the previous block; it was from not bothering to validate the previous block at all.

Right, and that's the harmful behavior which led to my response above.

SPV mining while the previous block is being verified is the profitable strategy, as shown here.  It also serves to produce "defensive blocks" that limit the effect blocksize without the need for a protocol-enforced blocksize limit, as discussed here.

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Cool.  Seems we agree then.

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

Activity: 938



View Profile
July 05, 2015, 08:27:37 AM
 #28193

We just need someone to figure out how to constantly feed them invalid blocks. Wink

I'm surprised to hear this from you, Holliday.  Can you explain why you think mining on the blockheader during the short time it takes to validate the block is bad?  It is clearly the profit-maximizing strategy, and I also believe it is ethically sound (unlike replace-by-fee).  

I personally don't see much wrong with replace-by-fee...

I'd like to hear Holliday's take on replace-by-fee. And DeathAndTaxes take on this too (where did he go??).

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63


View Profile
July 05, 2015, 08:52:01 AM
 #28194

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Yes.

Moreover, I don't see why the time spent verifying would be significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash, and looking up that the txn was previously mempool verified. The verification time for a block should be insignificant relative to its download time (unless it's a flood attack of new txns by a miner). Or am I missing something?

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 05, 2015, 08:54:23 AM
 #28195

I see no problem with SPV mining while verifying the previous block. It would also make my above suggestion pointless.

Yes.

Moreover, I don't see why the time spent verifying is very significant. The vast majority of transactions would have been verified by a full node before being included in the block, and then it is just a case of checking the hash. The verification time for a block would then be insignificant relative to its download time.

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time. 

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63


View Profile
July 05, 2015, 08:56:16 AM
 #28196

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

About 600 milliseconds to verify a 1MB block, will be reduced to about 10 ms

https://github.com/bitcoin/bitcoin/pull/6077

https://github.com/bitcoin/bitcoin/pull/5835

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 05, 2015, 09:03:07 AM
 #28197

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

https://github.com/bitcoin/bitcoin/pull/5835

Thanks.  So it looks like the fix was implemented this February, and that now TXs are not re-verified if they're already in mempool?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63


View Profile
July 05, 2015, 09:04:46 AM
 #28198

Great point.  Does anyone know how Bitcoin Core currently works in this regards?  Is every transaction in a block (re-) verified?  Or are the transactions first hashed, and if matched to a TX in mempool not re-verified, thus saving time.  

It would be stupid to forward unverified txns, and it would also be stupid to verify them twice. Easy to fix, so there's no reason for it to verify twice.

https://github.com/bitcoin/bitcoin/pull/5835

Thanks.  So it looks like the fix was implemented this February, and that now TXs are not re-verified if they're already in mempool?

Not sure if any solution is merged yet (see my edit above). But we are talking less than 600ms even without the extra speedup, or 10ms with the speedup.

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
July 05, 2015, 09:07:50 AM
 #28199

...we are talking less than 100ms even without the fix.

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
Mixles
Member
**
Offline Offline

Activity: 63


View Profile
July 05, 2015, 09:17:20 AM
 #28200

Thanks Mixles!  Do you have any thoughts on why F2Pool and AntPool are mining so many empty blocks if the previous block can be validated so quickly?

They gain a 600ms advantage on the verification, then another few seconds on the download, depending on their bandwidth. 600 seconds average in a block, so if they manage to get an advantage of 10 seconds, that's 10/600 or 2% greater profitability than other miners. There will be less incentive for that when the reward halvings happen (fees double relative to subsidy). *shrug* Maybe they are also making some political point, or simply can't be bothered dealing with the txns. But the recent orphans should have cost them a bit. They are playing their own sort of game theories, and not always winning.

Donations to 1SumKArxoEJ1HoGibmj8ygw1DZWYBvjmM
Pages: « 1 ... 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 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 ... 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!