📅 Original date posted:2015-08-10
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
If I understand this correctly, Lightning only requires transaction
malleability to be fixed to be able to work ~ I believe that was going
to happen in a release of (bitcoind), but I'm not sure if that is
correct on timing ( note also, this wiki seems to be out of date on
infos about bitcoind https://en.bitcoin.it/wiki/Bitcoind )
I have also heard it said that bitcoin should support relative
locktime opcodes so that long-lived micropayment channels would be
able to be created, such that there would be Lightning functionality
beyond the basic microhop channels (which would be short-lived in
nature at the basic level).
This would be nice, but it seems like such discussions would take a
while to get done as basic development issues right now aren't even
wrapping up (e.g. blocksize debate related stuff.) Note that I've
been in favor of going ahead with Cameron Garnham's dynamic softfork
proposal right now, which can be seen at http://is.gd/DiFuRr - testing
it out, seeing how that works, and at the same time making
preparations for moving forward with Garzik's BIP 100 (which could be
tailored or refined based on additional data gathered, without being
turned into a controversial fork (e.g. needs to make sure to avoid
inclusion of XT, for example). Garnham's proposal and Garzik's
proposal are not mutually exclusive, imho, and I don't see why the
matter can't simply be resolved, it seems to be just an endless pile
of argumentation that will go on forever and ever. This needs to,
like, stop.
Also, it strikes me that unless and until certain changes can be made
in bitcoin that would reduce fees and cost to transact, solutions such
as Lightning are going to fill the gap whether or not you want them
to; users have a choice in the market, and as the billions of unbanked
are gradually excluded from straight bitcoin, people will seek other
services which offer them lesser fees to transact, or they will seek
other coins which offer them lesser cost to transact. It is, after
all, an open market. I have made this point before elsewhere albeit
with more emphasis (and data to back up my point):
( On Github at Pull Request #6201: http://is.gd/8bW0zq )
In making and successfully defending such points on Github, the
following conclusions were drawn:
As the cost to transact goes higher and higher based on this
observable trend (due to all the factors mentioned in the thread on
github), then people who are affected by these rising costs to
transact will do one of three things with respect to bitcoin (and
virtual currencies generally):
1) Ignore bitcoin (an unlikely possibility, but it is one that would
occur),
2) adopt alts which are more inclined to allow people to perform
microtransactions,
3) and/or use bitcoin increasingly off-chain, which is likely to come
with its own set of problems for the network.
Regarding donation or microdonation use cases, To keep it all
on-chain, wallets can be designed to accumulate donation micro-amounts
according to donation settings of a user (in voluntary donation use
cases such as in ABIS -- http://abis.io ) as an internal accounting
feature, for example, and when enough donation value is accumulated,
it can be sent to the recipient by piggybacking on one of the user's
daily transactions. This is one method doing so in a manner which is
on-chain; depending on the cryptocurrency under consideration, the
feasibility of doing this in a wallet will be greater or lesser.
- -O
On 08/09/2015 01:14 PM, Hector Chu via bitcoin-dev 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVyNlfAAoJEGxwq/inSG8CTvgH/3b4wyoU+hQtQ7Ewk4n1UK/Q
gBezGVfv6v9D8uRU+8gR37gG6TpiG3VS37g47fkAbqTTUzY16qGRXMV8mi0FVz/3
8Hqz7rWZEllYfeYrV9MUoNftrFmjy1PucPgd95BYmWaHoZRxBwhr+YpkZS5lfEqK
p1byEdqXW04sc3UBdNlirYNOBJA0wOPgco45G2S3gFBh5XQZ9YCLB+x/IN8rW1mS
wQ3FrXRdEKfGMZ83xij1zOVpwi3bPJ5XrUzEV3sdGUdj6jWi0Pa05tRD+0qt7dpZ
oPq4p6aLj2z5/mwyiaW6T14CNY1Mp46tMgAv+BOJ/M3HA350isTGxG2X+73KeH0=
=xX4u
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 15:45:15
in reply to nevent1q…qhe5
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 15:45:15Event JSON
{
"id": "fb41a5d0715c0f5ddade4b7c3dd9d6913928a76ff9566e938fb2f821968459db",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686152715,
"kind": 1,
"tags": [
[
"e",
"6694b179d616199569dd5736f93c40a4efdd5385f12cb8506ca3793769329b78",
"",
"root"
],
[
"e",
"c23e3cdc48f91a314384179e43af8036b81b8a90d01227eccbc8fcb12464891d",
"",
"reply"
],
[
"p",
"f3e056e548ecd779cfbea56b1bf9eb9c26afb3780523aa0df2e58f34f4b1faee"
]
],
"content": "📅 Original date posted:2015-08-10\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nHello,\n\nIf I understand this correctly, Lightning only requires transaction\nmalleability to be fixed to be able to work ~ I believe that was going\nto happen in a release of (bitcoind), but I'm not sure if that is\ncorrect on timing ( note also, this wiki seems to be out of date on\ninfos about bitcoind https://en.bitcoin.it/wiki/Bitcoind )\n\nI have also heard it said that bitcoin should support relative\nlocktime opcodes so that long-lived micropayment channels would be\nable to be created, such that there would be Lightning functionality\nbeyond the basic microhop channels (which would be short-lived in\nnature at the basic level).\n\nThis would be nice, but it seems like such discussions would take a\nwhile to get done as basic development issues right now aren't even\nwrapping up (e.g. blocksize debate related stuff.) Note that I've\nbeen in favor of going ahead with Cameron Garnham's dynamic softfork\nproposal right now, which can be seen at http://is.gd/DiFuRr - testing\nit out, seeing how that works, and at the same time making\npreparations for moving forward with Garzik's BIP 100 (which could be\ntailored or refined based on additional data gathered, without being\nturned into a controversial fork (e.g. needs to make sure to avoid\ninclusion of XT, for example). Garnham's proposal and Garzik's\nproposal are not mutually exclusive, imho, and I don't see why the\nmatter can't simply be resolved, it seems to be just an endless pile\nof argumentation that will go on forever and ever. This needs to,\nlike, stop.\n\nAlso, it strikes me that unless and until certain changes can be made\nin bitcoin that would reduce fees and cost to transact, solutions such\nas Lightning are going to fill the gap whether or not you want them\nto; users have a choice in the market, and as the billions of unbanked\nare gradually excluded from straight bitcoin, people will seek other\nservices which offer them lesser fees to transact, or they will seek\nother coins which offer them lesser cost to transact. It is, after\nall, an open market. I have made this point before elsewhere albeit\nwith more emphasis (and data to back up my point):\n( On Github at Pull Request #6201: http://is.gd/8bW0zq )\n\nIn making and successfully defending such points on Github, the\nfollowing conclusions were drawn:\nAs the cost to transact goes higher and higher based on this\nobservable trend (due to all the factors mentioned in the thread on\ngithub), then people who are affected by these rising costs to\ntransact will do one of three things with respect to bitcoin (and\nvirtual currencies generally):\n1) Ignore bitcoin (an unlikely possibility, but it is one that would\noccur),\n2) adopt alts which are more inclined to allow people to perform\nmicrotransactions,\n3) and/or use bitcoin increasingly off-chain, which is likely to come\nwith its own set of problems for the network.\n\nRegarding donation or microdonation use cases, To keep it all\non-chain, wallets can be designed to accumulate donation micro-amounts\naccording to donation settings of a user (in voluntary donation use\ncases such as in ABIS -- http://abis.io ) as an internal accounting\nfeature, for example, and when enough donation value is accumulated,\nit can be sent to the recipient by piggybacking on one of the user's\ndaily transactions. This is one method doing so in a manner which is\non-chain; depending on the cryptocurrency under consideration, the\nfeasibility of doing this in a wallet will be greater or lesser.\n\n- -O\n\n\nOn 08/09/2015 01:14 PM, Hector Chu via bitcoin-dev wrote:\n\u003e In the Lightning network it is assumed that the balances can always\n\u003e be settled on the blockchain if any of the parties along the\n\u003e channel has a problem. What if the fee on the settlement\n\u003e transactions is not high enough to enter the blockchain? You can't\n\u003e do replace-by-fee after the fact. Do the fees always have to assume\n\u003e worst case scenarios on the Bitcoin fee market?\n\u003e \n\u003e On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Tom, you appear to be misunderstanding how lightning network and \n\u003e micropayment hub-and-spoke models in general work.\n\u003e \n\u003e\u003e But neither can Bob receive money, unless payment hub has\n\u003e advanced it to the channel (or (2) below applies). Nothing\n\u003e requires the payment hub to do this.\n\u003e \n\u003e On the contrary the funds were advanced by the hub on the creation \n\u003e of the channel. There is no credit involved. if the funds aren't \n\u003e already available for Bob to immediately claim his balance, the \n\u003e payment doesn't go through in the first place.\n\u003e \n\u003e On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev \n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:\n\u003e \n\u003e\u003e Don't turn Bitcoin into something uninteresting, please.\n\u003e \n\u003e Consider how Bob will receive money using the Lightning Network.\n\u003e \n\u003e Bob receives a payment by applying a contract to his local payment \n\u003e channel, increasing the amount payable to him when the channel is\n\u003e closed.\n\u003e \n\u003e There are two possible sources of funding for Bob's increased\n\u003e claim. They can appear alone, or in combination:\n\u003e \n\u003e \n\u003e Funding Source (1) A deposit from Bob's payment hub\n\u003e \n\u003e Bob can receive funds, if his payment hub has made a deposit to\n\u003e the channel. Another name for this is \"credit\".\n\u003e \n\u003e This credit has no default risk: Bob cannot just take payment\n\u003e hub's deposit. But neither can Bob receive money, unless payment\n\u003e hub has advanced it to the channel (or (2) below applies).\n\u003e Nothing requires the payment hub to do this.\n\u003e \n\u003e This is a 3rd-party dependency totally absent with plain old \n\u003e bitcoin. It will come with a fee and, in an important way, it is\n\u003e worse than the current banking system. If a bank will not even\n\u003e open an account for Bob today, why would a payment hub lock up hard\n\u003e bitcoin to allow Bob to be paid through a Poon-Dryja channel?\n\u003e \n\u003e \n\u003e Funding Source (2) Bob's previous spends\n\u003e \n\u003e If Bob has previously spent from the channel, decreasing his claim\n\u003e on its funds (which he could have deposited himself), that claim\n\u003e can be re-increased.\n\u003e \n\u003e To avoid needing credit (1), Bob has an incentive to consolidate \n\u003e spending and income in the same payment channel, just as with \n\u003e today's banks. This is at odds with the idea that Bob will have \n\u003e accounts with many payment hubs. It is an incentive for\n\u003e centralization.\n\u003e \n\u003e \n\u003e With Lightning Network, Bob will need a powerful middleman to send\n\u003e and receive money effectively. *That* is uninteresting to me.\n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVyNlfAAoJEGxwq/inSG8CTvgH/3b4wyoU+hQtQ7Ewk4n1UK/Q\ngBezGVfv6v9D8uRU+8gR37gG6TpiG3VS37g47fkAbqTTUzY16qGRXMV8mi0FVz/3\n8Hqz7rWZEllYfeYrV9MUoNftrFmjy1PucPgd95BYmWaHoZRxBwhr+YpkZS5lfEqK\np1byEdqXW04sc3UBdNlirYNOBJA0wOPgco45G2S3gFBh5XQZ9YCLB+x/IN8rW1mS\nwQ3FrXRdEKfGMZ83xij1zOVpwi3bPJ5XrUzEV3sdGUdj6jWi0Pa05tRD+0qt7dpZ\noPq4p6aLj2z5/mwyiaW6T14CNY1Mp46tMgAv+BOJ/M3HA350isTGxG2X+73KeH0=\n=xX4u\n-----END PGP SIGNATURE-----",
"sig": "58c2e4a8373365850ec89104d176094fd976527d335f3bb2325b6fdf2ff6fdb4cf10c4705c91fe06da926873d0ec784944a4ebfd31aafdb93a822c35d9533c65"
}