Skip to content
This repository has been archived by the owner on Nov 2, 2018. It is now read-only.

Whitepaper Things #3

Closed
DavidVorick opened this issue Oct 20, 2014 · 7 comments
Closed

Whitepaper Things #3

DavidVorick opened this issue Oct 20, 2014 · 7 comments

Comments

@DavidVorick
Copy link
Member

I'm basically using this as a place for notes.

We should mention in the whitepaper that using the blockchain to find hosts is completely optional. A centralized service (like a coin exchange, a forum, a private tracker) is a perfectly acceptible way to find hosts that you are interested in.

Generally though we like having all of the hosts listed in one place because then the random file placement works better.

I am worried about a few things. Simplicity is nice but also scary. With the new system, there's nothing forcing hosts to be available to everyone. It felt more rigorously powerful to force hosts to accept random files, and it felt more rigorously powerful to force files upon random hosts.

It's more powerful because the big players can't leave the system. Super reliable hosts couldn't go off to the side and collect more expensive fees, scaring less reliable hosts away. Also, hosts had no incentive to be "super reliable" if it was significantly more expensive than being "mostly reliable". I'm afraid that people are going to be suboptimally trusting more expensive "super reliable" nodes when in fact the safest behavior is to buy 2 or 3 slots on less reliable nodes than a single larger slot on a super reliable node.

The old Sia didn't have any room for people changing that.

Basically we're trusting that our control of the client will be sufficient to prevent people from doing largely suboptimal things.

I guess that's also an advantage to us though. If our client can produce statistics that's substantially more reliable, cheaper, and faster than other clients, nobody is going to use a competing service. We have a way to stand out without losing customer share to other coins, because our super awesome client won't store on other coins.

Or something. Maybe it will, but only after we take a fee for ourselves again. lol.

It's just nerves though. I think that by being really good we'll be able to stay well ahead of the competition. But that requires actually being really good.

@DavidVorick
Copy link
Member Author

I realized we may want to make the transaction fee an explicit output for the miner.

Imagine that you're doing the Timmy thing, where we're raising $100. So I have 30 people put in $10 each, who each sign that only Timmy can get the $100 out. I then mine the block, and take a $200 transaction fee.

That's bad.

@DavidVorick
Copy link
Member Author

We might want to add some level of type safety, for example the inputs must match the outputs, and we have an explicit field for miner fee, and a different explicit field for funding a contract.

@DavidVorick
Copy link
Member Author

We should add a naive/example algorithm to the whitepaper that lets clients pick which hosts they upload to.

@DavidVorick
Copy link
Member Author

We should distinguish between files and data sectors - clients aren't really uploading files, they are uploading data sectors.

Perhaps though that's unncessary.

For some reason I also eliminated the word 'host', instead calling them 'storage providers' and 'providers', which makes me feel better. I really don't like the word host as a noun for some reason.

@lukechampine
Copy link
Member

maybe because of its association with viruses? :P

I've started using "peer" in the network code for maximum genericness.

I think it's fairly implicit that when we say "file," we mean arbitrary data.

@DavidVorick
Copy link
Member Author

I'm pretty firmly settled on updating the difficulty every block. There seems to be a handful of upsides and no downsides. These should all be discussed in the whitepaper:

  • stronger defense against the difficulty raising attack
  • clamp can be made equally strong to Bitcoin's clamp
  • substantially stronger defense against the timewarp attack ( https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 ) ==> it's not even it's own thread? lol I guess it's not that important.
  • Protection against difficulty raising attacks is continuous, instead of staggered.
  • Smoother difficulty adjustments mean less miners turning off their machines at the same time (miners will traditionally turn off their machines right after a difficulty change, because you'll get +25% all at once sometimes, which means many miners will cross from efficient to inefficient at the same moment. On the other hand if you're biggest change is +0.05%, then it's going to be rare that a bunch of miners become unprofitable at the same moment). Smoother hash rate means more predictable security assumptions.

Unrelated: need to discuss DoS attacks on providers

@DavidVorick
Copy link
Member Author

Could also talk about soft forking plans.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants