What's arbitrary? The fact that Bitcoin, in its present state, could be overloaded by a single suburban shopping mall? Not sure I understand. Far as reversed payments, that's the reason people *use* Visa: so that they *could* charge back if shit goes south. Chargeback is not something intrinsic to fiat money -- Visa could make transactions as irreversible as Bitcoin, but it doesn't, because smart  the comparison between bitcoin and a shopping mall is arbitrary. bitcoin is not just a payment channel. it was intended to cut out third party trust (e.g. Visa), < snip > So tell me, Bitcoin: The Peer-to-Peer Electronic Cash System was designed to "cut out third party middleman (e.g. Visa)" out of WHAT? Clearly not shopping, because a single suburban shopping mall would overload the network, so it's not suitable for shopping. At least, according to you. it was designed to "cut out third party middleman (e.g. Visa)" from transactions between two parties. satoshi put it this way: "the main benefits are lost if a trusted third party is still required to prevent double-spending." since Visa is the central agent that enforces its rules, users could never trust Visa to keep transactions irreversible; nothing enforces that. and they are still a central point of failure.
Let me see now... Visa LENDS ME THE MONEY, FOR FREE, to buy shit with, and I can't trust it? Why, exactly, do I need to trust it, considering I'm playing with its money? Explain this shit. Visa doesn't lend you the money; a bank does. you need to trust it (or the lending bank) because they can reverse any payment that is made to you. this is problematic for anyone that accepts payment for goods/services only to have that payment reversed. Edit: ...
Visa's great. credit cards are fucking fantastic. i get fat cash back on all my purchases. i say, let's keep using Visa cuz it's fucking great. and let's keep bitcoin from turning into a centralized system like Visa, because that defeats the purpose.
Centralized? How des letting Bitcoin grow turn into centralization? if "letting bitcoin grow" =/= sacrificing decentralization, i'm with ya. but there have been compelling arguments made that increasing block size with the current infrastructure will sacrifice decentralization. |
|
|
|
What's arbitrary? The fact that Bitcoin, in its present state, could be overloaded by a single suburban shopping mall? Not sure I understand. Far as reversed payments, that's the reason people *use* Visa: so that they *could* charge back if shit goes south. Chargeback is not something intrinsic to fiat money -- Visa could make transactions as irreversible as Bitcoin, but it doesn't, because smart the comparison between bitcoin and a shopping mall is arbitrary. bitcoin is not just a payment channel. it was intended to cut out third party trust (e.g. Visa), and it does that by being a clunky, redundant dinosaur. it's not pretty but it's how decentralization works. not really comparable to centralized systems. since Visa is the central agent that enforces its rules, users could never trust Visa to keep transactions irreversible; nothing enforces that. and they are still a central point of failure. anyway, Core's plan increases capacity via segwit, and intends to increase the block size limit for more capacity once the technical problems re bandwidth are addressed. they've proposed how to address those too.
So, after stalling and pretending the problem didn't exist for a year, segwit is suddenly gonna be ready to solve it? Would that be In Two Weeks TM? what do you mean? this debate has been going on nearly all the way back to bitcoin's inception. Core didn't believe a hard fork increase was necessary back then, or now. that's not an illegitimate position just because some people disagree. the kids may be screaming in the back seat, but we just aren't there yet.
Kids no longer in the back seat. Got sick of the bullshit & bailed. Riding with Visa nao. Visa's great. credit cards are fucking fantastic. i get fat cash back on all my purchases. i say, let's keep using Visa cuz it's fucking great. and let's keep bitcoin from turning into a centralized system like Visa, because that defeats the purpose. |
|
|
|
Sure, but as you see, their communication method is FUD and lies. That bothers me.
Beyond that: all the reasons proponents of XT and Classic raise. FUD and lies? i disagree, but opinions are like assholes. we all got em. XT and Classic proponents have raised some points, and Core and much of the community vehemently disagrees. = contention. well that's anecdotal and dependent on how you define nerds. not very reliable
anyway, what happened? nothing. an unconfirmed transaction with insufficient fees went unconfirmed. and no one lost anything (unless you accept zero confirmations as a valid payment, which no one should be doing)
perhaps a solution is to integrate an optimal fee mechanism into the client.
Seems to meet the same stringent terms you allow yourself. But yes, it's anecdotal evidence. One got stuck for four days before the network unclogged and I received it. An integrated fee calculator is something you integrate before the network clogs up. As are alternate solutions to the block size problem. Or you simply bump up the block size limit. the difference is you are arguing to change the consensus rules, so the burden is on you to provide evidence for why. i was merely quipping that i haven't seen evidence that this supposedly urgent problem is urgent, nor a problem. blocks aren't actually full on average, nor fees prohibitive. so it seems to me that we could integrate an optimal fee mechanism into the client before the network actually clogs up (if it is going to). |
|
|
|
ah okay. so it's simply 1MB vs. 2MB. if Core joins the party, and everyone agrees to wait for miner consensus before forking, it wouldn't be contentious. that's fine with me.
but why should Core do that? just to make the "must-fork-now" camp happy? the basis for the disagreement is technical.
its called a buffer.. by having the setting.. but miners never making a block over 1mb for multiple reasons causes no harm that puts trust in miners not to prematurely fork before the rest of the network has updated. if you're so sure they won't do that, why don't we just enforce it with code? same outcome without putting trust into miners not to break the network. |
|
|
|
...
any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees.
bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin."
Whelp, this is about as popular as Bitcoin gets, because the network can't handle any more volume. Enjoy hehe well, seems to be chugging along just fine to me. i dunno who's getting their transactions constantly stuck but i've always been able to get my transaction in the next block for minimal fees. As I understand it, some still cling to the "Peer-to-Peer Electronic Cash System" pipe dream. At 3tps, Bitcoin could be "Bitcoin: A Peer-to-Peer Electronic Cash System For An Average Shopping Mall." why? seems kinda arbitrary. is that compared to centralized systems like Visa? they don't offer the same security that bitcoin does. centralization failure, reversible payments. anyway, Core's plan increases capacity via segwit, and intends to increase the block size limit for more capacity once the technical problems re bandwidth are addressed. they've proposed how to address those too. the kids may be screaming in the back seat, but we just aren't there yet. |
|
|
|
...
any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees.
bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin."
Whelp, this is about as popular as Bitcoin gets, because the network can't handle any more volume. Enjoy hehe well, seems to be chugging along just fine to me. i dunno who's getting their transactions constantly stuck but i've always been able to get my transaction in the next block for minimal fees. I've gotten txs stuck when other people send to me. And they're nerds. Which means a) if they can't get it right, a lot of others will fail b) you can't instruct them on something they think they know how to do. well that's anecdotal and dependent on how you define nerds. not very reliable anyway, what happened? nothing. an unconfirmed transaction with insufficient fees went unconfirmed. and no one lost anything (unless you accept zero confirmations as a valid payment, which no one should be doing) perhaps a solution is to integrate an optimal fee mechanism into the client. |
|
|
|
that fork was an emergency update, where there was no controversy over the implementation.
here, we have multiple competing development teams that disagree (including actively lobbying miners against one another), and the stated threat of moving forward with or without miner (and surely node) consensus. that can easily mean chain forking into multiple ledgers ...forever.
if the network can't reach consensus on the rules to enforce, the only means to establish a single (trustless, decentralized) ledger are broken. that will erode a lot of trust in bitcoin, possibly beyond repair.
XT, Classic and Unlimited are compatible with 2MB. If Core goes 2MB how is it contentious? that's a big if, for now. so...contention. gavin withdrew the BIP101 pull request from the Core BIPs on github, but isn't XT still implementing BIP101, which is 8MB block size limit to start? that means miners can produce blocks as large as 8MB. 8MB blocks are not compatible with Classic's 2MB block size limit. further, since Unlimited has no hard-coded block-size limit, it views all blocks as valid (whether max 1MB, 2MB or 8MB). that means that it accepts Core, Classic and XT blocks. but Classic and Core won't accept blocks above 2MB, meaning if any such blocks exist, compatibility with both XT and Unlimited is broken. none of these are compatible with a 1MB limit, of course. this represents a possibility for at least three separate forks. A 1MB fork, which rejects Classic and XT blocks above 1MB. A 2MB fork, which rejects XT blocks above 2MB. And an 8MB fork, which accepts Core, Classic and XT blocks. XT has joined Classic in their goal to achieve consensus for 2MB ( https://bitcoinxt.software/patches.html). Unlimited nodes will handle 2MB but there doesn't seem to be more of a chance that they will mine a 8MB block after a 2MB HF than tomorrow or yesterday. So if the argument against a HF is that it would be a contentious HF, then where is the contention if Core decides to join the party? ah okay. so it's simply 1MB vs. 2MB. if Core joins the party, and everyone agrees to wait for miner consensus before forking, it wouldn't be contentious. that's fine with me. but why should Core do that? just to make the "must-fork-now" camp happy? the basis for the disagreement is technical. |
|
|
|
...
any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees.
bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin."
Whelp, this is about as popular as Bitcoin gets, because the network can't handle any more volume. Enjoy hehe well, seems to be chugging along just fine to me. i dunno who's getting their transactions constantly stuck but i've always been able to get my transaction in the next block for minimal fees. |
|
|
|
that fork was an emergency update, where there was no controversy over the implementation.
here, we have multiple competing development teams that disagree (including actively lobbying miners against one another), and the stated threat of moving forward with or without miner (and surely node) consensus. that can easily mean chain forking into multiple ledgers ...forever.
if the network can't reach consensus on the rules to enforce, the only means to establish a single (trustless, decentralized) ledger are broken. that will erode a lot of trust in bitcoin, possibly beyond repair.
XT, Classic and Unlimited are compatible with 2MB. If Core goes 2MB how is it contentious? that's a big if, for now. so...contention. gavin withdrew the BIP101 pull request from the Core BIPs on github, but isn't XT still implementing BIP101, which is 8MB block size limit to start? that means miners can produce blocks as large as 8MB. 8MB blocks are not compatible with Classic's 2MB block size limit. further, since Unlimited has no hard-coded block-size limit, it views all blocks as valid (whether max 1MB, 2MB or 8MB). that means that it accepts Core, Classic and XT blocks. but Classic and Core won't accept blocks above 2MB, meaning if any such blocks exist, compatibility with both XT and Unlimited is broken. none of these are compatible with a 1MB limit, of course. this represents a possibility for at least three separate forks. A 1MB fork, which rejects Classic and XT blocks above 1MB. A 2MB fork, which rejects XT blocks above 2MB. And an 8MB fork, which accepts Core, Classic and XT blocks. We can wait for Bitcoin to become very hard to use when people constantly sends more transactions than can even be included in blockchain, also know as denial of service attack, but this will erode a lot of trust in Bitcoin as well, very likely beyond repair. So not much safer choice eighter - unless you believe people will be happy to use Bitcoin with 1) huge fees, 2) long 1st confirmation times 3) never confimed transactions. I dont know of any coin with restricted blocksizes so people can hardly use it, yet very popular and people eager to use this coin  any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees. bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin." |
|
|
|
I don't imagine we can or need to do anything more than what we're doing. I'm honestly just trying to understand the pushes and pulls involved in the possibility of a protocol change.
Me too. Let's try 1.1MB for a little while to see. Depending on what we learn then we can fallback to 1MB or try the next increment of like 1.2MB or something. Why do we feel compelled to jump to 2MB all at once? Because changing the blocksize requires a hard fork, the common wisdom being that hard forks are traumatic events, sort of like [invasive] surgery. If you already opened the patient, might as well do everything that needs to be done, instead of removing just a wee bit of the tumor & having to do the whole thing over again in a month. If you give a 6 months notice, I will most of the users and miners will change their software in time. This happened before. it took 4 hours to sync all miners on earth last time we had a HF, and no one had any notice. that fork was an emergency update, where there was no controversy over the implementation. here, we have multiple competing development teams that disagree (including actively lobbying miners against one another), and the stated threat of moving forward with or without miner (and surely node) consensus. that can easily mean chain forking into multiple ledgers ...forever. if the network can't reach consensus on the rules to enforce, the only means to establish a single (trustless, decentralized) ledger are broken. that will erode a lot of trust in bitcoin, possibly beyond repair. |
|
|
|
|
in the case of a hard fork, i'll be plugging away on my Core node. if you want 2 chains, you got it. and yes, i'll be doing my best to double spend on the "Classic" chain to make the fork irreparable. just doing my part.
|
|
|
|
what do you think it is? i see so much of this insinuation that he (and others) have these nefarious intentions, but it seems no one can spell out what they are, and how it's going to work. just how is Blockstream causing such massive conflicts of interest? where does the money come in? the VC numbers i've heard thrown around are tiny and meaningless. what exactly about Blockstream is it -- specifically -- that has made people turn so vociferously on Core devs that have tirelessly worked for years to make bitcoin what it is?
Amount of money lost if Gavin Andresen receives rejected proposals = -$Amount of money lost if Gregory Maxwell receives rejected proposals = -$$$$$$$$$$$$$$$$$$$$Who sounds like they have more to lose? Who sounds like the genuine person now? what proof do you have that Gavin Andresen isn't being paid to promote his fork? he is under no obligations (other than moral ones) to disclose to the community whose payroll he is on. why do you just assume that he is just some altruistic hero, when all he has done for the past year is try to take control of bitcoin's repository via two hard forks? i think it's quite suspicious that Gavin said 2mb was "absurdly small" when attempting previously to remove Core's commit access with his XT fork.... and NOW is pushing for a 2mb hard fork to remove Core's commit access. never mind that Seg Wit nearly matches the capacity increase -- or better... what proof do you have that "money is being lost if Gregory Maxwell receives rejected proposals?" what money? what is the business plan? what is the conflict of interest? spell it out for me, please. |
|
|
|
not so against any kind of increase in the max block size
The Bitcoin Core capacity roadmap includes several block size increases, including the immediate term segwit proposal that many people are actively working on (and which has a testnet)-- which increases the capacity to fairly close to Gavin's latest proposal (which is not BIP 102). 'immediate term' , no one knows what that means exactly. 3 months? 6 months? 18 months? This would be more immediate, simpler, and arguably more robust and less risky. What does core have against it? The community has been screaming for bigger blocks. If core won't accept Gavin's proposal, it means one of three things: 1. They don't care what the community wants (despite their pleas for consensus). 2. They think they know what is best and are too stubborn to accept anyone else's priorities. 3. They have an alterior motives. Could be a combination of all the above. Mr. G. Maxwell is a key developer on Core in addition to being a founder of Blockstream. What do you think is his agenda? what do you think it is? i see so much of this insinuation that he (and others) have these nefarious intentions, but it seems no one can spell out what they are, and how it's going to work. just how is Blockstream causing such massive conflicts of interest? where does the money come in? the VC numbers i've heard thrown around are tiny and meaningless. what exactly about Blockstream is it -- specifically -- that has made people turn so vociferously on Core devs that have tirelessly worked for years to make bitcoin what it is? |
|
|
|
2 MB block size brings nothing.
This is strange answer coming from a bitcointalk.org staff member. But you are the same person that said Satoshi's vision is irrelevant? Funny how well now I can remember you and your ways. I thought 2MB blocksize would mean keeping Satoshi's protocol intact, whilst relieving full blocks, quelling the current international dispute, and at the same time leaving open the possibility for SegWit, and other Blockstream corporate-sponsored programs. Strange indeed... the same people that cry most loudly against 'contentious hard forks' are the ones that seem to be against implementing a simple 2MB increase right now that would make the forking threat disappear. that's an interesting way of framing things. removing the threat of a contentious hard fork -- by implementing a contentious hard fork. brilliant. meanwhile, Gavin stated that 2mb is "absurdly small." but since his first [maximalist] attempt to remove Core's commit access failed, he is now trying the minimalist approach to remove Core's commit access. it's not a "compromise" at all. he has turned all the bullshit "sky is falling" rhetoric about the urgency of 20mb blocks entirely on it's head. quite clearly, the end goal of such rhetoric was "anything that will remove Core's commit access" -- now he's just being transparent about it. 20mb was never urgent at all, obviously. |
|
|
|
Who the fuck is this classic shit? Is sounds to me like some bad commercial! it's an hard fork for the 2mb capacity incrase nothing else we have two side here, those that want to hard fork no matter what and those that want a soft fork but the result is basically the same, capacity must increase all the other shit does not matterof course it does. that's what this is all about. whether capacity can increase before the system is more scalable. i am reminded of children in the back seat screaming "ARE WE THERE YET?!??!?!?!" decentralization > increased capacity. always. otherwise wtf is it all for? if bandwidth bottlenecks continue crippling node health as block size increases -- and we know this happens because that is the historical trend -- how much is too much? eventually, your transactions are censorable. so yes, all the other shit matters. the fact that SegWit offers a capacity increase in the interim while weak blocks/IBLTs are worked on (which will reduce peak bandwidth requirements by 90%+ for full nodes)... makes this a no-brainer. then we can talk about increasing block size limit -- when bandwidth loads for nodes are more sustainable. |
|
|
|
|
what is with this new obsession with "democracy?" did gavin write a new blog about how bitcoin is supposed to be a "democracy" or something?
|
|
|
|
If you feel that Lauda's alluding to game theory, feel free to cite that. Forgive me if I don't take the word of random_guy_from_the_internet on trust.
i don't need to cite anything. i was expanding on what Lauda said. in any case, i am asserting that this is the relevant issue. alternatively, you could explain how it has fuck all to do with "coding." Worked when, where and how? Also define what *you* mean by "consensus," everyone seems to have teir own opinions. one example is BIP66. an intentional fork would, for example, not be successful if it results in multiple surviving blockchains, thereby breaking bitcoin. i defined what i meant by consensus: the "consensus mechanism" stated in the whitepaper and the definition of "consensus" -- is to establish as close to 100% agreement as possible, and to prevent any changes that do not approach 100% agreement. Can you please cite the relevant passage? Again, it's simply rude of you to make me search for the text you're referencing. i'd say it's more rude to insult people for "not being a coder" when it's 100% irrelevant. if you haven't read bitcoin's whitepaper, then it's obvious why you haven't contemplated what consensus is, nor why it is necessary for bitcoin to function. refer to "consensus mechanism" in the whitepaper, relate it to the English definition of "consensus" and historically (as relates to bitcoin) how it has been used and subsequently achieved (e.g. BIP66). cite the fucking relevant passage plz.
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. Huh? "from a game theory perspective"? WTF are you taking about? Am enjoying the a) and b) list bit tho. Very acędemic of U.
you realize the bitcoin system is an economy, right? https://en.wikipedia.org/wiki/Game_theoryBro, unless you can be more specific than "herp, Gaem Theorie!!1!" I'm gonna have to put you on ignore.
Don't waste my time.
look, bro. clearly you're a fucking idiot if this is your grasp of economics. i took several more minutes than i should have answering your retard 101 questions, knowing full well that you know absolutely nothing about bitcoin or how it works. your comments to Lauda asserted that economic incentives can be determined by code. please explain to me how that works. an "economy" is "a system especially of interaction and exchange" -- that implies human rationality and incentive. so yes, if you think you can analyze the idea of "economic consensus" with no regard for modelling conflict and cooperation among intelligent rational decision-makers, you'd be dead wrong. please feel free to ignore me, though. apparently you're just another retard that picks apart others' arguments without the slightest understanding of them, and never once proves a point of your own. you just incessantly ask irrelevant questions rather than address the substance of what is being said. this is a classically dishonest style of argument. seriously, learn to use Google rather than forcing everyone to explain every little idea for you like a small child. Whoops, nothing left... Into ignore void you go then. But don't be a sad, will check on u every now and again yep, as expected.... |
|
|
|
If you feel that Lauda's alluding to game theory, feel free to cite that. Forgive me if I don't take the word of random_guy_from_the_internet on trust.
i don't need to cite anything. i was expanding on what Lauda said. in any case, i am asserting that this is the relevant issue. alternatively, you could explain how it has fuck all to do with "coding." Worked when, where and how? Also define what *you* mean by "consensus," everyone seems to have teir own opinions. one example is BIP66. an intentional fork would, for example, not be successful if it results in multiple surviving blockchains, thereby breaking bitcoin. i defined what i meant by consensus: the "consensus mechanism" stated in the whitepaper and the definition of "consensus" -- is to establish as close to 100% agreement as possible, and to prevent any changes that do not approach 100% agreement. Can you please cite the relevant passage? Again, it's simply rude of you to make me search for the text you're referencing. i'd say it's more rude to insult people for "not being a coder" when it's 100% irrelevant. if you haven't read bitcoin's whitepaper, then it's obvious why you haven't contemplated what consensus is, nor why it is necessary for bitcoin to function. refer to "consensus mechanism" in the whitepaper, relate it to the English definition of "consensus" and historically (as relates to bitcoin) how it has been used and subsequently achieved (e.g. BIP66). cite the fucking relevant passage plz.
Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. Huh? "from a game theory perspective"? WTF are you taking about? Am enjoying the a) and b) list bit tho. Very acędemic of U.
you realize the bitcoin system is an economy, right? https://en.wikipedia.org/wiki/Game_theoryBro, unless you can be more specific than "herp, Gaem Theorie!!1!" I'm gonna have to put you on ignore.
Don't waste my time.
look, bro. clearly you're a fucking idiot if this is your grasp of economics. i took several more minutes than i should have answering your retard 101 questions, knowing full well that you know absolutely nothing about bitcoin or how it works. your comments to Lauda asserted that economic incentives can be determined by code. please explain to me how that works. an "economy" is "a system especially of interaction and exchange" -- that implies human rationality and incentive. so yes, if you think you can analyze the idea of "economic consensus" with no regard for modelling conflict and cooperation among intelligent rational decision-makers, you'd be dead wrong. please feel free to ignore me, though. apparently you're just another retard that picks apart others' arguments without the slightest understanding of them, and never once proves a point of your own. you just incessantly ask irrelevant questions rather than address the substance of what is being said. this is a classically dishonest style of argument. seriously, learn to use Google rather than forcing everyone to explain every little idea for you like a small child. |
|
|
|
Maybe Gavin threw a wild proposal out there like Bitcoin-XT for the purpose of making a much more conservative proposal like this increase to 2MB looks perfectly acceptable.
more likely, he and hearn overestimated their ability to push for a block size increase on purely political/argumentative (rather than technical) grounds. i have no doubt he would have preferred the XT bloatchain. after all, for Gavin, capacity is all the matters. scalability be damned. |
|
|
|
Let me guess, Blockstream sent out an internal memo telling all of its paid developer shills to troll this thread!  what, and you're a Coinbase shill? maybe an NSA shill? #datlogic |
|
|
|
|
Show Posts
