Skip to content
This repository has been archived by the owner on Nov 2, 2018. It is now read-only.

Transaction Form #20

Closed
DavidVorick opened this issue Oct 29, 2014 · 3 comments
Closed

Transaction Form #20

DavidVorick opened this issue Oct 29, 2014 · 3 comments

Comments

@DavidVorick
Copy link
Member

Right now we have an ability to sign the miner fee, I want to add a flag that suggests stack/no-stack.

If you don't sign the miner fee, then it doesn't matter and the miner fee can be whatever.
If you sign the miner fee with 'no-stack', then the miner fee must be exactly what you signed.
If you sign the miner fee with 'stack', then the miner fee must be at least what you signed, summed with every miner fee that was signed 'stack'.

Example:

Alice signs 'stack' for a fee of 2 coins.
Bob signs 'stack' for a fee of 2 coins.
The minimum miner fee must then be 4 coins, because at least 2 have come from Bob, and at least 2 have come from Alice, and they must stack.
Charlie signs 'no-stack' for 3 coins. This transaction will now never be valid, because Charlie has stated that the fee must be exactly 3 coins, which is in conflict with what Alice and Bob have mandated.

Alternatively, Charlie could sign 'no-stack' for 5 coins, and the transaction will be valid as long as there are exactly 5 coins in the miner fee. This fits with what Alice and Bob have mandated.

And now that I think about it, we may want to add the 'stack' flag to all outputs. This makes sense for something like charity, where you want to be sure that if you and other parties are adding arbitrary inputs, nobody is going to be setting extra outputs where you don't want them, etc.

We also want a flag for 'all inputs', which means 100% of inputs are signed.
We also want a flag for 'all outputs', which means 100% of outputs are signed.
This prevents unwanted malleability.

@DavidVorick DavidVorick changed the title Miner Fee Stacking, all inputs & outputs Transaction Form Oct 31, 2014
@DavidVorick
Copy link
Member Author

I'm going to hijack this and make it about transactions in general instead of just the miner fee.

Transactions are weirdly complicated b/c there's so many ways to build them and so many ways for things to go wrong.

We could just make them dirt simple, which might be the best idea. This would remove the fee, and you sign inputs and outputs but don't have an option to sign all of them.

The things that we really want though:

  • Adjustable miner fees, but only up
  • assurance contracts

Assurance contracts are potentially useful to us because you can sign a contribution to a contract, and know that your funds are going directly to the contract. Without signing all potential outputs though, you can't be certain that the target goal won't be overshot and some malicious guy will run away with the spillover.

If you do sign all outputs, it means that people can't add refund outputs, which is annoying but not fatal. I think that the only time it's a real problem is when you have multiple people adding inputs to a contract without adding new outputs that weren't previously specified. Idk it seems like a really complicated problem so I'm going to make the potentially-fatal mistake of keeping things simple and not allowing you to sign all outputs.

But I think that I will add multiple miner fees because that's the only way that people can arbitrarily add to the miner fee without screwing up others who have signed the miner fee.

@DavidVorick
Copy link
Member Author

The ultra simple thing to do is just get rid of CoveredFields entirely and just have every single signature sign the entire transaction - which means everyone has to agree on the final state of the txn including the fees before making any signatures. More of a pain for people trying to make transactions... but makes implementation a lot simpler. Also potentially a lot safer.

The only dangers I can think of from having malleability that prevents you from signing all outputs and all inputs is that if multiple people are adding funds to the same contract, but don't know that each other exist, then they could be duped and some middle-guy could take whatever funds overlap.

So I guess the solution is to avoid situations where you are adding funds to a transaction along with unknown other parties. If you do that, then you should be safe even though you can't sign every output and guarantee that someone isn't adding more.

@DavidVorick
Copy link
Member Author

I guess we just need to make sure that the flexibility justifies the complexity, since the vast majority of transactions would be just fine without a CoveredFields object.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant