[ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming)

[coins101]

The bandwidth traffic should directly relate to the amount of simultaneous connections your node has.
People who run a node on a server with >100 connections will use a lot of bandwidth.

Good point.

I've seen a few people report the rather problematic bandwidth usage of full nodes, and while they post all kinds of graphs and reports,
they always ommit to tell you how many connections the node has open on average.

Of course, when your full node has 150 connections, you will have to "pay the price for this" so to speak.

Also, from a decentralization standpoint, it is much better (and cheaper) to have 10000 guys run a raspberry node than a full server.

Wait... let me visualize this....

Let's figure out how to help 10,000 guys run Bitcoin full nodes on a raspberry pi. Over the last year, node numbers have dropped by nearly 1,000 and the blockchain is only now starting to get to that point where most ordinary users will be contemplating their options for continuing to run a node.

[coins101]

@Dev

What we need is the the spreadwallet to download a bootstrap file from the longest chain compiled with the help of a few (8?) nearby nodes on mainnet.

That way, if you fire up a new node, you can download the entire blockchain and then get your node to verify it on sync. 1TB Bitcoin chain would take a few days to download using a bootstrap vs. a few months to download while verifying.

The issue about bandwidth is easy to solve, but it needs something to happen which won't be ready until early December.  

[rhinomonkey]

@Dev

What we need is the the spreadwallet to download a bootstrap file from the longest chain compiled with the help of a few (8?) nearby nodes on mainnet.

That way, if you fire up a new node, you can download the entire blockchain and then get your node to verify it on sync. 1TB Bitcoin chain would take a few days to download using a bootstrap vs. a few months to download while verifying.

The issue about bandwidth is easy to solve, but it needs something to happen which won't be ready until early December.  

I will definitely want to run a node or two on a Raspberry Pi for giggles when the new wallet comes out. It would be convenient to have some way to download the BTC blockchain without having it take a few weeks.

Furthermore, I think we could get some press just by having a few people running some nodes on the new wallet. It's a good way to show where the project is headed.

[rhinomonkey]

Also, is someone purposely suppressing price? Seems like the dumping is being forced. Hardly any large amounts of coins have been moved around on the block explorer. Maybe someone on trex is trying to get out of a relatively large position?

[legendbtc]

Also, is someone purposely suppressing price? Seems like the dumping is being forced. Hardly any large amounts of coins have been moved around on the block explorer. Maybe someone on trex is trying to get out of a relatively large position?

Yes some people are not believing themselves and selling at lower prices, i don't know why people keep selling their coins at low price and dumping the coin.

[rhinomonkey]

Also, is someone purposely suppressing price? Seems like the dumping is being forced. Hardly any large amounts of coins have been moved around on the block explorer. Maybe someone on trex is trying to get out of a relatively large position?

Yes some people are not believing themselves and selling at lower prices, i don't know why people keep selling their coins at low price and dumping the coin.

Oh well, no matter. I'm buying everything under 1 dollar 

[sparklerz]

Also, is someone purposely suppressing price? Seems like the dumping is being forced. Hardly any large amounts of coins have been moved around on the block explorer. Maybe someone on trex is trying to get out of a relatively large position?

Yes some people are not believing themselves and selling at lower prices, i don't know why people keep selling their coins at low price and dumping the coin.

Oh well, no matter. I'm buying everything under 1 dollar 

I hope you won't regret it by holding too so much coins in a bag. 

[rhinomonkey]

Also, is someone purposely suppressing price? Seems like the dumping is being forced. Hardly any large amounts of coins have been moved around on the block explorer. Maybe someone on trex is trying to get out of a relatively large position?

Yes some people are not believing themselves and selling at lower prices, i don't know why people keep selling their coins at low price and dumping the coin.

Oh well, no matter. I'm buying everything under 1 dollar  

I hope you won't regret it by holding too so much coins in a bag.  

Can't tell if you're being snarky, or genuinely concerned.

Have you seen this gold?

Everybody, thanks for waiting,
sorry, but there was a lot to digest first, and I'm far from finished...  

But lets dive in.

So here are some of the news about the new upcoming wallet, called Spreadwallet that will introduce a few changes.
I will have to split the info over a few posts, so consider this a first preview of what to expect.

I will give a short overview of the function and explain in the next post why I think it's a good idea to advance the wallet this way.

First of all, the spreadwallet is now a multicoin multiwallet that can operate in SPV and Fullnode mode.  

In short, what you'll get is:

- decentralized UTXO blockexplorer that works with the nodes you host locally (on your main computer or spread over your local network)
- 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.
- multiwallet support for many coins, immediate use of all those coins in SPV mode.
- support for many different styles of wallets (deterministic, non-deterministic, TREZOR and paperwallets)
- update of the spreadcoin daemon to newest bitcoin core codebase

In more detail:



You can see the main sections in this screen.

We have an explorer, based on the blockexplorer I've been working on for a while now.
It uses my own database engine called spreadDB for fast access to UTXO datastructures.
The explorer only works with full nodes you operate in your local network, be it on the same machine as your wallet, or e.g. a raspberry pi in your local network.

Above that we have a reserved section that will show all the wallets that you load/create,
and in the top right corner we have the section where all the nodes will be listed that the wallet is currently operating and connected to.
(Those can be Fullnodes or representations of SPV-Connections the wallet has with certain coins)

Once you "register" and "setup" a full node (or SPV-Connection) with the spreadwallet the explorer will start "exploring" the blockchain data and build the database that will allow you to quickly search for addresses, hashes, etc..
You will have to wait for the sync process to finish before the explorer can kick in. Although I am working on a mode where the explorer builds its database even while the blockchain is synching.
The explorer doesn't work with data it gets only through SPV-Connections.



BTW as you see in the top right corner the Nodes always inform you about how many connections they have and what percentage they are synched and explored.
Basically what was at the bottom of the old wallet (the statusbar) has now disappeared and all info about Nodes will be visualized directly in the respective Node-Box.
The "SPV nodes" look a little different than the Full Nodes to make them easily distinguishable.



When it's finished, the "Chains" sidebar menu will give you general information of all the chains/coins you are connected to.
This will list a few coin parameters a difficulty graph and a hashrate graph. Similar to what the old wallet shows in the overview screen of the mining menu.
This chain-list will include SPV connections, since all this data can be derived from header data alone, so that's good!

So how exactly will you add Nodes?



Remember that Genesis-Extractor experiment we started some time ago?
Here's the link to refresh your memory: http://spreadcointalk.org/index.php?board=21.0

We will continue to build on this information to provide useable data for the spreadwallet, so that we have all the necessary information to handle multiple coins.
I will start with a list of a few coins that I will personally test, we can then continue from there and add coins as the community sees fit.
But generally speaking ... you can customize this list anyway you want since it will be comprised of external files that are human readable.

Furthermore, some coins will not work with the wallet rightaway, so we will have to find different solutions later.
For example, AFAIK etherium doesn't use UTXO format, so it can't be scanned by the current version of the blockexplorer.
But coins that are very similar to spreadcoin will work rightaway.

So based on this external coinlist the Spreadwallet will present to you a few coins that you can activate/deactivate.
The three states of "coin connection" (or "Node state" if you will) are

Off
SPV
Full

Once a node is in SPV mode, you can basically use it rightaway. The Spreadwallet does everything automatically. It's like a multi-headed SPV-Monster.

If you put a node in Full mode, you will need to set it up first. (More about it later in more detail). This means you have to download the official daemon from the coins site and tell spreadwallet where you installed it, etc...

Now, there are 2 cool things about the way you can run full nodes here:

1) you can quickly setup raspberry pi's that will act as 24/7 full nodes that communicate with the spreadwallet over SSH. Everything is done through the wallet.
(Just to emphasize: I'm currently running my spreadwallet with only a raspberry pi as main full spreadcoin node.   And, as you would expect, the raspberry node keeps on running 24/7, even if I shut down my main computer!   )

2) you can quickly switch between Full and SPV mode depending on your needs. (ever waited for a full bitcoin node to synch to make a quick payment? Well, you can choose to temporarily switch to a SPV connection for BTC and afterwards switch back)

You will be able to scan your local network and figure out which computers and raspberries are available, and what IP they have, etc...
There are still many things missing here, I will inform you about progress.

I'm currently using a few Raspberry Pi 3, but am also exploring if it would be possible to use earlier versions of Raspberry Pi to do "some kind" of other non-node work. I do have a few ideas....



Next screen:



The spreadwallet does not contain a full node in its code, instead you will connect with a spreadcoin deamon that will be included in the package.
I repeat: Spreadwallet and spreadcoin daemon/CLI (based on newest bitcoin CORE) are now two different repositories.

Ok, continuing: The spreadwallet will be centered around ... well.... WALLETS! what else.

The details here are pretty extensive and there are lots of things I am still fleshing out, so I will have to inform you over the next days how the internals of the multi-wallet behaviour will look like and operate.

Here's another screen, with multiple coins simultaneously



BTW, it's entirely possible to run the wallet offline, just to create wallets (especially paperwallets) in a more secure fashion.
And vice versa, you can run Spreadwallet without having any wallet imported, just hosting a few full nodes to operate the blockexplorer.
Fully customizable.

You can even run spreadwallet completely without spreadcoin if you want!  

I don't care, the user decides! But that's how you create standards everyone likes to use.

So, to sum it up, this is the progress about the first of the three main things that keep me occupied right now:

1) Spreadwallet
2) Spreadminer (more info soon)
3) Servicenodes (more info about P2P and overlay research soon)

[coins101]

If using the Spreadsheet that Coins put up earlier this year and using the max nodes value of coinsupply/2880 the ROI calculations for running a Bitcoin node are starting to look interesting if the price keeps moving up



I adjusted the max service nodes based on Georgem's original gif, but I doubt we would see the max number of nodes immediately, so the ROI should still be ok while the price keeps going up attracting more nodes and then competitive bidding for rewards.

..snip...
In 4 years time, the VPS would need to have 1TB drive, so the value of each Spreadcoin would need to be approaching $5.

The issue will be bandwidth. When Bitcoin reaches 500GB-1TB, the bandwidth available from typical VPS's might start to cause problems.



If users host full nodes on domestic bandwidth, although they may get unlimited bandwidth the 'unlimited' terms and conditions might restrict some people to a 'fair use' policy. What's fair use? That is usually left vague so the ISP have some wriggle room.

Looks like BitFury are already paying $2k/year to run a full node.



They say they need to pay this much to make sure their mining operations are not impacted at all: super fast connectivity; no latency; no downtime; etc.

And we are not at 100GiB yet.  

Not everyone will need to spend this much. $200/year, at the moment should be fine. But it's an indication on the direction of travel.

[rhinomonkey]

There's a conversation on reddit going on about that. Someone suggested they could get their costs down to 47K, but that's still quite a hefty amount of money.

https://www.reddit.com/r/btc/comments/54gj7s/alex_petrov_bitfury_just_check_our_expense_list/

[coins101]

There's a conversation on reddit going on about that. Someone suggested they could get their costs down to 47K, but that's still quite a hefty amount of money.

https://www.reddit.com/r/btc/comments/54gj7s/alex_petrov_bitfury_just_check_our_expense_list/

It's a really interesting 'argument' - why would anyone pay $180k when they are being told they can pay orders of magnitude less?

There is a guy there who is doing a great job going through and justifying the need for good services.

I suspect the answer is - it depends on why you are running a node. If its business critical, you pay over the top; if its for altruistic reasons (help bitcoin for no reward), then it's running off your spare bandwidth when Netflix is not running.

Meanwhile:



People keep switching of their nodes. The actual numbers of 'always up' nodes vs. part-time on/off nodes, must be around 3,000. How many regular users around the world now? 5 Million? 10 Million?

[rhinomonkey]

There's a conversation on reddit going on about that. Someone suggested they could get their costs down to 47K, but that's still quite a hefty amount of money.

https://www.reddit.com/r/btc/comments/54gj7s/alex_petrov_bitfury_just_check_our_expense_list/

It's a really interesting 'argument' - why would anyone pay $180k when they are being told they can pay orders of magnitude less?

There is a guy there who is doing a great job going through and justifying the need for good services.

I suspect the answer is - it depends on why you are running a node. If its business critical, you pay over the top; if its for altruistic reasons (help bitcoin for no reward), then it's running off your spare bandwidth when Netflix is not running.

Meanwhile:



People keep switching of their nodes. The actual numbers of 'always up' nodes vs. part-time on/off nodes, must be around 3,000. How many regular users around the world now? 5 Million? 10 Million?

The situation does seem a bit grim. Even if I develop strong enough convictions to run a full bitcoin node on my own volition, the node would only be running 1% of the day because of Netflix and chill.  

It would take even stronger convictions (and slightly deeper pockets) to set one up on a VPS with far better up-time.

I have a feeling a lot of people who are using Bitcoin, but have a lay understanding of the way it works, don't realize that this (lack of worthy nodes) is a real problem. And even people within the community are quick to say it's not a big deal because "people will be willing to pay for the soon-to-be cheap hard drives." I know at least for me, I'm not going out of my way to set up a full node even if it only cost me 30 bucks.

@Sugarfly, how difficult was it for you to set up / maintain your BTC full Node on the Raspberry Pi?

[rhinomonkey]

This is how Proof of Bitcoin Node (or any cross chain Node) needs to work, using the OP_RETURN updates in BIP74



The internal communications within the Spreadwallet make this whole thing work. The internal communications within the Spreadwallet can be similar to the way exchanges deal with transactions, they have their own ledgers that keep track of whats going on, and only when customers put money in or take money out do they interact with specific coin daemons.

Because of Bitcoin confirmation wait times, the completion of the proof might take 10 minutes or 10 days, but the relay communications can be ring fenced / locked by the servicenode network to avoid an attacker stealing payments.

If you have the required public and private keys, only you can create and confirm the hash as proof of the broadcast message.

In regards to this post ^

You suggested something about BIP74 found here: https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki

So would that have to be implemented into Bitcoin in order for this all to work?

People who have issues with the block size would be against adding more data per block, no?

Also, in my recent reading (about proving full nodes), I saw some mention of Proof of Storage. Do you know anything about that?

[coins101]

This is how Proof of Bitcoin Node (or any cross chain Node) needs to work, using the OP_RETURN updates in BIP74



The internal communications within the Spreadwallet make this whole thing work. The internal communications within the Spreadwallet can be similar to the way exchanges deal with transactions, they have their own ledgers that keep track of whats going on, and only when customers put money in or take money out do they interact with specific coin daemons.

Because of Bitcoin confirmation wait times, the completion of the proof might take 10 minutes or 10 days, but the relay communications can be ring fenced / locked by the servicenode network to avoid an attacker stealing payments.

If you have the required public and private keys, only you can create and confirm the hash as proof of the broadcast message.

In regards to this post ^

You suggested something about BIP74 found here: https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki

So would that have to be implemented into Bitcoin in order for this all to work?

People who have issues with the block size would be against adding more data per block, no?

Also, in my recent reading, I saw some mention of Proof of Storage. Do you know anything about that?

This BIP update would need to find its way into Bitcoin.

This is one approach, one that I think could work with some sort of Proof of running a Bitcoin Node. If you can attach some meta data and have that going into the blockchain, you can look that up to do some validation.

The requirement to have collateral is a great way to fix the issue of fake SPR nodes, but the Bitcoin nodes will be held by the SPR node. So we need a way for the Spreadwallet to communicate with the Bitcoin node and then the bitcoin blockchain. Possibly making the Spreadwallet a Bitcoin wallet too.

The good think is that the Spreadwallet can create a hash of something, like a notification that the particular ServiceNode has been elected for payment subject to verification.   Being able to pass a hashed message through the ServiceNode >> get that into a payment loop into the Bitcoin blockchain via the Spread/Bitcoin wallet >> and then back out again because the Spreadwallet can validate the hashed message >> could be an option to our particular Sybil problem.

Will it add more data to the blockchain? Yes. It is worth the price to? If it creates a payment system for running nodes, i think so. The long term goal is to help fund mining too, so the network will be paying for the data storage.

Easy? No. Possible? Maybe.

Proof of storage. Remind me.....do you mean the MIT research on doing data mining on encrypted databases?

[coins101]

A not so complex variation of this:

No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here.

Sounds reasonable.

A picks a random number x

A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"

A creates TX2: "Pay w BTC from TX1 to <A's public key>, locked 48 hours in the future, signed by A"

A sends TX2 to B

B signs TX2 and returns to A

1) A submits TX1 to the network

B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"

B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future, signed by B"

B sends TX4 to A

A signs TX4 and sends back to B

2) B submits TX3 to the network

3) A spends TX3 giving x

4) B spends TX1 using x

This is atomic (with timeout).  If the process is halted, it can be reversed no matter when it is stopped.

Before 1: Nothing public has been broadcast, so nothing happens
Between 1 & 2: A can use refund transaction after 48 hours to get his money back
Between 2 & 3: B can get refund after 24 hours.  A has 24 more hours to get his refund
After 3: Transaction is completed by 2
- A must spend his new coin within 24 hours or B can claim the refund and keep his coins
- B must spend his new coin within 48 hours or A can claim the refund and keep his coins

For safety, both should complete the process with lots of time until the deadlines.

[rhinomonkey]

This BIP update would need to find its way into Bitcoin.

This is one approach, one that I think could work with some sort of Proof of running a Bitcoin Node. If you can attach some meta data and have that going into the blockchain, you can look that up to do some validation.

The requirement to have collateral is a great way to fix the issue of fake SPR nodes, but the Bitcoin nodes will be held by the SPR node. So we need a way for the Spreadwallet to communicate with the Bitcoin node and then the bitcoin blockchain. Possibly making the Spreadwallet a Bitcoin wallet too.

The good think is that the Spreadwallet can create a hash of something, like a notification that the particular ServiceNode has been elected for payment subject to verification.   Being able to pass a hashed message through the ServiceNode >> get that into a payment loop into the Bitcoin blockchain via the Spread/Bitcoin wallet >> and then back out again because the Spreadwallet can validate the hashed message >> could be an option to our particular Sybil problem.

Will it add more data to the blockchain? Yes. It is worth the price to? If it creates a payment system for running nodes, i think so. The long term goal is to help fund mining too, so the network will be paying for the data storage.

Easy? No. Possible? Maybe.

Proof of storage. Remind me.....do you mean the MIT research on doing data mining on encrypted databases?

It seems like a less than ideal way of going about things just because you would have to rely on it being implemented. I understand the incentives work in the network's favor, but maybe some people would resist it just because of the block size issue. Ideally a way could be found without having to change Bitcoin at the protocol level, no?

I suppose if it was the only viable way, there would be lots of lobbying the bitcoin developers to implement it. We would need tons of PR.

I remember Georgem said a while back something about the proof we were looking for was a proof that showed one bitcoin node was associated with one and only one full node. Is there no other way that you can thing of without implementing a BIP into BTC? You said it was only one of the options.

As for the proof of storage, I don't actually know. I was genuinely curious. I saw it referred to in this forum topic here:

I would guess the biggest problem you'd face with such an idea is "just how do you determine that someone has a full node"?

This would not be a trivial thing to do as presumably it would require some sort of separate consensus algorithm (i.e. a "proof of storage" type idea).

I wasn't exactly sure what this person was referring to.

He goes on to explain in some more detail.

Upon reading further I actually think he was alluding to proof of storage of the bitcoin blockchain...

Seems like actually a few people suggested an alt-coin that helped with it. But no one really had the answers when it came down to it.

[rhinomonkey]

A not so complex variation of this:

No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here.

...

This clarified the graphic to some degree, actually. If I'm understanding correctly, you have a service node that is elected for payment, it relays an invoice using BIP74 to the bitcoin network through the SpreadWallet. Once that's confirmed, the SpreadWallet recognizes that and sends payment to the service node. If the SN wasn't legit, it would have never relayed the invoice in the first place, and would become ineligible for receipt of payment.

[coins101]

A not so complex variation of this:

No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here.

...

This clarified the graphic to some degree, actually. If I'm understanding correctly, you have a service node that is elected for payment, it relays an invoice using BIP74 to the bitcoin network through the SpreadWallet. Once that's confirmed, the SpreadWallet recognizes that and sends payment to the service node. If the SN wasn't legit, it would have never relayed the invoice in the first place, and would become ineligible for receipt of payment.

Don't get hung up on the invoice number thing.. it was just an example used during the BIP discussion process by the guy proposing it.

What he was basically saying is that additional information can be sent to the bitcoin blockchain without a fee using the OP_RETURN codes and that's what we're interested in when seeking to create a proof.

[sugarfly]

@Sugarfly, how difficult was it for you to set up / maintain your BTC full Node on the Raspberry Pi?

I followed roger ver's instructions:
https://forum.bitcoin.com/bitcoin-discussion/check-out-my-85-raspberry-pi-bitcoin-full-node-t5542.html

georgem seems to be using an external HD. (makes it more complicated)
I have a 256 GB SDCard.

I haven't yet monitored my node over a long period of time, but I am sure there is room for improvement.

-sf-

[coins101]

A not so complex variation of this:

No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here.

...

This clarified the graphic to some degree, actually. If I'm understanding correctly, you have a service node that is elected for payment, it relays an invoice using BIP74 to the bitcoin network through the SpreadWallet. Once that's confirmed, the SpreadWallet recognizes that and sends payment to the service node. If the SN wasn't legit, it would have never relayed the invoice in the first place, and would become ineligible for receipt of payment.

Don't get hung up on the invoice number thing.. it was just an example used during the BIP discussion process by the guy proposing it.

What he was basically saying is that additional information can be sent to the bitcoin blockchain without a fee using the OP_RETURN codes and that's what we're interested in when seeking to create a proof.

@dev

I think sending a 40 byte hash of a validation check from spreadwallet into an internal communications channel that triggers a bitcoin wallet to confirm that same hash on the bitcoin blockchain via OP_RETURN is a strong contender for PoBN, in our servicenode context.

edits

some of the crap that gets into the blockchain



or could these be proofs?