Now I know why I had to drag myself to do the accounting stuff. There is about 1000 lines of code that needs to be written. Nothing difficult, just a lot of code to deal with JSON'izing the internal data structures so it can be displayed in debug console (and GUI)
At least I am finally on this, it will actually really help debugging, as I just display what the Teleport system things the internal state is and this will be much faster to debug than most other methods. So, I just have to tell myself I am just writing code needed for fast debugging.
anyway, there turned out to be a few more states than I expected. I am using separate bits, even though when the state changes, the most significant bit represents the actual state. Just though it might come in handy to see the history of each sequence, which this allows
#define TRANSPORTER_SEND 1
#define TRANSPORTER_RECV 2
#define TRANSPORTER_GOTACK 4
#define TRANSPORTER_TRANSFERRED 8
#define TRANSPORTER_ABORTED 64
#define TRANSPORTER_COMPLETED 128
Telepods themselves have a similar, but yet different set of states they can be in:
#define PODSTATE_SENT 1
#define PODSTATE_RECV 2
#define PODSTATE_GOTACK 4
#define PODSTATE_CONFIRMED 8
#define PODSTATE_TRUSTED 16
#define PODSTATE_CLONED 32
#define PODSTATE_ABORTED 64
#define PODSTATE_SPENT 128
With the potentially very long clonesmear time, I am thinking that there should be no timeout for a telepod sending, but rather a user initiated abort mechanism. This way, if there is a dispute or you lose contact with the destination acct, you can manually abort the remaining teleport sequence. Actually, the telepods are either all sent successfully or not pretty early in the sequence and only after there is a TRANSPORTER_GOTACK event indicating the destination knows what to expect.
If a teleport is aborted, all uncloned telepods will be cloned by the sender, so this is something you dont want to do unless you have to. It just loses any aging the telepods have had and just creates extra tx, but if you have to, you have to.
Once benefit of this mechanism is that it is actually possible to partially cancel a payment! Not sure if you ever clicked send and then the coins are on their way and nothing can be done. With teleport, the transaction is broken up into standard denominations and then using the process described the other day sent to the destination account. At this point the telepod is shared between sender and destination. As soon as the destination account clones it, then the sender cannot access it anymore. However, with teleport there is the clonesmear parameter and I am using one hour as a default, so each telepod will take up to an hour to be cloned. This means that even some minutes after sending, you can abort the transfer and if you are willing to create a possibly noticeable frenzy of cloning activity, you could prevent the destination acct from cashing any of the telepods.
Of course, if you do this, you wont get any credit for payment from the destination, but if it was something sent accidentally to the wrong address, on average you should be able to prevent the vast majority of funds from being delivered to the destination account. If the destination account has a clonesmear time set to 0 though, this wont be available. I knew about this property before but I dont think I ever wrote about the "unsend" feature that is implicit with Teleport.
James
At least I am finally on this, it will actually really help debugging, as I just display what the Teleport system things the internal state is and this will be much faster to debug than most other methods. So, I just have to tell myself I am just writing code needed for fast debugging.
anyway, there turned out to be a few more states than I expected. I am using separate bits, even though when the state changes, the most significant bit represents the actual state. Just though it might come in handy to see the history of each sequence, which this allows
#define TRANSPORTER_SEND 1
#define TRANSPORTER_RECV 2
#define TRANSPORTER_GOTACK 4
#define TRANSPORTER_TRANSFERRED 8
#define TRANSPORTER_ABORTED 64
#define TRANSPORTER_COMPLETED 128
Telepods themselves have a similar, but yet different set of states they can be in:
#define PODSTATE_SENT 1
#define PODSTATE_RECV 2
#define PODSTATE_GOTACK 4
#define PODSTATE_CONFIRMED 8
#define PODSTATE_TRUSTED 16
#define PODSTATE_CLONED 32
#define PODSTATE_ABORTED 64
#define PODSTATE_SPENT 128
With the potentially very long clonesmear time, I am thinking that there should be no timeout for a telepod sending, but rather a user initiated abort mechanism. This way, if there is a dispute or you lose contact with the destination acct, you can manually abort the remaining teleport sequence. Actually, the telepods are either all sent successfully or not pretty early in the sequence and only after there is a TRANSPORTER_GOTACK event indicating the destination knows what to expect.
If a teleport is aborted, all uncloned telepods will be cloned by the sender, so this is something you dont want to do unless you have to. It just loses any aging the telepods have had and just creates extra tx, but if you have to, you have to.
Once benefit of this mechanism is that it is actually possible to partially cancel a payment! Not sure if you ever clicked send and then the coins are on their way and nothing can be done. With teleport, the transaction is broken up into standard denominations and then using the process described the other day sent to the destination account. At this point the telepod is shared between sender and destination. As soon as the destination account clones it, then the sender cannot access it anymore. However, with teleport there is the clonesmear parameter and I am using one hour as a default, so each telepod will take up to an hour to be cloned. This means that even some minutes after sending, you can abort the transfer and if you are willing to create a possibly noticeable frenzy of cloning activity, you could prevent the destination acct from cashing any of the telepods.
Of course, if you do this, you wont get any credit for payment from the destination, but if it was something sent accidentally to the wrong address, on average you should be able to prevent the vast majority of funds from being delivered to the destination account. If the destination account has a clonesmear time set to 0 though, this wont be available. I knew about this property before but I dont think I ever wrote about the "unsend" feature that is implicit with Teleport.
James
That would also be useful in cases where someone slips up and sends to the wrong address and would otherwise have burned their coins. If the address isn't in use would the retraction be indefinite as it would never actively clone?
so if it is simple a bad address, then nothing would happen.
James
What do I do if I wind up with two Rikers that both believe they are the original, or split Kirks?
Would it be possible to have them optionally do something on their end to verify the address so it wont start to prevent address replacement on webpages or the like. Something they can preenter otherwise the teleporter wont even initiate, or is something like that already included, I've read over a bit of things but also been super busy lately.
From the "Of course, if you do this, you wont get any credit for payment from the destination, but if it was something sent accidentally to the wrong address, on average you should be able to prevent the vast majority of funds from being delivered to the destination account." it seems its not. But simply having something that can be entered on the receiving end if you are in communication with the person you are sending to could keep it from being able to go to the wrong address completely. Although that may overly complicate things.
