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

Pages: « 1 ... 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 [1522] 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1806920 times)
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 13, 2015, 08:30:03 PM
 #30421

As sickpig suggested, it would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer.

i never did quite get this part.  can you explain?

Sure.  

Why do we have a consensus layer in the first place?  It is a way for us to agree on what transactions are valid and what transactions are invalid.  For example, we all agree that Alice shouldn't be able to move Bob's coins without a valid signature, and that Bob shouldn't be able to create coins out of thin air.  The consensus layer is about obvious stuff like that.  In order for Bitcoin to function as sound money, we need to agree on "black-or-white" rules like this that define which transactions are valid and which are invalid.

Notice that the paragraph above discusses valid and invalid transactions.  No where did I say anything about blocks.  That's because we only really care about transactions in the first place!  In fact, how can a block be invalid just because it includes one too many valid transactions?  

Satoshi added the 1 MB limit as an anti-spam measure to deal with certain limitations of Bitcoin's transport layer--not as a new rule for what constitutes a valid transaction.  We should thus think of every block that is exclusively composed of valid transactions as itself valid.  The size of the block alone should not make it invalid.  Instead, if a block is too big, think of it as likely to be orphaned (a "gray" rule) rather than as invalid (a black-or-white rule).  Perhaps above a certain block size, we're even 100% sure that a block will be orphaned; still we should view it as a valid block!  It will be orphaned because the transport layer was insufficient to transport it across the network--not because there was anything invalid about it.

it was the term "layer" that made me question.  when i hear "transport layer" i start thinking technical like TCP/IP, SSL/TLS, http, https, etc.  

so nothing technical, just layered "concepts".

Yes, that was confusing in hindsight.  We're just proposing a new way to think about it. 

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

Posts: 1481263975

View Profile Personal Message (Offline)

Ignore
1481263975
Reply with quote  #2

1481263975
Report to moderator
1481263975
Hero Member
*
Offline Offline

Posts: 1481263975

View Profile Personal Message (Offline)

Ignore
1481263975
Reply with quote  #2

1481263975
Report to moderator
1481263975
Hero Member
*
Offline Offline

Posts: 1481263975

View Profile Personal Message (Offline)

Ignore
1481263975
Reply with quote  #2

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

Activity: 1064


Gresham's Lawyer


View Profile WWW
August 13, 2015, 08:36:02 PM
 #30422


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

You know that you can do this now, right?  And always could.

The code is open source, you can (of course) just change it and compile.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 08:40:49 PM
 #30423

here's further evidence the Reddit mods are steering the blocksize debate. they're letting this guy spam attack me with false allegations despite me reporting him.  same post about a dozen times:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1x6fl
Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 13, 2015, 08:41:57 PM
 #30424


At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.

I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way.  What if, instead, we just make it very easy for node operators to adjust their block size limit.  Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ."  What would happen?  

Personally, I'd just select some big block size limit, like 32 MB.  This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes.  I'd expect many people to do the same thing.  Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size.  We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks.  Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows.

TL/DR: maybe we don't need a strict definition for the max block size limit.

You know that you can do this now, right?  And always could.

The code is open source, you can (of course) just change it and compile.

I know that I could, but I also know that I won't, which is sort of another way of saying that I can't!

However, if everyone knows that everyone else could change the limit with just a couple key strokes, then the dynamics of the situation will be very different!  I know that in that case I both could and would change my block size limit.  Better yet: if, as awemany suggested, the software comes with no default block size limit, and the node operator has to pick something, then things will get very interesting.  

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

Activity: 1526


View Profile
August 13, 2015, 09:33:07 PM
 #30425

What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on.  IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.  However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I don't think it would be a problem.  Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size.  Worst case, a large block gets orphaned and nobody tries again for a while.  But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit).

IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.

This doesn't put the power directly in the miners' hands.  It keeps the power where it already is: in everybody's hands!  It just makes it much easier for people to exercise the power they already possess.  

Quote
However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I disagree.  For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better.  I expect many people would do the same thing.  Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned.

Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems.



Okay... I'm going to have to agree with that.

But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before.  By publishing a block of size X + 1 byte, the attacker effectively splits the network in half.  If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network.  Even if the attacker only has small hashpower, it will still cause a hash war between the two forks.

I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 13, 2015, 09:41:21 PM
 #30426

What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on.  IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.  However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I don't think it would be a problem.  Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size.  Worst case, a large block gets orphaned and nobody tries again for a while.  But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit).

IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.

This doesn't put the power directly in the miners' hands.  It keeps the power where it already is: in everybody's hands!  It just makes it much easier for people to exercise the power they already possess.  

Quote
However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I disagree.  For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better.  I expect many people would do the same thing.  Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned.

Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems.



Okay... I'm going to have to agree with that.

But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before.  By publishing a block of size X + 1 byte, the attacker effectively splits the network in half.  If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network.  Even if the attacker only has small hashpower, it will still cause a hash war between the two forks.

I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for.

awemany might have answered your question here:

https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/cu1tzuh

IOW, as a full node operator wanting to stay on the longest chain at all times, set your maximum block size high enough so as  not to be exceeded.
notme
Legendary
*
Offline Offline

Activity: 1526


View Profile
August 13, 2015, 09:55:00 PM
 #30427

What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on.  IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.  However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I don't think it would be a problem.  Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size.  Worst case, a large block gets orphaned and nobody tries again for a while.  But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit).

IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.

This doesn't put the power directly in the miners' hands.  It keeps the power where it already is: in everybody's hands!  It just makes it much easier for people to exercise the power they already possess.  

Quote
However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.

I disagree.  For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better.  I expect many people would do the same thing.  Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned.

Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems.



Okay... I'm going to have to agree with that.

But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before.  By publishing a block of size X + 1 byte, the attacker effectively splits the network in half.  If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network.  Even if the attacker only has small hashpower, it will still cause a hash war between the two forks.

I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for.

awemany might have answered your question here:

https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/cu1tzuh

IOW, as a full node operator wanting to stay on the longest chain at all times, set your maximum block size high enough so as  not to be exceeded.

Ensuring you are part of the supermajority by looking at votes should give you a safe least upper bound.  Ensuring you have the largest size possible is a bit excessive and will raise your costs too much compared to someone who only upgrades when they are coming close to falling out of the supermajority (however they define that).

If miners don't take the supermajority into account, it could be a risk to the network.  Including a risk to the nodes with the highest limits as they suddenly become part of a chain with half as much hash power.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
August 13, 2015, 10:18:32 PM
 #30428

here's further evidence the Reddit mods are steering the blocksize debate. they're letting this guy spam attack me with false allegations despite me reporting him.  same post about a dozen times:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1x6fl


Yesterday you were complaining about mod "censorship" and today you are demanding the same mods censor posts you don't like.

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

Activity: 714



View Profile
August 14, 2015, 02:45:07 AM
 #30429

I don't know if this is a problem for anyone, but anyway...

A fork in the software, as in bitcoin XT, is much welcome, as is alternative implementations of the basic libraries that are used. The more diverse the software, the more antifragile is the system.

A fork of the blockchain is different. Obviously, we do not want a fork to parallell the original for ever, that would create confusion for users and stir up some turbulence. On the other hand, we want forking the chain to be possible, and in fact it is necessary for the basic function that there is no single point deciding what is the right branch, it is based partly on randomness. It is also necessary to create and maintain the consensus on what bitcoin is. To the dangers: If the rules of one branch is distinctly different, we will have two coins. That would be almost the same as creating an altcoin. Note that the definition of altcoin is based only on the fact that bitcoin was first, otherwise there is no fundamental difference and you could also call bitcoin itself an altcoin, as in bitcoin comprises all coins based on blockchains. So the branch can live its own life.

When the branch is almost, but not quite, the same as the original, then what? The answer is that the two branches can not go on for long, one is bound to win. It is like turning a pendulum upside down, the situation is not stable. The reason is that liquidity is essential to money, money that has lower liquidity compared to a money type with essentially the same properties but higher liquidity, will lose. And the level of liquidity is decided by the number of users. Therefore, a blocksize based fork, if there is a chain fork at all, will be short lived. Meaning hours.

Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 14, 2015, 02:55:11 AM
 #30430

So if there is a blocksize based fork, and the largeblock branch can hold the lead for a few hours, the branch based on smallblocks will disappear quickly. There will probably not be time to establish the infrastructure to allow trading between them, and no time to create confusion whether a specific payment is valid or not.

If the largeblock branch can not hold for a few hours, it will disappear, it will act like a failed attempt at changing the blocksize. A new largeblock can then be attempted later, when a miner is sufficiently certain that it will succeed.

tl;dr A fork based on a largeblock is totally not destructive.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 14, 2015, 03:05:14 AM
 #30431

I think the answer is much simpler than this.

Which network will be easier and less expensive  to plug up with a spam attack for a prolonged period of time?
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 14, 2015, 03:08:35 AM
 #30432

I think the answer is much simpler than this.

Which network will be easier and less expensive  to plug up with a spam attack for a prolonged period of time?

If that was a comment directed towards me - I don't understand.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
August 14, 2015, 03:18:53 AM
 #30433

So the issue I see with BIP100 is if the majority of Miners collude to form a cartel to set the limit they can set it too low to suite the cartel's preferences, the difference between BIP 100 and BIP 101 to me, is that BIP100 miners cant leave the carrell and mine bigger blocks if there is a market for it, in the case with BIP100 the cartel needs to vote.

Whereas with BIP101 Miners can form a cartel but if it becomes more profitable to mine larger blocks they can break from the cartel without having to get a majority vote.

the innate incentive that limits the ability for cartels to form is important, BIP 100 is a change to an innate incentive in Bitcoin.  

Playing devils advocate here and creating a worse case scenario, imagine the optimal market equilibrium for block size and transaction cost resulted in the demand for a 16MB block, a majority of miners could form a voting cartel, and set a limit at 8MB, there would be no reason to do this in a free market because they would loose revenue, but in a controlled market for transaction fees where Sidechains exist, it becomes possible to manipulate the block size to undermine competition, a simple way to do it would be to limit your completion's revenue by limiting block size, if you were uncompetitive in block propagation that would give you an unfair advantage. In the case with SideChains the cartel could supplement revenue by being paid to Merge Mining side-chains that other miners dont have assess too.

giving the power to set block size to the miners by vote of the majority seems to me will ultimately tend towards centralization, where in BIP101 this power is vested in the market and incentives that govern it. More important, it's not a change to Satosis design which seems to have the incentive balance just right.  

I agree that there is more risk inherent in BIP 100 than 101 and 101 has simplicity in line with Satoshi's original vision.
There is a risk that miners might vote for a lower block limit than the ecosystem needs and cripple volumes. Although I think that incentives will prevent it, in the same way that the 3 different pools which got 50% of the network hashing power continued to behave. Miners don't want to cripple the ecosystem as it will tank the price, and they do want to handle more tx as it means more fees, which will be really important after the reward halves next year.

If miners made a small block limit to force volume onto a SC which is merge-mined by them it would be obvious to the community who can then boycott's the rogue SC's merchant services, and use a different SC. Also, this type of event should be seen a mile off and a new BIP raised to modify the voting, or just go with 101 instead.

At present I think either BIP is a vast improvement over the existing situation.

Peter R
Legendary
*
Offline Offline

Activity: 938



View Profile
August 14, 2015, 03:28:07 AM
 #30434

So if there is a blocksize based fork, and the largeblock branch can hold the lead for a few hours, the branch based on smallblocks will disappear quickly. There will probably not be time to establish the infrastructure to allow trading between them, and no time to create confusion whether a specific payment is valid or not.

If the largeblock branch can not hold for a few hours, it will disappear, it will act like a failed attempt at changing the blocksize. A new largeblock can then be attempted later, when a miner is sufficiently certain that it will succeed.

tl;dr A fork based on a largeblock is totally not destructive.

Yes!

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

Activity: 1078


100 satoshis -> ISO code


View Profile
August 14, 2015, 03:33:57 AM
 #30435

That is because bitcoins are a unique collectible unlike anything the world has seen since gold. Unfortunately much like gold some characteristics limit its direct use as a mean of exchange. Gold's shortcoming is in its physicality, Bitcoin's own is the decentralization tradeoff.


I think Bitcoins are absolutely a unique collectible. I hate to "call up" authority but its own creator was well aware of that:

Quote
Maybe it could get an initial value circularly as you’ve suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it. - Satoshi Nakamoto

Quote
It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. -Satoshi Nakamoto

Quote
Aug. 27, 2010: Bitcoins have no dividend or potential future dividend, therefore not like a stock. (They’re) more like a collectible or commodity. - Satoshi Nakamoto

Satoshi quotes which are correct, but also relate to when BTC was the only cryptocurrency.
Today http://coinmarketcap.com has about 600 listed, including - if I choose one at random - Monero.

So, is a monero a unique collectible unlike anything the world has seen since gold? Yes or No!

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 14, 2015, 03:42:07 AM
 #30436

here's further evidence the Reddit mods are steering the blocksize debate. they're letting this guy spam attack me with false allegations despite me reporting him.  same post about a dozen times:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1x6fl


Yesterday you were complaining about mod "censorship" and today you are demanding the same mods censor posts you don't like.

it's a repetitive spam attack; over a dozen times the exact same slanderous post attempt at character assassination.  have you forgotten the case seems to be going nowhere and that i deny the allegations?

everybody gets it already. i am a BitcoinXT proponent and i am a threat to you Cripplecoiners.  the HF dispute has nothing to do with it as much as you'd like to tie the two together.

but of course, i wouldn't expect you to see the difference.
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1512


Crypto is the separation of Power and State.


View Profile WWW
August 14, 2015, 04:18:26 AM
 #30437

here's further evidence the Reddit mods are steering the blocksize debate. they're letting this guy spam attack me with false allegations despite me reporting him.  same post about a dozen times:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1x6fl


Yesterday you were complaining about mod "censorship" and today you are demanding the same mods censor posts you don't like.

it's a repetitive spam attack; over a dozen times the exact same slanderous post attempt at character assassination.  have you forgotten the case seems to be going nowhere and that i deny the allegations?

everybody gets it already. i am a BitcoinXT proponent and i am a threat to you Cripplecoiners.  the HF dispute has nothing to do with it as much as you'd like to tie the two together.

but of course, i wouldn't expect you to see the difference.

My comment does not mention, or even allude to, the content of the posts.  As such, you are the only one who mentioned HF and XT.

The difference, as I see it, is that you cry censorship when off-topic posts you like are moderated, but turn on a dime to complain about lack of moderation when the posts in question do not suit you.

Make your own damn subreddit about FrappuccinoCoin if you don't like the BTC mods' "epitome of authoritarianism."  They are not your servants, and it's hilarious to watch your hypocrisy in action.

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


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


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


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

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

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

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

"Hard forks cannot be co
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 14, 2015, 04:44:35 AM
 #30438

here's further evidence the Reddit mods are steering the blocksize debate. they're letting this guy spam attack me with false allegations despite me reporting him.  same post about a dozen times:

https://www.reddit.com/r/Bitcoin/comments/3gutfp/if_youre_not_running_a_node_youre_not_really/cu1x6fl


Yesterday you were complaining about mod "censorship" and today you are demanding the same mods censor posts you don't like.

it's a repetitive spam attack; over a dozen times the exact same slanderous post attempt at character assassination.  have you forgotten the case seems to be going nowhere and that i deny the allegations?

everybody gets it already. i am a BitcoinXT proponent and i am a threat to you Cripplecoiners.  the HF dispute has nothing to do with it as much as you'd like to tie the two together.

but of course, i wouldn't expect you to see the difference.

My comment does not mention, or even allude to, the content of the posts.  As such, you are the only one who mentioned HF and XT.

The difference, as I see it, is that you cry censorship when off-topic posts you like are moderated, but turn on a dime to complain about lack of moderation when the posts in question do not suit you.

Make your own damn subreddit about FrappuccinoCoin if you don't like the BTC mods' "epitome of authoritarianism."  They are not your servants, and it's hilarious to watch your hypocrisy in action.

yep, didn't think you'd be able to see the difference.

one being outright censorship that attempts to suppress discussion of the most important debate in the community today about Bitcoins future direction, ie the XT fork, and the other a nobody cares spammy personal slander attack that only started when i began speaking out in favor of bigger blocks.  not to mention by a coward who hides behind an anonymous identity.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
August 14, 2015, 05:02:02 AM
 #30439

whoa.  look at that 7% drop in crude oil that just occurred.  someone wants out:

Mengerian
Newbie
*
Offline Offline

Activity: 7


View Profile
August 14, 2015, 05:08:54 AM
 #30440

I'm actually quite excited about this idea.  It has a sort of inevitable feel to it.

Yes. Since anyone can run any software they want to interact with the Bitcoin network, this idea does seem like a logical development.

It also seems like one of those counter-intuitive anti-fragility things, where the seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level.

If it became more common for individual nodes to be able to tweak consensus parameters, then I think that would actually lead to more predictable and stable consensus behaviour in the long run. The worst thing that can happen to a node operator is to fall out of consensus with the rest of the network, so individual node operators would be strongly incentivised to develop methods to ensure they can track the status of the network, and deal with any potential consensus forks.

As it stands now, consensus behaviour is based on the specific implementation details of Bitcoin Core. The software is not designed with the assumption that hard consensus forks are a likely event, and when they do happen nodes are not designed to handle it gracefully. The accidental hard form of March 2013 happened because of an obscure implementation detail in the Core software, and was only possible because the software monoculture created a "single point of failure". A more diverse implementation of consensus rules might result in more frequent consensus divergences and orphaned blocks, but each one would be non-catastrophic, and would lead toward a more stable and resilient network in the long run.
Pages: « 1 ... 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 [1522] 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 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!