Pooled minting

MatthewLM, creator of android wallet for ppc, expressed interest in creating pooled minting solution.

Here is my proposal for one block proof of concept:

  • candidates supply their stake (their transaction outputs eligible for minting) to server
  • server searches for their ‘minting times’ week ahead (timestamps when coinstake created from candidates’ outputs can mint a block if diff is not lower than 110% of current diff)
  • server sorts results by timestamp
  • server takes head result, creates coinstake with it and sends it to candidates
  • candidates verifies their rewards, sign inputs and return signatures to server
  • server publishes/broadcasts almost complete tx (w/o first input signed)
  • owner of first input (owner of ‘lucky stake’) waits for his minting time, creates PoS block and broadcasts it

To prevent ‘stealing block’ by owner of ‘lucky stake’ (he’ll mint his PoS block w/o other candidates’ input/outputs) his outputs in coinstake tx should receive additional 10% from participating coinage (taken from other candidates’ rewards).

1 Like

As I have outputs eligible for minting in coming days we can check this solution quite fast.
Please supply few tx outputs here, requirement is that 90% of expected reward for them(for each one) should be greater than 0.015 PPC.
We’ll create and sign coinstake by hand here, using signrawtransaction.

If you’re using Peerunity you can get list of your outputs by typing in debug console listunspent, copy and paste here one/more in form of

"txid" : "f56fc22e6de01ee13ba8ae7ceead64c0ab07076a92c18fa2217f463f962b9835", "vout" : 2,
Thanks for participating.

Here is coinstake tx that we will use.
It should mint a block @ 2014-09-28 14:55:46 UTC so we have 24h to create pooled PoS block!
Please post one of your outputs, at least 15 PPC older than 30 days. Thank you.
rawtransaction:010000007221285402b068508d614cd0ebc709266d520b33354a1b8d849f811d01d26bc5ff27db71380200000000ffffffff833db1031d36a3fa69242888c9d26b1707f09fbfae72b6c0696f6ef05779341c0100000000ffffffff02000000000000000000a3dd7116000000001976a91471435ed5ef708e16656ae9c1a52156666d21a2d688ac00000000
decoded:{ "txid" : "3f61afa9e662a58c535e5d25a4324f231468554a250756c79d652ba85f3fc1f8", "version" : 1, "time" : 1411916146, "locktime" : 0, "vin" : [ { "txid" : "3871db27ffc56bd2011d819f848d1b4a35330b526d2609c7ebd04c618d5068b0", "vout" : 2, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 }, { "txid" : "1c347957f06e6f69c0b672aebf9ff007176bd2c988282469faa3361d03b13d83", "vout" : 1, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 } ], "vout" : [ { "value" : 0.00000000, "n" : 0, "scriptPubKey" : { "asm" : "", "hex" : "", "type" : "nonstandard" } }, { "value" : 376.56105900, "n" : 1, "scriptPubKey" : { "asm" : "OP_DUP OP_HASH160 71435ed5ef708e16656ae9c1a52156666d21a2d6 OP_EQUALVERIFY OP_CHECKSIG", "hex" : "76a91471435ed5ef708e16656ae9c1a52156666d21a2d688ac", "reqSigs" : 1, "type" : "pubkeyhash", "addresses" : [ "PJv4DdZ1sFPiBXZEbj1gRmaFeQZWmB38wb" ] } } ] }
Now, every time someone will post his output- I’ll add input and output to this coinstake and ask him to sign this coinstake w/ sighashtype=SINGLE|ANYONECANPAY.
This will ensure output owner that he’ll receive his reward and allow others to add their inputs and outputs above his.

I don’t actually have any outputs that have reached minimum age unfortunately. But your concept is good. Thanks for taking the time to write it out and attempting to test it. Hopefully someone else will come along with some outputs to test.

You say “timestamps when coinstake created from candidates’ outputs can mint a block if diff is not lower than 110% of current diff”. Can I ask you what is meant by this?

@MatthewLM
To get each candidate’s output and iterate over time (seconds) to find kernelHash that satisfies at least 110% of current difficulty, f.e. diff=15.

Sir mably agreed to participate w/ his beautiful output on address PBeH6YDAfFGm76HntPFi86Y6WkJ3rHxGqy with 20 PPCs from 2014-06-12!
https://bkchain.org/ppc/tx/592443855d30c754afeb495982ced8a02700fb4c65f1bca644173df95912d3a7 (second output)

I’ve added his input and output to coinstake, now it is

010000007221285403b068508d614cd0ebc709266d520b33354a1b8d849f811d01d26bc5ff27db71380200000000ffffffff833db1031d36a3fa69242888c9d26b1707f09fbfae72b6c0696f6ef05779341c0100000000ffffffffa7d31259f93d1744a6bcf1654cfb0027a0d8ce825949ebaf54c7305d854324590100000000ffffffff03000000000000000000a3dd7116000000001976a91471435ed5ef708e16656ae9c1a52156666d21a2d688ac40c93101000000001976a914217e95987cfae5a0de37143333399e473dc8f9b388ac00000000

{ "txid" : "edddcdf8b09188a40ddbb60e685e4c4ffb22d44df006512fb7c4a5ed2887f7fe", "version" : 1, "time" : 1411916146, "locktime" : 0, "vin" : [ { "txid" : "3871db27ffc56bd2011d819f848d1b4a35330b526d2609c7ebd04c618d5068b0", "vout" : 2, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 }, { "txid" : "1c347957f06e6f69c0b672aebf9ff007176bd2c988282469faa3361d03b13d83", "vout" : 1, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 }, { "txid" : "592443855d30c754afeb495982ced8a02700fb4c65f1bca644173df95912d3a7", "vout" : 1, "scriptSig" : { "asm" : "", "hex" : "" }, "sequence" : 4294967295 } ], "vout" : [ { "value" : 0.00000000, "n" : 0, "scriptPubKey" : { "asm" : "", "hex" : "", "type" : "nonstandard" } }, { "value" : 376.56105900, "n" : 1, "scriptPubKey" : { "asm" : "OP_DUP OP_HASH160 71435ed5ef708e16656ae9c1a52156666d21a2d6 OP_EQUALVERIFY OP_CHECKSIG", "hex" : "76a91471435ed5ef708e16656ae9c1a52156666d21a2d688ac", "reqSigs" : 1, "type" : "pubkeyhash", "addresses" : [ "PJv4DdZ1sFPiBXZEbj1gRmaFeQZWmB38wb" ] } }, { "value" : 20.04000000, "n" : 2, "scriptPubKey" : { "asm" : "OP_DUP OP_HASH160 217e95987cfae5a0de37143333399e473dc8f9b3 OP_EQUALVERIFY OP_CHECKSIG", "hex" : "76a914217e95987cfae5a0de37143333399e473dc8f9b388ac", "reqSigs" : 1, "type" : "pubkeyhash", "addresses" : [ "PBeH6YDAfFGm76HntPFi86Y6WkJ3rHxGqy" ] } } ] }
To simplify calculations I resigned from my provision! Instead- mably’s reward is rounded down and he will have to pay 0.01 tx fee from his reward so after all cuts his output value is 20.04! 0.04 pure profit, 4 tx for free, lol.

What mably has to do is sign his part of coinstake.
Before any signing, he should verify transaction inputs/outputs:

decoderawtransaction PASTE_COINSTAKE_HEX

If it’s ok, he can sign it. Before he do this he’ll need to export his privkey for PBeH6YDAfFGm76HntPFi86Y6WkJ3rHxGqy.

dumpprivkey PBeH6YDAfFGm76HntPFi86Y6WkJ3rHxGqy

And

signrawtransaction PASTE_COINSTAKE_HEX [] ["PASTE_PRIV_KEY"] "SINGLE|ANYONECANPAY"

He should send me hex result of signing. His coins are safe.
Edit: he should also decode signed hex once more to see if his key was used with correct inputs - there should be only one ScriptSig in decoded tx!

Next person who want to participate doesn’t have to wait for mably to sign his part, he can post me his output and after adding input/output to coinstake participants can sign their inputs asynchronously.

Cheers

I’m not sure I follow. Can two uxto’s can receive minting reward in the same block? I thought that each POS block rewarded only a single utxo.

@Chronos
Sure they can.
Proof hash contains only first UTXO, but all other inputs older than 30 days add coindays to reward also.
Here is final coinstake, I’ll use it today.

010000007221285403b068508d614cd0ebc709266d520b33354a1b8d849f811d01d26bc5ff27db7138020000006b483045022100b9ca92d0d5100ee26c842a013879952c9851a325c10a0f1159d7bd79eca25c2502200c69b3a96dba393da8af7570e8d94c864c88d7248c71b28887c43ffdf7641ccf0121039cad406ca6c67f7e1340011a20c3dfa9eb0312cd278f36768c932ee862a5830bffffffff833db1031d36a3fa69242888c9d26b1707f09fbfae72b6c0696f6ef05779341c010000006a47304402205bb117004d25db8f96c20b2f9eca74f172043042c114d5f2547d0c6a56b64855022077ee27933ba6d8f7fe563f1484c7f5f85012417cf14febb05c5d793019179a9e01210323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8affffffffa7d31259f93d1744a6bcf1654cfb0027a0d8ce825949ebaf54c7305d85432459010000006b483045022100cc29e2d068aa09d06e08c62fe4d59cb6bad83e2d282e38743c1b24467f0dc28202204850333c5f944791ed55dfb5a089a5f14a9cc882feae8afdd679b05e40a93b658321028b816daf93ccd54a32da15ef98eb6955d22f4e404452921b9d12771481276613ffffffff03000000000000000000a3dd71160000000023210323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8aac40c93101000000001976a914217e95987cfae5a0de37143333399e473dc8f9b388ac00000000

{ "txid" : "47b76e63ae75fb961a7cb6a7fde02b32627c9c09eb92695f544db77626802e44", "version" : 1, "time" : 1411916146, "locktime" : 0, "vin" : [ { "txid" : "3871db27ffc56bd2011d819f848d1b4a35330b526d2609c7ebd04c618d5068b0", "vout" : 2, "scriptSig" : { "asm" : "3045022100b9ca92d0d5100ee26c842a013879952c9851a325c10a0f1159d7bd79eca25c2502200c69b3a96dba393da8af7570e8d94c864c88d7248c71b28887c43ffdf7641ccf01 039cad406ca6c67f7e1340011a20c3dfa9eb0312cd278f36768c932ee862a5830b", "hex" : "483045022100b9ca92d0d5100ee26c842a013879952c9851a325c10a0f1159d7bd79eca25c2502200c69b3a96dba393da8af7570e8d94c864c88d7248c71b28887c43ffdf7641ccf0121039cad406ca6c67f7e1340011a20c3dfa9eb0312cd278f36768c932ee862a5830b" }, "sequence" : 4294967295 }, { "txid" : "1c347957f06e6f69c0b672aebf9ff007176bd2c988282469faa3361d03b13d83", "vout" : 1, "scriptSig" : { "asm" : "304402205bb117004d25db8f96c20b2f9eca74f172043042c114d5f2547d0c6a56b64855022077ee27933ba6d8f7fe563f1484c7f5f85012417cf14febb05c5d793019179a9e01 0323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8a", "hex" : "47304402205bb117004d25db8f96c20b2f9eca74f172043042c114d5f2547d0c6a56b64855022077ee27933ba6d8f7fe563f1484c7f5f85012417cf14febb05c5d793019179a9e01210323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8a" }, "sequence" : 4294967295 }, { "txid" : "592443855d30c754afeb495982ced8a02700fb4c65f1bca644173df95912d3a7", "vout" : 1, "scriptSig" : { "asm" : "3045022100cc29e2d068aa09d06e08c62fe4d59cb6bad83e2d282e38743c1b24467f0dc28202204850333c5f944791ed55dfb5a089a5f14a9cc882feae8afdd679b05e40a93b6583 028b816daf93ccd54a32da15ef98eb6955d22f4e404452921b9d12771481276613", "hex" : "483045022100cc29e2d068aa09d06e08c62fe4d59cb6bad83e2d282e38743c1b24467f0dc28202204850333c5f944791ed55dfb5a089a5f14a9cc882feae8afdd679b05e40a93b658321028b816daf93ccd54a32da15ef98eb6955d22f4e404452921b9d12771481276613" }, "sequence" : 4294967295 } ], "vout" : [ { "value" : 0.00000000, "n" : 0, "scriptPubKey" : { "asm" : "", "hex" : "", "type" : "nonstandard" } }, { "value" : 376.56105900, "n" : 1, "scriptPubKey" : { "asm" : "0323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8a OP_CHECKSIG", "hex" : "210323cb186c4e14422dbee24cbd03ccb954545ab4f9d37cee355808a8225e9ccc8aac", "reqSigs" : 1, "type" : "pubkey", "addresses" : [ "PPvHSsr7xFdVNGBY16Ddga3X6UbJXaoQPM" ] } }, { "value" : 20.04000000, "n" : 2, "scriptPubKey" : { "asm" : "OP_DUP OP_HASH160 217e95987cfae5a0de37143333399e473dc8f9b3 OP_EQUALVERIFY OP_CHECKSIG", "hex" : "76a914217e95987cfae5a0de37143333399e473dc8f9b388ac", "reqSigs" : 1, "type" : "pubkeyhash", "addresses" : [ "PBeH6YDAfFGm76HntPFi86Y6WkJ3rHxGqy" ] } } ] }
I had to fix it a little- to use PubKey instead of PubKeyHash in second coinstake output(protocol requirement). But, since mably signed-off his input with SINGLE|ANYONECANPAY flags I could easily modify coinstake inputs/outputs and his old signature was still valid with my new coinstake!

Here is also request for Core Devs - ppcoin should have SIGHASH_ANYTIME flag which sets TX.TIME to ZERO - it would make pooled minting easy and popular.
Imagine: owner of 15 PPCs publishes his input/output with set of signatures (SINGLE|ANYONECANPAY|ANYTIME) for different positions in coinstake, f.e. from 2 to 100, on public board, reddit or something.
Once his COINDAYS/REWARD ratio will satisfy ANY minter - minter will pick his input/output and include in his coinstake, w/o any interaction from small stakeholder.
This way also small stakeholders will receive their reward in case they cannot wait 2 years to spend the coins. Additional interest from including small stakes will put more stake from bigger holders into active state.

LOL

And here it is…
World’s first pooled PoS block !
https://bkchain.org/ppc/block/8d3f4ca8b5bd6d450e9d60b4280b521926917f4d684079c9d56ddee7c882a158
I want to thank mably for his UTXO and software, ppcd, without it - this giant leap for mankind wouldn’t be possible.

1 Like

Nice!

All we need to do now is automate the job… if only that was easy. :slight_smile:

To get each candidate's output and iterate over time (seconds) to find kernelHash that satisfies at least 110% of current difficulty, f.e. diff=15

What did you mean by 110% difficulty, ie. if diff is 10 now, look for kernel hashes that satisfy diff 11? Why would you do that? You could be missing out on kernel hashes that satisfy lower difficulties. Instead when there’s a new output to mint he server can iterate through time to discover the soonest kernel hash to satisfy current difficulty, or if there is a new block iterate through time to discover the soonest kernel hash for the new difficulty for all outputs.

Quite easy if participants don’t want to disturb whole process.
Make it easier - vote for SIGHASH_ANYTIME. It will be trivial then.

110% is to prevent wasting ‘signing rounds’ and make scheme simpler, currently PoS diff is very low so missing few hashes isn’t a problem (UTXO used in this example coinstake could work even with diff=150). I’ll not argue about it, just want simpler scheme for ~zero penalty.
Searching results should be ‘cached’ even from 50% of current difficulty, storage is cheap.
Later, maybe pick UTXO with highest luck (lowest coindays) to optimize usage of available UTXOs set.

From static-stake side (coindays donor) things look simple: he needs coinstake timestamp.
With it, he can create even 1000 signatures at a time (for 1000 possible positions in coinstake), send it to the server and calmly wait for reward.
Server has to build coinstake tx and send it to active-stake (winning UTXO) owner.
Active-stake owner has to be online on his minting time to get mempool, previous block hash and bits (difficulty), sign coinstake, build block and sign it.
Done

SIGHASH_ANYTIME would have to be a hard fork though.

There is the consideration of balancing the inclusion of outputs in a minted block without going toward the kernel hash and keeping outputs behind to ensure blocks come through regularly. Perhaps only adding outputs that will be minted furthest in the future, keeping the closer mints available to keep the supply of blocks going. Then the assumption would be that those furthest mints would get replaced by new available outputs, before they would have come around.

So that would mean using the fast minters to benefit the slow minters. And the 10% fee as you mentioned in the first post could be the incentive for fast minters to help out.

If I understand this correctly…

  1. Does Peerunity already take advantage of this (when one utxo mints, combine all eligible utxo’s in the wallet with it)? Could it? Any reason not to?
  2. If all minters participated in one giant pool, would this severely reduce the number of POS blocks? (One POS block every 30 days could be enough to reward the entire network!)

If adopted on a wide scale, this seems unhealthy for network security. What are your thoughts?

@Chronos

  1. https://github.com/Peerunity/Peerunity/blob/master/src/wallet.cpp#L1387
  2. Why would all concentrate there? This solution is only for small stakeholders which want to use their coindays before they have to move/spend coins- else their coindays would be wasted, by such ‘delegated minting’ they’ll gain at least few cents to pay fees. I’d expect positive security impact as it presents additional interest from minting.

I’d expect no more than one pooled block a week or day currently, even if we’ll count in paper-wallet-holders who hold huge amounts of coindays and don’t want to touch them online. This way, they can create signatures in insulated environment (old laptop?). They’ll indirectly participate in network security by creating additional incentives.

Congratulations for having successfully performed this pooled minting!
If your assumption is right and this pooled minting is only done rarely it might indeed increase the network security.

[quote=“kac-, post:13, topic:2925”][…]
I’d expect positive security impact as it presents additional interest from minting.

I’d expect no more than one pooled block a week or day currently
[…][/quote]

But what if this process becomes automated by an adjusted client and pool software and a lot more blocks are generated this way?
Wouldn’t that lead to one of the centralization problem that PoW coins face?
I think of the security risk that is caused by pooled mining at PoW coins.
Pooled minting is not so different after all.

If the relative part of the minting that is done at pools is high enough to pull off attacks you have players that don’t have much to lose (assuming that the pool operators have not much coins themselves or sell them before they perform the attack) but may be able to achieve a gain by pulling off an attack (assuming that the gain from the attack is ecomical wise more attractive than continuing normal pool operation).
I don’t really like that scenario…

To protect against re-org attacks, the clients can verify that the block is being placed onto the main chain before signing them.

That would be a protection allowing the pooled minting to enhance the network security without generating attack vectors. Great!

No, there is no way to verify that before signing.

To make things clear - pooled minting in that form doesn’t increase chance to find a block. Set of participating UTXOs is taking reward WITHOUT securing the network. It’s kind of cheat.

The goal: to let smaller minters take 1% in case they cannot mint before spend. Bigger players dilute the currency by 1%/year, from economic point of view without such pooled minting they are simply taking 1% from smaller holders.

[quote=“kac-, post:17, topic:2925”][…]
To make things clear - pooled minting in that form doesn’t increase chance to find a block. Set of participating UTXOs is taking reward WITHOUT securing the network. It’s kind of cheat.

The goal: to let smaller minters take 1% in case they cannot mint before spend. Bigger players dilute the currency by 1%/year, from economic point of view without such pooled minting they are simply taking 1% from smaller holders.[/quote]

So you let those UTXOs piggyback on a block that is being solved allowing those piggybackers to get the coinstake reward that is corresponding to their coin age without having that coin age contributing to solving the block?

Economical wise it’s not cheating as you already explained.
And security wise I doubt that can really be seen as a drawback.
Even a peerbox consumes energy(I’m not even talking purchasing costs here). If the energy consumption is higher than the coinstake rewards that could be expected from letting it run continuously, one might simply not mint with these little amounts of Peercoins!

Why not? Only sign the block if the hashPrevBlock is OK.

@MatthewLM
Ah, that way, yes, active minter has full control. Others may only only watch.