{"type":"rich","version":"1.0","author_name":"npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","author_url":"https://nostr.ae/npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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-----"}