I'm just banging my head because I didn't have many easily accessible BTC's few weeks ago when price was 0.0005...
I would be drinking some nice champagne right now
Anyway, I will stick to that plan
Topic: BTCD is no more - page 394. (Read 1328490 times)
Ha ha, I was thinking about cashing out a half of coins when it reached 0.005 - could've made 10 BTC easy money
I'm just banging my head because I didn't have many easily accessible BTC's few weeks ago when price was 0.0005...
I would be drinking some nice champagne right now
Anyway, I will stick to that plan
I'm just banging my head because I didn't have many easily accessible BTC's few weeks ago when price was 0.0005...
I would be drinking some nice champagne right now
Anyway, I will stick to that plan
waiting and waiting.. just as many of us wait for half life 3, you know its gonna be awesome but the waiting makes you hate it.
Half Life- maaaan that takes me back. Except, well, fuck that Orange Box.
yes! i like you already !there is a hl2 engine remake of hl1 and free. just a tip until you might consider to stop your staking and sell out for some lousy btc's
i remember hearing about that, then life got in the way and I forgot. Dwnldng now. Thanks for the reminder- this will be cool.
New logo reminds me of a local cafe
waiting and waiting.. just as many of us wait for half life 3, you know its gonna be awesome but the waiting makes you hate it.
Half Life- maaaan that takes me back. Except, well, fuck that Orange Box.
yes! i like you already !there is a hl2 engine remake of hl1 and free. just a tip until you might consider to stop your staking and sell out for some lousy btc's
waiting and waiting.. just as many of us wait for half life 3, you know its gonna be awesome but the waiting makes you hate it.
Half Life- maaaan that takes me back. Except, well, fuck that Orange Box.
Like so:
waiting and waiting.. just as many of us wait for half life 3, you know its gonna be awesome but the waiting makes you hate it.
Silly question: What does HODL stand for? 
(I first ran across it here & thought it a typo...)
Hold On for Dear Life or Hold On for Dark Life (us?) (I first ran across it here & thought it a typo...) I found and solved a small leak in the packet routing. Probably most of you missed it too, I did. I was using the session's public and private keys to encrypt packets. I mean that's what there there for, so I didnt think it through enough.
The "problem" is that in order to not require the receiver to have to know who the packet is coming from (that would also be an info leak), I put in plain text the public key. I figured it is the key you are publishing as the one for people to use when encrypting to your "post office box". So not really a giant leak, but since it is in plain text, an attacker can relatively easily build up a database of IP address to public key mappings (assuming they are logging all the UDP packets on the Internet between all the privacyServers). Maybe this is harmless, but if I can close this leak I think it is better.
The answer is related to the problem of having the public key in plain text for the broadcast method. In this case, there is no IP address divulged, but everybody sees that such and such address is sending a packet to someone. Again, why leak this info.
I must have been tired when I coded the initial version as the answer is quite simple. All I have to do is generate a brand new one time keypair for each packet. Since I put the public key in plain text there is no need for anybody to keep track of them and it is perfect for one time use. Now with this simple change, both leaks are totally gone.
What the attacker sees is that some random public key is sending a packet to some IP address, which then might be rerouting it or processing it.
That was bugging me for a while.
Dont you feel better now? I sure do!
James
The "problem" is that in order to not require the receiver to have to know who the packet is coming from (that would also be an info leak), I put in plain text the public key. I figured it is the key you are publishing as the one for people to use when encrypting to your "post office box". So not really a giant leak, but since it is in plain text, an attacker can relatively easily build up a database of IP address to public key mappings (assuming they are logging all the UDP packets on the Internet between all the privacyServers). Maybe this is harmless, but if I can close this leak I think it is better.
The answer is related to the problem of having the public key in plain text for the broadcast method. In this case, there is no IP address divulged, but everybody sees that such and such address is sending a packet to someone. Again, why leak this info.
I must have been tired when I coded the initial version as the answer is quite simple. All I have to do is generate a brand new one time keypair for each packet. Since I put the public key in plain text there is no need for anybody to keep track of them and it is perfect for one time use. Now with this simple change, both leaks are totally gone.
What the attacker sees is that some random public key is sending a packet to some IP address, which then might be rerouting it or processing it.
That was bugging me for a while.
Dont you feel better now? I sure do!
James
I feel better everytime you write your techie stuff bruv lol
jl777 i love reading your posts but i dont understand any of it! keep up making me feel stupid. i do understand the market and yeah this is gonna be a wild ride. i would say hodl and maybe swingtrade 5$ a coin easely..
forgot to include "idk" in the poll
p.s. HOOOOOOOOODL for the longest time!
http://www.youtube.com/watch?v=NG1qooBzE2w
p.s. HOOOOOOOOODL for the longest time!
http://www.youtube.com/watch?v=NG1qooBzE2w
Silly question: What does HODL stand for? (I first ran across it here & thought it a typo...)
(I first ran across it here & thought it a typo...)HODL means 'to hold' the misspelling is deliberate, implying a certain vigor in 'holding and not selling your coins' often used in face of perceived market ambivalence.
In layman's terms: Don't sell your coins, they will increase in value even if the current market conditions make You think otherwise.
Bitcoindark a prime example of a coin to hodl 😊
It stuck and we had al sorts of funny memes.
I'm HODLING!
I found and solved a small leak in the packet routing. Probably most of you missed it too, I did. I was using the session's public and private keys to encrypt packets. I mean that's what there there for, so I didnt think it through enough.
The "problem" is that in order to not require the receiver to have to know who the packet is coming from (that would also be an info leak), I put in plain text the public key. I figured it is the key you are publishing as the one for people to use when encrypting to your "post office box". So not really a giant leak, but since it is in plain text, an attacker can relatively easily build up a database of IP address to public key mappings (assuming they are logging all the UDP packets on the Internet between all the privacyServers). Maybe this is harmless, but if I can close this leak I think it is better.
The answer is related to the problem of having the public key in plain text for the broadcast method. In this case, there is no IP address divulged, but everybody sees that such and such address is sending a packet to someone. Again, why leak this info.
I must have been tired when I coded the initial version as the answer is quite simple. All I have to do is generate a brand new one time keypair for each packet. Since I put the public key in plain text there is no need for anybody to keep track of them and it is perfect for one time use. Now with this simple change, both leaks are totally gone.
What the attacker sees is that some random public key is sending a packet to some IP address, which then might be rerouting it or processing it.
That was bugging me for a while.
Dont you feel better now? I sure do!
James
The "problem" is that in order to not require the receiver to have to know who the packet is coming from (that would also be an info leak), I put in plain text the public key. I figured it is the key you are publishing as the one for people to use when encrypting to your "post office box". So not really a giant leak, but since it is in plain text, an attacker can relatively easily build up a database of IP address to public key mappings (assuming they are logging all the UDP packets on the Internet between all the privacyServers). Maybe this is harmless, but if I can close this leak I think it is better.
The answer is related to the problem of having the public key in plain text for the broadcast method. In this case, there is no IP address divulged, but everybody sees that such and such address is sending a packet to someone. Again, why leak this info.
I must have been tired when I coded the initial version as the answer is quite simple. All I have to do is generate a brand new one time keypair for each packet. Since I put the public key in plain text there is no need for anybody to keep track of them and it is perfect for one time use. Now with this simple change, both leaks are totally gone.
What the attacker sees is that some random public key is sending a packet to some IP address, which then might be rerouting it or processing it.
That was bugging me for a while.
Dont you feel better now? I sure do!
James
Silly question: What does HODL stand for? (I first ran across it here & thought it a typo...)
(I first ran across it here & thought it a typo...)HODL means 'to hold' the misspelling is deliberate, implying a certain vigor in 'holding and not selling your coins' often used in face of perceived market ambivalence.
In layman's terms: Don't sell your coins, they will increase in value even if the current market conditions make You think otherwise.
Bitcoindark a prime example of a coin to hodl 😊
It stuck and we had al sorts of funny memes.
man oh man i finally ride a good coin (and not sell early ty darkcoin/blaccoin) does a money dance 
Silly question: What does HODL stand for? (I first ran across it here & thought it a typo...)
(I first ran across it here & thought it a typo...)HODL means 'to hold' the misspelling is deliberate, implying a certain vigor in 'holding and not selling your coins' often used in face of perceived market ambivalence.
In layman's terms: Don't sell your coins, they will increase in value even if the current market conditions make You think otherwise.
Bitcoindark a prime example of a coin to hodl 😊
Silly question: What does HODL stand for? (I first ran across it here & thought it a typo...)
(I first ran across it here & thought it a typo...)
James,
You are the most reliable & sincerely dedicated developer of a coin that I have ever seen!!
HEAD & SHOULDERS above all the rest, bar none!!
It is inevitable & now seems a truly foregone conclusion BTCD will be wildly successful & widely implemented.
Fireworks will start when the PR campaign kicks-off next week!! Hold on to your seats folks. P&D jerks are inevitable now....
~darylluke.
You are the most reliable & sincerely dedicated developer of a coin that I have ever seen!!
HEAD & SHOULDERS above all the rest, bar none!!
It is inevitable & now seems a truly foregone conclusion BTCD will be wildly successful & widely implemented.
Fireworks will start when the PR campaign kicks-off next week!! Hold on to your seats folks. P&D jerks are inevitable now....
~darylluke.
I am really impressed with your work and the community. I have run and am still working on a few projects.
Thanks guys!
Thanks guys!
I still have the local file encrypt/decrypt to link up, but I can test the teleporting without that, so I will probably procrastinate on it until a bit later. So, I am sure I have some small parts not quite right, but at long last I feel I can call it "code almost complete"
Before you get excited, this doesnt have much error handling and it hasnt been ported into BTCD core, but it does have multisig support, ready for user defined cipher sequences for local files, randomized cloning times, and I made it so that it should be pretty much an install it and run it design. As long as your BitcoinDark.conf file has "server=1" and rpcusername/password defined, Teleport should be enabled. No need for hours long reindexing of blockchain and other horribly inconvenient install issues. Turns out 80% of MGW code was needed to achieve this!
With all the new features, especially multisig added after I started, it feels like I need three days to get this debugged, so if I can achieve that timeframe, then on Wed some people will be able to do some command line teleports. After that I need to partition the code to make it easy to implant into BTCD core. I plan to make a libjl777.a that can be linked to the BTCD core and with a few small hooks, we can have just a single wallet executable that has everything needed for Teleport. until the QT has been updated, it would still be command line, but from the QT debug window console
Let's say two days to get it into libjl777.a form and the weekend to get it into BTCD core. This is getting more speculative, but if all goes well, a week from Monday, we could have a BTCD-qt with teleport built into it.
Now this first pass will not have full privacyServer + onion routing. That is a totally independent transport mechanism and I wanted to get a teleport enabled released into testing sooner rather than later. While the basic teleport is being tested, I will make the privacyServer that is embedded in the BTCD-qt do all the things it needs to do.
Even if I meet this schedule it is Aug 18th for the teleport enabled release, so I am three days late...
Blame multisig!
James
###
I totally forgot!
The other reason for libjl777 is to allow other coin's to link up to BTCD network, most importantly InstantDEX and Teleport. This will allow creation of a super network composed of all the participating coin's networks. It wont require a hardfork and would be a matter of linking the library and make some few interface functions. After they do that they will be able to utilize the encryption network and more importantly have access to InstantDEX orderbooks. The more people (and tradebots) trading on InstantDEX, the better liquidity, lower spreads, and more commissions. Also, if they can connect directly to the encryption network that increases Teleport traffic (and fees) which increases anon levels (and dividends)
All part of my master plan for liberation from fiat govts
Before you get excited, this doesnt have much error handling and it hasnt been ported into BTCD core, but it does have multisig support, ready for user defined cipher sequences for local files, randomized cloning times, and I made it so that it should be pretty much an install it and run it design. As long as your BitcoinDark.conf file has "server=1" and rpcusername/password defined, Teleport should be enabled. No need for hours long reindexing of blockchain and other horribly inconvenient install issues. Turns out 80% of MGW code was needed to achieve this!
With all the new features, especially multisig added after I started, it feels like I need three days to get this debugged, so if I can achieve that timeframe, then on Wed some people will be able to do some command line teleports. After that I need to partition the code to make it easy to implant into BTCD core. I plan to make a libjl777.a that can be linked to the BTCD core and with a few small hooks, we can have just a single wallet executable that has everything needed for Teleport. until the QT has been updated, it would still be command line, but from the QT debug window console
Let's say two days to get it into libjl777.a form and the weekend to get it into BTCD core. This is getting more speculative, but if all goes well, a week from Monday, we could have a BTCD-qt with teleport built into it.
Now this first pass will not have full privacyServer + onion routing. That is a totally independent transport mechanism and I wanted to get a teleport enabled released into testing sooner rather than later. While the basic teleport is being tested, I will make the privacyServer that is embedded in the BTCD-qt do all the things it needs to do.
Even if I meet this schedule it is Aug 18th for the teleport enabled release, so I am three days late...
Blame multisig!
James
###
I totally forgot!
The other reason for libjl777 is to allow other coin's to link up to BTCD network, most importantly InstantDEX and Teleport. This will allow creation of a super network composed of all the participating coin's networks. It wont require a hardfork and would be a matter of linking the library and make some few interface functions. After they do that they will be able to utilize the encryption network and more importantly have access to InstantDEX orderbooks. The more people (and tradebots) trading on InstantDEX, the better liquidity, lower spreads, and more commissions. Also, if they can connect directly to the encryption network that increases Teleport traffic (and fees) which increases anon levels (and dividends)
All part of my master plan for liberation from fiat govts
awsome work, only a week? let the panic buying begin.
We are back to the old 5% per day baseline before the recent spike, well actually still a healthy amount above it, so I prefer gradual 5% per day gains. Too distracting when the price is going crazy. I know I shouldnt look, but how can I not? If it is slow gradual, then I wont get distracted. So no pumping, just gradual 5% per day is best
Getting a bit tired now, maybe I will fiddle with the local file encryption.
James
Jump to: