Jim Renkel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-12-06 to 2017-12-21
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:48:15

- reply

📅 Original date posted:2017-12-20
📝 Original message:
Hello, all!
I'm a long-time computer networking developer, but a newbie to
cryptocurrency, and am interested in contributing to its development.
While looking at the lightning network design and code, I've come up
with an idea the would reduce the number of blockchain transactions used
by the LN, and the fees paid to confirm them, in a common LN use case.
I did a quick search and couldn't find this idea presented previously,
but I may have missed it. If so, or if the idea is faulty, I'm sure you
guys will let me know. :-)
And forgive me if I don't have the terminology quite right yet.
The use case I am referring to is the frequent, repeated purchases by a
customer from the same merchant over an extended period of time. I think
this will be a common use case.
For example: Alice buys a cup of coffee from Bob's Coffee Shoppe every
day, has done so for years, will do so for years.
To use the LN to pay for these purchases, Alice opens and funds an LN
channel to Bob. This takes one blockchain transaction.
As coffees are purchased every day, funds are transferred from Alice to
Bob in the channel without any blockchain transactions.
Alice cannot afford to fund the channel for an extended period of time,
and Bob is unwilling to wait an extended period of time to be paid for
the coffees Alice has purchased.
So every week or so, Alice and Bob close the channel, Alice gets back
any unspent funds, and Bob gets the funds that have been transferred to
him for Alice's purchases. Then Alice and Bob re-open the channel with
new funding from Alice. Closing and re-opening the channel each take one
blockchain transaction.
Over the life of the channel, if there are n close/re-open cycles, 2*n
blockchain transactions are required: 1 to open the channel initially, 2
each time the channel is closed and re-opened (n-1 times), and 1 to
close the channel finally.
If the LN were enhanced with an operation to deposit and withdraw
funding in the channel to and from the blockchain without closing the
channel, this could be done with a single blockchain transaction that is
essentially the merge of the closing and re-opening blockchain transactions.
In this example, each adjustment will only pay Bob his accumulated but
as yet unpaid funds and charge Alice for the new funds she places into
the channel, but leave Alice's unspent funds in the channel. The channel
could continue to operate between the launching and confirmation of the
adjustment transaction if Alice has unspent funds in the channel.
Then the n cycles would only require n+1 blockchain transactions: 1 to
initially open the channel, 1 each time the channel funding is adjusted
(total n-1), and 1 to finally close the channel. This is a significant
reduction in the number of blockchain transactions required, approaching
50% in the limit as n approaches infinity.
What about blockchain transaction fees? I've done the analysis, but it's
quite long (several conditions and dozens of combinations of conditions
to consider), so I won't include it here now. I will included it in
another post if anyone is interested and doesn't do the analysis for
themselves.
The bottom line of the analysis is that the number of inputs and the
number of outputs in the funding adjustment transaction are each never
greater than the sum of the number of inputs and the number of outputs,
respectively, in the channel opening and closing transactions that the
adjustment transaction replaces.
Thus the adjustment transaction is:
- never bigger than the closing and re-opening transactions put together,
- sometimes smaller, and
- occasionally significantly smaller.
And there's only one transaction instead of two, so ya always save on
the transaction header! :-)
Thus, the fee paid for the adjustment transaction, assuming the same fee
rate for all the transactions, is:
- never more than the sum of the fees paid for the closing and
re-opening transactions,
- sometimes less, and
- occasionally significantly less.
This reduction in fees is by an additive amount.
Because the channel remains open while waiting for the adjustment
transaction to confirm, there may be less urgency in having it confirm.
So it's fee rate can be reduced, reducing the fee paid by a
multiplicative amount.
Combined, these two effects lead to a reduction in total fees paid for
operating the channel, sometimes a significant reduction.
Comments expected and welcome.
If this high-level, bare-bones idea to seen to be worthy of further
consideration, I would like to work with the community to flesh out a
detailed specification, and, if consensus can be reached on that, to
participate in the implementation of it.
Jim Renkel

2023-06-09 12:48:15

- reply

📅 Original date posted:2017-12-20
📝 Original message:
Hello, all!
I'm a long-time computer networking developer, but a newbie to
cryptocurrency, and am interested in contributing to its development.
While looking at the lightning network design and code, I've come up
with an idea the would reduce the number of blockchain transactions used
by the LN, and the fees paid to confirm them, in a common LN use case.
I did a quick search and couldn't find this idea presented previously,
but I may have missed it. If so, or if the idea is faulty, I'm sure you
guys will let me know. :-)
And forgive me if I don't have the terminology quite right yet.
The use case I am referring to is the frequent, repeated purchases by a
customer from the same merchant over an extended period of time. I think
this will be a common use case.
For example: Alice buys a cup of coffee from Bob's Coffee Shoppe every
day, has done so for years, will do so for years.
To use the LN to pay for these purchases, Alice opens and funds an LN
channel to Bob. This takes one blockchain transaction.
As coffees are purchased every day, funds are transferred from Alice to
Bob in the channel without any blockchain transactions.
Alice cannot afford to fund the channel for an extended period of time,
and Bob is unwilling to wait an extended period of time to be paid for
the coffees Alice has purchased.
So every week or so, Alice and Bob close the channel, Alice gets back
any unspent funds, and Bob gets the funds that have been transferred to
him for Alice's purchases. Then Alice and Bob re-open the channel with
new funding from Alice. Closing and re-opening the channel each take one
blockchain transaction.
Over the life of the channel, if there are n close/re-open cycles, 2*n
blockchain transactions are required: 1 to open the channel initially, 2
each time the channel is closed and re-opened (n-1 times), and 1 to
close the channel finally.
If the LN were enhanced with an operation to deposit and withdraw
funding in the channel to and from the blockchain without closing the
channel, this could be done with a single blockchain transaction that is
essentially the merge of the closing and re-opening blockchain transactions.
In this example, each adjustment will only pay Bob his accumulated but
as yet unpaid funds and charge Alice for the new funds she places into
the channel, but leave Alice's unspent funds in the channel. The channel
could continue to operate between the launching and confirmation of the
adjustment transaction if Alice has unspent funds in the channel.
Then the n cycles would only require n+1 blockchain transactions: 1 to
initially open the channel, 1 each time the channel funding is adjusted
(total n-1), and 1 to finally close the channel. This is a significant
reduction in the number of blockchain transactions required, approaching
50% in the limit as n approaches infinity.
What about blockchain transaction fees? I've done the analysis, but it's
quite long (several conditions and dozens of combinations of conditions
to consider), so I won't include it here now. I will included it in
another post if anyone is interested and doesn't do the analysis for
themselves.
The bottom line of the analysis is that the number of inputs and the
number of outputs in the funding adjustment transaction are each never
greater than the sum of the number of inputs and the number of outputs,
respectively, in the channel opening and closing transactions that the
adjustment transaction replaces.
Thus the adjustment transaction is:
- never bigger than the closing and re-opening transactions put together,
- sometimes smaller, and
- occasionally significantly smaller.
And there's only one transaction instead of two, so ya always save on
the transaction header! :-)
Thus, the fee paid for the adjustment transaction, assuming the same fee
rate for all the transactions, is:
- never more than the sum of the fees paid for the closing and
re-opening transactions,
- sometimes less, and
- occasionally significantly less.
This reduction in fees is by an additive amount.
Because the channel remains open while waiting for the adjustment
transaction to confirm, there may be less urgency in having it confirm.
So it's fee rate can be reduced, reducing the fee paid by a
multiplicative amount.
Combined, these two effects lead to a reduction in total fees paid for
operating the channel, sometimes a significant reduction.
Comments expected and welcome.
If this high-level, bare-bones idea is seen to be worthy of further
consideration, I would like to work with the community to flesh out a
detailed specification, and, if consensus can be reached on that, to
participate in the implementation of it.
Jim Renkel

2023-06-07 18:08:14

- reply

📅 Original date posted:2017-12-06
📝 Original message:As i understand it, the transactions to be included in a block are
entirely up to the miner of that block.
What prevents a miner from implementing the proposal on their own?
If this is adopted as some kind of "policy", what forces a miner to
follow it?
Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
>
> # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering
> Transactions In Blocks
>
>
> I admit, with my limited experience in the operation of the protocol,
> the section entitled 'Solution operation' may not be entirely correct
> but you will get the idea. If I have it wrong, please correct it back
> to the list.
>
> ## The problem:
>
>
> Everybody wants value. Miners want to maximize revenue from fees.
> Consumers want transaction reliability and, (we presume) low fees.
>
>
> Current transaction bandwidth limit is a limiting factor for both.
>
> ## Solution summary:
>
>
> Provide each transaction with a transaction weight, being a function
> of the fee paid (on a curve), and the time waiting in the transaction
> pool (also on a curve) out to n days (n=30 ?); the transaction weight
> serving as the likelihood of a transaction being included in the
> current block, and then use a target block size.
>
>
> Protocol enforcement to prevent high or low blocksize cheating to be
> handled by having the protocol determine the target size for the
> current block using; current transaction pool size x ( 1 / (144 x n
> days ) ) = transactions to be included in the current block.
>
> The curves used for the weight of transactions would have to be
> appropriate.
>
> ## Pros:
>
>
> * Maximizes transaction reliability.
> * Maximizes possibility for consumer and business uptake.
> * Maximizes total fees paid per block without reducing reliability;
> because of reliability, confidence and uptake are greater; therefore,
> more transactions and more transactions total at priority fees.
> * Market determines fee paid for transaction priority.
>
> * Fee recommendations work all the way out to 30 days or greater.
>
> * Provides additional block entropy and greater security since there
> is less probability of predicting the next block.
>
> ## Cons:
>
>
> * ?
> * Must be first be programmed.
> * Anything else?
>
> ## Solution operation:
>
>
> As I have said, my simplistic view of the operation. If I have this
> wrong, please correct it back to the list.
>
>
> 1. The protocol determines the target block size.
>
> 2. Assign each transaction in the pool a transaction weight based on
> fee and time waiting in the transaction pool.
>
> 3. Begin selecting transactions to include in the current block using
> transaction weight as the likelihood of inclusion until target block
> size is met.
>
> 4. Solve block.
>
> Regards,
>
> Damian Williamson
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/c143a467/attachment-0001.html>

2023-06-07 18:08:14

- reply