[ANN][FLO] A Worldwide Public Record | Alexandria | ETDB | Medici | 0.15 Segwit

[coinerd]

Code:

function hex2str($hex) {
    for($i=0;$i<strlen($hex);$i+=2) $str .= chr(hexdec(substr($hex,$i,2)));
    $str=substr($str, strpos($str, 'text:'));
    return $str;
}

Also, I sent you a PM. Please respond when you can

That's almost exactly what I used to make the conversion.  Most of the data just coimes out as gibberish it's not useful ASCII values.

that and a preg_split will catch the messages, so far.

If anyone can see it not working please let me know

[1714153212]

1714153212

[1714153212]

1714153212

[1714153212]

1714153212

[1714153212]

1714153212

[skyangel]

http://lotto.coinworld.us/FLO/bc/index.php

ok you can find your messages there for now, I was able to find a few messages and it seems to work.

...

It would be nice to have the old bitcoin message (comment) stubs either removed, or activated for this feature.  Did you save time by implementing it in parallel or do you have other ideas for expansion?

Very nice! Exciting to see this. I'll update the first post with a link.

The version 1 transactions was kept for compatibility sake. Most of the version 1 transactions in the block chain was generated by mining software/pools other than the wallet.

The client generates version 2 transactions. I don't plan on changing the format of version 2 packets. I added the "text:" part in the beginning of the comment so that people could adopt the convention for their own kind of transaction comments, for example "encrypted:HGKJHGYXBgjh5j" or "url:http://example.com" or "reference:12345" or whatever they choose.

[coinerd]

Very nice! Exciting to see this. I'll update the first post with a link.

The version 1 transactions was kept for compatibility sake. I don't plan on changing the format of version 2 transactions. I added the "text:" part in the beginning of the comment so that people could adopt the convention for their own kind of transaction comments, for example "encrypted:HGKJHGYXBgjh5j" or "url:http://example.com" or "reference:12345" or whatever they choose.

For now it's a good add because it allows this sort of easy trapping of the message for folks that aren't comfortable fliflopping between bases and encodings.

The more people can work with it the more people will be attracted to it, for sure.  An update that returned it as a parameter of the RPC-JSON transaction data would make adoption easy. At the moment it's a bit of a (realtively easy) trick.

1. grab TX hex
2. Convert to ASCII using common tutorial funciton or native language function
3. use regex to split the ASCII translation of the hex at "text:"
4. second half of the split is the text message. (if one exists)

A check for transaction version may improve overall software efficiency but isn't necessary as a v2 transaciton may not have a message anyways.

Sound reliable enough, with your knowledge of how it actually works? 

Are there cases where it will catch "garbage" after the message in the hex? 

If it's always the end the length bytes only matter when you're already making sense of the rest of the hex. If you don't parse the actual hex into transaction data locally (and very few will) they're essentially at a random location it seems to me.

Also not to seem awful but I'm totally up for bounties and tips

F6cSj818K2b1DsQWMDVZDRck6TaiNfxEm7

[skyangel]

Are there cases where it will catch "garbage" after the message in the hex? 

If it's always the end the length bytes only matter when you're already making sense of the rest of the hex. If you don't parse the actual hex into transaction data locally (and very few will) they're essentially at a random location it seems to me.

Also not to seem awful but I'm totally up for bounties and tips

F6cSj818K2b1DsQWMDVZDRck6TaiNfxEm7

It will always be at the end of the message with version 2 transactions.

Of course it would be safer to parse this field like all the other fields are parsed (checking length, etc), but I think it should be fine as you have it now.

Sent you a donation, thanks

[coinerd]

.... I added the "text:" part in the beginning of the comment so that people could adopt the convention for their own kind of transaction comments, for example "encrypted:HGKJHGYXBgjh5j" or "url:http://example.com" or "reference:12345" or whatever they choose...

Wait, that's just sinking in.  If I was to add a comment to a console or RPC transaction, would it be preceded by the "text:" string or is the QT gui doing that?

is there currently a way to send a message without including the "text:" in the transaction data?

Uh oh

I'm not sure I'm ready to build an actual transaction parser for raw hex transactions in php. Until now the JSON return has been sufficient for what I've done.

And thank you for the donation as well.

[metacoin]

Sent some coins to coinerd

[skyangel]

The more people can work with it the more people will be attracted to it, for sure.  An update that returned it as a parameter of the RPC-JSON transaction data would make adoption easy.

The listtransactions RPC call returns the comment in the "tx-comment" field.

Also the send RPC calls also support an optional "tx-comment" parameter.

[skyangel]

.... I added the "text:" part in the beginning of the comment so that people could adopt the convention for their own kind of transaction comments, for example "encrypted:HGKJHGYXBgjh5j" or "url:http://example.com" or "reference:12345" or whatever they choose...

Wait, that's just sinking in.  If I was to add a comment to a console or RPC transaction, would it be preceded by the "text:" string or is the QT gui doing that?

is there currently a way to send a message without including the "text:" in the transaction data?

Yes, the GUI adds the "text" part in front. If you send using RPC calls, nothing is prefixed, you must add your own prefix.

[coinerd]

Sent some coins to coinerd

Thank you as well

The listtransactions RPC call returns the comment in the "tx-comment" field.

Also the send RPC calls also support an optional "tx-comment" parameter.

Ok, that's great for your own incoming stuff.

Yes, the GUI adds the "text" part in front. If you send using RPC calls, nothing is prefixed, you must add your own prefix.

So, for this to 'really' work in some sort of web service, a raw TX parser is required, then?

Ahhh, bitcoin.it just never seems very inviting, heh.

[coinerd]

We had the first public drawing the numbers are here:

http://lotto.coinworld.us/FLO/history.php?draw=2

If you entered please make sure you received your winnings, it's a new lottery after all

Thanks to all the players

[MobGod]

Get in the lotto I just pumped it up

[frobley]

nice work coinerd! 

[jackjack]

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 <B>FLO</B>"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


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

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
The 00000000 at the end will never change... Only 1B describes the size of the comment.

[skyangel]

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 <B>FLO</B>"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


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

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
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. If this is not the case, how would a value of 256 be encoded?

[jackjack]

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 <B>FLO</B>"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


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

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
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.

[skyangel]

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 <B>FLO</B>"

In hex:

746578743a476f207769746820746865203c423e464c4f3c2f423e


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

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
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

[coinerd]

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

[Petr1fied]

I'd use something like this to get the text in php:

Code:

<?php

$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.

[jackjack]

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

[Petr1fied]

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.