Release process and plan for 0.0.10

[dexX7]

Let's discuss a timeline, and steps to take.

The process for preview builds, and releases should be done as before:

1. Test build process
2. Tag release
3. Build binaries for Windows, Unix and OS X, ideally deterministically
4. Publish results

What is the timeline for the release, or preview?

What should be added for the preview?

What should be added for the release?

I started a list, and created a few more issues, for points I can currently think of:

• Unification of RPC labels, commands, descriptions #14: Unification of RPC labels, commands, descriptions
• Documentation for Omni Core specific options #71: Documentation for Omni Core specific options (started, but needs refinement)
• Tweak and group transaction parsing and handling #74: Tweak and group transaction parsing and handling
• Coin selection and fee warning #78: Coin selection and fee warning
• Rebrand project to Omni Core #91: Rebrand project to Omni Core (related: Rebranding / file names #10)
• LOCK properly, everywhere, where necessary #94: LOCK properly, everywhere, where necessary
• Update RPC API documentation #95: Update RPC API documentation
• Changelog and release notes for 0.0.10 #96: Changelog and release notes for 0.0.10
• Prepare installers, replace icons, define version #97: Prepare installers, replace icons, define version
• Use notifications to enable features #104: Notification based consensus rule updates (related: Seperate block height restrictions and feature activation #116, Implement and switch to Feature-Activation-By-Message #129, Implement and switch to Feature-Activation-By-Message #159)
• 0.0.10 RPC changes #105: MetaDEx RPC overhaul
• RPC: Standardize calls on omni_abcdefghij #113: Standardize RPC calls on omni_abcdefghij
• Bump Omni Core version to RC1 #117: Bump Omni Core version to RC1 (related: Bump version to 0.0.10.0-rc1 #162)

---

Guidelines:

• Signing of Omni Core build results via Gitian

[zathras-crypto]

Nice, this is great!

I wanted to talk with you about this actually - @CraigSellars and I had a chat at the last meeting where I raised my concerns that MetaDEx has so much complex math in it and hasn't really been tested much should we be making it live straight on mainnet?

We both agreed that one of my old suggestions from back in the day could potentially be revisited. This in a nutshell would be a message from Exodus "making live" a new feature, instead of having a hardcoded blockheight in the source.

The main focus of it is we would be able to release 0.0.10 at our convenience, and set the live MetaDEx (and Class C) height via an alert style message rather than having to decide the live blockheight before 0.0.10 is released. Thus we can release, have people play with trading test eco properties, and then broadcast the live blockheight for main eco when we're happy.

I fully agree with @msgilligan that this is not a substitute for testing, but given that folks would like to see 0.0.10 released soon, and I'd like to see a solid month + of testing by other people on MetaDEx via test properties, it seems like a potential compromise.

What do you think bud? Does what I've described make sense?

[dexX7]

Hehe, remember when I proposed: "let's do frequent releases, and one before the Meta DEx"? .. ;)

I don't feel strongly about the Meta DEx actually.

In my opinion it's a valid point to consider that excluding it from the release doesn't provide any additional exposure though. The test plan is unchanged since roughly December, and I haven't really seen any proposals until now to test it; the additional testing done during the overhaul excluded.

So this raises two important questions:

• When is the exchange considered as ready?
• Which steps are to take?

OP_RETURN is enabled in regtest mode and testnet, so it's basically already heavily tested passively for quite some time, and with #74 all statements in parseTransaction() are executed at least once, except the ones for logging and a return after a check, whether there are more than 255 multisig outputs in class B parsing (it's in the logic, but not tested via the unit tests).

So to add:

• What reasons are there to postpone class C encoding?
• Which steps are to take to resolve these?

I'll add a bit more later regarding the rest.

[zathras-crypto]

Hehe, remember when I proposed: "let's do frequent releases, and one before the Meta DEx"? .. ;)

I'm open to different options here :) What I do want to avoid is frequent consensus breaking releases. Releases that don't break consensus we can do more frequently perhaps?

So this raises two important questions:
When is the exchange considered as ready?
Which steps are to take?

This is where I need testers to advise really. But my current "gut feeling" is certainly it's not ready when the only people to have played with it are basically me and you.

So to add:
What reasons are there to postpone class C encoding?
Which steps are to take to resolve these?

None, Class C is solid in my book.

The notion of living features via a message instead of via a hardcoded blockheight is basically me trying to remove the requirement for us to feel MetaDEx is 100% ready for mainnet release in order to release 0.0.10.

[dexX7]

None, Class C is solid in my book.

Ah, okay.

This is where I need testers to advise really. But my current "gut feeling" is certainly it's not ready when the only people to have played with it are basically me and you.

So what could be done to get testers on board?

[zathras-crypto]

So what could be done to get testers on board?

A useable wallet :)

That's kind of where I was thinking if we released 0.0.10 without a hardcoded live height, people could trade test eco properties around and maybe we'd get some more exposure?

[dexX7]

Aahhh, the details.. hehe..

should we be making it live straight on mainnet?

I read the following at first:

should we exclude it [completely]?

And given all this, the discussion is pretty much about:

should we use hardcoded block heights or deliver them via notification system?

... and not really about whether some feature should be enabled or not.

It that correct? :)

If so: it's a great idea, and I like it!

We should nevertheless roughly define and communicate how the enabling is done, and when, at least an estimation. "We'll enable it, when we feel it's ready" ... probably wouldn't look good in any release notes. :)

[zathras-crypto]

I don't think we should exclude it, I would like to see people trading test eco properties as I think more eyes will help us pick up more bugs (and avoid potential loss of funds or an emergency release, my main goal in all this).

And given all this, the discussion is pretty much about:
should we use hardcoded block heights or deliver them via notification system?
... and not really about whether some feature should be enabled or not.
It that correct? :)

Pretty much - the context is coming from MetaDEx but it would apply to all features from now on.

If so: it's a great idea, and I like it!

Sweet!!! I'll look at coding it up :)

We should nevertheless roughly define and communicate how the enabling is done, and when, at least an estimation. "We'll enable it, when we feel it's ready" ... probably wouldn't look good in any release notes. :)

Fully agree - we should be saying "in the absence of any critical bugs we plan to make feature X live in {month}".

[dexX7]

We should probably create another issue to track/discuss ideas re: notification based enabling.

This, and probably the MetaDEx work should be added to the "tasks for the release", I think?

[zathras-crypto]

We should probably create another issue to track/discuss ideas re: notification based enabling.

Sure, it would be good to get consensus that this is the direction we're going in - I started working on some code for notification based feature enabling just as a PoC but it would be good to agree ideas and the process etc :)

[dexX7]

Alright. We're pretty close. Please don't worry, even though the list above gets longer, there are no new items, but rather refinements. Currently still missing:

• Unification of RPC labels, commands, descriptions #14: Unification of RPC labels, commands, descriptions (almost done)
• Documentation for Omni Core specific options #71: Documentation for Omni Core specific options (started, but needs refinement)
• Update RPC API documentation #95: Update RPC API documentation
• Changelog and release notes for 0.0.10 #96: Changelog and release notes for 0.0.10
• Use notifications to enable features #104: Notification based consensus rule updates (related: Seperate block height restrictions and feature activation #116)
• RPC: Standardize calls on omni_abcdefghij #113: Standardize RPC calls on omni_abcdefghij (almost done)
• Bump Omni Core version to RC1 #117: Bump Omni Core version to RC1 (low hanging)

I'm not 100 % sure, if the Gitian environment changed significantly since 0.9, and at home I have a VM, which I setup earlier. So first, just to clarify: we are going the deterministic build route, right?

Notably, downloading "inputs" for Gitian is no longer necessary, due to the superb dependency managment system, which was introduced with 0.10.

The documentation to setup a Gitian building box is pretty good. The following parts between Preparing the Gitian builder host and Setting up gitian images are useful for us.

@zathras-crypto: have you ever used GPG in Ubuntu? If not, do you have access to your GPG private key?

I'm going to write a short list of steps to do, after the environment is configured, to cover the rest. I think it would also be nice, if we'd have a "checklist" for releases, i.e. define a release process. Hopefully, I find some time later to take a first shot at it, too.

Are there others who would like to participate in the building process, and build the binaries locally, so we can tripple check results? @msgilligan maybe?

[msgilligan]

I'm game for giving it a try.

[zathras-crypto]

@zathras-crypto: have you ever used GPG in Ubuntu? If not, do you have access to your GPG private key?

No and yes :)

[zathras-crypto]

The documentation to setup a Gitian building box is pretty good. The following parts between Preparing the Gitian builder host and Setting up gitian images are useful for us.

I was attempting to build a fresh VM for building with the changes introduced in 0.10, though I seem to fail out with error:

bin/make-base-vm: 117: bin/make-base-vm: mkfs.ext4: not found

When trying to build the base VM - I had a quick poke around and can see it seems that PATH is set to:

declare -x PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

for user debian when following that guide - you'll note that it's lacking /sbin (which is where mkfs-tools are located) - I'll try adding sbin into the path (just with export PATH=$PATH:/sbin and give it another run and update here.

[zathras-crypto]

That seems to have sorted it - onwards!

[zathras-crypto]

Notably, downloading "inputs" for Gitian is no longer necessary, due to the superb dependency managment system, which was introduced with 0.10.

So we don't need to register for an Apple developer account and "Using a Mac, create a tarball for the 10.7 SDK and copy it to the inputs directory"?

[zathras-crypto]

Lots of errors hehe - culminating in:

Running build script (log in var/build.log)
./bin/gbuild:21:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
    from ./bin/gbuild:137:in `build_one_configuration'
    from ./bin/gbuild:264:in `block (2 levels) in <main>'
    from ./bin/gbuild:259:in `each'
    from ./bin/gbuild:259:in `block in <main>'
    from ./bin/gbuild:257:in `each'
    from ./bin/gbuild:257:in `<main>'

[dexX7]

Hmhm.. what does ~/gitian-builder/var/build.log say?

I have no experience with setups outside of the scope of this tutorial.

So we don't need to register for an Apple developer account and ...

Actually, this is this only exception, but no, we don't have to register an Apple account here. We can reuse the file, as Travis does:

• https://s3.amazonaws.com/ci.omnicore.private/depends-sources/sdks/MacOSX10.7.sdk.tar.gz

[zathras-crypto]

Hmhm.. what does ~/gitian-builder/var/build.log say?

Tail end is:

+ echo 'export FAKETIME="2013-06-01 00:00:00"'
+ echo '$REAL $@'
+ chmod +x /home/ubuntu/wrapped/i686-w64-mingw32-windres
+ for prog in '${FAKETIME_HOST_PROGS}'
+ echo '#!/bin/bash'
+ echo 'REAL=`which -a i686-w64-mingw32-strip | grep -v /home/ubuntu/wrapped/i686-w64-mingw32-strip | head -1`'
+ echo 'export LD_PRELOAD=/usr/lib/faketime/libfaketime.so.1'
+ echo 'export FAKETIME="2013-06-01 00:00:00"'
+ echo '$REAL $@'
+ chmod +x /home/ubuntu/wrapped/i686-w64-mingw32-strip
+ export PATH=/home/ubuntu/wrapped:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ PATH=/home/ubuntu/wrapped:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+ cd omnicore
++ pwd
+ BASEPREFIX=/home/ubuntu/build/omnicore/depends
+ for i in '$HOSTS'
+ make -j2 -C /home/ubuntu/build/omnicore/depends HOST=x86_64-w64-mingw32
make: Entering directory `/home/ubuntu/build/omnicore/depends'
Fetching native_ccache...
/bin/sh: 1: wget: not found
/bin/sh: 1: wget: not found
make: *** [/home/ubuntu/cache/common/download-stamps/.stamp_fetched-native_ccache-ccache-3.1.9.tar.bz2] Error 127
make: Leaving directory `/home/ubuntu/build/omnicore/depends'
lxc-start: Connection refused - inotify event with no name (mask 32768)

wget is available on the system and within path.

I get a large number of these two repeated:

lxc-start: unrecognized option '--version'
Usage: lxc-start --name=NAME -- COMMAND

lxc-start start COMMAND in specified container NAME

Options :
  -n, --name=NAME      NAME for name of the container
  -d, --daemon         daemonize the container
  -f, --rcfile=FILE    Load configuration file FILE
  -c, --console=FILE   Set the file output for the container console
  -C, --close-all-fds  If any fds are inherited, close them
                       If not specified, exit with failure instead
               Note: --daemon implies --close-all-fds
  -s, --define KEY=VAL Assign VAL to configuration variable KEY

Common options :
  -o, --logfile=FILE               Output log to FILE instead of stderr
  -l, --logpriority=LEVEL          Set log priority to LEVEL
  -q, --quiet                      Don't produce any output
  -?, --help                       Give this help list
      --usage                      Give a short usage message

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

See the lxc-start man page for further information.

and

dpkg: error: --compare-versions takes three arguments: <version> <relation> <version>

Type dpkg --help for help about installing and deinstalling packages [*];
Use `dselect' or `aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

I'll probably take another run at it again from scratch, the only difference from the tut is I'm doing this in VMWare Player instead of VirtualBox (because VirtualBox kernel modules won't compile under 14.04 with a 3.19 kernel) but that shouldn't make any difference.

[dexX7]

Hm...

Could you try the following (from `~/gitian-builder/):

make -C ../omnicore/depends download SOURCES_PATH=`pwd`/cache/common

[zathras-crypto]

debian@debian:~/gitian-builder$ make -C ../omnicore/depends download SOURCES_PATH=`pwd`/cache/common
-bash: make: command not found

[zathras-crypto]

Ahh - I just noticed your path there - I cloned the Omni Core repo into bitcoin:

git clone https://github.com/OmniLayer/omnicore.git bitcoin

But perhaps I shouldn't have specified the 'bitcoin'

[dexX7]

Ah! :) All bitcoin should be replaced with omnicore.

[zathras-crypto]

Ah! :) All bitcoin should be replaced with omnicore.

D'oh! I think I remember doing it that way last time so probably just ran with it hehe - I'll take another run - thanks :)

[dexX7]

This is probably due to the old tutorial. :)

Which version/commit did you specify, when running gbuild?

[zathras-crypto]

Which version/commit did you specify, when running gbuild?

./bin/gbuild --commit omnicore=97f00c387c23a87b1963f3cceb2a13cedae16ebf ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

[zathras-crypto]

Same error as before (wget: not found) after cloning into omnicore instead of bitcoin - I'll take another shot at the whole VM from scratch when I get some more time...

[dexX7]

Okay.. I'm going to give it a try, hopefully soon. Setting up the VM should be possible in a reasonable amount of time. I'll update, once I know more.

[dexX7]

Couple of notes:

• I downloaded http://cdimage.debian.org/debian-cd/8.1.0/amd64/iso-cd/debian-8.1.0-amd64-netinst.iso
• the setup was slightly different than before
• I couldn't login via SSH as root (fix)
• when trying to setup Gitian, as described in Setting up gitian images, I see the following error:

bin/make-base-vm: 117: bin/make-base-vm: mkfs.ext4: not found

Edit: appearingly this is due to the Debian version, and a one-line change fixes it.

Edit: same issue for me (wget: not found) ...

[zathras-crypto]

I see the following error:

see above mate :) #93 (comment)

export PATH=$PATH:/sbin

[dexX7]

So what would you change?

[zathras-crypto]

So what would you change?

I don't know at this stage, I just think we need an (easier) way for end users to use an appropriate fee, the Bitcoin Core estimation (0.00004424 BTC/kB) being well on the way to "fast" is obviously very inadequate when our transactions carry such a small amount of BTC (and thus the inputs are likely to be very small, and thus the priority is likely to be very low).

[dexX7]

Right now there are around 20.000 transactions in the mempool with a fee of at least 0.0001 BTC (per tx, not per kB), and more than 5.000 with at least 0.0002 BTC, and the top 2000 have a fee of 0.0009 BTC or more. I have no idea how large those transactions are, but let's assume around 300-350 kB, then that's close to 0.003 BTC/kB for the top 2000.

Given that there are around 1000-2000 transactions per block, well..

The assumptions are not really solid, but it provides some context for the non-confirming 0.00004424 BTC/kB transaction.

Edit:

$ bitcoin-cli estimatefee 1
0.00106377

$ bitcoin-cli estimatefee 6
0.00044247

$ bitcoin-cli estimatefee 10
0.00037593

$ bitcoin-cli estimatefee 20
0.00019230

This is significantly higher than the number shown in the UI picture.. hmm.

[zathras-crypto]

Thanks for the stats - where are you getting that data from? Programmatically inside Core? I know the data is there I've just never looked into getting at it...

I understand what's going on, I just think in an ideal world there would be a radio button a user could click for quick confirmation that'll advise & pay whatever fee is necessary, even if that's 0.003 BTC/kB (it's up to the user).

[dexX7]

I used bitcoin-cli getrawmempool true | grep "\"fee\"" and sorted it. :)

I just think in an ideal world there would be a radio button a user could click for quick confirmation ...

Hehe, but isn't this pretty similar to "move the UI silder to 1"?

Let's quickly clarify, because this is the part currently not really clear to me: do you want to improve the UI or the fee estimation?

Edit: mis-clicked.

[zathras-crypto]

Hehe, but isn't this pretty similar to "move the UI silder to 1"?

Heh, kind of :P The slider at 1 block is 0.00118869 BTC/kb - I guess the point I'm trying to make is that fee estimation makes the assumption that you'll actually be sending some BTC somewhere - since we're only sending slightly over dust for the most part our inputs will be tiny and our priority extremely low. Thus the "Estimated to begin confirmation within X block(s)" isn't really very accurate for Omni transactions.

Let's quickly clarify, because this is the part currently not really clear to me: do you want to improve the UI or the fee estimation?

I want to improve the user experience, whatever form that takes. Note it's confusing for users that the transaction fee selection sits under the Send > Bitcoin tab as it's not immediately obvious that this affects all outgoing Omni transactions also. Muddling with internal fee estimation calculation only seems like it'll cause more trouble and deviation from Bitcoin source moving forward so I'm not keen on that, I'm still thinking about what (if anything) to do, it could be as little as a warning dialog when a user sends anything that with their current settings it will take a long time to confirm, or as much as analysing what's in the mempool ourselves with some kind of heuristics to do our own fee estimation. I don't have an "answer" hehe at this stage, simply that I want to make it as simple as possible for end users :)

[dexX7]

fee estimation makes the assumption that you'll actually be sending some BTC somewhere

Thus the "Estimated to begin confirmation within X block(s)" isn't really very accurate for Omni transactions.

As long as we pass the IsStandard checks, then "close-to-dust" shouldn't matter (except for Eligius and other mean pools). Sending old coins, or high values, has a positive effect on the priority, and thus confirm time, but so does the transaction fee.

I may be very wrong, but if I recall correctly, then there are only two classes where priority plays a role:

• high enough priority to consider the transaction as free
• anything else

And "anything else" is then prioritized solely based on fee/kB. This is of course depending on the mining policy, but as far as I know this is the default behavior of Core.

Either way, to my understanding the whole point of the fee estimation is to estimate the fee for a transaction, whether this is based solely on the fee, or a combination of fee and priority, but I don't really see how a non-Omni-transaction and some-other-transaction would be rated differently.

[dexX7]

Now that the issues are hopefully resolved, let's give it another try.

Update your local copy of ~/omnicore and checkout 374779d.

export SIGNER=dexX7
export COMMIT=374779dbb677da3f3e62e59143f828364115f16b
export RELEASE=0.0.9.99-374779dbb6

./bin/gbuild --commit omnicore=${COMMIT} ../omnicore/contrib/gitian-descriptors/gitian-win.yml
./bin/gsign --signer $SIGNER --release ${RELEASE}-win --destination ../gitian.sigs/ ../omnicore/contrib/gitian-descriptors/gitian-win.yml
mv build/out/omnicore-*.zip build/out/omnicore-*.exe ../

./bin/gbuild --commit omnicore=${COMMIT} ../omnicore/contrib/gitian-descriptors/gitian-linux.yml
./bin/gsign --signer $SIGNER --release ${RELEASE}-linux --destination ../gitian.sigs/ ../omnicore/contrib/gitian-descriptors/gitian-linux.yml
mv build/out/omnicore-*.tar.gz build/out/src/omnicore-*.tar.gz ../

./bin/gbuild --commit omnicore=${COMMIT} ../omnicore/contrib/gitian-descriptors/gitian-osx.yml
./bin/gsign --signer $SIGNER --release ${RELEASE}-osx-unsigned --destination ../gitian.sigs/ ../omnicore/contrib/gitian-descriptors/gitian-osx.yml
mv build/out/omnicore-*.tar.gz build/out/omnicore-*.dmg ../

I further thought about how to handle gitian.sigs. Please create the pull request, but merge into master, and not into a feature branch. Ultimately, it is going to hold all signatures of previous releases, so it probably makes not so much sense to have a branch for each one.

[zathras-crypto]

I'm in the process of doing these builds btw :)

[dexX7]

Awesome. I'm really curious, if the Windows installer is deterministic now.

[zathras-crypto]

Awesome. I'm really curious, if the Windows installer is deterministic now.

All done. OmniLayer/gitian.sigs#6

[dexX7]

Matches! :)

[zathras-crypto]

Matches! :)

Outstanding!!!! :)

[dexX7]

I'm not sure, how this could be made more handy, but assuming you're still in your build box, then gverify can be used to fully verify, whether the results match:

cd ~/
rm -rf gitian.sigs/
git clone https://github.com/OmniLayer/gitian.sigs.git
gpg --recv-keys 0xA6308A6C5B1E67CC7CF7002FBCC02B71BE91B32B 0xF43718054C3E7C5CFB33E8257675E31CF5719832
./gitian-builder/bin/gverify --destination gitian.sigs/ --release 0.0.9.99-374779dbb6-linux omnicore/contrib/gitian-descriptors/gitian-linux.yml
./gitian-builder/bin/gverify --destination gitian.sigs/ --release 0.0.9.99-374779dbb6-win omnicore/contrib/gitian-descriptors/gitian-win.yml
./gitian-builder/bin/gverify --destination gitian.sigs/ --release 0.0.9.99-374779dbb6-osx-unsigned omnicore/contrib/gitian-descriptors/gitian-osx.yml

It then shows something like:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F437 1805 4C3E 7C5C FB33  E825 7675 E31C F571 9832
dexX7: OK
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: A630 8A6C 5B1E 67CC 7CF7  002F BCC0 2B71 BE91 B32B
zathras: OK

[dexX7]

What happens now? Do you want to push the binaries to the dev list?

[zathras-crypto]

Yep (x64 only to be on the safe side I think?) - probably do that tomorrow unless you have any other catches (which you're killing it with btw much to my thorough happiness!!! so many, many thanks)

[dexX7]

Yup, agreed. Sounds fine! :)

[zathras-crypto]

Maybe we should add a discussion on fees again before the 0.0.10 RC...

Woot my transactions finally confirmed after a week hehe... This is the essence of my concern though (most users will leave "settings" at their defaults, and those defaults can mean confirmation times that would sour the experience). I'm still toying with some local ideas for this, and will suggest a PR when I have something more tangible :)

[zathras-crypto]

Just a thought - zathras-crypto@8c58429

[dexX7]

Just a thought - zathras-crypto/omnicore@8c58429

I love it!

Let's move the discussion to a new thread: #137

[dexX7]

Just to keep gain an overview: we made some significant progress, and especially the checkpoints/block skipping was a valuable addition. The items left of the original plan:

• Documentation for Omni Core specific options #71: Documentation for Omni Core specific options (started, but needs refinement)
• Changelog and release notes for 0.0.10 #96: Changelog and release notes for 0.0.10
• Use notifications to enable features #104: Notification based consensus rule updates (related: Seperate block height restrictions and feature activation #116, Implement and switch to Feature-Activation-By-Message #129)
• Bump Omni Core version to RC1 #117: Bump Omni Core version to RC1 (low hanging)

[dexX7]

Soo.. it looks like only the documentation and change log is missing for the release?

I'm sure you'll object, and there are other items. It would be great to list them here. It was mentioned that the raw transaction creation should be part of 0.0.10, and the "send all" transaction also. Does this still apply?

[zathras-crypto]

t was mentioned that the raw transaction creation should be part of 0.0.10

I believe this is desired, I need to loop around and see where we're at with this and review notes from Josh (escrowmybits)

and the "send all" transaction also.

Also desired, given that the implementation is pretty close if we can finalize the spec issues I think we could fit this in...

It would be great to list them here

• I'd like to see confirmed TMSC/TMSAFE3 DEx exchange still showing unconfirmed in UI #154 resolved
• I'd like to redo alerting in the context of standardized payloads and combining feature activation notifications with alerting to some degree - I have some thoughts here and will submit some code when back home in two days
• I'm going to raise MetaDEx testing at the meeting again in the morning, since the preview builds were released there have been only 3 test ecosystem & 5 testnet trade transactions. I intend to raise the issue of how to motivate for more testing to improve confidence prior to release

I'm sure I probably have a couple of other points but it's a bit late and I'm a bit fuzzy so I'll leave it there hehe :)

[dexX7]

Alright. I think we should add:

• Deactivate side effects of granting tokens: Deactivate side effects of granting tokens #157
• Change the DEx payment processing rules: Seperate logic from plain transaction parsing #158 (comment)

Any comment on the last point?

[dexX7]

From the log of the meeting:

I want us to have a public release candidate build by this meeting next week.

@CraigSellars: can you quickly address the last four comments?

[dexX7]

Given that the usefulness of this issue is limited now, and it overlaps with #182, I'm going to close it.

Please also, and especially, see #194.