Provide user an easy way to transfer BTC (between their wallet addresses) for Masterprotocol transactions that don't have btc

[marv-engine]

E.g. if a user wants to send another currency but doesn't have any BTC, we should make it as easy as possible for the user to send some BTC to that address, so the only inconvenience is having to wait for the BTC send to be confirmed.

[ripper234]

Can we handle this by chaining transactions?

Suppose I have BTC at address X, and only MSC at address Y (but no BTC there).

Can't I prepare two transactions, one that sends some BTC from X to Y, and another that send MSC+BTC from Y to the target, and then broadcast both these transactions in the same block?

There shouldn't be any time spent waiting for the first tx to be confirmed.

[genecyber]

Do we have to chain? Can we just have the address with the btc be the payee of the tx? So multiple pay inputs (I'm not sure if bitcoin even allows this)

On Mon, Jun 23, 2014 at 9:26 AM, Ron Gross notifications@github.com
wrote:

Can we handle this by chaining transactions?
Suppose I have BTC at address X, and only MSC at address Y (but no BTC there).
Can't I prepare two transactions, one that sends some BTC from X to Y, and another that send MSC+BTC from Y to the target, and then broadcast both these transactions in the same block?

There shouldn't be any time spent waiting for the first tx to be confirmed.

Reply to this email directly or view it on GitHub:
#581 (comment)

[genecyber]

If we can make this transparent enough we could use "free x number of transactions for free for new users of omni"

On Mon, Jun 23, 2014 at 9:26 AM, Ron Gross notifications@github.com
wrote:

Can we handle this by chaining transactions?
Suppose I have BTC at address X, and only MSC at address Y (but no BTC there).
Can't I prepare two transactions, one that sends some BTC from X to Y, and another that send MSC+BTC from Y to the target, and then broadcast both these transactions in the same block?

There shouldn't be any time spent waiting for the first tx to be confirmed.

Reply to this email directly or view it on GitHub:
#581 (comment)

[ripper234]

@genecyber I don't understand the last comment about the free tx.
However regarding the first comment, @petertodd may be able to advise here.

Peter - is it even possible to have a tx with an input that doesn't have any BTC on it?

[petertodd]

As I mentioned in my "should Mastercoin move to a tx output model" reply, you can spend a zero-valued output bizarrely enough, although doing that is non-standard and may not be possible in the future. (banning zero-value outputs puts an upper limit on the UTXO set size, a theoretically nice thing)

However that doesn't actually solve your problem, as you still need to create that zero-valued output in the first place. Might as well just create one with some dust on it to make is an IsStandard() transaction.

Secondly re: confirmations, the Mastercoin protocol transaction can't confirm until the dust-creation transaction confirms, so there's no need to wait for anything to confirm beyond of course the Mastercoin transaction.

[ripper234]

Right... I'm used to thinking in terms of balances, not outputs.
An output is 'destroyed' when it is used/spent, so usually/always you won't have any outputs on an address.

So yeah, we can just use some dust, but indeed without waiting for an extra confirmation.

[petertodd]

Oh, and there's a bigger issue here too: If the user doesn't have any BTC, how did they pay the tx fee?

[genecyber]

Never mind, I was thinking omni could have an address with funds that we could use to transparently fund transactions for new users (in a new users get no tx fees scenario) but signing in the background would require code changes that are out of scope.

Sent from my iPhone

On Jun 23, 2014, at 9:38 AM, Ron Gross notifications@github.com wrote:

@genecyber I don't understand the last comment about the free tx.
However regarding the first comment, @petertodd may be able to advise here.

Peter - is it even possible to have a tx with an input that doesn't have any BTC on it?

—
Reply to this email directly or view it on GitHub.

[ripper234]

I don't think we should fund new users, but rather make sure to alert users if their BTC gets too low.

[petertodd]

@ripper234 Agreed. It'd almost certainly get abused.

Also remember that when time comes to fund the user's MSC wallet there's really nothing wrong with immediately spending that unconfirmed output. Just make sure you've handling malleability correctly and do something sane if it does get mutated. (IE, resign the txs with the correct txids)

[petertodd]

BTW, did anyone see my reply to OmniLayer/spec#189? IE get an email notification? I just looked and it seems to be missing... wondering if I did something stupid. :(

[ripper234]

Nope, I don't see your response neither on github nor in my inbox.

[petertodd]

@ripper234 Gah, I'm probably an idiot then. I'll re-write it and re-post.