[1000 BTCD bounty]
I have outlined one controlled test: https://forum.thesupernet.org/index.php?topic=76.msg995#msg995Hopefully there can be others identified. So, the help I need is for ideas on how to crack the Teleport and also to implement such attacks. Teleport uses public blockchains so the cloning (spend) events are visible on the blockchain. The part that makes it anon is that all teleports go from onetime use addresses to onetime use addresses. Effectively making a chain of tx without anything to link it to any actual person. Short of someone announcing (or being monitored) that a specific tx was theirs, I cannot think of any ways to correlate a spend on the blockchain with an account. maybe if a node is monitored at the packet level, the signed tx being sent to the blockchain can be captured? To work around this, we would need to use remote pushtx nodes, eg. nodes that accept encrypted onions with signedtx inside and they submit to the coin's network. For now, I want to make sure that even if the usage of the onion network is perfectly logged by the attacker, that the anon set is still all cloning events during the clonesmear timewindow. Of course, with each user's clonesmear parameter settable, I dont think it is even possible to know which tx are part of the anon set. And as usage grows, the anon set grows without any extra load on blockchains James
|
|
|
|
1000 BTCD bounty
I have outlined one controlled test: https://forum.thesupernet.org/index.php?topic=76.msg995#msg995Hopefully there can be others identified. So, the help I need is for ideas on how to crack the Teleport and also to implement such attacks. Teleport uses public blockchains so the cloning (spend) events are visible on the blockchain. The part that makes it anon is that all teleports go from onetime use addresses to onetime use addresses. Effectively making a chain of tx without anything to link it to any actual person. Short of someone announcing (or being monitored) that a specific tx was theirs, I cannot think of any ways to correlate a spend on the blockchain with an account. maybe if a node is monitored at the packet level, the signed tx being sent to the blockchain can be captured? To work around this, we would need to use remote pushtx nodes, eg. nodes that accept encrypted onions with signedtx inside and they submit to the coin's network. For now, I want to make sure that even if the usage of the onion network is perfectly logged by the attacker, that the anon set is still all cloning events during the clonesmear timewindow. Of course, with each user's clonesmear parameter settable, I dont think it is even possible to know which tx are part of the anon set. And as usage grows, the anon set grows without any extra load on blockchains James
|
|
|
|
[04:09] <jl777> no new release today, I decided to revamp the low level IP comms [04:09] <jl777> I also decided to implement a subset of http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf[04:10] <jl777> this is the Kademlia that is the basis for most DHT [04:10] <jl777> at small scale it wont matter, but at the larger number of SuperNET nodes, something like this will be needed [04:10] <jl777> might as well get it done now James |
|
|
|
|
I pushed a version that automatically disables the SuperNET code if there is no SuperNET.conf
Since this is all in a dynamic .so file, it means we can start making a SuperNET ready BitcoinDarkd release.
I think there are the build issues for Windows and Mac and maybe a few other things. We can start a release test cycle for BitcoinDarkd
James
|
|
|
|
What is the value proposition of ATOMIC to asset holders?
there will be fees for the recording of the tx pair and these fees will be accumulated for dividends to assetholders The specifics on fees have not been determined yet and it will be optimized. Clearly if it is too high then nobody will use the Atomic blockchain, so we need to test different fee structures to make sure it is not impacting usage. InstantDEX plans to use the Atomic blockchain, so it will have a built in default customer. James |
|
|
|
|
Thanks to BTCDDev!
I am now able to build and test libjl777.so without having to rebuild BitcoinDarkd
what this means is that we can start to think about release candidate testing for BitcoinDarkd!
The first version can just have a disabled libjl777 so all it tests is the new multisig, PoS v2, API pass through support and various other improvements BTCDDev has added over the months.
this will allow us to upgrade the installed base that is ready for a dropin libjl777.so into the /usr/lib and the Windows and Mac equivalents.
Then as new SuperNET features are qualified for release, we can make releases for libjl777 independently of a new BitcoinDarkd
James
|
|
|
|
Thanks for quick fix!! James |
|
|
|
I was able to compile libjl777 as a shared library and link it into BitcoinDarkd. Here is how: 1. copy randombytes.o from the nacl build directory (nacl-20090405/build/<username>/<processortype>/lib) to btcd/src 2. change the LIBS line in makefile.unix to this: LIBS += $(CURDIR)/leveldb/libleveldb.a $(CURDIR)/leveldb/libmemenv.a -ljl777 libuv.a libnacl.a randombytes.o -lcurl -lm -ldl 3. create a new file in btcd/libjl777 called make_shared and paste this into it: rm libjl777.so
rm /usr/lib/libjl777.so
gcc -shared -Wl,-soname,libjl777.so \
-o libjl777.so libjl777.o libtom/*.o \
picoc/*.o picoc/cstdlib/*.o picoc/platform/*.o \
libgfshare.o -lstdc++ -lc
mv libjl777.so /usr/lib 4. edit btcd/m_unix to this: git pull
./BitcoinDarkd stop
cd libjl777
./clean
./m
cp libjl777.a libs
cd libuv
make
cp .libs/libuv.a ../libs
cd ..
cp libs/*.a ../src
./make_shared
cd ../src
rm BitcoinDarkd
make -f makefile.unix
rm ~/.BitcoinDark/debug.log
cp BitcoinDarkd ..
cd ..
./BitcoinDarkd
Let me know if it works for you. My CPU usage seems to be pretty high, not sure if this is causing that. If we can get this perfected, then future SuperNET upgrades can be made by simply replacing libj777.so in /usr/lib with the updated one instead of rebuilding BitcoinDarkd  Is it running stable?
works great! I pushed a merged btcd repo Great, now we don't have to rebuild BitcoinDarkd when you update libjl777  but I only make a few hundred builds per week. is that too many? |
|
|
|
I was able to compile libjl777 as a shared library and link it into BitcoinDarkd. Here is how: 1. copy randombytes.o from the nacl build directory (nacl-20090405/build/<username>/<processortype>/lib) to btcd/src 2. change the LIBS line in makefile.unix to this: LIBS += $(CURDIR)/leveldb/libleveldb.a $(CURDIR)/leveldb/libmemenv.a -ljl777 libuv.a libnacl.a randombytes.o -lcurl -lm -ldl 3. create a new file in btcd/libjl777 called make_shared and paste this into it: rm libjl777.so
rm /usr/lib/libjl777.so
gcc -shared -Wl,-soname,libjl777.so \
-o libjl777.so libjl777.o libtom/*.o \
picoc/*.o picoc/cstdlib/*.o picoc/platform/*.o \
libgfshare.o -lstdc++ -lc
mv libjl777.so /usr/lib 4. edit btcd/m_unix to this: git pull
./BitcoinDarkd stop
cd libjl777
./clean
./m
cp libjl777.a libs
cd libuv
make
cp .libs/libuv.a ../libs
cd ..
cp libs/*.a ../src
./make_shared
cd ../src
rm BitcoinDarkd
make -f makefile.unix
rm ~/.BitcoinDark/debug.log
cp BitcoinDarkd ..
cd ..
./BitcoinDarkd
Let me know if it works for you. My CPU usage seems to be pretty high, not sure if this is causing that. If we can get this perfected, then future SuperNET upgrades can be made by simply replacing libj777.so in /usr/lib with the updated one instead of rebuilding BitcoinDarkd Is it running stable?
works great! I pushed a merged btcd repo |
|
|
|
@devs, any thoughts on how long before any of the new features are released?
The network of about 10 servers is being tested The onion routing has been seen to work, though there are still some bugs I did a bunch of new code to make the onion routing reliable and also the propagation of the routing info, so another day or so and I think we should have a pretty stable SuperNET networking. Still dont have any test programmers to create some really intense test scenarios, maybe I have to do this myself... Some small changes are needed to go from a loopback mode (where I had Teleport working) to SuperNET capable, but not so much. give me a couple days after the network stabilized to get teleport into testing. The GUI I have no idea how long this will take, also Windows and Mac builds. Without test programmers, I am nervous to scale things up much beyond the current network size. So hopefully we can find some Since nobody has ever made a SuperNET before and nobody has ever implemented Teleport before, to make an exact estimate is not going to be reliable. Now I am finally able to code for most of the day and I have made it clear I am done maintaining the MGW servers and also I dont bother with the SuperNET thread, these are all things that maximizes the time I have for coding. Keep in mind that once the SuperNET networking is working, all the other features are at the application level and will go much faster. And there are degrees of working. As soon as we have a dynamic library version of a build process, then we can make a hardfork update once. Then to update to a new SuperNET will just require adding a new dynamic library file to your system. So, this is what I want to have, but I am not doing this build process so I dont know how long it will take. As soon as we have that, then we could make a new release candidate and then make incremental SuperNET API releases. This I think is the practical path. James The design review of Teleport/SuperNET is not finding any critical issues and I did have to make improvements made, I dont think I posted much about these types of things and I know last weeks I have not been posting much here, but there has been a lot of progress toward the finish line. Validating the design via independent reviews is a critical part of all this |
|
|
|
|
just pushed a version that fixes sync issues so all the peers should auto discover each other, but need to see it in action to be sure that the bandwidth usage drops off as the nodes get in sync
James
|
|
|
|
|
mgwBTCD should be caught up now
let me know if any missing tx
James
|
|
|
|
a lot of stuff happening in https://forum.thesupernet.org/index.php?board=14.0 and ##supernet IRC: [16:02] <jl777> on one server I see {"requestType":"publishPservers","NXT":"10694781281555936856","Pservers":["209.126.70.170", "185.21.192.9", "23.97.66.164", "104.41.129.107", "74.143.21.66", "89.212.19.49", "209.126.70.156"],"firstPserver":0,"Numpservers":7,"xorsum":2198144725} [16:03] <jl777> and {"requestType":"publishPservers","NXT":"13434315136155299987","Pservers":["209.126.70.159", "209.126.70.170", "89.212.19.49", "185.21.192.9", "199.193.252.103", "74.143.21.66", "23.97.66.164", "137.116.193.215", "209.126.70.156"],"firstPserver":0,"Numpservers":9,"xorsum":3355436066} [16:03] <jl777> so this is very good! I have some MGW code to do and tonight I hope to make progress on making the propagation work reliably [16:51] <jl777> OK, MGW code is being tested. back to the routing issues. [16:51] <jl777> the third server only sees {"requestType":"publishPservers","NXT":"8894667849638377372","Pservers":["209.126.70.156", "74.143.21.66", "89.212.19.49", "185.21.192.9"],"firstPserver":0,"Numpservers":4,"xorsum":3867160699} [16:51] <jl777> and I see the dreaded error: got ("error":"no np or global udp for sendmessage || destnp->mypeerinfo.srvnxtbits == 0"}) [16:52] <jl777> yesterday, I had some infinite loops where one server responded to another server, which caused another command sent, etc. [16:52] <jl777> sort of like infinite recursion [16:53] <jl777> I was just hardcoding an implicit statemachine by the code for each API [16:54] <jl777> but clearly this is not workable for any complicated logic, so I need to generalize some simple ACK and ACK ACK protocol in a generic statemachine so the majority of API calls can just use a default statemachine [16:54] <jl777> does anybody see a flaw with this approach? |
|
|
|
Update:
As we are wrapping up the process of getting the ATOMIC blockchain running for testing but before we actually generate the main net genesis block we would like to hear the opinions of those in the community about a few of the variables that we have had to set such as block time and number of coins.
Block Time:
When deciding on what we wanted to make the block time for the ATOMIC network we took many things into consideration. First of all we wanted to make sure that the security of the blockchain was not compromised. When setting the block time you are playing with a double edged sword. Faster block times mean faster, but some would argue less secure transactions. Longer block times are arguably more secure but transactions take significantly longer. For example the original Bitcoin blockchain has block times of 10 minutes, while Litecoin has a block time of 2.5 minutes and Dogecoin a block time of just one minute. Although ATOMIC is not another altcoin it is just as important to the developers that we find a time fast enough to enable the advances we want to make with ATOMIC without compromising security. This is why we have settled for a block time of 5 minutes which places us right in between the block times of Litecoin and Bitcoin. We believe that a 5 minute block time is the best possible solution to reach a balance of speed and security on the ATOMIC network.
Number of coins:
As ATOMIC itself is not a 'coin' and we are making use of transactions as a method of storing ledger information we believe that setting the number of coins to be generated to infinite is the best option. ATOMIC does not have to face the same issues as Bitcoin in regards to maintaining value by acting as a deflationary currency as it isn't a currency at all. Other well tested crypto-currencies like Dogecoin have adopted an infinite number of coins as a way to ensure that their miners will never leave once the rewards dry up. ATOMIC would be making use of an infinite number of coins simply to ensure that new blocks will always be generating which is required for ATOMIC to act as the main ledger / ticker tape of all cryptocurrencies. While it may not be an issue right now, 5 years from now we do not want ATOMIC to run out of blocks!
We are open to discussion on these topics and we would love to hear any arguments for alternative values which may work better for ATOMIC, although we have put a lot of time into making these preliminary decisions.
2x bitcoin frequency is what I would have recommended and that happens to be 5 minutes! I was thinking that the miners would probably get more from InstantDEX revshare than whatever the coins they mine would be worth. Not sure what utility the coins actually have here (other than being able to use existing codebase and they all spit out coins from coinbase) and maybe some speculative market will be created, or maybe there will be some use for these coins that we come up with. OK, I came up with a use! Not all blocks will have the same value. One block might have a DOGE<->LTC swap another could be recorded a Legal Deed for a real estate transaction. The InstantDEX revshare would be based on the economic value of the tx a specific miner was involved in. This will be quite "lumpy" and provide results like solo mining. The coins could be the equivalent of a mining pool. The InstantDEX revshare could be allocated between the specific miner and the entire set of Atomic miners. If this split is 50/50 (maybe 2/3 vs 1/3?) then the revenues allocated to the entire set of Atomic miners would be allocated based on the number of coins they have. Basically each coin would be a share of the mining pool and when there are revenue sources other than just InstantDEX, this could become quite a bit larger than a share of 0.1% trading commissions The coins are perfect to represent the proportional value of mining, but I dont like the rapid emmissions that a lot of coins have. It gives the earliest miners a disproportionate number of coins. Hopefully we can get a lot more linear emission, so that a miner joining later is making close to the same rate. After all there is no arms race for hashrate, so any sort of exponential difficulty increase seems wrong. James |
|
|
|
Well, today is totally lost. Between dealing with investor support issues I have to spend hours fiddling with MGW server.
I have way too much coding to do to be stuck doing MGW server maintenance!
So far the issues have not been related to MGW itself, server out of RAM, new versions, shellshock, test versions crashing and messing up the cache, etc.
As of next weekend, I will formally stop running MGW servers. Until the production servers are running, there wont be any MGW servers.
I suggest to withdraw all the MGW assets ASAP. if they get stuck after I shutdown the MGW on my dev servers, it could take a while for me to figure out how to properly to manual withdraws. I need to code for 14 to 20 hours at a stretch and I cannot be monitoring people's deposit/withdraws that are not appearing after 17 blocks. So if you do not withdraw before the weekend, the funds will be safe but inaccessible for some weeks.
James
Is this why price dropped today? lol to all those who sold. BTCD under .012 = NOM NOM NOM ... James is the man. The production team is saying they will get the production MGW servers running soon, so it is possible that there will be minimal downtime. If there is downtime, just dont blame me! Also, it looks like there will be support for at least half a dozen coins maybe more. If you look at the prices, we are painting a giant flag pattern starting sep 4th with the centerline around .0125 We need a nice long base for the next move up and it is still quite a large swing from high to low, so maybe another week of sideways. now I am freeing myself from MGW server and customer support and also I stopped following the SuperNET thread (moved to SuperNET forum), this will free up a lot of my time and let me concentrate on the coding. got the Privatebet XML dev in sync and so all the projects are ~90% complete, just need to start connecting them all together. James |
|
|
|
|
OK, I am closing my browser tab with this thread on it, so see you in the SuperNET forum!
James
|
|
|
|
you would think it would, but the trolls did a good job and non-trolls were starting to get nervous so I had to get buy walls in place and that took hours to get the million NXT freed up
James
P.S. Do you really think I can just post once about something?
Does it really matter if a few investors get nervous? (If they are going to get nervous about something stupid like a buywall that will never be sold into, then let them sell.) The trolls were just being trolls, I assume most sensible people had put them on ignore. (For me, the last 5 pages was you defending superNET against a series of 'This poster is on your ignore list' posts.) Buywall is now up. If you ignored all the trolls and FUD in this thread, you'd have saved time and energy and money, and done more coding. And the advantage of responding was what?--a few panicky cryptoinvestors felt a bit better. The bigger SuperNET becomes, the more trolls will arrive. That's one thing the internet has no shortage of. You might think that making the SuperNET a success will decrease the trolls, but no, it'll be opened up to a wider audience, and there'll be a bigger pool of trolls to descend. (The bigger something or someone becomes, the more some people want to knock it down.) I think you have to give the serious investors in this thread more credit at being able to ignore the trolls. You don't like to leave troll-statements unchallenged though, so probably best to move to the forum. It seems like most are agreeing that I should just be on the superNET forum, but this thread can be monitored and handled by others. If so, people will have to understand that I wont respond to them here as I wont even see it James I think that is a good idea. I think so too. Then the answer to any FUD is simply "sign up at the SuperNET forum". Minimal presence maintained here, with the encouragement to check out where the real action is. Much like the way NXT maintains a thread here but has its own forum, where the SuperNET culture prevails. Many trolls probably don't even own any SuperNET. Perfect! I have updated the OP. Maybe we should require SuperNET ownership to be able to post on the forum? I remember the NXT threads on BTT, it was just horrible and today reminded me of that. The answer was moving to the NXT forum. So let us move to the SuperNET forum! That is where the real action will be. All the latest news on the latest coins, assets, dividends, all on the SuperNET forum and maybe some time later it will get posted here. James |
|
|
|
you would think it would, but the trolls did a good job and non-trolls were starting to get nervous so I had to get buy walls in place and that took hours to get the million NXT freed up
James
P.S. Do you really think I can just post once about something?
Does it really matter if a few investors get nervous? (If they are going to get nervous about something stupid like a buywall that will never be sold into, then let them sell.) The trolls were just being trolls, I assume most sensible people had put them on ignore. (For me, the last 5 pages was you defending superNET against a series of 'This poster is on your ignore list' posts.) Buywall is now up. If you ignored all the trolls and FUD in this thread, you'd have saved time and energy and money, and done more coding. And the advantage of responding was what?--a few panicky cryptoinvestors felt a bit better. The bigger SuperNET becomes, the more trolls will arrive. That's one thing the internet has no shortage of. You might think that making the SuperNET a success will decrease the trolls, but no, it'll be opened up to a wider audience, and there'll be a bigger pool of trolls to descend. (The bigger something or someone becomes, the more some people want to knock it down.) I think you have to give the serious investors in this thread more credit at being able to ignore the trolls. You don't like to leave troll-statements unchallenged though, so probably best to move to the forum. It seems like most are agreeing that I should just be on the superNET forum, but this thread can be monitored and handled by others. If so, people will have to understand that I wont respond to them here as I wont even see it James |
|
|
|
Humans have choice. This exercise of free will determines ones' reality. Dev can choose whether or not he spends the day checking this forum, or doing the coding required to pull off what he has promised.
The notion that we must rush about filtering everything that might reach the dev's delicate ears is - again - adding to the atmosphere of cult and leader here.
Dev is obviously a smart guy. Needs to up his game on what he chooses to focus on. Just like any leader in any large endeavor.
Why not post with your normal account? Why hide behind a new account? Interesting question. If I was fudding the answer would be obvious. But I am not. So what does that tell you about the atmosphere here? I am surely not doing it because i enjoy the 6 minute delay. If the dev wants others to help out, there are a lot of smart committed guys here who can do the job. He needs to reach out and explicitly empower said people. And he needs to stop taking bait & girding for battle at every perceived slight. So I am supposed to just code but if I ignore something so important as the missing buywall on a weekend, it is not acceptable either. which is it? Am I supposed to be worried about investor questions or to just ignore it and code? If I just didnt check this thread, I would be able to code, but then what happens on a weekend when a buywall emergency happens? You are saying I need to do two mutually exclusive things. For someone that is smart, you know this is not possible. When there are 4 pages of posts on something, I should just ignore it? James P.S. Did you not see that I was asking for help, that I empowered UNO? It seems you are not giving me any credit for dealing with the situation I think the criticism is about how much attention and energy you put into dealing with that buywall issue. You could address that issue once and ignore any future posts about it. you would think it would, but the trolls did a good job and non-trolls were starting to get nervous so I had to get buy walls in place and that took hours to get the million NXT freed up James P.S. Do you really think I can just post once about something? |
|
|
|
|
Show Posts
