<unnamed>

Public Key

npub130jddflllc905dlmj0pks9j6fdtld9eu0pql9gm86dxts7whrvxq5hyp4t

Profile Code

nprofile1qqsghexk5llluzh6xlae8smgzedyk4lkju78ss0j5dnaxn9c08t3krqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mq0r6yz0

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 13:04:17 UTC

- reply

📅 Original date posted:2021-10-15
📝 Original message:
On Fri, Oct 15, 2021 at 02:29:15PM +0000, ZmnSCPxj wrote:
> I propose substantially the same thing here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-September/003256.html
>
> In that proposal, I wrote:
>
> > Another thought is: Does the forwarding node have an incentive to
> > lie?
> > Suppose the next hop is alive but the forwarding node has
> > insufficient capacity towards the next hop.
> > Then the forwarding node can lie and claim it can still resolve the
> > HTLC, in the hope that a few milliseconds later, when the actual
> > HTLC arrives, the capacity towards the next hop has changed.
> > Thus, even if the capacity now is insufficient, the forwarding node
> > has an incentive to lie and claim sufficient capacity.
Under Joost's proposal, there's even more of an incentive to lie: sats
to be had.
> > Against the above, we can mitigate this by accepting "no" from *any*
> > node along the path, but only accepting "yes" from the actual payee.
This doesn't really help if all the routers along the way are lying and
saying 'yes'. Only the payee's 'yes' is meaningful, and she doesn't have
enough information to know if the routers were lying or not.
I think the actual enforcement mechanism is (also from your proposal
Zmn):
> > Presumably, when a node receives a question, it checks if the asking
> > node has sufficient capacity towards it first, and if not, fails the
> > channel between them, since obviously the asking node is not
> > behaving according to protocol and is buggy.
But I'm not sure the incentives align for this tattling on your neighbor.
Let's take an example A -> B -> C -> D
A sends a probe towards D. B doesn't have sufficient liquidity to send
to C. But B is a liar. B says 'yes'.
C now notes that B is lying, but is faced with the dilemma:
"I could either say 'no' because I can plainly see that B is lying, or
I could say 'yes' and get some free sats from the failed payment (or
via the hope of a successful payment from a capacity increase in the
intervening milliseconds)."
So C decides it's in his interest to keep the lie going. D, the payee,
can't tell that it's a lie when it reaches her.
If C did want to tattle, it's important that he be able to do so in a
way that blames B instead of himself, otherwise payers will assume
(incorrectly, and to C's detriment) that the liquidity deficit is with C
rather than B.
Maybe Joost's suggestion of using a simple reputation scheme would work.

2023-06-09 13:04:17 UTC

- reply

📅 Original date posted:2021-10-15
📝 Original message:
On Thu, Oct 14, 2021 at 09:48:27AM +0200, Joost Jager wrote:
> So how would things work out with a combination of both of the
> proposals described in this mail? First we make probing free (free as
> in no liquidity locked up) and then we'll require senders to pay for
> failed payment attempts too. Failed payment attempts after a
> successful probe should be extremely rate, so doesn't this fix the ux
> issue with upfront fees?
Why couldn't a malicious routing node (or group of colluding routing
nodes) succeed the probe and then fail the payment in order to collect
the failed payment fee?

2023-06-07 15:40:35 UTC

- reply

📅 Original date posted:2015-06-26
📝 Original message:On 06/26/2015 02:23 PM, Jeff Garzik wrote:
> Failure to plan now for a hard fork increase 6(?) months in the future
> produces that lumpy, unpredictable market behavior.
>
> The market has baked in the years-long behavior of low fees. From the
> market PoV, inaction does lead to precisely that, a sudden change over
> the span of a few months.
Which market participants are you referring to?
I entered the bitcoin market with open eyes, aware that it faces hard
scalability challenges by design. I was also aware that because of these
challenges, eventually transaction fees would have to rise.
Nevertheless, I made the decision to invest because of the utility I
gain from the anti-censorship, privacy, control, store of value, and
security aspects of bitcoin -- many of which stem from
decentralization, which others have demonstrated to be linked to the
block size.
On the other hand, there are undoubtedly other market participants who
heard hype about "zero fee transactions to anywhere in the world",
believed it would scale, and made (mal)investments as a result.
As for how many market participants of each flavor, and how deep their
respective pockets, who knows? My experience in markets has lead me to
realize that it's never wise to assume I know what "the market" does and
doesn't know. If Jeff Garzik is right about what the market has priced
in, then yes, filled blocks will be rocking the boat. But who's to say
that the smartest, biggest investors and traders don't already see this
scaling problem, and have already priced it in? In this case, a sudden
large increase in the block size is actually rocking the boat. The point
is, you can't know either way, so trying to pre-empt the market in this
way is erroneous.
Regarding entrepreneurial investment specifically, why should we favor
the entrepreneurs who require a more centralized bitcoin over those who
were more considerate of the possibility of rising transaction fees when
making their business models?
In my mind, we should favor neither, which is why I'm basically in
agreement with Pieter that this sense of "emergency" shouldn't really be
a part of the debate.
Not that I'm taking a stand on the specific block size issue either way.
I just think this particular line of reasoning (presupposing what
information the market has and has not already baked in) is unsound.

2023-06-07 15:38:39 UTC

- reply

📅 Original date posted:2015-06-21
📝 Original message:On 06/19/2015 07:48 AM, Brooks Boyd wrote:
> Has there been any talk about reducing the time between blocks? If
> blocks were allowed to come twice as fast, they would be able to clear
> pending transactions in the mempool the same as if the block size
> doubled, but would allow mining to stay more decentralized since miners
> wouldn't be working on such large-scale blocks? It would still take more
> storage space to store the blockchain, though.
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07663.html

2023-06-07 15:34:00 UTC

- reply

📅 Original date posted:2015-05-10
📝 Original message:On 05/08/2015 11:36 PM, Gregory Maxwell wrote:
> Another related point which has been tendered before but seems to have
> been ignored is that changing how the size limit is computed can help
> better align incentives and thus reduce risk. E.g. a major cost to the
> network is the UTXO impact of transactions, but since the limit is blind
> to UTXO impact a miner would gain less income if substantially factoring
> UTXO impact into its fee calculations; and without fee impact users have
> little reason to optimize their UTXO behavior.
Along the lines of aligning incentives with a diversity of costs to a
variety of network participants, I am curious about reactions to Justus'
general approach:
http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
I realize it relies on pie-in-the-sky ideas like micropayment channels,
but I wonder if it's a worthy long-term ideal direction for this stuff.