Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Loop Out amount precision

Đang mở
  • Có gì không ổn?
#234 11 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
go
Lĩnh vực
cli, payments

Hướng nghiên cứu

Bắt đầu với luồng CLI loop out được mô tả bởi --amt và --fast, sau đó truy vết cách xác định output của swap ban đầu và số tiền sweep về sau. Quyết định xem tùy chọn sweep-fee hay việc tự động điều chỉnh đáp ứng tốt hơn yêu cầu thanh toán chính xác cho merchant, và bổ sung coverage cho hành vi về số tiền và phí thu được.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature request loop out

One of the largest barriers/sources of friction for people to use Loop Out for on-chain payments, is the lack of precision in setting the target UTXO size.

Merchant Invoice: 1000000 sats
loop out --amt=1000000 --addr={merchant address} --fast

This results in a transaction "TXswap" in the mempool like so:
UXTO1 (swap): 1000000 sat
UTXO2 (loops change): ??? sat

Once TXswap has confirmed, loopd will sweep UTXO1 in another transaction:
UTXO3 (payment): 999500 sat

Because of the fee, the end result is slightly underpaying the merchant invoice. This usually requires hours of back and forth, and waiting for a refund and trying again. Most likely just on-chain this time around...

I don't know if is feasible to add a --sweep_fee_sats flag, where I can specify I want the sweep to be 1000 sats, and then I'll just increase my total payment by 1000 sat. Or if it makes more sense just automatically increase the initial payment, to account for the sweep fee.

Loop out already gives some friction, by requiring 1-2 blocks to go by before the final TX is broadcast. This gives headaches for BitPay, and also CoinKite stores, which gives a timeout for when it expects the transaction to be broadcasted. At least if we can make the output payment amounts correct, we'd be getting closer to the feeling that BTC is "unlocked" in a channel instead of "locked" in a channel.
Thanks!

Ngôn ngữ chính
Go
Star
593
Fork
138
Merge trung bình
4 ngày 18 giờ
Pull request đã merge (30 ngày)
20

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của lightninglabs/loop

Tất cả issue của lightninglabs/loop

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.