From cjp at ultimatestunts.nl Wed Jul 15 20:19:56 2015 From: cjp at ultimatestunts.nl (CJP) Date: Wed, 15 Jul 2015 22:19:56 +0200 Subject: [Lightning-dev] Routing on the lightning network? In-Reply-To: References: <874mlm0z5k.fsf@rustcorp.com.au> <1436295968.4352.49.camel@hppg6.kloosterkade> <87pp43v6rp.fsf@rustcorp.com.au> <1436900084.4523.87.camel@hppg6.kloosterkade> Message-ID: <1436991596.5886.13.camel@hppg6.kloosterkade> Nick ODell schreef op di 14-07-2015 om 18:29 [-0600]: > >I like to think of fees in the same way as we pay for Internet access. > >Every physical hop in the Internet has related costs, e.g. in placing > >the cables and upgrading the cables when new technology becomes > >available and when demand grows. > > What sort of fee would this be? A percentage fee? A per-transaction fee? Both? > > I can see a compelling case for any of the three. Rusty has argued for a fee that scales with Satoshi-seconds, so the to-be-transferred amount times the amount of time it takes to finish the transaction. The reason for that would be because then the fee scales with the actual scarce good you're consuming (the ability to lock a certain amount of funds for a certain amount of time on a channel is the thing that's scarce). Personally, I'd like to keep participants as free as possible in choosing the right fee structure; the technology platform shouldn't stand in the way. Virtually any fee structure is possible anyway, as long as some trust exists between two sides of a link, but in order to make fees trust-free, some fee structures require special features from the underlying technology. Per-transaction fees that can be determined in advance are easy to do, but e.g. the Satoshi-seconds structure is something that requires an extension of the micro-transaction channel design. CJP