That is the part about how to make the modified tx to sign, but how do I treat a set of sigs for a tx where the different multisig signers use different SIGHASH modes?

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input. Things are complicated enough with the different vins for a tx, which might or might not be dependent on each other, but do I do an M of N and count any mismatched SIGHASH as invalid? and which ones are mismatched if there are three different ones? Maybe depending on other clues, it can be determined which SIGHASH mode is valid for a specific tx, but what if more than one could be valid? It seems there would need to be a precedence or at least much clearer explanation on what should happen in these mixed SIGHASH vins.

Then I can start to worry about what happens when we have a single tx that contains mixed SIGHASH vins. As it is, it is tempting to just require SIGHASH_ALL across the board.

James

As you know there are several SIGHASH types, each signature has a byte at the end to indicate how it was signed.

I searched, but could not find any definitive explanation of the precedence and how all the various SIGHASH types affect each other.

For most inputs with a single signer, this is a moot issue, though even that doesnt seem to be true as some parts of an input appear to propagate to the entire tx, or its outputs or at least something beyond the apparent scope of the vin that is being signed.

But for a multisig output that is being signed by multiple signers and where the signers are using different SIGHASH types, I think there needs to be a defined way of figuring out what SIGHASH mode is in effect.

A few lines in the official docs leaves a lot to the imagination. Is it even valid for there to be different SIGHASH types in the same vin? Maybe it is just rejected if they dont all match? Or maybe there is an implicit precedence that applies?

James

thanks. mostly makes sense, but the last part sounds like doubling via 5 minutes is a onetime gain and we will have to increase blocksize at some point anyway, so no sense in doubling via 5 minutes.

using that logic, it leaves a "free" doubling unused and to me that seems a waste. Also 5 minutes would offer the advantage of half the latency, which many would view as a positive. so it is not just a lack of negative, but a presence of positive

James

P.S. There are ways to increase capacity 10x or more without increasing blocksize or even reducing the blocktime, but would require more significant changes in the core, but doing both would boost the overall capacity and I thought more capacity was better than less

But didnt you see that Walmart itself will be forced onto the fake chain due to the inevitable forces of entropy? Surely, they wont have 100% uptime, so their server will need to be restarted and murphy's law GUARANTEES that they will lose not just the local copy of the blockchain, but absolutely all backups. And inevitably as surely as day follows night, they will connect to the attacker's node and sync to the fake history where their balance is zero.

However, there is at the same time a mass hypnosis spell being cast on all data center operators, so they dont notice they have a zero balance and then the critical Walmart nodes are now part of the attacker's network. And it is unstoppable, after Walmart, all the other companies realize that they too are on the wrong network and immediately switch to the attacker's network. Management is useless as they dont understand the tech at all and just writeoff all the lost funds as a business expense. None of the customers impacted by this make a single complaint so it is impossible for anybody at all to notice something is wrong. And thus the attacker's network is 100% guaranteed to takeover completely. The exact time for this is not possible to know, but typically it would happen within a few hours, maybe 10 hours at most, so dont talk about any 720 block thing.

And there is no point to say that any single assumption in the above is unlikely to happen. It will happen, this is by assertion. So it must happen and therefore the above is not unlikely at all. How can you say that any of the above is unlikely when it is assumed that it would happen?

James

Looking at the data, it seems the negatives of 5 minute block are pretty small and that would give 2MB of blockspace per 10 minutes. So if we assume the error rate difference between 5 and 10 minutes is small enough to being considered equal enough, then having 2 1MB blocks in a 10 minute period sure seems like double the tx capacity per 10 minutes.

Not sure why the blocksize is reduced at half the time, that would defeat the purpose.

given the assumption that 5 and 10 minutes are equal enough, then why would the blocksize need to be cut in half? We can also assume that 1MB per 5 minutes is not any problem for the nodes' bandwidth and wouldnt increase the error rates appreciably.

What error rate at 5 minutes requires cutting the size in half. If there is no need to cut the size in half, then how is it not a doubling in capacity?

Confused...

James

Nice!

The iguana bitcoin core implements a parallel download where the vast majority of data goes into read only files. This avoids needing a DB and also allows them to be put into a compressed file system vi mksquashfs. By processing the data in several stages, it is possible to stream data in at bandwidth saturation levels. I am not seeing any bottlenecks until it exceeds 500 mbps. The parallel download is able to get 70 to 120 megabytes/sec, which is 12 minutes for all 60GB blockchain.

Using 8 cores all of the data structures are created in parallel with hash tables and bloom filters built into the read only files. I am seeing about a half hour time to get to where things are ready for the last pass. The last pass does the final processing that is needed.

So, the parallel processing somewhat similar to what you write is already in functioning project and it does remove the bottlenecks the DB oriented approaches incur. The only thing that changes into the past is the state of the unspents, but this is encoded into 6 bytes per unspent by assigning a deterministic 32bit integer to each of the high entropy hashes. So the net result is a relatively compact set of utxo. Even the spends data can be processed in parallel once all the blocks are loaded and create a vector of updates to the unspents. By or'ing together these vectors, it creates a current set of unspents relatively quickly.

The searches using the read-only bundles can also be done in parallel, but I am seeing times of about 2 milliseconds for the equivalent of an importprivkey operation on a 1.4Ghz i5 laptop just serially processing the parallel files.

James

most companies probably just have a fixed fee and their customer support isnt usually doing more than repeating standard answers

in recent days (hours), the number of unconfirmed tx spiked, this allows the miners to cherry pick the highest paying tx and still fill a block, so they do.

I prefer to add BTC security into PoS chain

Do you want objective analysis, or just unthinking agreement to whatever you post?

If the latter, you can always make some sockpuppets. I just respond with my analysis using the meager resources at my disposal. And to my simplistic thinking, postulating an economically motivated attack that assumes all the victims will mindlessly just give the ability to attack is essentially the "send me all your crypto" attack. Hey, if they do, it works so it is rational and viable.

James

I didnt understand the answer of why a 5 or 6 minute block would be bad, other than a very small increase in orphan rate and delaying any txfee auction market for a while

I think his point is that once a highly unlikely set of assumptions are accepted as a given then you can correctly make highly unlikely set of conclusions

I actually dont see a flaw with that logic.

Instead of silly hypotheticals, what about using other blockchains as the TTP?

I thought in crypto economically unviable attacks are not relevant.

Did that change? I must have missed the memo.

Since you dont have any calculations about the cost of actually acquiring the recent keys, nor even a definition of what recent is, nor how even if you magically got those recent keys how you get the big active accounts to switch chains, it does not pass the common sense test.

But if you change it to reflect that you need to fool existing large stakeholders to transfer all their funds to a new account, sell them the newly emptied key. Do this half a dozen to a dozen times. All within a few days. Then create a fake chain and then make the largest accounts, like the central exchanges with lots at stake and long time accounts to all switch to the fake chain, ok, you got me. with those sets of facts, yes you can compromise a chain.

However, an equally ridiculous set of assumptions can be used to take over a PoW chain. So this is not anything specific to PoS, it is social engineering attack mixed in with mass hypnosis. Why not simply the attack where you ask everyone to just send you all their funds? That would work too

James

My estimate is that the danger to a PoS with a relatively short max reorg depth has less to worry about from a history attack than BTC has to worry from miner centralization

You have proven nothing. There is no market for formerly large stakeholding keys. But you claim by declaration that they are easy to get and at significantly below market price. And that the current mainchain will just magically switch to the attackers chain.

Making a wrong statement is not quite the usual standard that comes with the word "proof"

James

If these old keys can indeed be used for easy attacks (I have no confidence they can), then they are not useless and have value. And if it does have value, the people who have them will quickly find out about it

Please tell me who your VPS is that allows unlimited use for ~0 cost.

Are you seriously claiming that you can reorg to any depth and just a passage of time will lead to the attacker chain dominating? Because, because nobody in the entire community will notice that just maybe there is a new chain? that their balances are gone?

1. is not possible due to the duration of time it takes for large stakeholders to become non-stakeholders and I think it is fair to assume they wont sell keys to a chain they still have economic interest in. So you make a statement using "easily", when it is most likely quite difficult at best

2. this is just science fiction or is it fantasy. It assumes that nobody in the community notices during the entire attack, including the exchanges which are currently NOT running the fake chain. But of course, they will upgrade to the attacker fork where there balances are gone.

THAT is what you want people to believe? PoW has some advantages over PoS, there is no need to concoct fantasy scenarios, it just looks a bit strange. I made a way for BTC to become the central clock for all the other cryptos, at that point you wont have to worry about BTC going away for a very long time

James

So now they are low intelligence large stakeholders?

What use are empty private keys other than history attack?

Might as well postulate that miners will just let you use their facilities for a small fee, since you promise not to push any buttons.

Pick a PoS coin, any PoS. Prove this attack is possible in a cash positive way. I am sure you can get many privkeys for a dead coin, but maybe a bit of a problem short selling a dead coin.

So while this history attack is a scary sounding thing, the practical difficulties makes it not anything to worry about. Try it if you dont believe me, just try to get a single valueless empty key. Maybe post an ad somewhere for it? How exactly do you propose to get recent keys?

Getting the genesis key seems to not be of any use, so maybe you need to update the OP as being impractical and not having a single documented case of it ever working and its expected return is negative cashflow

James

And this appears to contradict your conclusion. If you need a matched set of keys all having large balances from very recent history, then this is either impossible or very expensive.

Especially if there is a one day timeframe.

Since it needs to be a recent set of privkeys all with large values, it almost seems to be provable that is it impossible, unless the coin's liquidity is 20% of total marketcap per day. How would it be possible for all large stakeholders to go from being large stakeholder to not having any in a very recent history timeframe?

THAT is the fatal assumption in your attack when combined with being able to buy such keys for below market value.

I can postulate a similar nearly costless attack by saying I will just by all the mining equipment for scrap values from all the large miners right after they upgrade. Since I am buying it from all of them, even though the hardware is slower, I will have more hashpower than any of them. 51% attacker is in the bag. It will be so easy to get them to sell me their useless mining equipment for $500

Or maybe not?

A large stakeholder doesnt immediately become a non-stakeholder. Most all cases it is a gradual process.

James

I look forward to the proof of the OP's conclusion "The cost of this attack is very low"

He saved you thousands of dollars for the privkey. that privkey is the one for the original genesis account. with it you can make any new chain you want

you could have gotten a BTC for it!

now the history attack is all but completed. Just need to run 1000 nodes with a fake (but somewhat believable history), then make all new accounts use the fake chain, and please ignore the long running nodes on the mainchain, that chain is not relevant anymore. Only the attacker's chain matters, so all the exchanges and blockexplorers will simply move to the attackers chain.

Happens all the time. Wont cost anything at all for this free attack.

James