Bitcoin Forum
December 04, 2016, 08:41:03 PM *
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 ... 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 1461 1462 1463 1464 1465 1466 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804281 times)
iCEBREAKER
Legendary
*
Online Online

Activity: 1498


Crypto is the separation of Power and State.


View Profile WWW
July 06, 2015, 07:29:41 PM
 #28301

since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks.

Basic misunderstanding there

Quote
how can that be?  mining pools all use a full node around which they coordinate their mining.  all full nodes are relatively in sync with their mempools
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.
 
Quote
it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago.  the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.
Almost none of the blocks have been 1MB, the issues arise before then.

The more gmax patiently ELI5s basic Bitcoin 101 to Frap.doc, the more Frap.doc looks like a five year old.   Cheesy

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
1480884063
Hero Member
*
Offline Offline

Posts: 1480884063

View Profile Personal Message (Offline)

Ignore
1480884063
Reply with quote  #2

1480884063
Report to moderator
1480884063
Hero Member
*
Offline Offline

Posts: 1480884063

View Profile Personal Message (Offline)

Ignore
1480884063
Reply with quote  #2

1480884063
Report to moderator
1480884063
Hero Member
*
Offline Offline

Posts: 1480884063

View Profile Personal Message (Offline)

Ignore
1480884063
Reply with quote  #2

1480884063
Report to moderator
There are several different types of Bitcoin clients. EWallets are like banks -- a central organization has complete control over your money. You shouldn't put much money in EWallets.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480884063
Hero Member
*
Offline Offline

Posts: 1480884063

View Profile Personal Message (Offline)

Ignore
1480884063
Reply with quote  #2

1480884063
Report to moderator
1480884063
Hero Member
*
Offline Offline

Posts: 1480884063

View Profile Personal Message (Offline)

Ignore
1480884063
Reply with quote  #2

1480884063
Report to moderator
domob
Legendary
*
Offline Offline

Activity: 936


View Profile WWW
July 06, 2015, 07:33:19 PM
 #28302

meanwhile, my full nodes sit here totally unstressed and under-utilized.  Roll Eyes



i thought gmax et al said "large" blocks were going to collapse my nodes?

I've been reading this thread since a long time, and mostly enjoyed the economic insights it used to be about.  However, I can only agree with those who see cypherdoc's reputation fading with his supposedly technical comments like the one above.  It has been pointed out repeatedly and should be clear as day - currently we have the 1 MB limit you are complaining about.  That's precisely why your nodes are "unstressed and under-utilized".  From the current stress on your nodes, you can at best guess very vaguely at what they would be doing with larger blocks.  I don't see why that's an argument you make in favour of increasing the blocksize.  (Same as your comments about "full" blocks that were debunked by others above.)

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

Activity: 1764



View Profile
July 06, 2015, 08:33:00 PM
 #28303

since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks.  in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.
Basic misunderstanding there--- Being a larger miner has two effects: One is throughput not latency related: Being larger creates a greater revenue stream which can be used to pay for better resources.   E.g. if the income levels support one i7 CPU per 10TH/s of mining, then a 10x larger pool can afford 10x more cpus to keep up with the overall throughput of the network, which they share perfectly (relay network is about latency not so much about throughput-- its at best a 2x throughput improvement, assuming you were bandwidth limited);    the other is latency related,   imagine you have a small amount of hashpower-- say 0.01% of the network-- and are a lightsecond away on the moon.  Any time there is a block race, you will lose because all of the earth is mining against you because they all heard your block 1+ seconds later.  Now imagine you have 60% of the hashpower on the moon, in that case you will usually win because even though the earth will be mining another chain, you have more hashpower. For latency, the size of miner matters a lot, and the size of the block only matters  to the extent that it adds delay.

i don't believe that.  when i ran my small solo mining pool, i'll bet that the quality of my resources and bandwidth were superior to that of the large mining pools i've seen in the videos.  furthermore, if my small pool is connected to the same relay network as a large miner, then the transmission of our respective blocks on the moon should reach earth at the same time, thus, our respective chances to find the next block simply goes back to our respective % hashrates compared to the network.
Quote
When it comes to orphaning races miner sizes matters, in some amount that is related to the product of the size-of-the-miner and time it takes to validate a block.

Quote
how can that be?  mining pools all use a full node around which they coordinate their mining.  all full nodes are relatively in sync with their mempools  
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.

well, that was precisely Peter's mathematical point the other day that you summarily dismissed.  f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC.  they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure.  that's why their average validation times are 16-37sec long and NOT the 80ms you claim.  thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks.  thanks for making his point.

it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.

Quote

IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

Quote
pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago.  the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.

Almost none of the blocks have been 1MB, the issues arise before then. _Consistent_ 1MB blocks wouldn't have been supportable on the network at the time that limit was put in place-- back in the 0.5.x-ish days we were getting up to 2minutes for a 100k block to reach the whole network; the 1MB was either forward-looking, set too high, or only concenred about the peak (and assuming the average would be much lower) ... or a mixture of these cases.

these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool.  full blocks have been recognizable as 950+ and 720+kB.  this is undeniable.
Quote

Quote
have the Chinese miners given you a technical reason why they're SPV'ing?

F2Pool reported that as block sizes grew they saw increased orphaning rates and that they were seeing an orphan rate of 4% though this was at a time before the relay network and when GHash in europe had ~50% of the hashpower under them.  Excluding the recent issues they've had almost no orphans since, they report.

if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal for an immediate inc to 8MB?
Quote

Then why don't we decrease the blocktime from 10 min down to let's say 2 min. This way we can also have more transactions/second without touching the blocksize.
Ouch,  the latency related issues issues are made much worse by smaller interblock gaps once they are 'too small' relative to the network radius. When a another block shows up on the network faster than you can communicate about your last you get orphaned.  And for throughput related bottlenecks it doesn't matter if X transactions come in the form of a 10mb block or 10 1mb blocks.




cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 06, 2015, 08:37:02 PM
 #28304

meanwhile, my full nodes sit here totally unstressed and under-utilized.  Roll Eyes



i thought gmax et al said "large" blocks were going to collapse my nodes?

I've been reading this thread since a long time, and mostly enjoyed the economic insights it used to be about.  However, I can only agree with those who see cypherdoc's reputation fading with his supposedly technical comments like the one above.  It has been pointed out repeatedly and should be clear as day - currently we have the 1 MB limit you are complaining about.  That's precisely why your nodes are "unstressed and under-utilized".  From the current stress on your nodes, you can at best guess very vaguely at what they would be doing with larger blocks.  I don't see why that's an argument you make in favour of increasing the blocksize.  (Same as your comments about "full" blocks that were debunked by others above.)

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
July 06, 2015, 08:43:03 PM
 #28305

since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks.  in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.
Basic misunderstanding there--- Being a larger miner has two effects: One is throughput not latency related: Being larger creates a greater revenue stream which can be used to pay for better resources.   E.g. if the income levels support one i7 CPU per 10TH/s of mining, then a 10x larger pool can afford 10x more cpus to keep up with the overall throughput of the network, which they share perfectly (relay network is about latency not so much about throughput-- its at best a 2x throughput improvement, assuming you were bandwidth limited);    the other is latency related,   imagine you have a small amount of hashpower-- say 0.01% of the network-- and are a lightsecond away on the moon.  Any time there is a block race, you will lose because all of the earth is mining against you because they all heard your block 1+ seconds later.  Now imagine you have 60% of the hashpower on the moon, in that case you will usually win because even though the earth will be mining another chain, you have more hashpower. For latency, the size of miner matters a lot, and the size of the block only matters  to the extent that it adds delay.

When it comes to orphaning races miner sizes matters, in some amount that is related to the product of the size-of-the-miner and time it takes to validate a block.

Quote
how can that be?  mining pools all use a full node around which they coordinate their mining.  all full nodes are relatively in sync with their mempools  
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.

IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

Quote
pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago.  the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.

Almost none of the blocks have been 1MB, the issues arise before then. _Consistent_ 1MB blocks wouldn't have been supportable on the network at the time that limit was put in place-- back in the 0.5.x-ish days we were getting up to 2minutes for a 100k block to reach the whole network; the 1MB was either forward-looking, set too high, or only concenred about the peak (and assuming the average would be much lower) ... or a mixture of these cases.

Quote
have the Chinese miners given you a technical reason why they're SPV'ing?

F2Pool reported that as block sizes grew they saw increased orphaning rates and that they were seeing an orphan rate of 4% though this was at a time before the relay network and when GHash in europe had ~50% of the hashpower under them.  Excluding the recent issues they've had almost no orphans since, they report.

Then why don't we decrease the blocktime from 10 min down to let's say 2 min. This way we can also have more transactions/second without touching the blocksize.
Ouch,  the latency related issues issues are made much worse by smaller interblock gaps once they are 'too small' relative to the network radius. When a another block shows up on the network faster than you can communicate about your last you get orphaned.  And for throughput related bottlenecks it doesn't matter if X transactions come in the form of a 10mb block or 10 1mb blocks.



I have highlighted in red what should be considers external capital investment costs and part of the business decisions of miners, how these issues are resolved is not part of the bitcoin protocol. Its not up to the developers to optimize for miners in China or the moon, or on earth for that matter.

If someone was to build 60% of the hashing power, all the power too them, the Bitcoin protocol manages only so much and then there is game theory and the Nash equilibrium to manage the extreme circumstances like 60% of the hashing power coming from a single facility in China or the Moon.    

When it comes to orphaning races miner sizes matters as does optimizing your business to leverage the inherent limitations in technology, and the guidelines of the protocol. Managing orphans is an essential function that keeps the incentives in the Bitcoin Protocol distributed and functioning, reporting a 4% orphan rate from memory when your pool was small and starting out is very different than publishing verifiable numbers. The protocol was designed with the fact that we dont live in a harmonious world where resources are not optimally distributed.

Why should we change it?

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

Activity: 280


View Profile
July 06, 2015, 08:43:41 PM
 #28306

Even if mining pools set higher fees, aren't the unconfirmed TX's still added to their mempools?
No.

In other words, cypherdoc is clueless about how Bitcoin works.

Moar like the LeBron of Lasik, am I right?   Cheesy

Doubtful.  Dr. Lowelife spends every waking moment on bitcointalk and reddit so it seems.  A malpractice suite which stuck is one hypothesis which springs to mind, and could explain an early and intense interest in asset protection.  A clinic full of subordinate eye frying minions would be another.  Neither these or countless others are really interesting enough for me to spend much time on, but perhaps others who are more into such things would ferret out this mystery.

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 for someone doing eye surgery with laser beams it's an entirely different ball of wax.



So now we know what his "highly successful business" entailed.   Roll Eyes
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 2016



View Profile
July 06, 2015, 09:38:13 PM
 #28307

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

Quote
have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.

Quote
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.
well, that was precisely Peter's mathematical point the other day that you summarily dismissed.  f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC.  they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure.  that's why their average validation times are 16-37sec long and NOT the 80ms you claim.  thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks.  thanks for making his point.
PeterR wasn't saying anything about mempools, and-- in fact-- he responded expressing doubt about your claim that mempool size had anything to do with this.  Moreover, I gave instructions that allow _anyone_ to measure verification times for themselves.  Your argument was that miners would be burned by unconfirmed transactions, I responded that this isn't true-- in part because they can keep whatever mempool size they want.

To further make the point about mempools, here is what the mempool looks like on a node with mintxfee=0.0005 / minrelaytxfee=0.0005 set:


$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 301,
    "bytes" : 271464
}


Quote
it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.
Their response was not to use smaller blocks, their response was to stop validating entirely.  (And, as I pointed out-- other miners are apparently mining without validating and still including transactions).

Quote
these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool.  full blocks have been recognizable as 950+ and 720+kB.  this is undeniable.
If we're going to accept that every correlation means causation;  what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

In this case, these forks are only visible by someone mining an invalid block, which no one had previously done for over a year.

Quote
if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal
They are no longer seeing any orphans at all, they "solved" them by skipping validation entirely. They opposed that initial proposal, in fact, and suggested they could at most handle 8MB, which brought about a new proposal which used 8MB instead of 20MB though only for a limited time. Even there the 8MB was predicated on their ability to do verification free mining, which they may be rethinking now.

Quote
i don't believe that.
I am glad to explain things to people who don't understand, but you've been so dogmatically grinding your view that it's clear that every piece of data you see will only "confirm" things for you; in light of that I don't really have unbounded time to waste trying. Perhaps someone else will.
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 06, 2015, 09:55:52 PM
 #28308

... what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?


I will not be surprised if this is true. Only I'll expect higher price  ... few millions. He is fighting hard.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 06, 2015, 10:10:48 PM
 #28309

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

Quote
have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.

Quote
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.
well, that was precisely Peter's mathematical point the other day that you summarily dismissed.  f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC.  they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure.  that's why their average validation times are 16-37sec long and NOT the 80ms you claim.  thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks.  thanks for making his point.
PeterR wasn't saying anything about mempools, and-- in fact-- he responded expressing doubt about your claim that mempool size had anything to do with this.  Moreover, I gave instructions that allow _anyone_ to measure verification times for themselves.  Your argument was that miners would be burned by unconfirmed transactions, I responded that this isn't true-- in part because they can keep whatever mempool size they want.

To further make the point about mempools, here is what the mempool looks like on a node with mintxfee=0.0005 / minrelaytxfee=0.0005 set:


$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 301,
    "bytes" : 271464
}


Quote
it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.
Their response was not to use smaller blocks, their response was to stop validating entirely.  (And, as I pointed out-- other miners are apparently mining without validating and still including transactions).

Quote
these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool.  full blocks have been recognizable as 950+ and 720+kB.  this is undeniable.
If we're going to accept that every correlation means causation;  what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

In this case, these forks are only visible by someone mining an invalid block, which no one had previously done for over a year.

Quote
if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal
They are no longer seeing any orphans at all, they "solved" them by skipping validation entirely. They opposed that initial proposal, in fact, and suggested they could at most handle 8MB, which brought about a new proposal which used 8MB instead of 20MB though only for a limited time. Even there the 8MB was predicated on their ability to do verification free mining, which they may be rethinking now.

Quote
i don't believe that.
I am glad to explain things to people who don't understand, but you've been so dogmatically grinding your view that it's clear that every piece of data you see will only "confirm" things for you; in light of that I don't really have unbounded time to waste trying. Perhaps someone else will.


On my phone now so this is going to be hard to respond.

First, nice try pretending UTXO is not potentially a memory problem. We've had long debates about this on this thread so you are just being contrary.

Second, my reference to Peters argument above aid nothing about mempool; I was talking  about block verification times. You're obfuscation again.

Third, unlike SPV mining if 0 tx blocks like now, didn't mean they would do the same without a limit. Perhaps they would pare down block sizes to an efficient level of other larger miners were allowed to clear out the unconfirmed TX set.

Fourth, you have no shame do you with the ad hominems? No, I'm not endorsing for any company like I told everyone ahead of time I was doing for HF.
tvbcof
Legendary
*
Online Online

Activity: 1974


View Profile
July 06, 2015, 10:11:55 PM
 #28310


... what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

I will not be surprised if this is true. Only I'll expect higher price  ... few millions. He is fighting hard.

A bit to hard I'd say.  He's losing his support base.  The more technical people first, but eventually most of those who can be dazzled by technobabble word-salad that cypherdoc himself doesn't really understand will fall away as well.

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


traderCJ
Sr. Member
****
Offline Offline

Activity: 280


View Profile
July 06, 2015, 10:19:35 PM
 #28311


... what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

I will not be surprised if this is true. Only I'll expect higher price  ... few millions. He is fighting hard.

A bit to hard I'd say.  He's losing his support base.  The more technical people first, but eventually most of those who can be dazzled by technobabble word-salad that cypherdoc himself doesn't really understand will fall away as well.

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



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

Activity: 1974


View Profile
July 06, 2015, 10:23:20 PM
 #28312


... what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

I will not be surprised if this is true. Only I'll expect higher price  ... few millions. He is fighting hard.

A bit to hard I'd say.  He's losing his support base.  The more technical people first, but eventually most of those who can be dazzled by technobabble word-salad that cypherdoc himself doesn't really understand will fall away as well.

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

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

Yup.  He had an opportunity to save face and bow out that way but he's blown that one.  Now he'll have to think of a different way, or hopefully stick around and continue to show the world the Gavinista's true colors.


Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 06, 2015, 10:27:20 PM
 #28313

cypherdoc, who is paying you now ? (KNC ?)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
July 06, 2015, 10:29:47 PM
 #28314

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

LOL, no one.
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
July 06, 2015, 10:33:29 PM
 #28315

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

LOL, no one.

Then you are losing money. :-)
BlindMayorBitcorn
Hero Member
*****
Offline Offline

Activity: 728


Blockchain Theorist


View Profile
July 06, 2015, 10:37:54 PM
 #28316

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

Here bro. I heard you liked tactical pitchforks Grin


Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
tvbcof
Legendary
*
Online Online

Activity: 1974


View Profile
July 06, 2015, 10:38:34 PM
 #28317


no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks

Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

Quote
have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.

"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.
...

Thanks for this tid-bit about the UTXO database.  This is the kind of info that someone who is mildly familiar with database technology but doesn't really want to make a lifes' work of studying the technicals find cumbersome to pick out.  Especially since modern Bitcoin is already past what is realistic to run behind my ($80/mo) connectivity so unless/until I set up a VM somewhere it's kind of a textbook exercise.

Just from knowing a little about database tuning and ram vs. disk-backed memory, I have always wondered if people have make projections about performance of the validation process under different scenarios and whether they can/will become problematic.  One think I've always wondered if it would be possible to structure transactions such that they would load validation processes to heavily on queue, and particularly if it is common case to push more and more data out of the dbcache.  Any thoughts on this that can be quickly conveyed?


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 06, 2015, 11:14:42 PM
 #28318

I favor Adam Backamoto's

stop equating Adam to Satoshi.  no contest.

you have a serious Daddy problem.

No where near as serious as those who consider cypherdoc to be some sort of daddy figure.  There are probably vastly fewer who consider you to be 'the LeBron James of Bitcoin' than you and your attorney might imagine.  Probably there are a handful though which is pretty sad.

The LeBron assertion is hilariously funny though one way or another.  Whether it was you or your attorney who came up with that one, kudos for the comic relief.

It behoves him to continue posting and proving his thread has the largest readership on bitcointalk by far because it assures he will win his case...

...the more you guys fight him and post here, the more you help him retain 3000 BTC (perhaps in collusion with HF if they aren't just derelict and who knows  Huh perhaps even the judge via his well connected Obama legal counsel  Huh that being wild speculation Huh  not an accusation ...).

Don't you realize he is either making the technical errors on purpose or it is a strategy he inherited by dumbdorc luck!

If they wanted to win, they wouldn't argue that DorkyDoc didn't do adequate promotion (because there is an entire thread on this forum showing he did, and now we have a core Dev admitting he invested 100 BTC based on Dorc's thread which adds validity to his promotional value). Rather they would...

P.S. Gmax you committed a category error. It doesn't matter to his case if he slobbers on the technology (and because so many people can't understand the technology including some of the readers here, the attorneys, and the judge); it only matters that he has a huge following.

tvbcof
Legendary
*
Online Online

Activity: 1974


View Profile
July 06, 2015, 11:16:23 PM
 #28319


It behoves him to continue posting and proving his thread has the largest readership on bitcointalk by far because it assures he will win his case...

...the more you guys fight him and post here, the more you help him retain 3000 BTC.

Don't you realize he is making the technical errors on purpose!


Good catch.  I had not thought of that.


TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
July 06, 2015, 11:22:42 PM
 #28320

The coin needs to be the first legitimate instance of its kind, had a fair start/emission, and a market niche
-----------------------------------------------------------------------------------------------------------------
Litecoin FAIL (not the first of its kind)
Peercoin FAIL (no market niche)
Bytecoin FAIL (not fair start)
Boolberry FAIL (not the first of its kind)
Ethereum FAIL (questionable start)
All shitcoins FAIL (2-3 counts)

Only BTC and XMR fulfill all conditions, so it makes sense to invest into them (and them alone). To be fully hedged, you can keep 99.8% in BTC and set 0.2% aside in XMR. Going over this ratio, is overinvesting in XMR.

It is not hard to come with these understandings after a generous overview of the top 50 altcoins, reason why I'm as uninpressed with LTC market as with its innovative features (none).

+1 on rpietila's logic.

I would only add it needs a reasonable shot of attaining critical mass, so the niche needs to be evaluated for that probability.

I am thinking Trapqoin has a potentially large market  Tongue

I'm thinking about maybe making Trapqoin by Shetty One Eye.

Pages: « 1 ... 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 1461 1462 1463 1464 1465 1466 ... 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!