Re: [bitcoin-dev] Off-chain transactions and miner fees

[Rune K. Svendsen via bitcoin-dev]

Nodes in the Lightning network earn fees that wouldn't be there if it weren't 
for the Lightning network. The base Bitcoin layer can't handle the transaction 
throughout that Lightning can, so the Lightning fees were never available to 
Bitcoin miners in the first place.

What Lightning does is raise the value of a transaction on the block chain. 
Imagine you're a Lightning node, and in order to collect your fees, that you've 
earned over the past month, you have to settle on the blockchain. If you've 
earned, say, 0.5 BTC in fees, you can attach a huge 0.005 BTC fee to the 
Bitcoin settlement transaction. The miners earn a larger fee, and you make sure 
your transaction gets into the blockchain quickly, and you can afford to pay 
this fee because you've made much more on the Lightning transactions you've 
routed.

/Rune



> Den 10/08/2015 kl. 00.20 skrev info--- via bitcoin-dev 
> :
> 
> Hello all,
> 
> one argument I often read on this mailing list is that it's essential to
> reward miners with transaction fees at some point to secure the network.
> 
> Off-chain transactions, whether it's Lightning or something else,
> potentially extract fees, which may otherwise be paid to miners, if the
> transactions were actually on-chain.
> 
> In this context, wouldn't it be contradictory, maybe even harmful, to
> aim for an environment, where some/many/most transactions are off-chain?
> 
> I have not yet seen this conflict addressed in the recent discussions.
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Off-chain transactions and miner fees

[Joseph Poon via bitcoin-dev]

Hi,

On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote:
> Off-chain transactions, whether it's Lightning or something else,
> potentially extract fees, which may otherwise be paid to miners, if the
> transactions were actually on-chain.
> 
> In this context, wouldn't it be contradictory, maybe even harmful, to
> aim for an environment, where some/many/most transactions are off-chain?

I think the fee market's long-term implications for mining rewards is
very important as well! However, opening and closing channels will not
be infrequent to the point that it will never happen with Lightning.
Individuals that fill up their channel will need to accommodate
accumulation (as well as those that do a lot of disbursement). These
fund flows are not too rare, and huge payments (think the equivalent to
wire transfers today) will probably be still on-chain. I think the
payment size of micropayments to credit cards are Lightning-scale, what
people use today for wire transfers (e.g. buying a house) will be
on-chain.

What Lightning does is it mitigates the advantages that doing an end-run
around bitcoin entirely via centralized systems provides to a sufficient
level, e.g. everyone transacting on Coinbase. Having everything on
centralized services will have significantly lower on-chain transactions
than Lightning and is one of the more viable alternative off-chain
payments.

Fundamentally, without off-chain transactions, there's a paradox within
a viable fee market. If you presume that fees should be relatively
competitive (i.e. not asymptotically close to zero), that implies that
higher-value transactions *will* be prioritized over low-value
transactions, as high-value transactions are willing to pay higher fees.
Wire transfers are cheap when it's a million-dollar wire.

In my view, different transaction values is the much larger risk for
on-chain transaction fee markets, with high-value transactions crowding
out low-value transactions on-chain. With lightning, it significantly
mitigates this problem by aggregating the low-value transactions
off-chain.

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Joseph Poon via bitcoin-dev]

Hi Hector,

On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote:
> Is the Lightning system limited in the number of hops there can be in
> the payment channel? I am looking at the initial Lightning slides
> presented in February and it looks like the locktime decrements by
> 1-day along each hop. So the more hops there are the longer my
> bitcoins are potentially locked up for?

The hops are limited to the time-value which the sender wishes to pay
and the minimum acceptable timeout between each hop. It should be
relatively cheap if you game it out, though (I don't forsee me opening a
1 BTC channel and being able to make $5 per month...)

1-day is used as a convenience. However, the time between hops should be
somewhat long, as the intermediate steps can be extended further when
you want to offload the HTLCs to others who have a channel open with
both counterparties. E.g. Alice sends a payment to Dave through Bob and
Carol. Bob has a channel with Carol and has an HTLC with it, but that
channel seems to be used a lot. Erin has a relationship to both Bob and
Carol, she can offload the payment so that the payment actually goes to
A->B->E->C->D. B<->C is now completely clear.

> > On Aug 9, 2015 1:15 PM, "Hector Chu"  wrote:
> >> In the Lightning network it is assumed that the balances can always
> >> be settled on the blockchain if any of the parties along the
> >> channel has a problem. What if the fee on the settlement
> >> transactions is not high enough to enter the blockchain? You can't
> >> do replace-by-fee after the fact. Do the fees always have to assume
> >> worst case scenarios on the Bitcoin fee market?

How do you send coins if you wanted to send funds below the current
IsStandard value? It should be no different. If your wallet can't send
funds below the IsStandard value on-chain today, then I don't think it
should be able to to in the future, right? If you send funds *at* the
minimum IsStandard value today, you're probably paying really high fees,
this is a problem that exists today.

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Joseph Poon via bitcoin-dev]

Hi Gavin,

On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make it all work.

I'm writing a (hopefully more accessible) summary on Lightning
currently. It might not go into too much detail with infrastructure, but
is a bit more UX focused.

> A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> cup of tea. Walk me through what happens before/during/after the
> transaction, assuming I have a  lightning-enabled wallet on my iPhone and
> the tea shop has a lightning-enabled cash register.
> 
> Assume neither the customer nor the tea shop are technically sophisticated
> -- assume the customer is using an SPV wallet and the tea shop is using a
> service similar to Bitpay.

It's a bit of a tangent, but I see it as necessary that all Lightning
services/wallets support on-chain payments for a multitude of reasons,
including usability and long-term security/fungibility. For that reason,
the UX flow for payment after channels are established should not be
significantly different than Payment Protocol based payment flows (with
the only exception being a possible additional fee dialog box/alert when
the fees will be higher than expected/on-chain).

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman via bitcoin-dev]

> I would be surprised if the rates charged to consumers for BTC credit
aren't much closer to today's BTC borrowing rates.

The borrowing rates you're talking about involve the risk of default.

In lightning the hubs funds are not at risk so long as they maintain
control of the private keys.

The rates charged by hubs will almost certainly be orders of magnitude
below the rates charged on the various p2p lending sites

But that seems fairly obvious... did I miss something?

On 08/09/2015 06:52 PM, Tom Harding via bitcoin-dev wrote:
> On 8/9/2015 2:45 PM, Hector Chu wrote:
>> Tom, my understanding is that the money that is debited from a payment
>> hub is simultaneously credited from either another payment hub or the
>> person making the payment, so that the net funds flow at a payment hub
>> always sums to zero.
> 
> That describes the steady-state dynamics.  I refer to the hub funding
> required to initiate and maintain the ability to receive payments.
> 
> If Bob opens a channel at his hub, doesn't use it for spending, and
> Alice sends 1 BTC to the channel, her payment can only be applied if the
> hub has funded the channel with at least 1 BTC.
> 
> Yes, the hub receives an offsetting payment (from Alice, ultimately) in
> another channel.  But to make this work, it must subject 1 BTC to shared
> control with Bob and forfeit the use of that money for other purposes
> (opportunity cost) while the channel is open.  The opportunity cost is
> likened to gold lease rates in the LN paper.  I would be surprised if
> the rates charged to consumers for BTC credit aren't much closer to
> today's BTC borrowing rates.  We'll see.
> 
> Burying this cost in general fees might not work very well, because
> different Bobs may want different maximum payment amounts, and channels
> open for different lengths of time.
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

On 8/9/2015 2:45 PM, Hector Chu wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero.

That describes the steady-state dynamics.  I refer to the hub funding
required to initiate and maintain the ability to receive payments.

If Bob opens a channel at his hub, doesn't use it for spending, and
Alice sends 1 BTC to the channel, her payment can only be applied if the
hub has funded the channel with at least 1 BTC.

Yes, the hub receives an offsetting payment (from Alice, ultimately) in
another channel.  But to make this work, it must subject 1 BTC to shared
control with Bob and forfeit the use of that money for other purposes
(opportunity cost) while the channel is open.  The opportunity cost is
likened to gold lease rates in the LN paper.  I would be surprised if
the rates charged to consumers for BTC credit aren't much closer to
today's BTC borrowing rates.  We'll see.

Burying this cost in general fees might not work very well, because
different Bobs may want different maximum payment amounts, and channels
open for different lengths of time.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Btc Drak via bitcoin-dev]

I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Gavin Andresen via bitcoin-dev]

While we're on the subject of payment hubs / lightning network...

I'd love to see somebody write up a higher-level description of what the
user experience is like, what communication happens underneath, and what
new pieces of infrastructure need to get built to make it all work.

A use-case to start with:

A customer starts with eleven on-chain bitcoin. They want to pay for a nice
cup of tea. Walk me through what happens before/during/after the
transaction, assuming I have a  lightning-enabled wallet on my iPhone and
the tea shop has a lightning-enabled cash register.

Assume neither the customer nor the tea shop are technically sophisticated
-- assume the customer is using an SPV wallet and the tea shop is using a
service similar to Bitpay.

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman via bitcoin-dev]

On the contrary those costs are clearly very low.

Both the time value of money and operating expenses will be trivial with
even a small volume of transactions.

The true cost of operating a hub is clearly in the enhanced risk of loss.

It's clear that risk of loss will be moderated by market forces.

The hubs which are better at securing their systems will reduce their
risk of loss and obtain a competitive advantage.

It's also important to note that the risk of loss is the same whether
the hub is doing 1 transaction/second or 1 million transactions/second.

At 1 transaction/second the cost (but not necessarily the fees) is going
to be quite high.

At 1 million transactions/second the cost is going to be very very low.

On 08/09/2015 03:03 PM, Hector Chu wrote:
> Ok good. We have established it to be a non-trivial cost.
> Now, what is the growth complexity of the total cost of the network in
> terms of number of connections each hub has to other hubs? And then,
> consider a payment channel with many hops in it. The end-to-end users
> would have to swallow all the costs of the hubs in the channel.
>
> On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev
>  > wrote:
>
> The costs of operating a hub are as follows:
>
> Time value of the funds the Hub has locked up in payment channels.
> Enhanced risk of loss of control of private keys (the keys
> necessarily need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>> Tom, my understanding is that the money that is debited from a
>> payment hub is simultaneously credited from either another
>> payment hub or the person making the payment, so that the net
>> funds flow at a payment hub always sums to zero. So no, there is
>> no credit advanced by the payment hub to anyone.
>>
>> Given Mark's previous answer of using CPFP and other tricks to
>> pay for the Bitcoin transaction fees, we can assume that Bitcoin
>> fees do not play a part in the payment channel balances.
>>
>> So, the interesting question is what are the costs of running a
>> payment hub? The tx fees that a payment hub would have to pay to
>> settle its Bitcoin transactions would be passed on as a cost to
>> the clients of the payment hub. Also there is a cost to locking
>> up funds in a payment channel (time value of money). The lost
>> interest or opportunity cost on those funds would need to be paid
>> for by its clients as well. And don't forget normal running costs
>> such as networking and electricity.
>>
>> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
>> > > wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"
>> mailto:m...@friedenbach.org>> wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation 
>> of the channel.
>> There is no credit involved.
>>
>> That's a chuckle. 
>>
>> As I said, nothing requires the hub to advance anything, and
>> if it does, Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds,
>> whether the fee depends on the amount deposited, and whether
>> it depends on the amount of time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds
>> of fees.  Can you guess it?
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Off-chain transactions and miner fees

[info--- via bitcoin-dev]

Hello all,

one argument I often read on this mailing list is that it's essential to
reward miners with transaction fees at some point to secure the network.

Off-chain transactions, whether it's Lightning or something else,
potentially extract fees, which may otherwise be paid to miners, if the
transactions were actually on-chain.

In this context, wouldn't it be contradictory, maybe even harmful, to
aim for an environment, where some/many/most transactions are off-chain?

I have not yet seen this conflict addressed in the recent discussions.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

Sorry about that Patrick. Gmail hides previous messages including sender
names. Regardless, no worries.

On 9 August 2015 at 23:27, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> That was not in reply to you.
>
>
> On 08/09/2015 03:09 PM, Hector Chu wrote:
>
> Right, you've stated a bunch of facts, but how does it answer my concerns
> of the exploding cost of the network the more interconnected it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I suspect there is some amount of confusion here on terms.
>>
>> The hub is essentially swapping funds between payment channels.
>>
>> The hub's entire business is centered around having payment channels open
>> with other hubs/users.
>>
>> If the hub requires user funds to open these channels... then the users
>> have no reason to pay the hub anything in fees.
>>
>> A hub that doesn't use it's own funds to open payment channels to other
>> hubs/merchants is useless.
>>
>>
>> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>>
>> ___
>> bitcoin-dev mailing 
>> listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman via bitcoin-dev]

That was not in reply to you.

On 08/09/2015 03:09 PM, Hector Chu wrote:
> Right, you've stated a bunch of facts, but how does it answer my
> concerns of the exploding cost of the network the more interconnected
> it it?
>
> On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev
>  > wrote:
>
> I suspect there is some amount of confusion here on terms.
>
> The hub is essentially swapping funds between payment channels.
>
> The hub's entire business is centered around having payment
> channels open with other hubs/users.
>
> If the hub requires user funds to open these channels... then the
> users have no reason to pay the hub anything in fees.
>
> A hub that doesn't use it's own funds to open payment channels to
> other hubs/merchants is useless.
>
>
> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach" > > wrote:
>>
>> > On the contrary the funds were advanced by the hub on the
>> creation of the channel. There is no credit involved.
>>
>> That's a chuckle. 
>>
>> As I said, nothing requires the hub to advance anything, and if
>> it does, Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether
>> the fee depends on the amount deposited, and whether it depends
>> on the amount of time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of
>> fees.  Can you guess it?
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

Right, you've stated a bunch of facts, but how does it answer my concerns
of the exploding cost of the network the more interconnected it it?

On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I suspect there is some amount of confusion here on terms.
>
> The hub is essentially swapping funds between payment channels.
>
> The hub's entire business is centered around having payment channels open
> with other hubs/users.
>
> If the hub requires user funds to open these channels... then the users
> have no reason to pay the hub anything in fees.
>
> A hub that doesn't use it's own funds to open payment channels to other
> hubs/merchants is useless.
>
>
> On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
>
> ___
> bitcoin-dev mailing 
> listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman via bitcoin-dev]

I suspect there is some amount of confusion here on terms.

The hub is essentially swapping funds between payment channels.

The hub's entire business is centered around having payment channels
open with other hubs/users.

If the hub requires user funds to open these channels... then the users
have no reason to pay the hub anything in fees.

A hub that doesn't use it's own funds to open payment channels to other
hubs/merchants is useless.

On 08/09/2015 02:27 PM, Tom Harding via bitcoin-dev wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  > wrote:
>
> > On the contrary the funds were advanced by the hub on the creation
> of the channel. There is no credit involved.
>
> That's a chuckle. 
>
> As I said, nothing requires the hub to advance anything, and if it
> does, Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the
> fee depends on the amount deposited, and whether it depends on the
> amount of time it stays there.
>
> I predict "all of the above." There is a name for these kinds of
> fees.  Can you guess it?
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

Ok good. We have established it to be a non-trivial cost.
Now, what is the growth complexity of the total cost of the network in
terms of number of connections each hub has to other hubs? And then,
consider a payment channel with many hops in it. The end-to-end users would
have to swallow all the costs of the hubs in the channel.

On 9 August 2015 at 22:57, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The costs of operating a hub are as follows:
>
> Time value of the funds the Hub has locked up in payment channels.
> Enhanced risk of loss of control of private keys (the keys necessarily
> need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
>
> Tom, my understanding is that the money that is debited from a payment hub
> is simultaneously credited from either another payment hub or the person
> making the payment, so that the net funds flow at a payment hub always sums
> to zero. So no, there is no credit advanced by the payment hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for the
> Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
> part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a payment
> hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
> transactions would be passed on as a cost to the clients of the payment
> hub. Also there is a cost to locking up funds in a payment channel (time
> value of money). The lost interest or opportunity cost on those funds would
> need to be paid for by its clients as well. And don't forget normal running
> costs such as networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:
>>
>> > On the contrary the funds were advanced by the hub on the creation of
>> the channel. There is no credit involved.
>>
>> That's a chuckle.
>>
>> As I said, nothing requires the hub to advance anything, and if it does,
>> Bob can expect to pay for it.
>>
>> We'll see whether hubs assess a fee for depositing funds, whether the fee
>> depends on the amount deposited, and whether it depends on the amount of
>> time it stays there.
>>
>> I predict "all of the above." There is a name for these kinds of fees.
>> Can you guess it?
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> ___
> bitcoin-dev mailing 
> listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Patrick Strateman via bitcoin-dev]

The costs of operating a hub are as follows:

Time value of the funds the Hub has locked up in payment channels.
Enhanced risk of loss of control of private keys (the keys necessarily
need to be on an internet connected system).
Operating costs (I expect this will be minimal).

The hub can charge a fee for it's services to recoup these costs.

On 08/09/2015 02:45 PM, Hector Chu via bitcoin-dev wrote:
> Tom, my understanding is that the money that is debited from a payment
> hub is simultaneously credited from either another payment hub or the
> person making the payment, so that the net funds flow at a payment hub
> always sums to zero. So no, there is no credit advanced by the payment
> hub to anyone.
>
> Given Mark's previous answer of using CPFP and other tricks to pay for
> the Bitcoin transaction fees, we can assume that Bitcoin fees do not
> play a part in the payment channel balances.
>
> So, the interesting question is what are the costs of running a
> payment hub? The tx fees that a payment hub would have to pay to
> settle its Bitcoin transactions would be passed on as a cost to the
> clients of the payment hub. Also there is a cost to locking up funds
> in a payment channel (time value of money). The lost interest or
> opportunity cost on those funds would need to be paid for by its
> clients as well. And don't forget normal running costs such as
> networking and electricity.
>
> On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev
>  > wrote:
>
> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  > wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of 
> the channel. There is no credit
> involved.
>
> That's a chuckle. 
>
> As I said, nothing requires the hub to advance anything, and if it
> does, Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether
> the fee depends on the amount deposited, and whether it depends on
> the amount of time it stays there.
>
> I predict "all of the above." There is a name for these kinds of
> fees.  Can you guess it?
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

Tom, my understanding is that the money that is debited from a payment hub
is simultaneously credited from either another payment hub or the person
making the payment, so that the net funds flow at a payment hub always sums
to zero. So no, there is no credit advanced by the payment hub to anyone.

Given Mark's previous answer of using CPFP and other tricks to pay for the
Bitcoin transaction fees, we can assume that Bitcoin fees do not play a
part in the payment channel balances.

So, the interesting question is what are the costs of running a payment
hub? The tx fees that a payment hub would have to pay to settle its Bitcoin
transactions would be passed on as a cost to the clients of the payment
hub. Also there is a cost to locking up funds in a payment channel (time
value of money). The lost interest or opportunity cost on those funds would
need to be paid for by its clients as well. And don't forget normal running
costs such as networking and electricity.

On 9 August 2015 at 22:27, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Chris Pacia via bitcoin-dev]

I'm glad Tom is bringing these points up. There seems to be an assumption
by many that LN will be automatically awesome by virtue of it being
technically feasible with having considered whether it is economically
feasible or desirable.

So much stock has been placed in LN as the solution to the block size
debate, yet it could turn out that it sucks in practice. Then what?
On Aug 9, 2015 5:27 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:
>
> > On the contrary the funds were advanced by the hub on the creation of
> the channel. There is no credit involved.
>
> That's a chuckle.
>
> As I said, nothing requires the hub to advance anything, and if it does,
> Bob can expect to pay for it.
>
> We'll see whether hubs assess a fee for depositing funds, whether the fee
> depends on the amount deposited, and whether it depends on the amount of
> time it stays there.
>
> I predict "all of the above." There is a name for these kinds of fees.
> Can you guess it?
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

On Aug 9, 2015 11:54 AM, "Mark Friedenbach"  wrote:

> On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved.

That's a chuckle.

As I said, nothing requires the hub to advance anything, and if it does,
Bob can expect to pay for it.

We'll see whether hubs assess a fee for depositing funds, whether the fee
depends on the amount deposited, and whether it depends on the amount of
time it stays there.

I predict "all of the above." There is a name for these kinds of fees.  Can
you guess it?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

Thanks Mark.
Ok next obvious question (apologies for all of these but it seems you are
the authority on Lightning here). Is the Lightning system limited in the
number of hops there can be in the payment channel? I am looking at the
initial Lightning slides presented in February and it looks like the
locktime decrements by 1-day along each hop. So the more hops there are the
longer my bitcoins are potentially locked up for?

On 9 August 2015 at 21:18, Mark Friedenbach  wrote:

> Child pays for parent, and potentially future sighash modes implemented in
> the checksig2 operator lightning needs anyway which enable adding inputs to
> provide additional fee.
> On Aug 9, 2015 1:15 PM, "Hector Chu"  wrote:
>
>> In the Lightning network it is assumed that the balances can always be
>> settled on the blockchain if any of the parties along the channel has a
>> problem. What if the fee on the settlement transactions is not high enough
>> to enter the blockchain? You can't do replace-by-fee after the fact. Do the
>> fees always have to assume worst case scenarios on the Bitcoin fee market?
>>
>> On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Tom, you appear to be misunderstanding how lightning network and
>>> micropayment hub-and-spoke models in general work.
>>>
>>> > But neither can Bob receive money, unless payment hub has
>>> advanced it to the channel (or (2) below applies).  Nothing requires the
>>> payment hub to do this.
>>>
>>> On the contrary the funds were advanced by the hub on the creation of
>>> the channel. There is no credit involved. if the funds aren't already
>>> available for Bob to immediately claim his balance, the payment doesn't go
>>> through in the first place.
>>>
>>> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:

 > Don't turn Bitcoin into something uninteresting, please.

 Consider how Bob will receive money using the Lightning Network.

 Bob receives a payment by applying a contract to his local payment
 channel, increasing the amount payable to him when the channel is
 closed.

 There are two possible sources of funding for Bob's increased claim.
 They can appear alone, or in combination:


 Funding Source (1)
 A deposit from Bob's payment hub

 Bob can receive funds, if his payment hub has made a deposit to the
 channel.  Another name for this is "credit".

 This credit has no default risk: Bob cannot just take payment hub's
 deposit. But neither can Bob receive money, unless payment hub has
 advanced it to the channel (or (2) below applies).  Nothing requires the
 payment hub to do this.

 This is a 3rd-party dependency totally absent with plain old bitcoin.
 It will come with a fee and, in an important way, it is worse than the
 current banking system.  If a bank will not even open an account for Bob
 today, why would a payment hub lock up hard bitcoin to allow Bob to be
 paid through a Poon-Dryja channel?


 Funding Source (2)
 Bob's previous spends

 If Bob has previously spent from the channel, decreasing his claim on
 its funds (which he could have deposited himself), that claim can be
 re-increased.

 To avoid needing credit (1), Bob has an incentive to consolidate
 spending and income in the same payment channel, just as with today's
 banks.  This is at odds with the idea that Bob will have accounts with
 many payment hubs.  It is an incentive for centralization.


 With Lightning Network, Bob will need a powerful middleman to send and
 receive money effectively.  *That* is uninteresting to me.


 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

>>>
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[Dave Scotese via bitcoin-dev]

On Sun, Aug 9, 2015 at 3:42 AM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> > Someone mentioned that when the backlog grows faster than it shrinks,
> that
> > is a real problem.  I don't think it is.  It is a problem for those who
> > don't wait for even one confirmation
>
> The mention you refer to was about the fact that the software doesn't cope
> well with a continuously growing mempool.
> If Bitcoind starts eating more and more memory, I expect lots of people
> that
> run it now to turn it off.
>

That is a real problem then.  While emptying the mempool faster with bigger
blocks will help to reduce the occurrence of that problem, I propose a
user-configurable default limit to the size of the mempool as a permanent
solution regardless of block size.  "This software has stopped consuming
memory necessary to validate transactions.  You can override this by ..."
If anyone feels that protecting those running full nodes from bitcoind
eating more and more memory this way is a good idea, I can make a BIP out
of it if that would help.


> > but backlogs in the past have already
> > started training users to wait for at least one confirmation, or go
> > off-chain.
>
> I am wondering how you concluded that? The only time we saw full blocks
> for a
> considerable amount of time was when we had a spammer, and the only thing
> we taught people was to use higher fees.
>

I concluded that because I don't think I'm all that different than others,
and that is what I have done.  The "training" of which I speak is not
always recognized by the bitcoiner on whom it operates.  A similar
"training" is how we all learn to ignore teachers because governments force
our attendance at school.


> > Everyone else can double-spend (perhaps that's not as easy as
> > it should be in bitcoin core) and use a higher fee, thus competing for
> > block space.
>
> This is false, if you want to double spent you have to do a lot of work and
> have non-standard software.  For instance sending your newer transaction
> to a
> random node will almost always get it rejected because its a double spent.
> Replace by fee (even safe) is not supported in the vast majority of Bitcoin
> land.
>

I don't know what you meant to say is false.  I agree with the other stuff
you wrote.  Thanks for confirming that it is difficult.

I did some research on replace by fee (FSS-RBF) and on
Child-pays-for-parent (CPFP).  You point out that these solutions to paying
too-low fees are "not supported in the vast majority...".  Do you mean
philosophically or programmatically?  The trend seems to me toward
improvements, just as I insinuated may be necessary ("perhaps that's not as
easy as it should be in bitcoin core"), so, once again, I have to reiterate
that transaction backlog has valuable solutions other than increasing the
block size.

I also realized that we have already been through a period of full blocks,
so that tremendously reduces the value I see in doing it again.  It was
that "spam" test someone ran that did it for us, and I love that.  It seems
to have kicked the fee-increasability efforts in the butt, which is great.

I now place a higher priority on enabling senders to increase their fee
when necessary than on increasing the Txns per second that the network can
handle.  The competition between these two is rather unfair because of how
easy it is to apply the "N MB-blocks bandaid".

Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Hector Chu via bitcoin-dev]

In the Lightning network it is assumed that the balances can always be
settled on the blockchain if any of the parties along the channel has a
problem. What if the fee on the settlement transactions is not high enough
to enter the blockchain? You can't do replace-by-fee after the fact. Do the
fees always have to assume worst case scenarios on the Bitcoin fee market?

On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Tom, you appear to be misunderstanding how lightning network and
> micropayment hub-and-spoke models in general work.
>
> > But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing requires the
> payment hub to do this.
>
> On the contrary the funds were advanced by the hub on the creation of the
> channel. There is no credit involved. if the funds aren't already available
> for Bob to immediately claim his balance, the payment doesn't go through in
> the first place.
>
> On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>>
>> > Don't turn Bitcoin into something uninteresting, please.
>>
>> Consider how Bob will receive money using the Lightning Network.
>>
>> Bob receives a payment by applying a contract to his local payment
>> channel, increasing the amount payable to him when the channel is closed.
>>
>> There are two possible sources of funding for Bob's increased claim.
>> They can appear alone, or in combination:
>>
>>
>> Funding Source (1)
>> A deposit from Bob's payment hub
>>
>> Bob can receive funds, if his payment hub has made a deposit to the
>> channel.  Another name for this is "credit".
>>
>> This credit has no default risk: Bob cannot just take payment hub's
>> deposit. But neither can Bob receive money, unless payment hub has
>> advanced it to the channel (or (2) below applies).  Nothing requires the
>> payment hub to do this.
>>
>> This is a 3rd-party dependency totally absent with plain old bitcoin.
>> It will come with a fee and, in an important way, it is worse than the
>> current banking system.  If a bank will not even open an account for Bob
>> today, why would a payment hub lock up hard bitcoin to allow Bob to be
>> paid through a Poon-Dryja channel?
>>
>>
>> Funding Source (2)
>> Bob's previous spends
>>
>> If Bob has previously spent from the channel, decreasing his claim on
>> its funds (which he could have deposited himself), that claim can be
>> re-increased.
>>
>> To avoid needing credit (1), Bob has an incentive to consolidate
>> spending and income in the same payment channel, just as with today's
>> banks.  This is at odds with the idea that Bob will have accounts with
>> many payment hubs.  It is an incentive for centralization.
>>
>>
>> With Lightning Network, Bob will need a powerful middleman to send and
>> receive money effectively.  *That* is uninteresting to me.
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative chain support for payment protocol

[John L. Jegutanis via bitcoin-dev]

Another possibility to support side|alt-chains is the bip44 coin type
registry.

A problem that hasn't been mentioned is that a coin can extend the protocol
in an incompatible way (different protocol buffer format) so just changing
the network field in the PaymentDetails message will not work. A better
approach is to add an optional coin type field to the PaymentRequest and
serialize the incompatible PaymentDetails to the serialized_payment_details
field.

To support a future testnet4 in PaymentDetails we only need to add a new
network string like "test4".
On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

I'm cautious of using human-meaningful identifiers, especially any that
might require a central repository, due to name collisions. Examples that
could be complicated include BitcoinDark, Litedoge, and other names that
base on existing coins. I think the ability to differentiate between test
networks is also useful.

Could certainly just use the genesis hash as network ID, that would work.
Bit long, but suspect 64 bytes isn't the end of the world! I'll see if any
more responses come in then raise a BIP for using genesis hash as an
alternative to short names.

Ross


On 09/08/2015 15:29, Mike Hearn wrote:

I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>

The reason BIP 70 doesn't do this is the assumption that alt coins are ...
well  alt. They can vary in arbitrary ways from Bitcoin, and so things
in BIP70 that work for Bitcoin may or may not work for other coins.

If your alt coin is close enough to BIP 70 that you can reuse it "as is"
then IMO we should just define a new network string for your alt. network =
"dogecoin-main" or whatever.

You could also use the genesis hash as the network name. That works too.
But it's less clear and would involve lookups to figure out what the
request is for, if you find such a request in the wild. I don't care much
either way.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What Lightning Is

[Mark Friedenbach via bitcoin-dev]

Tom, you appear to be misunderstanding how lightning network and
micropayment hub-and-spoke models in general work.

> But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies).  Nothing requires the
payment hub to do this.

On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved. if the funds aren't already available
for Bob to immediately claim his balance, the payment doesn't go through in
the first place.

On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>
> > Don't turn Bitcoin into something uninteresting, please.
>
> Consider how Bob will receive money using the Lightning Network.
>
> Bob receives a payment by applying a contract to his local payment
> channel, increasing the amount payable to him when the channel is closed.
>
> There are two possible sources of funding for Bob's increased claim.
> They can appear alone, or in combination:
>
>
> Funding Source (1)
> A deposit from Bob's payment hub
>
> Bob can receive funds, if his payment hub has made a deposit to the
> channel.  Another name for this is "credit".
>
> This credit has no default risk: Bob cannot just take payment hub's
> deposit. But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies).  Nothing requires the
> payment hub to do this.
>
> This is a 3rd-party dependency totally absent with plain old bitcoin.
> It will come with a fee and, in an important way, it is worse than the
> current banking system.  If a bank will not even open an account for Bob
> today, why would a payment hub lock up hard bitcoin to allow Bob to be
> paid through a Poon-Dryja channel?
>
>
> Funding Source (2)
> Bob's previous spends
>
> If Bob has previously spent from the channel, decreasing his claim on
> its funds (which he could have deposited himself), that claim can be
> re-increased.
>
> To avoid needing credit (1), Bob has an incentive to consolidate
> spending and income in the same payment channel, just as with today's
> banks.  This is at odds with the idea that Bob will have accounts with
> many payment hubs.  It is an incentive for centralization.
>
>
> With Lightning Network, Bob will need a powerful middleman to send and
> receive money effectively.  *That* is uninteresting to me.
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] What Lightning Is

[Tom Harding via bitcoin-dev]

On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:

> Don't turn Bitcoin into something uninteresting, please.

Consider how Bob will receive money using the Lightning Network.

Bob receives a payment by applying a contract to his local payment
channel, increasing the amount payable to him when the channel is closed.

There are two possible sources of funding for Bob's increased claim. 
They can appear alone, or in combination:


Funding Source (1)
A deposit from Bob's payment hub

Bob can receive funds, if his payment hub has made a deposit to the
channel.  Another name for this is "credit".

This credit has no default risk: Bob cannot just take payment hub's
deposit. But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies).  Nothing requires the
payment hub to do this.

This is a 3rd-party dependency totally absent with plain old bitcoin.   
It will come with a fee and, in an important way, it is worse than the
current banking system.  If a bank will not even open an account for Bob
today, why would a payment hub lock up hard bitcoin to allow Bob to be
paid through a Poon-Dryja channel?


Funding Source (2)
Bob's previous spends

If Bob has previously spent from the channel, decreasing his claim on
its funds (which he could have deposited himself), that claim can be
re-increased.

To avoid needing credit (1), Bob has an incentive to consolidate
spending and income in the same payment channel, just as with today's
banks.  This is at odds with the idea that Bob will have accounts with
many payment hubs.  It is an incentive for centralization.


With Lightning Network, Bob will need a powerful middleman to send and
receive money effectively.  *That* is uninteresting to me.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Ross Nicoll via bitcoin-dev]

I'm cautious of using human-meaningful identifiers, especially any that 
might require a central repository, due to name collisions. Examples 
that could be complicated include BitcoinDark, Litedoge, and other names 
that base on existing coins. I think the ability to differentiate 
between test networks is also useful.


Could certainly just use the genesis hash as network ID, that would 
work. Bit long, but suspect 64 bytes isn't the end of the world! I'll 
see if any more responses come in then raise a BIP for using genesis 
hash as an alternative to short names.


Ross

On 09/08/2015 15:29, Mike Hearn wrote:


I'd appreciate initial feedback on the idea, and if there's no
major objections I'll raise this as a BIP.


The reason BIP 70 doesn't do this is the assumption that alt coins are 
... well  alt. They can vary in arbitrary ways from Bitcoin, and 
so things in BIP70 that work for Bitcoin may or may not work for other 
coins.


If your alt coin is close enough to BIP 70 that you can reuse it "as 
is" then IMO we should just define a new network string for your alt. 
network = "dogecoin-main" or whatever.


You could also use the genesis hash as the network name. That works 
too. But it's less clear and would involve lookups to figure out what 
the request is for, if you find such a request in the wild. I don't 
care much either way.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Mark Friedenbach via bitcoin-dev]

A sha256 hash is 32 bytes, but otherwise I agree with this proposal.
Genesis block hash is the logical way to identify chains, moving forward.
On Aug 9, 2015 7:12 AM, "Ross Nicoll via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> BIP 70 currently lists two networks, main and test (inferred as testnet3)
> for payment protocol requests. This means that different testnets cannot be
> supported trivially, and the protocol cannot be used for alternative coins
> (or, lacks context to indicate which coin the request applies to, which is
> particularly dangerous in cases where coins share address prefixes).
>
> I propose adding a new optional "genesis" field as a 16 byte sequence
> containing the SHA-256 hash of the genesis block of the network the request
> belongs to, uniquely identifying chains without any requirement for a
> central registry. For backwards compatibility, the "network" field would
> contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, and
> "other" for other networks apart from those two.
>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>
> Ross
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Alternative chain support for payment protocol

[Mike Hearn via bitcoin-dev]

>
> I'd appreciate initial feedback on the idea, and if there's no major
> objections I'll raise this as a BIP.
>

The reason BIP 70 doesn't do this is the assumption that alt coins are ...
well  alt. They can vary in arbitrary ways from Bitcoin, and so things
in BIP70 that work for Bitcoin may or may not work for other coins.

If your alt coin is close enough to BIP 70 that you can reuse it "as is"
then IMO we should just define a new network string for your alt. network =
"dogecoin-main" or whatever.

You could also use the genesis hash as the network name. That works too.
But it's less clear and would involve lookups to figure out what the
request is for, if you find such a request in the wild. I don't care much
either way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Alternative chain support for payment protocol

[Ross Nicoll via bitcoin-dev]

BIP 70 currently lists two networks, main and test (inferred as 
testnet3) for payment protocol requests. This means that different 
testnets cannot be supported trivially, and the protocol cannot be used 
for alternative coins (or, lacks context to indicate which coin the 
request applies to, which is particularly dangerous in cases where coins 
share address prefixes).


I propose adding a new optional "genesis" field as a 16 byte sequence 
containing the SHA-256 hash of the genesis block of the network the 
request belongs to, uniquely identifying chains without any requirement 
for a central registry. For backwards compatibility, the "network" field 
would contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, 
and "other" for other networks apart from those two.


I'd appreciate initial feedback on the idea, and if there's no major 
objections I'll raise this as a BIP.


Ross

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[Thomas Zander via bitcoin-dev]

On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem.  I don't think it is.  It is a problem for those who
> don't wait for even one confirmation

The mention you refer to was about the fact that the software doesn't cope 
well with a continuously growing mempool.
If Bitcoind starts eating more and more memory, I expect lots of people that 
run it now to turn it off.

> but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain.

I am wondering how you concluded that? The only time we saw full blocks for a 
considerable amount of time was when we had a spammer, and the only thing
we taught people was to use higher fees.
Actually, we didn't teach people anything, we told wallet developers to do it. 
Most actual users were completely ignorant of the problem.

Full blocks will then stop being a supported usecase when real humans are 
trying to buy a beer or a coffee. Waiting for a confirmation won't work either 
for the vast majority of the current usages of Bitcoin in the real world.

> I am comfortable leaving those zero-conf people in a little bit
> of trouble.  Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space.

This is false, if you want to double spent you have to do a lot of work and 
have non-standard software.  For instance sending your newer transaction to a 
random node will almost always get it rejected because its a double spent. 
Replace by fee (even safe) is not supported in the vast majority of Bitcoin 
land.

-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[Thomas Zander via bitcoin-dev]

On Saturday 8. August 2015 19.05.29 Alex Morcos via bitcoin-dev wrote:
> I agree
> There are a lot of difficult technical problems introduced by insufficient
> block space that are best addressed now.

I agree problems for space restrictions should be solved, and the sooner the 
better.
What your statement has as a side-effect is that we will run into problems when 
the moment of insufficient block space comes *this* year instead of in 5 years.

I can practically guarantee that no proper solutions will be deployed in time 
for natural growth of usage to reach always 1Mb full blocks.
Having several more years to make such solutions will be very healthy.

> As well as problems that scale
> will exacerbate like bootstrapping that we should develop solutions for
> first.  

Notice that many people here have tried but have been unable to find a relation 
between max-blocksize and full node-count.

Also, there are pretty good solutions already, like a bootstrap torrent and 
the headers first. In the upcoming release the actual CPU load should also get 
better making the actual download much much faster than the 0.9 release.

Or, in other words, these problems have been solved in a large part already, 
and more is underway.
I don't expect them to be showstoppers when a the network finally allows bigger 
than 1Mb blocks. Natural growth has shown that blocks won't jump in size 
significantly in one month anyway. So this scenario still has 6 months or so.

-- 
Thomas Zander
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev