Dist.ribut.us Claude - Revision history

Adamcolton at 17:41, 1 May 2018

2018-05-01T17:41:13Z

← Older revision		Revision as of 17:41, 1 May 2018
Line 18:		Line 18:
	== Identity Credit (puzzle tower) ==		== Identity Credit (puzzle tower) ==
	I like [https://youtu.be/bWKK_z-Rh4Q?t=16m2s this idea] - nodes build up an identity by validating individual transactions and performing hash puzzles on them. The block is composed of these sub validations. Each time a node get a transaction into a block, it's reputation increases. Over time, the reputation decays. More reputation makes it easier to mine a block. Taking any Byzantine action that can be cryptographically proven, can be registered to the chain and destroy that ID.		I like [https://youtu.be/bWKK_z-Rh4Q?t=16m2s this idea] - nodes build up an identity by validating individual transactions and performing hash puzzles on them. The block is composed of these sub validations. Each time a node get a transaction into a block, it's reputation increases. Over time, the reputation decays. More reputation makes it easier to mine a block. Taking any Byzantine action that can be cryptographically proven, can be registered to the chain and destroy that ID.

	== Fuel ==		== Fuel ==
	I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.		I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.

			== Must Hold ==
			To facilitate transactions and prevent double-spend, some or all accounts could require a must-hold for transactions. This may not work, but it warrants further investigation; if an account creates a transaction that uses less than half of the funds in the account, that is automatically cleared. If a transaction would spend more than half of the money in the account, it requires a certain number of blocks to complete.

			This is under the assumption that a malicious double-spend will take the form of; from A send X to B then another transaction of from A send Y to E so the remainder is <X. Even if the second transaction makes it in first, the first transaction will cause it to be canceled. It does create an issue that for transactions spending >50% of an account, you now have to wait for the transaction closed block, then enough blocks after that to be sure the transaction has closed.

	[[Category:dist.ribut.us]]		[[Category:dist.ribut.us]]

Adamcolton at 13:52, 13 April 2018

2018-04-13T13:52:38Z

← Older revision		Revision as of 13:52, 13 April 2018
Line 16:		Line 16:
	Any of these approaches also opens up the ability to do pipelining similar to a CPU - work on several blocks at different stages simultaneously. For each transaction, if we have all the locks, put it in the current block, otherwise request the locks and put it in the next block.		Any of these approaches also opens up the ability to do pipelining similar to a CPU - work on several blocks at different stages simultaneously. For each transaction, if we have all the locks, put it in the current block, otherwise request the locks and put it in the next block.

			== Identity Credit (puzzle tower) ==
			I like [https://youtu.be/bWKK_z-Rh4Q?t=16m2s this idea] - nodes build up an identity by validating individual transactions and performing hash puzzles on them. The block is composed of these sub validations. Each time a node get a transaction into a block, it's reputation increases. Over time, the reputation decays. More reputation makes it easier to mine a block. Taking any Byzantine action that can be cryptographically proven, can be registered to the chain and destroy that ID.
	== Fuel ==		== Fuel ==
	I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.		I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.

	[[Category:dist.ribut.us]]		[[Category:dist.ribut.us]]

Adamcolton at 13:31, 13 April 2018

2018-04-13T13:31:17Z

← Older revision		Revision as of 13:31, 13 April 2018
Line 13:		Line 13:

	Of course, we could take this a level further and instead of locking, just transfer control. So the transfer actually says "this account is now controlled by what ever shard controls 9,0...0". And it just stays there. Accounts will jump around, but that doesn't matter.		Of course, we could take this a level further and instead of locking, just transfer control. So the transfer actually says "this account is now controlled by what ever shard controls 9,0...0". And it just stays there. Accounts will jump around, but that doesn't matter.

			Any of these approaches also opens up the ability to do pipelining similar to a CPU - work on several blocks at different stages simultaneously. For each transaction, if we have all the locks, put it in the current block, otherwise request the locks and put it in the next block.

			== Fuel ==
			I think the fuel must be consumed. Originally I was thinking we would only consume the fuel of a successful transaction. But that seems ripe for abuse. I think the better approach is that a transaction must put up some fuel up-front and can add more fuel as the transaction proceeds. But even if the transaction fails, the spent fuel is burned.

	[[Category:dist.ribut.us]]		[[Category:dist.ribut.us]]

Adamcolton at 18:09, 9 April 2018

2018-04-09T18:09:03Z

← Older revision		Revision as of 18:09, 9 April 2018
Line 9:		Line 9:

	The core can be sharded with locking. So if there were two shards one would handle 0-8 and two would handle 9-F. If a transaction spanned both, then it takes two blocks to complete. Lets say we're transferring from 0X to 9X and the 0-8 shard is going to handle it. In a back-channel (not recorded) 0-8 requests a lock on the 9X account. The next block that 9-F releases includes a lock on 9X for 0-8 for one block. In the block after that, 0-8 can perform the transaction.		The core can be sharded with locking. So if there were two shards one would handle 0-8 and two would handle 9-F. If a transaction spanned both, then it takes two blocks to complete. Lets say we're transferring from 0X to 9X and the 0-8 shard is going to handle it. In a back-channel (not recorded) 0-8 requests a lock on the 9X account. The next block that 9-F releases includes a lock on 9X for 0-8 for one block. In the block after that, 0-8 can perform the transaction.

			This may not work because it requires that the blocks stay in sync. Another approach would be 9-F to set on a lock on 9X, then 0-8 can perform transactions that instead of referencing the account directly, reference the lock. Then 0-8 executes an action that releases the lock and 9-F reclaims the lock.

			Of course, we could take this a level further and instead of locking, just transfer control. So the transfer actually says "this account is now controlled by what ever shard controls 9,0...0". And it just stays there. Accounts will jump around, but that doesn't matter.

	[[Category:dist.ribut.us]]		[[Category:dist.ribut.us]]

Adamcolton: Created page with "== Progressive Layers == Getting away from block-chain and hash-puzzles, the core challenge of a distributed currency is recording transactions in an open and accountable way...."

2018-04-09T17:25:58Z

Created page with "== Progressive Layers == Getting away from block-chain and hash-puzzles, the core challenge of a distributed currency is recording transactions in an open and accountable way...."

New page

== Progressive Layers ==
Getting away from block-chain and hash-puzzles, the core challenge of a distributed currency is recording transactions in an open and accountable way.

The catch-22 is that as we make the agreement process broader we gain trust, but it takes longer to validate transactions. As we narrow, it becomes possible for the controlling nodes to act maliciously.

It may be possible to mitigate this with a layering scheme. There's an outer layer responsible for distributing the data - acting almost purely as a CDN. The next layer performs validation. It can't write transactions, but it can veto a transaction by showing that it's malformed. The inner most layer can actually write transactions to the ledger.

The second layer can also form a transaction pool. The transaction pool attempts to pre-sort the transactions into a queue for the core. Classic chain-fork-resolution can be handled at this layer. A node can submit a transaction to this layer and quickly get an accept or reject - or submit to a few nodes at this layer for more confidence. If a fork-resolution invalidates a pending transaction, an event is emitted making it easy to track.

The core can be sharded with locking. So if there were two shards one would handle 0-8 and two would handle 9-F. If a transaction spanned both, then it takes two blocks to complete. Lets say we're transferring from 0X to 9X and the 0-8 shard is going to handle it. In a back-channel (not recorded) 0-8 requests a lock on the 9X account. The next block that 9-F releases includes a lock on 9X for 0-8 for one block. In the block after that, 0-8 can perform the transaction.

[[Category:dist.ribut.us]]