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/3245626c36497e6d82d68a20c2e00fcd75f938bf780333d3a5038dea71ba4aab
There 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?
POS attack - is possible?
Imagine, I do following:
Prepare set of 32 “special mature transactions” UTXOs.
Each transaction has relative big value, and matured for long time - for
example, 90 days.
Prepare 32 * 32 small “junk transactions” UTXOs.
Also, I modify my wallet to generate POS-block with using
IN-transactions, whose I wish.
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.
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.
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.
Is the coin age of all inputs being involved in calculating the reward reset to 0?
I’m asking, because here’s a quite “uncomfortable” idea of how to attack a PoS process by splitting the coins into transactions with small amounts: [HOWTO] kill any 100% PoS coins owning less than 1% of all coins.
As far as I understand it, this is no issue with Peercoin, right?
As far as I understand it, this is no issue with Peercoin, right?[/quote]
It’s true that you get slightly more chances to find consecutive blocks if you have many outputs than if you have only one. But I don’t see how this allows you to double spend with 1% of the coins.
As far as I understand it, this is no issue with Peercoin, right?[/quote]
It’s true that you get slightly more chances to find consecutive blocks if you have many outputs than if you have only one. But I don’t see how this allows you to double spend with 1% of the coins.[/quote]
I think it’s about lucky streak scenario, if so then yes, attacker with 1% can double spend - minter with one ‘fat’ output doesn’t have any chances of that.
The question is: what are his chances?
Since his chances are >0 he will surely(?) try to attack.
1 He need to split his stake into small pieces so he looses in down-rounding of reward and fees.
2 He need second stake, spending stake, because if he’ll send ‘dust-inputs’ tx recipient will notice it and require more confirmations to make a deal. Then, if attack will be successful, his minting stake will loose value due to lost of confidence in the network.
I think it’s much easier to attack destroy BTC with 1% by bribing night shift of few mining pools.
—edit—
In worse case we’ll have a ‘fork market’, whole thing needs calcs( don’t count on me) and simulations( I’ll try)
—edit2—
Made some simple simulations, I can clearly see advantage of dispersed stake against more concentrated but far from 1% attack possibility, after code refining I’ll publish my simulators.
