A critical vulnerability in PoS?
1. Halving POS-transaction
I see, at POS generation, wallet splits transaction by half, if age less
then 90 days.
There is missing detailed explanation, why it doing.
We assume, it made for preserve attack to POS block by carousel with
chain of huge transactions,
when value of some huge transaction grows and grows, and small set of
rich transaction like this
is occupy POS-engine, and disallow to another transactions participate
in POS.
However we see, there is splitting small transaction values, too.
for example, see emercoin block:
http://darkgamex.ch:2752/block/3245626c36497e6d82d68a20c2e00fcd75f938bf780333d3a5038dea71ba4aabThere is divided transaction with small value - 50EMC only.
We thinking, often split like this just unnecessary increases blockchain
size, and produce future transactions with higher size.
So, we decided to setup bottom threshold, and transaction with value
less than that threshold will not be split.
There is our changes:
wallet.cpp:1336
- if (block.GetBlockTime() + nStakeSplitAge > txNew.nTime)
- txNew.vout.push_back(CTxOut(0, scriptPubKeyOut));
//split stake
+ if (block.GetBlockTime() + nStakeSplitAge > txNew.nTime
&& nCredit > nCombineThreshold)
+ txNew.vout.push_back(CTxOut(0, scriptPubKeyOut));
//split stake if (age < 90 && value > POW/3)
So our question:
Are our changes reasonable? Can it hurt security with some way, which we
not aware?
Can you share your opinion?
2. POS attack - is possible?
Imagine, I do following:
1. Prepare set of 32 "special mature transactions" UTXOs.
Each transaction has relative big value, and matured for long time - for
example, 90 days.
2. Prepare 32 * 32 small "junk transactions" UTXOs.
3. Also, I modify my wallet to generate POS-block with using
IN-transactions, whose I wish.
4. I run quick loop with attempts to generate POS-block (not every
second, but just in the for loop).
On each loop iteration, I select for my minting transaction inputs
4.1. - one "special" transaction from [1]
4.2. - subset of "junk set transaction" [2], selected by bits in the
iteration counter.
5. As result of [4.1] there will be high probability of pass through
POS-barrier:
if (CBigNum(hashProofOfStake) > bnCoinDayWeight * bnTargetPerCoinDay)
As result of [4.2] there will be different hash values on each
iteration, so
I can generate many attempts to create POS-block with a different hashes.
Therefore tith this way, I have very high probability to generate my own
POS-block.
6. If so, I can create uninterrupted sequence of 32 my own POS-blocks,
and by this way -
rollback some fresh transaction, i.e. produce result like attack 51%.
Question: Is this attack possible? Or, I missing something, and cannot
see whole picture?
I asked Sunny King these questions, but received no reply.
Show Posts
