Increase the memo field in the transaction to 64 characters

[fav]

Thinking about how memo could be like NXT Message system. wouldn't that be awesome?

[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?

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

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

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

[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

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

[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?

[Rune]

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?

[bytemaster]

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

What's the replacement?  Mail?

Yes

[theoretical]

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

What's the replacement?  Mail?

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

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

[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 :)

[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