DavidVorick

Keybase proof

I hereby claim:

• I am davidvorick on github.
• I am taek42 (https://keybase.io/taek42) on keybase.
• I have a public key ASCPihl8s_D-doqVB2ugjyJHcr3KBAzr688NbALruk71lQo

To claim this, I am signing this object:

DavidVorick

I wanted to highlight that patents in the PoW world are very bad for the health of a cryptocurrency. The problem is that if one party or group has exclusive access to an advantage, they will over time be able to put every one else out of business, even if that advantage is small. For this reason, cryptocurrencies should be very proactive about shutting down patents that are owned by mining companies or groups, lest they fall into complete centralization.

Let's assume that we have 2 parties mining. One party (party A) has a patented 30% efficiency advantage over the other party. These parties each start with 40 TH/s, and buying more hashrate costs $10 per TH/s. The party without the patent (Party B) needs to spend $1 per month on electricity per TH/s, while Party A only needs to spend $0.70 per month on electricity. The total block reward is

DavidVorick

ccdb

ccdb is a database that:

• has buckets
• is transactional
• is ACID
• has random access values (can read and write partial values)
• has appendable values (can append to a value already stored in the database)

DavidVorick

This document is a proposed roadmap for the renter. It contains a lot of long term code projects, and a path to get there incrementally. It is our goal to never refactor more than a small part of the code at a time, and to divide the code cleanly so that multiple people can easily work on the code in parallel.

Sprint 1: Distributed Renter Abstraction

An important feature for moving towards large enterprise customers is a distribtuted renter, where multiple renters use the same filesystem and the same set of contracts. This allows larger systems to be set up with multiple nodes,

DavidVorick

Purpose: Suggest a new method for choosing fees on a transaction. Goal is to get a transaction confirmed as cheap as possible within the provided timeframe, with emphasis on both not missing the time window, and also on not going over the user's maximum fee.

Existing Problems:

1. Transaction fee setting is currently really 'loose'. Blocks will have transaction fees between 300 sats and 500 sats, which means that, at the very least, everyone at 500 sats could have gotten in at 300 sats. That's a huge spread.

2. Loose fee markets just generally drives prices up quite a bit. People see '300' and '500' as the 0-1 block confirmation rate, and that's where they set their expectations. They don't like it, but they know that's what the market is, so that's where they put their fees. Basically, we've ended up with a market where people are trying hard to make sure that they are using fees that are good enough instead of using fees that are what they could reasonably get away with.

3. The emphasis on getting confir

DavidVorick

Construction

It will be easiest for me to explain Jute by starting with Bitcoin-style consensus and modifying it. And the first change to make is to allow blocks to have multiple parents. This changes our 'chain' into a directed acyclic graph, or 'rope' (also called a braid or a tangle). A block can have multiple parents, but no parent can be an ancestor of another parent. Banning ancestor inclusion is not strictly necessary, but makes implementation easier. Turning the blockchain into a rope means that multiple blocks can be mined in parallel, and then later merged into the chain. In Bitcoin style consensus, when two blocks are mined with the same parent, one will definitely become an orphan. By allowing a child block to point to multiple parents, we can enable both blocks to be included in the chain, meaning that both may be able to get block rewards.

Unmerged chaintips are called 'threads', and may consist of multiple bl