Add send-to-many transaction

zathras-crypto commented 8 years ago

The request is in to add the capability to send tokens to multiple recipients in a single transaction.

The following provides an initial draft of a new transaction type - Send To Many - that would serve this purpose.

Field	Type	Example
Transaction version	[Transaction version]	0
Transaction type	[Transaction type]	5
Number of sends	[Integer-one byte]	4

Followed by an array of the sends (expected array size is defined by number of sends field):

Field	Type	Example
Property identifier	[Property identifier]	1 (Omni)
Amount to transfer	[Number of Coins]	100,000,000 (1.0 coins)
Recipient vOut	[Intger-one byte]	3

From a sizing perspective we'd be looking at 4 bytes + 13 for each subsend. Thus with a class C 80 byte OP_RETURN restriction we'd be looking at up to 5 sends in a Send To Many before we have to fall back to class B.

Note if we decided that we did not want to support multiple properties in a Send To Many (ie all recipients receive varying amounts of the same property) we don't need to repeatedly encode the property ID and thus would be looking at up to 8 recipients in a Send To Many before we fall back to class B. This however introduces a restriction I'm not sure we want to apply.

Since we don't have the concept of partial validity (ie whereby part of a transaction can be valid but another part is invalid) I propose that the following will invalidate the transaction and thus all of the sub-sends.

Array size not as per number of sends (will cause a parsing error)
Recipient vout for any of the sub-sends is higher than the number of outputs
Recipient vout for any of the sub-sends is a non-supported output type
Sender has insufficient tokens for any of the sends

This is just an initial draft and is of course open to changes based on your feedback guys.

Thanks Z

dexX7 commented 8 years ago

Just to throw it in the room: we could also do multi-sends with multi-payloads in one transaction.

zathras-crypto commented 8 years ago

Just to throw it in the room: we could also do multi-sends with multi-payloads in one transaction.

Understood and agreed. I think the question is one of scope, and I thought a new transaction would be easier (more isolated) than doing multiple payloads.

My own vision of multiple payloads is atomic actions within each transaction, each with their own validity - not sure if that makes sense so for example:

{
  "txid": "1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
  "fee": "0.00011472",
  "sendingaddress": "1BitcoinAddress",
  "ismine": false,
  "blockhash": "00000000000000000419a97081424cc3db3cbedbb3147bc9c7ff6a2cda53f799",
  "blocktime": 1462186249,
  "block": 409864,
  "confirmations" : 8,
  "actions" : [
    {
      "actionreference" : 357943,
      "version": 0,
      "typeint": 0,
      "type": "Simple Send",
      "propertyid": 3,
      "divisible": false,
      "amount": "43012",
      "referencevout" : 2,
      "referenceaddress": "1SomeBitcoinAddress"
      "valid": true,
    },
    {
      "actionreference" : 357944,
      "version": 0,
      "typeint": 0,
      "type": "Simple Send",
      "propertyid": 1,
      "divisible": true,
      "amount": "100000",
      "referencevout" : 3,
      "referenceaddress": "1SomeOtherBitcoinAddress"
      "valid": true,
    },
    {
      "actionreference" : 357945,
      "version" : 0,
      "type_int" : 25,
      "type" : "MetaDEx trade",
      "propertyidforsale" : 31,
      "propertyidforsaleisdivisible" : true,
      "amountforsale" : "5.00000000",
      "propertyiddesired" : 1,
      "propertyiddesiredisdivisible" : true,
      "amountdesired" : "5.00000000",
      "unitprice" : "1.00000000000000000000000000000000000000000000000000",
      "valid": false,
    },
  ],
}

Does that fit in with the kind of thing you have in mind for multi payload?

I figured this would be a fair chunk more work and be quite invasive - but what concerns me most is integrators - I worry that if we break the "one-to-one" relationship between transactions and Omni messages that this would require extra development on their end.

The other concern I had was class B fallback - simple sends are fairly small messages so we can fit in 5 of them in our available 80 bytes. However we could only fit 2 trade payloads before falling back to class B. Essentially, we'd be using class B more with multi payload support.

TL:DR; I thought multi payloads would be more complex and require a bigger scope of changes than a new transaction :)

What are your thoughts dude? I haven't started writing code, it's still feasible to change approach to multi-payloads instead if we wanted to 'aim high' so to speak.

dexX7 commented 8 years ago

Does that fit in with the kind of thing you have in mind for multi payload?

Yes.

I figured this would be a fair chunk more work and be quite invasive - ...

Agreed. It's likely much more complex.

What are your thoughts dude?

It can also be done with seperate simple sends, so the benefit of multi-sends seems to come down to a size/cost optimization.

I'd prefer multi-payloads, but the use-case and consumer for multi-sends isn't clear to me. If there are integrators waiting for it, which would really benefit I could see the value of adding it now.

patrickdugan commented 8 years ago

The value add for multi-sends is so we an compensate having a DAC-like algorithm providing BTC miner fees as inputs to transactions on demand and have the thing being sent or traded, such as USDT, being accepted as compensation for the BTC value, so that's economically sustainable and we don't have to strictly require BTC for people it can be made a behind-the-scenes service. So the fastest path that is best.

zathras-crypto commented 8 years ago

@patrickdugan I'm not sure I follow mate "BTC miner fees as inputs to transactions" and "USDT being accepted as compensation for the BTC value" etc - the send many transaction I'm proposing here is quite simplistic in that it allows to send multiple Omni based tokens to multiple addresses in a single transaction - it doesn't relate to BTC at all just FYI.

The debate is essentially one of two options: 1) Do we add send-to-many now as a new transaction type (less work, only allows multiple sends) 2) Do we wait and implement support for multiple payloads (more work, allows multi-anything (eg multiple sends/trades/grants/property creations etc)

zathras-crypto commented 8 years ago

Sorry I forgot about this issue guys and started prototyping!

My current approach for sendmany in a nutshell is:

[version][type] [propertyid][numberofsends] [address1:5,address2:10,address3:15]

I've tried to optimize for minimal transaction size, and one of those compromises was making the transaction single-property as I figure that'll be most use cases, and in those cases we don't want to encode the same property 10 times for example if we're sending to 10 addresses.

I went with a new transaction instead of multi-payloads because:

1) The code changes are more self-contained as a new transaction type 2) It's a much smaller scope of work 3) It's much more scalable

Number 3 may require some explanation. I figured:

multi-payload (each payload referencing a vout for recipient if needed) would cost perhaps 50 bytes per recipient (34 bytes for a p2pkh output and 16 bytes for simple send payload)
send-many transaction would cost 29 bytes per recipient (1 byte for address version, 20 for hash160, 8 for amount)

Given the purpose is to facilitate multiple sends in a single transaction, I figured it should do this as efficiently as possible (with regard to transaction size).

Happy to hear feedback :)

jinglics commented 7 years ago

Currently, each btc transaction can only carry one omni tx now? Am I correct?

dexX7 commented 7 years ago

@jinglics: Currently, each btc transaction can only carry one omni tx now? Am I correct?

This is correct.

phuongnd08 commented 6 years ago

USDT is being heavily used by exchanges. Allowing multiple omni txes per btc transaction will make handling deposit and withdrawal much less problematic.

Also I would vote for the multiple-payloads solution as it sounds intuitively simpler to me.

nbphuoc commented 6 years ago

+1

sto0pkid commented 6 years ago

Hello, is it possible to make a single omni tx in a btc tx that has multiple regular btc tx outputs, or can there be only one tx output in the btc tx for omni clients to recognize it as valid?

dexX7 commented 6 years ago

Hi @sto0pkid, the last output (which isn't from the sender) is used to determine the recipient of a transaction, but there can be others. E.g., the following transaction is fine and valid:

- txin 0: input from sender
- txin 1: some other input
- txin 2: some other input

- txout 0: payload
- txout 1: some output
- txout 2: some output
- txout 3: recipient output
- txout 4: change output to the sender`

cedricfung commented 6 years ago

Hi @dexX7, in your example, does the txin 1 and txin 2 need to be from the same sender address?

e.g. if I have some USDT in address 0, but not enough BTC UTXO in it to pay the miner fee, could I use another UTXO from address 1 as input?

Then how do the simple send decide sender address? The spec said "Has a single or the largest pay-to-pubkey-hash or pay-to-script-hash (since block height 322000) input with a valid signature to designate the sending address", what's largest?

And the spec also requires an exodus output, but I can't find the exodus output in this transaction https://www.omniexplorer.info/tx/5704c0bc3e5af45353a44caeb6098aef629e477daa8f3ef78b92770e7a738ff3

Thanks

dexX7 commented 6 years ago

Hi @cedricfung,

with Class C encoding (OP_RETURN, which is what we use now) the sender is determined by the first transaction input. All other transaction inputs can be arbitrary, so it becomes possible to use other addresses for BTC funding. :)

ScriptProdigy commented 6 years ago

Hey @dexX7 ,

does this also mean that omni_createpayload_simplesend will use all available inputs to pay out the total of the asset? Or will it only use the first input as funding for assets being sent to the singular receiver of the assets?

dexX7 commented 6 years ago

@ScriptProdigy: Omni is balance and not UTXO based and only the specified amount of tokens is taken from the first input.

nival999 commented 5 years ago

Hey @dexX7, i am building off your example to try and embed additional data into the blockchain during an Omni transaction. I am pretty sure that i can do this by sending satoshis to bitcoin addresses that spell something (?).

I am building off the example you gave earlier to make sure I got the whole process right:

txin 0: omni input from sender

txin 1: omni input from same sender

txin 2: omni input from same sender

txout 0: payload that sends omnis from (tx0 + tx1 +tx2)

txout 1: address A that receives omnis

txout 2: satoshi to bitcoin address that spells 'ilikedogs00000'

txout 3: satoshi to bitcoin aaddress that spells 'wethepeople'

txout 4: change output to the sender

In this scenario the "wethepeople" and "ilikedogs00000" are a hidden message

WilliamXie9 commented 5 years ago

Hey @dexX7, i am building off your example to try and embed additional data into the blockchain during an Omni transaction. I am pretty sure that i can do this by sending satoshis to bitcoin addresses that spell something (?).

I am building off the example you gave earlier to make sure I got the whole process right:

txin 0: omni input from sender

txin 1: omni input from same sender

txin 2: omni input from same sender

txout 0: payload that sends omnis from (tx0 + tx1 +tx2)

txout 1: address A that receives omnis

txout 2: satoshi to bitcoin address that spells 'ilikedogs00000'

txout 3: satoshi to bitcoin aaddress that spells 'wethepeople'

txout 4: change output to the sender

In this scenario the "wethepeople" and "ilikedogs00000" are a hidden message

@nival999 can you share how to building your example?

adambor commented 2 years ago

What is the state of this issue? Open for more than 5 years now... Correct me if I am wrong here, but I see this as something that might make it very easy to use omni layer tokens on LN and allow for multi-asset channels to be established (yep, I am aware of OmniBOLT).

patrickdugan commented 2 years ago

Lol, we did an implementation on TradeLayer I'm trading a dev rn with finishing the ticket that my porting engineer started.

I wonder how many 5 year old tickets there are in this repo.

On Sat, Oct 23, 2021 at 11:31 AM adambor @.***> wrote:

What is the state of this issue? Open for more than 5 years now... Correct me if I am wrong here, but I see this as something that might make it very easy to use omni layer tokens on LN and allow for multi-asset channels to be established (yep, I am aware of OmniBOLT).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OmniLayer/omnicore/issues/370#issuecomment-950161187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS2CBJCDJ3A5FOIN2ON2HLUILBLFANCNFSM4CDFFQQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

phuongnd08 commented 2 years ago

Omni is just a deadend right now. So many other technologies has superseded it on other powerful blockchain like bsc, solana

patrickdugan commented 2 years ago

It seems that way due to the lack of resources that have gone into funding it, but it's a powerful 3rd plank of extending the blockchains that really matter. BSC's trade-offs are meh and Solana's trade-offs are cool but it's very different from Bitcoin or (to a lesser extent) Litecoin+Doge (one Scrypt mining network). Appreciation of the role of PoW isn't in vogue right now but in a few years interop between chains will blur a lot of these lines.

OP_Return layers also stand a chance of becoming their own interop environment and bridging the PoW chains together, creating a more powerful DeFi ecosystem than these.

On Mon, Oct 25, 2021 at 7:15 AM Phuong Nguyen @.***> wrote:

Omni is just a deadend right now. So many other technologies has superseded it on other powerful blockchain like bsc, solana

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OmniLayer/omnicore/issues/370#issuecomment-950762091, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS2CBPGI4APLA4SSESNCEDUIUU57ANCNFSM4CDFFQQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

OmniLayer / omnicore

Add send-to-many transaction #370