Topic: BTCD is no more - page 334. (Read 1328507 times)

Interesting thing I found that, on Windows 8 there is more active connection to BitcoinDark network (found 67+) rather than Windows 7. I used to get only 16 active connections from Win7 but getting 27 today morning. Don't know anything about Mac or Linux. Just for the clarification, used 2 different laptops on different networks.

BitcoinDark Block Explorer: http://stakexplorer.com:1234

Enjoy it.

Donations to R9kZxVTw2hk4oU8cKbSPcjFxnE7wBf1rWr are appreciated.

I can provide the raw data to the GUI. As to all the fancy graphics, etc. that is not me

While on this topic, will there be an indicator for ‘teleport system status’ in the client, such as number of privacy servers currently running? Just to give users peace of mind that everything they need is ready.

Yeah, my only side point had been, if it can be preentered the person getting paid could enter it when requesting payment so the person paying doesn't need wait for them to get around to entering it and can just pay promptly when they get the message to pay. At that point it would be more about time efficiency for the person getting paid to preenter for the payment. You mentioned the lack of need for it in that order as it's being sent to a node which has a specific public address. It technically wouldn't add more than the initial idea to do, it was just an additional use of it. If a person being paid can preenter the pass a person paying them gives them. It also means the inverse is completely possible, even if not necessary, without additional effort.

Edit: people can be clumsy, if someone owed me a large payment, I'd like to be sure there was no way they could fat finger it and send it to the last person they paid by accident. I may be more sure of my ability, but others, one little safeguard and they can't accidentally send it off to the address they paid 5 minutes before instead. I've watched someone walk up to an ATM with an OUT OF ORDER sign OVER the screen, tear it off and try and use it, then get mad it didnt work. Also heard of people losing their cards that way then getting mad. Spoofing may be prevented, but idiotproofing is nice as well.

Wouldnt having a password that the destination had to put in protect against your scenario above?

Yeah, it makes sense. As I mentioned though, some people accidentally send to an address they sent to in the past instead of the one they meant to sent to, like the guy sending to the MtGox addy. People do screw up and send coin to a recently used address instead of the one they mean to, and a recently used address can very well still be alive and active. But it's all up to you, if I were ever able to send a large value teleport it would make me feel better even with checking 20 times that I have the right address in the field it won't accept if it's incorrect but a live node.

I once had a strange bug in the eBay shipping applet caused my current shipping label to print with the address the previous one should have. One person wound up getting two items, 3 the wrong item and I was very confused as I only ever box one item at a time, print the label, attach to box, close the window, box the next item open the shipping for that, print label, attach to box, close. The labels even matched the onscreen info. You would think that would leave no way to have a wrong label, but I guess not. I would really DREAD having something happen like that while if I were sending out a bunch of large payments in a row from what ever source I was getting addresses from. All good live addresses, but the system feeding me them had choked on itself.

That would be awesome.....Thank you once again......you are seriously the most active dev I've every seen......I've followed you from NXT, BBR and now here.....there is no escape LOL  

with teleport you are not sending to an address, but rather to a node, which happens to have a specific public address. They can make a new public address, but it would end up on the same destination computer.

I hope that makes sense. teleport is connecting node to node (via privacyServers) and I assign each node a public address based on what the user puts in the config file. You can send to BTCD or BTC or NXT address, all go to the same node. Also, if a person is running their privacyServer on the same computer, you could even send to the privacyServer's public address and it would also end up on that computer

So if you are sending to a pubaddr and it exists and it is responding, it is very hard for it to not be your intended destination. I prevent spoofing by requiring all packets to be signed by the linked NXT address, so some random person cant just claim a pubaddr for themselves.

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..

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

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

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

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.

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

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.

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.

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

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

James,

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