Gold collapsing. Bitcoin UP.

[Christoph Bergmann]

It looks like the complete transformation of bitcoin has been achieved ... the brainwashing in communication channels such as r/bitcoin, on irc where much development chat takes place, on the mailing list, the ddosing.

Their story is just too alluring. Their conspiracies too mind fucking. Segwit will now be incorporated, making onchain scaling impossible. RBF is now necessary. Bitcoin is transformed. They succeeded by using the same methods as others when they took control over our forefathers. We failed in the same manner they did.

Yes, it doesn't look good.

The insidous thing with RBF and full block is, that it essentially destroys bitcoins as a mean of payment.

If blocks are full, you can't do transactions without RBF. If you do this, and you start with a low fee, you can need 48 hours untill your transaction is confirmed (or untill you do the doublespend). In this timeframe a merchant doesn't know if you have paid.

It's really a desaster and core and it's brainwashed fanboys have zero mind for real world needs and are proud for it.

 

[jl777]

adding

prune=550

with 0.12 will prune the local files to 550MB, you end up with about 2.5GB of data and cant be a full relaying node, but it is nice to be able to run on a low HDD system

 

[Christoph Bergmann]

@Christoph Bergmann what is the pruning command? is it dependent on 0.12?

No, but with 0.12 you can use the client as a wallet when it is pruned. Before wallet-functionality was disabled. Only downside is you can't import privkeys, what I think is one of the most important features of a client.

@jl777 - you can't relay as a pruned node? I didn't know. Do you have a source?

 

[jl777]

sorry, it does relay current blocks, but cant relay old blocks that have been pruned

pretty sure it still handles headers, but of course you cant get any tx that have been pruned
[doublepost=1457459213][/doublepost]On the RBF being required due to blocks being full, it is primarily an issue with the blocks being full, which causes many problems.

You cant force a miner to include a transaction right now. Given multiple transactions using the same inputs, the miner already should choose the one with the higher txfee.

If defining RBF behavior where the higher txfee is required to be accepted breaks things, then it seems things are already broken.

Basically if you dont know what txfee is needed for being confirmed, then zeroconf is kind of a contradiction. Just seeing the tx in the mempool is not sufficient to know if it will in fact be confirmed, even if 100% of the nodes have it in the mempool. So zeroconf is broken due to blocks being full.

If the worry is that the output destination will be changed, then maybe restrict any change in RBF enabled tx to only change the miner's fee and the change amount and not any other outputs. It really is nice to know the behavior of tx in a mempool

 

[freetrader]

It looks like the complete transformation of bitcoin has been achieved.

[...]

Segwit will now be incorporated, making onchain scaling impossible. RBF is now necessary. Bitcoin is transformed. They succeeded by using the same methods as others when they took control over our forefathers. We failed in the same manner they did.

The torch of bitcoin's dream will have to move somewhere else and carried in another fora. We lost the battle, but I hope, not the war.

I honestly think you're too pessimistic sometimes.

These are chaotic and troubled times, but the "other side" is scurrying around just as much as we are.
The problem is, they're trying to avoid the solutions that the majority wants, and the beauty of Bitcoin is that we have the power to implement the changes, as long as the majority wants it.

We can kick these miners out - even if the price signal from the market doesn't come as we expected it. It's too early to tell that IMHO, but that's opinions.

Meanwhile, there are serious efforts underway to produce alternatives which will put Bitcoin on track again. The way Satoshi wanted.

I think it's too early to get downtrodden. We got more battles ahead of us, but we also have much more fight in us. I would say we are only starting to discover our fighting spirit. Let's give it our best shot, like our forefathers did!

 

[satoshis_sockpuppet]

@Aquent
https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/
Something like this is the way to win the war.

 

[jl777]

how about 100x increase in tx capacity?
that should be enough for a while

use subchains to make larger blocksizes not have any orphan problems
and interleave them 10x

then the blocks wont be full and zeroconf will work again
make sure the miners understand they will make more revenues using this version and all of a sudden they will support it

The miners dont want to develop their own core, but if they get to choose between A and B, where B gets them more revenues, guess which one they will support? Of course, the fees cant be so high the users wont pay, so it is an indirect negotiation between the userbase and the miners

Maybe like the postal system, where people can pay for different classes of delivery? Something that wont be hard to get the mass users to understand. If you want it to get there reasonably fast, use firstclass postage. If you dont really care if it takes a week, then third class, if it absolutely has to get there in the next block, pay the premium

With that three level model, the miners are assured to get more txfees, the users can choose the service level.
[doublepost=1457459821][/doublepost]On the comment about "we can kick the miners out".... I have to disagree
The entire PoW design gives the miners the power, literally, to create new blocks. As such they are the ones that decide which hardfork wins

They are looking at a brutal revenue halving.
We need to help them so that the halving wont kill their business
They of course like the txfee auction, so of course they support smaller blocks, but as soon as there is a viable solution that gets them more revenues, they will support that.

I know this because I know a key fact many seem to overlook.

Miners like money

 

[freetrader]

@jl777 :

The entire PoW design gives the miners the power, literally, to create new blocks. As such they are the ones that decide which hardfork wins

There are the current miners (and the software they run) and there are potentially new miners (and the software those run). No miners should ever forget that.

They are looking at a brutal revenue halving.

All the more reason to make smart business decisions and put greed to the back burner for a second.

We need to help them so that the halving wont kill their business

They also have to help us (the rest of Bitcoin), not just themselves.

Either they show their willingness to listen to the call for bigger blocks and act accordingly, or they want to remain in control against the wishes of the majority and believe their businesses can survive that way. It's too early to declare safe victory, but Satoshi envisioned that miners can be ejected by the rest of the system - either through POW change (the "nuclear" option from which there is hardly any chance of return for the kicked miners) or through a real hard fork which retains the POW, run by those who've had enough. The only difference is the second option gives miners a chance to "reform". It also depends on an untested assumption that those interested in redistributing control of Bitcoin are able to act with more agility than the existing miners.

I believe your worry is that such forks would not be able to adequately defend against the existing miners. I don't think anyone really knows yet, because we're gearing up to test that hypothesis for the first time.
[doublepost=1457460919,1457460299][/doublepost]

On winning this war:

Source: http://www.bjornsolstad.com/wp-content/uploads/quote-gavin-andresen-bitcoin-developer.jpg

P.S. I hope Gavin actually said that But I believe...

 

[cypherdoc]

 

[jl777]

miners are businesses who have invested millions of dollars in mining equipment and all they care about is ROI. Anybody that believes that they care about anything else is not being realistic.

Regardless of the reasons, we are here where miners control the block generation and thus will vote for the hardfork that gets them more revenues. So the politics of this is to find the maximum revenues that the users (and bitcoin businesses) will pay and that embodied in a new hardfork will get unanimous miner support.

The argument that there wont be any tx for the miners to use, requires coordinating the tens of thousands of users, versus the dozen main miners and largest businesses.

Given roughly equal ROI expectations, the miners will choose what is best in the long term, but with the long term scenarios not anything that is guaranteed, the support will go to the max short term ROI. That's business. sorry

 

[yrral86]

Could someone review the interleaved blocks method for attack vectors?

I want to make sure I didnt miss any exploits against it before I code up a proof of concept. I think I can implement it with a small overlay layer on top of an arbitrary consensus mechanism, so it should be able to interleave normal blocks, subchain blocks, thin blocks, fat blocks, giant blocks, micro blocks, etc

At the high level, a block is just a grouping of tx that creates an ordering of the tx within and relative to other blocks, ie for (i=0; i<numtx; i++) will iterate through all the tx in a block. So the value of numtx changing, it is not affecting the code logic at all. The technical issue about large blocks are more about internal buffer sizes, especially if you connect to a lot of peers, so having 1GB blocks would require internal design changes as just changing a #define wont be enough like it is at the smaller sizes

Anybody that is saying that 2MB block is somehow going to break everything (other than backward compatibility) seems to be using non-technical modes of thinking. The economic effect is quite clear, especially at the border of totally full blocks, ie higher txfees.

And who wants higher txfees?
And who determines which hardfork wins?

The answers to the above two questions will lead to the solution. This is a politics thing so of course the answer is the normal answer.

James

I don't understand how interleaving helps. Every miner must still follow all chains in order to validate transactions.

 

[jl777]

making an altcoin is a weak nuclear option
if the exchanges are not using the new altcoin and the existing miners arent mining the new altcoin, then what has been achieved?

Baksheesh is what is needed to make this happen. Thousands of years of human behavior is not anything that can be changed in the short term.

 

[freetrader]

thus will vote for the hardfork that gets them more revenues

Yes - this is what they should be doing. We just need to give them that hardfork.

If they don't realize that that's what they want, other people will.

If we hardfork in a way that junks their equipment, they are out of the game (in the short term). But maybe a lot of new people will enter the game and they will be forgotten very quickly.

If we give them the chance to add their hashpower to a fork which preserves their investment - what's not to like? Sure, they could (and probably will - it's kind of rational) try to attack that fork. We must think of how to defend it. Eventually, some will come around (either through greed or realization that they just witnessed the system work as designed). Those would be adding strength to the chain again.

NOTE: I am assuming they will behave rationally. I don't think it's bad to make plans for the possibility that they don't. IMHO that means a change of POW would be needed (and done).

---

There is still time for all this to be resolved without such hard forks. But it's getting less and less.

And I for one will not sit by and watch while they "transform" Bitcoin into something entirely different from what it was envisioned. And I know I'm not alone.

 

[jl777]

I don't understand how interleaving helps. Every miner must still follow all chains in order to validate transactions.

It helps by increasing tx capacity and validating is a lot less work than mining, in fact all the nodes at large would validate all the interleaves, so not sure why it is any detriment that the miners have to follow all the interleaves

Also miners can choose which interleaves to mine, all of them, just the next one, something in between.

With 1MB of space per 10 minutes, there is finite capacity of the TX that fits in that 1MB.

You can encode things smarter and compress the blocks for a 2x increase
you can reducde the blocktime to 5 min to get a 2x increase
you can double the blocksize to 2MB for a 2x increase
You can interleave 10x (one for each minute on average) for a 10x increase

these are all orthogonal to each other and could all be combined for 80x increased capacity.

 

[cypherdoc]

time to upgrade to Classic 0.12.

the XT node guys should come over to Classic...

 

[jl777]

If we hardfork in a way that junks their equipment, they are out of the game (in the short term). But maybe a lot of new people will enter the game and they will be forgotten very quickly.

IMHO that means a change of POW would be needed (and done).

anything that doesnt work with current mining ASIC is an altcoin and is DOA as a bitcoin harkfork. If this is not understood, then I cannot help.

So the danger of being attacked, well this will be an issue with any hardfork, and the way to prevent this is to have a transition weekend where all the major miners and exchanges upgrade to the new hardfork, using a snapshot as of specific time on Friday. Then when things resume, the old bitcoin will still continue but the security will be with the miners and the businesses will want the highest security.

This is NOT a technical issue. It is a political/business issue where the main decision makers are give a clear path to more revenues and an exact migration path. With the majority of miners liking more money and the main exchanges wanting to avoid being double spent against, then after the hardfork weekend two thirds or more of the ecosystem will be on the new hardfork. If there isnt commitment from two thirds of hashpower and two thirds of the exchanges (by deposits), then it wont work.

With 2/3 hashpower, the other 1/3 can attack,but it wont work too well and they will be forced to switch or to continue mining the old fork, which then becomes an altcoin. Of course a version that activates with X% hashrate can achieve the same effect too,but that just seems to create a prolonged painful period of doubt, not to mention chance of unexpected things just being included for the ride.

 

[Peter R]

In the Bitcoin9000 paper the diff blocks should just be interpreted as what transactions a miner is trying to put into a block at present. So it could be all the transactions mentioned in a previous diff block plus some additional transactions minus perhaps a few transaction. No transactions are undone or unconfirmed because they are removed in a diff block. The proposal is not about more frequent mini-confirmations. It is about only needing to send a minimal amount of data when a real block is found.

What I was getting at was that if you do NOT allow transactions that were already included in a weak block to be removed, then those transactions actually have a measurable amount of security, as described in Section 8 of my subchains paper.

On the other hand, if the protocol allows subsequent weak blocks (diff blocks) to "cherry pick" certain transactions and remove them, then that one benefit is lost. In that case, the idea of a "partial" or "fractional" confirmation loses most of its meaning.

In my opinion, making the weak blocks "append only" (i.e. just like real blocks) is both the simplest and the most useful. What is the benefit of allowing the "diff blocks" to remove transactions?

 

[jl777]

append only seems to be quite important within each subchain. a valid tx should be confirmed and not subject to arbitrary changes.

The interleaved blocks will need to ignore double spends that occur via conflicting tx in two different interleaves

How about making the selection of which interleave to use based on the vin? This wont totally solve things, but for tx with single inputs, it would and that would reduce the number of invalidated tx in the interleaves

 

[yrral86]

It helps by increasing tx capacity and validating is a lot less work than mining, in fact all the nodes at large would validate all the interleaves, so not sure why it is any detriment that the miners have to follow all the interleaves

Also miners can choose which interleaves to mine, all of them, just the next one, something in between.

With 1MB of space per 10 minutes, there is finite capacity of the TX that fits in that 1MB.

You can encode things smarter and compress the blocks for a 2x increase
you can reducde the blocktime to 5 min to get a 2x increase
you can double the blocksize to 2MB for a 2x increase
You can interleave 10x (one for each minute on average) for a 10x increase

these are all orthogonal to each other and could all be combined for 80x increased capacity.

I still don't see the advantage over just increasing block size. It adds complexity for no gain.

 

[jl777]

it is orthogonal to increasing blocksizes
so it adds complexity for 10x gain in tx capacity.
it also allows potentially shorter latency for users (assuming the interleaved blocks arent all full)

so 10x capacity and faster response and being able to work in conjunction with increased blocksizes. you call that "no gain"?