Hi all, I’m back with two new PeerAssets challenges, each with a bounty of 100PPC.
On peercoin’s testnet, the first card issue transaction has taken place!
You can find this card issue transaction by it’s id: 39b46de5f651ee9a6b50d62bee1f5cd3cb9e1169bf59418b38e1fc1b3ce0e529
Here is the raw transaction for people without a testnet client:
Solve one of the challenges below, explain how you solved it and the address to send the bounty to.
The bounty is paid to the first one to solve and explain correctly how the challenge is solved.
Marloon is incorrect, he is using mainnet not testnet (testnet addresses begin with n and m) and the dust outputs totally matter. I’m still working on it, I’m getting stuck up on the protobuf3 stuff.
You are indeed incorrect, but I will allow mainnet encoded addresses, no worry. I’m able to convert them
The output you selected is the PPC change output. It is an output to return the unused PPC to the sender, it has no meaning for the PeerAssets transaction.
V[0] is the tag, V[1] is the OP_RETURN of 1206c102c803db07. The other V[n] are destinations.
The first 2 digits are version number, then 3 repeated amounts, followed by a number of decimals.
So the amounts are:
06c1
02c8
03db
in hexidecimal.
There are 7 decimal places.
My question is how do I differentiate between a destination address and the change address? Does there always need to be a change address, even if it’s a zero output? So I can’t do other independent ppc outputs with the same txn?
vout[0] gives you which P2TH tag you should look for
vout[1]: (OP_RETURN) of the spawn transaction contains a protobuf message which contains Short name for the registered asset
the name itself can be easily decoded with a simple hex to string like http://string-functions.com/hex-string.aspx
The receiver addresses are correct! But the amounts are wrong.
No there doesn’t need to be a change output. After the specified outputs, you can include as many ppc outputs as you like. The number of receiving outputs is defined somewhere in the protobuf message.
Ok, it’s a packed repeated field, where the ‘06’ refers to the 6 following bytes. There is no decimal number, implying 1 is the smallest share.
So the amounts are:
1.
Hex: c102
Dec: 49410
2.
Hex: c803
Dec: 51203
3.
Hex: db07
Dec: 56071
ok guys, this hint should get you guys to the solution.
You can use the peerassets.js code by browsing to the peerscript-labs page and opening the console (CTRL+SHIFT+I). https://hrobeers.github.io/peerscript-labs/
In that console, you should require the libs to use.
Execute the following lines in the console:
taking c102 = 1100 0001 0000 0010
Then switch the bytes, cause varint does lowest sig digit first:
0000 0010 1100 0001
Drop the starting bit of each byte cause it’s an indicator:
000 0010 100 0001
Concatinate
10 100 0001
This equals 321 in decimal.
According to Mercator, there is only one valid deck spawn on PA prod: http://137.74.40.81:4000/
The other one is probably not a valid deck spawn, will check it later.
Unfortunately your reasoning is incorrect. As you can see on the Mercator page, there are two deck spawned from mpwRGC6URPCvdU4J83YbUzvqmBhKSDXk4p
One on PAprod (My little pony): 93dff38d65ef25ff9539ea2fa1fda45eb29d8bb989ca91399218c7e83e6630ea
One on PAtest (hello): 388838106ad9970e238a52db448dc2ab630d9b1ff547b8fa56b8713bb9ff9ff5
The card issue transaction is linked to one of these two.
For this the P2TH of the card issue transaction should be used, not the P2TH of the deck spawn.