Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bitcoin Blocksize: A Summary

rusty.ozlabs.org

Post reply on HN
Print view View original

91–96 of 96 posts

Re: The Bitcoin Blocksize: A Summary

#91

Post by jwilkins »

mike_hearn wrote: post #81
Bae8anoh wrote: post #33

Earlier quoted context omitted.

Read up on the history of Mike Hearn, he has wanted to fork Bitcoin into his own governance for years, this is just an excuse. In 2011 he was proposing to Satoshi that he should take over the project[0], in 2013 he was trying to pitch the concept that development was stagnant and that a fork was needing to fix it[1][2], and now in 2015 it's again come about that he has found an excuse to attempt it (this time with so…

Oh dear, you have some serious anger issues, don't you? I have not wanted to fork Bitcoin for years. I still don't - I have many better things to do, like working on Lighthouse or oh .... really anything else. Screwing about with gitian and gcc all day is right at the bottom of my list of "fun things to do on a sunny day". But the fact that Bitcoin Core was heading for disaster was obvious for a long time now. It has…

Core has been moving away from failed experiments like unconfirmed transactions. (How that wasn't an obviously flawed idea in the first place is beyond me, but hey, might as well get the data..)

No one in core is saying that growth is a bad thing and must be avoided, the key point that has been repeated is that the approach you and Gavin took with XT was not a good one. It has been poorly thought out from the get go. The initial proposal contended that we had to go to 20MB or we were doomed, remember that?

Bitcoin needs a steady hand at the wheel. Wladimir and co are putting out a solid amount of code with remarkably little disruption.

Your statement re: orchid is a little misleading. You might be a maintainer, but https://github.com/subgraph/Orchid/commits/develop shows that your contributions are minor. https://github.com/subgraph/Orchid/graphs/contributors

Why do you continue to cause this degree of public spectacle and unnecessary drama?

Re: The Bitcoin Blocksize: A Summary

#92

Post by jwilkins »

paulmd wrote: post #83
pstrateman wrote: post #70

Earlier quoted context omitted.

> It's impossible to maintain the massive amount of processing power spent on this solely through transaction fees. 0.00625 BTC in fees is enough to match the current block reward. That's to say the current security of the network would continue on if everybody paid $1.63 per transaction in fees. > You still have the problem of the chain becoming too great in size, but that's a problem with some pretty obvious answer…

$1.63 per transaction rules out the possibility of microtransactions. I personally don't think that anyone has the moral authority to deem a use-case "wrong" for a currency. You need to support transactions involving pocket change just as well as you support transactions in benjamins to see wide acceptance. Such high transaction fees effectively make the currency indivisible to a substantial degree. Sure you can send…

Why does the penny transaction have to confirm in 10 mins? Currently, and for at least a couple of years, you will likely still be able to send 0 fee transactions. The time for them to appear in a block will increase however.

Have you heard of Lightning (https://lightning.network)?

Re: The Bitcoin Blocksize: A Summary

#93

Post by kentt »

davidgerard wrote: post #16

Important point about this debate: * There is not the organic transaction growth for this to even be a problem, and there is no evidence there ever will be. Bitcoin's only real-world use case is illicit goods. * Even 20MB blocks would be susceptible to a cheap spam attack like the DDOS "stress test" a few weeks ago. This is the quintessential bikeshed: a fight to the death for insanely low stakes.

I use Bitcoin to buy from NewEgg. It's the only way I can buy from them as a Canadian buy from the US site (they decline my PayPal and Credit Card for some unknown reason).

I use it for buy Joylent for Europe, because I don't get screwed by exchange rate the Visa/PayPal give me.

These are real everyday uses of Bitcoin that normal people could engage in that to my knowledge are better provided by the Bitcoin network than by traditional system.

Re: The Bitcoin Blocksize: A Summary

#94

Post by celticninja »

DennisP wrote: post #43
celticninja wrote: post #39

Earlier quoted context omitted.

What is more likely is that when that problem is solved it will be applied to bitcoin rather than create a new coin.

That's the theory, but changing the consensus algorithm would be a far bigger change than just adjusting the block size, which is causing plenty of controversy already. If they do try to move away from mining, they'll have to first get agreement from the miners, who've already purchased a lot of mining equipment.

I don't think so. You see if you move away from mining you need the agreement of the users not the miners, who by design will become surplus to requirements. If a method of securing the Blockchain without miner is found you could be pretty certain most people would back that option if it promoted further decentralisation.

Re: The Bitcoin Blocksize: A Summary

#95

Post by mike_hearn »

jwilkins wrote: post #91
mike_hearn wrote: post #81

Earlier quoted context omitted.

Oh dear, you have some serious anger issues, don't you? I have not wanted to fork Bitcoin for years. I still don't - I have many better things to do, like working on Lighthouse or oh .... really anything else. Screwing about with gitian and gcc all day is right at the bottom of my list of "fun things to do on a sunny day". But the fact that Bitcoin Core was heading for disaster was obvious for a long time now. It has…

Core has been moving away from failed experiments like unconfirmed transactions. (How that wasn't an obviously flawed idea in the first place is beyond me, but hey, might as well get the data..) No one in core is saying that growth is a bad thing and must be avoided, the key point that has been repeated is that the approach you and Gavin took with XT was not a good one. It has been poorly thought out from the get go.…

Orchid is developed in the bitcoinj tree these days, not the subgraph repository. Upstream imported changes one time, but I continue to handle it on a day to day basis.

Unconfirmed transactions are not at all a failure. The data is in - usage of them has been increasing over time, not decreasing. When someone attacked shapeshift.io (an exchange that uses them!) and double spent, their response was "We get significant value from fast payments, we can easily patch the exploit they used, and we're going to continue with our current path".

The initial proposal was not "20mb or we're doomed". It was "we need more space or we're doomed, 20mb seems to work OK based on ". But lowering it to make the Chinese pools happy is not a problem, as it's an upper limit.

I'm afraid the drama has all been created by others. The limit was always meant to be removed, remember? We're not the ones suddenly trying to change the plan.

Re: The Bitcoin Blocksize: A Summary

#96

Post by kang »

meshr wrote: post #90

I have a question, why not to solve the bitcoin issues another way: by decreasing the amount of transactions by changing the way of paying with bitcoins. I suggest using bitcoin wallets as a cash banknotes and send bitcoin private keys (i.e. the wallet itself) instead of paying from the wallet to transfer money. So everyone should have a set of bitcoin wallets with different bitcoin amounts instead of using one bitco…

Because no one prevents the sender to keep a copy of that wallet. Wallets are nothing but list of your private keys. Suppose I gave my private keys to you, what prevents me to not use them before you use those keys?
Post reply on HN