public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sun, 28 Jun 2015 19:18:03 +0200	[thread overview]
Message-ID: <CAOoPuRaR_A3ani3d_KVjc4oTfmLYbP52rLsqBEQMZ4gajqoV8A@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4753 bytes --]

"You open a channel with a hub and through that channel send coins to
anyone accessible to the network."

Define hub *precisely* and you will find there are
some significant problems here.
a) does everyone know each other in the network? In Bitcoin transacting
parties exchange keys out of band. How do I know that Alice is owner of a
pubkey? I don't, and if don't know Alice I'm out of luck and can't transact
with here (or trust another PKI).
b) hubs need incentives. There are not going to put up collateral just for
nothing.
c) how is complexity reduced? I would speculate that most transactions are
one-time transactions in the time frame of days.

LT is a very interesting idea, but far from actual implementation.

On Sun, Jun 28, 2015 at 7:12 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Think in terms of participants, not addresses. A participant in the
> lightning network has a couple of connections to various hubs, from which
> the participant is able to send or receive coin. The user is able to send
> coins to anyone connected to the lightning network by means of an atomic
> transaction through any path of the network. But the only payment from them
> that ever hits the chain is their settlement with the hub.
>
> Imagine there was a TCP/IP data chain and corresponding lightning network.
> Everyone connected to the network has an "IP" channel with their ISP.
> Through this channel they can send data to anywhere on the network, and a
> traceroute shows what hops the data would take. But when settlement
> actually occurs all the network sees is the net amount of data that has
> gone through each segment -- without any context. There's no record
> preserved on-chain of who sent data to whom, just that X bytes went through
> the pipe on the way to somewhere unspecified.
>
> So it is with lightning payment networks. You open a channel with a hub
> and through that channel send coins to anyone accessible to the network.
> Channels only close when a participant needs the funds for non-lightning
> reasons, or when hubs need to rebalance. And when they do, observers on the
> chain learn nothing more than how much net coin moved across that single
> link. They learn nothing about where that coin eventually ended up.
>
> So back to your original question, each channel can be considered to have
> a pseudonymous identity, and each new channel given a new identity. Channel
> closures can even be coinjoin'd when the other party is cooperating. But
> ultimately, lightning usefully solves a problem where participants have
> semi-long lived payment endpoints.
>
> On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <raystonn@hotmail.com> wrote:
>
>> Write coalescing works fine when you have multiple writes headed to the
>> same (contiguous) location.  Will lightning be useful when we have more
>> unique transactions being sent to different addresses, and not just
>> multiple transactions between the same sender and address?  I have doubts.
>>
>>
>> -----Original Message----- From: Adam Back
>> Sent: Sunday, June 28, 2015 5:37 AM
>> To: Benjamin
>> Cc: bitcoin-dev@lists.linuxfoundation.org
>> Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
>>
>>
>> On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes@gmail.com> wrote:
>>
>>> I agree that naive scaling will likely lead to bad outcomes. They might
>>> have
>>> the advantage though, as this would mean not changing Bitcoin.
>>>
>>
>> Sure we can work incrementally and carefully, and this is exactly what
>> Bitcoin has been doing, and *must* do for safety and security for the
>> last 5 years!
>> That doesnt mean that useful serious improvements have not been made.
>>
>>  Level2 and Lightning is not well defined. If you move money to a third
>>> party, even if it is within the constrained of a locked contract, then I
>>> don't think that will solve the issues.
>>>
>>
>> I think you misunderstand how lightning works.  Every lightning
>> transaction *is* a valid bitcoin transaction that could be posted to
>> the Bitcoin network to reclaim funds if a hub went permanently
>> offline.  It is just that while the hubs involved remain in service,
>> there is no need to do so.  This is why it has been described as a
>> (write coalescing) write cache layer for Bitcoin.>
>>
>> I believe people expect lightning to be peer 2 peer like bitcoin.
>>
>> Adam
>> _______________________________________________
>> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 6762 bytes --]

  reply	other threads:[~2015-06-28 17:18 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-28  5:34 [bitcoin-dev] A Proposed Compromise to the Block Size Limit Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29   ` Benjamin
2015-06-28 12:37     ` Adam Back
2015-06-28 16:32       ` Raystonn .
2015-06-28 17:12         ` Mark Friedenbach
2015-06-28 17:18           ` Benjamin [this message]
2015-06-28 17:29           ` Gavin Andresen
2015-06-28 17:45             ` Mark Friedenbach
2015-06-28 17:51             ` Adam Back
2015-06-28 18:58               ` Adam Back
2015-06-28 21:05                 ` Gavin Andresen
2015-06-28 21:23                   ` Michael Naber
2015-06-28 22:07                   ` Adam Back
2015-06-29  0:59                     ` Eric Lombrozo
2015-06-29  1:13                     ` Eric Lombrozo
2015-06-29  1:45                     ` Andy Schroder
2015-06-30  0:42                     ` Tom Harding
2015-07-10  2:55                 ` Tom Harding
2015-06-28 17:53             ` Jorge Timón
2015-06-28 19:22             ` Andrew Lapp
2015-06-28 19:40               ` Benjamin
2015-06-28 12:32   ` Milly Bitcoin
  -- strict thread matches above, loose matches on Subject: below --
2015-06-27 14:39 Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29   ` Randi Joseph
2015-06-27 15:32     ` Peter Todd
2015-06-27 16:19   ` Michael Naber
2015-06-27 17:20     ` Peter Todd
2015-06-27 17:26       ` Benjamin
2015-06-27 17:37         ` Peter Todd
2015-06-27 17:46           ` Benjamin
2015-06-27 17:54             ` Peter Todd
2015-06-27 17:58               ` Venzen Khaosan
2015-06-27 19:34               ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09   ` Michael Naber
2015-06-27 16:28     ` Mark Friedenbach
2015-06-27 16:37     ` Peter Todd
2015-06-27 17:25       ` Michael Naber
2015-06-27 17:34         ` Peter Todd
2015-06-27 18:02           ` Jameson Lopp
2015-06-27 18:47             ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOoPuRaR_A3ani3d_KVjc4oTfmLYbP52rLsqBEQMZ4gajqoV8A@mail.gmail.com \
    --to=benjamin.l.cordes@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mark@friedenbach.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox