Pages:
Author

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

legendary
Activity: 1456
Merit: 1000
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.
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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.
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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.

legendary
Activity: 1456
Merit: 1000
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 if (x for H(x) known and signed by B) or (signed by A & B)"

A creates TX2: "Pay w BTC from TX1 to , 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 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 , 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.
legendary
Activity: 1456
Merit: 1000
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?
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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?
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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.  Wink

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?
legendary
Activity: 1456
Merit: 1000
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?
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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/
legendary
Activity: 1456
Merit: 1000
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.
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
member
Activity: 67
Merit: 10
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  Grin Grin

I hope you won't regret it by holding too so much coins in a bag.  Grin
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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  Grin Grin
hero member
Activity: 1218
Merit: 507
Leading Crypto Sports Betting & Casino Platform
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.
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
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?
hero member
Activity: 646
Merit: 501
Ni dieu ni maître
@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.
legendary
Activity: 1456
Merit: 1000
@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.  
legendary
Activity: 1456
Merit: 1000

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.

legendary
Activity: 1456
Merit: 1000
...


...

....But, what if you zoomed out of that picture and those two full nodes were actually 5,000 full nodes run by miners, businesses, altruists + 5,000 ServiceNodes running full bitcoin nodes, serving 10million or 100million Bitcoin users round the world?

That would look a little more decentralized, especially vs just 5,000 full nodes run by miners, businesses and altruists alone.

SPV's are already the most popular way to use Bitcoin, which is fine for mass adoption, so this chart is already the future, today.
legendary
Activity: 1456
Merit: 1000
I think this post should be preserved around here, because of the email from Satoshi on the future of incentives for Nodes (I don't want to raise the issue of small vs large blocks, as I think that issue is going to resolve itself over the long-term):

Well thanks for being the "spokesperson" for everyone here but I think you'll find that quite a few people disagree and if Satoshi really had planned for Bitcoin to be a tx system to compete with the likes of Paypal/Visa then you don't think he might have made a mistake or two (if not then why does this very thread exist)?

Ian, Satoshi did plan for Bitcoin to compete with PayPal/Visa in traffic volumes. The block size limit was a quick safety hack that was always meant to be removed.

In fact, in the very first email he sent me back in April 2009, he said this:

Quote from: satoshi
Hi Mike,

I'm glad to answer any questions you have.  If I get time, I ought to write a FAQ to supplement the paper.

There is only one global chain.

The existing Visa credit card network processes about 15 million Internet purchases per day worldwide.  Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost.  It never really hits a scale ceiling.  If you're interested, I can go over the ways it would cope with extreme size.

By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10.  Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.

I don't anticipate that fees will be needed anytime soon, but if it becomes too burdensome to run a node, it is possible to run a node that only processes transactions that include a transaction fee.  The owner of the node would decide the minimum fee they'll accept.  Right now, such a node would get nothing, because nobody includes a fee, but if enough nodes did that, then users would get faster acceptance if they include a fee, or slower if they don't.  The fee the market would settle on should be minimal.  If a node requires a higher fee, that node would be passing up all transactions with lower fees.  It could do more volume and probably make more money by processing as many paying transactions as it can.  The transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces.

Eventually, most nodes may be run by specialists with multiple GPU cards.  For now, it's nice that anyone with a PC can play without worrying about what video card they have, and hopefully it'll stay that way for a while.  More computers are shipping with fairly decent GPUs these days, so maybe later we'll transition to that.

Satoshi said back in 2010 that he intended larger block sizes to be phased in with some simple if (height > flag_day) type logic, theymos has linked to the thread before.

I think he would be really amazed at how much debate this thing has become. He never attributed much weight to it, it just didn't seem important to him. And yes, obviously, given the massive forum dramas that have resulted it'd have been nice if he had made the size limit floating from the start like he did with difficulty. However, he didn't and now we have to manage the transition.

Quote
1) My question is why will nodes contribute on behalf of everyone(including wasteful nodes)? Or is there a scheme where the payee can filter which txns are subsidised?

The "why" is the whole point of assurance contracts. They're a way to fund the creation of what economists call public goods, that is, goods which cost money to create but once created benefit everyone for free with no way to exclude people. The canonical example is a lighthouse.

Why will nodes contribute on the behalf of everyone? Firstly, it's not actually nodes, it's "receivers of funds", and it doesn't need to be all of them, just some. They will fund these contracts because they need network security and thus mining to take place. Yes, by doing so, they implicitly subsidize freeloaders who don't pay, however that's the reason for the design of an assurance contract - it means others have to chip in, otherwise nobody pays anything.

Quote
Even if there are big Bitcoin businesses which benefit from sustaining the network, how do we know their contribution will be enough?

The system naturally converges upon an equilibrium in which the only businesses that use Bitcoin are the ones who can tolerate the delay/double-spend-frequency tradeoff. If other businesses want more hashing in less time, they can join the contracts and result in more fees. So "enough" is a relative term. It will always be "enough" for the current set of users, and for other sets the equilibrium hash rate may be more or less than what they need.

Bear in mind that if everyone thinks "I won't pay for hashing because my competitors will" then the contract does not complete and nobody pays anything, therefore nobody gets any security. That's the purpose of an assurance contract - I pay only if my competitors also pay.

W.R.T "waste" - you have to distinguish between the cost of mining and the cost of validation. The two are not connected except that the cost of mining is always more than the cost of validation, because mining requires validation. I believe validation will be, even at high transaction rates, cheap enough that people can just swallow them as a cost of business or even just for hobbyist reasons. Alternatively, people can once again band together and form assurance contracts to fund the running of full nodes.

Quote
Having said that, maybe im wrong. If you feel strongly that this will work, please implement it and prove me wrong so that we can all have free Bitcoin txns.

Unfortunately I can't do that today. The present situation is that hash speeds are so great thanks to inflation that nobody is successfully double spending via forced re-orgs (the attack that lots of mining prevents). So there's no incentive for anyone to fund mining via fees, the only reason anyone is attaching fees at all right now is to try and win the block space auction or avoid DoS checks. Currently inflation is "good enough" and this has, in fact, always been the case.

One of the curious things about this whole argument is nobody knows the future well enough to implement solutions today. For all we know it can be the year 2050 and a single Bitcoin is worth so much that inflation is still driving hash speeds sky high. There may never even need to be incentivization via fees within our lifetimes. Or maybe there will. If there is, then if I'm still around I'll sit down and write the code.

Highlighting:

"Eventually, most nodes may be run by specialists [with multiple GPU cards]."
Pages:
Jump to: