Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> Nodes don't do politics. People do, and politics is a lot larger with a lot > more moving parts than just node operation. Node operation is making a stand on what money you will accept. Ie Your local store will only accept US Dollars and not Japanese Yen. Without being able to run a node,

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Sorry for sending a double, hit the wrong button... Den 31 mars 2017 06:14 skrev "Natanael" : > > > Den 30 mars 2017 11:34 skrev "Natanael" : > > Block size dependent difficulty scaling. Hardfork required. > > Larger blocks means greater difficulty -

Re: [bitcoin-dev] High fees / centralization

Can there be a minimum amount to put up for mining ? I hope i’m not in violation with any ideology yet :) > On Mar 30, 2017, at 10:01 PM, Jared Lee Richardson wrote: > > That would be blockchain sharding. > > Would be amazing if someone could figure out how to do it

Re: [bitcoin-dev] High fees / centralization

That would be blockchain sharding. Would be amazing if someone could figure out how to do it trustlessly. So far I'm not convinced it is possible to resolve the conflicts between the shards and commit transactions between shards. On Thu, Mar 30, 2017 at 6:39 PM, Vladimir Zaytsev <

Re: [bitcoin-dev] High fees / centralization

There must be a way to organize “branches” of smaller activity to join main tree after they grow. Outsider a bit, I see going circles here, but not everything must be accepted in the chain. Good idea as it is, it’s just too early to record every sight…. > On Mar 30, 2017, at 5:52 PM, Jared

Re: [bitcoin-dev] High fees / centralization

On 3/30/2017 9:14 AM, David Vorick wrote: > On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" > > wrote: > > Raystonn, > > Your logic is very hard to dispute. An important special case is >

Re: [bitcoin-dev] High fees / centralization

> Further, we are very far from the point (in my appraisal) where fees are high enough to block home users from using the network. This depends entirely on the usecase entirely. Most likely even without a blocksize increase, home purchases will be large enough to fit on the blocksize in the

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Den 30 mars 2017 11:34 skrev "Natanael" : Block size dependent difficulty scaling. Hardfork required. Larger blocks means greater difficulty - but it doesn't scale linearly, rather a little less than linearly. That means miners can take a penalty in difficulty to claim a

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> The block size itself should be set based on the amount of fees being paid to miners to make a block. There's a formula to this as well, though going from that to a blocksize number will be very difficult. Miner fees need to be sufficient to maintain economic protection against attackers.

Re: [bitcoin-dev] High fees / centralization

On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Raystonn, Your logic is very hard to dispute. An important special case is small miners. Small miners use pools exactly because they want smaller, more frequent payments. Rising fees force

[bitcoin-dev] High fees / centralization

Raystonn, Your logic is very hard to dispute. An important special case is small miners. Small miners use pools exactly because they want smaller, more frequent payments. Rising fees force them to take payments less frequently, and will only tend to make more of them give up. With fees rising

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> What we want is a true fee-market where the miner can decide to make a block > smaller to get people to pay more fees, because if we were to go to 16MB > blocks in one go, the cost of the miner would go up, but his reward based on > fees will go down! > A block so big that 100% of the

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

>> If home users are not running their own full nodes, then home users have to >> trust and rely on other, more powerful nodes to represent them. Of course, >> the more powerful nodes, simply by nature of having more power, are going to >> have different opinions and objectives from the users.

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

Den 30 mars 2017 12:04 skrev "Luke Dashjr" : I don't see a purpose to this proposal. Miners always mine as if it's their *only* chance to get the fee, because if they don't, another miner will. Ie, after 1 block, the fee effectively drops to 0 already. I believe that with

Re: [bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

On Thursday, March 30, 2017 9:34:31 AM Natanael via bitcoin-dev wrote: > You want to really make sure your transaction gets processed quickly? > Transactions could have a second fee type, a specially labeled > anyone-can-spend output with an op_return value defining a "best-before" > block number

[bitcoin-dev] Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool)

I had these following ideas as I was thinking about how to allow larger blocks without incentivizing the creation of excessively large blocks. I don't know how much of this is novel, I'd appreciate if anybody could link to any relevant prior art. I'm making no claims on this, anything novel in