BuildingCellsByBlockChain

Protocol.BuildingCellsByBlockChain History

Hide minor edits - Show changes to output

Changed lines 41-45 from:
As more and more connections form between the two cells/endpoints, it may be useful to merge by one inviting the other in to its structure, and then the other possibly dissolving, or having only some of its members leave to join the new mother cell's structure in a more fine-grained way.  There are a lot of possibilities, but given well-defined conventions, hopefully this can happen smoothly, in a measured, orderly way, without being too hard to implement in software.
to:
As more and more connections form between the two cells/endpoints, it may be useful to merge by one inviting the other in to its structure, and then the other possibly dissolving, or having only some of its members leave to join the new mother cell's structure in a more fine-grained way.  There are a lot of possibilities, but given well-defined conventions, hopefully this can happen smoothly, in a measured, orderly way, without being too hard to implement in software.

!! Routing Restrictions

To work with [[Protocol/KnowledgeRouting | payer-computed routes]], all exchanges within a cell would have to be at a rate of 1.0, and credit reservation fees could only be charged at the boundaries
.
February 20, 2011, at 07:02 AM by Ryan - Replace "controller" with "representative"
Changed lines 5-12 from:
Cells organize around a Bitcoin-style [[https://en.bitcoin.it/wiki/Block_chain | block chain]].  Each block defines membership in a cell, as well as which endpoint acts as the routing controller for the duration of that block. 

!! Routing Controller

Each block has a public key in it which validates routing advertisement messages from that cell to the outside world.  Only the peer who computed the lastest block can sign these messages.  This peer is the routing controller.  When they become eligible for a cell, members may invalidate their previous advertisements of connections to the outside world, preferring to let the cell's controller send out aggregate advertisements for the whole cell, on the assumption that the cell has sufficient internal routing capacity between any two external connections to handle most any potential through transaction.

When a new block is computed, the old controller must broadcast a message signing over routing authority to the new controller.  This message is broadcast to the outside world also, so it knows the new cell authority's key.  If it does not do so within a reasonable amount of time, endpoints within the cell can just start unilaterally sending out their own individual routing messages, effectively dissolving the cell.  The routing controller is responsible for sending out routing advertisements on behalf of all cell members for links between the cell's members and the outside world.  If it fails to do so to the satisfaction of any cell member, that member is free resume its own advertisements as a standalone endpoint. 
to:
Cells organize around a Bitcoin-style [[https://en.bitcoin.it/wiki/Block_chain | block chain]].  Each block defines membership in a cell, as well as which endpoint acts as the routing representative for the duration of that block. 

!! Routing Representative

Each block has a public key in it which validates routing advertisement messages from that cell to the outside world.  Only the peer who computed the lastest block can sign these messages.  This peer is the routing representative.  When they become eligible for a cell, members may invalidate their previous advertisements of connections to the outside world, preferring to let the cell's representative send out aggregate advertisements for the whole cell, on the assumption that the cell has sufficient internal routing capacity between any two external connections to handle most any potential through transaction.

When a new block is computed, the old representative must broadcast a message signing over routing authority to the new representative.  This message is broadcast to the outside world also, so it knows the new cell authority's key.  If it does not do so within a reasonable amount of time, endpoints within the cell can just start unilaterally sending out their own individual routing messages, effectively dissolving the cell.  The routing representative is responsible for sending out routing advertisements on behalf of all cell members for links between the cell's members and the outside world.  If it fails to do so to the satisfaction of any cell member, that member is free resume its own advertisements as a standalone endpoint. 
Changed line 25 from:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The [[https://en.bitcoin.it/wiki/Difficulty | difficulty of computing a block]] ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.
to:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing representative for that block.  The [[https://en.bitcoin.it/wiki/Difficulty | difficulty of computing a block]] ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.
Changed lines 25-27 from:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The [https://en.bitcoin.it/wiki/Difficulty | difficulty of computing a block] ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.

The difficulty can be set by a coefficient to the [https://en.bitcoin.it/wiki/Target | hash target] for the next block.  Whoever computes the next block unilaterally decides membership eligibility going forward.  The hash target for a cell would be updated periodically according to network convention in order to achieve a new block over a target period, also set by network convention.  The period should be longer than Bitcoin's 10 minutes -- perhaps one day is a good target block period, perhaps one hour. 
to:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The [[https://en.bitcoin.it/wiki/Difficulty | difficulty of computing a block]] ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.

The difficulty can be set by a coefficient to the [[https://en.bitcoin.it/wiki/Target | hash target]] for the next block.  Whoever computes the next block unilaterally decides membership eligibility going forward.  The hash target for a cell would be updated periodically according to network convention in order to achieve a new block over a target period, also set by network convention.  The period should be longer than Bitcoin's 10 minutes -- perhaps one day is a good target block period, perhaps one hour. 
Changed lines 1-2 from:
This document describes a way for multiple independent endpoints (nodes/addresses/places that can send and receive payment) in the network to join together into cells which are then abstracted away from the rest of the network for routing purposes.  This provides both better privacy for those in the cell, and better routing scalability, since their individual connections no longer need to be broadcast to the network at large.
to:
This document describes a way for multiple independent endpoints (nodes/addresses/places that can send and receive payment) in the network to join together into cells whose internal connections are then abstracted away from the rest of the network for routing purposes.  This provides both better privacy for those in the cell, and better routing scalability, since their individual connections no longer need to be broadcast to the network at large.
Changed lines 25-27 from:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The difficulty of computing a block ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.

The difficulty can be set by a coefficient to the hash target for the next block.  Whoever computes the next block unilaterally decides membership eligibility going forward.  The hash target for a cell would be updated periodically according to network convention in order to achieve a new block over a target period, also set by network convention.  The period should be longer than Bitcoin's 10 minutes -- perhaps one day is a good target block period, perhaps one hour. 
to:
Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The [https://en.bitcoin.it/wiki/Difficulty | difficulty of computing a block] ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.

The difficulty can be set by a coefficient to the [https://en.bitcoin.it/wiki/Target | hash target] for the next block.  Whoever computes the next block unilaterally decides membership eligibility going forward.  The hash target for a cell would be updated periodically according to network convention in order to achieve a new block over a target period, also set by network convention.  The period should be longer than Bitcoin's 10 minutes -- perhaps one day is a good target block period, perhaps one hour. 
Added lines 1-41:
This document describes a way for multiple independent endpoints (nodes/addresses/places that can send and receive payment) in the network to join together into cells which are then abstracted away from the rest of the network for routing purposes.  This provides both better privacy for those in the cell, and better routing scalability, since their individual connections no longer need to be broadcast to the network at large.

An initial, partial sketch of this concept is at [[Protocol/Cell Structure Routing]].

Cells organize around a Bitcoin-style [[https://en.bitcoin.it/wiki/Block_chain | block chain]].  Each block defines membership in a cell, as well as which endpoint acts as the routing controller for the duration of that block. 

!! Routing Controller

Each block has a public key in it which validates routing advertisement messages from that cell to the outside world.  Only the peer who computed the lastest block can sign these messages.  This peer is the routing controller.  When they become eligible for a cell, members may invalidate their previous advertisements of connections to the outside world, preferring to let the cell's controller send out aggregate advertisements for the whole cell, on the assumption that the cell has sufficient internal routing capacity between any two external connections to handle most any potential through transaction.

When a new block is computed, the old controller must broadcast a message signing over routing authority to the new controller.  This message is broadcast to the outside world also, so it knows the new cell authority's key.  If it does not do so within a reasonable amount of time, endpoints within the cell can just start unilaterally sending out their own individual routing messages, effectively dissolving the cell.  The routing controller is responsible for sending out routing advertisements on behalf of all cell members for links between the cell's members and the outside world.  If it fails to do so to the satisfaction of any cell member, that member is free resume its own advertisements as a standalone endpoint. 

!! Cell Membership

The goal of a cell is to obscure and abstract away its internal exchange connections.

Cell members continue to passing routing advertisements for their individual endpoints locally to other cell members.  Any member is always free to continue broadcasting individual advertisements for itself and other members of the cell to the outside world for any reason.  The reasons it may choose not to include improved privacy, and lower message traffic leading to better scalability of routing across the entire network.  Of course, to achieve this, all members of the cell must stop broadcasting their individual messages to the outside world.  That means that all members must be satisfied with the structure and operation of the cell for their own benefit. 

If any member endpoint is not satisfied fully joining the cell and wishes to continue individual advertisements to the outside world, but does not wish to unilaterally dissolve the cell's privacy out of consideration for the other members, it may send the other members a cell membership refusal, in which case other members no longer consider it part of the cell.

A cell member must inform its external account partners of its cell membership so they can begin broadcasting their available credit messages as being with the cell, as opposed to with the individual endpoint.  Correspondingly, a cell member must inform its external account partners when it leaves the cell.  This probably makes it difficult or impossible for an endpoint to belong to multiple cells in any meaningful way.

!! Computing Blocks

Any member of a cell may compute the next block, unilaterally selecting eligible members of the cell and becoming routing controller for that block.  The difficulty of computing a block ought to be proportional to the number of endpoints in the block, but inversely proportional to some measure of their "connectedness".  For stability, the difficulty also probably ought to be proportional to the change in membership (not including voluntarily refusals) of the cell -- eg, each new or dropped member is counted as double in the difficulty coefficient.

The difficulty can be set by a coefficient to the hash target for the next block.  Whoever computes the next block unilaterally decides membership eligibility going forward.  The hash target for a cell would be updated periodically according to network convention in order to achieve a new block over a target period, also set by network convention.  The period should be longer than Bitcoin's 10 minutes -- perhaps one day is a good target block period, perhaps one hour. 

!! Cells Within Cells

When a cell grows large, there's no reason a subset of its members can't form a subcell within the cell.  A hierarchical structure of endpoints can emerge from peers cooperating in this way.  This is excellent for routing efficiency and scalability, but should only happen where the connectivity bears it out.  If a cell in fact cannot process the vast majority of requested through transactions, it ought to dissolve.  Happily, individual endpoints control their own destiny in this regard.

!! Addressing

To address a payment to an individual endpoint within the same cell, just name the endpoint.  To address a payment to an individual endpoint within a different cell, name the cell and the endpoint.  Similarly with nested cells: cell, subcell, sub-subcell, ..., endpoint.  A recipient would have to tell a payer his address or addresses at or before payment time, either automatically by communication between their servers, or in some other way.

!! Cells Meeting Cells

The entire known network could also consider itself a single cell, so that if and when it meets a previously-unknown endpoint, that endpoint will not be told anything of the structure the network, other than what it can glean from endpoint addresses it learns.  The other endpoint could be a cell too, of course. 

As more and more connections form between the two cells/endpoints, it may be useful to merge by one inviting the other in to its structure, and then the other possibly dissolving, or having only some of its members leave to join the new mother cell's structure in a more fine-grained way.  There are a lot of possibilities, but given well-defined conventions, hopefully this can happen smoothly, in a measured, orderly way, without being too hard to implement in software.