Transaction hash

[alp]

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.

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. 

[1714753849]

1714753849

[1714753849]

1714753849

[1714753849]

1714753849

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

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.

[alp]

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.

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.

[jadair10]

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.  

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.

[alp]

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.  

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.