Author

Topic: [ANN][FLO] A Worldwide Public Record | Alexandria | ETDB | Medici | 0.15 Segwit - page 119. (Read 516115 times)

hero member
Activity: 630
Merit: 502
Tested on php with a newly compiled daemon:
Code:

require_once("jsonRPCClient.php");

$rpc_host="127.0.0.1";
$rpc_port=12345;
$rpc_user="some_rpc_user";
$rpc_pass="some_rpc_pass";

$client = new jsonRPCClient("http://".$rpc_user.":".$rpc_pass."@".$rpc_host.":".$rpc_port."/");

$raw_transaction=$client->getrawtransaction("de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce"1);

echo 
"
";
print_r($raw_transaction);
echo 
"
"
;

?>

Output:
Code:
Array
(
    [hex] => 02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b78010000006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab9041000000001976a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e
    [txid] => de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce
    [version] => 2
    [locktime] => 0
    [tx-comment] => text:Go with the FLO
    [vin] => Array
        (
            [0] => Array
                (
                    [txid] => 780b3d811f9a82c00b9055f2d27eb9c7959cc58f0588cc934e852a5fcf8ad10c
                    [vout] => 1
                    [scriptSig] => Array
                        (
                            [asm] => 3045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f01 037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672
                            [hex] => 483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672
                        )

                    [sequence] => 4294967295
                )

        )

    [vout] => Array
        (
            [0] => Array
                (
                    [value] => 50.04221891
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => OP_DUP OP_HASH160 e969fd5fb098999ab4df96429cf33aed4f33fe07 OP_EQUALVERIFY OP_CHECKSIG
                            [hex] => 76a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac
                            [reqSigs] => 1
                            [type] => pubkeyhash
                            [addresses] => Array
                                (
                                    [0] => FT7Hso1wQ7DpCtKNzGz3HNMHvA5KeKnLEd
                                )

                        )

                )

            [1] => Array
                (
                    [value] => 11
                    [n] => 1
                    [scriptPubKey] => Array
                        (
                            [asm] => OP_DUP OP_HASH160 ad5de988256a98eee955c77b1e92c7ff065ebf99 OP_EQUALVERIFY OP_CHECKSIG
                            [hex] => 76a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac
                            [reqSigs] => 1
                            [type] => pubkeyhash
                            [addresses] => Array
                                (
                                    [0] => FMdns8Aq7YNRxE43G1NeTzAggz38ed2Qy6
                                )

                        )

                )

        )

    [blockhash] => 7e2f59f9ad863318538afc76c1ca553714e50f20b81db3ba650fb06ad149947a
    [confirmations] => 2348
    [time] => 1371831466
)

Works good and it's certainly easier to manage an array than having to parse it yourself. The only thing required is to strip text: and probably any html if you don't want anyone doing anything malicious with it (although you can't really do much in 120 characters).
sr. member
Activity: 301
Merit: 260
FLO dev

I just checked, it re-uses the same code so you get the "freebie" Smiley


EDIT: pulled, compiled, testing in ubuntu very nice and thanks for your activity on this (and putting up with me)  Grin

Thanks for your suggestions, anything that makes the coin easier to use is good Smiley
full member
Activity: 196
Merit: 100

I just checked, it re-uses the same code so you get the "freebie" Smiley


ok great and I AM being an idiot.

Getrawtransaction takes a TXid.

decoderawtransaction takes raw transaction hex not a TX id.

If you have the TXid you can skip the extra step of the decode request, but if you already have the hex might as well just decode it.

EDIT: pulled, compiled, testing in ubuntu very nice and thanks for your activity on this (and putting up with me)  Grin
sr. member
Activity: 301
Merit: 260
FLO dev

I'm not sure why decoderawtransaction exists I assumed it was legacy but bitcoin.it implies they were added at the same time.

I suppose if you are building your own transactions it might be useful to segment your code.

I just finished the script i was working on about to recompile this and see if they're re-using the code internally already. You may have gotten a freebie on this one.


I just checked, it re-uses the same code so you get the "freebie" Smiley
full member
Activity: 196
Merit: 100
ok, I don't know the internal daemon code, is it within scope to add it to getraw transaction so that If I input

Code:
getrawtransaction de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce 1

It's included in the decoded output?

I think that might break too many other application that depend on getrawtransaction to only output the raw transaction.



Oh, no. Note the added "verbose" parameter at the end of the request.

getrawtransaction has always provided the decoded transaction data if you ask it to.

Just to be a dork:  http://lotto.coinworld.us/FLO/bc/gethelp.php The full help of the FLO daemon (page takes a moment to load all the detail directly from the daemon each time).

I'm not sure why decoderawtransaction exists I assumed it was legacy but bitcoin.it implies they were added at the same time.

I suppose if you are building your own transactions it might be useful to segment your code.

I just finished the script i was working on about to recompile this and see if they're re-using the code internally already. You may have gotten a freebie on this one.

sr. member
Activity: 301
Merit: 260
FLO dev
ok, I don't know the internal daemon code, is it within scope to add it to getraw transaction so that If I input

Code:
getrawtransaction de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce 1

It's included in the decoded output?

I think that might break too many other application that depend on getrawtransaction to only output the raw transaction.
full member
Activity: 196
Merit: 100
ok, I don't know the internal daemon code, is it within scope to add it to getraw transaction so that If I input

Code:
getrawtransaction de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce 1

It's included in the decoded output?

From "the outside" it looks like a cut and paste op. In the next hour I'll be recompiling your GIT.

If there's reasonable re-use in the daemon code it may be done already.  I haven't done any comparisons but it seems at a glance the decoded data returned by getrawtransaction is the same as the data returned by decoderawtransaction.

I'll cross my fingers if you didn't test that might be added as well Smiley

sr. member
Activity: 301
Merit: 260
FLO dev
full member
Activity: 196
Merit: 100
full member
Activity: 196
Merit: 100
sr. member
Activity: 301
Merit: 260
FLO dev
In my opinion it should really be the responsibility of the decoderawtransaction method to also provide the text as part of the returned array rather than relying on people to write their own parsers to get this information from the hex string manually.

Implemented "tx-comment" field in decoderawtransaction response.

Github source code updated.

Example:

Code:
decoderawtransaction 02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b78010000006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab9041000000001976a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e


19:38:20

{
"txid" : "de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce",
"version" : 2,
"locktime" : 0,
"tx-comment" : "text:Go with the FLO",
"vin" : [
{
"txid" : "780b3d811f9a82c00b9055f2d27eb9c7959cc58f0588cc934e852a5fcf8ad10c",
"vout" : 1,
"scriptSig" : {
"asm" : "3045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f01 037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672",
"hex" : "483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 50.04221891,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 e969fd5fb098999ab4df96429cf33aed4f33fe07 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"FT7Hso1wQ7DpCtKNzGz3HNMHvA5KeKnLEd"
]
}
},
{
"value" : 11.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 ad5de988256a98eee955c77b1e92c7ff065ebf99 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"FMdns8Aq7YNRxE43G1NeTzAggz38ed2Qy6"
]
}
}
]
}
full member
Activity: 196
Merit: 100

In my opinion it should really be the responsibility of the decoderawtransaction method to also provide the text as part of the returned array rather than relying on people to write their own parsers to get this information from the hex string manually.

This is true, the daemon should provide this string in raw text as it does basically every other part of the data with the exception of the scripted stuff. since you can tell getrawtransaction to decode it anyways, you have everything in one request.

That was the point of some of my conversation earlier, it sounds like the coin dev considers these conversions trivial, but a lot of us don't. I did spend some time at the wiki yesterday and it looks like it will be simple just tedious to write such a parser in php.

Considering the variability of transaction size and the chance of a few other zeros popping up elsewhere in the hex data , the thing to do is write a transaction parser if you want this to be reliable.  I'm already using sendmany with FLO and that means that the "text:" is not added for me if I choose to add a comment. Anyone else who uses this feature in a service may or may not choose to follow the coin dev's example with the "Text:" prefix.


Without having a transaction where there are multiple payments, each with different comments I can't really improve the code & test for this kind of situation and I can't be bothered trying to hunt through the blockchain for a situation where this is the case. If someone wants to point me towards a transaction where this is the case I'll look into improving the function but for now it'll do the job assuming there's only one payment with a comment in the transaction.

What?

I don't think what you are talking about is feasible.

These comments are at the TX level, not actually associated with a specific output of the TX.

No matter how many payments you send it should only be one comment per TX.
hero member
Activity: 630
Merit: 502
OK seeing as the string length is stored in the hex how about this:
Code:

function get_florin_transaction_text($hexstring)
{
    
$output="[no text]";
    
$last_zeros_pos=strrpos($hexstring"00000000");

    if(
$last_zeros_pos)
    {
        
$mini_hexstring=substr($hexstring, ($last_zeros_pos+8));
        if(
hex2bin(substr($mini_hexstring210))=="text:")
        {
            
$character_count=hexdec(substr($mini_hexstring02));
            
$output=hex2bin(substr($mini_hexstring12, ($character_count*2)));
        }
    }
    return 
strip_tags($output);
}

$hexstring="02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b78010000006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab9041000000001976a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e";
echo 
get_florin_transaction_text($hexstring);

?>

Hmm no, nothing to do with the hex (assuming hex string means transaction comment for you). My post was rather clear: you could have that byte sequence in every other fields in your transaction.

And yes, as far as I'm concerned the hex string to be passed to the function would come from the method getrawtransaction but I'm aware that this is not without it's problems because the sender could have sent multiple payments and this only takes into account one comment in that eventuality.

Without having a transaction where there are multiple payments, each with different comments I can't really improve the code & test for this kind of situation and I can't be bothered trying to hunt through the blockchain for a situation where this is the case. If someone wants to point me towards a transaction where this is the case I'll look into improving the function but for now it'll do the job assuming there's only one payment with a comment in the transaction.

In my opinion it should really be the responsibility of the decoderawtransaction method to also provide the text as part of the returned array rather than relying on people to write their own parsers to get this information from the hex string manually.
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
If it appears in a random position within the hex string, perhaps. But with only one hex string to go on there is really no easy way to test other eventualities.
Hmm no, nothing to do with the hex (assuming hex string means transaction comment for you). My post was rather clear: you could have that byte sequence in every other fields in your transaction.
hero member
Activity: 630
Merit: 502
If it appears in a random position within the hex string, perhaps. But with only one hex string to go on there is really no easy way to test other eventualities.
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
Bad idea, you could have 746578743a in the transaction inputs, in the signature, in the output amounts, or even in the hashes you send the money to.
Actually you could have this everywhere.

Taking the last 746578743a in the transaction would be better
Taking the first 746578743a after the last 00000000 would be even better
Actually parsing the transaction would be the only way to be sure
hero member
Activity: 630
Merit: 502
I'd use something like this to get the text in php:
Code:

$text_output
=false;
$hex="02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b78010000006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6cf602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e69a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab9041000000001976a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e";

$decoded_text=hex2bin($hex);
$text_pos=strpos($decoded_text"text:");
if(
$text_pos)
{
    
$text_output=strip_tags(substr($decoded_text, ($text_pos+5)));
}

if(
$text_output)
{
    echo 
$text_output;
}
else
{
    echo 
"No text in transaction";
}

?>

Note: the hex2bin function requires php 5.4 or above.
full member
Activity: 196
Merit: 100
Hey, whoever owns florin address FMgofXxjaHW7wyw8mYMQd189eCq7dZGi93 -


I'm guessing it's a reader here, got caught in an issue at the lotto site where an empty drawing was run before the deposit confirmed.

Your new reservation address is FV9YQMAX95BFxBHsg9FioaThG9GQnS9xNZ and also I added a couple of tickets for you in the next drawing.

On another topic - frobley, thank you for your support Smiley
sr. member
Activity: 301
Merit: 260
FLO dev
All right I hope I don't end up feeling like an idiot but I'm tired and I can't see it in the tx data:

http://lotto.coinworld.us/FLO/bc/index.php?transaction=de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce

can someone help me fish it out or something so it can be displayed cleartext>?



02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b7801000 0006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6c f602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e6 9a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a 010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab904100000000197 6a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e

1b (27) is the length of the message.

The full message is:

"text:Go with the FLO"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


Also note that only those transactions that have "Tx version" = 2 have a message at the end.

Quote
Since messages are currently a maximum of 140 characters, the three bytes before the length byte should be 0.

It would be nice for a coin creator to know how his coin works Roll Eyes
The 00000000 at the end will never change... Only 1B describes the size of the comment.

I assumed since I'm writing an a 32 bit value to the serializer it would use 32 bits to encode the value. How would a value of 256 be encoded then?


VarInt... Should be something like fd0100, check on the wiki.

Ah, something similar to Google's Varint in protocol buffers. Thanks for the info Smiley
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
All right I hope I don't end up feeling like an idiot but I'm tired and I can't see it in the tx data:

http://lotto.coinworld.us/FLO/bc/index.php?transaction=de2824f54ccf5391bfc0c9b5a0a5e09214e4c045627a44c696bfb325f20c92ce

can someone help me fish it out or something so it can be displayed cleartext>?



02000000010cd18acf5f2a854e93cc88058fc59c95c7b97ed2f255900bc0829a1f813d0b7801000 0006b483045022100ec82001cca4924e0f9b857153a0e6e07bcb5d657b090b870929014a14dbe6c f602207047b247b6c6b99f985406d9df184c81ff302b01c0dea1c396df1b8d0061713f0121037e6 9a13d14797dc3d9555cc75da616edb9c1a058876183fe0171f85c7ebf2672ffffffff02c35d462a 010000001976a914e969fd5fb098999ab4df96429cf33aed4f33fe0788ac00ab904100000000197 6a914ad5de988256a98eee955c77b1e92c7ff065ebf9988ac000000001b746578743a476f207769746820746865203c423e464c4f3c2f423e

1b (27) is the length of the message.

The full message is:

"text:Go with the FLO"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


Also note that only those transactions that have "Tx version" = 2 have a message at the end.

Quote
Since messages are currently a maximum of 140 characters, the three bytes before the length byte should be 0.

It would be nice for a coin creator to know how his coin works Roll Eyes
The 00000000 at the end will never change... Only 1B describes the size of the comment.

I assumed since I'm writing an a 32 bit value to the serializer it would use 32 bits to encode the value. How would a value of 256 be encoded then?


VarInt... Should be something like fd0100, check on the wiki.
Jump to: