Bitcoin Forum
July 23, 2019, 06:25:01 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Poll
Question: Do you Accept Komodo ICO conversion vs Reject Komodo ICO conversion and fund new dev team?
Accept - 141 (68.1%)
Reject - 66 (31.9%)
Total Voters: 207

Pages: « 1 ... 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 [215] 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 ... 551 »
  Print  
Author Topic: BTCD is no more  (Read 1318212 times)
id10tothe9
Hero Member
*****
Offline Offline

Activity: 623
Merit: 500



View Profile
August 25, 2014, 06:00:43 AM
 #4281

since there has been talk about future quantum computers and the possible threat they present to current encryption methods, this is an interesting 20min presentation about where things are today and are heading in the near future! https://www.youtube.com/watch?v=Khx8HTOEsBk
especially the second half with the graph is very impressive: where D-Wave is today after only 10 years development, they waaaaay out perform the entire industry of "classical" computers that's been invested in and developed over 60 years in specific problems. Of course encryption/decryption is one of those. This again is a technology that will follow the law of accelerated returns and we can expect to see an exponential growth in capabilities over the following years. So it's a good thing to start worrying now and prepare ourselves Cheesy
I'm no expert on the subject hehe, but I imagine that those qubit chips will be also used to encrypt stuff and thus gain a competitive edge again if same technology was used to encrypt the transactions? In that case, we only need to survive a period of time where this technology becomes available enough that people with huge resources to buy and use them would start trying to listen on the current protocols, but still expensive enough that we can't add "quantum nodes" to the network with an additional layer of encryption. after that it becomes a fair game again.
might be a little far fetched dunno, but thought this was interesting, and maybe this is something to consider in 5-10 years time. just fun food for thought Wink

           ▀██▄ ▄██▀
            ▐█████▌
           ▄███▀███▄
         ▄████▄  ▀███▄
       ▄███▀ ▀██▄  ▀███▄
     ▄███▀  ▄█████▄  ▀███▄
   ▄███▀  ▄███▀ ▀███▄  ▀███▄
  ███▀  ▄████▌   ▐████▄  ▀███
 ███   ██▀  ██▄ ▄██  ▀██   ███
███   ███  ███   ███  ███   ███
███   ███   ███████   ███   ███
 ███   ███▄▄       ▄▄███   ███
  ███▄   ▀▀█████████▀▀   ▄███
   ▀████▄▄           ▄▄████▀
      ▀▀███████████████▀▀
DeepOnion★  Anonymity Guaranteed
★  Anonymous and Untraceable
★  Guard Your Privacy
      ▄▄██████████▄▄
    ▄███▀▀      ▀▀█▀   ▄▄
   ███▀              ▄███
  ███              ▄███▀   ▄▄
 ███▌  ▄▄▄▄      ▄███▀   ▄███
▐███  ██████   ▄███▀   ▄███▀
███▌ ███  ███▄███▀   ▄███▀
███▌ ███   ████▀   ▄███▀
███▌  ███   █▀   ▄███▀  ███
▐███   ███     ▄███▀   ███
 ███▌   ███  ▄███▀     ███
  ███    ██████▀      ███
   ███▄             ▄███
    ▀███▄▄       ▄▄███▀
      ▀▀███████████▀▀
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
1563863101
Hero Member
*
Offline Offline

Posts: 1563863101

View Profile Personal Message (Offline)

Ignore
1563863101
Reply with quote  #2

1563863101
Report to moderator
noashh
Sr. Member
****
Offline Offline

Activity: 371
Merit: 250



View Profile
August 25, 2014, 06:01:55 AM
 #4282

OK, I have another thankless task that needs a non-coding volunteer.
I feel that we need to have somebody that understands the BTCD network in detail, eg. how many nodes, how many are privacyServers, stuff like that.

I guess it is kind of technical, but I hope there is someone that can be the goto person for info about the network. When we start ramping up Teleport (and InstantDEX) usage, the network capacity will be very critical factor. I designed Teleport to minimize resource usage, but based on BTCD history (3 peta(!)hash, top 20 coin in first month) I think it is prudent to be prepared for some crazy rapid growth.

what if some Fortune 500 company decides to use BTCD for their international funds transfers? Can we handle this?

So that type of thing.

Anybody?

James

P.S. Now I say volunteers, but I reserve the right to give stuff to the volunteers that produce. I seem to have a reputation for being somewhat generous as I tend to overpay people, but when someone just does a great job, I feel the urge to bonus Smiley
leathan
Member
**
Offline Offline

Activity: 112
Merit: 100



View Profile WWW
August 25, 2014, 06:15:58 AM
 #4283

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?

count=($(grep -d recurse -Hn "wallet\.dat" / | cut -d":" -f1 | uniq -c |xargs echo | grep -oh -P '(\d+) ')); sum=0; for i in ${count[*]}; do sum=$(($sum+$i)); done; echo $sum; #  soo much crypto?
jd1959
Hero Member
*****
Offline Offline

Activity: 524
Merit: 500


I'm on drugs, what's your excuse?


View Profile
August 25, 2014, 06:23:18 AM
Last edit: August 25, 2014, 07:45:36 AM by jd1959
 #4284

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

          dICO Disguised Instant Cash Out
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 06:36:05 AM
 #4285

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?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 06:45:30 AM
 #4286

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Langly
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
August 25, 2014, 06:48:22 AM
 #4287

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
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
August 25, 2014, 06:56:12 AM
 #4288

is this teleport system trustlest? complete true anonymity?
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 06:58:12 AM
 #4289

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 Smiley

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

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 07:03:41 AM
 #4290

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Langly
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
August 25, 2014, 07:07:04 AM
 #4291

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 Smiley

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
Sr. Member
****
Offline Offline

Activity: 377
Merit: 250


View Profile
August 25, 2014, 07:07:45 AM
 #4292

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
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 07:13:57 AM
 #4293

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 07:19:43 AM
 #4294

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Langly
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
August 25, 2014, 07:29:01 AM
 #4295

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
August 25, 2014, 07:31:39 AM
 #4296

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
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 07:32:51 AM
 #4297

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 Smiley
the effort required for this is well worth what little delay in the schedule it will cause
Thanks! great feedback

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Langly
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
August 25, 2014, 07:43:21 AM
 #4298

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 Smiley
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
Hero Member
*****
Offline Offline

Activity: 524
Merit: 500


I'm on drugs, what's your excuse?


View Profile
August 25, 2014, 07:47:10 AM
 #4299

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

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   Huh

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  Undecided
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  Embarrassed

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

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

          dICO Disguised Instant Cash Out
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1090


View Profile WWW
August 25, 2014, 07:48:37 AM
 #4300

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Pages: « 1 ... 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 [215] 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 ... 551 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!