Transaction hash

[jadair10]

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?

[1714768917]

1714768917

[Meni Rosenfeld]

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.

[jadair10]

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.

[alp]

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.

[Meni Rosenfeld]

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.

I don't understand what you're asking.

[jadair10]

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?

[Meni Rosenfeld]

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?

[jadair10]

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

[alp]

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.

[TierNolan]

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.

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)?

[jadair10]

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)?

[alp]

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.

[TierNolan]

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.

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.

[jadair10]

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.

Good idea.

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.

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.

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

I agree.

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.

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.

[alp]

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.

[DeathAndTaxes]

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.

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.

[alp]

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.

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.

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.

[DeathAndTaxes]

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.

[alp]

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.

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.

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 the scenario just requires that tx1 not be broadcast.  It can't be broadcast because it isn't yet signed by both parties.  However don't prohibits the depositor from sharing the unsigned tx DIRECTLY (i.e. not using Bitcoin network) with the website.  The user doesn't lose any security.  The security comes from the fact that the site can't spend the funds without the tx signed by the user's private key. As long as the user keeps their private key secure they are fine.

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.

[DeathAndTaxes]

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.

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.

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 the scenario just requires that tx1 not be broadcast.  It can't be broadcast because it isn't yet signed by both parties.  However don't prohibits the depositor from sharing the unsigned tx DIRECTLY (i.e. not using Bitcoin network) with the website.  The user doesn't lose any security.  The security comes from the fact that the site can't spend the funds without the tx signed by the user's private key. As long as the user keeps their private key secure they are fine.

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).