Pooled minting

It is amazing. But I don’t understand why outputs of different addresses can be combined (as the source code indicates). Or did I get what you are doing wrong?

@mhps
Coinstake transaction is normal transaction, It has constraints only for first input and fists two outputs and summarized amounts. Additional input/outputs can be anything.
Solution here is using not popular, but available and treated as standard, signature flags - so coinstake can be quite easily pre-built before actual minting.
Other thing is that from protocol v03 your future ‘minting times’ can be searched very effectively, so I can ‘predict’ which coinstake timestamp will be used to mint a block, that gives me time to gather participants and prepare pooled coinstake transaction/block.

Yes I talked about prediction in a past post. Since stakemodifier changes every 6 hours you can only predict maximum 6 hours ahead of time, right?

No, stake modifier is static for UTXOs, it’s just not pre-computable before certain time(~9 days after tx currently), e.g. you receive 100 coins, wait ~9 days, now you can search future, till 2106-02-07, to find when those 100 PPCs will be able to mint.
It would be impossible in v02 protocol times, but v02 was vulnerable to real pre-computation.
Now it’s secure, it gives good minters chance to prepare and not miss their chance, thus provide optimal block flow and difficulty increase - it evens chances between pre-computing attacker and standard-minting honest network part, now the attacker have to be the best minter - better than 50% of the newtork.

No, stake modifier is static for UTXOs, it’s just not pre-computable before certain time(~9 days after tx currently), e.g. you receive 100 coins, wait ~9 days, now you can search future, till 2106-02-07, to find when those 100 PPCs will be able to mint.
It would be impossible in v02 protocol times, but v02 was vulnerable to real pre-computation.
Now it’s secure, it gives good minters chance to prepare and not miss their chance, thus provide optimal block flow and difficulty increase - it evens chances between pre-computing attacker and standard-minting honest network part, now the attacker have to be the best minter - better than 50% of the newtork.[/quote]

It is so good it must be illegal :wink: Seriously it’s good to know this is possible at a given diff. However difficulty changes will put some uncertainty in it. So the prediction is a prediction of probability given an difficulty change model. Still that uncertainty can be small in many cases, and will be getting smaller as time passes because the model can get more accurate as time gets close to the “block moment”.

One draw back with predicted minting is that if, for example, 50% minter turns off wallet when it’s not their time yet, then if for some reason difficulty drops unexpectedly, there will half as many minter on-line, thus making it twice easier to make a 51% attack.

@MatthewLM

mably hosts a tool that serves data needed to find future stake.

Query unspent outputs of an address: http://178.62.206.205:9999/PBMN1yUSoRuaotjQRWjyk6mDRibjPuzigw?skip=100
(returns max 100 unspents, use skip=X for more)

To get a ‘minting template’ of an UTXO: http://178.62.206.205:9999/a33bb0ffe83df5642b63f3ee4177e307d2e947a613f458438475170a6978e0e2:1

If you need to port CheckStakeKernelHash to Java here is simplified Go implementation: https://github.com/kac-/umint/blob/master/ukernel.go

Thanks kac-, I’m sure this will come in useful.

Do you know if mably’s tool is open source? If not it would be better adapting Abe for this purpose.

Edit: Ah I see it’s part of the ppcd project, correct? It’s worth taking a look.

Hi Matthew,

It’s rather kac-'s tool than mine :slight_smile: he did most of the work, thanx to him.

For your information, ppcd is a full node peercoin implementation written in Go derived from the Conformal btcd project, licensed under the copyfree ISC License.