Find a clever trick to lower the cost of transactions
ripper234 opened this issue · 24 comments
I really don't know whether it's possible and how so ... but transaction cost on the Master Protocol is too high.
We are doing some things to alleviate that, e.g. redeeming outputs in Omni. The question is - is that enough, and what more can we do.
Is it time to accelerate research into cross-chain Mastercoins?
Should we push harder to lobby class C tx AKA OP_RETURN?
Should we revert to using class A? (No ... it doesn't really solve anything).
Redeeming outputs is the low-hanging fruit. Also, I recall seeing someone did a test where they tried lowering the outputs per address, and they still got relayed fine (despite being under the dust threshold). Be interesting to know if that is something we can depend on.
That was me. And FYI: the dust threshold was moved 10x.
At the current stage those transactions take significantly longer to confirm, so I'd suggest to not recommend them right now. There are still some Satoshi that might be saved nevertheless -- zathras uses 6000 Satoshi where 5460 are fine etc.
+1 DexXs comments - TXs can be pushed now with much lower outputs but have
extended confirmation times.
Also FYI DexX we kind of have a gentleman's agreement at the mo with
outputs (we all use unique values per codebase) as it allows us to
determine which implementation sent a transaction. Core is set at 5678 ATM.
Thanks
Zathras
On Jun 6, 2014 9:26 PM, "dexX7" notifications@github.com wrote:
That was me. And FYI: the dust threshold was moved 10x.
#167 (comment)
#167 (comment)At the current stage those transactions take significantly longer to
confirm, so I'd suggest to not recommend them right now. There are still
some Satoshi that might be saved nevertheless -- zathras uses 6000 Satoshi
where 5460 are fine etc.—
Reply to this email directly or view it on GitHub
#192 (comment).
Haha fine! :) Did you read the other part related to mutlisig outputs? They are currently being overpaid greatly and I suggest to use the higher number of 0.0000882 + x (for tagging) to skip the step of determining, if uncompressed keys were used. 8820 (resp. 882 in 0.9x) Satoshi is enough for one uncompressed and two compressed public keys in an OP_MULTISIG output.
Indeed I did and you're quite correct :)
The send_MP code is pretty fresh/raw in Core and currently utilizes the
same values across all outputs (including the multisigs for data packets)
but this will obviously be adjusted as we move ahead. I'd like to see us
take into account input age as well since that impacts on priority (and
thus confirmation times).
// the min amount to send to marker, reference, data outputs, used in
send_MP() & related functions
#define MP_DUST_LIMIT 5678
Thanks!
Zathras
On Fri, Jun 6, 2014 at 9:39 PM, dexX7 notifications@github.com wrote:
Haha fine! :) Did you read the other part related to mutlisig outputs?
They are currently being overpaid greatly and I suggest to use the higher
number of 0.0000882 + x (for tagging) to skip the step of determining, if
uncompressed keys were used. 8820 (resp. 882 in 0.9x) Satoshi is enough for
one uncompressed and two compressed public keys in an OP_MULTISIG output.—
Reply to this email directly or view it on GitHub
#192 (comment).
From a coder's perspective the easiest way would probably be to write one "get fee" method. Well anyway, just mentioned it, because those are the low hanging fruits - I'm sure you are doing great stuff nevertheless. :)
Ah credit where credit is due, this is all Michael's handiwork, he's been
killing it for us recently :)
Thanks
Zathras
On Jun 6, 2014 9:54 PM, "dexX7" notifications@github.com wrote:
From a coder's perspective the easiest way would probably be to write one
"get fee" method. Well anyway, just mentioned it, because those are the low
hanging fruits - I'm sure you are doing great stuff nevertheless. :)—
Reply to this email directly or view it on GitHub
#192 (comment).
did they pay the mining fee? this ought to be an option that will gain
favor with the miners
The fee and minimum output values are two seperate constructs and currently a min. fee of 0.0001 BTC/1000 byte is still required.
ah ok i thought the fee was optional
in any case people with high value, time sensitive tx may wish to provide
for a higher fee
Thanks,
Dominik Zynis
Skype: dominik.zynis
USA: +1-415-800-4155
dominik.zynis@gmail.com
On Fri, Jun 6, 2014 at 2:08 PM, dexX7 notifications@github.com wrote:
The fee and minimum output values are two seperate constructs and
currently a min. fee of 0.0001 BTC/1000 byte is still required.—
Reply to this email directly or view it on GitHub
#192 (comment).
On topic: ways to reduce transaction costs:
- Change the transaction identifier. Instead of using an output to Exodus, OP_RETURN could be used with some magic word.
- Get rid of receiver references and move the recipient into the data package, see: #62
Both changes are significant changes.
Is it time to accelerate research into cross-chain Mastercoins?
Needs to be an all or nothing thing unfortunately, and all the chains have security issues.
Should we push harder to lobby class C tx AKA OP_RETURN?
Working on it! I'll have a "IsSoftforkSafe()" branch soon that replaces IsStandard() and lets people do what they want.
That was me. And FYI: the dust threshold was moved 10x.
Yes, but very few miners upgraded to 0.9 OTOH some of the big mining pools were ignoring the dust limit before; not sure if they still do that. Worth an experiment.
Change the transaction identifier. Instead of using an output to Exodus, OP_RETURN could be used with some magic word.
Good idea. Also, if you do that, best to make the "is a mastercoin tx" output a probabilistic match, rather than exact, so blocking Mastercoin means blocking others as well.
Yes, but very few miners upgraded to 0.9 ...
I switched to those values for all Mastercoin faucet transactions to observe the behavior of the network. My current impression is that such transactions are relayed quickly, whereby I only have the view of four nodes, but confirmation takes significantly longer. It's difficult to tell exact durations, but an estimate: about, but less than four hours. If there is a handy way to map mined blocks to mining pools, I may create an overview of which pool does mine those transactions.
Good idea.
The downside of this is that it may be more difficult to track Mastercoin transactions - at least for some implementations which rely on third party APIs such as blockchain.info and to my knowledge this also affects sx and therefore mastercoin tools. ("gethistory" lists pay-to-pubkey-hash transactions associated with the lookup address afaik)
And see this $5000 + $50,000 bounty as well.
Heh, sounds like I should implement tree chains. :)
Hate to say it though, but the bounty is underspecified as is - there's no proper definition of what security guarantees the solution needs to provide.
Care to write a reply to that bounty? I'll be happy to deliver that to the Aleph team.
Yeah, it would be sweet to see you take that prize money!
Just so we're clear, you did see Aleph's $50K USD bounty, right? I updated the wording above to reflect that.
Sure did! All the more reason yo make sure the specs are so solid only I can win, er, I mean they're not wasting their money on a insecure solution. ;)
I'll do up a writeup after I redo my one on whether or not MSC should move to a txout system.
Looking forward to it!
I'm all for both security and you winning, it's a win-win scenario.
I'm not sure if this has been suggested before, but it just clicked for me.
In Class B transactions we must include outputs for:
- Exodus address
- Reference address
- Multisig data output
as well as include the miners fee. If the intended recipient provided a public key instead of an address we'd be able to designate that public key as the 1-of-n public keys that can redeem the multisig UXTO. By doing this we can combine the reference address output with the multisig data output and reduce the cost of a Class B Master Protocol transaction by 0.00006 BTC (from 0.00034 BTC to 0.00028 BTC). Besides reducing the cost, it also has the effect that Master Protocol transactions create fewer dust UXTOs. This would also be a pretty neat area to utilize stealth addresses...
Also, if the Master Protocol does choose to transition to an output model, the cost of a Master Protocol transaction could be decreased by an additional 0.00006 BTC by removing the requirement that Master Protocol transactions have an output to the Exodus address (from 0.00034 BTC to 0.00022 BTC).
Note: I these values are pulled from the spec as it is currently - I know there is a pending pull request to update those values.
Another thought on decreasing Master Protocol transaction costs under an output model:
If the sender and the owner of the reference address can come to consensus on a redeem script off chain, the cost of a Master Protocol transaction can be reduced to 0.00016 BTC (0.0001 BTC for miner's fee plus 0.00006 BTC to the P2SH address.)
Kind of an exciting prospect considering that that is the smallest amount that one can spend in any Bitcoin transaction and still expect quick confirmation. It also sets the stage for a very elegant way to send tokens to multiple recipients in a single bitcoin transaction. Of course there are catches to this idea, however it's still probably worth exploring further.
Interesting idea actually. I once suggested to include recipients in the data payload with the intention of laying out a structure for multisends.
It may also be thinkable to use the Exodus address as first multisig recipient or use the slot to send BTC change - somewhat related: a Chancecoin transaction, but this introduces complications related to the identification, because it's easier to track "standard outputs". This is what JR said in this context, too:
The recipient gets a ping when somebody sends them money, even if they are only using a standard bitcoin wallet