SMS big enough for Bitcoin Payment Instruction?

[FreeTrade]

I think the title asks it all.

Imagine I have a phone with no internet, but with SMS and a Bitcoin wallet. Is SMS big enough to send a payment instruction? Compression allowed. If not, how many SMS messages would it require?

[dogisland]

They vary in size.

Here's one...

Code:

01000000020f7b7fb86d4cf646058e41d3b007183fdf79736ed19b2a7468abc5bd04b16e91000000008c493046022100b2ee39d2fcc2e5544a57c30f7b4e49cfb82222666d034fb90e22348e17e28e0f022100db91c3199cc7b41d4d7afce0ccb4ceb424b9476d51c06142583daf53ce0a9b66014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff97004125528f7b5ed33465caaae021c0b815f3e6a3707641d5a0bca43fc14949010000008a473044022033d02c2e896f1a1252488d534cfb08abf3e7ea90aba7ba6f57abf189cef1d837022005668d755013b0e59a2af5145f10efe62ea716d333268b0b5a3efbd82d1439be014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff0100c2eb0b000000001976a91402bf4b2889c6ada8190c252e70bde1a1909f961788ac00000000

[DeathAndTaxes]

Likely too many. SMS is limited to 140 bytes.  A "standard" Bitcoin transaction is going to be 800 to 900 bytes.  Compression isn't going to help much (if any) as the largest components are the signature and addresses/keys.  Hashes are indistiguishable from random data and thus aren't compressible.

[FreeTrade]

Thanks. I'm seeing 404 bytes compressed as zip file there - but it looks alphanumeric so i guess a custom compression might get something better. Maybe 2 or 3 SMS is the best I could hope for.

Is there a way to ensure the message is short rather than long, or just send the key instead so that the server generates the payment instruction?

[DeathAndTaxes]

Thanks. I'm seeing 404 bytes compressed as zip file there - but it looks alphanumeric so i guess a custom compression might get something better. Maybe 2 or 3 SMS is the best I could hope for.

Is there a way to ensure the message is short rather than long, or just send the key instead so that the server generates the payment instruction?

If send the private key then the "server" now has complete access to your funds so it all depends on how much you trust them.

What may be a better idea (given the need for trust anyways) is an ewallet which gives you the option to pay by SMS.  Then you would simply need the address of the payee, the amount, and some sort of code to authenticate the user.

That could fit in a single SMS message.  So someone gives our a QR code.  You scan it to get the address and message it to your ewallet who processes the instruction for you.  You could even use some public/private key encryption.  Each account has a keypair.  Application on phone has public key.  It encrypts the transaction and includes a plain-text account #.

The server takes the plaintext account number to retreive the private key, decrypts the message and processes the transaction.  Obviously this require some sort of smartphone (dumbphones excluded).

[terrytibbs]

Take a look at "phoneco.in", I'm not sure if they're what you're referring to, and I haven't used them personally, but they've been around for quite some time now and seem pretty legitimate.

http://phoneco.in/

[theymos]

If your transaction has only one input and your change address has already been seen by the network, you could send just the 72-byte signature along with some bytes of the input tx hash and some bytes of the change hash160. The recipient can then construct the full transaction.

If you're able to send private keys, you could use the mini private key format:
https://en.bitcoin.it/wiki/Mini_private_key_format

[Inaba]

I suppose the question that needs to be asked is what is the endpoint of the SMS?  Or to put it another way, where are you sending the SMS?  

At some point, there is going to have to be a computing device involved in the process, even if you are injecting the transaction directly into the block chain as opposed to going through a client.  That being the case, the computing device can handle the additional data that does not necessarily need to be encoded in the SMS.  Unless you are talking about a zero knowledge computing device that is just being used as a dumb conduit into the block chain?

If the latter, then you can concatenate multiple SMS or send an MMS and let the computing device assemble it.

[slush]

Hm, idea of broadcasting transaction over sms doesn't sound so bad.

Code:

01000000020f7b7fb86d4cf646058e41d3b007183fdf79736ed19b2a7468abc5bd04b16e91000000008c493046022100b2ee39d2fcc2e5544a57c30f7b4e49cfb82222666d034fb90e22348e17e28e0f022100db91c3199cc7b41d4d7afce0ccb4ceb424b9476d51c06142583daf53ce0a9b66014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff97004125528f7b5ed33465caaae021c0b815f3e6a3707641d5a0bca43fc14949010000008a473044022033d02c2e896f1a1252488d534cfb08abf3e7ea90aba7ba6f57abf189cef1d837022005668d755013b0e59a2af5145f10efe62ea716d333268b0b5a3efbd82d1439be014104c32215a9093011bd3c41283ace3d002c666077b24a605b3cfc8f71019a0f43df66f389f3d9a62188a494b869dc7e5f9dffc98a76d3088a21e9b738ec9eba98cbffffffff0100c2eb0b000000001976a91402bf4b2889c6ada8190c252e70bde1a1909f961788ac00000000

This is 800 bytes in hexa, but you can compress that message to some proprietary format for sms. Thanks to this (http://www.csoft.co.uk/sms/character_sets/gsm.htm - it was first result on google for "sms character set"), sms charset has 128 single byte characters, so teoretically message above should fit in less than 100 bytes in SMS...

[FreeTrade]

I suppose the question that needs to be asked is what is the endpoint of the SMS?  Or to put it another way, where are you sending the SMS?  

Let's assume a SMS gateway attached to a server that is set up specifically to receive the message and forward it to the network. Ideally the server shouldn't have any need of knowledge of the cellphone or wallet or key. It's merely a gateway to convert the message for the network.

I'm thinking it might be a good backup for a smartphone bitcoin wallet where the internet is not available for some reason.

More exciting though, it can potentially run on a much wider range of cellphones - you could SMS the bitcoin address to a dumb phone, and the phone could send the payment to the gateway also by SMS - not much processing or internet needed.

I'm wondering how do we ensure the message is the bare minimum in size, what's the best compression and encoding. It would be thrilling to get it into a single SMS. But I guess 2 wouldn't be too bad.

[casascius]

I could see it fitting into one SMS messages (140 total 8-bit bytes) if the public key for the input txid could already be located on the block chain.


I think it might be able to work with some manipulation... the only thing needed would be:

1. Input txid 32 bytes (though could be uniquely identified from the block chain with as few as four bytes)
2. Destination bitcoin address... 20 bytes... total 24 to 52 bytes... (if firstbits are on block chain, this could be four bytes as well)
3. Amount... let's call this 4 bytes (total 28 to 56 bytes)
4. r and s values from the digital signature unlocking the funds... 64 bytes... total 92 to 120 bytes.
5. Change address (20 bytes) (total 112 to 140 bytes) (change address may be unnecessary or could be assumed to be the sending address)

The single SMS doesn't have enough room to carry the public key if it is needed.

The public key for a Bitcoin address can be found on the block chain if funds have ever been spent from that address at any point in the past, regardless of amount.  If the public key can be derived from the block chain, there is no need for a second SMS to provide it.  Otherwise, that's another 64-byte payload.

There may be an algorithm to compress the public key into a smaller package.  I hear one exists and that it's patented.  In any case, if the public key could be represented in 48 bytes or fewer, and a change address isn't needed, nor a full txid, the entire thing should fit into a single SMS.

[deslok]

if you're willing to fo the work to encode and then decode it in some propriatary maner lots of things will fit in a SMS, however MMS may be more practical

[btc_artist]

Likely too many. SMS is limited to 140 bytes.  A "standard" Bitcoin transaction is going to be 800 to 900 bytes.  Compression isn't going to help much (if any) as the largest components are the signature and addresses/keys.  Hashes are indistiguishable from random data and thus aren't compressible.

The raw transaction can be compressed.  For example, the transaction posted above is 808 bytes. If I gzcompress it, then base 64 encode (so it can be represented as printable ASCII chars), I can get it down to 488 bytes.

[FreeTrade]

The raw transaction can be compressed.  For example, the transaction posted above is 808 bytes. If I gzcompress it, then base 64 encode (so it can be represented as printable ASCII chars), I can get it down to 488 bytes.

Also I guess a Tweet -> Bitcoin gateway would allow anything that has access to the twitter network to broadcast transactions too.

[casascius]

Likely too many. SMS is limited to 140 bytes.  A "standard" Bitcoin transaction is going to be 800 to 900 bytes.  Compression isn't going to help much (if any) as the largest components are the signature and addresses/keys.  Hashes are indistiguishable from random data and thus aren't compressible.

The raw transaction can be compressed.  For example, the transaction posted above is 808 bytes. If I gzcompress it, then base 64 encode (so it can be represented as printable ASCII chars), I can get it down to 488 bytes.

The raw transaction above is 404 bytes.  Two hex digits make a byte.  All of the compression "gain" you are observing is merely a result of compressing out the additional space taken up by converting the binary to text.  Try compressing the 404 bytes.

[btc_artist]

Likely too many. SMS is limited to 140 bytes.  A "standard" Bitcoin transaction is going to be 800 to 900 bytes.  Compression isn't going to help much (if any) as the largest components are the signature and addresses/keys.  Hashes are indistiguishable from random data and thus aren't compressible.

The raw transaction can be compressed.  For example, the transaction posted above is 808 bytes. If I gzcompress it, then base 64 encode (so it can be represented as printable ASCII chars), I can get it down to 488 bytes.

The raw transaction above is 404 bytes.  Two hex digits make a byte.  All of the compression "gain" you are observing is merely a result of compressing out the additional space taken up by converting the binary to text.  Try compressing the 404 bytes.

Oops, I'll have to try again.

Edit:  gzipping and base 64 encoding the original binary transaction (404 bytes) yields 460 ASCII chars.  That probably about as good as it's going to get without modifying what information needs to be sent.