Chancecoin / Ultra cheap transaction costs

[de...@bitwatch.co]

Hey all,

there was some discussion on GitHub related to OP_RETURN and transaction
costs. One point that was raised was the cost associated with output
amounts. While what has been said holds true, there are actually a few
options to save costs.

I'd like to share, and try.., a new "format":

http://i.imgur.com/hiZFZa7.png (overview)


Chancecoin demonstrated with several thousand transactions that both
output amounts as well as transaction costs can be cut significantly
without adopting a new encoding scheme, but simply by reducing output
amounts and fees.

I tracked over 2'100 transactions from broadcast to confirmation and
mapped most blocks to mining pools. It turns out that transactions with
output amounts as low as 0.00000780 BTC and transaction fees of 0.00001
BTC confirm within about 20 minutes on average while 85 %+ pools (in
terms of hash power/total network) are mining those transactions. This
includes GHash as well as DiscusFish.

The actual data can be found here:

https://docs.google.com/spreadsheets/d/1ELqeBlKKsze6Tya-Arh6HfoFcnV5CAtAObmhEb_wmSM/


TL;TR + conclusion:

Given that at least 75 % of all nodes are using Bitcoin Core v0.9+ and
about 85 % pools confirm ultra cheap transactions in general, I think
it's time to step back from the old "0.00006 BTC/packet rule" and adopt
output amounts of 0.00000546-0.00000882 BTC which are defacto default
and standard since Bitcoin core v0.9.

Furthermore it might be worth a try to cut down transaction fees from
0.0001 BTC/1000 byte to 0.00001 BTC/1000 byte transaciton size, given
the reasonable confirmation delay of about 20 minutes. The later should
not be enforced, but could be offered as an experimental option for
users who may choose cost savings over confirmation speed.


Cheers!




Previous discussions and further reading about this topic:

https://groups.google.com/a/mastercoin.org/d/msg/dev/w7WD3-pwXxg/9wyk22PP55kJ
(experiment with 250 transactions)

https://github.com/mastercoin-MSC/spec/issues/167#issuecomment-43417733
(initial post about low output amounts)

https://getaddr.bitnodes.io/dashboard/#user-agents (Bitcoin Core client
usage overview)

http://bitcoincore.org/smartfee/ (Gavin's smart fee estimates)

https://www.blocktrail.com/ (block explorer - unofficial API endpoint
/json/blockchain/block/:hash slowes down after a few hundred queries,
but remains very usable -- my favorite of the day! Just a matter of time
until all Exodus transactions are linked to blocks/pools.. :)

[zathras crypto]

Great work as always mate, thank you.

I support this, I think we should work to provide users the option of having a low fee with potentially longer confirmation time, and a 'traditional' fee with potentially faster confirmation time, then let the user community feed back to us on what should be the default.

@Michael @Faiz, thoughts?

Thanks

Z

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@mastercoin.org.

[Shannon Code]

What if we had an optional alternative tx encoding / decoding option and tested it out on omni. I'm not sure if if we be able to do this without updating core, tools and any other implementations. 

Would lowering fees create invalid transactions. 

A significant per tx lowering in cost is great press.

[Shannon Code]

Well that last email I wrote read just about how I'm feeling. :)

[Faiz Khan]

I think that in general while we pay more, we should support the lower fee transactions as a feature ('deprioritized transactions') but as a standard I can't advocate it since the average of 20-30minutes is about the time it takes a normal transaction to attain 2-3 confirms. 

That means there is certainly some value in keeping the current scheme, while still allowing the option to exist for users who don't mind waiting the extra 20 minutes (and saving a few cents). However, chasing and optimizing fee amounts is a moving target, so I also am not sure how much emphasis the feature would have on the main development roadmap. 

That said, I think nobody would reject a patch to the spec/ref to allow Chancecoin's low-priority multisig sends :)

[Marv Schneider]

I agree with Zathras. If it's reasonable to offer users this choice, we should give it serious consideration.

--

Marv Schneider

Mastercoin Foundation

mastercoin.org    |   ma...@mastercoin.org

[Adam Chamely]

Amazing detail and research into this Dexx,  I don't see any reason we couldn't include this as an option when sending regular style transactions. 

Adam Chamely

Mastercoin Foundation

mastercoin.org    |   ad...@mastercoin.org

Schedule my time at http://meetme.so/AdamChamely 

[de...@bitwatch.co]

Just to be clear, there are two seperated tweaking points:

1. Output amounts:
Can be dropped to 0.00000546 BTC (pay-to-pubkey-hash) - 0.00000882 BTC
(multisig, worst case: one uncompressed, two compressed public keys) --
this *should* be safe and *probably* delay free, because those numbers
are live since November 2013.

2. Transaction fees:
Lower fees come very likely at the cost of a delayed confirmation - at
least to some degree and probably more notable in times of high overall
number of transactions. Cost vs. speed, that's pretty much it.

CHA reduced output amounts as well as fees. I'm unsure, if a sample size
of 2.1k is sufficient, but you're right. Those 20 min on average equal
roughly 2.5 confirmations. Unanswered (at least for me): is a fee of
0.0001 sufficient to push the average down by 2.5x? I'm really unsure.
Anyway, I rather think of this as something experimental for cost savers.

---

In the context of Mastercore:

Transaction fees are inherited from Core and can be set right now:

1. Start with parameter "-mintxfee=0.00001" or bitcoin.conf entry
"mintxfee=0.00001" (as example, default is "mintxfee=0.0001") - this
defines the allowed minimum fee per 1000 byte.

2. The actual fee is then set via RPC "settxfee 0.00001" (or some other
amount which is larger or equal than the "mintxfee").

The fee can be changed on the fly via "settxfee", as long as the
"mintxfee" level allows the fee. (e.g. "settxfee 0.00001, send_MP ...,
settxfee 0.0001, send_MP ..., ...)

---

Output amounts, dust threshold and the "minrelayfee" are bound, more or
less - in the sense that the minrelayfee is used as basis to determine,
if an output amount is too low, and as consequence, a transaction
considered as dust. (see: core.h IsDust(nMinRelayTxFee))

Currently a magic number is used to set a fixed output amount, but
adjusting those numbers indirectly via the relayfee seems actually
reasonable in my opinion, since those numbers are bound anyway. I
actually pushed a commit once (PR #66) to accomplish this and replaced
it by an up-to-date version (PR #110) a few minutes ago -- for the case
you want to give it a try. Slightly increasing the default relayfee may
serve the purpose as marker as wlel, since this results in sligthly
different output amounts.

Out of the box simple send without touching the config (defaults to
txfee = 0.0001, relayfee = 0.00001001):

http://tbtc.blockr.io/tx/info/0ea9296fd75c03ad4e1f3031a2e20e9a5a3a44fb7d6635fd3156fe86c29b9c88


Cheers

> <mailto:de...@bitwatch.co> <de...@bitwatch.co

> <mailto:dev%2Bunsu...@mastercoin.org>.

>
>
> To unsubscribe from this group and stop receiving emails from
> it, send an email to dev+uns...@mastercoin.org

> <mailto:dev+uns...@mastercoin.org>.

>
>
> To unsubscribe from this group and stop receiving emails from it,
> send an email to dev+uns...@mastercoin.org

> <mailto:dev+uns...@mastercoin.org>.

>
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to dev+uns...@mastercoin.org

> <mailto:dev+uns...@mastercoin.org>.

[Ron Gross]

dexx, as always - you're amazing.

I think this should be the default.

People should have the option to opt-out of this and pay extra fees for faster confirms, but most everyone should get this behavior out of the box.

I think I'd make these changes:

1. MasterCore uses the new lower fee structure by default, and have a per-transaction flag in the RPC interface to set the fee to be higher current amounts.

2. Omniwallet uses the new lower fee structure by default. It should have a global per-user setting where a user can opt into 'always use higher fees' (needs better wording than this).

3. Optional - Where applicable and the UI makes sense, Omniwallet can then offer an option to pay higher fees per transaction without going into the settings menu. This is like blockchain.info has the custom send option today. However it's more work in Omni because we have several different types of transaction, so for simplicity I would not implement this right now and just do #1 and #2, saving the per-tx fee option in the backlog.

[David Johnston]

Dexx,

Great stuff my friend. Definitely looking forward to this update and reduction in costs for the Master Protocol clients.

Best Regards,

David A. Johnston

[Zathras Crypto]

Hey DexX,

Just wanted to keep you in the loop mate, we're all pretty positive about this, however the queue for next tag in 11 days is already pretty stiff (we have manual issuances and P2SH support among others).  We have discussed looking at this for the tag following next so we can give it our full attention - it's really valuable stuff & just didn't want you to think your work was wasted if you didn't hear anything for a few days.

Thanks

Z

[Shannon Code]

btw: [1:47:30 AM] taariq lewis: dexx7 has done excellent work analyzing Counterparty & Mastercoin transactions. He's maybe one of the best blockchain scientists out there. And he does it for fun. Pure amazing.

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@mastercoin.org.

[Ron Gross]

Indeed!

[Marv Schneider]

With the drop in transaction costs, do we need to revisit/rethink any past spec decisions? For instance, I think some assumptions were made that the then current costs would inhibit people from bloating the blockchain with spam transactions, e.g. creating nuisance smart properties. We may need a more deliberate approach going forward.

[Ron Gross]

I don't see blockchain spam as a problem.

Gavin said that "if users clamor for better support for including custom data in the blockchain, they will consider it".

Let this become a real problem, and as a result we might get more bytes in OP_RETURN.

Ron Gross

mastercoin.org   |   ripper234.com   |   ripper234 on skype (Inbox != Zero) | PGP

Schedule my time at meetme.so/RonGross
Chief Ninja Officer

[Marv Schneider]

It may not be a problem - I don't know. My more general objective is to ensure we actively consider potential unintended consequences when we make changes, especially changes that appear to have no obvious downside.

Marv Schneider

VP, User Experience/Product Usability

Engine, Inc.

ma...@engine.co

[Ron Gross]

+1

Ron Gross

mastercoin.org   |   ripper234.com   |   ripper234 on skype (Inbox != Zero) | PGP

Schedule my time at meetme.so/RonGross
Chief Ninja Officer

[Randy Brito]

Don't you mean 0.00005640 BTC?

[de...@bitwatch.co]

Sorry, in which context? If you think I'm off by a factor of 10x - I'm
not. :)

I mentioned 0.00000564-0.00000882 BTC (5 zeros or 546-882 Satoshi),
e.g.:
https://blockchain.info/tx/294c48b76ec419cea34e1b404d2dafe62da52f4304d0cc6169e2d85d2c940ea4

Here is a bit of further detail about where these numbers are coming
from:
https://github.com/mastercoin-MSC/mastercore/pull/110#issuecomment-54386076

[Shannon Code]

Wait, this tx only cost 

Estimated BTC Transacted	0.00000546 BTC

If this is infact the case, guys we have one of the largest announcements of the year.