AnotherNode
Full Member
Offline
Activity: 178
Merit: 100
Nodes That Serve
|
|
October 20, 2016, 10:46:00 AM |
|
* DSDN is a way to enable ServiceNodes (you knew that was coming) to run bankchains, without caring what bankchains are doing (also why we encrypt bankchains). This is what Georgem's new Spreadwallet enables. He doesn't care what blockchain you run, just as long as there are enough people running a particular blockchain.
Intriguing. I don't think anyone has really done node to node encryption between several different parties. This could be something significant if you can avoid man in the middle attacks during the procedure to create secure channels.
|
|
|
|
coins101
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
October 21, 2016, 06:43:24 PM |
|
* DSDN is a way to enable ServiceNodes (you knew that was coming) to run bankchains, without caring what bankchains are doing (also why we encrypt bankchains). This is what Georgem's new Spreadwallet enables. He doesn't care what blockchain you run, just as long as there are enough people running a particular blockchain.
Intriguing. I don't think anyone has really done node to node encryption between several different parties. This could be something significant if you can avoid man in the middle attacks during the procedure to create secure channels. Bastards at Visa trying to muscle in on my idea already: Visa Introduces International B2B Payment Solution Built on Chain’s Blockchain Technology
Predictable and transparent: Banks and their corporate clients receive near real-time notification and finality of payment Secure: Signed and cryptographically linked transactions are designed to ensure an immutable system of record Trusted: All parties in the network are known participants on a permissioned private blockchain architecture that is operated by Visahttp://www.businesswire.com/news/home/20161021005212/en/Visa-Introduces-International-B2B-Payment-Solution-Built
|
|
|
|
|
sugarfly
Full Member
Offline
Activity: 135
Merit: 100
Zettel-Dolphin
|
|
October 22, 2016, 05:50:21 PM |
|
That tweet sounded very weird. Like out of character for wikileaks. It was obviously not written by Assange himself. Is he still in control of his twitter account? "Taking down the internet"? What does that even mean? -sf-
|
|
|
|
sugarfly
Full Member
Offline
Activity: 135
Merit: 100
Zettel-Dolphin
|
|
October 22, 2016, 06:00:19 PM |
|
- multihost capabilities that allow you to run multiple nodes in your local network, remote controlling them with your spreadwallet. - easy setup and control through SSH of all the raspberry pis in your local network.
I am gonna post this here so that I remember to ask again in the future when Georgem is less busy developing than he is now. But will these features eventually be extendable to remote servers? That would be awesome. I asked myself the same thing. Raspberry Pi's are supposed to be run at home. In your local network. Local networks are usually well secured against outside influences. They are sitting behind a router. If you let the Spreadwallet manage remote servers you would have way more security concerns. But people are already managing their servers/nodes from afar, so… sure, why not? -sf-
|
|
|
|
crysx
|
|
October 23, 2016, 02:27:16 AM |
|
- multihost capabilities that allow you to run multiple nodes in your local network, remote controlling them with your spreadwallet. - easy setup and control through SSH of all the raspberry pis in your local network.
I am gonna post this here so that I remember to ask again in the future when Georgem is less busy developing than he is now. But will these features eventually be extendable to remote servers? That would be awesome. I asked myself the same thing. Raspberry Pi's are supposed to be run at home. In your local network. Local networks are usually well secured against outside influences. They are sitting behind a router. If you let the Spreadwallet manage remote servers you would have way more security concerns. But people are already managing their servers/nodes from afar, so… sure, why not? -sf- agreed ... as long as there is a fully functional api - a port / link - and full accessibility to the api ... then there should be no reason why remote accessibility could not be available ... there will always be security concerns - as with any form of remote accessibility ... but that is par for the course ... that will be a georgem 'thing' to build if it is to be implemented ... #crysx
|
|
|
|
AnotherNode
Full Member
Offline
Activity: 178
Merit: 100
Nodes That Serve
|
|
October 23, 2016, 10:18:47 AM |
|
Looking forwards to those videos. We're bleeding a bit and we need our gang of core supporters to have something to be able to create a buzz about the project. There are lots of people in the media waiting to see this project succeed because it can make a big difference to all projects.
|
|
|
|
sirazimuth
Legendary
Offline
Activity: 3528
Merit: 3617
born once atheist
|
|
October 23, 2016, 02:18:17 PM |
|
looks like that bleeding stopped..thanx buyer, you will be rewarded......
GO SPREADCOIN!
(my humble apologies for that being the extent of the buzz i can generate besides supporting network with 2 crazy-mega-huge 1.4mh miners and the occassional buy when my meager budget allows... which is next to never)
|
Bitcoin...the future of all monetary transactions...and always will be
|
|
|
coins101
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
October 23, 2016, 10:07:01 PM |
|
DSDN Whitepaper going reasonably well.
I might PM a few people to get their views before release.
|
|
|
|
rhinomonkey
|
|
October 24, 2016, 04:13:50 AM |
|
- multihost capabilities that allow you to run multiple nodes in your local network, remote controlling them with your spreadwallet. - easy setup and control through SSH of all the raspberry pis in your local network.
I am gonna post this here so that I remember to ask again in the future when Georgem is less busy developing than he is now. But will these features eventually be extendable to remote servers? That would be awesome. I asked myself the same thing. Raspberry Pi's are supposed to be run at home. In your local network. Local networks are usually well secured against outside influences. They are sitting behind a router. If you let the Spreadwallet manage remote servers you would have way more security concerns. But people are already managing their servers/nodes from afar, so… sure, why not? -sf- agreed ... as long as there is a fully functional api - a port / link - and full accessibility to the api ... then there should be no reason why remote accessibility could not be available ... there will always be security concerns - as with any form of remote accessibility ... but that is par for the course ... that will be a georgem 'thing' to build if it is to be implemented ... #crysx That's good to hear. It will make running the Service Nodes far easier if we can control them through the Spreadwallet - especially when there are updates. What security issues exist with operating remotely? I'm assuming we would eventually be able to have our collateral stored in Trezor wallets which would greatly reduce any possibility of coin theft if that is a large risk with remote operation.
|
|
|
|
coins101
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
October 24, 2016, 11:12:51 AM Last edit: October 24, 2016, 12:32:28 PM by coins101 |
|
... reasonably well.
Georgem If a Bitcoin node broadcasts a message to the Bitcoin Blockchain, is it reasonable to expect that the average confirmation time for all transactions within a given fee range is how long that individual broadcast message should take, give or take say +12hrs? Why I ask - say we want to give a node a score, against one of several different scoring cards. ServiceNodes will do the scoring on this particular activity. We ask ServiceNodes to each sign a message and the combination of those messages produces a hash. One of the ServiecNodes, elected to sign part of the hashed message, is chosen to randomly pick 1 of [Coin supply / 2880] ServiceNode to confirm it is holding a real Bitcoin node by broadcasting the part of the message it generated into the hash: Hey, I was part of this gang of ServiceNodes, but I was chosen to drop out and pick another (err, you) at random to make the group quorate again. When I joined the gang, we each generated a random message and grouped them, then signed them. The grouped messages went into a hash. Here is my part of the message. When you send this message to the Bitcoin network and use my public key, the other members of the gang will pick it up and be able to generate the same hashed message, but this time my part of the message will not come from me, it will come from you. You've only got so long to get this done. Have a nice day." This 1 of [Coin supply / 2880] ServiceNode is then required to send that message to the Bitcoin network. The ServiceNodes doing the scoring will have to wait for that message to appear in the Bitcoin network, as only they combined, less the one chosen to relay part of the message to the 1 of [Coin supply / 2880] ServiceNode, can validate the initial hash. If the message does not appear, the remaining group of ServiceNodes cannot close their required validation check, the ServiceNode chosen to validate if it holds a Bitcoin node fails and is scored down (three strikes and your out?). The question is what is a reasonable time to wait? We don't want to score down ServiceNodes because of problems outside of their control. One way is to average up the wait time for transactions, which is dependent on the fees, but also general congestion, ddos attacks, etc. If the average wait time is 3 hours, then leaving the scoring open for +24hrs seems too much. Perhaps average wait time plus 12hrs or average wait time plus x% (say 100%) for margin of error? It could be that we partly solve our Sybil problem by giving nodes an incentive to select higher than average fees to broadcast their messages, so they don't get a scoring penalty and also helping them to push up their rankings. Need to have something reasonable figured out for the whitepaper. Cheers, And, Stay Tuned And, GO SPREADCOIN
|
|
|
|
restless
Legendary
Offline
Activity: 1151
Merit: 1001
|
|
October 24, 2016, 11:31:19 AM |
|
Can someone say what ports should be opened in order for wallet to work behind a firewall?
|
|
|
|
crysx
|
|
October 24, 2016, 01:30:41 PM |
|
Can someone say what ports should be opened in order for wallet to work behind a firewall?
in the op mate ... Hash algorithm: SpreadX11 Total supply: 20 million Block time: 1 minute Block halving: smoothly halved every 4 years Initial block reward: 6.66 SPR Port: 41678 RPC-Port: 41677
forward / allow rpcport above ... #crysx
|
|
|
|
sugarfly
Full Member
Offline
Activity: 135
Merit: 100
Zettel-Dolphin
|
|
October 24, 2016, 03:54:51 PM |
|
Can someone say what ports should be opened in order for wallet to work behind a firewall?
in the op mate ... Hash algorithm: SpreadX11 Total supply: 20 million Block time: 1 minute Block halving: smoothly halved every 4 years Initial block reward: 6.66 SPR Port: 41678 RPC-Port: 41677
forward / allow rpcport above ... #crysx Don't let the rpcport through the firewall, only the normal port (41678) rpcport should only be accessed through localhost or local network. -sf-
|
|
|
|
crysx
|
|
October 24, 2016, 11:14:21 PM |
|
Can someone say what ports should be opened in order for wallet to work behind a firewall?
in the op mate ... Hash algorithm: SpreadX11 Total supply: 20 million Block time: 1 minute Block halving: smoothly halved every 4 years Initial block reward: 6.66 SPR Port: 41678 RPC-Port: 41677
forward / allow rpcport above ... #crysx Don't let the rpcport through the firewall, only the normal port (41678) rpcport should only be accessed through localhost or local network. -sf- why not? ... if you have a solid rpcpassword=xxx - there is no need to be worried ... the daemon produces one for you if you havent got a conconf ( or credentials in the con ) - and they are very solid passwords ... even brute force would take way too long to crack ... besides - without the rpcport - you cant access the api - as far i know ... i havent tested though ... #crysx
|
|
|
|
AnotherNode
Full Member
Offline
Activity: 178
Merit: 100
Nodes That Serve
|
|
October 24, 2016, 11:14:42 PM |
|
Hey, I was part of this gang of ServiceNodes, but I was chosen to drop out and pick another (err, you) at random to make the group quorate again. When I joined the gang, we each generated a random message and grouped them, then signed them. The grouped messages went into a hash. Here is my part of the message. When you send this message to the Bitcoin network and use my public key, the other members of the gang will pick it up and be able to generate the same hashed message, but this time my part of the message will not come from me, it will come from you. You've only got so long to get this done. Have a nice day."
This looks pretty close to solving the Byzantine Generals problem. A message is contained within a cryptex (the hash in your example), where 5 soldiers know part of the puzzle. If all 5 soldiers do their part then the lock gets opened and the general knows he can trust the messengers. If one of them fails. You put a black mark against each one. Repeat the process. Pretty soon you would weed out those you can't trust.
|
|
|
|
coins101
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
October 25, 2016, 03:06:28 PM Last edit: October 25, 2016, 03:37:32 PM by coins101 |
|
Hey, I was part of this gang of ServiceNodes, but I was chosen to drop out and pick another (err, you) at random to make the group quorate again. When I joined the gang, we each generated a random message and grouped them, then signed them. The grouped messages went into a hash. Here is my part of the message. When you send this message to the Bitcoin network and use my public key, the other members of the gang will pick it up and be able to generate the same hashed message, but this time my part of the message will not come from me, it will come from you. You've only got so long to get this done. Have a nice day."
This looks pretty close to solving the Byzantine Generals problem. A message is contained within a cryptex (the hash in your example), where 5 soldiers know part of the puzzle. If all 5 soldiers do their part then the lock gets opened and the general knows he can trust the messengers. If one of them fails. You put a black mark against kill each one. Repeat the process. Pretty soon you would weed out those you can't trust. Potentially, you would knock them off the payments list and put a temporary ban on the IP. One of the issues to be resolved is the numbers game. You could put up a fake node and let it get paid knowing that at some point you will be found out and you will get bumped off the payments list. The risk reward issue is important here. If the Proof of Bitcoin node validation checking takes 30 days, you'd run the risk of being bumped off as your odds are 1 in 30 days. You'd get bumped, but then you could set-up another fake within a few hours. If all nodes could be verified within 24hrs, you wouldn't bother. So somewhere closer to checking every 24hrs is necessary. Is that 48hrs, 5 days, 7 days? Not sure.
|
|
|
|
|
|
rhinomonkey
|
|
October 28, 2016, 06:51:29 PM |
|
Can we expect this when SPR hits Poloniex and we have Service Nodes?
|
|
|
|
|