This is some what an old topic, but I think I have to say their paper may have been part of a suggested project to apply confidential transactions in Bitcoin.
-As u see from here,
https://en.bitcoin.it/wiki/Confidential_transactions
It's all research projects, a soft fork that was never implemented (or haven't been implemented yet)
.
& from this topic
https://bitcointalksearch.org/topic/confidential-transactions-5367212
I realized that if there were confidential TXs in Bitcoin, they would have necessiated a separate non-confidential UTXO for the fee ...
.
Although, they should have clarified that in their paper
Topic: Is there a Fee UTXO in every transaction?! (Read 288 times)
u mean the sender can use CSV for like the change, but can NOT do it to the UTXO sent to a receipant without his knowledge/approval? otherwise it will get verified as valid as the 1st statement says
No. The sender can define conditions for their addresses, which is why you have P2SH, P2WSH with the conditions for an UTXO to be valid. You do not specify additional conditions in your transaction outputs. This is why it doesn't concern the recipient; so long as the transaction is confirmed, the recipient can spend the UTXO with no additional requirements whatsoever, beyond those that were defined during the creation of the address. Since the sender cannot define any conditions for the recipient, beyond whatever conditions are nested within the addresses as defined by the recipient.
Joining both statements from u too
u mean the sender can use CSV for like the change, but can NOT do it to the UTXO sent to a receipant without his knowledge/approval? otherwise it will get verified as valid as the 1st statement says
Quote
If the sender is spending an output by using OP_CSV it still doesn't concern the receiver as long as the tx was valid and is confirmed
Quote
The sender cannot define the requirements to spend the UTXO for the recipient, that wouldn't make sense
u mean the sender can use CSV for like the change, but can NOT do it to the UTXO sent to a receipant without his knowledge/approval? otherwise it will get verified as valid as the 1st statement says
I think CSV has some differences than n-timelock ( as they say in the help file)
I mean for users who use SPV or alike and thinks someone paid them X money, could it be that they don't know CSV is used? It's not going to appear either in the header or in the proof?
nLocktime is not an OP code. It is a parameter within a transaction that only limits when it can be mined.I mean for users who use SPV or alike and thinks someone paid them X money, could it be that they don't know CSV is used? It's not going to appear either in the header or in the proof?
Conditions for the UTXOs are not defined by the sender, and are only bounded by the conditions as specified in the script of the recipient address. The recipient defines the conditions for the UTXOs to be valid and able to be spent. The recipient will know the CSV, because they're going to be defined by them. The sender cannot define the requirements to spend the UTXO for the recipient, that wouldn't make sense.
I think CSV has some differences than n-timelock ( as they say in the help file)
I don't know what you mean by "n-timelock" but we only have 2 OP codes that deal with time.1. OP_CheckLockTimeVerify which compares the top stack item (interpreted as an integer) with the transaction's locktime (the last 4 bytes of all transactions) and only passes if (a) they are both of same type (time or height) (b) the stack item is smaller than tx lock time (c) all inputs' sequences are less than max
2. OP_CheckSequenceVerify which does the comparison similar to above but with input's sequence (after applying some masks to the 2 values).
Quote
I mean for users who use SPV or alike and thinks someone paid them X money, could it be that they don't know CSV is used? It's not going to appear either in the header or in the proof?
No, because the receiver (SPV user) has to create an address and give it to the sender to send them bitcoin and when they are creating their address they can decide what kind of script they want to use. The script can contain OP_CSV if they wanted to.If the sender is spending an output by using OP_CSV it still doesn't concern the receiver as long as the tx was valid and is confirmed.
It is not "expiration of UTXO". This OP code is simply a "time condition" that either fails or passes based on how the value that goes into that condition and the current time. It is always used in combination with other signature related OP codes. For example you can create a smart contract saying "if 10 days is past let this output be spent by key1 else let it be spent by key2+key3".
The UTXO itself doesn't "expire" ever. As long as it was valid when first received and is still unspent, it will remain in the UTXO database.
I think CSV has some differences than n-timelock ( as they say in the help file)The UTXO itself doesn't "expire" ever. As long as it was valid when first received and is still unspent, it will remain in the UTXO database.
I mean for users who use SPV or alike and thinks someone paid them X money, could it be that they don't know CSV is used? It's not going to appear either in the header or in the proof?
op-code CHECKSEQUENCEVERIFY that gives an expiration date of old UTXOS
It is not "expiration of UTXO". This OP code is simply a "time condition" that either fails or passes based on how the value that goes into that condition and the current time. It is always used in combination with other signature related OP codes. For example you can create a smart contract saying "if 10 days is past let this output be spent by key1 else let it be spent by key2+key3".The UTXO itself doesn't "expire" ever. As long as it was valid when first received and is still unspent, it will remain in the UTXO database.
It's worth mentioning that I found out ( in a comment on MIT lec on Forks) there was a soft fork of an op-code CHECKSEQUENCEVERIFY that gives an expiration date of old UTXOS
.
I searched, it was in BIP-0112 (2015)
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.
.
This additional explaination here dated 2020 proves even before reading it is still valid (ie, the fork succeeded although rarely used)
https://academy.bit2me.com/en/what-is-checksequenceverify-csv/
I hope I didn't got my information mixed up here
.
I don't know maybe this paper was trying to address this feature somehow
.
It is interesting when u go through this
https://blockstream.com/2021/01/25/en-blockstream-green-bitcoin-wallets-now-using-checksequenceverify-timelocks/
https://help.blockstream.com/hc/en-us/articles/900004249546-The-upgrade-from-nLockTime-to-CheckSequenceVerify
and remember her words from the lecture about SPV users & wallets being careful:
-What will happen if Alice paid Bob & used this op-code without Bob knowing, if Bob didn't spend before the expiry date he will lose his money it will be like burned, vanished in
-& in general, what will happen to the system state, UTXO set?
-would things be like this paper (without the extra fee UTXO ofcourse)
.
I searched, it was in BIP-0112 (2015)
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent.
.
This additional explaination here dated 2020 proves even before reading it is still valid (ie, the fork succeeded although rarely used)
https://academy.bit2me.com/en/what-is-checksequenceverify-csv/
I hope I didn't got my information mixed up here
.
I don't know maybe this paper was trying to address this feature somehow
.
It is interesting when u go through this
https://blockstream.com/2021/01/25/en-blockstream-green-bitcoin-wallets-now-using-checksequenceverify-timelocks/
https://help.blockstream.com/hc/en-us/articles/900004249546-The-upgrade-from-nLockTime-to-CheckSequenceVerify
and remember her words from the lecture about SPV users & wallets being careful:
-What will happen if Alice paid Bob & used this op-code without Bob knowing, if Bob didn't spend before the expiry date he will lose his money it will be like burned, vanished in
-& in general, what will happen to the system state, UTXO set?
-would things be like this paper (without the extra fee UTXO ofcourse)
Just took a look at that paper. It’s full of errors and misrepresentations. Feel free to pass along the following if you like:
It should be noted that the paper is not specifically about Bitcoin, though it does say "bitcoin-like" several times.
Right. Sure. The paper is not actually about "Bitcoin". We all believe that.
And how many times did they mention ANY other specific "bitcoin-like" blockchain systems? (Litecoin? Bitcoin Cash? etc).
In what way is their imaginary "bitcoin-like" blockchain system anything like bitcoin? Do they make any effort to state what is the same or what is different?
Note that they DO explicitly state that Fig 3 is supposed to be "the structure of the bitcoin blockchain system" (as I mentioned, it is not).
This is a lazy, error-ridden, paper full of nonsense in my opinion.
Just took a look at that paper. It’s full of errors and misrepresentations. Feel free to pass along the following if you like:
It should be noted that the paper is not specifically about Bitcoin, though it does say "bitcoin-like" several times.
Thanks for the confirmation, so it seems the reviewers didn't actually read the paper! Because it's stated several times there, they could've asked the authors to correct it:
Quote
Computer Systems Science & Engineering
DOI:10.32604/csse.2021.014530
CSSE, 2021, vol.36, no.3
Article
DOI:10.32604/csse.2021.014530
CSSE, 2021, vol.36, no.3
Article
Since you already submitted the correction(s) to the paper authors, you did your part. You're a researcher, so they will probably get back to you, and you should just wait for their reply at this point.
Just took a look at that paper. It’s full of errors and misrepresentations. Feel free to pass along the following if you like:
How would you do that? You'd need to know, when you are creating the transaction, which mining pool will eventually succeed in confirming the transaction. You'd be limiting your transaction to being considered zero fee by all standard full nodes, so they wouldn't relay it, and all other mining pools would also consider your transaction to be zero fee, so they wouldn't confirm it. You'd be waiting more than double the amount of time for your first confirmation, and if you chose your pool poorly you may be waiting MUCH longer than that.
Or could it be that in China they actually do create an extra unnecessary UTXO for the fee?
I mean the transaction will be still valid if they did so thinking it is a must???
I mean the transaction will be still valid if they did so thinking it is a must???
How would you do that? You'd need to know, when you are creating the transaction, which mining pool will eventually succeed in confirming the transaction. You'd be limiting your transaction to being considered zero fee by all standard full nodes, so they wouldn't relay it, and all other mining pools would also consider your transaction to be zero fee, so they wouldn't confirm it. You'd be waiting more than double the amount of time for your first confirmation, and if you chose your pool poorly you may be waiting MUCH longer than that.
The paper is already published,
I sent to the corresponding author email with all the details even a link to this discussion so that they correct it on the internet and the published proceedings, and defend themselves here if they want/explain their point/.... whatever.
There's another post too that I forgot to include in the email, incase they want to reply
https://bitcointalk.org/index.php?topic=5357735.new#new
The post was in Mining group, and moved in what I believe is a wrong decision to alternate cryptocurrencies; I locked the topic before it was moved anyways. So, if the authors need to defend themselves it will be here
I also told him that the reviewers are also to blame, if they really did read the paper they would have correct it before publishing.
Or could it be that in China they actually do create an extra unnecessary UTXO for the fee?
I mean the transaction will be still valid if they did so thinking it is a must???
I sent to the corresponding author email with all the details even a link to this discussion so that they correct it on the internet and the published proceedings, and defend themselves here if they want/explain their point/.... whatever.
There's another post too that I forgot to include in the email, incase they want to reply
https://bitcointalk.org/index.php?topic=5357735.new#new
The post was in Mining group, and moved in what I believe is a wrong decision to alternate cryptocurrencies; I locked the topic before it was moved anyways. So, if the authors need to defend themselves it will be here
I also told him that the reviewers are also to blame, if they really did read the paper they would have correct it before publishing.
Or could it be that in China they actually do create an extra unnecessary UTXO for the fee?
I mean the transaction will be still valid if they did so thinking it is a must???
I don't want to be the bad guy here, but papers get to become references
Be the bad guy.
Papers are published with the expectation that errors will be pointed out.
Thanks for the confirmation, so it seems the reviewers didn't actually read the paper! Because it's stated several times there, they could've asked the authors to correct it:
You can read in there
And it's funded by like 3 or 4 research centers, and I don't know what to do I don't want to be the bad guy here, but papers get to become references
Someone like me who doesn't really mine or have BTC could think based on this of a research point or a script to add these UTXOS automatically to the coinbase UTXO to save the added overhead of ~2000 unnecessary UTXOS per block ?
Quote
Computer Systems Science & Engineering
DOI:10.32604/csse.2021.014530
CSSE, 2021, vol.36, no.3
Article
DOI:10.32604/csse.2021.014530
CSSE, 2021, vol.36, no.3
Article
You can read in there
Quote
In most cases, as shown in Fig.2, the number of input UTXOs is one or more, and at output end, there will be at least three UTXOs:
One UTXO paid to the payee,
one paid to the miner, and one UTXO change returning to the payer. In order to independently verify
transactions, nodes need to track all the UTXOs in the blockchain databases.
One UTXO paid to the payee,
one paid to the miner, and one UTXO change returning to the payer. In order to independently verify
transactions, nodes need to track all the UTXOs in the blockchain databases.
Quote
Based on Eq. (2), the SIMO transaction only consumes one UTXO, so the number of input UTXOs is: Nin = 1.
Meanwhile, the SIMO transaction will generate k + 2 UTXOs, and the number of output UTXOs
is: Nout = k + 2. Here, k is the payee number.
We can summarize the formula of UTXO expansion speed for
SIMO transactions as follows:
2; if k = 1
k + 1; if k > 1
Meanwhile, the SIMO transaction will generate k + 2 UTXOs, and the number of output UTXOs
is: Nout = k + 2. Here, k is the payee number.
We can summarize the formula of UTXO expansion speed for
SIMO transactions as follows:
2; if k = 1
k + 1; if k > 1
And it's funded by like 3 or 4 research centers, and I don't know what to do I don't want to be the bad guy here, but papers get to become references
Someone like me who doesn't really mine or have BTC could think based on this of a research point or a script to add these UTXOS automatically to the coinbase UTXO to save the added overhead of ~2000 unnecessary UTXOS per block ?
I tried to direct the Q to miners, but it seems those who join a pool get paid by the pool, not transaction creators, and maybe not sure of the answer.
Yes, there are those miners who just sell their computational power; far as this. They don't know how a transaction is structured like or possibly how the entire system works. Most of them should know, though, that they're calculating hashes.-In MIT lectures they say the fee is the difference between input & output values; ie calculated implicitly, at least that's what I understood.
That's correct. There shouldn't be any extra information in your transaction, think about it. The weight of your transaction speaks by itself. It's a matter of a consensus rule to make the chain weight lighter by taking the fee for granted.
The transaction fee is not part of the UTXO set. If for example, the sum of all inputs is 1.01 and the sum of all outputs is 1.00 BTC, the difference, 0.01 BTC will be added to the block subsidy of the coinbase transaction of the block that confirmed the transaction. If the above transaction was the only transaction confirmed, the coinbase transaction would include no inputs and 6.26 BTC in total outputs.
Quote
Does every Bitcoin Tx contain a Fee UTXO???
No, it is simply calculated as a sum of all outputs subtracted from a sum of all inputs. You spend 1 BTC in your inputs and create 0.99 BTC in your outputs, so the fee is up to 0.01 BTC (because miners could take less than block reward, then coins are burned forever).
I tried to direct the Q to miners, but it seems those who join a pool get paid by the pool, not transaction creators, and maybe not sure of the answer.
Q:
Does every Bitcoin Tx contain a Fee UTXO???
-In MIT lectures they say the fee is the difference between input & output values; ie calculated implicitly, at least that's what I understood.
-Then I ran into this paper that repeats in explicit words & substitute in EQs (for the growth of the UTXOS set) adding 1 extra UTXO in each transaction for the fee.
-It doesn't like destroy their results to subtract this 1 from all their EQs, but just made me double check
Q:
Does every Bitcoin Tx contain a Fee UTXO???
-In MIT lectures they say the fee is the difference between input & output values; ie calculated implicitly, at least that's what I understood.
-Then I ran into this paper that repeats in explicit words & substitute in EQs (for the growth of the UTXOS set) adding 1 extra UTXO in each transaction for the fee.
-It doesn't like destroy their results to subtract this 1 from all their EQs, but just made me double check
Jump to: