Closed dexX7 closed 9 years ago
Shoot - that'll be it - sorry I shouldn't bounce around too many things at once ...
Hehe. Works fine, tests passed. :)
Nice, thanks :)
Omniwallet has its own decoder for pending tx support (i.e. to decode the tx's its creating sending). Eventually we're going to want to roll tx decoding and (if possible) tx creation into omnicore entirely. i.e. omniwallet calls omnicore and says i want to send tx type X with info Y and core returns the unsigned tx for us to give the user to sign.
This is something I would very much want to see.
it's probably in no one's interest to re-use a marker or to build a system that collides with another one.
I’m not certain this is true.
@CraigSellars: This is something I would very much want to see.
- https://github.com/mastercoin-MSC/mastercore/issues/283#issuecomment-72756268 Create or fetch raw Omni data
- https://github.com/mastercoin-MSC/mastercore/issues/302#issue-60956007 Wrap it into transaction outputs
- Construct a transaction
Now all this was to test some approaches, and is only partially related, but @zathras-crypto published a new branch for payload creation yesterday (or so) and his class C encoding branch looks pretty solid as well, basically closing the link between raw transaction data and class B/C transactions.
I'd say Omni Core 0.10 (0.0.10 :p) will be huge, and I'm confident creating raw transactions is going to a part of it.. ;)
Class C doesn't use the Exodus marker anymore, but the bytes "omni"
instead. /close
@zathras-crypto suggested the removal of the Exodus address quite some time ago.
Is this feasible? What's your opinion? What are alternatives?