1AAPLWg7TxkvD5Vt9EFLrJLY5rzf7Nt2d2  |
|
|
|
|
Here Endeth The Analysis.
Here Begineth The Glorious Wave Three.
Tips hat in your general direction Master Luc
|
|
|
|
watching  |
|
|
|
The level of hostile emotional appeal and logical fallacy in this thread is astounding.
Why is it so difficult for a group of intelligent people to discuss ideas on their own merit?
there is no tax on being respectful.
With respect, you are unaware of the level of contempt that the BIP101 pushers are showing for anyone who disillusions them of their idea. These people aren't attempting a reasonable discussion in the first instance, and so it is only appropriate to match their zeal with opprobrium. Of course BIP101 is a technical proposal to be discussed on it's merits; it has been dissembled, disliked, and then ruled out already. But this very vocal minority doesn't seem to want to go away gracefully. I may have missed the contempt, but I assure you I've read as much as I can find on this subject. To date i'm not fully convinced of any argument. However I've seen very little evidence that leads me to think using the 1MB limit a good idea. It appears to be adding a new variable (a hard limit) where we have not previously needed one. I see one argument for keeping it and that is to prevent 'centralization' although nowhere is this term quantified. Further, it also introduces a new centralization vector that previously didn't exist. ( namely increased fees.). If you are going to argue keeping something reduces centralization, whilst introducing something else that increases centralization. The whole thesis breaks down, as it is self contradicting. Now that keeping 1MB is ruled out, that leads to the conclusion; we must have a hard fork. Therefore if you put me on the spot today, i'd say removing the blocksize limit altogether ( in a gradual and predictable manner) Is the best solution. Reading the paper by Peter R will help with the leap of faith, required here to trust in the free market. In my humble opinion that's what this whole debate boils down to. Attempting to control a vast and complex system of variables or simply letting supply and demand of the free market do what it does best. |
|
|
|
|
The level of hostile emotional appeal and logical fallacy in this thread is astounding.
Why is it so difficult for a group of intelligent people to discuss ideas on their own merit?
there is no tax on being respectful.
|
|
|
|
Right, Ok so my misunderstanding on this scaling debate comes down to one question.
Assuming vast quantities of transactions, and no restrictions on block size. Where is the primary processing/storage bottleneck? Is it in the temporary size of the mempool, (pre processing), or the permanent size of the blockchain? (post processing)
Storage (a hierarchy, in general), CPU power, and bandwidth are all potential bottlenecks and the future critical factor will depend in on the path of technological evolution which is difficult to predict. Most expect bandwidth, I believe. Great timing from mike. Pretty much provides the answers I was looking for. Namely a fee market can and might develop around the mempool storage.  https://medium.com/@octskyward/mempool-size-limiting-a3f604b72a4a |
|
|
|
|
Right, Ok so my misunderstanding on this scaling debate comes down to one question.
Assuming vast quantities of transactions, and no restrictions on block size. Where is the primary processing/storage bottleneck? Is it in the temporary size of the mempool, (pre processing), or the permanent size of the blockchain? (post processing)
|
|
|
|
I think you are confusing UTXO and unconfirmed transactions. The UTXO set is all confirmed transactions that have unspent outputs.
Edited the original post, is my question clearer now ? |
|
|
|
Thanks for the info. The idea is to make the cost of sending the spam comparable to the cost of cleaning up the spam, which makes a lot of sense. Min TX fees can work as an anti spam measure, and can be applied without hard forking the coin if enough nodes simply refuse to relay transactions without the min TX fee. Forgive the ignorance as i'm not a coder.  If the unconfirmed transactions are stored in the mempool, (effectively distributed cloud storage). Surely this provides the natural free market limit and restricts spam. For example if i'm a full node or solo miner, I clearly can't store every tiny unconfirmed transaction. Therefore i would just add a filter to limit my mempool size. Filtering on say; fee paying transactions, or only including transactions over a certain quantity of satoshis. Larger miners, Pools or super nodes will be able to afford broader limits on their filters and store more (or all) unconfirmed transactions. As enough transactions get stored in the mempool eventually a fee market will emerge, Some transactions are worth storing until they get confirmed while others are not and should drop out. Certain companies say NASDAQ who are just using the single satoshi as a coloured coin (hence, zero fee) will clearly have to sponsor miners to store and confirm these. What am I missing ? edited to remove stupidity.  |
|
|
|
My take on the issue:
Any solution has to make spam expensive. Anything else is just adding further problems. That's why I like the solution implemented with Litecoins. Why does spam have to be expensive? if transactions are zero fee, then miners have no incentive to include them, so they'll just get filtered out and apply some mempool clearing system that forgets them after a certain time. If the transactions have a fee attached they are not really spam, so why not let supply and demand economics take care of the miners incentive? |
|
|
|
Please take the OT discussion elsewhere. jeez i've not even seen a chart for three pages.  |
|
|
|
I speculate that people will get what they pay for.
paying such a little to disrupt the entire network for an entire month seems very cheap. Not to mention knocking offline most of the colored coin style micro transaction companies. |
|
|
|
Speculate as to how this will play out  http://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981UK-based mining service CoinWallet is gearing up to conduct a stress test of the Bitcoin network in early September, which it said will likely render most standard wallet software "worthless" and create "nearly a 30-day backlog".
A CoinWallet representative told IBTimes in an email exchange: "I don't have a set date, but it will be early September. I'm too busy this month to fully devote a large amount of time to executing the 'test'.
"Despite the general belief that someone can do something like this by setting up a couple of servers to send payments to yourself over and over, it's a little more complicated than that."
CoinWallet's last test of the system involved taking a bunch of Bitcoin and then dividing it among thousands of Bitcoin addresses, all in tiny amounts of 0.00001.
"As part of this test, I will be reconsolidating more than 150 Bitcoin that currently sits in these wallets."
CoinWallet conducted a transaction to demonstrate what this will look like.
"As you can see from the transaction, there are 20 tiny inputs, with half going to miner fees, and half going to one of my CoinWallet addresses. This transaction is approximately 3kb, or 1/323rd of a block. In other words, for every ~323 of these I send, I fill up a block.
"Each of these transactions is for a total amount of 0.0002 BTC (including miner fees), meaning that with my 150 btc that is currently in this state, I will be crafting 750000 transactions, or 2321 blocks, or a 16 day backlog."
CoinWallet said the second phase of the test will be to use 20 cloud-hosted servers to send bitcoin payments in amounts of 0.00001 to thousands of its addresses at random, all in transactions that are also approximately 3kb each.
"These 20 servers push approximately 1 transaction per second. The plan is to fill them up to 50-100 Bitcoin in total. In theory, if all things go as planned, we will create a nearly 30-day backlog."
"Of course, this won't cripple Bitcoin entirely. Those who are smart enough to increase their fees will still manage to push transactions through. However, it will make it prohibitively expensive, and will likely render most standard wallet software, ranging from Multibit, to Mycellium, Blockchain.info and others completely worthless.
"I should however note that CoinWallet.eu is relatively immune to this form of 'attack' as our fees are dynamic and are set at 3x the standard limit. As always, CoinWallet clients will be unaffected by the test. More details will be posted publicly when the test is imminent."
The WSJ BitBeat reported in July that CoinWallet had communicated plans to flood the system with countless small transactions, enough to fill two blocks every minute, and after that send out slightly larger transactions. Its goal was to create a 200 megabyte blockchain backlog.
The previous CoinWallet test only achieved about 15% of its output because its servers crashed.
"We feel that our tests might prove to be the catalyst that propels the core devs and miners to implement the required hard fork that is desperately needed," Coinwallet told BitBeat.
A debate has been raging for months over whether or not to increase the maximum size of a transaction block of data beyond 1 megabyte.
Bitcoin core developers Gavin Andresen and Mike Hearn are spearheading the drive to increase the block size, and have developed Bitcoin XT client to allow miners to opt out of the current 1MB limit. The majority of miners must adopt the protocol upgrade or else no change will come into effect.
"The fact that the XT fork hasn't occurred yet is ridiculous," CoinWallet said. |
|
|
|
Thanks for the that. Bitcoin-XT represents a somewhat reckless approach, which in the name of advancement shatters existing structures, fragments the community, and spins the ecosystem into chaos. A new enemy of Frap.doc and the Gavinistas emerges! Let's see what kind of poo they fling this time. If you're going to quote Meni at least have some respect and not take it out of context. here is the full post in it's entirety MeniRosenfeldMeni Rosenfeld - Bitcoin Expert 172 points 9 hours ago*x2
Sorry for being the odd one out in theymos' list, not having my stance on the issue clear  . I will clarify it, but only after I explain at length why I reject the whole premise of the question.
This used to be a technical debate about block sizes. We were presented with two bad choices: Keep it at 1MB which is obviously too low, or increase to 8MB/20MB which is obviously too high (obvious to me anyway). As a community we've failed to reach a compromise, and I think that if more people pushed for a reasonable number like 3-4 MB in the short term (including also Gavin and Mike on one extreme, and Peter on the other), things would be different now.
Given that compromise failed, Gavin and Mike went ahead to push Bitcoin-XT, and now the real issue isn't about technology, it's about the philosophy of Bitcoin evolution. To me, Bitcoin-XT represents a somewhat reckless approach, which in the name of advancement shatters existing structures, fragments the community, and spins the ecosystem into chaos. Whereas Bitcoin Core represents a frigid approach, where no technology improvement will ever be made because consensus can't be reached, and where we can't do anything about the fact that we can't do anything, because of the delegitimization of attempts to change the status quo by forking and letting the best currency win (and make no mistakes, there will be many necessary technology improvements down the road; the block size limit pales in comparison).
Both choices are bad.
I had plans once to write a paper about the game-theoretic aspects of changing the Bitcoin protocol, the contingencies in case of a fork, and how the mere threat of a fork can create a Schelling point which would prevent it from happening. I regret never getting around to it, because it might have been illuminating in the current debate. (For that matter, the other paper I had plans for writing was about transaction fees and how they relate to things like a block size limit; I regret that too, but again the block size is no longer the real issue).
But anyway, I do strongly believe that the possibility of forking Bitcoin - even if at first it has no consensus - is vital to Bitcoin's health, growth and survival. It's the glue that holds everything together and makes sure the Bitcoin economy has a say in case something goes wrong with the development. Ideally a contentious fork would forever remain a theoretical possibility - but if it is possible it means it can happen, and that's what we're seeing right now. Rejecting a fork on the grounds that it's a fork is wrong.
Of course, there are grounds to reject Bitcoin-XT on the grounds that its timing and method are wrong. The objection to the technical change was too strong to just gloss over it. We're definitely not anywhere near the point where Pieter, Greg or Wladimir can be conceivably considered rogue and we should break away from them. Mike and Gavin have, quite arrogantly I would say, assumed that this is just like any other software change and that virtually everyone will just automatically follow them, where the reality is far from it. They didn't properly consider the consequences of making this move without enough support. (They might reply that they have been fighting for this for a long time and exhausted all other options, but I don't accept this - they made many attempts at persuasion, but not enough at compromise).
So here we are, having to choose between two bad alternatives. The mere act of choosing commits, in my opinion, the logical fallacy of privileging the hypothesis. There are millions of possible approaches, and "someone" out there restricted them to just 2. Most of the decision process (culling from millions to 2) was made for me and I'm left rubber-stamping one of the choices that remain. (See also http://lesswrong.com/lw/mi/stop_voting_for_nincompoops/).
But hey, even a noisy bit contains some information, and the question was asked, so...
Given the choice between short-term sticking with 1MB or going all the way to 8MB, I am in favor of going to 8MB.
Given the choice between sticking with Bitcoin Core or switching to Bitcoin-XT, I am in slight favor of sticking with Bitcoin Core, but that could change any time.
All that said, the parent post explaining theymos' policy makes no sense to me. As explained above, the possibility of forking is an integral part of Bitcoin. As long as Bitcoin-XT has non-negligible support as the true Bitcoin implementation, even with nothing resembling unanimous consensus, it is a part of what Bitcoin is, and of course is on topic on a Bitcoin subreddit.
Even if for some reason we take a purist approach that Bitcoin = Bitcoin Core, I'd imagine that most posts about Bitcoin-XT would compare it in some way to Bitcoin Core, and as such are on-topic (just like a post comparing Bitcoin and Litecoin would be on topic).
I'm considering upgrading the above to a post, but honestly, since it includes a discussion of Bitcoin-XT, I'm not even sure it passes the moderation rules...
|
|
|
|
I was still holding out, and hoping for some peaceful bip 100 or 101 implementation being compromised into Core but this whole disturbing censorship thing has just shown how irrational, illogical and childish one side has become. The sooner XT gets its 75% majority the better as far as i'm concerned. we could do with forking bitcointalk and /r/bitcoin while were at it. ........ It's maddening.  |
|
|
|
I FUCKING HATE CENSORSHIP.  |
|
|
|
So I just opened both the bitcoin and bitcoinxt reddits to compare the number of active uses online at that moment since this is a better comparison than subscriber count which is mostly inactive users. The results are:
/r/bitcoin - 606 online users
/r/bitcoinxt - 306 online users
That makes 33% of bitcoin redditers switching to the XT reddit in 1 day.
Wow just wow
what about this? briefly spotted on reddit but can't find it again now? from redditmetrics Subreddit Growth
How /r/Bitcoin growth compares with growth of 695,515 other subreddits.
No. 695,515 Fastest growing yesterday basically it's going negative by about 300 odd people left in the last few days. |
|
|
|
I think cypher is counting all nodes not just the top 5. the metric to watch is, 1 and 2 are they dropping? 1 /Satoshi:0.11.0/ 2229 (36.30%) 2 /Satoshi:0.10.2/ 1158 (18.86%)  Something you might want to consider; is of the massive mining power in china only one node (from the 105) is actually running XT https://getaddr.bitnodes.io/nodes/?page=1&q=China |
|
|
|
The 1MB'ers are happy watching that adoption isn't growing anymore. Stupidity at its best.
Stupidity is pretending that "adoption" and "growth" is all about users & transactions. Probably one of your more stupid posts. brg444 is correct. EG:  Closed minded stubbornness it pretending it's not. The reason for these phenomenal VC investments has nothing to do with the 'block size debate' this false cause fallacy, is yet another desperate attempt to argue some hidden agenda and self interest, in the face of overwhelming contrary evidence. |
|
|
|
|
Show Posts
