Hilo oficial del Bitcoin (VIII)

15:40 gavinandresen It is all a question of priorities: time spent fixing bufferbloat for home users is time not spent doing something else
15:40 wumpus for wallets there is a difference between enterprise needs an dhome user needs, not for infrastructure nodes
15:40 sipa you don't have to work on that if you do not think it is important
15:40 sipa having different priorities is fine, i think
15:41 sipa i think home hobbyists are important, because the code should be able to run for them
15:42 wumpus natural even, in an open source project everyone always has their own priorities
15:42 sipa if we fork, they may get less attention
15:42 gavinandresen mmm. Until the priority is “support more tras*actions per second”. That is DEFINITELY a priority for every single large bitcoin business I’ve spoken with.
15:42 sipa yeah
15:42 sipa it's not about support
15:42 wumpus well once the consensus library is 'complete' (for whatever that means), you could use that in any node project
15:42 sipa we can support 100x more tras*actions
15:43 sipa the question is at what cost
15:43 gavinandresen the question is “are the benefits worth the cost"
15:43 wumpus if you want to make a bitcoin-core-for-professionals you could evven start from scratch and write one, as long as you use the same consensus module
15:43 sipa this is not scaling up a web 2.0 project where you increase traffic when you have a larger cluster
15:43 gavinandresen … or “are the costs of not doing it too great"
15:44 sipa sorry, going to leave this discussion for my own sanity
15:44 gavinandresen sipa seems grumpy…..
15:45 hearn it's dragged on for far too long
15:45 gavinandresen I agree.
15:46 wumpus no use in repeating the same disscussion with the same arguments time after time, we just can't agree on this
15:47 hearn this is the point where in any other project, the leader/maintainer makes a final decision and then it either results in a fork or doesn't. anyway, time to go home
15:49 wumpus normally, yes, except that a fork on this would fork the chain too, and result in a catastrophe
15:50 gavinandresen wumpus: no, it won’t. I can get the big exchanges and merchants to run bigger-max-block code.
15:51 gavinandresen And I can certainly convince enough hashing power that the rest of the miners would have to go along.
15:51 wumpus yes, you could, but it would be kind of pointless if the rest of the network rejects those blocks
15:51 gavinandresen what do you miccionan “rest of network” ? SPV nodes don’t care....
15:52 wumpus the nodes running either an old version or the other fork
15:52 gavinandresen If merchants and miners and exchanges go along, then who else matters?
15:52 helo everyone else
15:52 sturles Users.
15:52 gavinandresen Those nodes will get automatic alerts telling them it is time to upgrade.
15:52 gavinandresen … we don’t even have to break out the alert key....
15:52 helo i would love to warm up my old miners if all of the big miners start mining invalid blocks
15:54 jeremyrubin helo: why not go so far as to switch to a different hash
15:56 sturles
ACTION thinks pluggable sidechains would be a more flexible and scalable and future proof way of solving the block size problem.

15:57 helo i think everyone hopes it will be... there's just that small matter of it being released
15:57 sturles Yep. Not ready today, of course.
16:25 gavinandresen wumpus: I downloaded and installed and am running 0.10.1rc3 on my mac, no issues.
16:26 wumpus gavinandresen: good to hear
18:55 petertodd gavinandresen: fwiw much of the financial world is *not* on board with a blocksize increase based on the discussions I've had; don't assume you have the consensus you think you do
18:55 petertodd gavinandresen: there's very big worries among them that they'll open up bitcoin to regulation for obvious reasons
18:57 petertodd gavinandresen: equally, that crowd understand very well that linear scaling increases do nothing in the face of exponential demand increases

Hacer clic para expandir...