Owen Gunden [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-10 to 2022-09-01
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:06:47

- reply

📅 Original date posted:2022-09-01
📝 Original message:
On 7/1/22 08:02, Joost Jager wrote:> Any thoughts from routing node
operators would be welcome too (or links > to previous threads).
I'm a routing node operator and have been for over a year. I've been
wanting this feature (plus negative fees) for a long time now.
Reason 1:
For peers that tend to be liquidity sources (i.e. the liquidity tends to
be all on my side), there's currently no way to keep a channel in
balance with fees. All I can do is set a zero outbound fee and usually
that's not good enough :/. A high inbound fee would discourage payments
through that route.
Reason 2:
Not all inbound traffic is created equally. If two different peers wish
to route through me to the same outbound peer, I may value the two
forwards differently depending on who the sender is. E.g.
A->C where A is a great peer that I frequently route payments to
B->C where B is a peer that I rarely route payments to, or otherwise
wish to preserve more inbound from
I'm much happier routing A->C than I am routing B->C, but there's
currently no way of expressing this to the market through fees. All I
can do is htlc-intercept B->C and reject it, but this damages my
reputation obviously.
Reason 3:
Greater expressivity in fee-setting generally allows markets to push
more flows off-chain without having to loop or open new channels. While
I think negative fees would be more impactful for this, inbound fees are
helpful as well. Combining negative + inbound fees is where the real
magic would happen IMO.

2023-06-09 13:04:17

- 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

- 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 23:00:16

- reply

📅 Original date posted:2021-10-20
📝 Original message:On Wed, Oct 20, 2021 at 07:37:48PM +0000, Pieter Wuille wrote:
> On Wednesday, October 20th, 2021 at 3:20 PM, Owen Gunden via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I also notice that, as of 22.0, Wladimir is no longer signing the
> > releases, and I have no trust in my gpg network of the people who seem
> > to have replaced him.
>
> This is not correct. Here are Wladimir's attestations on the 22.0
> release:
> https://github.com/bitcoin-core/guix.sigs/tree/main/22.0/laanwj
>
> There is no separate special release key anymore though. Instead, the
> build attestations (by anyone) can be used as your trust basis.
Ah, that explains it, thanks Pieter. I was looking for a signature from
the release key 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964,
which was still being supplied as recently as 0.21.1.
> There is no new website. The Bitcoin Core project website has been
> https://bitcoincore.org for years.
Some of us are very old :).

2023-06-07 23:00:15

- reply

📅 Original date posted:2021-10-20
📝 Original message:On Wed, Oct 20, 2021 at 04:47:17PM +0200, Prayank wrote:
> > It seems confusing to have two sites that seemingly both represent
> > bitcoin core.
>
> There is only one website which represents Bitcoin Core full node
> implementation. You can download Bitcoin Core from
> https://bitcoincore.org
I also notice that, as of 22.0, Wladimir is no longer signing the
releases, and I have no trust in my gpg network of the people who seem
to have replaced him.
Given the level of security at stake here, my eyebrows are raised at
this combination of items changing (new website + new gpg signers at the
same time).

2023-06-07 23:00:14

- reply

📅 Original date posted:2021-10-20
📝 Original message:When I search for "download bitcoin core" my top result is bitcoin.org,
which is out of date and doesn't have 22.0.
It seems confusing to have two sites that seemingly both represent
bitcoin core.
Maybe the download links could be removed from bitcoin.org and instead
it could just link to bitcoincore.org?

2023-06-07 15:41:29

- reply

📅 Original date posted:2015-07-02
📝 Original message:I'm also a user who runs a full node, and I also like this idea. I think
Gavin has done some back-of-the-envelope calculations around this stuff,
but nothing so clearly defined as what you propose.
On 07/02/2015 08:33 AM, Mistr Bigs wrote:
> I'm an end user running a full node on an aging laptop.
> I think this is a great suggestion! I'd love to know what system
> requirements are needed for running Bitcoin Core.
>
> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
> <jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at me.com>> wrote:
>
> I’m a game developer. I write time critical code for a living and
> have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
> These budgets are based on what we call a minimum specification (of
> hardware); min spec for short. In most cases the min spec is based
> on entry model machines that are available during launch, and will
> give the user an enjoyable experience when playing our games.
> Obviously, we can turn on a number of bells and whistles for people
> with faster machines, but that’s not the point of this mail.
>
> The point is, can we define a min spec for Bitcoin Core? The number
> one reason for this is: if you know how your changes affect your
> available budgets, then the risk of breaking something due to
> capacity problems is reduced to practically zero.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 15:40:35

- 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

- 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:47

- reply

📅 Original date posted:2015-05-16
📝 Original message:On 05/13/2015 09:31 PM, Aaron Voisine wrote:
> > by people and businesses deciding to not use on-chain settlement.
>
> I completely agree. Increasing fees will cause people voluntary
> economize on blockspace by finding alternatives, i.e. not bitcoin.
This strikes me as a leap. There are alternatives that still use bitcoin
as the unit of value, such as sidechains, offchain, etc. To say that
these are "not bitcoin" is misleading.
> A fee however is a known, upfront cost... unpredictable transaction failure in
> most cases will be a far higher, unacceptable cost to the user than the
> actual fee.
Are we sure that raising the block size is the only way to avoid
"unpredictable transaction failure"? If so, and it's as bad as you say
it is, aren't we screwed anyway when we inevitably start hitting the cap
(even if it's raised 10x or 20x)? And if that's the case, then don't we
do a disservice to users by continuing to pretend that we can make this
problem go away?
> The higher the costs of using the system, the lower the
> adoption as a store-of-value.
On what do you base this? Gold has a very high cost of using (storage,
transport) and yet is perhaps the most widely accepted store of value.

2023-06-07 15:34:00

- 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.