BTCD is no more

[leathan]

Is there any way I can help? I can code in most languages? I think this is the crypto that I most like... I think.. I have some ideas but am nervous to just throw them out there .. and im noob to the group.

Does BTCD have an irc?

[1713550191]

1713550191

[1713550191]

1713550191

[jd1959]

I've deleted my old debug file and run wallet to create new one, I've posted as gist

I did it this way as the old file was huge and kept timing out uploading

https://gist.github.com/anonymous/355c90994f02f8f73d9d

had a similar problem with another wallet ages ago.....the problem there was someone / people running old wallet that kept requesting data but couldn't use the data, so request again

Also noticed balance of data usage about 60/40   send receive....any ideas ?

Jon

[jl777]

Is there any way I can help? I can code in most languages? I think this is the crypto that I most like... I think.. I have some ideas but am nervous to just throw them out there .. and im noob to the group.

Does BTCD have an irc?

do you know C?
any examples of your code, eg. on github?

Alternatively can you get stuff to compile on Windows or Mac?

[jl777]

Maybe we should also translate to some other major languages?

Shall I get some price quotes from professional high quality translation services or is it not necessary to translate into more languages atm?

I think we are OK for now, though if we have volunteer translators that would be great

[Langly]

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

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?

[darkslash]

is this teleport system trustlest? complete true anonymity?

[jl777]

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

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?

the only way the transporter will even start teleporting is if it gets confirmation from the other side that everthing is ready to go. Just like in Star Trek

so if it is simple a bad address, then nothing would happen.

James

[jl777]

is this teleport system trustlest? complete true anonymity?

That is my opinion, we are seeking skilled C coder to verify

The creator and extractor of telepods will not be anon, but once in the system, the teleports are quite private. I have some scenarios that require brute force logging of all UDP packets from all nodes and Quantum computer from future that cracks encryption. This seems pretty cost prohibitive and also in the future by years. I think it would be much cheaper to simply confiscate a significant number of teleport nodes, eg. all users!, or maybe use the magic radio stuff on each node to just get the info in unencrypted form. Of course coordinating a global confiscation of innocent citizen's computers will hopefully not be anything that can be done.

So we are back to brute force logging of all UDP and Quantum computers from the future.
Realistically, I think they wont bother trying to snoop on normal peoples and just put physical surveillance on actual suspected criminals.

James

[Langly]

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

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?

the only way the transporter will even start teleporting is if it gets confirmation from the other side that everthing is ready to go. Just like in Star Trek

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.

[blackyblack]

James,

why do I get a lot of jl777 messages on BTCD blockchain on debug.log? There is 70MB of it already and growing.

[jl777]

James,

why do I get a lot of jl777 messages on BTCD blockchain on debug.log? There is 70MB of it already and growing.

this is due to test message that ended up being propagated and it seems that before it is expired, it makes copies of itself. Kind of like tribbles

[jl777]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

[Langly]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

Wouldn't be hard required, you could just tell the payee to input it. It could be entered any time like some form of preauth code. Just went you arrange what ever you are paying them for, have them entire it, wouldn't even need to be long or complicated, just a small layer to prevent any chance of accident like some of the recent posts I've seen of people accidentally sending BTC to their old MtGox address. Exactly as you state, just a password to activate the transporter, but not required outright. Calling back on the Tricorded to inform the landing party it is now safe to beam down, all clear signal from the address you are sending to. No signal, no teleport. For a lot of small payments people wouldn't bother using it, for large ones, it would be a nice safeguard to take out the risk of even the smallest slip, IE sending to a past address in your history instead, or a derpy copypaste and somehow got a different address. Since you likely have some form of communication with whoever you are paying, giving them one keyword to enter would be simple, even if preentered to be ready for the teleport.

[IceColdTommy]

The multipool at http://bitcoindark.net/multipool will continue to runas it was so far, but there will be some changes done and some more servers added so we can get the most profitability. This decision is due to some PM's sent to me that i should continue running it and the fact that everyday it has more members and performs better that the previous day. I am sorry that the global speed stats are still not shown but i will show them with the new release of the multipool which i hope it will happen in 48 hours. Thanks for the support.

EDIT: Yesterday shift got about 128 BTCD sent to miners.

[jl777]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

Wouldn't be hard required, you could just tell the payee to input it. It could be entered any time like some form of preauth code. Just went you arrange what ever you are paying them for, have them entire it, wouldn't even need to be long or complicated, just a small layer to prevent any chance of accident like some of the recent posts I've seen of people accidentally sending BTC to their old MtGox address. Exactly as you state, just a password to activate the transporter, but not required outright. Calling back on the Tricorded to inform the landing party it is now safe to beam down, all clear signal from the address you are sending to. No signal, no teleport. For a lot of small payments people wouldn't bother using it, for large ones, it would be a nice safeguard to take out the risk of even the smallest slip, IE sending to a past address in your history instead, or a derpy copypaste and somehow got a different address. Since you likely have some form of communication with whoever you are paying, giving them one keyword to enter would be simple, even if preentered to be ready for the teleport.

I've already added it to my todo list
the effort required for this is well worth what little delay in the schedule it will cause
Thanks! great feedback

James

[Langly]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

Wouldn't be hard required, you could just tell the payee to input it. It could be entered any time like some form of preauth code. Just went you arrange what ever you are paying them for, have them entire it, wouldn't even need to be long or complicated, just a small layer to prevent any chance of accident like some of the recent posts I've seen of people accidentally sending BTC to their old MtGox address. Exactly as you state, just a password to activate the transporter, but not required outright. Calling back on the Tricorded to inform the landing party it is now safe to beam down, all clear signal from the address you are sending to. No signal, no teleport. For a lot of small payments people wouldn't bother using it, for large ones, it would be a nice safeguard to take out the risk of even the smallest slip, IE sending to a past address in your history instead, or a derpy copypaste and somehow got a different address. Since you likely have some form of communication with whoever you are paying, giving them one keyword to enter would be simple, even if preentered to be ready for the teleport.

I've already added it to my todo list
the effort required for this is well worth what little delay in the schedule it will cause
Thanks! great feedback

James

Glad it's of use. I was also just thinking, if it can be preentered, that would also mean the payee could give the payer the code to use as well. Just turning things from a 1 party initiated teleport, into a 2 party. Flare, green light, some signal you've got the right spot. Can't go beaming the captain down into solid rock because we merely used a fixed set of coordinates now can we. Payer is given address plus TX auth code to enter if the payee chooses to use the feature.

[jd1959]

Not wishing to interfere with the current debate it's been interesting to say the least...and congrates to dev team......love your work  

However my wallet is still chewing way too much data to leave it open for staking.....I know I've only got open it and sync a couple of times a day to increase weight.

That being said it does not help maintain the network doing it like that......I would really like to be told how to block nodes in wallet, I can't find any add/remove nodes command

I know I'm far from the smartest guy......If they ever release a coin with proof of stupidity it'll have my picture on it. So if anybody can tell me how to go about it I will be very grateful

Jon  

do you have access to a different machine? our tests are not seeing any such massive bandwidth usage, so we are thinking maybe it is some other program? so if a different computer does same thing, we can narrow problem down

Have installed every thing on a different computer after monitoring for 20 minutes 9.27 Megabytes of data times 72 = 667.24 megs in 24 hours, it still seems too much to me

Jon  

like crackfoo says, until the blockchain is caught up, bandwidth use would be close to saturation levels for your channel.
need data for after you are caught up

Oh, have you synchronized your clock? A lot of times excess packets are caused by a node that has the wrong time and the other nodes end up sending a lot of packets to it (and vice versa)

Use ntp or equivalent

James

I'm not sure about syncing time ......I just pick my time zone with windows and everything looks fine......I'm running a couple of other wallets with no excess data usage on ether.

However if you can tell me how to sync time on windows 7, I will follow your instructions and see if that sorts it.....Thank you for your help, I know your dealing with much more important things than my incompetence

Jon  

P.S  I just got 100 cheap JLH on polo awesome  

http://mintywhite.com/windows-7/7maintenance/windows-seven-7-sync-system-clock-with-internet-time-how-to/

im using ptbtime1.ptb.de myself. it syncs to the atomic clock of the PTB onwed by the german department of energy

Have followed instructions in link, unfortunately it tells me that I'm already sycned with  'time.windows.com' and set to check on a regular basis....so I don't think it's a time issue on my end.

Jon

I've deleted my old debug file and run wallet to create new one, I've posted as gist

I did it this way as the old file was huge and kept timing out uploading

https://gist.github.com/anonymous/355c90994f02f8f73d9d

had a similar problem with another wallet ages ago.....the problem there was someone / people running old wallet that kept requesting data but couldn't use the data, so request again

Also noticed balance of data usage about 60/40   send receive....any ideas ?

Jon

[jl777]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

Wouldn't be hard required, you could just tell the payee to input it. It could be entered any time like some form of preauth code. Just went you arrange what ever you are paying them for, have them entire it, wouldn't even need to be long or complicated, just a small layer to prevent any chance of accident like some of the recent posts I've seen of people accidentally sending BTC to their old MtGox address. Exactly as you state, just a password to activate the transporter, but not required outright. Calling back on the Tricorded to inform the landing party it is now safe to beam down, all clear signal from the address you are sending to. No signal, no teleport. For a lot of small payments people wouldn't bother using it, for large ones, it would be a nice safeguard to take out the risk of even the smallest slip, IE sending to a past address in your history instead, or a derpy copypaste and somehow got a different address. Since you likely have some form of communication with whoever you are paying, giving them one keyword to enter would be simple, even if preentered to be ready for the teleport.

I've already added it to my todo list
the effort required for this is well worth what little delay in the schedule it will cause
Thanks! great feedback

James

Glad it's of use. I was also just thinking, if it can be preentered, that would also mean the payee could give the payer the code to use as well. Just turning things from a 1 party initiated teleport, into a 2 party. Flare, green light, some signal you've got the right spot. Can't go beaming the captain down into solid rock because we merely used a fixed set of coordinates now can we. Payer is given address plus TX auth code to enter if the payee chooses to use the feature.

the public address is essentially this.
each teleport is sent to a public address that was published before, without this there is no place to teleport to
so I think there is no need for this variant.
It it is really wanted, the payee just needs to make a new public address and get that to the payer

[jl777]

I did it this way as the old file was huge and kept timing out uploading

https://gist.github.com/anonymous/355c90994f02f8f73d9d

had a similar problem with another wallet ages ago.....the problem there was someone / people running old wallet that kept requesting data but couldn't use the data, so request again

Also noticed balance of data usage about 60/40   send receive....any ideas ?

it seems that you are connected to a node that is sending many of these messages. the new release will fix this.
actually we might be able to make a test version for you to run and then you can verify if it fixes the problem
hopefully it will be available soon

James

[Langly]

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.

there is handshaking between the sender and receiver, but it is initiated by the sender.
I could add a whitelist of people you would accept teleports from, but wouldnt most people set that to *

If we required the destination to have to put some sort of code he got from the sender via different channel, then each tx becomes quite an involved process and also not really automated. However as an option it would be cool to be able to have a password that needs to be typed in by the recipient to activate the transporter.

You would send this via email, phone, SMS, etc. and when the transporter sequence is started, it waits for a password to be input. Something like that?

James

Wouldn't be hard required, you could just tell the payee to input it. It could be entered any time like some form of preauth code. Just went you arrange what ever you are paying them for, have them entire it, wouldn't even need to be long or complicated, just a small layer to prevent any chance of accident like some of the recent posts I've seen of people accidentally sending BTC to their old MtGox address. Exactly as you state, just a password to activate the transporter, but not required outright. Calling back on the Tricorded to inform the landing party it is now safe to beam down, all clear signal from the address you are sending to. No signal, no teleport. For a lot of small payments people wouldn't bother using it, for large ones, it would be a nice safeguard to take out the risk of even the smallest slip, IE sending to a past address in your history instead, or a derpy copypaste and somehow got a different address. Since you likely have some form of communication with whoever you are paying, giving them one keyword to enter would be simple, even if preentered to be ready for the teleport.

I've already added it to my todo list
the effort required for this is well worth what little delay in the schedule it will cause
Thanks! great feedback

James

Glad it's of use. I was also just thinking, if it can be preentered, that would also mean the payee could give the payer the code to use as well. Just turning things from a 1 party initiated teleport, into a 2 party. Flare, green light, some signal you've got the right spot. Can't go beaming the captain down into solid rock because we merely used a fixed set of coordinates now can we. Payer is given address plus TX auth code to enter if the payee chooses to use the feature.

the public address is essentially this.
each teleport is sent to a public address that was published before, without this there is no place to teleport to
so I think there is no need for this variant.
It it is really wanted, the payee just needs to make a new public address and get that to the payer

Ah, yeah that work out, it would just be nice to have something when to people are transferring a large sum to rule out accidentally sending to an old but active address that could accept payment. Send one payment to an address, go to send another, accidentally send second to the last. Heck I derped on an NOMP pool shortly for the BTCD mining after switching pools and making new bat files a few times. That was because for some reason my Synergy that links two of my systems was only sharing clipboard in one direction. I cut, repasted to make sure it copied correctly, switched the mouse over to the other system and pasted into the bat file. Bit later looking at pool stats, wait what? That's not the right address... I had to completely kill and restart all the synergy processes to get two way clipboard sharing working again. That was just weird, but that's exactly how freak accidents happen..