l8
New Member
Posts: 31
|
Post by l8 on May 7, 2018 21:21:18 GMT 1
När jag tar absolutvärdet av det som visas i listtransactions och använder som amount från en egengenererad adress till en annan så verkar det funka bra. Dock har jag hittills inte lyckats luska ut hur jag ska signa...
payload = {
"method": method,
"params": params[0]
}
ska då params[0] vara:
param[0] = 'hash_from_createraw' '[{"txid":"","vout":}]' '["priv_key"]'där private key är den key som hör till den address dit jag skickat coinsen från min plånbok...
måste alla pramaterar finnas med, tex txid? När jag skickar från plånboken angav jag endast 'hash from createraw' och det gick bra.
|
|
s
New Member
1SeanW4LgPMph7N5g5ZT38bEoHXQU4dn6
Posts: 31
|
Post by s on May 7, 2018 21:33:44 GMT 1
Halloj - de där som har negativ amount, har du inte en motsvarande även med positiv amount?
Tack för bra tips Thomas med round() för att säkert få med hela satoshis. Det borde räcka med en avrundning för all praktisk användning i kursens exempel. Jag misstänker att det kan finnas exempel på flyttalsvärden som, efter avrundning, återigen blir omöjliga att representera. Det finns förtsås fixed point flyttal någonstans, men det får jag lämnas till en senare övning.
|
|
s
New Member
1SeanW4LgPMph7N5g5ZT38bEoHXQU4dn6
Posts: 31
|
Post by s on May 7, 2018 21:35:56 GMT 1
L8 annars ta och jämför resultaten från rpc-anrop gettransaction vs rpc-anrop getrawtransaction och hex-strängen som fås skickar du via RPC-anrop decodetransaction. Jag behövde ha stld för det för att kunna få fram rätt scriptPubKey, som jag skrev lite mer om igår.
|
|
|
|
Post by thomaslundqvist on May 8, 2018 6:32:09 GMT 1
l8: helt rätt tänkt med att först skicka till dina egna adresser, listtransactions ska du inte bry dig om, den gäller bara den inbyggda plånboken, du skriver ju din egen nu! Slå upp adressen i block-explorern istället.
När det gäller round() så finns det en mer avancerad modul "decimal" men den är lite onödigt krånglig att använda tror jag...
|
|
l8
New Member
Posts: 31
|
Post by l8 on May 8, 2018 20:01:33 GMT 1
Hmmm.... Nu fr jag tebax en hel massa från decoderawtransaction:
L8 payload to send: {'method': 'decoderawtransaction', 'params': ['020000000001018ff67b34d234b73a46f56f27ae7786d37239dc8a440c14181d92d4c93709617a0100000017160014d31761eb50a83aa360a763b03ae5df95be8ae907fdffffff0280f0fa02000000001976a9140d6501bd4e58640d0f47a8684c131d264e299c3a88ac8b6b8a0e0000000017a9145c14cca2c5bdf119af60209e79c22370bd90ce72870247304402205f4a60a41c4e83f0e02bcafabd929a2b0685e3bba733ad3fdb6e84cb0f5ef4ef02202e59947873377ee428548160ed0b2153d7539441a1540d21285ddc18c8c2e18d0121026503bca68a018e465b1922e0587ebd6539fc4b8efaa469dcef216ab221083b1c7f2c0000']}
L8 response: {'result': {'txid': 'fac065146ef731b722a53ab78ab2c2cf116b99bf438dac90e8015af548ab8e4b', 'hash': '83ebc8bd2c0fda24677ac9d8f33ec8988bedfde5856130b2f5ba5f6589eb35c2', 'version': 2, 'size': 249, 'vsize': 168, 'locktime': 11391, 'vin': [{'txid': '7a610937c9d4921d18140c448adc3972d38677ae276ff5463ab734d2347bf68f', 'vout': 1, 'scriptSig': {'asm': '0014d31761eb50a83aa360a763b03ae5df95be8ae907', 'hex': '160014d31761eb50a83aa360a763b03ae5df95be8ae907'}, 'txinwitness': ['304402205f4a60a41c4e83f0e02bcafabd929a2b0685e3bba733ad3fdb6e84cb0f5ef4ef02202e59947873377ee428548160ed0b2153d7539441a1540d21285ddc18c8c2e18d01', '026503bca68a018e465b1922e0587ebd6539fc4b8efaa469dcef216ab221083b1c'], 'sequence': 4294967293}], 'vout': [{'value': 0.5, 'n': 0, 'scriptPubKey': {'asm': 'OP_DUP OP_HASH160 0d6501bd4e58640d0f47a8684c131d264e299c3a OP_EQUALVERIFY OP_CHECKSIG', 'hex': '76a9140d6501bd4e58640d0f47a8684c131d264e299c3a88ac', 'reqSigs': 1, 'type': 'pubkeyhash', 'addresses': ['12DpnZzu8Ugjk1YhN9iUfnUDsPPvffPd6a']}}, {'value': 2.43952523, 'n': 1, 'scriptPubKey': {'asm': 'OP_HASH160 5c14cca2c5bdf119af60209e79c22370bd90ce72 OP_EQUAL', 'hex': 'a9145c14cca2c5bdf119af60209e79c22370bd90ce7287', 'reqSigs': 1, 'type': 'scripthash', 'addresses': ['3A5u1MeyBmPvNXGysUgcLr4Nn3EN4DopCZ']}}]}, 'error': None, 'id': None}
Vadr det som ska med i signtransaction-hela följande harang?
{'asm': 'OP_DUP OP_HASH160 0d6501bd4e58640d0f47a8684c131d264e299c3a OP_EQUALVERIFY OP_CHECKSIG', 'hex': '76a9140d6501bd4e58640d0f47a8684c131d264e299c3a88ac', 'reqSigs': 1, 'type': 'pubkeyhash', 'addresses': ['12DpnZzu8Ugjk1YhN9iUfnUDsPPvffPd6a']}
|
|
s
New Member
1SeanW4LgPMph7N5g5ZT38bEoHXQU4dn6
Posts: 31
|
Post by s on May 8, 2018 22:01:34 GMT 1
Kolla dokumentationen för RPC-metoden signrawtransaction.
- Första parametern är samma raw transaction (string) som du kan skicka in i decoderawtransaction som kontrollsteg.
- Till andra parametern hade jag problem med scriptPubKey - och fick tag på den via RPC-anrop getrawtransaction där jag kunde gräva fram rätt vout.
- Tredje är en lista med privata nycklar. wif-format funkar visst (och möjligen inga andra format?)
I PDF:en med denna kursuppgift står "Ange adress att skicka från: " så jag håller mig med samma begräsning, så jag begär via input() att användare kopierar och klistrar in wif-nyckeln från några rader högre upp där nyckel genererats. En bra wallet sparar förstås nycklar i en krypterad fil. Och backupar...
|
|
|
|
Post by thomaslundqvist on May 9, 2018 9:37:14 GMT 1
Och jag repeterar: scriptPubKey behövs inte! Den gamla transaktionen finns typiskt i blockkedjan redan. Noden letar själv upp det som behövs...
|
|
nikke
New Member
Posts: 30 
|
Post by nikke on May 18, 2018 9:33:47 GMT 1
Hur får man txid från den första tx? sendrawtransaction ger tillbaks "The transaction hash in hex" vilket väl inte går att använda? Edit: det gick visst att använda, jag får tillbaks t.ex
{'error': None, 'result': 'ee03bfdd07164b15c094a320014e0d8297fbf505d07a86d9e88840735b7f4127', 'id': None}.
Om result är id, vad är då det andra id?
|
|
|
|
Post by thomaslundqvist on May 18, 2018 14:43:12 GMT 1
result är mycket riktigt txid. Det sista id är ett id som kan användas vid rpc-anrop (gäller alla anrop). När du gör anropet så kan du skicka med ett id så vet du att det är rätt svar du får tillbaka (förmodligen förberett för mer asynkrona rpc men vet inte om det egentligen används).
|
|
nikke
New Member
Posts: 30
|
Post by nikke on May 18, 2018 21:34:49 GMT 1
|
|
|
|
Post by thomaslundqvist on May 19, 2018 18:51:53 GMT 1
Om en transaktion X spenderar en tidigare transaktion Y måste X komma efter Y i ett block. Annars är ordningen inuti ett block slumpmässig (eller egentligen kan den bestämmas på valfritt sätt av en miner).
|
|
nikke
New Member
Posts: 30
|
Post by nikke on May 19, 2018 21:02:49 GMT 1
Det jag borde skrivit var ordningen i vout. Jag tycker den verkar slumpmässig?
|
|
|
|
Post by thomaslundqvist on May 20, 2018 9:00:58 GMT 1
Ja! Om du inte bygger transaktionen helt själv (plånbokensprogrammet är det egentligen som bestämmer).
|
|
