Define our OP_RETURN strategy #198

Open
ripper234 opened this Issue Jun 9, 2014 · 38 comments

Projects

None yet

8 participants

@ripper234
Contributor

No description provided.

@ripper234
Contributor
@dexX7
Member
dexX7 commented Jun 9, 2014

If we want to use OP_RETURN, then I currently see two options:

  1. Use it as Mastercoin transaction identifier instead of the current pay-to-pubkey-hash output to the Exodus address.
    The probably huge downside: sx (and potentially other tools) are only able to list transactions associated with an address, but not with any output, as far as I know. So this would require significant changes to the parsing engines or mastercoin-tools/masterchain.info at least.
  2. Encode data within the OP_RETURN output.
    Up to 40 byte can be stored and this works for most, but not all Mastercoin transactions which are currently in use. The exceptions are (potentially) tx 50: create smart property with fixed number of tokens and 51: create crowdsale with variable number of tokens. This is mainly based on the space used for smart property meta data (category, subcategory, label, url and description).

Tx 50 would fit in, if the size of meta data is at most 20 byte. But no way for tx 51, because even without any meta data, tx 51 still requires 42 byte and this calculation does not include an action byte which is going to be added in version 1 of tx 51.

I'd actually welcome, if we get rid of all meta data and store a reference to somewhere else instead, because it's not required for the functionality, but that's a different story.

So, if we are going to use OP_RETURN to store data:

  1. Is the data obfuscated similar to class B?
  2. Are only transactions allowed which fit in?
  3. If so, is tx 51 considered to fit in or is it decided on the acutal size used in the particular transaction?
  4. Is a mix of class B and C allowed? For example: the first half of tx 51 is stored in an OP_RETURN output, the other half in a m-of-n multisig output with class B encoding.

If we do it, I'm in favor of obfusculation and a mix between class B and C.

By the way, here is an overview of MSC transactions and space required:

u8zjdla

@taariq
taariq commented Jun 9, 2014

Thanks @dexX7. I agee with your points and YES: I would propose removing the metadata including ALL the null-terminated text. Most likely these will never be used and each issuer may use them differently. Maybe the property URL, but even that I would remove as we find that in our assets these are not really used at all by either users or other issuers. Metadata is pretty useless.

All else is asking issuers to fill space they can use elsewhere. Fitting to OP_RETURN would be a good move forward.

@ripper234
Contributor

It's too early to predict what will "most likely never be used".
We'll be a lot smarter in a month.

On Mon, Jun 9, 2014 at 8:01 AM, Taariq Lewis notifications@github.com
wrote:

Thanks @dexX7 https://github.com/dexX7. I agee with your points and
YES: I would propose removing the metadata including ALL the
null-terminated text. Most likely these will never be used and each issuer
may use them differently. Maybe the property URL, but even that I would
remove as we find that in our assets these are not really used at all by
either users or other issues.

All else is asking issuers to fill space they can use elsewhere. Fitting
to OP_RETURN would be a good move forward.


Reply to this email directly or view it on GitHub
#198 (comment).

Ron Gross
Executive Director, Mastercoin Foundation
mastercoin.org | ripper234.com | ripper234 on skype (Inbox != Zero
http://ripper234.com/p/how-i-learned-to-let-go-of-inbox-zero/) | PGP
http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7468729E28277264
Schedule my time at meetme.so/RonGross

@taariq
taariq commented Jun 9, 2014

I don't have to predict. DTT already issues several thousands dollars in gold assets each week and none of the meta data has proven useful or used. I'm sharing insights from deploying real world use case for the past 60 days.

@ripper234
Contributor

Yeah, but that's just one example.
I think we need evidence from ~ 10 issuers to start understanding the needs
of issuers.

On Mon, Jun 9, 2014 at 9:18 AM, Taariq Lewis notifications@github.com
wrote:

I don't have to predict. DTT already issues several thousands dollars in
gold assets each week and none of the meta data has proven useful or used.
I'm sharing insights from deploying real world use case for the past 60
days.


Reply to this email directly or view it on GitHub
#198 (comment).

Ron Gross
Executive Director, Mastercoin Foundation
mastercoin.org | ripper234.com | ripper234 on skype (Inbox != Zero
http://ripper234.com/p/how-i-learned-to-let-go-of-inbox-zero/) | PGP
http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7468729E28277264
Schedule my time at meetme.so/RonGross

@LOLLOLOOLOL

100% support move to OP_RETURN, and marginalizing metadata to an external reference at most.

Strongly against both OP_RETURN and multisig data outputs in a single transaction.

@taariq
taariq commented Jun 9, 2014

@ripper234 Agreed fully and well said. If I can be of further help to your understanding of needs, just let me know.

@zathras-crypto
Contributor

OP_RETURN is too restrictive with 40 bytes. Plain and simple. Also DexX that visualization of byte requirements is excellent :)

The purpose of OP_RETURN is to embed a hash to verify an alternate source of the data, not to store data in itself. Unless we want to adopt that model, you'll have a hard time convincing me that:

  1. We can make MP effective by limiting every message to 40 bytes
    or
  2. We can make MP effective by chaining multiple transactions together to utilize multiple OP_RETURN outputs (only one is permitted per transaction).

There is a clear use case for OP_RETURN, and that is verifying an alternate source of data. I don't see it as a method for data storage. I actually started to draft a Class C implementation back when OP_RETURN was 80 bytes and still found that too restrictive unless metadata was stored elsewhere, which brings us full circle back to the original intent of OP_RETURN which is to embed a hash to verify data stored elsewhere.

@taariq
taariq commented Jun 9, 2014

Indeed. Indeed. Thanks for the reminder Zathras

Sent from my Mobile with fat fingers!

@zathras-crypto
Contributor

On the Exodus marker point, I actually don't think we should have a marker full stop.
We certainly shouldn't spend the effort on obfuscation and then add a marker - it completely defeats the purpose. When we devised obfuscation it was following a discussion with PT around steganography and how to make our data appear random like any other pubkey. This is a pointless endeavor when we hang a marker on the front door (exodus or OP_RETURN or any other).

I believe it should be one of the other - if we want to make our transactions indistinguishable from any other Bitcoin transaction, then we need to rely on (computationally expensive) deobfuscation of all Bitcoin transactions as if they were MP messages. If we want to continue down the road of easily identifiable transactions (marker), then obfuscation seems entirely fruitless IMO.

Thanks!

@dexX7
Member
dexX7 commented Jun 9, 2014

Trying to match all and every transaction against several templates sounds laborious. This completely kills any chance of a lite client. It may be noted that even right now it's completely possible via the Electrum client to fetch all transactions with an Exodus output in less than a few seconds. (well, to be more specific: transaction ids, but tx fetching and decoding is also available)

You have a very good point about the contradiction of a visible identifier vs. obfuscation. On the other hand, maybe they should be seen as something unrelated for the sake of modularity. I once had the idea of using some kind of rolling identifier. Say as simple example: each Mastercoin transaction includes it's "Master protocol transaction index" (how you called it). And let's assume the current last MSC transaction has an index of 12197. Based on this number, we know the next MSC transaction can be found under the identifier 12198 etc. If this is mixed with state information, a miner who likes to block MSC transactions would be required to verify all MSC transactions.. ;) But that's really not practial for more than one reason.

I don't share your sentiment about the usage of OP_RETURN. Only because someone said a potential use-case is to include a hash or a reference to somewhere else, this still doesn't support any argument against the usage for other purposes. In fact, OP_RETURN is actually the best available way to store data on the blockchain in my opinion -- but with the restriction of 40 bytes.

Nevertheless, tx51 won't fit in, even without any all meta data. The data could be splitted between OP_RETURN and multisig outputs or the usage of OP_RETURN is limited to tx 0, 20, 21, 22 and 53 which fit in in all cases.

@zathras-crypto
Contributor

That's an interesting point about an SPV/similar model - I haven't given much thought to how we would apply that kind of simplified model to MP (though should!).

Very interesting concept around a rolling identifier - very interesting indeed - did we discuss before? It rings a bell but I can't quite recall...

My wording was poorly chosen - should have said design intent by those who implemented it - I'm of the view personally that the entire blockchain is use case agnostic (wouldn't be involved in this project otherwise hehe). I see it as unusable for tangible data storage simply because of the byte restriction (I concur that if there were some way to make 40 bytes meaningful then it would be the best way to go, but I disagree that we can make 40 bytes meaningful without handicapping ourselves).

The mix isn't something that stands out as ideal as it introduces complexity without providing benefit to MP (though arguably provides benefit to the underlying Bitcoin network by reducing the weight we add to the UTXO).

I'm keen on keeping the door open for any future potential transaction types in MP and worry that people will spend time trying to restrict themselves to 40 bytes at the expense of functionality so that the TX type can fit in the 'good' OP_RETURN type rather than the 'bad' multisig type (perception wise).

TL:TR; I'm currently in the boat of putting our effort into redeeming Class B multisigs when sending new transactions rather than trying to switch to a half-OP_RETURN half-multisig model. I will say that I haven't given this nearly as much thought as I'd like to however, so I'm of course always open to the fact that my position may not be the best position :)

Thanks
Zathras

@petertodd
Contributor

Any future changes should be to a generic model, rather than one tied to specific assumptions about what scriptPubKeys are allowed. Basically this means the encoding algorithm thinks in terms of PUSHDATA's - how those PUSHDATA's got into the transaction is unspecified. You use low-order bits of the nValue or something to distinguish between mastercoin PUSHDATA and transaction PUSHDATA's. I've got some code from months ago doing this that I can dig up again...

Right now I'm working on replacing IsStandard() with IsSoftforkSafe() - effectively removing all restrictions - and releasing a fork of Bitcoin Core that includes it along with replace-by-fee and my preferential peering code. Code will be here as it's completed: https://github.com/petertodd/bitcoin/tree/issoftforksafe

@LOLLOLOOLOL
  1. We can make MP effective by chaining multiple transactions together to utilize multiple OP_RETURN outputs (only one is permitted per transaction).

This is the most forward thinking and scalable option IMO. At that point we can think about the cost of a transaction rather than whether it's possible, or how it may need to be limited.

@dexX7
Member
dexX7 commented Jun 10, 2014

Basically this means the encoding algorithm thinks in terms of PUSHDATA's - how those PUSHDATA's got into the transaction is unspecified. You use low-order bits of the nValue or something ...

Instead of using the space in multisig or nulldata outputs or choosing either one of those, we would be open to any possible storage slot, but use a marker or selector to identify the storage positions, correct?

Seems reasonable and I'd like to hear more about how you'd use nValue. Did you intend to use the selector also as marker for the purpose of identifying Mastercoin transactions? I'm not sure, if we can get around something static similar to the Exodus output or some magic bytes somewhere.

This is the most forward thinking and scalable option IMO.

Using two or more chained transactions, only to increase the space OP_RETURN provides? Seems like a huge overhead where we already have working solutions, namely class B, for larger chucks of data.

Edit: it's interesting, currently we have quite some rules in place to determine what is what, e.g. (implicitly) multisig outputs (class B) have a higher priority than pay-to-pubkey-hash outputs (class A), data packages must be in order, if there are multiple multisig packages, then start at the beginning and ignore any junk afterwards, select the last pay-to-pubkey-hash output as receiver reference, use the vin with the highest contribution as input, etc. etc. ...

LOL presented the very elegant solution of using a selector to determine a reference output. This could also be applied for inputs. And Peter suggested to do something similar, but related to data packages... nice!

@petertodd
Contributor

Also, I'm working on the general-purpose blockchain proof-of-publication scheme that we can all use. Found some considerations in my previous implementation that I didn't consider, so I need another day or two for a rewrite. Code will be here as it's written: https://github.com/petertodd/blockpop

And yeah, basically you want to be able to, in a general purpose fashion, embed one or more messages into a transaction, make the presence of those messages undetectable unless you know some key, and finally, be compatible SIGHASH_ANYONECANPAY and SIGHASH_SINGLE transaction forms for crowd funds and decentralized market applications.

@petertodd
Contributor

And yeah, we can do much better than chained transactions! P2SH only needs two "levels" of "chain" - setup and publish - and the decoding functions only need to care about single transactions in isolation.

@dexX7
Member
dexX7 commented Jun 11, 2014

To fully benefit from advanced signing mechanisms, we still need a way to attach balances to outputs. (Assuming you were thinking about atomic coin swaps etc.)

@petertodd
Contributor

@dexX7 Yup - I'm taking that into account in my encoding scheme, in the sense that it can assign data to an output (or input) regardless of what outputs or inputs that data is stored in.

@ripper234
Contributor

Counterparty now has OP_RETURN,

They claim this drops the tx fees for their 'simple sends' to $0.01 fees with $0.03 sent to destination

This transaction is an example of a modern send transaction that cost only US $0.01 in fees, with a $0.03 output to the destination. It was constructed and broadcast with the following command: counterpartyd.py send --source=SOURCE --destination=DEST --quantity=1 --asset=XCP --encoding='opreturn' --fee=.00002, and it was confirmed almost immediately. If you're moving lots of assets around, or sending one asset to many users, you can use this script to automate the process and keep costs as low as possible.

See #192 .

Shouldn't we adopt the same trick (that our developers initially planned back in the day), to lower the cost of our transactions as well?

@LOLLOLOOLOL

@PeterTodd I believe what @dexX7 meant is that MP balances are attached to
addresses instead of transaction outputs. Meaning that spending an output
that a Mastercoin "rode in on" doesn't necessarily spend that Mastercoin.
The applicability of SIGHASH_ANYONECANPAY and SIGHASH_SINGLE transaction
forms to Mastercoin is minimal at best at the moment.

And yeah, we can do much better than chained transactions! P2SH only needs two "levels" of "chain" - setup and publish - and the decoding functions only need to care about single transactions in isolation.

How do you envision this being implemented in MP? If I'm understanding
correctly, the "setup" is sending an output to a P2SH address, and the
"publish" is spending that output, which publishes the encrypted payload,
which can then be decrypted if the proper key is known. This may be great
for data storage under certain circumstances, however its usefulness is
greatly diminished since spending an output can't guarantee spending
Mastercoin. It also adds an additional bitcoin transaction to any MP
transaction.

Anyway, I'd love to see an implementation of this - it'd be revolutionary
for protocols that are closer to the colored coin model.

On Wed, Jun 11, 2014 at 3:03 PM, Peter Todd notifications@github.com
wrote:

@dexX7 https://github.com/dexX7 Yup - I'm taking that into account in
my encoding scheme, in the sense that it can assign data to an output (or
input) regardless of what outputs or inputs that data is stored in.


Reply to this email directly or view it on GitHub
#198 (comment).

@petertodd
Contributor

Here's my blockchain proof-of-publication library/spec: https://github.com/petertodd/blockpop

So basically the idea there is it's a generic publishing mechanism with a defined standard. As you can see in the extraction function it doesn't actually care how you encode the transaction, just that you follow the standard. P2SH scriptSigs, bare CHECKMULTISIG, OP_RETURN, OP_RETURN with > 40 bytes, whatever - it's all data and it's all treated the same way. What's really nice about this is it's future proof: if the best way to encode a transaction changes, you just change an encoding function and the decoding side of things doesn't need to change and it's not a consensus critical change.

Honestly, I think Counterparty is being a bit foolish here. There isn't One True Way to encode transactions and if they had to restrict what the protocol does to stuff everything in 40 bytes they've made a mistake. Defining explicit ways of encoding transactions as opposed to generic mechanisms is just too low-level.

Of course, authenticating the data is another matter. Basically you want to think in terms of what signatures signed the data that was encoded rather than outputs per-se. Fortunately this can easily be done "locally" by just checking that the scriptSig signed the data - what's nice about P2SH and pay-to-pubkeyhash is that all the info to check this is in the scriptSig's.

This may be great for data storage under certain circumstances, however its usefulness is greatly diminished since spending an output can't guarantee spending Mastercoin.

What do you mean here? Again, it's just a data-encoding mechanism - the "setup" transactions don't exist from the point of view of the decoding routine.

@ripper234
Contributor

Here's my blockchain proof-of-publication library/spec: https://github.com/petertodd/blockpop

Woot Peter, I didn't know what stage that was at, it seems to be picking up speed!
Posted to our groups.

@ripper234 ripper234 referenced this issue in petertodd/blockpop Jun 25, 2014
Open

Add some meat to readme.md #1

@dacoinminster
Contributor

@CraigSellars in a meeting with @ripper234 and @DavidJohnstonCEO asked me to make a recommendation about what we should do with OP_RETURN. This issue seems to be the place to discuss it.

It does appear that XCP has successfully leveraged this opcode to lower their transaction costs for simple sends. I believe (from what I read) that they are encoding their metadata in the OP_RETURN opcode. Since they don't have a marker address like 1Exodus, that is a significant cost savings for them. It appears that the cost savings would be smaller for us, unless we also got rid of our marker address simultaneously which is (I believe) a bigger change, but also another potential cost savings.

What is clear is that we cannot put the recipient's bitcoin address into the metadata (not enough room).

I think this could be a small win for us, but it would only be one part of a more comprehensive "class C" transaction type aimed at lowering fees.

I won't try to say where this should fall in our development priorities, but I don't think the coding would be trivial. Actual size estimates should come from the ones doing the coding, obviously.

@dexX7
Member
dexX7 commented Oct 9, 2014

@zathras-crypto posted in #267 a OP_RETURN strategy as a sidenote and I think it's better to keep it this in a seperated thread. I'm not sure, if it's ready for prime time, but nevertheless: http://pastie.org/private/lqtwnyyt8undpgth1tlw

This means that Class C transactions cannot currently completely replace Class B for larger transaction types such as smart property issuances ....

I know you don't like it, but what's your objection against mix-encodings? Class A is soft-depreciated, that's for sure, but it's actually not that simple to decide op_return is the new standard from now and the use of bare multisig should be discouraged. At the very moment using op_return comes with a significant confirmation delay, even though I agree: it should be used most of the time - but it's not that black and white.

Lowered Cost

A switch to op_return should only yield minimal cost savings and the most part at the very moment is based on the way to high outputs values.. :/

Since in a Class C transaction Master Protocol data no longer needs to masquerade as valid public keys, obfuscation is no longer required ...

I'm pretty sure we could get away with [02|03] unobfuscated-data-package [ecdsa byte] given that (much?) more than 50 % of all possible values are valid and it would rather be a rare event, if 256 variants are not enough to find a valid ecdsa point. I'm not sure, if we should remove the obfuscation altogether or rather find something more efficient.

... sequence numbers and packet ordering are no longer required.

Yup, agree - an explicit package order makes sequence numbers obsolete and I also think - if class B is not completely depreciated, then there could also be class B+ without sequence numbers.

Has a single or the largest (by sum) pay-to-pubkey-hash or pay-to-script-hash input with a valid signature to designate the sending address.

Input selection by sum should be depreciated imho and I see no benefit of doing it any different. It was never used in the wild and it kills one use-case I will refer to rather sooner than later. Is there any reason to not simply use "first vin = sender"?

By encoding the vout number of the reference address within the data packet ....

That's interesting! I'm split between explicit references and "virtualized". I guess it depends on the use-case, but since Mastercoin is not output based, I believe references could be virtualized most of the time - and given that any Mastercoin transaction is parsed anyway and there is no "notification" aspect to begin anymore. (I reserve here an option for explicit references via outputs nevertheless)

Starting to pack multiple Mastercoin transactions into one is what I proposed quite some time ago and I still think it's an idea worth to consider - see #62.

But let's remove the explicit reference from a simple send quickly and send 500 GoldCoins to 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb:

version: 0 | type: 0 | currency identifier: 3 | number-of-coins: 500

As raw data and with op_return it would be something like:

OP_RETURN:
0000|0000|0000 0003|0000 0000 0000 01f4 (payload length: 16 byte)

Still plenty of space.. so why not append the reference? The last data piece is the address in hex form:

OP_RETURN:
0000|0000|0000 0003|0000 0000 0000 01f4|dd84 a40b a1d6 efd7 d303 e2c3 ca80 ced2 a9b3 d45f

And there are still 4 bytes left.. which could be used as marker:

OP_RETURN:
54455354|0000|0000|00000003|00000000000001f4|dd84a40ba1d6efd7d303e2c3ca80ced2a9b3d45f
marker  |ver |type|  curr  |  num-of-coins  | ref: 1MCHESTxYkPSLoJ57WBQot7vz3xkNahkcb

The example transaction: ab9698f02af0f7414f0ae3fcec0a74b841b648546a42e438e0cdc5dffef921dd

But that's just an idea. I care much more about packing multiple transactions into one instead of virtualizing the reference..

... removing the requirement for an Exodus output ...

This is also interesting. Would you remove any marker? I believe this might be possible, but you mentioned this some time ago already IIRC, so I'm especially interested in your thoughts about this.

Regarding the encoding in general: I'd try to avoid to think in terms of "this-or-that output-type" but rather in push operations. And @petertodd's blockpop library is worth to mention here, too. It's done well and worth to spend some step-by-step debug time to get a feeling for the general idea. :)

@zathras-crypto
Contributor

Thanks DexX

I know you don't like it, but what's your objection against mix-encodings?

None. Perhaps worded poorly but both Class B & Class C would still be fully supported by the reference client, it's simply that the reference client would have an order of preference, and if possible to send a Class C then it should do so. I envisage that would come with say a startup flag --disableclassc for example and/or UI selectable options.

This also kind of factors into my suggestions that we have a 'high' and 'normal' priority send facility, where the fees, outputs, class and so on can all be set based on that selection - basically "cost more and confirm quicker", or "cost less and confirm slower"

A switch to op_return should only yield minimal cost savings and the most part at the very moment is based on the way to high outputs values.

I don't disagree there at all. For me it's a simplistic view of "if we're gonna have a new transaction class, why not try and make it as low cost as is technically feasible". The question for me is more of whether a loss of the Exodus marker would hurt lightweight clients trying to use something like say BIP37 to only retrieve messages that include Exodus.

I'm pretty sure we could get away with [02|03] unobfuscated-data-package [ecdsa byte]

Yeah, obfuscation I initially put in as a censorship resistance method, since plain pubkeys are so easy to detect. However since we hang an 'Exodus' sign on the front door anyway, I see this as ineffective overall. As you mentioned I was also pushing for removal of Exodus back in the day :p

Input selection by sum should be depreciated imho

Interesting point. FYI input selection of largest 'by sum' is an inheritance from the original Exodus fundraiser, where we considered the largest (by sum) input address to be the sender of the bitcoin and receiver of the generated MSC & TMSC. It has proven reliable though so I'd be looking at what benefits a change in input selection would bring before commenting further on that one :)

Still plenty of space.. so why not append the reference?

This bit confused me a little mate, what hex encoding are you using for the address there? That seems to short? That 1MCHEST address is 314d434845535478596b50534c6f4a35375742516f7437767a33786b4e61686b6362 hex encoded no? Anyway tl:dr; on that is most bitcoin addresses are 34 bytes right, so once you encode 34 bytes into an OP_RETURN output you're left with 6 - not enough to do much with.

Thanks for the feedback (keep it coming!) :) and I'll try and find some time to look at PT's blockpop and your issue #62

Z

@dexX7
Member
dexX7 commented Oct 12, 2014

That 1MCHEST address is ...

Actually you converted the base58 encoded address into hex, but the 1xxxx form is only what you "see", not what is actually transported. If you run bitcoin-cli getrawtransaction 5392f31370f69840a700ad4de5091cf2e235326614778d474f70c3d199d7490f 1 or take a look at the script section here: https://blockchain.info/tx/5392f31370f69840a700ad4de5091cf2e235326614778d474f70c3d199d7490f?show_adv=true

rraw

raw2

raw3

... it's hopefully more clear. :)

If you want to dig deeper:

https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
https://bitcoin.org/en/developer-reference#address-conversion

The TL;TR: 27-35 (IIRC) bytes long addresses are for human consumption and are constructed in a more readable form (without ambiguous characters such as "0", "O" or "o" and with a check-sum, but that's not how they are actually transported -- and it's only 20 byte. :)

You can visit https://brainwallet.github.io/#converter and play around a bit (top: B58Check, bottom: Hex).

@zathras-crypto
Contributor

Thanks DexX - really helpful info :)

Whilst I still like the idea of the current reference address scheme that certainly does open up some thought. The reason I prefer the current model at the mo is because the incoming BTC is a kind of notification that there has been an inbound transaction to the address. I'm not sure how many of our integrators are using things like walletnotify= to trigger stuff in their respective systems for incoming txs but I quite like inheriting that function. FYI I also do use that also in the UI currently (rather than new signals I hook into the BTC setBalance signal that's emitted every time a bitcoin tx comes into the wallet) to go out and refresh the global tokens and address tokens numbers and then the form. That can be solved of course with new MP related signals.

3x20 bytes fits in quite nicely to our Class B outputs, (2 packets at 30 bytes each). I wonder if that's an avenue for multisend...

Thanks
Z

@dexX7
Member
dexX7 commented Oct 12, 2014

Yeah, well, the "virtualization" was rather a byproduct for what I actually wanted: including multiple transactions into one - seperated by a seperator field or something. You already named multisend as one application. :)

I agree that there are indeed reasons to have an explicit output.

@dexX7
Member
dexX7 commented Oct 31, 2014

By the way, is there any reason not to use OP_RETURN right now, all further optimizations and so on aside?

Since everyone - except someone how sends zero fee transactions from time to time and the faucet which calculates fees based on actual transaction size - seems to attach a standard fee of 0.0001 BTC per transaction, there is plenty of unused space, so to speak and I believe the following might be a possible strategy for a transition:

To ensure "no one gets left behind" or ends up with a very different view of world, because a client is unable to recognize OP_RETURN transactions, there could be a special period in which data packages are embedded in bare multisig outputs and OP_RETURN at the same time.

New and old clients would equally be able to identify and parse such transactions and doing so signals "I'm ready for OP_RETURN" and likewise "I'm not ready for OP_RETURN", if the second data output is missing.

When the majority of Mastercoin transactions carries an OP_RETURN output, then we can stop attaching duplicated data encoded in two formats and stick to the new one.

Of course old encoding schemes will still be accepted.

@ripper234
Contributor

I don't support using two encodings per tx. Instead I propose implementing
on testnet, setting a migration path and schedule, and eventually adding
opreturn to the production protocol. After a while of running in
production, I would deprecate and then remove class b tx altogether.
On Oct 31, 2014 9:34 AM, "dexX7" notifications@github.com wrote:

By the way, is there any reason not to use OP_RETURN right now, all
further optimizations and so on aside?

Since everyone - except someone how sends zero fee transactions from time
to time and the faucet which calculates fees based on actual transaction
size - seems to attach a standard fee of 0.0001 BTC per transaction, there
is plenty of unused space, so to speak and I believe the following might be
a possible strategy for a transition:

To ensure "no one gets left behind" or ends up with a very different view
of world, because a client is unable to recognize OP_RETURN transactions,
there could be a special period in which data packages are embedded in bare
multisig outputs and OP_RETURN at the same time.

New and old clients would equally be able to identify and parse such
transactions and doing so signals "I'm ready for OP_RETURN" and likewise
"I'm not ready for OP_RETURN", if the second data output is missing.

When the majority of Mastercoin transactions carries an OP_RETURN outputs,
then we can stop attaching duplicated data encoded in two formats and stick
to the new one.

Of course old encoding schemes will still be accepted.


Reply to this email directly or view it on GitHub
#198 (comment).

@dexX7
Member
dexX7 commented Oct 31, 2014

Without checkpoints or any other Mastercoin transaction pruning mechanism, all encodings and transaction types must be supported to process historical transactions, but yeah, at some point new class A (or B) transactions could be invalidated. @LOLLOLOOLOL actually suggested doing so about two months ago in #241.

A scheduled start where clients already have the ability to use OP_RETURN, but start to use it after some specific block in the future is an option too, if it's forseeable that users actually update their clients.

Let me rephrase then:

What's needed to get the process starting?

@ripper234
Contributor

Someone to lead it :-)
On Oct 31, 2014 10:27 AM, "dexX7" notifications@github.com wrote:

Without checkpoints or any other Mastercoin transaction pruning mechanism,
all encodings and transaction types must be supported to process historical
transactions, but yeah, at some point new class A (or B) transactions
could be invalidated. @LOLLOLOOLOL https://github.com/LOLLOLOOLOL
actually suggested doing so about two months ago in #241
#241.

A scheduled start where clients already have the ability to use OP_RETURN,
but start to use it after some specific block in the future is an option
too, if it's forseeable that users actually update their clients.

Let me rephrase then:

What's needed to get the process starting?


Reply to this email directly or view it on GitHub
#198 (comment).

@dexX7
Member
dexX7 commented Nov 11, 2014

Directly related - there is a pending PR for Bitcoin Core to disable bare multisig per default:

https://github.com/bitcoin/bitcoin/pull/ 5231

@ABISprotocol

@dexX7 I made a random comment on that bitcoin pull (5231) that you referenced above.

@ripper234
Contributor

Right link for the PR: bitcoin/bitcoin#5231

P.S @dexX7 , cool chart here.

https://cloud.githubusercontent.com/assets/5836089/4985288/ec2640fa-692b-11e4-985f-265bd438fad5.png

Can you add another chart with real time instead of block time on the X axis?

@dexX7
Member
dexX7 commented Nov 13, 2014

@ripper234: I uploaded the whole collection of charts and data to:
http://bitwatch.co/uploads/chain_usage_0-327500.zip.

Here is a version with timestamps:

Total Number of Asset Transactions

Unfortunally I didn't gather timestamps right from the beginning and added the dates by hand, so a "with real dates" version is only available for this chart. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment