Bitcoin Forum
March 28, 2024, 09:04:12 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Is there a Fee UTXO in every transaction?!  (Read 246 times)
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 02, 2021, 05:11:46 AM
Merited by LoyceV (8), hugeblack (2), NotATether (2), vapourminer (1), ABCbits (1)
 #1

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
1711616652
Hero Member
*
Offline Offline

Posts: 1711616652

View Profile Personal Message (Offline)

Ignore
1711616652
Reply with quote  #2

1711616652
Report to moderator
1711616652
Hero Member
*
Offline Offline

Posts: 1711616652

View Profile Personal Message (Offline)

Ignore
1711616652
Reply with quote  #2

1711616652
Report to moderator
Even in the event that an attacker gains more than 50% of the network's computational power, only transactions sent by the attacker could be reversed or double-spent. The network would not be destroyed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711616652
Hero Member
*
Offline Offline

Posts: 1711616652

View Profile Personal Message (Offline)

Ignore
1711616652
Reply with quote  #2

1711616652
Report to moderator
1711616652
Hero Member
*
Offline Offline

Posts: 1711616652

View Profile Personal Message (Offline)

Ignore
1711616652
Reply with quote  #2

1711616652
Report to moderator
vjudeu
Hero Member
*****
Offline Offline

Activity: 639
Merit: 1473



View Profile
September 02, 2021, 05:27:54 AM
Merited by LoyceV (4), o_e_l_e_o (4), ABCbits (3), odolvlobo (1)
 #2

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

█▀▀▀











█▄▄▄
▀▀▀▀▀▀▀▀▀▀▀
e
▄▄▄▄▄▄▄▄▄▄▄
█████████████
████████████▄███
██▐███████▄█████▀
█████████▄████▀
███▐████▄███▀
████▐██████▀
█████▀█████
███████████▄
████████████▄
██▄█████▀█████▄
▄█████████▀█████▀
███████████▀██▀
████▀█████████
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
c.h.
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀█











▄▄▄█
▄██████▄▄▄
█████████████▄▄
███████████████
███████████████
███████████████
███████████████
███░░█████████
███▌▐█████████
█████████████
███████████▀
██████████▀
████████▀
▀██▀▀
PrimeNumber7
Copper Member
Legendary
*
Offline Offline

Activity: 1610
Merit: 1899

Amazon Prime Member #7


View Profile
September 02, 2021, 05:28:38 AM
Merited by NotATether (2)
 #3

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.
BlackHatCoiner
Legendary
*
Offline Offline

Activity: 1470
Merit: 7064


Farewell, Leo


View Profile
September 02, 2021, 07:02:25 AM
 #4

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 02, 2021, 07:08:22 AM
 #5

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

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.

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

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 ?
DannyHamilton
Legendary
*
Offline Offline

Activity: 3346
Merit: 4505



View Profile
September 02, 2021, 01:25:41 PM
 #6

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.
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 02, 2021, 03:25:42 PM
Last edit: September 11, 2021, 12:06:11 AM by Shymaa-Arafat
 #7

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???
DannyHamilton
Legendary
*
Offline Offline

Activity: 3346
Merit: 4505



View Profile
September 02, 2021, 03:36:56 PM
Merited by ABCbits (22), LoyceV (12), LeGaulois (4), vapourminer (3), n0nce (3), BlackHatCoiner (2), NotATether (1)
 #8

Just took a look at that paper.  It’s full of errors and misrepresentations. Feel free to pass along the following if you like:

Quote
The public key is like the bank account number . . . In a transaction, the blockchain address usually appears as the payee account number.
A public key is not like a bank account number.  It is a signature verification system. It’s slightly closer to say that the address is like a bank account number, since this is the value that a transaction recipient gives to the transaction creator to be used for the transfer of value, but even that is terribly misleading.  First of all, addresses shouldn’t typically be re-used unless necessary.  In this way, the address is more like an invoice number.  Secondly, neither the address nor the public key are typically stored in the transaction output.  The transaction output is typically encumbered with a set of requirements (defined by a “script”) that must be met for that output to be used as an input to another transaction.  While this set of requirements CAN include a public key, it typically doesn’t. Instead it typically will contain a hash of the public key.  An address is just a representation of the entire script, frequently containing additional data such as a checksum and a version number used to indicate to wallet software how to build the appropriate output script.  Many output scripts are simple puzzles that have NO public key associated with them at all, and multiple different scripts can all use the same public key in entirely different ways that would not lead to them all belonging to a single “account balance”.


Quote
The so-called account balance is actually the sum of all UTXOs belonging to the user address
Since most people interact with the blockchain system with a wallet, and therefore think of their “wallet balance” as their “account balance”, and since wallets can generate multiple addresses, it would be more accurate to say that the “so-called account balance is actually the sum of all UTXO for which the wallet (or user) can satisfy the requirements defined in the script (which may include having access to associated private keys.

Quote
This feature determines that the total input UTXO value must be equal to the output UTXO value. In most cases, as shown in Fig. 2, the number of input UTXOs is one or more,
There are no input UTXOs.  That doesn’t even make sense.  A UTXO is an spent transaction OUTPUT.  Transactions have inputs, and they have outputs.  The outputs may be spent or unspent. If they are unspent, they are called an unspent transaction output (or a UTXO). If they are included in an input, then they are spent.  They are no longer unspent, and therefore they are no longer a UTXO.

Quote
Every transaction can generate more UTXOs. Therefore, as transactions happen, the UTXO set will become larger and larger, and more memory space should be occupied.
Transactions have outputs, and those outputs are generally initially unspent, therefore it’s true that transactions generate UTXOs.  However, transactions also consume UTXO in their inputs.  A transaction may have more outputs than inputs, the same number of outputs as inputs, or less outputs than inputs.  Common use patterns will determine if a particular blockchain based cryptocurrency will have an increasing number of UTXOs, a relatively static number of UTXOs, or a decreasing number of UTXOs.

Quote
The structure of bitcoin blockchain system is shown in Fig. 3
Fig 3 is mistaken in multiple areas. It implies that the merle tree is stored in the block body (it is not). It indicates that the current block hash value is stored in the block header (it is not). It fails to indicate that the difficulty target is stored in the block header. It indicates that the block reward is stored in the block header (it is not).

Quote
The block body mainly contains the transaction tree status information supported by hash algorithm . . . The Merkle tree in the block body will sign each transaction digitally, which can ensure that every transaction is unforgeable
No.  The block body consists ONLY of the actual transactions that were used to assemble the block. The Merkle tree isn’t stored in the block, and it doesn’t sign anything.

Quote
The continuous growth of blockchain database will also reduce the speed of transaction verification by nodes, which will hinder the development of the system.
No.  The number of blocks in the blockchain has negligible effect on the speed of transaction verification. Once a transaction has been verified, and its outputs are added to the UTXO set in the mempool, there is no need to ever look at the historical blocks for transaction verification.

Beyond the first 4 paragraphs, everything else in section 2 looks like they were just trying to fill up space to meet some page count requirement for a school project.  They have a paragraph about Interplanetary File System, another about Section-Blockchain, yet another about blockchain as an electricity trading system, and a paragraph that just lists work performed by Guo, Mbinkeu, Mei, Wang, El-Hindi, and Gennaro. None of this appears to have any relevance to this paper at all, and leaving all of it out would not make the paper any more difficult to understand.

Quote
According to the blockchain running principal mentioned above in Section 1, we can divide blockchain transactions into two types as shown in Fig. 4: Single input multiple output (SIMO) and multiple input multiple output (MIMO)
They completely left out the remaining 2 types: Single input single output (SISO) and Multiple input single output (MISO).

They then include a bunch of transactions where they attempt to calculate a speed at which the UTXO set will grow, but since they are including an output for the transaction fee, and they are leaving out SISO and MISO, their calculations are effectively useless.

Furthermore, this paper appears to go back and forth multiple times between complaining about the need for Full Nodes to store the entire blockchain, and the need for transaction verification to store the entire UTXO set.  It doesn’t seem to distinguish between these very well and can leave a reader that is unfamiliar with these concepts lost as to which of these “storage pressures” the proposed solution is supposed to help with. Especially when the paper says things like this:
Quote
Compared with the original blockchain system, new method slows down the expansion speed of blockchain transaction databases. The proposed method alleviated thee storage pressure of full nodes to a certain extent

Their “Evaluation” section (section 4) is nothing more than a simulation using their already invalid formula for calculating UTXO growth rather than evaluating real transactions in a real blockchain, or even experimentally creating actual transactions in a test blockchain.  They also don’t compare any of their calculations of what they predict will happen to the quantity of UTXO to any current real-life blockchain to see if their predictions match reality.

All in all, I’d rate this paper below average for effort, and a failure for accuracy and usefulness.

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

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.
NotATether
Legendary
*
Offline Offline

Activity: 1554
Merit: 6531


bitcoincleanup.com / bitmixlist.org


View Profile WWW
September 02, 2021, 04:09:33 PM
 #9

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

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
odolvlobo
Legendary
*
Online Online

Activity: 4270
Merit: 3159



View Profile
September 02, 2021, 04:22:29 PM
Merited by NotATether (1)
 #10

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.

Join an anti-signature campaign: Click ignore on the members of signature campaigns.
PGP Fingerprint: 6B6BC26599EC24EF7E29A405EAF050539D0B2925 Signing address: 13GAVJo8YaAuenj6keiEykwxWUZ7jMoSLt
DannyHamilton
Legendary
*
Offline Offline

Activity: 3346
Merit: 4505



View Profile
September 02, 2021, 05:00:48 PM
Merited by HCP (10), ABCbits (1)
 #11

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.
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 13, 2021, 05:22:45 AM
Last edit: September 13, 2021, 05:43:13 AM by Shymaa-Arafat
 #12

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)
pooya87
Legendary
*
Offline Offline

Activity: 3402
Merit: 10433



View Profile
September 13, 2021, 05:29:23 AM
Merited by vapourminer (1)
 #13

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 13, 2021, 05:50:38 AM
 #14

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)
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?
pooya87
Legendary
*
Offline Offline

Activity: 3402
Merit: 10433



View Profile
September 13, 2021, 06:29:49 AM
Merited by ranochigo (1)
 #15

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
ranochigo
Legendary
*
Offline Offline

Activity: 2940
Merit: 4127



View Profile
September 13, 2021, 06:34:26 AM
 #16

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.

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
September 13, 2021, 06:57:21 AM
 #17

Joining both statements from u too
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
ranochigo
Legendary
*
Offline Offline

Activity: 2940
Merit: 4127



View Profile
September 13, 2021, 07:31:46 AM
Merited by pooya87 (2)
 #18

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.

..JAMBLER.io..Create Your Bitcoin Mixing
Business Now for   F R E E 
▄█████████████████████████████
█████████████████████████
████▀████████████████████
███▀█████▄█▀███▀▀▀██████
██▀█████▄█▄██████████████
██▄▄████▀▄▄▄▀▀▀▀▀▄▄██████
█████▄▄▄██████████▀▄████
█████▀▄█▄██████▀█▄█████
███████▀▄█▀█▄██▀█▄███████
█████████▄█▀▄█▀▄█████████
█████████████████████████
█████████████████████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
      OUR      
PARTNERS

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
▄█████████████████████████████
████████▀▀█████▀▀████████
█████▀█████████████▀█████
████████████████████████
███████████████▄█████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████▀█████████
████████████████████████
█████▄█████████████▄█████
████████▄▄█████▄▄████████
▀█████████████████████████████
█████████████████████████████████████████████████
.
   INVEST   
BITCOIN

.
█████████████████████████████████████████████████
████▄
██
██
██
██
██
██
██
██
██
██
██
████▀
Shymaa-Arafat (OP)
Full Member
***
Offline Offline

Activity: 228
Merit: 156


View Profile
October 24, 2021, 08:39:29 AM
 #19

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://bitcointalk.org/index.php?topic=5367212.0
 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
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!