bitcoin-payment-channel 0.1.1.1 → 0.1.1.2

raw patch · 3 files changed

+24/−12 lines, 3 files

Files

• bitcoin-payment-channel.cabal +14/−10
• src/Data/Bitcoin/PaymentChannel/Internal/Payment.hs +0/−1
• src/Data/Bitcoin/PaymentChannel/Internal/Refund.hs +10/−1

@@ -1,16 +1,20 @@ name:                 bitcoin-payment-channel-version:              0.1.1.1+version:              0.1.1.2 synopsis:             Library for working with Bitcoin payment channels description:-    A Bitcoin payment channel allows two parties two send value to each other very rapidly.-    The speed of the value transfer is limited primarily by network latency, and payments-    cannot be double spent, as the receiver of funds is defined during channel setup.-    The channel setup procedure is trustless, in that the funding party is able to retrieve the funds,-    after a chosen expiration date, in case the receiving party goes missing.--    This library implements a type of payment channel (CHECKLOCKTIMEVERIFY-style) where channel setup-    is safe from transaction ID malleability, and value transfer is uni-directional (one party-    sends and the other party receives).+    A Bitcoin payment channel allows secure and instant transfer of bitcoins from one+     party to another. Payments are created and verified in less than a millisecond+     (plus network latency), and cannot be double spent, as the receiver of funds is defined+     during channel setup.+    When the channel is closed, the settlement transaction transfers the appropriate value to each+     party, thus paying the Bitcoin transaction fee only once, regardless of the number of payments+     made over the channel.+    The channel setup procedure is trustless, because the funding party - after the chosen+     expiration date - is able to reclaim the bitcoins used to fund the channel,+     in case the receiving party goes missing.+    This library implements a type of payment channel where channel setup+     is safe from transaction ID malleability, and value transfer is uni-directional (one party+     sends and the other party receives) (CHECKLOCKTIMEVERIFY-style).  author:         Rune K. Svendsen <runesvend@gmail.com> maintainer:     Rune K. Svendsen <runesvend@gmail.com>

@@ -36,7 +36,6 @@ ---Payment Tx builer---  - getPaymentTxForSigning ::     PaymentChannelState     -> BitcoinAmount      -- ^New sender value (newValueLeft)

@@ -15,8 +15,17 @@     let         (baseTx,_) = getPaymentTxForSigning st 0 --create empty payment tx, which redeems funding tx         refundOut = HT.TxOut (toWord64 $ pcsChannelTotalValue st - txFee) (pcsClientChange st)+        txInput0 = head $ HT.txIn baseTx     in-        baseTx { HT.txOut = [refundOut] }+        baseTx {+            HT.txOut = [refundOut],+            -- lockTime of refund tx must be equal to or greater than lockTime+            -- in channel redeemScript+            HT.txLockTime = toWord32 (pcsLockTime st),+            -- if the sequence field equals maxBound (0xffffffff),+            -- lockTime features are disabled, so we set it to that minus one+            HT.txIn = [ txInput0 { HT.txInSequence = maxBound-1 } ]+}  getRefundTxHashForSigning ::     PaymentChannelState