Discussion: A Proposal for Reusable Addresses


Author
Message
HusQy
HusQy
Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)
Group: Moderators
Posts: 8, Visits: 0
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.
caseyy
c
Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)
Group: Forum Members
Posts: 4, Visits: 0
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.

1). Do you have to make sure the initial location of the random walk (rw) particles are in strategic depth and position inside the Tangle such that they will pass through your previous transaction?
2). When you say the transactions are in correct order, are they in partial order or total order? If partial order, is it sufficient for your reusable address proposal?
HusQy
HusQy
Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)
Group: Moderators
Posts: 8, Visits: 0
caseyy - 16 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.

1). Do you have to make sure the initial location of the random walk (rw) particles are in strategic depth and position inside the Tangle such that they will pass through your previous transaction?
2). When you say the transactions are in correct order, are they in partial order or total order? If partial order, is it sufficient for your reusable address proposal?

regarding 1.) At the moment we start at a milestone that is "n" milestones in the past (relative to the latest solid milestone) so it is deterministic where we start the random walk. The depth parameter can directly be controlled in the API call "getTransactionsToApprove" (see https://iota.readme.io/reference#gettransactionstoapprove). It should be bigger than 15 to reach a good randomness. The deeper you go the more potential paths exist that you can take - so a deeper depth is usually better for the tangle.

This means you will see the transactions in the order that you attached them to the tangle. Assuming that you attached them in the correct order, you will "walk" through them in the correct order. It is of course possible that you will arrive at a later spend through the 2nd path (branch vs trunk) and therefore skip the previous spend but this "problem" also exists with the remainder approach where you might skip the transaction that funds the remainder address. In this case the 2nd spend would be considered invalid (the same way as the spend from an unprocessed remainder address would be considered invalid).

Whenever we face an invalid transaction we apply a backtracking strategy and try another path (until we find 2 valid tips).

regarding 2.) Since it is possible that we "skip" transactions (due to the fact that there are usually 2 path that exist to arrive at any given point), they are only in partial order.


If you would set the "trunk" to be the same transaction as the "branch", you could prevent the possibility of reaching the 2nd spend without having walked through the first one but that would also decrease the chances of your transaction to be reached.

Since we plan to only sweep the balances every now and then (wallets could implement sth like only sweep if your last sweep is not older than n minutes) this is something that can be worked around to be practically irrelevant.
caseyy
c
Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)
Group: Forum Members
Posts: 4, Visits: 0
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.

1). Do you have to make sure the initial location of the random walk (rw) particles are in strategic depth and position inside the Tangle such that they will pass through your previous transaction?
2). When you say the transactions are in correct order, are they in partial order or total order? If partial order, is it sufficient for your reusable address proposal?

regarding 1.) At the moment we start at a milestone that is "n" milestones in the past (relative to the latest solid milestone) so it is deterministic where we start the random walk. The depth parameter can directly be controlled in the API call "getTransactionsToApprove" (see https://iota.readme.io/reference#gettransactionstoapprove). It should be bigger than 15 to reach a good randomness. The deeper you go the more potential paths exist that you can take - so a deeper depth is usually better for the tangle.

This means you will see the transactions in the order that you attached them to the tangle. Assuming that you attached them in the correct order, you will "walk" through them in the correct order. It is of course possible that you will arrive at a later spend through the 2nd path (branch vs trunk) and therefore skip the previous spend but this "problem" also exists with the remainder approach where you might skip the transaction that funds the remainder address. In this case the 2nd spend would be considered invalid (the same way as the spend from an unprocessed remainder address would be considered invalid).

Whenever we face an invalid transaction we apply a backtracking strategy and try another path (until we find 2 valid tips).

regarding 2.) Since it is possible that we "skip" transactions (due to the fact that there are usually 2 path that exist to arrive at any given point), they are only in partial order.


If you would set the "trunk" to be the same transaction as the "branch", you could prevent the possibility of reaching the 2nd spend without having walked through the first one but that would also decrease the chances of your transaction to be reached.

Since we plan to only sweep the balances every now and then (wallets could implement sth like only sweep if your last sweep is not older than n minutes) this is something that can be worked around to be practically irrelevant.

Setting the "trunk" (Tip 0)to be the same transaction as the "branch" (Tip 1), are you saying only one tip to approve, that it will end up like ''chain'' instead of DAG? That is why it is undesirable?
I appologize if my questions are naive. I understand the inherent partial order of DAG. Let say, if DAG were able to be total ordered(perhaps using modified DFS) first and logically timestamped, and the TSA were to check this ordering timestamping also(on top of checking the accumulated weight) , will it helps?


HusQy
HusQy
Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)Attaching to Tangle (102 reputation)
Group: Moderators
Posts: 8, Visits: 0
caseyy - 17 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.

1). Do you have to make sure the initial location of the random walk (rw) particles are in strategic depth and position inside the Tangle such that they will pass through your previous transaction?
2). When you say the transactions are in correct order, are they in partial order or total order? If partial order, is it sufficient for your reusable address proposal?

regarding 1.) At the moment we start at a milestone that is "n" milestones in the past (relative to the latest solid milestone) so it is deterministic where we start the random walk. The depth parameter can directly be controlled in the API call "getTransactionsToApprove" (see https://iota.readme.io/reference#gettransactionstoapprove). It should be bigger than 15 to reach a good randomness. The deeper you go the more potential paths exist that you can take - so a deeper depth is usually better for the tangle.

This means you will see the transactions in the order that you attached them to the tangle. Assuming that you attached them in the correct order, you will "walk" through them in the correct order. It is of course possible that you will arrive at a later spend through the 2nd path (branch vs trunk) and therefore skip the previous spend but this "problem" also exists with the remainder approach where you might skip the transaction that funds the remainder address. In this case the 2nd spend would be considered invalid (the same way as the spend from an unprocessed remainder address would be considered invalid).

Whenever we face an invalid transaction we apply a backtracking strategy and try another path (until we find 2 valid tips).

regarding 2.) Since it is possible that we "skip" transactions (due to the fact that there are usually 2 path that exist to arrive at any given point), they are only in partial order.


If you would set the "trunk" to be the same transaction as the "branch", you could prevent the possibility of reaching the 2nd spend without having walked through the first one but that would also decrease the chances of your transaction to be reached.

Since we plan to only sweep the balances every now and then (wallets could implement sth like only sweep if your last sweep is not older than n minutes) this is something that can be worked around to be practically irrelevant.

Setting the "trunk" (Tip 0)to be the same transaction as the "branch" (Tip 1), are you saying only one tip to approve, that it will end up like ''chain'' instead of DAG? That is why it is undesirable?
I appologize if my questions are naive. I understand the inherent partial order of DAG. Let say, if DAG were able to be total ordered(perhaps using modified DFS) first and logically timestamped, and the TSA were to check this ordering timestamping also(on top of checking the accumulated weight) , will it helps?


Yes exactly, you would only choose 1 Tip in this case and this one transaction would then indeed be "chained" to the previous one. This is possible already and we see it happen in the tangle, today.

But as i already said, this slightly decreases the chance of your transaction to be picked up by other nodes doing tip selection because there exists only 1 path to reach that chained transaction (instead of 2). It is not necessarily bad for the tangle because other people would still reference 2 tips. Since everybody wants their transactions to be picked up by other nodes it is in everybody interest to reference two other transactions. In math terms you call this a nash equilibirum - a rule that (even tho it doesnt get enforced) will be followed my most participants voluntarily because it is in their very own interest.

It would maybe even make sense to "chain" consecutive sweeps together this way because if the 2nd path to my transaction skips the first sweep - this path would always consider my sweep invalid anyway. And having an invalid path is as good as having just 1 anyway. Ideally we would select two tips that both indirectly reference my first spend. This can be done by starting the random walk at my first sweep instead of a milestone in the past. This can be done by providing the "reference" parameter in getTransactionToApprove.

Btw. these are very important things to ask and understand - the questions are not naive at all.

If the DAG could somehow be totally ordered this would solve A LOT of problems but since nodes and transaction creators can lie about the timestamps it is not easy (maybe even impossible) to achieve
Edited 2 Years Ago by HusQy
caseyy
c
Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)Attaching to Tangle (10 reputation)
Group: Forum Members
Posts: 4, Visits: 0
HusQy - 17 Oct 2018
caseyy - 17 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
HusQy - 16 Oct 2018
caseyy - 16 Oct 2018
As the order of dependent transactions now matters in your reusable address proposal, you are saying it can be resolved by directly or indirectly referencing a previous spend in a consecutive spend if the previous one is still pending. I presumed, it will be considered as another tip-selection method (TSM) apart from the existing MCMC random walk tip selection algo (TSA) for choosing two tips for approving by new transaction. However, will this disrupt the original intention of Tangle MCMC of keeping the width of Tangle (see L(t) in page 7 of Tangle white paper) from either expanding too wide or shrinking too narrow?? This is because your TSM may not end-up with the similar outcome (tips selection) if you were to use TSA.

No, its exactly the same tip selection algorithm.

They way the tip selection algorithm works is by choosing a transaction in the past and then "randomly" following their approvers until we arrive at a tip. Since the walk happens from past to present, you will see the transactions in their correct order.

1). Do you have to make sure the initial location of the random walk (rw) particles are in strategic depth and position inside the Tangle such that they will pass through your previous transaction?
2). When you say the transactions are in correct order, are they in partial order or total order? If partial order, is it sufficient for your reusable address proposal?

regarding 1.) At the moment we start at a milestone that is "n" milestones in the past (relative to the latest solid milestone) so it is deterministic where we start the random walk. The depth parameter can directly be controlled in the API call "getTransactionsToApprove" (see https://iota.readme.io/reference#gettransactionstoapprove). It should be bigger than 15 to reach a good randomness. The deeper you go the more potential paths exist that you can take - so a deeper depth is usually better for the tangle.

This means you will see the transactions in the order that you attached them to the tangle. Assuming that you attached them in the correct order, you will "walk" through them in the correct order. It is of course possible that you will arrive at a later spend through the 2nd path (branch vs trunk) and therefore skip the previous spend but this "problem" also exists with the remainder approach where you might skip the transaction that funds the remainder address. In this case the 2nd spend would be considered invalid (the same way as the spend from an unprocessed remainder address would be considered invalid).

Whenever we face an invalid transaction we apply a backtracking strategy and try another path (until we find 2 valid tips).

regarding 2.) Since it is possible that we "skip" transactions (due to the fact that there are usually 2 path that exist to arrive at any given point), they are only in partial order.


If you would set the "trunk" to be the same transaction as the "branch", you could prevent the possibility of reaching the 2nd spend without having walked through the first one but that would also decrease the chances of your transaction to be reached.

Since we plan to only sweep the balances every now and then (wallets could implement sth like only sweep if your last sweep is not older than n minutes) this is something that can be worked around to be practically irrelevant.

Setting the "trunk" (Tip 0)to be the same transaction as the "branch" (Tip 1), are you saying only one tip to approve, that it will end up like ''chain'' instead of DAG? That is why it is undesirable?
I appologize if my questions are naive. I understand the inherent partial order of DAG. Let say, if DAG were able to be total ordered(perhaps using modified DFS) first and logically timestamped, and the TSA were to check this ordering timestamping also(on top of checking the accumulated weight) , will it helps?


Yes exactly, you would only choose 1 Tip in this case and this one transaction would then indeed be "chained" to the previous one. This is possible already and we see it happen in the tangle, today.

But as i already said, this slightly decreases the chance of your transaction to be picked up by other nodes doing tip selection because there exists only 1 path to reach that chained transaction (instead of 2). It is not necessarily bad for the tangle because other people would still reference 2 tips. Since everybody wants their transactions to be picked up by other nodes it is in everybody interest to reference two other transactions. In math terms you call this a nash equilibirum - a rule that (even tho it doesnt get enforced) will be followed my most participants voluntarily because it is in their very own interest.

It would maybe even make sense to "chain" consecutive sweeps together this way because if the 2nd path to my transaction skips the first sweep - this path would always consider my sweep invalid anyway. And having an invalid path is as good as having just 1 anyway. Ideally we would select two tips that both indirectly reference my first spend. This can be done by starting the random walk at my first sweep instead of a milestone in the past. This can be done by providing the "reference" parameter in getTransactionToApprove.

Btw. these are very important things to ask and understand - the questions are not naive at all.

If the DAG could somehow be totally ordered this would solve A LOT of problems but since nodes and transaction creators can lie about the timestamps it is not easy (maybe even impossible) to achieve

Does IOTA Tangle use physical clocks or logical clock for its timestamping mechanism? Thanks.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search