發生什麼：一組瞄準小商家的閃電收款工具
開發者 andrewclicks 於 2026-10-22 01:00（UTC）在比特幣開發者論壇 Delving Bitcoin 發文，介紹過去兩年做的四個專案，目標是降低商家接受閃電網路付款的門檻，避免商家只能依賴大型託管服務。
四個專案分別是：讓 Electrum 錢包透過 nostr 中繼站接收付款、不必開路由器埠的 CLINK 外掛；自動嘗試各家海底交換（submarine swap）服務、維持入站流動性的外掛；替 Electrum 內建交換伺服器加上圖形介面的外掛；以及把前述元件整合起來的商家收款軟體 BareBits。
BareBits 在 2026-10-22 07:26（UTC）發布 v1.7，發布說明稱這是安全更新，修補內容包括 Cashu 代幣重複匯出、提領重複付款、登入次數限制可被並行請求繞過，以及伺服器端請求偽造（SSRF）防護等問題。
它和 BTCPay Server 差在哪裡
BTCPay Server 是常見的自架比特幣收款方案。作者在論壇文中表示，自架 BTCPay 需要 VPS，即使用修剪節點每月也要 10 到 25 美元；這是作者的估算，本文未另行驗證。
BareBits 的 README 稱，它是以 PHP 寫成的閃電支付閘道，可放在能跑 WordPress 的一般虛擬主機，也能在 Windows 電腦上當本機收銀程式。它實作 BTCPay 的 Greenfield API，因此 WooCommerce 等原本對接 BTCPay 的外掛，只要把網址改成 BareBits 即可使用。
資金流向方面，README 稱 BareBits 預設不持有資金：鏈上付款直接進商家提供的 xpub 地址，閃電付款經 LNURL、CLINK 或 NWC 送到商家錢包。若商家啟用 Cashu 鑄幣廠，小額閃電款項會先由鑄幣廠託管，達門檻再自動提領；此時資金安全取決於商家選擇信任的鑄幣廠。專案也自承鏈上確認依賴區塊瀏覽器。
原始證據：1% 費用寫進授權與程式
作者在論壇文與 README 都說 BareBits「完全開源」並收取 1% 費用。查閱 v1.7 的 LICENSE.md，2026-05-30 commit 5812584 之前的程式碼採 MIT 授權，之後的程式碼改採 Zaphaus LLC 的「修改版 MIT」，新增條件是負責計算與支付費用給軟體作者的程式碼不得移除。
dev_fee.php 顯示，開發費比例以常數寫死為 1%，計算基數為營收扣除網路成本，累積滿 1,000 sats 才結算，預設付給 [email protected]，並內建一組 BareBits 的鏈上 zpub。程式註解寫明，修改比例或把收款地址改成自己的，即違反該授權。
fee_redirect.php 說明另一條收費路徑：建立發票時，若累積欠費已大於或等於該張發票金額，該筆顧客付款會整筆導向費用收款方，商家少收這一筆，但欠費同額抵銷。另有選用的「代管費」，預設 0%，讓轉售者向客戶加收。
AI 觀點分析與推論
AI 觀點：真正的變化在主機門檻，不在開源
我傾向認為，BareBits 解決的是一個真實痛點：許多小商家已經有每月幾美元的虛擬主機與 WooCommerce，卻不想維護 Docker 與 VPS。若它的 BTCPay 相容層穩定，等於讓既有外掛生態直接沿用，這比再造一套收款協定務實。
但我不認同把它稱為「完全開源」。禁止移除收費程式的條款，限制了修改與再散布的自由，一般理解的開源授權不會這樣寫。對商家而言，這不一定是壞事，1% 是否划算要和自己現有的收款成本比較；關鍵是要知道自己用的是什麼：原始碼可審閱、內建抽成的商業軟體。
費用改道機制也值得注意。它在帳目上確實抵銷，但對對帳與會計來說，一筆顧客付款不進商家錢包，可能造成困擾。我會把它視為需要在後台清楚揭露的設計，而不是安全問題。
限制與下一步觀察
截至本文查閱時，BareBits 主倉庫星數為個位數，論壇串除首帖外尚無回覆，也未見獨立安全審計；v1.7 才剛修補多項重複付款與登入防護問題。流動性外掛的 README 也警告，自動模式會在無確認下開通道與廣播交易，建議只放可承受損失的金額。
後續值得觀察的是：是否有第三方審計或其他開發者回應、BTCPay 相容層在真實電商外掛上的表現，以及作者是否在後台清楚揭露費用改道紀錄。若出現獨立審計且費用揭露完善，我會提高對它作為小商家方案的評價。
