You can't.

To be exact, once a transaction output is created, spending it under any circumstance will take some amount of data, about ~130 bytes IIRC. Fees for transactions are paid per byte of data; it has nothing to do with how much the transaction is worth for the most part. (some miners will mine high-value transactions for free, but there is a lot of demand for those "freebies", and miners lose a small amount of money by doing this)

What you need to do is stop making so many transaction outputs. You should be charging the fees for each withdraw or deposit separately, or just give your customers minimum withdraw and deposit amounts.

You can also use an off-chain transaction service like inputs.io to skip blockchain fees entirely.

Huh?

There are two main ways of making provable sacrifices that make sense:

1) Create a txout with a scriptPubKey that can't be spent that has a non-zero value.

2) Use the the announce/commit sacrifice protocol to ensure all miners have an equal chance.

2.1) Create a anyone-can-spend coinbase txout. (can't be spent for 100 blocks, so again, all miners have an equal chance)

2.2) In the future add an OP_VERIFY_LOCKTIME or similar to make a specific txout unspendable for some amount of time.


That miners can mine their own fee sacrifices makes the whole fee sacrifice thing a horrible, horrible idea and a complete non-starter. It'd dead easy to round up enough mining power to create any single-tx fee sacrifice you want in a reasonable amount of time, and of course you can always turn that into a service. No-one who knew what they were talking about was seriously proposing that idea.

As for #1: it's dead easy to create all kinds of scriptPubKeys that you can prove can never be spent. Previously people thought UTXO bloat was an issue, but right now I'm quite convinced UTXO size isn't a big deal due to TXO commitments. (though having invented them, I might be a bit biased!)

Annoyingly only 80 bytes are allowed in a standard OP_RETURN <data> txout, which makes announce/commit sacrifices hard to pull off, but then again they aren't as trustworthy as spend-to-unspendable - for now I don't think we want to use them. Better to eventually add OP_VERIFY_LOCKTIME and lock the coins involved for fairly long amounts of time, months to years.

Real-world example: piuk told me that blockchain.info was moving to CoinJoin transactions for their send-shared service so that there would be transactions in the blockchain that could be used to help stop people from fraudulently claiming the service never forwarded their coins. (they don't keep any logs after all)

With the payment protocol they could have just gave the customer a signed receipt.

Please go and implement the code to turn the blockchain into a certificate authority, get Bitcoin-using businesses and people to use it as their primary identity, the one users use to also secure all other communications with those businesses and people, and get back to us so we can add it to the payment protocol specification.

Of course, that's already been done, Namecoin, but no-one uses it.

There's plenty of very intelligent people working on understanding and improving Bitcoin's core technologies and resistance to attack. What we're lacking most is people doing the ugly and boring work, and the payment protocol definitely fits that description. Heck for me personally even testing and auditing, at least for cool stuff like security and consensus threatening bugs, is way more interesting than the payment protocol.

Anyway, Bitcoin is brand new computer science and cryptography and you really don't want a single person being "assigned" to hardening it and refining the design of it. No one person is smart enough or has the breadth of experience to do that, but from the sounds of it the Foundation doesn't have the money to hire the teams of researchers that you'd really need. So they're doing a good job focusing their efforts on what they can do, and letting the community handle the rest.

It's not very well thought out.

The main problem is it calculates fees based purely on blockchain data, so if miners ever accept transactions for reasons other than fees, or because of some contract to mine transactions for someone else, the estimates get pushed down and your transactions will get stuck. If a transaction does get stuck, there's nothing you can do about it other than wait - no different from now.

There are already miners with such contracts, Eligius for example, and the practice is likely to become more widespread in the future because the payment protocol is designed to allow the shifting of the burden of mining a transaction to the merchant. The only way the merchant can get a transaction confirmed if the customer put a too-low fee is to either respend it, making use of Luke-Jr's child-pays-for-parent code, (not yet included in the reference client) or by using a out-of-band transaction mining contract. The latter is cheaper because you don't have to pay for a wasteful second transaction.

The other issue is that fee estimation can only be done by full clients; the SPV clients that more and more people are using don't have the blockchain data or mempool so they can't make good fee estimates. Gavin's solution is to make full nodes provide SPV clients with estimation services, but there's no way for the client to know if the node is lying - it gives miners incentives to setup lots of nodes that lie about fees, saying they are higher than they really are, or griefers incentives to do the opposite and get people's transactions stuck. Bitcoin is supposed to be as zero-trust as possible...


There are better solutions, the main one is transaction replacement. Basically if your first transaction isn't getting mined, you broadcast a second one that spends at least one of the same inputs (so both can't be mined at once) and pays every output that the first did, plus another change output. (so zeroconf transactions are still "safe") This would work best if combined with proof-of-propagation, which gives you cryptographic proof that your transaction actually got to miners, although that doesn't have to be implemented immediately.

The main disadvantage with transaction replacement is that it will confuse some wallet software, but that same wallet software can get confused by accidental double-spends, transaction malleability, etc. We're better off if people in the ecosystem write robust software frankly rather than making assumptions that aren't actually true.

Interestingly part of Gavins proposal is to make transactions expire from mempool's relatively quickly, and in that case then yeah, just like in replacement the wallet would rebroadcast a different version with a higher fee! So you still need to implement changing transactions, and you also still need to fix wallets so they handle replacements. Only in his version you have to wait until the transaction expires, which is problematic because you've got stuff like misguided people rebroadcasting transactions that they don't own, preventing the expiration from happening. (making expiration permanent is ugly too - what if you're trying to get a transaction paying you mined, and can't change it?)

Fee estimation with replacement is fine though, as it lets you replace transactions in the event that the estimate was too low. This helps remove some of the incentive for griefers to play games lying to SPV clients, and it lets people be more aggressive in their bargaining with miners by allowing people willing to wait a little bit the ability to make an initial low-ball bid, and raise it if needed.


tl;dr: Why would you want to be at an auction for something you needed where you got exactly one chance and one chance only to make a bid? There's nothing wrong with making an initial estimate for your first bid to save time, but the bottom line is you're going to be able to get a better deal if you can make a low-ball bid first, raising your bid only if required.

FWIW There's a number of cryptographic techniques such as merkle sum trees and pay-to-contract that you can use with crypto-currencies to make it easy for anyone holding Bitcoin's on behalf of someone else to prove to their owners that the account balances are 100% backed by actual Bitcoins.

If the Winklevoss fund or any similar venture wants to use these technologies I'd be happy to discuss the matter further with them. This kind of proof could be a strong competitive advantage over competitors that don't have it; customers should demand cryptographic proof that each and every balance is backed 100% by actual Bitcoins.

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

It's impossible to do box office futures in a completely decentralized manner because a computer program can't determine what a movies sales were - only a trusted human can do that. (well, you can use web-of-trust systems w/ reputations, but have fun with that...)

Once you do have that trusted human, they can take actions - like redeeming colored coins on demand for bitcoins - that make the colored coins valuable. But fundamentally there are some things math can't compute.

Suggestion: put your protocol documentation in a git repo along with a reference to the git commit hashes of one or more implementations of the protocol. If a new type of transaction is sufficiently well defined to be something that should be Mastercoin "officially", PGP sign a statement saying so and saying on what block # this takes effect.

The PGP isn't really the important thing FWIW, it's having a solid definition of what's what and making that public.

Also you guys really need to think through out the Mastercoin equiv of a soft-fork would work... killerstorm has a very good point re: that.

Indeed, why bits of the truth will come out every time those sneaky devs do a git push! 

Yes, but CScript::GetSigOpCount() simply quits counting if it runs into an invalid script.

Would be good to add more test-cases for that though... It's also kinda an odd decision by satoshi to count scriptPubKey sigops, as they aren't executed when a block is processed.

I'm talking about my TXO commitments idea, which is what I replied to the OP with and is what gmaxwell was talking about.

I was explaining earlier in this thread how to turn arbitrary data into into valid pubkeys to get around that issue.

In addition Mastercoin would be very smart to retain (encrypted) data embedding in pay-to-(script|pubkey)-hash outputs as a backup, and in addition to that, make it possible to embed them in P2SH scriptSigs.

Picture taking a merkle tree of some data, computing the tip, and then changing some data and recomputing - only a subset of the intermediary digests need to be updated, and you can prove that the transition between unspent and spent was correct.

Merkle mountain ranges support efficient appends and updates; when a txout is spent the tree is updated, and the updated root is what is committed in the block. Same idea as UTXO commitments, except with a merkle mountain range not only can you can do secure updates, but because it's insertion ordered you can also add new txouts without actually having any of the data in the set. (other than the tips of the trees)

Mike: rather than platitudes, you got any useful comments on txin proofs from a wallet-side perspective?

Besides, the whole point of MMR TXO commitments is to allow you to verify fully and efficiently without the whole UTXO set; it's the same security as if you did have the full UTXO set. What particular bandwidth vs. local storage tradeoff best suits your needs can then be up to you.

As for hard numbers, so it's log2(n)*32bytes to get to the merkle root in the block header. In reality we can probably skip the Merkle Mountain Range part of the whole scheme for txin proofs, and only provide proofs to block headers, so if we had, say, 2^16 txouts a block you'd be looking at 512 byte proofs per txin roughly, worst case. That's not bad really - a txin takes on the order of ~140 bytes anyway and the bandwidth quickly drops by just storing some of the merkle trees associated with blocks.

Not anymore: Eligius won't mine anything that looks like it's storing data these days. I'd have to check with Luke, but I think the rules are currently that only IsStandard() scriptPubKey's will be mined, although P2SH scriptSigs can be non-standard.


Frankly I think that's awful advice in the case of Mastercoin and similar systems, precisely because they can get away with using standard transaction to achieve their goals.

Why risk having the reference client maintainers reject your transaction standard if you don't have to?

You could also effectively short a merge-mined system - in a trust-free decentralized manner - by using oracle betting like the system alp is working on.

"I bet Namecoin will have a hash rate of X on date Y"

Well, the problem is you want blocking Mastercoin to be something that has to be done explicitly, through blacklists; that's politically more difficult to do than measures that are aimed at parasitic consensus systems in general.

One issue I forgot to mention is that address re-use may be discouraged in the future - transactions that pay scriptPubKeys that have been used recently might be discouraged. That every Mastercoin transaction pays to the 1exodus address is a problem. (though it does mean you can make an SPV client for mastercoin, at least SPV at the bitcoin level)

IsStandard() rules sure, but there's nothing stopping a miner from putting whatever they want in a scriptPubKey.