No. The reason they won't is that they aren't going to waste precious mining resources for attacking a worthless UASF altcoin, while they can still use them for mining the good old bitcoins.

You guys really don't get it.

Bitcoin protocol has been designed to resist governments and the financial oligarchy. I'm talking about institutions that wage wars killing millions, just to benefit from it.  
And it has resisted...

If you think that a bunch of users or some developers can achieve what the world's biggest money makers haven't, then you are obviously delusional.

No, you couldn't spend from that address.
You need hash of a script, not of a public key.



You can get virtually unlimited number of P2SH addresses for a single private key.
You just need to hash a script with some kind of nonce.
For instance, it could be 1 of 2 mulitisig, where the second key is a random number.

Yes, but to be fair, from my own experience, gmaxwell has always been an active defender of a freedom of speech - on any forum I've seen.

Although, it makes me wonder why he publishes such kind of (controversial) material on a forum that uses excuses of "In the name of Wu, this post shall not pass." to censor posts which are menat to provide feedback on the proposed solutions.

I think all these people would be making much less fools of themselves, if they just suggested to change the 95% into 55%.

Although, considering that they would still be half short then, I can understand why some try to reach for a crazy ideas.

It's interesting news indeed.

I'm guessing he has done the reading.
Now he knows enough to be able to crack the Satoshi's system of the consensus guarded by the miners...

I think what tomtomtom7 is trying to say is that the common approach (used not only by core) is that even though the node verifies the transactions before a block is announced, the actual moment when the UTXO database is updated (and the changes committed to it)  is during the block's validation.

Whilst his solution updates (appends)  TXO database while verifying a transaction in the first place. Later,  during the block's validation, it's just logging  the information of which of the outputs from the TXO database has been spent by the block.

Wow.

Why don't you just publish it on reddit, so all these crazy kids spreading the panic and undermining the value of bitcoin could shut up once and for all?

Let me add some numbers here.

At this moment (block 461402) a typical UTXO index has 20438271 records (transactions) - that's 20 millions.
In the meantime a TXO index used by your solution needs more than 210 millions of records.
https://blockchain.info/charts/n-transactions-total

I guess that means 'yes'.

In which case I can give a more accurate feedback.

First of all, you did not get rid of UTXO-index.
You still have it.
You just extended it into TXO-index meaning that you index not only unspent transactions, but also the spent ones.


Now, how is it possible that your code performs better than the leveldb solution used by core..?

It has nothing to do with any "fast concurrent spend tree".
It has all to do with the (U)TXO index itself.
You use a hashmap as the index, which is much faster than the index used by core's leveldb engine.
But it also takes much more system memory.

I know, because I also use hashmap based UTXO index in my gocoin s/w.
So you don't have to tell me that it's much faster.
But it comes at the cost of the memory - you can't run this with e.g. 2GB of RAM.
From my personal experience I'd say you need at least 8GB.
And because you index both; spent and unspent transactions, you need even more memory than the UTXO-index solution, which you are trying to beat.

The bottom line is: no way this can perform better than a simple hashmap based UTXO-index.

You might want to look into my gocoin.

See how it works on a remote server through WebUI - it's basically what you need.

Not sure though what you mean by "high demand" - you might need another layer to proxy requests into it.

I think I get it.

So you basically extract all the transactions from the blocks and store them in a separate files (transactions1+transactions2), giving each transaction a unique sequencional "numeric index".

Then you have the index file (tx-index) where each different TXID points to the "numeric index" - that's actually your equivalent of UTXO-index, except that it includes also spent transactions.

And then you have the spend-index (addressed by the "numeric index") which basically tells you whether a specific output of a specific transaction has been spent.

Is that correct?

I honestly can't say that I understand half of what you've said.
But I'm trying.

Let's say you receive a new transaction and you have to verify it.
All you know is that it spends one output described as TXID-VOUT.

Correct me if I'm wrong: first you go through the last X blocks up the spend tree trying to find TXID there.
But say the TXID wasn't there - so then you have to go to the spend-index, right?

Now, how do you look for the TXID inside the spend-index?
How do you transform the TXID into the hash?

Oh, ok. Sorry, I didn't get the spend-index idea at first.

Can you please say something more about how it actually works inside?

As much as I like out of the box approaches to topics that interest me, to be honest I don't think this one can improve the overall speed of "common operations when validating transactions and blocks".

The UTXO index is there for a reason.
Personally I'd rather see some work on improving the index and the UTXO-db itself, rather than getting rid of it, which I think is not the right way to go.

Looking at the "performance results" one must remember that core (and the leveldb solution) use a limited amount of system memory, while this solution seems to be using all of it. Also, when the core gets to verify a transaction that is trying to spend a non-existing input, it won't consume so much resources. This is a potential DoS problem.

Sorry, I don't mean to be a mean person - it's just my cold professional opinion that it won't work well for you, for an actual real bitcoin node.
I wish you all the best with your project, @tomtomtom7, but I don't think this is a proper approach to optimise the performance.

Well, I will be looking forward to see this UASF of yours at work.

Or to you making fools of yourselves - which ever comes at the end.

No sir.

This would crash BTC price as nobody would be willing to invest in such an asset anymore.

Miners would be the biggest losers of such a change, left with millions of dollars worth of mining equipment that isn't profitable enough to even plug it in.

Ok. But what about outputs that never existed in the first place. How do you find that they don't exist?

How much memory and disk space does it need?

Do you keep it all in files on disk?

If you get to verify a transaction (block) that tries to spend an unexisting output, do you have to go back through all the files just to find out that it doesn't exist?

well, that's the actual interesting part.

because if you had like 40% of miners not willing to mine segwit transactions, thus delaying the payments...
wishlist 100% of miners would be mining non-segwit transactions, because why wouldn't they...

I don't know about you, but I would rather stick to the non-segwit payments, just to have them confirmed quicker.
especially if a fee for sending my BTC via segwit wold not be so much lower.

No, it would definitely have an impact.

Assuming of course that asicboost is a real thing and that it saves like the given 20% of some important costs.

Let me give you an example.

The miner gets 12.50 BTC + fees for mining a block.
Let's say that mining of a block without using asicboost costs him 10.00 BTC (in energy, hardware, staff, rent, taxes, etc.)
Note that we're talking about an average cost per block, over a certain span of a time.
Now, assuming that asicboost saves 20% of energy, lets say that with using asicboost, the cost of mining a block (for the same miner) is 10% lower - that's 9.00 BTC

So he has to choose to either mine only non-segwit transactions, to be able to use asicboost: getting a net profit per block of 3.50 BTC + fees
Or he can choose to mine segwit transactions as well, in which case he can't use asicboost and has to deal with a profit per block of 2.50 BTC + fees

In the second case he has to gather the total fees per block, being at least 1.00 BTC higher to break even.
So it would affect the relation between segwit and non-segwit transaction fees.
It would basically make non-segwit transaction fees cheaper, at the expense of segwit transaction fees.

Or maybe I should start from saying, that after segwit is activated, you as a user can still choose to send your money via segwit or non-segwit transactions.
And the average choice of the average user will most likely be based on the cost of the transaction - he will simply choose the cheaper one.
The rest is just the mechanics.