Here's a perfect example of the kind of doublethink coming from the decentralization crowd: https://twitter.com/Daniel_Plante/status/607009316915191808https://twitter.com/Daniel_Plante/status/607010068857393152"the point of decentralization is to give TX confirmation power to as many clueless people as possible." "300 million ordinary people running full nodes is the goal because they don't get it and don't care. Won't collude." How many assumptions are baked into those statements? - The developers/distributors of full nodes are 300 million times more clueful than ordinary humans
- Ordinary humans can not be trusted to make informed decisions, but they can be trusted to listen to the right group of developers
- Decentralization means multiplying by 300 million times the capabilities of a self-selected group of developers who can be trusted to do the right thing, unlike regular clueless humans
War is peace, freedom is slavery, ignorance is strength, and techno-fascism is decentralization. |
|
|
|
I'd imagine that there are quite a few litecoin bagholders there who would be happy to see bitcoin hobbled by limited transaction capacity. This is a really informative thread, particularly page 17: https://bitcointalk.org/index.php?topic=144895.335Really the entire thread is worth reading, so you don't miss quotes like this: RE: lots of code to write if you can't keep up with transaction volume: sure. So? Transaction volume itself leads to centralization too, simply by ensuring that only a miner able to keep up with the large volume of low-fee transactions can make a profit.
I really don't understand this logic. Yes, it is a fact of life that if you have a system where people are competing, the people who are less efficient will be driven out of business. So there will be fewer people in that business. You seem to be saying that we should subsidize inefficient miners by limiting the block size, therefore driving up fees and making users pay for their inefficiency. All in the name of vague worries about "too much centralization." |
|
|
|
As I already said We'll find out in due course, once it's measured. |
|
|
|
What I said is it is possible to layer similar schemes on top of Bitcoin. I'm not sure if it's true that Bitcoin can be as private as Monero or not, but I hope to find out. One of the things we want to do with the Open Bitcoin Privacy Project ratings is generalize the measurement criteria until it's possible to make cross-currency privacy comparisons. That's tentatively planned for 2016. At some point it should be possible to start to meaningfully compare Monero wallets with various Bitcoin wallets. Note that just proving the cryptographic properties of ring signatures isn't enough, because some other part of the system might leak information or be susceptible to privacy-reducing user error. You have to evaluate the entire stack. |
|
|
|
That and ordering. The entire purpose of mining (other than distribution) is to establish ordering so that if coins are double spent the new location of those coins is not ambiguous. Ordering is a subset of the problem of maintaining the supply of money. Allowing the same coins to be spent twice is one of the ways that the supply can be violated. Distribution is not a primary purpose of mining. We know this because the distribution function is temporary yet mining will continue even when there are no new coins to distribute. Linking initial coin distribution to mining was just the least-bad way to get the coins into circulation. |
|
|
|
don't be an idiot. you remember when he and Adam were posting here a few months ago to play their silly games?
How long do you really think it's been since either of them posted in this thread? |
|
|
|
The blockchain appears to be a ledger, which is a tool to record and thus document transactions. But that is not the purpose of the blockchain, neither do we need it for that. We need it only to ensure the integrity of the system, to avoid double spending and guard against coin fractions coming from nowhere. That's probably the most overlooked fact about Bitcoin. Transactions using digital signatures are easy. We've had the technology since the 80s. Bitcoin is special because it enforces a defined quantity of money without a trusted third party. All the mining and the verification is done for the purpose of ensuring that that every balance being spent in a transaction legitimately existed prior to the transaction. |
|
|
|
|
It's interesting how people talk about Monero as if we know for sure the privacy achievable in Monero is greater than the privacy achievable in Bitcoin.
Has anyone measured it?
|
|
|
|
Not only that friend, what else are they planing to change down the line? Like I said many moons ago, they will try change the emission and they will start making Bitcoin permanently inflationary, not that I'm against the model, I like Monero exactly because the disinflation but it is a severe rupture of Bitcoin's trust and social contract and all started with the project being hijacked into this obscure XT fork. If they try to make a change like that, users will migrate away from their fork just as easy as they migrated to it. In the end, the developers don't actually have any power - they can only product the software which users want or refrain from doing so. I would have thought the same until his last statement, you are clearly ignoring the power he is displaying to hold as he forces his plan with help of the billionaire backed VC companies so if you want to buy Bitcoin on exchange X, you'll need to install his fork. I think you need to consider who the billionaire backed VC companies are backing. we don't know how this turns out, but your concerns are valid, i just don't know if you are directing them towards the correct developers. if this is a 1 way path why do you think so, I agree with justusranvier, you just switch back if they move in the wrong direction how do you see it? Masses are easily influenced, you would think most people think like you, there is no "going back" from this, the bitcoin eco-system is already centralized in few companies backed by same hands, what I see is a move to put the bitcoin network effect in great peril if this fork happens, because the way bitcoin and decentralized crypto works, only when theres absolute consensus should a move like that happen. What I believe to be the hidden intention behind this fork is to open the bitcoin network to new regulatory frameworks that will be born from the centralized nature of mining and the inherent traceability and likability of the protocol, and establishing a precedent of strong-arming forks. If you can't see the messages from the same agents pointing towards this scenario, well, you are making a fool of yourself to the future community that will be studying Bitcoin-history http://sourceforge.net/p/bitcoin/mailman/message/34161751/So you're saying we should address the implementation monoculture problem? |
|
|
|
Not only that friend, what else are they planing to change down the line? Like I said many moons ago, they will try change the emission and they will start making Bitcoin permanently inflationary, not that I'm against the model, I like Monero exactly because the disinflation but it is a severe rupture of Bitcoin's trust and social contract and all started with the project being hijacked into this obscure XT fork. If they try to make a change like that, users will migrate away from their fork just as easy as they migrated to it. In the end, the developers don't actually have any power - they can only product the software which users want or refrain from doing so. |
|
|
|
One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).
This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong. Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase. The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary. After all that was done, you could use the test suites as the basis of a spec. Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did. |
|
|
|
Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system. I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.
Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs. What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage. Also, a clear spec with extensive testing of each implementation's correctness. As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed. The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program. |
|
|
|
If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client. The bug wasn't nearly so deterministic. Whether or not a particular block would trigger the bug depended on the runtime history of a particular node (when they started downloading blocks, how many orphans they had observed, etc) meaning that binary-identical versions of Bitcoin Core running on machines with identical hardware could exhibit divergent behaviour based on them connecting to different peers at different times. In that regard what do you think about the plan to isolate the consensus code in a separete library? Would have been a good idea to do from the beginning. I'm not sure if the existing code can be cleaned up well enough to make a meaningful difference. |
|
|
|
but there is truth to the fact that those embedded bugs and general messiness somehow "contribute" to the behavior of how the system works in unknowable but apparently predictable and stable ways which seem to work. by changing those bugs or trying to clean up the mess, someone somewhere along the line will disrupt the predictability to where how the code operates may become unstable or unpredictable. that would be bad. The problem is that there are two very different things in play here: - How humans think the Bitcoin protocol behaves
- What Bitcoin Core actually does
There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour. We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee. The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible. If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement. it would take someone or some group truly exceptional to be able to rewrite the entire code and have it function exactly like it does today. and with billions on the line, that would be a tremendous responsibility for a volunteer, would it not? That work has already been done by the authors of btcd (btcsuite). They do have some truly exceptional developers, particularly davec. That he receives snubbing, derision, and personal attack for his efforts is a major example of how toxic and dysfunctional the Bitcoin development culture has become. Nope. Szatoshi will back Back and Maxwell. The cypherpunks will stick together (or hang separately). Some cypherpunks would do well to engage in soul searching regarding the question of so many of their flagship efforts (PGP) have been market failures. Knowledge of cryptography doesn't automatically translate into understanding business, economics, engineering, or interface design. |
|
|
|
i read about this here one time but i don't fully understand it nor the implications, not being a coder.
a spec is a written, detailed, normal language description of how the protocol works, is that correct? wouldn't the current developer's guide qualify as something similar?
where as the code is what actually executes within the operating system and carries out the protocol rules?
and why NL, do you believe it would've prevented what we have going on now?
The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible. You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software. I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written. Doing that would have the beneficial effect of increasing the number of developers who can participate, since the reference would be more understandable and better documented. |
|
|
|
if Gavin and XT are successful, and i think they will be, there is a real opportunity to clean house and leave the garbage outside. we can selectively pick that which we wish to retain, maybe pwiullie & Wlad, but the rest can be shipped off to the junkyard.
plus, it will give plenty of new fresh minds an opportunity to become core devs with all the perks that go along with it. and there are plenty even if you're essentially volunteering. i wouldn't expect them to, but my pt still stands. there's prestige, access, status, and lucrative consulting opportunities that abound. there are plenty of brilliant minds out there that have been spurned by the current group and would love to step into their shoes. it also probably will set a precedent that large blocks of core devs shouldn't go off and start a for-profit company that introduces massive conflicts of interest into the dev process. If you want to bring fresh minds into Bitcoin, then dumping the Bitcoin Core codebase is necessary. Part of the reason that there are so few "core developers" is because Bitcoin Core is so difficult to understand, despite fairly extensive attempts to clean it up. Other implementations, notably btcsuite, do not share this problem. It would be a huge waste of effort to not take the opportunity to switch the reference codebase to something more understandable and maintainable. |
|
|
|
there's a clue here. and it's not good news.
/u/nullc still thinks he was right in banning Ver & Matonis despite an overwhelming community opinion to the contrary. the community's only course of action at the time, which has proven very successful and stood the test of time, was to "fork" away from PressCenter.org and move to another website. which has now become the de facto go to place. I believe the Blockstream crew is going to learn the hard way that there's no such thing as tenure in Bitcoin. |
|
|
|
diff btwn 32 & 44?
BIP32 is a standard for deriving key pairs from seeds. BIP44 is an application of BIP32 for creating a standard HD wallet structure. |
|
|
|
i don't blame the short sightedness of the guy who just sold us off down to $232 given how strident iCE and his buddies have been about making any progress whatsoever on this block size issue. It's equally likely the sell off is related to the impending Goxxing of OKCoin users. |
|
|
|
|
Show Posts
