Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 91. (Read 790417 times)

Nice tool for checking code for bugs
https://scan.coverity.com/

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.

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.

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

Don't let the rpcport through the firewall,
only the normal port (41678)

rpcport should only be accessed through localhost or local network.

-sf-

in the op mate ...


forward / allow rpcport above ...

#crysx

Can someone say what ports should be opened in order for wallet to work behind a firewall?

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

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.

DSDN Whitepaper going reasonably well.

I might PM a few people to get their views before release.

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)

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.

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

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-

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-

Looks like people were shutting down the US internet because of fears over WikiLeaks founder being arrested or closing links to his website?



https://twitter.com/wikileaks/status/789574436219449345

How many miners were affected?

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 Visa

http://www.businesswire.com/news/home/20161021005212/en/Visa-Introduces-International-B2B-Payment-Solution-Built

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. 

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.

Definitely looking forward to reading more about what's in the whitepaper!


Also, I made a new twitter so I can keep it updated somewhat regularly.

https://twitter.com/SpreadtheSPR