[ANN][FLO] A Worldwide Public Record | Alexandria | ETDB | Medici | 0.15 Segwit - page 120.

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: jackjack on June 22, 2013, 03:09:38 AM

Quote from: skyangel on June 21, 2013, 01:44:48 PM

Quote from: coinerd on June 21, 2013, 01:23:24 PM

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

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

Quote from: skyangel on June 21, 2013, 01:44:48 PM

Quote from: coinerd on June 21, 2013, 01:23:24 PM

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.

frobley

hero member

Activity: 708

Merit: 500

nice work coinerd! Wink

MobGod

hero member

Activity: 532

Merit: 500

Get in the lotto I just pumped it up

coinerd

full member

Activity: 196

Merit: 100

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

coinerd

full member

Activity: 196

Merit: 100

Quote from: metacoin on June 21, 2013, 05:41:01 PM

Sent some coins to coinerd

Thank you as well

Quote from: skyangel on June 21, 2013, 05:41:37 PM

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.

Quote from: skyangel on June 21, 2013, 05:43:21 PM

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.

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 05:40:06 PM

Quote from: skyangel on June 21, 2013, 04:59:23 PM

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

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 05:22:25 PM

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.

metacoin

sr. member

Activity: 437

Merit: 260

balance

Sent some coins to coinerd

coinerd

full member

Activity: 196

Merit: 100

Quote from: skyangel on June 21, 2013, 04:59:23 PM

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

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.

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 05:22:25 PM

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

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

full member

Activity: 196

Merit: 100

Quote from: skyangel on June 21, 2013, 04:59:23 PM

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

F6cSj818K2b1DsQWMDVZDRck6TaiNfxEm7

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 04:23:23 PM

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

full member

Activity: 196

Merit: 100

Quote from: metacoin on June 21, 2013, 04:24:18 PM

Code:

function hex2str($hex) {
    for($i=0;$i    $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

metacoin

sr. member

Activity: 437

Merit: 260

balance

Quote from: coinerd on June 21, 2013, 03:20:03 PM

Quote from: skyangel on June 21, 2013, 03:01:08 PM

The "text:" part is not guaranteed to always be there. It is only there if you send through the GUI. The best would be to parse the whole message like under the "Raw Transaction Detail" part on the web-site, but I don't know how easy it will be.

A quick way might be to do like you suggested and only look for "text:" messages. The length byte will always be before that, so you can validate that you are in the right spot. Since messages are currently a maximum of 140 characters, the three bytes before the length byte should be 0. Also remember that the message could contain anything, so if you display it on a web site there might be HTML in the message. You should "clean up" the message before displaying on a web site.

This is going to be a stab in the dark..

those things you're saying, I know what they mean but i have no idea how to sort out the bytes and etc...

I see already that v2 tx don't always have a text.

preg_split is probably the extent of my brain stretching today

EDIT and maybe some htmlspecialchars heh

Code:

function hex2str($hex) {
    for($i=0;$i    $str=substr($str, strpos($str, 'text:'));
    return $str;
}

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

coinerd

full member

Activity: 196

Merit: 100

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.

Thank you very much skyangel for the tips.

I'll be merging that with some other code and cleaning it up a little later.

There's no database so it's hard to browse for random transactions but if you have a TXid it's fine.

I've never released this code before so if you run into anything odd feel free to drop me a PM thanks.

I'm working with MobGod to get some lottos up at http://lotto.coinworld.us/ since I wanted to check out this messaging FLO is one of the first coins added. It will have a coin and a link on the front page within the next hour or so.

Compared to 6coin and 8coin this is pretty damn innovative on my chart.

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?

MobGod

hero member

Activity: 532

Merit: 500

Get in the lotto lets go guys

http://lotto.coinworld.us/FLO

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 03:20:03 PM

This is going to be a stab in the dark..

Good luck

coinerd

full member

Activity: 196

Merit: 100

Quote from: skyangel on June 21, 2013, 03:01:08 PM

The "text:" part is not guaranteed to always be there. It is only there if you send through the GUI. The best would be to parse the whole message like under the "Raw Transaction Detail" part on the web-site, but I don't know how easy it will be.

A quick way might be to do like you suggested and only look for "text:" messages. The length byte will always be before that, so you can validate that you are in the right spot. Since messages are currently a maximum of 140 characters, the three bytes before the length byte should be 0. Also remember that the message could contain anything, so if you display it on a web site there might be HTML in the message. You should "clean up" the message before displaying on a web site.

This is going to be a stab in the dark..

those things you're saying, I know what they mean but i have no idea how to sort out the bytes and etc...

I see already that v2 tx don't always have a text.

preg_split is probably the extent of my brain stretching today

EDIT and maybe some htmlspecialchars heh

skyangel

sr. member

Activity: 301

Merit: 260

FLO dev

Quote from: coinerd on June 21, 2013, 02:40:52 PM

Quote from: skyangel on June 21, 2013, 01:44:48 PM

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

ok thanks a lot, that should help. It looks like if I send it all through a hex to ascii conversion i get a bunch of gibberish then "Text: and the cleartext message.

Is there a reason I shouldn't just trap for that? It seems to be the end of the hex data each time. Along with the tx version it should make things simple.

The "text:" part is not guaranteed to always be there. It is only there if you send through the GUI. The best would be to parse the whole message like under the "Raw Transaction Detail" part on the web-site, but I don't know how easy it will be.

A quick way might be to do like you suggested and only look for "text:" messages. The length byte will always be before that, so you can validate that you are in the right spot. Since messages are currently a maximum of 140 characters, the three bytes before the length byte should be 0. Also remember that the message could contain anything, so if you display it on a web site there might be HTML in the message. You should "clean up" the message before displaying on a web site.

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