Bitcoin’s Time Locks - Summa - Medium

Locktime: Use Bitcoin script to its fullest potential.

https://hedgetrade.com/what-is-locktime/
Did you know you can set time parameters on your Bitcoin transactions? I have written I brief explanation of it here.
submitted by CryptoEK to Bitcoin [link] [comments]

LockTime - nLockTime /r/Bitcoin

LockTime - nLockTime /Bitcoin submitted by SimilarAdvantage to BitcoinAll [link] [comments]

[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

submitted by ciphera to Bitcoin [link] [comments]

Will this locktime tx ever become valid? /r/Bitcoin

Will this locktime tx ever become valid? /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

How to create a locktime based transaction /r/Bitcoin

How to create a locktime based transaction /Bitcoin submitted by BitcoinAllBot to BitcoinAll [link] [comments]

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Aug 13 2015 /r/bitcoin_devlist

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Aug 13 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

BIP 68 (Relative Locktime) bug | Tom Harding | Jul 05 2015 /r/bitcoin_devlist

BIP 68 (Relative Locktime) bug | Tom Harding | Jul 05 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Bitcoin locktime issue

How can I create a transaction using the command createrawtransaction but specifying a locktime?
submitted by RIP-Department to Bitcoin [link] [comments]

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak) | Nicolas Dorier | Aug 13 2015 /r/bitcoin_devlist

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime (Btc Drak) | Nicolas Dorier | Aug 13 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Sep 16 2015 /r/bitcoin_devlist

[BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime | Btc Drak | Sep 16 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

With the LN support in master, did CLI or GUI support for CTLV make it in?

CTLV is a type of arbitrary P2SH TXN that allows you to lock a TXN until a certain datetime. It's a bit different from locktime since it is usually used in a N-of-M multisig situation.
I thought that LN required CTLV so was wondering if there is a formal GUI feature for it or CLI to exercise in for on-chain UTXOs now?
submitted by brianddk to Electrum [link] [comments]

[Idea] Bech32 encoding of private keys

Ever since I saw BIP-173 I was excited to see the encoding used anywhere other than addresses. I've done some search but apart from some comments here and there I haven't been able to find any major work done (please let me know if you know of any proposals). Here is my idea of addressing some of the problems with current encoding of private keys:

Using Bech32 encoding instead of Base58

While writing a private key recovery tool I've felt how hard it is to come up with an optimized algorithm to recover a key that is missing a couple of characters (eg. a damaged paper wallet). That is not true with Bech32 being a multiply of base-2 algorithm is inherently faster, and the checksum is not a bottleneck since it is not a hash algorithm. Bech32 also has the benefit of having error detection.

Script (address) type

Currently when a user imports/sweeps a private key in a wallet client, that client either has to explicitly ask user for the script type (like Electrum) which means user is exposed to complications and has to be familiar with script types; or the wallet has to construct all script types and scan the blockchain for all of them (like bitcoin core) which adds more burden on the client. If the encoding included a script type that becomes so much easier.

Locktime!

Another burden on both clients and users (specially full node users) is the time consuming need for a re-scan of the entire blockchain to find the historical transactions that belong to an imported key. A timestamp can make that process a lot shorter. Using locktime (similar to last 4 bytes of any transaction) the key string (aka WIF) could include either a block height or a date-time value of when the key was created.
This idea was added to Bitcoin.Net library as an "experimental" class. Direct link to the code
Here is an example with a random key from Bitcoin.Net KeyHelper class:
Original WIF (Base-58): L28Peud5cQcijrtMthAdUS8FynpM8PKZtnoUZb1VAio9WxKoebHt Key bytes (Base-16): 92734fe879f662ff8ee4eb87dd019425e2ee73ff3edd0c4dc3def2f71e1a6a69 Version byte (ie. the script type): 0x02 or P2WPKH Date UTC: 5/4/2020 7:11:05 AM H.R.P.: bprv New encoding (versioned Bech-32): bprv1zjfe5l6re7e30lrhyawra6qv5yh3wuull8mwscnwrmme0w8s6df5sns90tcqqzyen4e 
Note that key is encoded the same way an address would be encoded (version byte is added separately as a 5-bit value instead of 8-bit).
submitted by Coding_Enthusiast to Bitcoin [link] [comments]

HELP! OverflowError: timestamp out of range for platform time_t

Hi,
I am guessing this means Electrum Wallet is set to a particular time zone, which is not allowing me to send bitcoin. As I tried to send to the exchange and found this error popped up. This is my first time using the wallet and I have no idea how to change the time to sync.
Anyone have an idea what I can do to change it(thats is it is the time issue) so I can send to exchange.
Thanks
Traceback
Traceback (most recent call last): File "/home/dotbin/electrum/electrum/gui/qt/main_window.py", line 1542, in do_pay self.do_pay_invoice(invoice) File "/home/dotbin/electrum/electrum/gui/qt/main_window.py", line 1555, in do_pay_invoice self.pay_onchain_dialog(self.get_coins(), outputs) File "/home/dotbin/electrum/electrum/gui/qt/main_window.py", line 1591, in pay_onchain_dialog external_keypairs=external_keypairs) File "/home/dotbin/electrum/electrum/gui/qt/main_window.py", line 1617, in preview_tx_dialog window=self) File "/home/dotbin/electrum/electrum/gui/qt/transaction_dialog.py", line 690, in __init__ finalized=False, external_keypairs=external_keypairs) File "/home/dotbin/electrum/electrum/gui/qt/transaction_dialog.py", line 126, in __init__ self.add_tx_stats(vbox) File "/home/dotbin/electrum/electrum/gui/qt/transaction_dialog.py", line 634, in add_tx_stats self.locktime_e = LockTimeEdit() File "/home/dotbin/electrum/electrum/gui/qt/locktimeedit.py", line 32, in __init__ self.locktime_date_e = LockTimeDateEdit() File "/home/dotbin/electrum/electrum/gui/qt/locktimeedit.py", line 155, in __init__ self.setMaximumDateTime(datetime.fromtimestamp(self.max_allowed_value)) OverflowError: timestamp out of range for platform time_t
Additional information
submitted by unusual_characters to Electrum [link] [comments]

[How-To] Crafting an offline TXN with the trezorlib python API

With the rollout of the new 0.12.0 Trezor API, I thought it might be time to update some of my old offline_txn scripts. The following is about 80 lines of python that will craft and sign a VERY simple transaction on Testnet.
The new rollout also comes with some new tools. The build_tx.py that is useful in conjunction with the trezorctl sign_tx command.
Both of the methods below will produce a signed TXN that can then be imported into Electrum using the "Tools -> Load transaction -> From text" command.
Note: u/Crypto-Guide has a good walkthrough for installing trezorlib in Windows if you haven't already done that.

Example of using trezorctl btc sign-tx

This example uses the build_tx.py script to build JSON to feed to the sign-tx command. You will need to download the build_tx.py file from github. It is not automatically installed with the trezor package.
```

python build_tx.py | trezorctl btc sign-tx -

Coin name [Bitcoin]: Testnet Blockbook server [btc1.trezor.io]: tbtc1.trezor.io
Previous output to spend (txid:vout) []: e294c4c172c3d87991...060fad1ed31d12ff00:0 BIP-32 path to derive the key: m/84'/1'/0'/0/0 Input amount: 129999866 Sequence Number to use (RBF opt-in enabled by default) [4294967293]: Input type (address, segwit, p2shsegwit) [segwit]:
Previous output to spend (txid:vout) []:
Output address (for non-change output) []: 2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3 Amount to spend (satoshis): 129999706
Output address (for non-change output) []: BIP-32 path (for change output) []: Transaction version [2]: Transaction locktime [0]: Please confirm action on your Trezor device.
Signed Transaction: 0200000000010100ff121dd31ead0f06...f279b642d85c48798685f86200000000 ```

Example of using crafting a TXN using trezorlib directly

If your good with python, or want to see how everything works under the hood, here's 80 lines of python to generate a similar signed transaction.
```python

!/usbin/env python3

[repo] https://github.com/brianddk/reddit ... python/offline_txn.py

[req] pip3 install trezor

from trezorlib import btc, messages as proto, tools, ui from trezorlib import MINIMUM_FIRMWARE_VERSION as min_version from trezorlib.client import TrezorClient from trezorlib.transport import get_transport from trezorlib.btc import from_json from json import loads from decimal import Decimal from sys import exit

Tested with SLIP-0014 allallall seed (slip-0014.md)

User Provided Fields; These are pulled from test scripts

CHANGE THESE!!!

coin = "Testnet"

Get legacy UTXO prev_txn hex from blockbook server. For example:

https://tbtc1.trezor.io/api/tx-specific/ \

e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00

in1_prev_txn_s = '{"txid":' \ '"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00"}'
in1_prev_index = 0 in1_addr_path = "m/84'/1'/0'/0/0" # allallall seed in1_amount = 129999867 out1_address = "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" out1_amount = in1_amount - 192

Defaults

tx_version = 2 tx_locktime = 0 sequence = 4294967293

Code

in1_prev_txn_j = loads(in1_prev_txn_s, parse_float=Decimal) in1_prev_hash = in1_prev_txn_j['txid'] in1_prev_hash_b = bytes.fromhex(in1_prev_hash) device = get_transport() client = TrezorClient(transport=device, ui=ui.ClickUI())
fw_version = (client.features.major_version, client.features.minor_version, client.features.patch_version) if fw_version < min_version[client.features.model]: print("Please flash to the latest FW") exit(1)
signtx = proto.SignTx( version = tx_version, lock_time = tx_locktime )
ins = [proto.TxInputType( address_n=tools.parse_path(in1_addr_path), prev_hash=in1_prev_hash_b, prev_index=in1_prev_index, amount=in1_amount, script_type=proto.InputScriptType.SPENDWITNESS, sequence=sequence )] outs = [proto.TxOutputType( address=out1_address, amount=out1_amount, script_type=proto.OutputScriptType.PAYTOADDRESS )]
txes = None for i in ins: if i.script_type == proto.InputScriptType.SPENDADDRESS: tx = from_json(in1_prev_txn_j) txes = {in1_prev_hash_b: tx} break
_, serialized_tx = btc.sign_tx(client, coin, ins, outs, details=signtx, prev_txes=txes) client.close() print(f'{{"hex": "{serialized_tx.hex()}"}}') ```
From here, you simple take the resultant TXN hex and import it into Electrum using the "Tools -> Load transaction -> From text" clickpath
submitted by brianddk to Bitcoin [link] [comments]

Signing Issue -- Signature must use SIGHASH_FORKID

Currently integrating my wallet software with Bitcoin Cash, but am having one hell of a time sending funds. I like to think I'm quite well versed with the bitcoin protocol, but this one has me stumped, so any help greatly appreciated.
Keep getting that, "Signature must use SIGHASH_FORKID" error. I know the general format of bitcoin txs, which is basically: Version + Num_Inputs + Inputs + Num_Outputs + Outputs + Locktime. Then I know how to sign via ECDSA, create the DER signatures, etc. That's all no problem.
This 0x40 SIGHASH is causing an issue though. What do I change within the original bitcoin tx to add that 0x40 in there?
I think one thing I have to do, is when getting that double SHA256 hash to sign, instead of adding '00000000' at the end you add '40000000' to get the proper hash to sign. However, what do I change in the DER signature to make this work? At the end of the DER there's a '01' so tried switching that to to 40, and no luck. Tried adding 40 at the end as some docs state, and again no luck.
Any help would be greatly appreciated, as I know this is a 30 second fix that I've already spent 3 days on. Google isn't much help on this one.
submitted by Envrin to Bitcoincash [link] [comments]

[How-To] Crafting an offline TXN with the trezorlib python API

With the rollout of the new 0.12.0 API, I thought it might be time to update some of my old offline_txn scripts. The following is about 80 lines of python that will craft and sign a VERY simple transaction on Testnet.
The new rollout also comes with some new tools. The build_tx.py that is useful in conjunction with the trezorctl sign_tx command.
Both of the methods below will produce a signed TXN that can then be imported into Electrum using the "Tools -> Load transaction -> From text" command.
Note: u/Crypto-Guide has a good walkthrough for installing trezorlib in Windows if you haven't already done that.

Example of using trezorctl btc sign-tx

This example uses the build_tx.py script to build JSON to feed to the sign-tx command. You will need to download the build_tx.py file from github. It is not automatically installed with the trezor package.
```

python build_tx.py | trezorctl btc sign-tx -

Coin name [Bitcoin]: Testnet Blockbook server [btc1.trezor.io]: tbtc1.trezor.io
Previous output to spend (txid:vout) []: e294c4c172c3d87991...060fad1ed31d12ff00:0 BIP-32 path to derive the key: m/84'/1'/0'/0/0 Input amount: 129999866 Sequence Number to use (RBF opt-in enabled by default) [4294967293]: Input type (address, segwit, p2shsegwit) [segwit]:
Previous output to spend (txid:vout) []:
Output address (for non-change output) []: 2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3 Amount to spend (satoshis): 129999706
Output address (for non-change output) []: BIP-32 path (for change output) []: Transaction version [2]: Transaction locktime [0]: Please confirm action on your Trezor device.
Signed Transaction: 0200000000010100ff121dd31ead0f06...f279b642d85c48798685f86200000000 ```

Example of using crafting a TXN using trezorlib directly

If your good with python, or want to see how everything works under the hood, here's 80 lines of python to generate a similar signed transaction.
```python

!/usbin/env python3

[repo] https://github.com/brianddk/reddit ... python/offline_txn.py

[req] pip3 install trezor

from trezorlib import btc, messages as proto, tools, ui from trezorlib import MINIMUM_FIRMWARE_VERSION as min_version from trezorlib.client import TrezorClient from trezorlib.transport import get_transport from trezorlib.btc import from_json from json import loads from decimal import Decimal from sys import exit

Tested with SLIP-0014 allallall seed (slip-0014.md)

User Provided Fields; These are pulled from test scripts

CHANGE THESE!!!

coin = "Testnet"

Get legacy UTXO prev_txn hex from blockbook server. For example:

https://tbtc1.trezor.io/api/tx-specific/ \

e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00

in1_prev_txn_s = '{"txid":' \ '"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00"}'
in1_prev_index = 0 in1_addr_path = "m/84'/1'/0'/0/0" # allallall seed in1_amount = 129999867 out1_address = "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" out1_amount = in1_amount - 192

Defaults

tx_version = 2 tx_locktime = 0 sequence = 4294967293

Code

in1_prev_txn_j = loads(in1_prev_txn_s, parse_float=Decimal) in1_prev_hash = in1_prev_txn_j['txid'] in1_prev_hash_b = bytes.fromhex(in1_prev_hash) device = get_transport() client = TrezorClient(transport=device, ui=ui.ClickUI())
fw_version = (client.features.major_version, client.features.minor_version, client.features.patch_version) if fw_version < min_version[client.features.model]: print("Please flash to the latest FW") exit(1)
signtx = proto.SignTx( version = tx_version, lock_time = tx_locktime )
ins = [proto.TxInputType( address_n=tools.parse_path(in1_addr_path), prev_hash=in1_prev_hash_b, prev_index=in1_prev_index, amount=in1_amount, script_type=proto.InputScriptType.SPENDWITNESS, sequence=sequence )] outs = [proto.TxOutputType( address=out1_address, amount=out1_amount, script_type=proto.OutputScriptType.PAYTOADDRESS )]
txes = None for i in ins: if i.script_type == proto.InputScriptType.SPENDADDRESS: tx = from_json(in1_prev_txn_j) txes = {in1_prev_hash_b: tx} break
_, serialized_tx = btc.sign_tx(client, coin, ins, outs, details=signtx, prev_txes=txes) client.close() print(f'{{"hex": "{serialized_tx.hex()}"}}') ```
From here, you simple take the resultant TXN hex and import it into Electrum using the "Tools -> Load transaction -> From text" clickpath
submitted by brianddk to TREZOR [link] [comments]

Technical: More channel mechanisms!

This is a followup of my older post about the history of payment channel mechanisms.
The "modern" payment channel system is Lightning Network, which uses bidirectional indefinite-lifetime channels, using HTLCs to trustlessly route through the network.
However, at least one other payment channel mechanism was developed at roughly the same time as Lightning, and there are also further proposals that are intended to replace the core payment channel mechanism in use by Lightning.
Now, in principle, the "magic" of Lightning lies in combining two ingredients:
  1. Offchain updateable systems.
  2. HTLCs to implement atomic cross-system swaps.
We can replace the exact mechanism implementing an offchain updateable system. Secondly we can replace the use of HTLCs with another atomic cross-system swap, which is what we would do when we eventually switch to payment points and scalars from payment hashes and preimages.
So let's clarify what I'll be discussing here:
Now I might use "we" here to refer to what "we" did to the design of Bitcoin, but it is only because "we" are all Satoshi, except for Craig Steven Wright.
So, let's present the other payment channel mechanisms. But first, a digression.

Digression: the new nSequence and OP_CHECKSEQUENCEVERIFY

The new relative-timelock semantics of nSequence.
Last time we used nSequence, we had the unfortunate problem that it would be easy to rip off people by offering a higher miner fee for older state where we own more funds, then convince the other side of the channel to give us goods in exchange for a new state with tiny miner fees, then publish both the old state and the new state, then taunt the miners with "so which state is gonna earn you more fees huh huh huh?".
This problem, originally failed by Satoshi, was such a massive facepalm that, in honor of miners doing the economically-rational thing in the face of developer and user demands when given a non-final nSequence, we decided to use nSequence as a flag for the opt-in replace-by-fee.
Basically, under opt-in replace-by-fee, if a transaction had an nSequence that was not 0xFFFFFFFF or 0xFFFFFFFE, then it was opt-in RBF (BIP125). Because you'd totally abuse nSequence to bribe miners in order to steal money from your bartender, especially if your bartender is not a werebear.
Of course, using a 4-byte field for a one-bit flag (to opt-in to RBF or not) was a massive waste of space, so when people started proposing relative locktimes, the nSequence field was repurposed.
Basically, in Bitcoin as of the time of this writing (early 2020) if nSequence is less than 0x80000000 it can be interpreted as a relative timelock. I'll spare you the details here, BIP68 has them, but basically nSequence can indicate (much like nLockTime) either a "real world" relative lock time (i.e. the output must have been confirmed for X seconds before it can be spent using a transaction with a non-zero nSequence) or the actual real world, which is measured in blocks (i.e. the output must have been confirmed for N blocks before it can be spent using a transaction with a non-zero nSequence). Of course, this is the Bitcoin universe and "seconds" is a merely human delusion, so we will use blocks exclusively.
And similarly to OP_CHECKLOCKTIMEVERIFY, we also added OP_CHECKSEQUENCEVERIFY in BIP112. This ensures that the nSequence field is a relative-locktime (i.e. less than 0x80000000) and that it is the specified type (block-based or seconds-based) and that it is equal or higher to the specified minimum relative locktime.
It is important to mention the new, modern meaning of nSequence, because it is central to many of the modern payment channel mechanisms, including Lightning Poon-Dryja.
Lessons learned?

Decker-Wattenhofer "Duplex Micropayment Channels"

Mechanisms-within-mechanisms for a punishment-free bidirectional indefinite-lifetime payment channel.
The Decker-Wattenhofer paper was published in 2015, but the Poon-Dryja "Lightning Network" paper was published in 2016. However, the Decker-Wattenhofer paper mentions the Lightning mechanism, specifically mentioning the need to store every old revocation key (i.e. the problem I mentioned last time that was solved using RustyReddit shachains). Maybe Poon-Dryja presented the Lightning Network before making a final published paper in 2016, or something. Either that or cdecker is the Bitcoin time traveler.
It's a little hard to get an online copy now, but as of late 2019 this seems to work: copy
Now the interesting bit is that Decker-Wattenhofer achieves its goals by combining multiple mechanisms that are, by themselves, workable payment channel mechanisms already, except each has some massive drawbacks. By combining them, we can minimize the drawbacks.
So let's go through the individual pieces.

Indefinite-lifetime Spilman channels

As mentioned before, Spilman channels have the drawback that they have a limited lifetime: the lock time indicated in the backoff transaction or backoff branch of the script. However, instead of an absolute lock time, we can use a relative locktime.
In order to do so, we use a "kickoff" transaction, between the backoff transaction and the funding transaction. Our opening ritual goes this way, between you and our gender-neutral bartender-bancho werebear:
  1. First, you compute the txid for the funding transaction and the kickoff transaction. The funding transaction takes some of your funds and puts it into a 2-of-2 between you and the bartender, and the kickoff is a 1-input 1-output transaction that spends the funding transaction and outputs to another 2-of-2 between you and the bartender.
  2. Then, you generate the backoff transaction, which spends the kickoff transaction and returns all the funds to you. The backoff has a non-zero nSequence, indicating a delay of a number of blocks agreed between you, which is a security/convenience tradeoff parameter
  3. You sign the backoff transaction, then send it to the bartender.
  4. The bartender signs the backoff, and gives back the fully-signed transaction to you.
  5. You sign the kickoff transaction, then send it to the bartender.
  6. The bartender signs the kickoff, and gives it back to you fully signed.
  7. You sign and broadcast the funding transaction, and both of you wait for the funding transaction to be deeply confirmed.
The above setup assumes you're using SegWit, because transaction malleability fix.
At any time, either you or the bartender can broadcast the kickoff transaction, and once that is done, this indicates closure of the channel. You do this if you have drunk enough alcoholic beverages, or the bartender could do this when he or she is closing the bar.
Now, to get your drinks, you do:
  1. Sign a transaction spending the kickoff, and adding more funds to the bartender, to buy a drink. This transaction is not encumbered with an nSequence.
  2. Hand the signed transaction to the bartender, who provides you with your next drink.
The channel is closed by publishing the kickoff transaction. Both of you have a fully-signed copy of the kickoff, so either of you can initiate the close.
On closure (publication and confirmation of the kickoff transaction), there are two cases:
  1. You fail to pick up any chicks at the bar (I prefer female humans of optimum reproductive age myself rather than nestling birds, but hey, you do you) so you didn't actually spend for drinks at all. In this case, the bartender is not holding any transactions that can spend the kickoff transaction. You wait for the agreed-upon delay after the kickoff is confirmed, and then publish the backoff transaction and get back all the funds that you didn't spend.
  2. You spend all your money on chicks and end up having to be kicked into a cab to get back to your domicile, because even juvenile birds can out-drink you, you pushover. The bartender then uses the latest transaction you gave (the one that gives the most money to him or her --- it would be foolish of him or her to use an earlier version with less money!), signs it, and broadcasts it to get his or her share of the money from the kickoff transaction.

Decrementing nSequence channels

Enforcing order by reducing relative locktimes.
I believe this to be novel to the Decker-Wattenhofer mechanism, though I might be missing some predecessor.
This again uses the new relative-locktime meaning of nSequence. As such, it also uses a kickoff transaction like the above indefinite-lifetime Spilman channel. Set up is very similar to the setup of the above indefinite-lifetime Spilman channel, except that because this is bidirectional, we can actually have both sides put money into the initial starting backoff transaction.
We also rename the "backoff" transaction to "state" transaction. Basically, the state transaction indicates how the money in the channel is divided up between the two participants. The "backoff" we sign during the funding ritual is now the first state transaction. Both sides keep track of the current state transaction (which is initialized to the first state transaction on channel establishment).
Finally, the starting nSequence of the first state transaction is very large (usually in the dozens or low hundreds of blocks).
Suppose one participant wants to pay the other. The ritual done is then:
  1. A new version of the current state transaction is created with more money in the payee side.
  2. This new version has nSequence that is one block lower than the current state transaction (in practice it should be a few blocks lower, not just one, because sometimes miners find blocks in quick succession).
  3. Both sides exchange signatures for the new state transaction.
  4. Both sides set the new state transaction as the current state transaction that will be the basis for the next payment.
When the channel is closed by publication of the kickoff transaction, then the transaction with the lowest nSequence becomes valid earlier than the other state transactions. This is enough to enforce that the most recent state transaction (the one with the lowest nSequence, and thus the first to become valid) is published.

Mechanism-within-mechanism

Combining the ingredients of the Decker-Wattenhofer Duplex Micropayment Channels concoction.
Of note is that we can "chain" these mechanisms together in such a way that we strengthen their strengths while covering their weaknesses.
A note is that both the indefinite-lifetime nSequence Spilman variant, and the above decrementing nSequence mechanism, both have "kickoff" transactions.
However, when we chain the two mechanisms together, it turns out that the final transaction of one mechanism also serves as the kickoff of the next mechanism in the chain.
So for example, let's chain two of those decrementing nSequence channels together. Let's make them 144 blocks maximum delay each, and decrement in units of 4 blocks, so each of the chained mechanisms can do 37 updates each.
We start up a new channel with the following transactions:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 144, paying to the initial state of the channel.
When we update this channel, we first update the "stage 2" state transaction, replacing it with an nSequence lower by 4 blocks. So after one update our transactions are:
  1. A funding transaction paying to a 2-of-2, confirmed deeply onchain. All other transactions are offchain until closure.
  2. A kickoff transaction spending the funding transaction output, paying to a 2-of-2.
  3. A "stage 1" decrementing nSequence state transaction, spending the kickoff, with current nSequence 144, paying to a 2-of-2.
  4. A "stage 2" decrementing nSequence state transaction, spending the stage 1, with current nSequence 140, paying to the second state of the channel.
The first 3 transactions are the same, only the last one is replaced with a state transaction with lower `nSequence.
Things become interesting when we reach the "stage 2" having nSequence 0. On the next update, we create a new "stage 1", with an nSequence that is 4 lower, and "reset" the "stage 2" back to an nSequence of 144.
This is safe because even though we have a "stage 2" with shorter nSequence, that stage 2 spends a stage 1 with an nSequence of 144, and the stage 1 with nSequence of 140 would beat it to the blockchain first.
This results in us having, not 36 + 36 updates, but instead 36 * 36 updates (1296 updates). 1296 updates is still kinda piddling, but that's much better than just a single-stage decrementing nSequence channel.
The number of stages can be extended indefinitely, and your only drawback would be the amount of blockchain space you'd spend for a unilateral close. Mutual cooperative closes can always shortcut the entire stack of staged transactions and cut it to a single mutual cooperative close transaction.
But that's not all! You might be wondering about the term "duplex" in the name "Duplex Micropayment Channels".
That's because the last decrementing nSequence stage does not hold the money of the participants directly. Instead, the last stage holds two indefinite-lifetime Spilman channels. As you might remember, Spilman channels are unidirectional, so the two Spilman channels represent both directions of the channel. Thus, duplex.
Let's go back to you and your favorite werebear bartender. If you were using a Decker-Wattenhofer Duplex Micropayment Channel, you'd have several stages of decrementing nSequence, terminated in two Spilman channels, a you-to-bartender channel and a bartender-to-you channel.
Suppose that, while drinking, the bartender offers you a rebate on each drink if you do some particular service for him or her. Let us not discuss what service this is and leave it to your imagination. So you pay for a drink, decide you want to get the rebate, and perform a service that the bartender finds enjoyable. So you transfer some funds on the you-to-bartender direction, and then later the bartender transfers some funds in the bartender-to-you channel after greatly enjoying your service.
Suppose you now exhaust the you-to-bartender direction. However, you note that the rebates you've earned are enough to buy a few more drinks. What you do instead is to update the staged decrementing nSequence mechanisms, and recreate the two Spilman directions such that the you-to-bartender direction contains all your current funds and the bartender-to-you direction contains all the bartender's funds. With this, you are now able to spend even the money you earned from rebates. At the same time, even if the staged decrementing nSequence mechanisms only have a few hundred thousand updates, you can still extend the practical number of updates as long as you don't have to reset the Spilman channels too often.

Burchert-Decker-Wattenhofer Channel Factories

Because you like channels so much, you put channels inside channels so you could pay while you pay. I N C E P T I O N
The Decker-Wattenhofer Duplex Micropayment Channels introduced the possibility of nesting a channel mechanism inside another channel mechanism. For example, it suggests nesting a decrementing-nSequence mechanism inside another decrementing-nSequence mechanism, and having as well an unlimited-lifetime Spilman channel at the end. In the Decker-Wattenhofer case, it is used to support the weakness of one mechanism with the strength of another mechanism.
One thing to note is that while the unlimited-lifetime Spilman channel variant used is inherently two-participant (there is one payer and one payee), the decrementing-nSequence channel mechanism can be multiparticipant.
Another thing of note is that nothing prevents one mechanism from hosting just one inner mechanism, just as it is perfectly fine for a Lightning Network channel to have multiple HTLCs in-flight, plus the money in your side, plus the money in the counterparty's side. As these are "just" Bitcoin-enforceable contracts, there is no fundamental difference between an HTLC, and a payment channel mechanism.
Thus the most basic idea of the Burchert-Decker-Wattenhofer Channel Factories paper is simply that we can have a multiparticipant update mechanism host multiple two-party update mechanisms. The outer multiparticipant update mechanism is called a "channel factory" while the inner two-party update mechanisms are called "channels".
The exact mechanism used in the Burchert-Decker-Wattenhofer paper uses several decrementing-nSequence mechanisms to implement the factory, and Decker-Wattenhofer Duplex Micropayment Channels to implement the channel layer.
However, as noted before, there is no fundamental difference between a Poon-Dryja channel and an HTLC. So it is in fact possible to have chained Decker-Wattenhofer decrementing-nSequence mechanisms to implement the factory level, while the channels are simply Poon-Dryja channels.

Conclusion

So this concludes for now an alternative mechanism to the classic Poon-Dryja that Lightning uses. The tradeoffs are significantly different between Decker-Wattenhofer vs Poon-Dryja:

Copyright

Copyright 2020 Alan Manuel K. Gloria. Released under CC-BY.
submitted by almkglor to Bitcoin [link] [comments]

Technical: Upcoming Improvements to Lightning Network

Price? Who gives a shit about price when Lightning Network development is a lot more interesting?????
One thing about LN is that because there's no need for consensus before implementing things, figuring out the status of things is quite a bit more difficult than on Bitcoin. In one hand it lets larger groups of people work on improving LN faster without having to coordinate so much. On the other hand it leads to some fragmentation of the LN space, with compatibility problems occasionally coming up.
The below is just a smattering sample of LN stuff I personally find interesting. There's a bunch of other stuff, like splice and dual-funding, that I won't cover --- post is long enough as-is, and besides, some of the below aren't as well-known.
Anyway.....

"eltoo" Decker-Russell-Osuntokun

Yeah the exciting new Lightning Network channel update protocol!

Advantages

Myths

Disadvantages

Multipart payments / AMP

Splitting up large payments into smaller parts!

Details

Advantages

Disadvantages

Payment points / scalars

Using the magic of elliptic curve homomorphism for fun and Lightning Network profits!
Basically, currently on Lightning an invoice has a payment hash, and the receiver reveals a payment preimage which, when inputted to SHA256, returns the given payment hash.
Instead of using payment hashes and preimages, just replace them with payment points and scalars. An invoice will now contain a payment point, and the receiver reveals a payment scalar (private key) which, when multiplied with the standard generator point G on secp256k1, returns the given payment point.
This is basically Scriptless Script usage on Lightning, instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).

Advantages

Disadvantages

Pay-for-data

Ensuring that payers cannot access data or other digital goods without proof of having paid the provider.
In a nutshell: the payment preimage used as a proof-of-payment is the decryption key of the data. The provider gives the encrypted data, and issues an invoice. The buyer of the data then has to pay over Lightning in order to learn the decryption key, with the decryption key being the payment preimage.

Advantages

Disadvantages

Stuckless payments

No more payments getting stuck somewhere in the Lightning network without knowing whether the payee will ever get paid!
(that's actually a bit overmuch claim, payments still can get stuck, but what "stuckless" really enables is that we can now safely run another parallel payment attempt until any one of the payment attempts get through).
Basically, by using the ability to add points together, the payer can enforce that the payee can only claim the funds if it knows two pieces of information:
  1. The payment scalar corresponding to the payment point in the invoice signed by the payee.
  2. An "acknowledgment" scalar provided by the payer to the payee via another communication path.
This allows the payer to make multiple payment attempts in parallel, unlike the current situation where we must wait for an attempt to fail before trying another route. The payer only needs to ensure it generates different acknowledgment scalars for each payment attempt.
Then, if at least one of the payment attempts reaches the payee, the payee can then acquire the acknowledgment scalar from the payer. Then the payee can acquire the payment. If the payee attempts to acquire multiple acknowledgment scalars for the same payment, the payer just gives out one and then tells the payee "LOL don't try to scam me", so the payee can only acquire a single acknowledgment scalar, meaning it can only claim a payment once; it can't claim multiple parallel payments.

Advantages

Disadvantages

Non-custodial escrow over Lightning

The "acknowledgment" scalar used in stuckless can be reused here.
The acknowledgment scalar is derived as an ECDH shared secret between the payer and the escrow service. On arrival of payment to the payee, the payee queries the escrow to determine if the acknowledgment point is from a scalar that the escrow can derive using ECDH with the payer, plus a hash of the contract terms of the trade (for example, to transfer some goods in exchange for Lightning payment). Once the payee gets confirmation from the escrow that the acknowledgment scalar is known by the escrow, the payee performs the trade, then asks the payer to provide the acknowledgment scalar once the trade completes.
If the payer refuses to give the acknowledgment scalar even though the payee has given over the goods to be traded, then the payee contacts the escrow again, reveals the contract terms text, and requests to be paid. If the escrow finds in favor of the payee (i.e. it determines the goods have arrived at the payer as per the contract text) then it gives the acknowledgment scalar to the payee.

Advantages

Disadvantages

Payment decorrelation

Because elliptic curve points can be added (unlike hashes), for every forwarding node, we an add a "blinding" point / scalar. This prevents multiple forwarding nodes from discovering that they have been on the same payment route. This is unlike the current payment hash + preimage, where the same hash is used along the route.
In fact, the acknowledgment scalar we use in stuckless and escrow can simply be the sum of each blinding scalar used at each forwarding node.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

Short ELI5 text for gift of bitcoin

Greetings:

I am a true believer in the blockchain, and believe it may become something much greater 20+ years down the road. My best friend has a ton of offspring, and I have none (and plan to have none). I intend to give each of their children $100 worth of bitcoin in today's value in the form of a metal offline wallet (I have access to a nifty metal engraver).

They will be given the public key only, and a note. The note is what I need help with. My intention is to describe to them that they will receive the private key on their 18th birthday, and until then they are free to check their balance or add to it. I intend to include extra incentive to HODL, in that if after their 18th birthday and receipt of the private key they do not transfer any bitcoin from the wallet, from time to time on Birthdays and such I might deposit more bitcoin. However the moment any transfer out of the wallet occurs, all future new deposits from me will stop.

The goal here is to use bitcoin to get them interested in investing in their future (we also talk a lot about traditional FIAT investing and retirement planning).

The main part I need help with is how to keep a description of bitcoin/blockchain technology and how it relates to traditional value holders, and the importance of long-term gain possibilities, while also explaining the volatility and potential for it to drop to zero some day (e.g., the risk). I can explain all of this to someone but it takes me several paragraphs, I'm long-winded. I'm trying to get this boiled down to 3-4 sentences so it fits in a greeting card, and also simple enough for a 10-12 year old to understand it.

Help please. :)
submitted by gh2222 to Bitcoin [link] [comments]

You can call you a Bitcoiner if you know/can explain these terms...

03/Jan/2009
10 Minutes
10,000 BTC Pizza
2016 Blocks
21 Million
210,000 Blocks
51% Attack
Address
Altcoin
Antonopoulos
Asic
Asic Boost
Base58
Batching
Bech32
Bit
Bitcoin Cash
Bitcoin Improvement Proposal (BIP)
Bitcoin SV
Bitmain
Block
Block height
Block reward
Blockchain
Blockexplorer
Bloom Filter
Brain Wallet
Buidl
Change Address
Child pays for parent (CPFP)
Coinbase (not the exchange)
CoinJoin
Coinmarketcap (CMC)
Colored Coin
Confirmation
Consensus
Custodial Wallet
Craig Wright
David Kleinman
Difficulty
Difficulty adjustment
Difficulty Target
Dogecoin
Dorian Nakamoto
Double spend
Elliptic Curve Digital Signature Algorithm (ECDSA)
Ethereum
Faketoshi
Fork
Full Node
Gavin Andresen
Genesis Block
Getting goxed
Halving
Hard Fork
Hardware Wallet
Hash
Hashing
Hierarchical Deterministic (HD) Wallet
Hodl
Hot Wallet
Initial Coin Offering (ICO)
Initial Exchange Offering (IEO)
Ledger
Light Node
Lightning
Litecoin
Locktime
Mainnet
Malleability
Master Private Key
Master Public Key
Master Seed
mBTC
Mempool
Merkle Tree
Mining
Mining Farm
Mining Pool
Mixing
MtGox
Multisig
Nonce
Not your keys,...
Opcode
Orphan block
P2PKH
P2SH
Paper Wallet
Peers
Pieter Wuille
Premining
Private key
Proof of Stake (PoS)
Proof of Work (PoW)
Pruning
Public key
Pump'n'Dump
Replace by Fee (RBF)
Ripemd160
Roger Ver
sat
Satoshi Nakamoto
Schnorr Signatures
Script
Segregated Witness (Segwit)
Sha256
Shitcoin
Sidechain
Signature
Signing
Simplified Payment Verification (SPV)
Smart Contract
Soft Fork
Stratum
Syncing
Testnet
Transaction
Transaction Fees
TransactionId (Txid)
Trezor
User Activated Soft Fork (UASF)
Utxo
Wallet Import Format (WIF)
Watch-Only Address
Whitepaper
List obviously not complete. Suggestions appreciated.
Refs:
https://bitcoin.org/en/developer-glossary https://en.bitcoin.it/wiki/Main_Page https://www.youtube.com/channel/UCgo7FCCPuylVk4luP3JAgVw https://www.youtube.com/useaantonop
submitted by PolaT1x to Bitcoin [link] [comments]

I found a $600k BCH theft that has gone unnoticed

Hello all, I'm (among other things) a graduate student getting a master's degree in cybersecurity. This last quarter for one of my classes, I was tasked to examine and recreate an exploit. For the actual exploit I was examining the "anyone can spend" segwit addresses on the BCH chain, and in my research I found a $600k theft that seems to have gone completely unnoticed.
You all might recall this $600k theft of segwit addresses, but it happened again in mid-February 2018 and there has been zero news about it.
BCH block 517171 contains solely segwit-stealing transactions. If you look at any given transaction, the inputs are all segwit program hashes spending a P2SH segwit output. I only caught it by accident, as I was originally going to talk about the publicized November attack.
The interesting thing I discovered about this was that it's harder to have stolen that segwit money than most people think. Both Unlimited and ABC nodes do not relay segwit-spending transactions, and Bitcoin ABC hard-coded in fRequireStandard, so you couldn't even force-relay them with a conf option. On top of that, miners keep their node IPs private for obvious avoiding-ddos-and-sybil-attack reasons, which means it's impossible to directly send transactions to miners. This means that the only way to actually execute this attack was to setup one's own mining pool running on a custom-modified client to allow non-standard transactions. Then you'd have to get enough hash power to mine a block yourself. I estimated the cost of renting enough hash power to do this at the time as around $30k-$60k to have a greater than 90% chance of mining a block within a 3 month window.
In order to simulate the attack, I spun up BTC, LTC, and BCH nodes in Docker, and wrote a Python script. The Python script started at segwit activation on BTC and LTC and it scanned every transaction in every block looking for P2SH segwit inputs as well as native segwit outputs, since these are the necessary hash pre-images to spend P2SH segwit money on the BCH chain. The script then also scanned the BCH chain for any native segwit outputs, as well as recording all P2SH outputs. (This was all saved in a MySQL database.) Then, at any point in time, I could simply query for BCH unspent native segwit outputs as well as P2SH outputs for which I had a known segwit hash pre-image. (If this was an attack I was doing real-time, I would probably also have a large mempool on each node and monitor unconfirmed tx's for useful info as well, but since this was after the fact, I just queried blocks sequentially.)
For the mining node that runs the pool, it would need to be firewalled behind (i.e. only connected to) an unmodified node in blocks-only mode, so that the segwit hash pre-images aren't transmitted out to the network, and so that no other unconfirmed transactions are transmitted in to the mining node. (The mining node should only be filling its block with segwit tx's in order to maximize the gain from the attack.)
Then a script should run continuously to grab segwit utxos from the MySQL database and construct high-fee transactions to send directly to the mining node. Unlike the November attack, each input should be spent in its own individual transaction, so that in the event it is individually spent, I don't negate a tx with other inputs. The overhead on having different transactions for each input is only about 8 extra bytes (the tx version and the locktime), so I think this is a good trade-off.
Then, the attacker simply rents hashing power and points it at his secret pool.
By the time February rolled around and the attack happened, my MySQL database had about 40 million BCH P2SH outputs and each query took about 3 minutes to execute. This of course would have been fine in the 10-minute block world of Bitcoin and BCH, but it means that I stopped my Python script after that time, so I don't know about any possible other attacks that happened before the clean stack rule was hard-forked into BCH.
It was pretty interesting to work through how this attack must have happened, and it was significantly harder to execute than I thought it would be given that all the money was "anyone can spend".
However, the most interesting thing about all this is that nobody has noticed. There is literally no news or mention of block 517171 or any of the transactions in it. My theory is that it is money that nobody misses -- i.e. misprogrammed custom wallet software for BTC nodes accidentally also sent out BCH transactions to the same address, given that BTC and BCH shared the same history until August 2017. And whatever person or entity is running those nodes is only thinking about BTC money and is completely oblivious to its misprogrammed problem of shipping BCH to segwit P2SH addresses.
Obviously, that's just a theory, but I think it's pretty reasonable. Given the intense community divide, I think it's very possible that a number of BTC users simply ignored money on the BCH chain, even though it's "free money" for them, simply out of ideological hatred.
Whatever the case, nobody has posted anywhere complaining of money stolen in that block. It seems to have gone completely unnoticed. (Which is why I'm posting this.) It was an interesting case study and I'd be curious to hear if anybody has any addition information or thoughts about it. I believe this was a different person than the November theft, because the way it was done was different -- the November theft had all the money in one transaction, but this February theft was done with separate individual transactions. Additionally worth noting is that the address which received the bulk of the money is still active, which means they're still out there.
Anyway, I thought this was interesting and worth posting.
submitted by exmachinalibertas to btc [link] [comments]

node information on explorers

I'm trying to set my first c-lightning node with docker-compose using image from https://hub.docker.com/elementsproject/lightningd. currently, my node can connect and open channel with other nodes (and I can open a channel to the node just fine), but it's still not updated (ie. has no information) on most explorers.
the following is result of getinfo and listconfigs
getinfo { "id": "03db40337c2de299a8fa454fdf89d311615d50a27129d43286696d9e497b2b027a", "alias": "TestName", "color": "fff000", "num_peers": 3, "num_pending_channels": 0, "num_active_channels": 3, "num_inactive_channels": 0, "address": [ { "type": "ipv4", "address": "68.183.195.14", "port": 9735 } ], "binding": [ { "type": "ipv4", "address": "172.18.0.3", "port": 9735 } ], "version": "v0.7.1-906-gf657146", "blockheight": 601917, "network": "bitcoin", "msatoshi_fees_collected": 0, "fees_collected_msat": "0msat" } listconfigs { "# version": "v0.7.1-906-gf657146", "lightning-dir": "/root/.lightning", "wallet": "sqlite3:///root/.lightning/lightningd.sqlite3", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/pay", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/autoclean", "plugin": "/uslocal/bin/../libexec/c-lightning/plugins/fundchannel", "network": "bitcoin", "allow-deprecated-apis": true, "always-use-proxy": false, "daemon": "false", "rpc-file": "lightning-rpc", "rgb": "fff000", "alias": "HubTest", "bitcoin-rpcuser": [redacted], "bitcoin-rpcpassword": [redacted], "bitcoin-rpcconnect": "bitcoind", "bitcoin-retry-timeout": 60, "pid-file": "lightningd-bitcoin.pid", "ignore-fee-limits": false, "watchtime-blocks": 144, "max-locktime-blocks": 2016, "funding-confirms": 3, "commit-fee-min": 200, "commit-fee-max": 2000, "commit-fee": 500, "cltv-delta": 14, "cltv-final": 10, "commit-time": 10, "fee-base": 0, "rescan": 15, "fee-per-satoshi": 1, "max-concurrent-htlcs": 30, "min-capacity-sat": 10000, "bind-addr": "172.18.0.3:9735", "announce-addr": "68.183.195.14:9735", "offline": "false", "autolisten": true, "disable-dns": "false", "enable-autotor-v2-mode": "false", "encrypted-hsm": false, "log-level": "DEBUG", "log-prefix": "lightningd(7):" } 
is there something wrong with this configuration? or is it another issue?
I understand that explorers update their node list irregularly, and as far as the node can open channels (and can be connected), everything is fine. but this thing has bugging me for weeks.
thank you~
edit=c-lightning
submitted by 17hubest to lightningnetwork [link] [comments]

The Bitcoin Foundation - YouTube Lock down me baad .me Sanitizer Door lock lock 1 ADA price explosion! + BTC Options strategy to lock in 70-81% profit (18-month time horizon)

Bitcoin’s time locks are powerful tools, but can be confusing. Here’s a quick list of important things to remember: OPs go in scripts. “Locktime” means absolute. “Sequence” means relative. Locktime Decimal Descrpition; 0xede80600: 452845: This transaction could only be relayed on the network after the blockchain reached a height of 452,845.(0x06241559: 1494557702: This is Fri, 12 May 2017 02:55:02 in Unix Time. The transaction could only be relayed on the network after the median time of the last 11 blocks (according to the time field in their block headers) is greater than this. The Bitcoin transaction lock time is the time at which a particular transaction can be added to the blockchain.This is the earliest time that miners can include the transaction in their hashing of the Merkle root to attach it in the latest block to the blockchain.. There are two specific types of transaction locktime. Some of the regularly used Bitcoin wallets, for example, the Bitcoin Core wallet and the Electrum Bitcoin Wallet, set the locktime of newly constructed transactions to the current block height. This is as an anti-fee-sniping measure and visible as a stair-like pattern when plotting time-locked transactions by their mempool arrival time and locktime. The plot, however, reveals transactions time A Timelock is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height. Timelocks feature prominently in many Bitcoin smart contracts, including payment channels and hashed timelock contracts.It can also be used to lock-up bitcoins held as an investment for a period of months or years.

[index] [17024] [4593] [7172] [2270] [18645] [5644] [20485] [27049] [15303] [21496]

The Bitcoin Foundation - YouTube

The Rise and Rise of Bitcoin YouTube Movies. 2014 · Documentary; 1:36:08. Barber belittled by CNN's Brooke Baldwin returns to 'Tucker Carlson Tonight' - Duration: 6:47. ADA price explosion! + BTC Options strategy to lock in 70-81% profit (18-month time horizon) #Cryptocurrency #Bitcoin #Ethereum #XRP #ADA #Digital Assets #Macroeconomics #Staking #BTC #ETH #Ripple ... Shakuntala Devi - Official Trailer Vidya Balan, Sanya Malhotra Amazon Prime Video July 31 - Duration: 2:48. Amazon Prime Video India 5,608,947 views. New Banking on Bitcoin YouTube Movies. 2017 · Documentary; 1:23:41. Ghislaine Maxwell reportedly ready to name names - Duration: 6:59. Fox News 3,721,778 views. 6:59. Sagittarius! Winning the Lottery ... Banking on Bitcoin YouTube Movies. 2017 · Documentary; 1:23:41. TOP 20 ACOUSTIC GUITAR INTROS OF ALL TIME - Duration: 13:59. Rick Beato Recommended for you. 13:59.

Flag Counter