That person would still be providing the service of 500 bitcoin nodes. That in my opinion seems better for Bitcoin than not running 500 nodes although the decentralisation issue is serious as you say.
So, someone whose goal it is to reuse one bitcoin node (blockchain) for 500 servicenodes, so he can save costs, is actually doing a disservice to both the bitcoin network (which requires as many distinct full nodes as possible) and the servicenode network (whose services require high decentralization and the resiliance that follows from it). Let's see how this goes. For BreakThrough 1 I can't concern myself with solving this problem yet. All I know is that this scenario you describe is a very artificial one anyway, and most distinct servicenode actors will run distinct servers with distinct full nodes anyway. I'm talking about somebody runnning 500 bitcoin daemons as full nodes from one copy of the blockchain with 500 service nodes. |
|
|
|
|
That person would still be providing the service of 500 bitcoin nodes. That in my opinion seems better for Bitcoin than not running 500 nodes although the decentralisation issue is serious as you say.
|
|
|
|
I'm not moving the goalposts.
All you had to do was point out that proving that a node has correct data is different to proving that a node is unique.
Exactly, you just answered your own question. With all of this talk about it not being possible to prove the veracity of a bitcoin node, why should somebody trust bitcoin?
That's what confused me, I thought we were obviously talking about uniqueness the whole time. I confused myself. It has been a long day. |
|
|
|
|
So, if somebody has 500 nodes running off one valid copy of the blockchain on appropriate hardware, is the impact on network resilience the only concern or are there other problems caused by this too?
Is somebody running 500 decently performing nodes from one blockchain copy better or worse than that person running no nodes at all?
|
|
|
|
|
I'm not moving the goalposts.
All you had to do was point out that proving that a node has correct data is different to proving that a node is unique.
|
|
|
|
Fairly hardcore. I have a facetious question. With all of this talk about it not being possible to prove the veracity of a bitcoin node, why should somebody trust bitcoin? |
|
|
|
I like the scoring approach because it makes use of a unique set of circumstances we have access to: a second tier where you can introduce queries and additional checks to validate against fake nodes.
One of the things you can do, for example, is triangulate ping and query response rates. If I ping nodes in my immediate network I can record the ping times of my group of connected nodes. If I ping and query, the query times should have some level of correlation, unless you are running a fake node. A fake node has to send a request to another node (hey, AnotherNode :-)) in order to get data to respond to the queries it is being asked for. Do this enough times and you will be able to figure out who are the fake nodes, but even if they are not fake you can score them down.
If you add random ping and qurry rules into the equation, then you can avoid someone trying to game the ping and queries by running 5:2 bitcoin full nodes to fake nodes.
You could even throw a random transaction verification into the mix. |
|
|
|
|
@georgem
On the developer slack channel there have been numerous conversations about whether PoBN would be open to abuse by service node operators running multiple full bitcoin nodes sharing a single blockchain.
I have been doing some research into this over the last few days and I think that it isn't necessary to require cryptographic proof that a bitcoin node is using a unique blockchain copy.
Bitcoin Core (and XT for that matter) uses a database lock which locks the Berkeley Database when a blockchain is mounted and prevents another instance from connecting to the same blockchain copy. This lock was put in place because if you have multiple bitcoin instances reading/writing to the same blockchain, near instant corruption occurs stopping synchronisation and forcing a reindex.
It is possible to over-ride the lock by deleting the lock file and opening another instance but blockchain corruption is rapid, almost instantaneous.
Does this mean that if a service node is scoring well in quality of service and has an up to date block height it can be trusted as a unique node?
|
|
|
|
Why would you do this?
Most reasons should be easily solvable by using an RPC call instead of a second deamon, isn't it?
I am trying to understand, for example, whether somebody could run 10 bitcoin full nodes only using one single copy of the blockchain thus saving on storage costs. More specifically, I want to understand whether it is possible to prevent this behavior if it is already possible. |
|
|
|
It's probably not possible IIRC.
Bitcoin Core creates a lock file that is only deleted once the program exits. If Bitcoin Core detects such a file, the instance will not run. Accessing Blockchain from two different places would result in a corruption (same scenario as how Blockchain gets corrupted if anti viruses attempts to scan it).
Thank you. For clarity, does this mean that it is possible but is ill advised or that it is simply impossible due to the lock file mechanism? |
|
|
|
|
Hi,
Is it possible for somebody to run several bitcoin instances sharing the same local blockchain?
If it is possible, how is it done and what are the risks?
If it isn't possible, what prevents it from happening?
I am keen to understand whether there are any full node operators out there who are skimping on the storage costs that come with running multiple full nodes.
Many thanks.
|
|
|
|
Quick crazy question - when the test net goes live what is the length of time that we will be testing? BTW - I am getting back on my feet and slowly accumulating. :-)
Well, we will follow standard procedure: Test until we have a stable functioning version, and try to bring it as quickly as possible to mainnet, even if it is not 100% complete (functionality wise). It's important to start building a strong network as soon as possible. Music to my ears  |
|
|
|
It does look like Bitcoin has a storm heading its way. Spreadcoin is perfectly positioned to help with a problem that very few people are even aware is a problem. This could be one of those right time, right place opportunities for both Bitcoin and Spreadcoin.
I reckon its an opportunity that's too good to be missed. Maybe block explorer needs to be shelved for a while in order to start building the service network. |
|
|
|
Hey georgem, what exactly do you need to complete this phase of testing?
I mean, maybe a few of us could setup a bounty to give to who ever submits unique daemon information?
5 or more gets over 200SPR?
10 and over get 300SPR?
How many coins do you need? I'm sure we can do without 10's and 10's of shit coins... Can't we set a target say of top 50-100 coins?
I think georgem wants any coin to be possible although I suspect that only the top 10 or so coins would see much use. Besides, new coins will arrive and current ones will disappear over time... |
|
|
|
Never actually thought I would see Cryptsy die. But zero transactions and it looks like it has flat lined   Speaking of exchanges, let's get listed on some more! |
|
|
|
|
I suppose we won't know the specifics until we have been through testnet.
|
|
|
|
Servicenodes
I understand that when you place a certain amount of SPR as collateral, you get a SN seat (so long as you are not the weakest link and thereby "kicked" when someone outbids you). Do you lose any of this collateral in the event that you are outbidded? If not, then it's just to increase the amount and go again, right?
In theory, I guess you can put all of your SPR as collateral to secure a seat, but the drawback will be that you have no SPR left to run several more SNs, thus making it less lucrative. Am I right? Just trying to work out the mechanics here...
Yes, collaterals aren't "payments to someone" (that this someone might take away from you). No, they are basically "tied lookup addresses" that the network/protocol will constantly check to see if you match the criteria. Yes, there is a spread between less risk and more reward! It's up to you to find out what suits you best. Thanks for the answer. And just to be clear: When you say risk you mean simply for instance tying up too much SPR so you earn less (because you could have had multiple SNs), and not risk related to any other loss factors I should be aware of? Like if SN reputation, kick rate, stats or similar affect earnings negatively in the long run? There is no risk of losing your collateral running a servicenode. Usual caveats apply such as don't publish your private key |
|
|
|
If I wasn't excited about this project before I really am now after seeing our plans in colour  |
|
|
|
Very cool, wasn't there speculation that awoland was MrSpread back in the day? Yes, people definitely speculated  |
|
|
|
|
Show Posts
