BitShares Forum

Main => Stakeholder Proposals => Topic started by: monsterer on January 15, 2015, 09:07:15 am

Title: Increase the memo field in the transaction to 64 characters
Post by: monsterer on January 15, 2015, 09:07:15 am
That way a memo can reference a bitcoin address, or bitcoin TXID as well as bitshares trxid and account name.

The current length cant even accommodate a bitcoin address.

use case: gateways - having the user put their desired bitcoin address into the memo field of a bitshares transaction removes the need to import private keys into the bitshares wallet, which is fragile and only works once due to change addresses.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: liondani on January 15, 2015, 09:22:29 am
That way a memo can reference a bitcoin address, or bitcoin TXID as well as bitshares trxid and account name.

The current length cant even accommodate a bitcoin address.
+5

Sent from my ALCATEL ONE TOUCH 997D

Title: Re: Increase the memo field in the transaction to 64 characters
Post by: Markus on January 15, 2015, 10:04:13 am
Good idea.
Maybe charge an extra high transaction fee for long memos to avoid bloat?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: monsterer on January 15, 2015, 10:35:53 am
Good idea.
Maybe charge an extra high transaction fee for long memos to avoid bloat?

Yeah, maybe transaction fee could be per kb?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: cass on January 15, 2015, 12:29:15 pm
IMO good idea
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: xeroc on January 15, 2015, 12:35:01 pm
according to
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/include/bts/blockchain/config.hpp#L39

The memo limit is currently 19bytes .. for a ripemd160 hash of a public key you need 160bit which is 20 byte ..
so actually we are very close to what is required .. increasing the limit to 20bytes would be enough ..

not sure what the argumentation has been to set it at 19bytes in the first place
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: svk on January 15, 2015, 01:14:35 pm
according to
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/include/bts/blockchain/config.hpp#L39

The memo limit is currently 19bytes .. for a ripemd160 hash of a public key you need 160bit which is 20 byte ..
so actually we are very close to what is required .. increasing the limit to 20bytes would be enough ..

not sure what the argumentation has been to set it at 19bytes in the first place
I think they lowered it for v0.4.27 actually, I know at one point I could no longer use the same memo I had used before.  It even caused those transactions that had the earlier, longer memos to disappear from my transaction history.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: bytemaster on January 15, 2015, 01:15:29 pm
It was either 19 or 35 due to aes encryption chunk size. 
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: xeroc on January 15, 2015, 01:45:53 pm
It was either 19 or 35 due to aes encryption chunk size.
so what's the argument against increasing the memo size to 35 bytes again?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: monsterer on January 15, 2015, 06:26:45 pm
according to
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/include/bts/blockchain/config.hpp#L39

The memo limit is currently 19bytes .. for a ripemd160 hash of a public key you need 160bit which is 20 byte ..
so actually we are very close to what is required .. increasing the limit to 20bytes would be enough ..

not sure what the argumentation has been to set it at 19bytes in the first place

Remembers its the base58 version of the address in the memo, so will take 34 bytes not including EOL
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: xeroc on January 15, 2015, 07:13:33 pm
according to
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/include/bts/blockchain/config.hpp#L39

The memo limit is currently 19bytes .. for a ripemd160 hash of a public key you need 160bit which is 20 byte ..
so actually we are very close to what is required .. increasing the limit to 20bytes would be enough ..

not sure what the argumentation has been to set it at 19bytes in the first place

Remembers its the base58 version of the address in the memo, so will take 34 bytes not including EOL
no one forces you to base58 encode the address ... you could also go binary
 .. also no one forces you add the checksum (4 bytes) as those should be checked before anyway ..

afaik the memo could be binary .. may look crappy .. but could :)
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: theoretical on January 15, 2015, 07:19:00 pm
Could we have an "extended memo" op that replaces the memo with text of arbitrary length?

We should have separate fields for encrypted ("public memo") and unencrypted ("private memo") contents, each of which can be arbitrary length (of course max tx size sets an effective limit).  The client should automatically add a 64-bit nonce to the encrypted memo (and strip it on the receiving side).  The nonce is to boost the entropy, e.g. if you're sending a bitcoin address in the memo field, without the nonce an attacker could find out the memo contents by simply encrypting all Bitcoin addresses in existence with the recipient's public key.

If the blockchain was frozen, I'd suggest re-purposing the burn op for this, but since we obviously have hardforks planned, it makes sense to just make a new op.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: bytemaster on January 15, 2015, 07:33:59 pm
https://github.com/BitShares/bitshares/issues/1258

I'll add the ability to have an extra 32 bytes for a total of 51 bytes.   That should be plenty to contain a bitcoin address.  In theory we should be moving away from using the memo field all together, but it does not require a hard fork to support 51 bytes, just wallet support.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: theoretical on January 15, 2015, 08:11:47 pm
In theory we should be moving away from using the memo field all together

What's the replacement?  Mail?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: bytemaster on January 15, 2015, 08:13:45 pm
In theory we should be moving away from using the memo field all together

What's the replacement?  Mail?

Yes
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: Rune on January 15, 2015, 08:26:36 pm
Wish we can get this as soon as possible. I've been messing around with GATEBTC all day and importing private keys from the bitshares wallet to a bitcoin wallet is not user friendly. We just need something similar on the bitcoin end too... I guess the best option is the public message that blockchain.info can do, does other wallets have that capability too?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: monsterer on January 16, 2015, 01:05:38 pm
Wish we can get this as soon as possible. I've been messing around with GATEBTC all day and importing private keys from the bitshares wallet to a bitcoin wallet is not user friendly. We just need something similar on the bitcoin end too... I guess the best option is the public message that blockchain.info can do, does other wallets have that capability too?

Bitcoin transactions do not support message data, so I'm not sure how their public message facility works, do you have a link?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: bytemaster on January 16, 2015, 02:49:57 pm
It could easily be done with bitcoin send to many.  Have users add a second output that is their own btc/bts address with a very small amount.    Most wallets support send to many without much work.  If the amount is small enough they can probably just forget about it and never import their bts key. 
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: xeroc on January 16, 2015, 02:54:47 pm
It could easily be done with bitcoin send to many.  Have users add a second output that is their own btc/bts address with a very small amount.    Most wallets support send to many without much work.  If the amount is small enough they can probably just forget about it and never import their bts key.
Needs to know the amount of satoshi that are considered dust .. besides that its a good idea .. afaik satoshi dice has such a feature too for payouts
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: theoretical on January 16, 2015, 07:28:14 pm
We just need something similar on the bitcoin end too...

Why don't you just hold the GATEBTC until you get a signed message telling you where to send it?

The default Bitcoin client can sign a message with private key corresponding to its address.  So you could just have the person send you a signed message from the Bitcoin client saying "send GATEBTC from <bitcoin_txid> to <account>, sincerely, <signer>".  Then check:

- <bitcoin_txid> represents a transaction that exists
- And is sufficiently confirmed
- And is sending BTC to your ingress address
- And has not yet had its GATEBTC claimed
- And has at least one input controlled by <signer>

Then you issue GATEBTC (or whatever your gateway's BTC IOU UIA is) to the corresponding address.

The message could be published somewhere on the blockchain, but it's easier (and doesn't require them to pay a fee) if you just have an HTTP(S) interface on your webserver to submit the message.

You could also have semantics to remember the association between a BTC address and account, i.e. the message could instead be:

"if your ingress address gets any BTC from <my_address>, please send the GATEBTC to <titan_account>, sincerely, <signer>"

Then you just check that <signer> controls <my_address>.  The user can then send you BTC in any number of transactions, past or future.  As long as the user has at least one tx input from <my_address>, it will all go to the right place.  If the user forgets and you get BTC from unknown addresses, you can just hang onto it until one of the addresses files a signed message claiming the new GATEBTC.  Of course, with the way Bitcoin makes a new change address by default and de-prioritizes recent balances, it may be a little extra work to make sure <my_address> always has a balance that is included.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: arhag on January 16, 2015, 07:43:27 pm
We just need something similar on the bitcoin end too...

Why don't you just hold the GATEBTC until you get a signed message telling you where to send it?

The default Bitcoin client can sign a message with private key corresponding to its address.  So you could just have the person send you a signed message from the Bitcoin client saying "send GATEBTC from <bitcoin_txid> to <account>, sincerely, <signer>".  Then check:

- <bitcoin_txid> represents a transaction that exists
- And is sufficiently confirmed
- And is sending BTC to your ingress address
- And has not yet had its GATEBTC claimed
- And has at least one input controlled by <signer>

Then you issue GATEBTC (or whatever your gateway's BTC IOU UIA is) to the corresponding address.

The message could be published somewhere on the blockchain, but it's easier (and doesn't require them to pay a fee) if you just have an HTTP(S) interface on your webserver to submit the message.

You could also have semantics to remember the association between a BTC address and account, i.e. the message could instead be:

"if your ingress address gets any BTC from <my_address>, please send the GATEBTC to <titan_account>, sincerely, <signer>"

Then you just check that <signer> controls <my_address>.  The user can then send you BTC in any number of transactions, past or future.  As long as the user has at least one tx input from <my_address>, it will all go to the right place.  If the user forgets and you get BTC from unknown addresses, you can just hang onto it until one of the addresses files a signed message claiming the new GATEBTC.  Of course, with the way Bitcoin makes a new change address by default and de-prioritizes recent balances, it may be a little extra work to make sure <my_address> always has a balance that is included.

I like this approach. We could even have a standard that we include in the public JSON of a BTS account. A standard JSON key and associated value optionally linking your BTS account to a particular BTC public key which is verified by including in the value the BTC public key and a signature of the standard message that includes the BTC public key and BTS account name.

The client would have an interface where you can paste in a BTC public key under your BTS account, it would spit out a message for you to sign in your Bitcoin client, you would get the signature and paste that back into the BTS client and then press submit and it would update your public account data with the necessary information linking your BTS account to that BTC public key. Then sending BTC from that address to the gateway address makes the GATEBTC arrive at your BTS account automatically.

It also means that the gateway on the BitShares end can automatically know which address to send the BTC to when you send GATEBTC to the gateway account. Whether it is TITAN (checks the from field and uses that to look up linked BTC public key from your account JSON) or not (I'm assuming if it's not TITAN then you should be sending GATEBTC to the gateway account directly from a balance owned by the account's active key).
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: bytemaster on January 16, 2015, 07:47:16 pm
I much prefer gateway solutions that don't depend upon centralized servers with public HTTPS addresses.   Those centralized servers then become vulnerable to hack/attack.

Far better to have the gateway secretly operate as an anonymous node on both networks.
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: monsterer on January 16, 2015, 10:54:48 pm
We just need something similar on the bitcoin end too...

Why don't you just hold the GATEBTC until you get a signed message telling you where to send it?

The default Bitcoin client can sign a message with private key corresponding to its address.  So you could just have the person send you a signed message from the Bitcoin client saying "send GATEBTC from <bitcoin_txid> to <account>, sincerely, <signer>".  Then check:
[/quote]

Because I don't think this is an atomic operation, is it?
Title: Re: Increase the memo field in the transaction to 64 characters
Post by: fav on February 26, 2015, 12:15:01 pm
Thinking about how memo could be like NXT Message system. wouldn't that be awesome?