7

I would like to basically Make SMS payments of Ether (or bitcoin). The basic Idea I'm thinking about is:

1) Private key signs a transaction on a mobile phone.

2) Raw transaction is 'compressed' somehow into 140 characters.

2) Compressed raw transaction is sent to some phone number where our servers give it to the network, and possible text the recipient that it went through.

Is it possible to get this down to 140 character?

axic
  • 2,569
  • 12
  • 20
ZMitton
  • 2,750
  • 4
  • 19
  • 34

1 Answers1

5

SMS supports multi-part messages. Is that not reliable in the countries you are targeting?

Assuming you are bound to the plain old SMS protocol, let's see what can be done.

This is a simple send value transaction: 0xf8660185042817c80082420894e0defb92145fef3c3a945637705fafd3aa74a241822710001ba0909bb38d67799654ea53d3c05b839aa5f12f1f9e96205125d30a326a74eedd95a0634ee974baa4930dd4a943e392dcd526186531e20fb116ead9c0c10c520e3703

This is 104 bytes or 208 bytes as a hex ASCII string.

It all depends on the character encoding supported by the SMS protocol, I remember it was a weird character set, but it is definitely not 8-bit safe.

This means you'll need to find an encoding which fits into the character set supported by SMS as well as reduce the above by from hex string format by 25%.

You could also apply compression, but that is unlikely to be very successful on this data set.

Can I remove fields?

If you assume the only transaction supported is normal value transfer between two external accounts, then you can remove gasLimit, gasPrice and data from the transaction.

Essentially you could do the following:

  • Create the transaction as normal
  • Sign it as normal
  • Send only the following fields:
    • recipient address
    • value to be transferred
    • signature (r, s and v components)
  • Rebuild the transaction on the host side and check the signature
  • If it matches you're ready to go

Remark: One problem I see is the nonce needs to be communicated with sender.

Edit: the actual size of the transaction depends on the values included. Some of them have constant or predictable size (recipient, the signature, gas limit), but the value, gas price and data can vary widely.

This is a transaction for sending 1 ETH (which equals to 1000000000000000000 Wei, 0x0de0b6b3a7640000 in hex, a total of 8 bytes). This amounts to 110 bytes total:

0xf86c018504a817c80082520894e0defb92145fef3c3a945637705fafd3aa74a241880de0b6b3a7640000001ba075862cd4397d54b2804118984b1ba7a09ca7c4f58253f4c73523c241a74a13a3a07226191881ced6311bce1f03dda40ae7294edb3e973a1525686d9b4911f3fc0a

Additionally to the remark about the nonce, the gas price should also be periodically communicated with the sender. Even though it is supposed to be dynamic and miners are free to decide what to accept, currently you could get away with fixing it. This will change in the future.

axic
  • 2,569
  • 12
  • 20
  • I don't know much about the nonce. So I would get that from the blockchain and give to the sender? Sender needs this during signing, correct? – ZMitton Mar 17 '16 at 23:28
  • The sender is the one who sets the nonce. They would then have to tell you what nonce it is, or you can check the blockchain to see what nonce that account is on. – Tjaden Hess Mar 17 '16 at 23:56
  • Then how come @axic said ' the nonce needs to be communicated with sender' then? – ZMitton Mar 18 '16 at 00:08
  • 2
    The nonce is the sequence number of an account. It basically equals to the number of transactions (as it counts from zero). It is part of the transaction and the phone needs to receive it before sending any transaction. There cannot be any gaps in it either. See a few other comments here: http://ethereum.stackexchange.com/questions/1172/how-does-the-ethereum-eth-accounting-system-work-and-prevent-double-spends – axic Mar 18 '16 at 00:22
  • 2
    If you convert the transaction hex into base 64, then 104 bytes becomes 139 characters. That said, the data in your transaction there looks like it's a few bytes short of what you would normally see - I get 106 bytes for mine. Hence, I'd recommend a custom base 94 encoding based on all ASCII values from 33 to 126 to be safe - that lets you cover up to 114 bytes so you can even call zero-argument functions of contracts if you need to. – Vitalik Buterin Mar 18 '16 at 22:07
  • Good catch, that one used a very small transaction value (and a wrong gas price). Updated with a more realistic one. – axic Mar 19 '16 at 11:25