-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Dust Protection #32
Conversation
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Co-authored-by: Andrea V <andreakarimodm@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find the pseudo-code really hard to follow! I think it needs to be consistently simplified.
The second option is much more complicated as it introduces a completely new unlock mechanisms and requires the nodes to store the Merkle tree roots indefinitely. | ||
|
||
|
||
# Unresolved questions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire section should be gone.
I agree. I was even wondering whether it should be removed completely. During the last few iterations the Validation rules got rather precise and well-defined, so IMHO they are much easier to understand and review than the pseudo code. |
If we really wanna keep the pseudo code, it must be simplified:
|
Not only that, the attacker could also make it basically impossible to move all funds from that address if more dust per dust allowance output is allowed than one can have inputs in a single transaction to collect it with the dust allowance output together |
@Thoralf-M But maybe the address owner can take funds out in batches? For example, a service can put 3 Mi and constantly consolidate 100 outputs. |
@GalRogozinski if an attacker constantly sends new transaction to this address the owner of the address can only move all funds if he does the PoW faster than the attacker or if the attacker stops spamming at some point |
Reducing the dust per output to 100, independent of the amount of the dust allowance output, also protects in cases where someone with a lot iotas (1 Ti for example) creates a dust allowance output unintentional (unintentional with such a large amount), then an attacker can just spam 100 million dust outputs to this address |
Since we have a rule that a single message can't create more than 1 output per address, it means that an attacker will have to create 100 different messages with a signature for each. A sweeper can use 100 inputs with 1 output and 1 signature in a single message. At least from tests on my personal laptop I concluded that the attacker would need to have X20 PoW power to keep up with the sweeper. I want to point out that the current know flaws with the proposal are discussed here https://hackmd.io/@iota-protocol/S1zFaBCjP (just a draft). In the Chrysalis protocol team we talked about implementing the dust tiers idea later on. The assumption behind the dust tiers solution is that tiny dust is less useful for business purposes than larger dust. Meaning we can be very limiting on small dust outputs, but not so much on larger dust, which will be more expensive to spend in a large scale.
As for the last comment about someone accidentally creating a 1 Ti allowance, I guess it is possible but unlikely... The reason to allow more than 100 is to make sure that businesses that want to rely on microtransactions can actually do it w.o having their addresses blocked. From a security perspective, I agree with you. |
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Hmm,
It doesn't make sense that the amount will be less than a dust amount.
I can rephrase it this way.
Should wallets in general update themselves in case of a change? That's
up to the wallet to decide... I still think of it as syntactic
validation, but I guess it can be viewed as semantic
Btw, why does the hardware ledger itself has to validate anything?
Shouldn't it just sign and leave validation to the software wallet on
the laptop that is connected to the ledger?
…On 22.1.2021 10:11, Thomas Shufps wrote:
Some suggestion from my side:
move |The Amount must be ≥ 1,000,000.| from syntactical validation to
semantic validation.
Reason: Amount of dust will change over time and I can't put a static
value into eg the validation of the Nano Ledger app! That shouldn be
validated on node side and not on hardware-wallet side.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4WDF4I7UUIB4PNIPD2M73S3EXMLANCNFSM4UU6SNIA>.
|
Co-authored-by: Wolfgang Welz <welzwo@gmail.com>
Let A be the address that should hold the dust outputs' balances. Let S be the sum of all the amounts of all unspent `SigLockedDustAllowanceOutputs` on A. Then, the maximum number of allowed dust outputs on A is S divided by 100,000 and rounded down, i.e. 10 outputs for each 1 Mi deposited. | ||
However, regardless of S, the number of dust outputs must never exceed 100 per address. | ||
|
||
The amount of a `SigLockedDustAllowanceOutput` must be at least 1 Mi. Apart from this, `SigLockedDustAllowanceOutputs` are processed identical to `SigLockedSingleOutput`. The transaction validation as defined in [Draft RFC-18](https://github.com/luca-moser/protocol-rfcs/blob/signed-tx-payload/text/0000-transaction-payload/0000-transaction-payload.md), however, needs to be adapted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The amount of a
SigLockedDustAllowanceOutput
must be at least 1 Mi.
This is already said right after in the syntactical validation, bit repetitive.
Rendered