The value range is very big, allowing to lock transactions until close to the heat death of the universe.If the lock is moved to a single output, change outputs become distinguishable. Not just the recipient's outputs, but also any change or outputs of other recipients. The timelock locks an entire transaction.An output mined a long time ago, but only recently expired is treated the same as any other output mined with it. The ring member selection does not take the timelock values into account.Exactly one transaction used the time-based locktime, a test transaction by Mitchell. The 2% are a total of 195 transactions in the past 1'000'000 blocks that use the block-based locktime. Actual legitimate usage is really low.This weird pattern potentially allows linking these transactions to a single service. These are unlock_time values between 1 and 15 that have been expired shortly after genesis. 98% of its usage does not have semantic meaning.I detailed most of them in a series of blogposts. The unlock_time field has a host of problems. A user receiving an output in a timelocked transaction can only spend this output once it has expired. A user can choose to either set it to a block height, indicating until which block all the outputs of the transaction remained locked, or a timestamp, indicating until what time all the outputs should be locked. Monero's timelock is used with the unlock_time field, which is available in every transaction. There are future use cases, for example payment channels and payment channel networks, that require some form of timelock, as described in the DLSAG paper. This issue should open further discussion on this topic. ![]() Following discussions during a #monero-research-lab meeting, see logs here, there seems to be some support for removing monero's timelock implementation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |