I pushed a new version with findaddress API

./b SuperNET '{"requestType":"findaddress","refaddr":"8894667849638377372","dist":24,"numthreads":20,"duration":6000,"list":["13434315136155299987","8894667849638377372","10694781281555936856","18429876966171494368","16163006958863727986","1838354277347686608","17572279667799017517","14815310753561302584"]}'

The refaddr is your privacyServer's NXT address, dist is the distance in bits (after xor), numthreads is the number of parallel tasks doing the search, duration is in seconds and list is the reference list of public server addressees

This will run in the background until the time runs out and it will print out a password and stats for your super private account. I havent done the storing in encrypted file or anything else yet. while it is running, if it finds a better acct, it will print:

>>>>>>>>>>>>>>> new best (super secret password) ...

so you can always search for this and get decent accounts to use while the findaddress keeps working in the background. It is kind of like mining! But what it is doing is actually very useful. It is finding the perfect address for you to use by making it look like an address that could be linked to any of the other public servers.

Due to the way the accounts are created, bruteforce random guessing is the best way to find such an address. This is a good thing as it means that the encryption is quite good. After all if the distance between the mined acct and the reference account went to zero, we have effectively hacked it!

The search is creating an N dimensional space where each dimension is the distance from one of the server accts in the list. The metric function is a bit more complicated, but conceptually we want a point in N-space that is equidistant from as many public nodes as possible. With the current number of nodes being so small, it is hard to come up with any address that meets this criteria, but at a distance of 24, given enough time, it should be possible to find an address that is +/- 3 distance from most of the list.

I am hoping that with more nodes, it will be possible to find addresses that are around 20 bits distant and still have the above characteristic.

Now why on earth do we care about such things?

The reason is that this solves the "last mile" problem of how to establish totally private comms without resorting to broadcasting to everybody. My coding the DHT is what allowed me to solve this, so those that think these seemingly unrelated things are slowing down the progress, it is quite the opposite. It is helping achieve the ultimate goal!

To understand how this allow comms without divulging the IP address, requires a bit of background on DHT, especially the Kademlia XOR distance method. Using XOR as a distance function sounds so simple, but it has some very powerful mathematical properties. Namely, you can know if another node is closer or farther away from the desired location, totally in the abstract. Imagine that you start searching for something. It gets a delivery address (in the abstract not IP). Now you find all the nodes you know about that are closest to this address and ask them to deliver it. You only know they are closer to the destination that you are.

That's it!

Of course a lot more details, but this is emergent behavior, eg. out of very simple behavior at the local level, some powerful global functionality emerges. Imagine you got the packet from someone that was farther away than you are. Now you do the same thing and the packet keeps getting closer and closer to the destination. Finally it gets to the nodes that are as close as possible that are in the network.

All the SuperNET nodes are part of this "bucket brigade", each passing the packet one step closer to the destination. This means that your node is also going to be involved in this and everybody knows your public server's acct and IP address. If not because you publish it, but if they wanted to the attacker can do sybil attacks and get this info. It is simply unavoidable to get an account linked to the IP address if you are transacting with it.

However, we have the private address that only people you transact with know. Your privacyServer's acct is known along with its IP address, but as long as you are careful with who finds out your privateaddress, then it is just an address that happens to be equidistant from N other privacy servers. Which one? Could be any of them as the way the DHT works is that it replicates the info to all the nodes closest to the destination, which in this case is your address. Taking advantage of this property of the DHT and the fact that your privacyServer will be handling the routing allows packets that are encrypted to your private address to be received by your computer and you can decrypt it as it is sent on to the closer nodes.

As the network grows, it will become harder and harder even to identify the set of possible nodes your private address belongs to. So even if your private address is compromised, there isnt a way to link it to any IP address!

James

First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig. https://forum.thesupernet.org/index.php?topic=154.msg1262#msg1262

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

James

First off I remind you I am just a simple C programmer and not a cryptographer. If anybody has the math background to confirm or deny my experimental finding, please post!

I was experimenting with Curve25519 yesterday and I observed a very useful property that allows the creation of multisig. https://forum.thesupernet.org/index.php?topic=154.msg1262#msg1262

Now I doubt it was just in the few cases that I discovered that works. I bruteforce searched thousands of combinations and found a very simple relationship that I believe can be used for arbitrary M of N signatures.

The fundamental property of Curve25519 is that if A and B know each others public key, they can create a shared secret. Let A and B be the private keys and a and b the public keys:

curve25519(A,b) == curve25519(B,a)

I searched and searched on the Internet to find little actual useful info, so I started with the above and my intuition and searched for combinations that created the same result and there were many, but the simplest and clearest was:

Add C and c to the above and denote S_ab to being the result of curve25519(A,b) or curve25519(B,a) (they are the same)

curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)!

This relationship is quite useful and it is probably obvious to anybody familiar with curve25519 so maybe I am just getting excited over nothing, but the recommendation is to immediately hash the output S_ab. Presumably to avoid any low entropy sections of the point and once you do this, the above relationship does not work as you end up totally scrambling the location of the point in the finite field. I call this the rawsharedkey and maybe it has been explored in depth so we can get some math proofs of the above relationship.

We also know that curve25519(A,curve25519(B,curve25519(C,seed))) is equal to all the permutations of order, I think this is because the field forms an abelian group, but it has been a long time since I did any abstract algebra so I probably have the terms wrong. It is just a fancy way of saying the order doesnt matter.

So how to use these math properties to make multisig?

Since S_xy is constant for each set of keypairs for each node, these values can actually be cached locally. Of course this means that the presence of S_xy in the output does not mean that either X or Y actually signed anything. Turns out this is fine, as the final step requires the signing node to actively participate and the final output can be processed till the dogs come home:

sha256(seed ^ curve25519(A,S_bc))
sha256(seed ^ curve25519(B,S_ac))
sha256(seed ^ curve25519(C,S_ab))

all the above produce the identical result and proves that A, B and C all signed it with the seed (which should have a timestamp in it) and since it goes through sha256 the output gives no useful info about A, B or C. I am not sure if S_xy is leaking any info to the nodes that get access to it, but I dont think so as it is the output of curve25519 and that's supposed to be hard to reverse.

Since it is safe to publish the final number, A, B and C publish it and everybody can verify if 0, 1, 2 or 3 signers signed it. The enforcement of following the result is beyond the scope of this thread, but this can be put into the NXT core and each node can just use the above to verify whether the payment should be released

Now, how can this be generalized? I feel strongly that the "triangle" relationship can be generalized, but so far my experimental results are not finding the right sequence.

Let me ramble a bit, that sometimes helps

Starting with the fundamental triangle:
curve25519(A,S_bc) == curve25519(B,S_ac) == curve25519(C,S_ab)

Let us replace C,c with D, d:
curve25519(A,S_bd) == curve25519(B,S_ad) == curve25519(D,S_ab)

The problem is these are different values as it is S_ab combined with C vs D, however, we can use the priv/pub equivalence:

curve25519(d,curve25519(C,S_ab)) ?? curve25519(c,curve25519(D,S_ab))

nope, that didnt work, but as expected:

curve25519(D,curve25519(C,S_ab)) == curve25519(C,curve25519(D,S_ab))
which means:

curve25519(D,curve25519(C,S_ab)) ==  curve25519(C,curve25519(D,S_ab))  == curve25519(B,curve25519(D,S_ac))  == curve25519(A,curve25519(D,S_bc))

Hey! That means there is a 4 signer solution, but this requires multiple signings and then correlations, so not exactly what I am looking for. Anyway I hope to get some math help here so an efficient M of N multisig using curve25519 is possible. Experimentally I found the triangle relationship, which I am not sure if it is trivially obvious or something significant.

James

one way to find out
as far as SuperNET is concerned, a BTCD node has ip:port, but it is based on ipv4 so not sure how the ipv6 will map to ipv4 addr...

not sure if multiple BTCD can be run on a single machine, but if there are two virtual machines each with separate ports, it is possible

https://bitcointalk.org/index.php?topic=421615.msg9169365#msg9169365
seems DRK is being stolen via this exploit?
I never felt comfortable with the whole mixing thing where you are literally sending your coins to some random node. This is why Teleport is "direct" peer to peer. As long as the telepods are not compromised, your funds are not compromised.

James

I have a 1000 BTCD bounty already, but we can certainly be more active about this. I know a lot of people have tried to find something wrong and would love to proclaim some horrible bug in my code.

do you have URL about the darksend exploit?

I wasnt even aware of that, this is the problem with closed source as it takes a lot of people looking at something to find these things. Also, this explains why the price has been down recently. we share "dark" with darkcoin

James

Pushed a new version that adds random delay to packets, this makes it harder for an attacker to correlate packets coming in and going out. Since these packets are all exactly 1400 bytes and fully encrypted, there wasnt much for the attacker to analyze, now even that is fuzzy

James

FANTASTIC!!

Really cool video.

James

In the last week, I coded the Kademlia DHT, MofN filesystem and multisig API, while I helped others issue a few assets.

What new tech this is silly LTCD actually do? I notice it has not even applied to be part of SuperNET, probably due to lack of any actual tech.

The price has indeed dropped 50% from the SuperNET ICO created peak, the current oscillation point is around .012 so we are one third down from there, which is a significant drop, but when BTC drops to $275 there is a ripple effect.

Anyway, look forward to hear what awesome tech the LTCD has that will make it fundamentally increase in value. BTCD peoples know that the price and value are not always in lockstep, this is how they make more money.

The SuperNET ICO did create some delay, but in any case we dont have the GUI yet, so not sure if it has caused any time to market delay. It did however create a 10x larger audience for generating revenues from.

James

P.S. I have been buying BTCD and certainly not selling at these silly bot made prices.

it would be better to have as many different vendors as possible
we need as big a variety as possible, to get both geographic coverage and host OS diversity

James

It looks like the bots are going crazy on bittrex. very thin sells from .009 down, a few BTC and it is back up there.
so it looks like someone(s) is trying to get some good price for the BTCD as the release is approaching

James

I dont deal in fiat, so I cannot be the one that actually signs up for the servers

James

I figured out how to add 2 of 3 and 3 of 3 multisig API to SuperNET. It is a low level API, but allows any three nodes to verify that the other two nodes have signed the referenced data and also allows all three to publish proof that they came to an agreement

the following is a detailed process on how to do this:

I linked BitcoinDarkd to b to save on typing. I have three servers, with the following pubaddrs:
1st: 10694781281555936856
2nd: 8894667849638377372
3rd: 13434315136155299987

./b SuperNET '{"requestType":"cosign","otheracct":"10694781281555936856","text":"this is a test"}'
./b SuperNET '{"requestType":"cosign","otheracct":"8894667849638377372","text":"this is a test"}'
./b SuperNET '{"requestType":"cosign","otheracct":"13434315136155299987","text":"this is a test"}'
it returns:

1st server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"f193137b79a4993b40b0be6c7154cf2d559e3d6f974941cca657a45733435205","privacct":"10694781281555936856","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"10694781281555936856","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"10694781281555936856","pubacct":"13434315136155299987"}

2nd server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"8894667849638377372","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"4a3bc59ad2f2ea5191447ce2ad2f6a2d877daebbc096c826eb2b40bfd8293502","privacct":"8894667849638377372","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"8894667849638377372","pubacct":"13434315136155299987"}

3rd server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"13434315136155299987","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"13434315136155299987","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"d6bdcaf3d5890eb3839860d6eec1f8f151d6af7c94d7feb6691e9b4ebc26a20a","privacct":"13434315136155299987","pubacct":"13434315136155299987"}

####
note the matched pairs of results. Now I will submit one of them to the server that isnt listed, the following three, to each server:


./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"8894667849638377372","pubacct":"13434315136155299987"}'

./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"13434315136155299987","pubacct":"10694781281555936856"}'

./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"10694781281555936856","pubacct":"8894667849638377372"}'

and all three servers produced the same results! Note that each server had different inputs to create the same result.

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","10694781281555936856","privacct":"8894667849638377372","pubacct":"13434315136155299987","input":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071"}

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","8894667849638377372","privacct":"13434315136155299987","pubacct":"10694781281555936856","input":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f"}

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","13434315136155299987","privacct":"10694781281555936856","pubacct":"8894667849638377372","input":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209"}

now these are low level primitives and doesnt directly get us multisig tx, but it does allow 3 nodes to cooperate and verify that the other two are also signing the original text. by publishing the final result, it will prove to others that all three nodes reached agreement.

James

Since without the 50 servers, I cant really debug the DHT and I need that for the next step, I decided to take a break and looked into curve25519

I figured out how to do 3 of 3 multisig!
I think I can also do 2 of 3, but still need to verify the 3 of 3.

I linked BitcoinDarkd to b to save on typing. I have three servers, with the following pubaddrs:
1st: 10694781281555936856
2nd: 8894667849638377372
3rd: 13434315136155299987

./b SuperNET '{"requestType":"cosign","otheracct":"10694781281555936856","text":"this is a test"}'
./b SuperNET '{"requestType":"cosign","otheracct":"8894667849638377372","text":"this is a test"}'
./b SuperNET '{"requestType":"cosign","otheracct":"13434315136155299987","text":"this is a test"}'
it returns:

1st server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"f193137b79a4993b40b0be6c7154cf2d559e3d6f974941cca657a45733435205","privacct":"10694781281555936856","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"10694781281555936856","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"10694781281555936856","pubacct":"13434315136155299987"}

2nd server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"8894667849638377372","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"4a3bc59ad2f2ea5191447ce2ad2f6a2d877daebbc096c826eb2b40bfd8293502","privacct":"8894667849638377372","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"8894667849638377372","pubacct":"13434315136155299987"}

3rd server:
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"13434315136155299987","pubacct":"10694781281555936856"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"13434315136155299987","pubacct":"8894667849638377372"}
{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"d6bdcaf3d5890eb3839860d6eec1f8f151d6af7c94d7feb6691e9b4ebc26a20a","privacct":"13434315136155299987","pubacct":"13434315136155299987"}

####
note the matched pairs of results. Now I will submit one of them to the server that isnt listed, the following three, to each server:


./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071","privacct":"8894667849638377372","pubacct":"13434315136155299987"}'

./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f","privacct":"13434315136155299987","pubacct":"10694781281555936856"}'

./b SuperNET '{"requestType":"cosigned","seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209","privacct":"10694781281555936856","pubacct":"8894667849638377372"}'

and all three servers produced the same results! Note that each server had different inputs to create the same result.

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","10694781281555936856","privacct":"8894667849638377372","pubacct":"13434315136155299987","input":"196d7054e987a0a8061d4b4d86db5e3dfe502066208bda98a3b1c834e4fc8071"}

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","8894667849638377372","privacct":"13434315136155299987","pubacct":"10694781281555936856","input":"681d2ff77944cb36db523e775f5fe7fb5519cc106ca3fafd6bb8a31d17d10d6f"}

{"seed":"2e99758548972a8e8822ad47fa1017ff72f06f3ff6a016851f45c398732bc50c","result":"5f176db34fce1b7812e97c13771d9c7767e839304d17c9611794343db76bc556","acct","13434315136155299987","privacct":"10694781281555936856","pubacct":"8894667849638377372","input":"b39af77f1b18389e9acb782ad41a365cf5ef48d63b7394f714742f7471b4d209"}

now these are low level primitives and doesnt directly get us multisig tx, but it does allow 3 nodes to cooperate and verify that the other two are also signing the original text. by publishing the final result, it will prove to others that all three nodes reached agreement.

James

not sure why you ran as sudo, there is no need for that, but once you do you have to either change permissions or keep running as sudo

there will need to be guards against such things, but primarily it will be too expensive
though if you wanted to pay for it, then why not allow it?
100GB on 100 servers is 1 GB per server, so actually possible
with 1000 servers, it is 100 mb per server, so not a big issue

these API I have now is for low level access, enough for teleport to use as online backup of the private chains. since all the critical details are needed to even know what data belongs to you, the requirement that the privatechains need access to your local machine (and all the passwords cracked) remains, so I am ok with cloud backup if telepods

teleport has been working between my servers for over a month, so as soon as I get things tweaked to working with SuperNET API, then it should work as well as it did between my servers. I still had to do accounting report API, but now that we have cloud storage, I want to automatically backup the telepods to the cloud. still recommend making USB backups, but I know how sometimes we forget to do the things we are supposed to.

the current issue is that the existing nodes dont accept the teleport tx, so we need to wait for a node running the latest version to stake a block. Once we update the installed base, this wont be an issue.

anyway, without a bigger network there is only so much I can do. I am glad the community is in big favor to funding these nodes, so lets get them going and paid for as soon as possible

James

./b SuperNET '{"requestType":"maketelepods","coin":"BTCD","amount":".005"}'
got JSON.({"requestType":"maketelepods","coin":"BTCD","amount":".005"})
is_BTCD_command
{"result":"SuperNET BTCD command queued"}
ubuntu3@colo:~/btcd$ maketelepods.BTCD 0.00500000
satoshis 0.00500000, i.10 min 0.01000000
got podaddr.(RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1) privkey.(UtxAKVMgJDngt72gpXC4ZQs7GwttQir5ZPcQuiBCQTrjMPBNbvBK)
0x7ff69c013f20 create    0.10000000 height.146794   BTCD RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1 211d78e93255395dc9272afa759f8ab9905f9eb7b3bb9224fd99e16338a622c6/vout_1 priv.(UtxAKVMgJDngt72gpXC4ZQs7GwttQir5ZPcQuiBCQTrjMPBNbvBK)
(RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1 0.10000000) set TRANSPORTER.0 ADDRESS.(RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1) 0.10000000
changeaddr.(RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1) availchange 0.10000000, refsatoshis 0.00500000
availchange 0.09500000 refsatoshis 0.00500000
calc_telepod_transaction amount 0.10000000 = (0.00500000 + 0.09500000)
numinputs 1 sum 0.10000000 vs amount 0.00500000 change 0.09500000 -> miners 0.00000000
numoutputs.2
numdests.2 ({
   "RL8MLqhyaH2EFWt5k2BwRRt4rcaoVZQWYs":   0.00500000,
   "RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1":   0.09500000
})
createrawtxid_json_params.[[{
         "txid":   "211d78e93255395dc9272afa759f8ab9905f9eb7b3bb9224fd99e16338a622c6",
         "vout":   1,
         "scriptPubKey":   "76a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88ac"
      }], {
      "RL8MLqhyaH2EFWt5k2BwRRt4rcaoVZQWYs":   0.00500000,
      "RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1":   0.09500000
   }]
rawparams.([[{
         "txid":   "211d78e93255395dc9272afa759f8ab9905f9eb7b3bb9224fd99e16338a622c6",
         "vout":   1,
         "scriptPubKey":   "76a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88ac"
      }], {
      "RL8MLqhyaH2EFWt5k2BwRRt4rcaoVZQWYs":   0.00500000,
      "RJ1BZx18AeWEJhX4VvV3S9xLhj2B65PkK1":   0.09500000
   }])
calc_rawtransaction retstr.(010000003846375401c622a63863e199fd2492bbb3b79e5f90b98a9f75fa2a27c95d395532e9781 d210100000000ffffffff0220a10700000000001976a91476fd5f936f2d195b64e5e3a29510db6f 76608a3588ac60f59000000000001976a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88a c00000000)
sign_rawtransaction rawbytes.(010000003846375401c622a63863e199fd2492bbb3b79e5f90b98a9f75fa2a27c95d395532e9781 d210100000000ffffffff0220a10700000000001976a91476fd5f936f2d195b64e5e3a29510db6f 76608a3588ac60f59000000000001976a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88a c00000000)
got signparams.(["010000003846375401c622a63863e199fd2492bbb3b79e5f90b98a9f75fa2a27c95d395532e9781 d210100000000ffffffff0220a10700000000001976a91476fd5f936f2d195b64e5e3a29510db6f 76608a3588ac60f59000000000001976a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88a c00000000",[{"txid":"211d78e93255395dc9272afa759f8ab9905f9eb7b3bb9224fd99e16338a622c6","vout":1,"scriptPubKey":"76a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88ac"}],["UtxAKVMgJDngt72gpXC4ZQs7GwttQir5ZPcQuiBCQTrjMPBNbvBK"]])
got retstr.({
   "hex":   "010000003846375401c622a63863e199fd2492bbb3b79e5f90b98a9f75fa2a27c95d395532e9781 d21010000006a473044022001944391cdb661725cc4137a70d92d10c03dfb005bbedb95135fe45c e23fa4750220412be4278166ac2518ee10382c55977f69296f8da0c840e68fecf9cd13e80e02012 102a5eb561c038965fa212bb91c620c561932018d8309a0214c738e061807afbe37ffffffff0220 a10700000000001976a91476fd5f936f2d195b64e5e3a29510db6f76608a3588ac60f5900000000 0001976a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88ac00000000",
   "complete":   true
})
about to send.(["010000003846375401c622a63863e199fd2492bbb3b79e5f90b98a9f75fa2a27c95d395532e9781 d21010000006a473044022001944391cdb661725cc4137a70d92d10c03dfb005bbedb95135fe45c e23fa4750220412be4278166ac2518ee10382c55977f69296f8da0c840e68fecf9cd13e80e02012 102a5eb561c038965fa212bb91c620c561932018d8309a0214c738e061807afbe37ffffffff0220 a10700000000001976a91476fd5f936f2d195b64e5e3a29510db6f76608a3588ac60f5900000000 0001976a9145fb20d16a69edf9dab72b6ab7af6a716ddc2e02b88ac00000000"])
tx.vout[0] = 500000
amount: 200
isTeleport? true
In CTransaction::ConnectInputs(). vout[0] = 500000
amount: 200
isTeleport? true
sendrawtransaction returns.(55483e85940be52477e81a5b798932ef36d7584cca4eaafa511468d69256f5d3)
SEND_TRANSACTION!
34 FULL SET
check (backups/telepods/BTCD.0)
0x7ff69c003410 create    0.00500000 height.146794   BTCD RL8MLqhyaH2EFWt5k2BwRRt4rcaoVZQWYs 55483e85940be52477e81a5b798932ef36d7584cca4eaafa511468d69256f5d3/vout_0 priv.(UtzmDRmqj2YW5dm6UB8a7dHEeg6ADDSRAhZGm2ZRot1aSTyUwnS8)
SET CLONE HEIGHT <- 146794
({"requestType":"maketelepods","coin":"BTCD","amount":".005"}) -> ({"result":"maketelepod created telepods"})

ouch
the recent BTC craziness also caused a liquidity crunch for a lot of people
seems just a few BTC will boost the price a lot, but I am waiting for it to keep coming down before I by it all up

James