Author Topic: Increase the memo field in the transaction to 64 characters  (Read 6524 times)

0 Members and 1 Guest are viewing this topic.

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
Thinking about how memo could be like NXT Message system. wouldn't that be awesome?

Offline monsterer

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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
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).
« Last Edit: January 16, 2015, 07:49:10 pm by arhag »

Offline theoretical

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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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

Offline bytemaster

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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline monsterer

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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
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?

Offline bytemaster

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline theoretical

In theory we should be moving away from using the memo field all together

What's the replacement?  Mail?
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline theoretical

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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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 :)

Offline monsterer

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
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads