New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove release canidate status #304

Closed
dexX7 opened this Issue Dec 5, 2015 · 15 comments

Comments

Projects
None yet
2 participants
@dexX7
Copy link
Member

dexX7 commented Dec 5, 2015

In the past we've used the suffix -rel for releases, e.g. 0.0.9-rel.

Now with 0.0.10 on it's way, and currently 0.0.10.0-rc3, I'm wondering, whether we should use:

  1. 0.0.10.0-rel
  2. 0.0.10-rel
  3. 0.0.10.0
  4. 0.0.10

Simply updating rc3 to rel (similar to #286) would result in the first. I tend to use 0.0.10 or 0.0.10.0, but this needs some tweaking of the setup/resource files etc., because it uses something like:

STRINGIZE(OMNICORE_VERSION_MILESTONE) "." STRINGIZE(OMNICORE_VERSION_MAJOR) "." STRINGIZE(OMNICORE_VERSION_MINOR) "." STRINGIZE(OMNICORE_VERSION_PATCH) "-" STRINGIZE(OMNICORE_VERSION_STATUS)

And configure.ac:

AC_INIT([Omni Core],[_OMNICORE_VERSION_MILESTONE._OMNICORE_VERSION_MAJOR._OMNICORE_VERSION_MINOR._OMNICORE_VERSION_PATCH-_OMNICORE_VERSION_STATUS],[https://github.com/OmniLayer/omnicore/issues],[omnicore],[http://www.omnilayer.org/])

It's a bit unforseeable, whether we can get away with removing the last parts, and I'd give it a test tomorrow, but first, let's decide if this is the way to go at all. :)

@dexX7 dexX7 added the release label Dec 5, 2015

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

On a related note: we should probably also add to the release notes that - at least in default mode - transaction fees are estimated based on historical blocks. There are a few transactions out there, which seem to be created by one of the release candidates, and the fees are crazy high, likely due to the fee estimation, instead of fixed fee/1000 byte).

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

To be honest I'm happy with any, though 0.0.10.0-rel is a slight preference and does seem the easiest to deliver.

Regarding the fees - I did see your other issue and meant to comment - I run with confirmation estimation - to confirm within 15 blocks which is about 13000 satoshis per KB, and my transactions usually end up somewhere in the 3500-4000 satoshi range for mining fees.

The example you posted had a fair number of inputs pushing up the size to a touch over a KB which is probably a bit larger than most Omni transactions.

Agree we definitely want the user base to be informed of this, but we also don't want to give the impression that Omni transactions cost massively more with this new version or people might be encouraged to use an older one (even though it'd risk being out of consensus later on).

That's kind of why I was keen on doing Class C soon, so our transactions are smaller and have less outputs, which helps to arrest the increase in dust thresholds and the switch to fee estimation.

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

To be honest I'm happy with any, though 0.0.10.0-rel is a slight preference and does seem the easiest to deliver.

Sure, sounds good to me!

Agree we definitely want the user base to be informed of this, but we also don't want to give the impression that Omni transactions cost massively more with this new version or people might be encouraged to use an older one (even though it'd risk being out of consensus later on).

This is my primary concern actually: 5x dust value, and pretty high transaction fees per default. I think the best course would be to outline the options, and highlight the new default. Then it's up to each user, and "it's no longer our responsibility".

On top, it's also thinkable to change the default to something less extreme. Bitcoin Core actually updated the confirm target from 1 to 2 in 0.11 (bitcoin@77ed59d + bitcoin@2457dc4), which we could adopt.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

I think it's probably a good idea to adopt our own defaults that are less 'extreme' but also we need to be cautious about going too far, as while 0.0.9 txs are cheaper, they're also taking forever to mine in some cases so we'll probably want to find a suitable middle ground...

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

Agreed. It wouldn't be our own default though, but the default of 0.11.

So to summarize:

  • adopt confirm target = 2 (yes? no?)
  • add notes for default fee estimation
  • update change log
  • bump version to 0.0.10.0-rel
  • tag release

I'm going to tackle this later/tomorrow, so we have Sunday and Monday to build and publish the binaries.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

Sure I guess what I meant was that we have the potential option of choosing our own defaults if we want to.

In a nutshell, we have differing utilizations of the network, and thus the defaults for Bitcoin Core may not be appropriate for Omni Core. We have the issue of priority (size & age) since our inputs are inherently small and usually quite new (since we send change back to sender, that's commonly the input that's used for the next transaction). I've been meaning to try and test out whether this factors into the fee estimation process (eg are our transactions skewed from this?) but mainly:

adopt confirm target = 2 (yes? no?)

This is my concern with a confirm target of 2:
screenshot from 2015-12-05 13 18 57

50,000 satoshis per KB.

FYI I use a confirm target of 15 and I get very quick confirmations just fine.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

FYI my last 20 transaction fees with estimate to confirm at 15 blocks (usually mines next block):

zathras@zathras-desktop:~/github/build/omnicore$ src/omnicore-cli omni_listtransactions "*" 20 | grep \"fee\"
        "fee" : "0.00003737",
        "fee" : "0.00003749",
        "fee" : "0.00003749",
        "fee" : "0.00003746",
        "fee" : "0.00003754",
        "fee" : "0.00003754",
        "fee" : "0.00003754",
        "fee" : "0.00003737",
        "fee" : "0.00004166",
        "fee" : "0.00004166",
        "fee" : "0.00004166",
        "fee" : "0.00004166",
        "fee" : "0.00003749",
        "fee" : "0.00003737",
        "fee" : "0.00003749",
        "fee" : "0.00003737",
        "fee" : "0.00003749",
        "fee" : "0.00003749",
        "fee" : "0.00003749",
        "fee" : "0.00003749",

I just sent one at estimated to confirm within 2 blocks and

        "fee" : "0.00017000",

Thus I'm thinking it might be appropriate to choose our own :)

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

Ah, very good points actually.

Which value would you suggest?

FYI I use a confirm target of 15 and I get very quick confirmations just fine.

Haha yeah, I have the impression the confirm target is pretty off. And also to note, it looks like the fee estimation in Core master is completely different:

bitcoin@Ubuntu-1404-trusty-64-minimal:~$ bitcoin-cli estimatefee 2
0.00029328
bitcoin@Ubuntu-1404-trusty-64-minimal:~$ bitcoin-cli estimatefee 10
0.00019924
bitcoin@Ubuntu-1404-trusty-64-minimal:~$ bitcoin-cli estimatefee 25
0.00011031
@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

I've found differing results even for the same build - take my desktop against OmniChest for example - I know the platforms are different (Linux vs Windows) but that shouldn't affect the math which I thought was based on data from previous blocks, but if that were the case the values should be equal:

estimatefee 1
0.00117370

estimatefee 2
0.00050000

estimatefee 3
0.00044444
c:\Program Files\Omni Core\daemon>omnicore-cli.exe estimatefee 1
0.00072306

c:\Program Files\Omni Core\daemon>omnicore-cli.exe estimatefee 2
0.00044843

c:\Program Files\Omni Core\daemon>omnicore-cli.exe estimatefee 3
0.00041322

Which leads me to think that some other additional factor is part of the calculation other than just previous block data...

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

Interesting. Are both nodes up to date? Were they running all the time?

What do you think about a confirm target of 6? Should be somewhere in the middle, and it doesn't sound too extreme imho (in contrast to 15 for example - even if it works).


Transaction fee changes

Starting with Bitcoin Core 0.10, transaction fees, as per default, are no longer hardcoded, but estimated based on previous blocks.

This behavior can result in significantly different fees compared to Master Core 0.0.9, and manual tweaking is recommended, if the default fee estimation doesn't yield satisfying results.

The following fee related configuration options are available:

  • txconfirmtarget=<n>: create transactions that have enough fees (or priority) so they are likely to begin confirmation within n blocks (default: 6). This setting is overridden by the paytxfee option.
  • paytxfee=<amount>: fee (in BTC/kB) to add to transactions you send.
  • sendfreetransactions=0|1: send transactions as zero-fee transactions if possible (default: 0).

New RPC commands for fee estimation:

  • estimatefee nblocks: returns approximate fee-per-1,000-bytes needed for a transaction to begin confirmation within nblocks. Returns -1 if not enough transactions have been observed to compute an estimate.
  • estimatepriority nblocks: returns approximate priority needed for a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not enough free transactions have been observed to compute an estimate.

Please note, the fee estimation is not necessarily accurate.


@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

Interesting. Are both nodes up to date? Were they running all the time?

Yes & Yes. There are two potential avenues for the difference I can see:

  1. My local node sends Omni transactions (Chest sends none) and metrics from sent transactions play a part in the calculation
  2. Data from the mempool plays a part in the calculation (as this is likely to differ between nodes)

I don't know which (if either) is in play.

I saw your PR to default to 6 blocks, but I'm still not so sure - Chest says 36000 satoshis/KB and my local node says 27000 satoshis/KB for 6, let's take a rough average at say 32000 satoshis/KB and it still seems a bit higher than necessary IMO.

The average across all Omni transactions ever sent is a transaction size of 454 bytes, let's call it half a KB for good measure. So 6 blocks is, for an average transaction, about 16000 satoshis, or 0.00016 BTC.

When considered in the context of the "0.0001 default fee" from Bitcoin days past then 0.00016 doesn't look too bad I guess, but I guess I'm having a hard time getting behind the new 6 block default because I'm pushing half KB transactions around without delay for 3 or 4 thousand satoshis, so it seems wasteful to default at roughly 16 thousand satoshis. But this is just personal experience.

It's hard because there are no explicit values here, it's all implied but I tend to err on the side of going a touch over the old-skool default 10,000 satoshis per KB (eg say 12,000 satoshis per KB) - it's enough to get transactions mined in a timely manner and not break the bank.

I'm really not sure I have that much faith in this estimation code as is anyway - for example I would expect more than a <1% spread for basically doubling the confirm target:

09:17:22
estimatefee 6

09:17:22
0.00026881

09:17:23
estimatefee 7

09:17:23
0.00026809

09:17:24
estimatefee 8

09:17:24
0.00026809

09:17:25
estimatefee 9

09:17:25
0.00026809

09:17:27
estimatefee 10

09:17:27
0.00026737

We could always default to an explicit satoshi/KB value rather than per block estimation? If that's something we would consider then I'd vote for a touch over 0.0001/KB, say 0.00012/KB or 0.00013/KB.

Just thinking out loud here bud...

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 5, 2015

Oh and sorry, forgot to mention - the transaction fee changes doc looks fantastic, thanks for putting it together dude :)

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 5, 2015

I'd be fine with other values as well, though my concern would be to underestimate the situation. E.g.: I could imagine blocks get full rather sooner than later, and then we could end up in a bad situation. Furthermore, with class C, we have some more room.

I'm not really sure where to go from here, or let me rephrase: I'm not sure how we can determine a good value. It's just "guessing" right now, at least that's my impression, and I tend to pick a more conservative number (i.e. confirm target closer to 1).

I'm really not sure I have that much faith in this estimation code as is anyway - for example I would expect more than a <1% spread for basically doubling the confirm target

Yeah, these are some really unexpected results.

Here is another source, which I saw a few times on reddit: https://bitcoinfees.github.io/. This doesn't help in the context of picking a magic confirm target, but just to get a better feeling for it.

@zathras-crypto

This comment has been minimized.

Copy link

zathras-crypto commented Dec 6, 2015

Well, I guess the question is do we want a default confirm target or a default fee?

I'd be fine with other values as well, though my concern would be to underestimate the situation.

Yeah I agree we wouldn't want to underestimate. I can't really suggest an accurate alternate value for confirm target because for example pushing from 6 to 11 seems to make just a few satoshis difference, but pushing from 11 to 12 makes over 6,000 satoshi difference so it's as you say pure guesswork and extremely non-linear; seems like confirm targets of 6 or 12+ are our options if intermediate values make no difference (purely inferring from my results so far)...

I don't want to drag this out too much hehe, put it this way - a confirm target of 6 is much better than the default of 2 (or 1) so I support your PR, my only question was really whether the change goes far enough to reduce fees as much as possible but since it seems evident we'd need to go to a target of 12+ to make any real difference I'm happy to merge as is mate :)

@dexX7

This comment has been minimized.

Copy link
Member

dexX7 commented Dec 6, 2015

Well, I guess the question is do we want a default confirm target or a default fee?

Even if it's still not perfect (current master is probably better), I think the future holds floating fees.

I don't want to drag this out too much hehe, put it this way - a confirm target of 6 is much better than the default of 2 (or 1) so I support your PR, my only question was really whether the change goes far enough to reduce fees as much as possible but since it seems evident we'd need to go to a target of 12+ to make any real difference I'm happy to merge as is mate :)

Alright, sounds good to me. 12 seems already "extreme", so I'm fine with this decision. In any case, if we notice the fees are still too high (or low) and transactions confirm nevertheless fast (or slow), we can also send out an announcement.

@dexX7 dexX7 closed this in #306 Dec 6, 2015

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