Gold collapsing. Bitcoin UP.

[cypherdoc]

everything US going down now.  that should only mean one thing for Bitcoin, UP:

[1714222188]

1714222188

[1714222188]

1714222188

[1714222188]

1714222188

[1714222188]

1714222188

[cypherdoc]

well, waddaya know.  i just plunked in GBTC into my TOS and got this!  $550/BTC!!!

[lebing]

with a $940 high 

[NewLiberty]

Cypherdoc while I still am "for" sidechains from a technical perspective, I'm beginning to think that you are correct that sidechains (etc) presents a conflict of interest for some core devs.  Ideally one could make bitcoin the best that it can be and use sidechains for things that are impossible for bitcoin to do.  However resistance to the 20MB change seems to me like people want bitcoin to be reduced to Gold's role -- backing a lot of other layers (lightning network, changetip, certain sidechains) that are what is actually used.  This opens up space for these other layers to make money.

And so we will end up with the all the same issues with services we have today because these for-profit corporate backed layers will be taking their piece of the pie, limiting transactional freedom, and confiscating balances at the whim of TPTB.

My guess is that this blogging avalanche of Gavin's is basically his way of saying that he's going to fight this one "to the death".

I hope he does.  I very strongly advocated AGAINST ALL his previous proposals.
I'd have sold out of the fork and stayed on the 1mb chain until a better solution was made.
He answered all my concerns with this one.  I'm on board.

It does little enough and gives us room to develop the necessary pieces for getting further.

[cypherdoc]

big, big trouble:

[justusranvier]

Added some diagrams which should greatly enhance understanding of the protocol:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

[NewLiberty]

Added some diagrams which should greatly enhance understanding of the protocol:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

Those sexy diagrams are a helpful addition.

I've always enjoyed the ongoing romance of Alice and Bob.

[Patel]

big, big trouble:

been waiting for this since 09

[rocks]

Added some diagrams which should greatly enhance understanding of the protocol:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

Those sexy diagrams are a helpful addition.

I've always enjoyed the ongoing romance of Alice and Bob.

They have a true romance, but Eve is always trying to spoil it.

justusranvier, thanks for sharing and explaining this work in this thread

[Livermore]

big, big trouble:

https://i.imgur.com/Y4OQ9hr.png

https://i.imgur.com/jBdgjHn.png

 I don't see any bearish signs yet. 200day EMA (white) still rising and price is above it. It has served as big big support 5 times.

However I do agree with your DXY bearish. Time for correction.

[cypherdoc]

big, big trouble:

 I don't see any bearish signs yet. 200day EMA (white) still rising and price is above it. It has served as big big support 5 times.

However I do agree with your DXY bearish. Time for correction.

last minute stick save $DJT +12.9.  still concerning.  we're very close.

we all have our indicators, methods with which to analyze the markets.  i like Dow Theory and cycle analysis so we'll see.

[solex]

I'm trying to find out if this is different to the last gavin update, where the rolling increase was proposed 20mb first and X% per increment after. Or if this new proposal is a different hacked increase to 20mb, thus requiring another hard fork in the future should this new limit need changing?
thanks

The new proposal is similar to Satoshi's original 2010 example where the max block size increases after a predetermined block height (115,000).
Instead, Gavin has code allowing a one-off increase, blocks up to 20MB which are later than a predetermined timestamp (1st March 2016 00:00:00 UTC). Block timestamps can only vary +/- a couple of hours from UTC. The advantage is that everyone will know the date by which they need to have their full node upgraded. Working with block height means that the cut-over could vary, a couple of weeks earlier or later, depending on difficulty changes.

Hopefully, this will get unanimous consensus in core dev (the 5 people with commit access) so that there is not a split. In theory Gavin could commit this change and someone else reverse it in an "edit war". That would be a sad situation. However, Gavin has a trump card which means he *should* be able to prevail even if he were to be in a minority of 4:1 against. Satoshi gave him the key to broadcast alerts to all the instances of BitcoinCore. So, he could fork the code and create, say "Bitcoin20", and advise all BitcoinCore users that they need to upgrade to Bitcoin20 (or BitcoinXT). I really hope it does not come to that.

He has consulted many stakeholders and indications are that major miners, exchanges, wallet providers, 3rd party services, and BitcoinXT will be on-board with the change. Those that want to see how 1MB affects fees might get their wish, because March 2016 is a fair way off and there may be long periods of nearly-full 1MB blocks. The resulting problems for ordinary users will create an avalanche of demand for the 20MB change, or Bitcoin20, if that is what it takes.

It is worth repeating: just because the max block size increases does not mean the blocks immediately get bigger. The 1st 20MB block may be 5 years away.

edit: the last point about future limit changes. Yes, other hard-forks may be necessary, however, 20MB is large enough that it buys time for alternative scaling methods to be fully developed and implemented, such as the Lightning Networks.

[sickpig]

Matt Corallo, Blockstream co-founder, just sent an email with the subject "Block Size Increase" on btc dev mailing list , you could read it all here:

http://sourceforge.net/p/bitcoin/mailman/message/34090292/

quoting the relevant part:

Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

bold is mine

[solex]

Matt Corallo, Blockstream co-founder, just sent an email with the subject "Block Size Increase" on btc dev mailing list , you could read it all here:

http://sourceforge.net/p/bitcoin/mailman/message/34090292/

quoting the relevant part:

Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

bold is mine

This is an example of what I was saying yesterday about core dev being too focused on the tech to see the big picture.
Matt suggests using the 1MB to apply upwards fee pressure. This is using a bit of software for something for which it was not intended. It is like using a hammer to fix a car engine. Mike Hearn has recently provided the missing piece of the puzzle of why Satoshi put the 1MB in place. It was for anti-spam when everyone who used Bitcoin needed to run a full node: a time when there were no lightweight wallets.

The idea which thezerg recently came up with is far superior to just leveraging the 1MB to force up fees (which won't work as people will start to abandon Bitcoin instead).

I'm for Gavin's 20MB increase.  But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works.  The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).

So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit).  In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve).  So supply (space in a block) can actually increase as demand increases.

You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit.  The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high.  In that case, we are no worse than today's proposal.

I like this proposal a lot.

High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all.

Reserving a front space in each block for high-priority non-fee transactions does two things:
1) It would ensure that high-priority transactions are processed in a timely fashion
2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly

This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing.

Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...)

If core dev came up with a variation of this, e.g. based upon a function of the median aggregate block fee over the previous 2016 blocks for the "buying" of blockspace >1MB then perhaps their position could be taken more seriously.

[Erdogan]

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

[smooth]

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

[majamalu]

given what has happened to Ripple today, i am forced to haul out one of my old time memes which i have now taken up to 70% probability in my own mind:

"The blockchain may only ever be applicable to Bitcoin as Money".

I'd put it this way: "We will know if the blockchain is applicable to more than money only when Bitcoin is well established as money".

[cypherdoc]

given what has happened to Ripple today, i am forced to haul out one of my old time memes which i have now taken up to 70% probability in my own mind:

"The blockchain may only ever be applicable to Bitcoin as Money".

I'd put it this way: "We will know if the blockchain is applicable to more than money only when Bitcoin is well established as money".

that is not bad.  not bad at all.  how about this:

"We will know if the blockchain is applicable to more than money only when after Bitcoin is well established as money".-majamalu

[majamalu]

given what has happened to Ripple today, i am forced to haul out one of my old time memes which i have now taken up to 70% probability in my own mind:

"The blockchain may only ever be applicable to Bitcoin as Money".

I'd put it this way: "We will know if the blockchain is applicable to more than money only when Bitcoin is well established as money".

that is not bad.  not bad at all.  how about this:

"We will know if the blockchain is applicable to more than money only when after Bitcoin is well established as money".-majamalu

Yep. If people understood this, we wouldn't have so many entrepreneurs and developers building castles in the air.

[molecular]

With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?

Yes it is called replace by fee

I'm not sure. With replace by fee, you can change other things in the transactions (like outputs), no? This makes double-spending much easier. I'm not sure wether "increase fee" can even be done, since it also requires changes to the outputs (and maybe inputs).

I see replace-by-fee as a very bad idea currently.