Topic: [ANN] SuperNET NXT asset 12071612744977229797, SUPERNET KMD assetchain in summer - page 120. (Read 736772 times)
October 12, 2014, 06:24:19 AM
when superset go to btc38.com trade？
October 12, 2014, 02:42:24 AM
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
./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
October 12, 2014, 12:02:36 AM
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
It looks good I take some UNITY 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
October 11, 2014, 11:03:18 PM
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
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
October 11, 2014, 05:17:11 PM
You should add opal
What would be the point of that?
October 11, 2014, 04:58:46 PM
You should add opal
October 11, 2014, 02:37:36 PM
When supertraders going to pay?
I don't think they "pay" anything. The trading will increase the NAV of the fund, not produce "payments".
October 11, 2014, 02:34:46 PM
When supertraders going to pay?
Not sure, but considering they mentioned that they are starting with a 10 BTC portfolio I wouldn't get my expectations up for big returns too quickly. Slow and steady is not a bad way to do it. Plus the markets aren't exactly on fire lately anyway.
October 11, 2014, 01:37:53 PM
When supertraders going to pay?
October 11, 2014, 01:02:57 PM
Yeah, while we bought it for 0.01, so the buy wall on 0.008 kinda sucks...not what was promised..
not what was promised? please quote or link to this promise....
October 11, 2014, 10:42:31 AM
LOL at guys still talking about buywall... lets talk about near future development, that is something everyone would like to hear more about.
On freenode channel ##supernet(not #supernet) people can come and watch or assist in the development and testing of superNET. Lots of testing going on everyday and I know they need more people to donate their time and their servers to test the network.
October 11, 2014, 10:10:35 AM
LOL at guys still talking about buywall... lets talk about near future development, that is something everyone would like to hear more about.
October 11, 2014, 08:09:32 AM
Awesome work James & crew, thank you
Jon
Jon
October 11, 2014, 04:39:47 AM
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
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
October 10, 2014, 04:03:11 PM
My friend you also forgot to put this story in http://supernet.wikia.com/wiki/CECVW
THE BOOLBERRY AND THE TROLL
A Boolberry was walking along the bank of the river looking for a spot shallow enough to cross to meet her boyfriend BTCD. Finally, the Boolberry found a spot, but waiting there, in the water, was a Troll that greeted her
''Good morning Boolberry, are you crossing the river today?"
The Boolberry responded, "Yes I need to cross the river to meet my dear boyfriend BTCD that is waiting in our House Supernetwork. Are you here alone or are your friends hiding nearby, waiting for me to cross the river?"
The Troll responded, "No please do not think like that I am a nice Troll and so are my friends you can cross with not fears at all so you can meet your beloving BTCD boyfriend."
The Boolberry said, "Ok, I trust you. You seem honest."
As the Boolberry was crossing the river the Troll and friends swam up to her ankles and started to chew her legs off; "Mmmm. Tastes just like berry coin"
The Troll's devoured the Boolberry in a matter of seconds. As the swarm of trolls left the sinking carcass, with full little bellies, the lead Troll turned to his other companions and belched, "BURP! I just love April fools' day ... don't you?''
This story tell you do not trust what Trolls say, its all lies and misleading information, lets learn from this story and do not cross a river infected by trolls.
THE BOOLBERRY AND THE TROLL
A Boolberry was walking along the bank of the river looking for a spot shallow enough to cross to meet her boyfriend BTCD. Finally, the Boolberry found a spot, but waiting there, in the water, was a Troll that greeted her
''Good morning Boolberry, are you crossing the river today?"
The Boolberry responded, "Yes I need to cross the river to meet my dear boyfriend BTCD that is waiting in our House Supernetwork. Are you here alone or are your friends hiding nearby, waiting for me to cross the river?"
The Troll responded, "No please do not think like that I am a nice Troll and so are my friends you can cross with not fears at all so you can meet your beloving BTCD boyfriend."
The Boolberry said, "Ok, I trust you. You seem honest."
As the Boolberry was crossing the river the Troll and friends swam up to her ankles and started to chew her legs off; "Mmmm. Tastes just like berry coin"
The Troll's devoured the Boolberry in a matter of seconds. As the swarm of trolls left the sinking carcass, with full little bellies, the lead Troll turned to his other companions and belched, "BURP! I just love April fools' day ... don't you?''
This story tell you do not trust what Trolls say, its all lies and misleading information, lets learn from this story and do not cross a river infected by trolls.
October 10, 2014, 04:01:27 PM
My friend you forgot to put this story in http://supernet.wikia.com/wiki/CECVW
Now I will tell you a story how to become a coin in supernetwork.
There once was a coin named pesetacoin, she lives in Spain and used to be the Spanish currency before joining the Euro. And now its made as a crypto coin.
Pesetacoin always felt like an outcast because she did not have a special feature to join supernetwork. She could not be different as she was an utterly improvement of BTC and with lovely people supporting her trying to find an exchange to trade her, but only bittrex was her only exchange and felt was not good enough to be famous.
Sitting at home one morning and reminiscing of her childhood, she remembered an old fairy tale about a green coin that granted wishes.
Jobless and alone, Pesetacoin resolved to go in search of the green coin. So she packed her bags and set off toward...
Half the way through her journey she thought " Oh no! How will I ever make it to the unsafe land without any special feature?
Suddenly she saw a green coin flickering up ahead.
As she crept closer she soon realised it was the green coin that she had hoped to run into.
"Oh great magical green coin," Pesetacoin said, "please give me a special feature so I can join supernetwork."
The green coin granted her the wish and she was so happy with the results that Pesetacoin came back with her amazing Silicon fake boobs to meet BTCD
Pesetacoin knocked on the door of Supernetwork house and BTCD opened the door with big eyes.
BTCD: wow, you have amazing features.
Pesetacoin: Thanks, does it mean I can join the supernetwork?
BTCD: OH yeah!
You see this story tell you that if you have a special feature that not other coin have you have a big chance to join the supernetwork.
Long Live James.
Now I will tell you a story how to become a coin in supernetwork.
There once was a coin named pesetacoin, she lives in Spain and used to be the Spanish currency before joining the Euro. And now its made as a crypto coin.
Pesetacoin always felt like an outcast because she did not have a special feature to join supernetwork. She could not be different as she was an utterly improvement of BTC and with lovely people supporting her trying to find an exchange to trade her, but only bittrex was her only exchange and felt was not good enough to be famous.
Sitting at home one morning and reminiscing of her childhood, she remembered an old fairy tale about a green coin that granted wishes.
Jobless and alone, Pesetacoin resolved to go in search of the green coin. So she packed her bags and set off toward...
Half the way through her journey she thought " Oh no! How will I ever make it to the unsafe land without any special feature?
Suddenly she saw a green coin flickering up ahead.
As she crept closer she soon realised it was the green coin that she had hoped to run into.
"Oh great magical green coin," Pesetacoin said, "please give me a special feature so I can join supernetwork."
The green coin granted her the wish and she was so happy with the results that Pesetacoin came back with her amazing Silicon fake boobs to meet BTCD
Pesetacoin knocked on the door of Supernetwork house and BTCD opened the door with big eyes.
BTCD: wow, you have amazing features.
Pesetacoin: Thanks, does it mean I can join the supernetwork?
BTCD: OH yeah!
You see this story tell you that if you have a special feature that not other coin have you have a big chance to join the supernetwork.
Long Live James.
October 10, 2014, 03:47:34 PM
Since the NAV is like 0.013 or something it doesn't really make much a difference whether the wall is at 0.0088 or 0.01 considering no one in their right mind is going to sell at those prices.
Except when it dropped to .0095...
Wall should have been placed at .01 from the get-go, especially on a scaling ICO like this was.
The agreement was made to put the wall where it is. It's a bit silly to even put a wall in the first place but if people demand it then they get it. It would actually be more beneficial not to have the wall there because if someone decides to dump for whatever reason it would enable people to pick up more shares at a price below NAV which is great(but I guess superNET itself buying back cheap shares is a good result too). People selling below NAV are likely people who need the money for heir bills or some family emergency or something, and it represents basically a free money opportunity for whoever gets there first to pick up the cheap shares. If this was a currency backed by nothing then that wouldn't really be the case, but here we have the whole asset backed by all the money that went in to it and then the bonus of having James transfer that massive amount of assets.
Most people still don't even know what superNET is. I try to explain the concept to people on here, but a lot of people are intentionally remaining ignorant of it I think because the implications if superNET succeeds are something that they think will harm their own financial interests. Which isn't necessarily the case at all considering the intention is to bring more people in to crypto in general and get them using it.
I'm surprised someone hasn't just thrown up their own buy wall at 0.01 themselves considering how much value they would get from someone dumping in to it. I guess it comes down to the fact that only a few hundred or at the most a few thousand people know about superNET so far. As things begin to come together though that number should change by at least a couple orders of magnitude. I guess the big question is what sort of plans does superNET for outreach and education? I've never heard anyone yet who after me explaining what superNET would mean for them as a user say that it's a fundamentally a bad idea. The only objections that have come up are ones about the fact that it's an asset(and people are skeptical of assets) and security issues(which are of course valid concerns). The core idea itself seems to be a potential game changer. The network effect is extremely powerful.
The goal is to get hundreds of thousands if not millions of people using superNET as their singular financial gateway. So some effort is going to have to be put in to getting users to see the benefits that can be offered to them. I think it will be important going forward that people realize that the important thing is getting the user base, not trying to sell an investment to people. If the user base is there, the investment takes care of itself. Users will mean profit, and profit will mean dividends. And the market will take care of the rest.
I also try to explain what supernetwork is with fairy stales story so people can understand better, see below when you can learn without getting a headache to understand what supernetwork is:
http://supernet.wikia.com/wiki/CECVW
The first story starts from the bottom iof the page of that link and so on, The last story is on the top of the page
October 10, 2014, 03:36:24 PM
Well put Este.
Thank you for taking the time to post quality content. I'm sure it's appreciated by many here.
Having somebody like you to summarize SuperNet topis and/or progress is valuable, especially for those like me for whom time is scarce.
Thank you for taking the time to post quality content. I'm sure it's appreciated by many here.
Having somebody like you to summarize SuperNet topis and/or progress is valuable, especially for those like me for whom time is scarce.
October 10, 2014, 01:46:16 PM
Since the NAV is like 0.013 or something it doesn't really make much a difference whether the wall is at 0.0088 or 0.01 considering no one in their right mind is going to sell at those prices.
Except when it dropped to .0095...
Wall should have been placed at .01 from the get-go, especially on a scaling ICO like this was.
The agreement was made to put the wall where it is. It's a bit silly to even put a wall in the first place but if people demand it then they get it. It would actually be more beneficial not to have the wall there because if someone decides to dump for whatever reason it would enable people to pick up more shares at a price below NAV which is great(but I guess superNET itself buying back cheap shares is a good result too). People selling below NAV are likely people who need the money for heir bills or some family emergency or something, and it represents basically a free money opportunity for whoever gets there first to pick up the cheap shares. If this was a currency backed by nothing then that wouldn't really be the case, but here we have the whole asset backed by all the money that went in to it and then the bonus of having James transfer that massive amount of assets.
Most people still don't even know what superNET is. I try to explain the concept to people on here, but a lot of people are intentionally remaining ignorant of it I think because the implications if superNET succeeds are something that they think will harm their own financial interests. Which isn't necessarily the case at all considering the intention is to bring more people in to crypto in general and get them using it.
I'm surprised someone hasn't just thrown up their own buy wall at 0.01 themselves considering how much value they would get from someone dumping in to it. I guess it comes down to the fact that only a few hundred or at the most a few thousand people know about superNET so far. As things begin to come together though that number should change by at least a couple orders of magnitude. I guess the big question is what sort of plans does superNET for outreach and education? I've never heard anyone yet who after me explaining what superNET would mean for them as a user say that it's a fundamentally a bad idea. The only objections that have come up are ones about the fact that it's an asset(and people are skeptical of assets) and security issues(which are of course valid concerns). The core idea itself seems to be a potential game changer. The network effect is extremely powerful.
The goal is to get hundreds of thousands if not millions of people using superNET as their singular financial gateway. So some effort is going to have to be put in to getting users to see the benefits that can be offered to them. I think it will be important going forward that people realize that the important thing is getting the user base, not trying to sell an investment to people. If the user base is there, the investment takes care of itself. Users will mean profit, and profit will mean dividends. And the market will take care of the rest.
October 10, 2014, 12:50:17 PM
Since the NAV is like 0.013 or something it doesn't really make much a difference whether the wall is at 0.0088 or 0.01 considering no one in their right mind is going to sell at those prices.
Except when it dropped to .0095...
Wall should have been placed at .01 from the get-go, especially on a scaling ICO like this was.
Jump to: