Bitcoin Forum
May 24, 2017, 08:01:44 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   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 ... 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 1461 1462 1463 1464 1465 1466 1467 1468 ... 1559 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1902835 times)
Peter R
Legendary
*
Offline Offline

Activity: 1036



View Profile
July 07, 2015, 03:25:28 AM
 #28341

I noted you posted a result of a classification, did you run the same data through a simple logistic regression with prior size as the treatment? The intercept in the model would be interesting.

Not yet, but I had the same idea!  Ugh…but right now I have to get back to non-bitcoin work...

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

Posts: 1495656104

View Profile Personal Message (Offline)

Ignore
1495656104
Reply with quote  #2

1495656104
Report to moderator
1495656104
Hero Member
*
Offline Offline

Posts: 1495656104

View Profile Personal Message (Offline)

Ignore
1495656104
Reply with quote  #2

1495656104
Report to moderator
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1495656104
Hero Member
*
Offline Offline

Posts: 1495656104

View Profile Personal Message (Offline)

Ignore
1495656104
Reply with quote  #2

1495656104
Report to moderator
1495656104
Hero Member
*
Offline Offline

Posts: 1495656104

View Profile Personal Message (Offline)

Ignore
1495656104
Reply with quote  #2

1495656104
Report to moderator
1495656104
Hero Member
*
Offline Offline

Posts: 1495656104

View Profile Personal Message (Offline)

Ignore
1495656104
Reply with quote  #2

1495656104
Report to moderator
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2184



View Profile
July 07, 2015, 03:33:50 AM
 #28342

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

Bitcoin will not be compromised
Adrian-x
Legendary
*
Offline Offline

Activity: 1358



View Profile
July 07, 2015, 03:44:58 AM
 #28343

why does the 0 tx block have to come "immediately" after a large block?

They don't.  Empty blocks can come after any sized block.  But I just showed that F2Pool is more likely to produce an empty block when the previous block was large, than when the previous block was not large.  

This makes sense to me because I expect that for large blocks, there's more time between when F2Pool has just enough information to begin hashing, and when they have processed the block and sent a new non-empty blocktemplate to their hashers to work one.  If this time is longer, then there's a better chance they get lucky and mine an empty block.  See what I mean?


So one could assume those empty block would never be mined or would be orphaned should a competitor be SPV mining.

I'd also assume this phenomena is also only viable while the block subsidy is high enough that transaction fees are inconsequential. In the near future this strategy would most likely be optimized to including the minimum tx's that are low risk high reward to balanced against the risk of loss for the fiew seconds it would take to include in a block.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 03:45:24 AM
 #28344

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

yeah, i had noticed that.  strange...
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 03:55:22 AM
 #28345

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

this is what they say on their website.  i should try to find out the exact #:

TradeBlock maintains an extensive bitcoin network data architecture with multiple nodes across geographies. With the ability to view and record every message broadcast to the network, including those that are not extensively relayed, unique insights regarding the network may be derived.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 04:30:58 AM
 #28346

Conclusions are valid in substance but in terms of not getting blocks for days, that's not really a big problem for a pool (or solo mining farm) being run as a business. Most expenses (hosting, etc) are going to run monthly, possibly somewhat more often (paying workers), but not daily. Once you look at a one-month window it is about the same as Litecoin: almost certain to find a block in a month. With some ability to draw on reserves or credit in the event of a few bad months it should still be viable.

I think you missed the economic reasoning, which is that pools have to compete at near 0 margins which means any losses due to overpaying some ephemeral miners during periods (e.g. any variant of pool hopping or just miners who come and go for any reason), is bankruptcy relative to those with larger hashrate share which don't incur that variance in profitability.

Variance such as in unit-of-exchange kills currency and it does the same concentrating effect on pools, as they are currently defined in the current network design for PoW coins (which btw I have a fix for[1]).

And that centralizing effect is exacerbated by the in-band (e.g. lower relative to hashrate latency and orphan rate) and out-of-band incentives (e.g. being paid to double-spend a 0-conf, etc) that may apply to any who may be running hidden monopolies via the Sybil attack, perhaps able to run at negative profit margins thus driving smaller pools extinct. Again I challenge any one to prove that pools are not Sybil attacked (meaning multiple pools being effectively owned by the same controlling entity). Since it can't be disproved, then Cypherdoc's assumption that miners are independent can not be proven to be true, yet it can be falsied by the math and economic reasoning I presented above (although some will refuse to admit the math because they can't falsify it with physical evidence).

All of this gets worse as bandwidth requirements are scaled up.

[1] my improvement over CN need not be anonymity (which could just be copied from CN), but rather network characteristics.

Adrian-x
Legendary
*
Offline Offline

Activity: 1358



View Profile
July 07, 2015, 04:42:38 AM
 #28347

Interesting!  
And this is why I like the empirical "block box" approach.  I don't care initially what the mechanism is.  I try to find a simple model that explains the effect, and then, later, ask what that mechanism might be.
But now why would the "latency of the mining process" depend on the size of the previous block?  That doesn't make sense to me, but we just showed empirically that F2Pool is indeed more likely to produce an empty block when the previous block is large.
It wouldn't expect the miner latency part to be size dependant: the miner can't even tell how big the prior block was.  I expect your function relating them to have a big constant term in it! (thats why I asked if you tried other regression approaches. )

I suppose there may be some dependance that is introduced by virtue of what percentage of the miners got the dummy work.  Would be pretty interesting to try to seperate that.

Another trap of empirical analysis in this kind of discussion is that we can only measure how the system is-- but then we use that to project the future;  e.g.  say we didn't have ECDSA caching today, you might then measure that it was taking >2 minutes to verify a maximum size block... and yet 100 lines of code and that cost vanishes; which is bad news if you were counting on it to maintain incentives. Smiley

Miners can't tell as soon as a block header is published, but they can tell once they get the block, according to Peters analysis bigger blocks take longer to propagate so SPV mining fills the gap until the block is known. So yes you're correct they can't know but not knowing isn't a good explanation as to why we see a higher percent of empty block after a big block.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 04:49:12 AM
 #28348

Another trap of empirical analysis in this kind of discussion is that we can only measure how the system is-- but then we use that to project the future;  e.g.  say we didn't have ECDSA caching today, you might then measure that it was taking >2 minutes to verify a maximum size block... and yet 100 lines of code and that cost vanishes; which is bad news if you were counting on it to maintain incentives. Smiley

Good point and more accurate is "we can only measure how we think it is". We don't even have absolute proof that someone isn't running a superior algorithm or hardware solution although we can often make very strong educated inductions.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 04:53:38 AM
 #28349

Interesting!  
And this is why I like the empirical "block box" approach.  I don't care initially what the mechanism is.  I try to find a simple model that explains the effect, and then, later, ask what that mechanism might be.
But now why would the "latency of the mining process" depend on the size of the previous block?  That doesn't make sense to me, but we just showed empirically that F2Pool is indeed more likely to produce an empty block when the previous block is large.
It wouldn't expect the miner latency part to be size dependant: the miner can't even tell how big the prior block was.  I expect your function relating them to have a big constant term in it! (thats why I asked if you tried other regression approaches. )

I suppose there may be some dependance that is introduced by virtue of what percentage of the miners got the dummy work.  Would be pretty interesting to try to seperate that.

Another trap of empirical analysis in this kind of discussion is that we can only measure how the system is-- but then we use that to project the future;  e.g.  say we didn't have ECDSA caching today, you might then measure that it was taking >2 minutes to verify a maximum size block... and yet 100 lines of code and that cost vanishes; which is bad news if you were counting on it to maintain incentives. Smiley

Miners can't tell as soon as a block header is published, but they can tell once they get the block, according to Peters analysis bigger blocks received take longer to propagate process so SPV mining fills the gap until the block is known has been processed. So yes you're correct they can't know but not knowing isn't a good explanation as to why we see a higher percent of empty block after a big block.

ftfy
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 04:55:51 AM
 #28350

If you don't want to be called LeBron until the day Lord Satoshi moves His Holy Coins, I suggest apologizing for accusing the core devs (who write the free code you run) of impropriety/malfeasance/obstructionism/etc.

And you have the audacity to assert I am delusional for having faith in Armstrong's investment in his models and the performance I have observed thereof. At least I am not blind to the existence of my faith — as opposed to first hand knowledge of the open source, which you don't have either in the case of your Lord and I also doubt you've internalized all the source code that has been written by ongoing devs.

Haters gonna hate...

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 05:05:27 AM
 #28351

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:
No clue, no node I have access to is seeing that much-- they may have turned off the minfee rules (not unreasonable for a metrics thing)...

Even given that, again, 37MB doesn't explain your swap.

but turning off minfee rules would only be used to include 0 fee tx's.

look at how much BTC value is included in that 37MB.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 07, 2015, 05:07:30 AM
 #28352

looks like they may have turned off SPV mining.  that would be good.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 05:16:48 AM
 #28353

I favor Adam Backamoto's extension block proposal.

The 1MB blocksize limit reminds me of the old 640k limit in DOS.

Rather than destroy Window's interoperability with the rich/valuable legacy of 8088 based software, that limit was extended via various hacks sublime software engineering.

Where can I find a specification for this extension blocks proposal, so I can determine how this proposal is differentiated from a pegged side chain?

Mike Hearn is so obviously for centralization it is a requirement to separate his objective points, and appears he may have a point about Lightning networks being not viable for much but very specialized interactions (which was also my upthread point about them).

I continue to think existing PoW designs are stuck between a rock and a hard place, thus I am very interested to read more detail about this proposal.


Edit: I found it, http://sourceforge.net/p/bitcoin/mailman/message/34157058/

The only way I see this is differentiated from pegged side chains, is it could be optionally a one-way transfer of BTC to the extension block chain, thus removes the need for the reliance on federated servers.

I understand that if address formats are differentiated between the two chains, then it is claimed one could pay from one chain to other but I can't see how that can work because the miners on the lower bandwidth chain would be SPV miners on the extension block chain. Thus all the dominos (due to orphaned chains) insecurity ramifications of pegged side chains which I argued upthread is untenable, unless you allow the BTC on each chain to have a different value. Afaics, the only reliable way to move pegged value back and forth between chains is as I wrote upthread with very long challenge periods on transferred funds and to use the Blockstream SPV proofs.

Thus one can view this proposal as a trojan horse to require Blockstream's pedded chains (and either the federated servers or the soft fork for the added OP code to eliminate the federated servers). Clever.

However, I still like the proposal for the same reasons I liked pegged side chains. But pleeeaaaase do it correctly. None of the mumbo jumbo about instant transfers between pegged chains. Sheesh.

And note this does nothing to solve the decentralization problem and rather just transfers the centralization to the extension block chain, because the 1MB chain can ultimately be 51% attacked because its relative block rewards will wither as debasement diminishes and transactions increase on the extension block chain (that is unless extension block transactions will have so extremely small fees and the 1MB chain sufficiently high enough fees which is very very unlikely because centralization by definition drives towards monopolistic pricing). Also because per math and economic reasoning above, solo mining is doomed any way.

domob
Legendary
*
Offline Offline

Activity: 971


View Profile WWW
July 07, 2015, 05:35:05 AM
 #28354

look at what we're facing with this latest spam attack.  note the little blip back on May 29 which was Stress Test 1.  Stress Test 2 is the blip in the middle with the huge spikes of the last couple of days on the far right.  this looks to me to be the work of a non-economic spammer looking to disrupt new and existing users via stuck tx's which coincides with the Grexit and trouble in general in the traditional fiat markets.  they want to discourage adoption of Bitcoin.  the fastest way to eliminate this attack on users is to lift the block size limit to alleviate the congestion and increase the expense of the spam:



So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

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

Activity: 1036



View Profile
July 07, 2015, 06:06:02 AM
 #28355

Quote from: domob
So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

Who decides what enough fees is?

I think this whole blocksize debate comes down to ideology.  It's not a technical decision. Some people think we need to keep 1 degree of freedom of control to shape Bitcoin "correctly," while others think we should let destiny take the wheel.

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

Activity: 420


View Profile
July 07, 2015, 06:33:04 AM
 #28356

Quote from: domob
So you think that it would be best to simply put all that spam on the blockchain, and have everyone that ever wants to validate it go through that spam for eternity?  Wouldn't it be better to simply let the network and miners adjust their fee policies instead as they see fit and make sure that the spam is not even mined unless they pay "enough" fees?

Who decides what enough fees is?

Actually you ask precisely the correct question, if you want to find the correct answer for decentralization. Hint, hint. But that answer is more clever and complex than I expect you to find.

I think this whole blocksize debate comes down to ideology.  It's not a technical decision. Some people think we need to keep 1 degree of freedom of control to shape Bitcoin "correctly," while others think we should let destiny take the wheel.

You think that because you are blinded.

My well informed, prescient suggestion is wholeheartedly support the pegged side chain direction; otherwise prepare to exchange your BTC for another monetary unit or accept centralization.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 06:46:28 AM
 #28357

A clinic full of subordinate eye frying minions would be another...

Many of my co-workers kept a stock market ticker within easy visual reach and referred to them about 60 times per hour as they performed the tasks of the day.  That's fine for code monkeys, but...

+1 for dry humor style points  Cheesy

If I were hiring cypherdoc to shill for me he would have been fired about a month ago when he reached an inflection point...

That was when I arrived in the thread.  Wink

As long as he sticks to techno babble and steers clear of excessive ad hominem (against me for example that got his HF case revealed by vokain), then afaics he bolsters his case by remaining the owner of the most read thread on bitcointalk, i.e. in the bitcoin universe.

Note I am no longer fighting with him and I assume he has declared a truce with me also. Best for both of us. I have no skin in the HF debacle (although I feel for vokain et al, they need to learn and bounce back[1]). If he has cajones, Slypherdoc will invest some of his 3000 BTC in NewCoin and perhaps make off like a $billionaire bandit (untraceable). As for justice, don't people who fall for scams have some culpability too? The universe has a way of handing out justice. I lost my eye because of some decisions I had made. I had to own up to responsibility for it, i.e. involving the government in dispensing justice wasn't justified nor efficient. Life is too short.

[1] the day after the event on Dec. 1, 1999 that cost me blindness in my eye, I in my mind and heart forgave the guys who did it to me and decided to moveon. I don't have time for grudges. There is too much stuff I can still do. Until you render me incapable of doing anything, I will try my best to remain positive about life. I did however take up boxing as form of self-defense training and exercise since that event. And I continue to do sprinting training, because the smartest defense is often to run.


cypherdoc, who is paying you now ? (KNC ?)

Perhaps all those who placed preorders with HF.

solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
July 07, 2015, 07:04:25 AM
 #28358

You think that because you are blinded.

My well informed, prescient suggestion is wholeheartedly support the pegged side chain direction; otherwise prepare to exchange your BTC for another monetary unit or accept centralization.

I've got to put this type of comment in the "give-up" file.
It would have merit if the following weren't the case:

x=Software & design optimizations. e.g. BitcoinCore is orders of magnitude faster in many respects than in 2009.
y=Moore's "Law" and Nielsen's "Law" and other relevant descriptions of the rate of improvement in computing technology

x*y > rate-of-growth-of-the-world-economy  (here's a visual)



It is only a matter of time before Bitcoin can handle a large proportion of world transactions. The key thing is not to f*ck up the process in the meantime.

others think we should let destiny take the wheel.

I think this is the only viable option.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 07, 2015, 07:11:17 AM
 #28359

You think that because you are blinded.

My well informed, prescient suggestion is wholeheartedly support the pegged side chain direction; otherwise prepare to exchange your BTC for another monetary unit or accept centralization.

I've got to put this type of comment in the "give-up" file.

...

It is only a matter of time before Bitcoin can handle a large proportion of world transactions. The key thing is not to f*ck up the process in the meantime.

Give up if you don't care about centralization. I for one think a Rottweiler will bite the arms off those who don't care:


And I don't think centralized scaling can attain the network effects of decentralized scaling. Thus I think the heavy end of the scale goes to NewCoin by orders-of-magnitude (note NewCoin might be something created by Blockstream, not limiting it to Trapqoin by Shetty One Eye).

Make your choice do you want NewCoin pegged to BTC or not. That may be the only choice you have and you may not even have that choice as that appears to maybe be inevitable (although I am concerned about TPTB's ability to attack the federated servers if the community is reticient on the necessary OP code soft fork, but the way around that is build the OP code into NewCoin and aim for extracting all the BTC out of Core asap).


iCEBREAKER
Legendary
*
Offline Offline

Activity: 1680


Crypto is the separation of Power and State.


View Profile WWW
July 07, 2015, 07:54:57 AM
 #28360

Rather amazing that he still is posting.  For starters, his counsel should have advised him to stop posting here.

Frap.doc is the world's leading expert on everything; he is the LeBron of Dunning-Kruger.

What makes you think he'd respect some dumb old lawyer's advice, when he refuses to swallow basic technical facts charitably spoon-fed to him by several of the world's top 10 Bitcoin experts?

His saving grace is that the absurd, pro-forma, borderline barratry lawsuit against him is being laughed out of court; the bankruptcy lawyers just did it to look busy and thus justify their fees and the endless process.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange
Fungibility provides privacy as a side effect.  Adam Back 2014

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


Warning Dash is a planned instamine, it wasn't
Pages: « 1 ... 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 1461 1462 1463 1464 1465 1466 1467 1468 ... 1559 »
  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!