diff --git a/bitcoin-payment-channel.cabal b/bitcoin-payment-channel.cabal
--- a/bitcoin-payment-channel.cabal
+++ b/bitcoin-payment-channel.cabal
@@ -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>
diff --git a/src/Data/Bitcoin/PaymentChannel/Internal/Payment.hs b/src/Data/Bitcoin/PaymentChannel/Internal/Payment.hs
--- a/src/Data/Bitcoin/PaymentChannel/Internal/Payment.hs
+++ b/src/Data/Bitcoin/PaymentChannel/Internal/Payment.hs
@@ -36,7 +36,6 @@
 ---Payment Tx builer---
 
 
-
 getPaymentTxForSigning ::
     PaymentChannelState
     -> BitcoinAmount      -- ^New sender value (newValueLeft)
diff --git a/src/Data/Bitcoin/PaymentChannel/Internal/Refund.hs b/src/Data/Bitcoin/PaymentChannel/Internal/Refund.hs
--- a/src/Data/Bitcoin/PaymentChannel/Internal/Refund.hs
+++ b/src/Data/Bitcoin/PaymentChannel/Internal/Refund.hs
@@ -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