Bitcoin Forum

If you receive the hash of a transaction that has not been broadcast then what do you know or what can you derive about that transaction?

Absolutely nothing. If you could deduce anything it means the hash function is broken. You can't even tell if this hash actually represents a valid transaction.

But assuming this hash is different from the hash of any transaction you know, you can tell that if in fact it is a valid transaction, it is a transaction you don't already know of.

That is what I thought.

If I were creating a transaction and was provided the input for my transaction (i.e., in hash form), how can I specify the value of the output? My concern being, I do not want change created from the transaction I am creating.

You can specify whatever value you want as an output.  It just won't be valid if it's too high.

I don't understand what you're asking.

Is there an option in the creation of a transaction that makes it so that the value of the outputs equals the value of the inputs? Otherwise, consider the transaction invalid. Alp is saying only if the outputs>inputs is invalid. I am looking for, outputs<>inputs is invalid, but it sounds like this is not currently possible?

Difference between inputs and outputs is the transaction fee, not the change. The change is one of the outputs.

I'm still not sure what you mean (or wish to accomplish) by making some form of transaction "invalid". Are you looking for such an option in some GUI? If you're creating the transaction programatically, can't you just... Not include change/tx fee in it?

Got it: Change is sent back to yourself.

Correction: My concern being, I do not want any transaction fee being created from the transaction I am creating; that is, because I have no way to verify the value of the input.

I am walking through the steps of "providing a deposit" looking for exploits or unintentional consequences (e.g. the user made an error in the creation of Tx1 and funded it with too many bitcoins).

https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit (https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit)

There is no way to validate it through just the hash.  The user could create the refund transaction and give it to the website (since he knows what the hashed transaction is), or he could tell the website how much to make the refund for.  If he screws up, then he loses (either by paying a huge transaction fee or getting an invalid refund that ends up in limbo until the website grants a new refund).  The user can verify that the refund is for the correct amount before signing and broadcasting anything.  This is *his* responsibility (and likely should be a part of whatever custom wallet he is using to do this).

BTW, I have implemented this in Java if you need sample code.  It's a bit messy now and needs some refactoring but it at least should work.  Disclaimer:  I have only done basic testing with it so far, and need to actually create some transactions on testnet to show it works.

This is an issue that Armory had.

You want to be able to look at a transaction and make sure that you are not spending a 10 BTC coin to pay for a 0.1BTC item (without seeing the input transactions)?

Or say the website decides to set the deposit fixed to the current $10usd exchange rate value in bitcoin (i.e., 0.0938174btc). A 10btc deposit seems like quite a bit to be a deposit for a website (i.e., at current rates), but I'm cheap.

The value of bitcoin goes up 8.4-fold 3 months from now making the new deposit a different amount (e.g., .0111687btc). A hacker could change the value being displayed to the user, getting them to pay more than they should. You ask, so a transaction fee is sent to some miner, what's the harm in that? Well, what if the hacker had a vested interest.

Is there or will there be a way to make this set of transactions more secure? (i.e., with the current protocol)?

The website could set the deposit and give refunds earlier by having a higher sequence number that refunds some, and locks up the rest.  This would have to be worked out after the deposit is there with the refund.

Users can see the contents of transactions, so I have no clue why you think a hacker would be able to change any of this.

There is no need to make this "more secure", the data is all there to the party that cares the most (the user), and once published to the blockchain, it's available for the website.

The 10BTC deposit is an example, you could do it with any amount larger than dust and it would work the same.

You can write software that displays things to users and double-checks with them and tries to do the correct thing.  Users can take the transactions and try to validate them independently of your software if they so choose.

I literally have no idea what you are worried about or concerned about, these are fairly trivial problems and easy to solve.

You probably need to do a step by step guide to what you are thinking.

Transactions can be full set (inputs and outputs) before the customer signs them.  That guarantees that there is no accidental fee.

Your concern is that the customer will go to the website to pay and see a number higher than the actual value?  If they pay to the right address, the bank would still get the overpayment, not the miner.

Good idea.

Yes, but the website won't be able to see the transaction because the website only received a hash of the transaction. Well, until it is posted on the blockchain.


I agree.

Click. Yes, that was my concern. You are right, if the user accidentally over-payed, and the user did not recognize the mistake (i.e., the discrepancy between Tx1 & Tx2), then the website would end up with the overpayment, not the miner.

Users are unlikely to be creating raw transactions like this, though, so some software will need to present it to them what is going on.  That makes it far less likely that a mistake will be mad in creating these transactions.

Where do you get this idea from.  Nodes rapidly share tx even before they are confirmed (included in a block).  If the server has a properly running bitcoind they should "see" the transaction (as unconfirmed) within seconds at most.  The site can then report to the user, "tx received (unconfirmed)" and update the status once included in a block "tx received (1 confirmation)" and update the confirmation count as the blockchain is extended.

On edit: For security reasons the user needs to sign but not broadcast tx1 until it receives and verifies the half signed tx2.

In this use case, you don't broadcast the transaction until after you receive a "refund" transaction.   So no nodes see it except yourself (if you are doing it right).  The refund is then given back to you, which you can't broadcast until after you broadcast the funding transaction.

Ok gotcha, missed that part.  

Yeah there is no good way to avoid user error here.  No possibility of malicious attack but if the user creates the tx1 incorrectly (i.e. has a 100 BTC output instead of 10 BTC output) then the tx2 would return 10 BTC and create 90 BTC in miner's fee.  Ooops.  


One thing I have always considered useful in an alt-coin would be to specify the miner fee in the tx header.  This issue (and others related to lost coins in malformed raw txs) comes from the fact that Bitcoin doesn't explicitly specify the miner fee.  The miner's fee is computed implicitly by SUM(in) - SUM(out).  While it works fine as long as no mistake is made, there have been plenty of instances in the past when tx were incorrectly created that gave large sums to miners.  It would be an improvement for future alt-coins to add an explicit "tx fee" field to the tx header.  This would simply result in malformed txs to be invalid and dropped by the network. In this example if a user created a tx1 which SHOULD pay a 10 BTC deposit but accidentally paid a 100 BTC deposit then the tx2 would specify (the output as 10 BTC and fee as 0 BTC).  Even if the user broadcasted both txs, tx2 would be rejected (value of input: 100 BTC, value of outputs: 10 BTC, value of fees: 0 BTC = tx invalid).  The website could then recreate tx2 to the correct amount, half sign it and send it to the user.  Note the user loses some security here, the site "could" hold the funds hostage but this hostage situaiton would only occur where the user a) creates tx1 incorrectly and b) broadcasts tx1 before realizing tx2 is invalid.

Yes, it might even be preferred for the website to have the unsigned transaction, as he has no clue what he is signing.  If the website is not careful, the transaction could possibly be a spend out of one of his addresses (he would have to ensure that no one deposits funds into the address of his public key, or inspect each transaction).  The website would have no idea if the transaction matches one of his unspent outputs or not since he doesn't have the connected script or the transaction being generated.

Sorry now it is extra confusing I modified my answer before you responded as the scenario I described doesn't really ensure the user can't/didn't make an error.  See updated answer above for a non-Bitcoin solution to this (and many other problems).

User error in raw transactions and in code are something to be very careful of.  This has happened a lot.

Explicitly calling out the fee is a good improvement, and seems like something that should be considered in the future (all blocks after N need to have correct outputs, and have a way to tell miners).  That's a nasty fork, and I'm not sure how much benefit there is to it. 

Bitcoin will almost certainly not be forked for that.  However you can add it to a laundry list of things which would make sense for an alt-coin to implement.  There are lots of things which can be improved and tightened up, require compressed pub keys, explicitly include blockheight in blockheader, explicitly include tx fees in tx header, remove pubkey from input (can be recovered from signature), require all signatures to be in canonical form (reduce signature mallability), etc.  Some significant tightening up of the protocol combined with a solid modular code base (i.e. separate wallet operations, from the node codebase from standardized library used to build the reference node) would produce some real value.  Of course all alt-coins to day are merely pump & dump junk so they take wholesale all the bugs/quirks in bitcoin.  In theory though someone "could" make a better alt-coin ... someday.

Better will need to have real tangible benefits to overcome networking effects, and if they did, it might be worth the fork then, especially if it was planned out well in advance.  It will be interesting to see how things play out, and it's tough for the first version of anything to survive long term, almost always something is left out and someone improves.  Bitcoin has a pretty huge first player advantage, though.

Sometimes the correct thing to do is obvious. And, I suspect that regulators like to look at issues like this one and just shake their heads and ask why, why, why? K.I.S.S.

The benefit is to the user (i.e., the customer), and by extension, to bitcoin itself.

Update:
I am curious to know if there are any statistics on users accidentally making this error of overpaying. Also, if anyone has written any code which would cull the blockchain looking for transactions that appear to fallen into this trap. Sometimes in order to see how big a problem is, you have to quantify it.

Almost all users are using clients that do not overpay.  Very few people mess with raw transactions.  There are instances of people screwing up testing stuff or trying to be cute.  You are trying to solve a problem that virtually does not exist and cannot be solved.  If you want to use this use case, code it without making a mistake and test the hell out of it.  Then your users won't screw up.