Bitcoin Forum

This is goooood news..

As of the release of Core 0.11.2 OP_CHECKLOCKTIMEVERIFY is now becoming a reality.

This has major implications, as it means that REFUND TXNs now work. Without having to worry about TXN malleability.

So that lots and lots of clever smart contracts can be written and used, that were more like fantasy stories a mere couple of months ago..

For me, the BIG ONE, is Atomic Cross Chain Transfers.

We can now finally see the light at the end of the 'Trust-Free 100%-Secure Crypto-Exchange' tunnel. (Crypto, not FIAT, as FIAT always requires trust)

Lots of other uses too. (Lightning Network is another..)

..

Just wanted to pass that info on..  ;D

yep, when i have tested the RC1 of 0.11.2 ... i have many cscript blocked on the debug.log (i have a mining device).

Would this be compatible with coins currently supporting AT, such as Qora (https://bitcointalk.org/index.php?topic=1015379.0) and Burst (https://bitcointalk.org/index.php?topic=731923.0)?  They can already do atomic cross chain transfers directly from one blockchain to the other without an exchange, but I don't know if it's done via a different method.  I can grasp enough to understand vaguely how Automated Transactions work, but not the technical inner workings and whether it uses OP_CHECKLOCKTIMEVERIFY or not.  Would be amazing if I could trade Between BTC/Qora/Burst without relying on an intermediary.

Absolutely.

The ACCT 'trick' involves revealing the preimage of a hash value. (show you know the value that hashes to a value locked in the smart contract.)

Looking at https://ciyam.org/at/at_atomic.html that is exactly how AT does it as well.

CIYAM ?

I don't see this big news. Its actually bad, you never know if there are some "paused" coins spent.
This can give heads-up to some traders, and some will be unaware :/
Thats pretty sad day

I don't follow you. What do you mean ?

The coins are sent to a multi-sig contract that can refund you at a future time. You can't spend the coins once you have initiated the procedure (sent them to the multi-sig contract).

The only 'issue' is if one party refuses to complete the trade (refuses to sign the multi-sig txn), in which case the coins will be refunded.

You probably shouldn't say "refund" txs, it is more like escrow, and when the terms are not fulfilled, it is returned to you.
Refund makes it sound more like on-the-spot return.

But anyway this is great news. Many new features and companies will come from this.

Yes - if it works with an SHA256 hash then it would be compatible with AT.

EDIT: To clarify if a "Bitcoin script" is written that works by checking a secret then it would be compatible with the Atomic Cross-Chain Transfer AT although it is not clear to me how OP_CHECKLOCKTIMEVERIFY is really going to help (as it just prevents an output from being spendable for X blocks).

Fantastic news.  Qora and Burst are so undervalued at the moment, so the fact that they're pretty much all set to go for Atomic Cross Chain Transfers while other coins will be playing catch up is a definite buy signal for me.  Time to increase some holdings while it's cheap!

I think it will take a bit of time until all those mainstream companies realize any of this. I mean the average guy who is involved in here in this forum probably doesn't know what stuff like OP_CHECKLOCKTIMEVERIFY does, let alone people outside the Bitcoin ecosystem. This is good news for us because I dont want an higher price just yet.

He meant to get paid for his ad-sig

I'm afraid that I didn't understand. What does it actually mean ? You could buy altcoins directly from Bitcoin Core ? How could it be organised ? It seems unrealistic for me.

Awesome news, indeed!

When will it be activated? It requires a fork it seems.

The announcement says it's been activated already, but I think it needs a mountain of other changes to be fully usable. The technical details in the announcement aren't easy to understand, but I interpreted it as saying lock timed transactions can't be put into a block or the mempool until after the lock time's up. If my interpretation's right that will need changing before OP_CHECKLOCKTIMEVERIFY becomes fully usable.

https://bitcoin.org/en/release/v0.11.2

Here's another thread. It explains some more: https://bitcointalk.org/index.php?topic=1101437.20

After reading about CLTV (a fairly simple explanation of it can be found here: https://bitcoinmagazine.com/articles/checklocktimeverify-or-how-a-time-lock-patch-will-boost-bitcoin-s-potential-1446658530) I have worked out how to tie it to the ACCT AT implementation and the workflow is as follows (assuming that Alice and Bob have decided that they are wanting to exchange 100 ATC for 0.001 BTC respectively and assuming fees have been added as appropriate for each blockchain):

Alice creates an ACCT AT to transfer 100 ATC to Bob (locked by a "secret" and with an automatic refund after 24 hours).

Alice gives Bob a BTC public key and then Bob then creates a Bitcoin 2 of 2 multi-sig address and sends 0.001 BTC to it with a special P2SH script.

The first part of this script requires Alice's signature plus a secret and the second part only requires Bob's signature but is CLTV locked for 12 hours.

Assuming both parties are happy (say after 6 confirmations) then Alice will send a tx that contains the secret in order to move the BTC to another address she owns and Bob will send that secret to the ACCT AT to transfer the ATC to his account on the AT supporting blockchain.

If Alice never sends the tx then after 12 hours Bob can simply create a new tx to refund his BTC to another address and of course if Bob never creates the correct Bitcoin tx then Alice will automatically have her ATC refunded after 24 hours (of course 12 and 24 hours could be made smaller if desired).

Although it is a little more tricky on the BTC side, assuming that some software is written to take care of the script and multi-sig address, then it will be entirely possible to exchange BTC for any ATC (such as BURST or QORA) without the need of any 3rd party (although you'd still need to find somewhere to match an order).

Thanks a lot for the explanation!
I really hope that AT finally gets more attention, more coins implementing it and more people using it.

It only prevents malleability once the tx has been confirmed (before it is confirmed it is still potentially malleable although that itself is becoming harder to do due to other changes that have been introduced to prevent it).

The thing is that unlike nLockTime you can have the txid safely confirmed prior to the actual time in question (which is what made trying to do ACCT using nLockTime unpractical which is why projects that had claimed they could do this were actually only working on "testnet").

So I think the Bitcoin script to do an ACCT would look something like this:


although I'm not sure if the above is correct (perhaps someone more familiar with Bitcoin script could provide some feedback).

Admittedly I'm not very well versed with P2SH so I'm not sure exactly how you could get the script that does not contain the <secret> nor public keys to actually work (but I do think this should be possible).

Does bitcoin core allow signing for nonstandard p2sh script? I just tried this and gmaxwell pointed out there are missing templates for these new type of p2sh scripts so you cant sign these new escrow time locked scripts, although you can use an external lib to do this.

Basically, yes.  Once all the foundations are laid, you'd enter your buy/sell order directly through the wallet.  Obviously the user interface in the wallet software will need an update (for any coins that you want to trade between), but that shouldn't be too large a job.  The more tricky part would be the "matchmaking" bit to match a buy/sell order on one blockchain to another, but if it already works between Burst and Qora, then it should be doable in Bitcoin (and any other altcoin that wants to add support for it).  Truly decentralised trading.  The future just gets more and more interesting.  Can't wait to see which currency makes history by being the first to transact directly with the Bitcoin blockchain (hoping it's Qora or Burst, since they've got a good head start). 

Actually with transaction malleability finally being fixed CLTV is more a nice feature than a necessity. Moreover, practical difference is small, because for both features to work, you need both coins (that you want to trade) to implement it.

Grear news! What next?  :)

It would be great is someone could implement FiatCoin (pegged to USD, EUR, GBP, etc.), hopefully without any AML/KYC restrictions (beyond the initial purchase). Then you can truly trade Bitcoins and fiat from your client.

Syscoin does this

Not what I had in mine. The FiatCoin would be unmineable and instead backed by an equivalent amount of fiat. The issuance would be done by a centralized authority (e.g. bank or brokerage, possibly for a small fee) but once issued they may be exchanged freely on a distributed blockchain that is compatible with cross-chain transactions. Mining will be fee based only without block rewards.

if there is the old known governments behind it, how we can think of having those fiatcryptocoin without aml/kyc...we cannot, they must be decentralized like every other crypto

P2SH doesn't fundamentally change script.  It is just another way of encoding everything using a template so that the scriptPubKey is effectively included when spending the coin.

You pay to OP_HASH160 <20-byte-hash-value> OP_EQUAL and the client interprets the hash value as the hash of the actual scriptPubKey you want to use.

Script works with a stack.  For spending, the stack is initialized so that it doesn't result in a failure if the scriptPubKey is executed.

Protocol

Alice picks a random array "secret" and funds this Altcoin transaction.


If Bob knew the secret, he could spend this transaction output with this stack

    <signature using Bob's public key 1> <secret> OP_1

Alice can spend this transaction output with this stack

    <signature using Bob's public key 1> OP_0

OP_0 causes the else branch to execute and Alice doesn't have to provide the secret but she does have to wait 24 hours due to the locktime requirement.

This means that Alice can spend the output in 24 hours if Bob hasn't and Bob can only spend it if he finds out the secret.

Bob funds this output with BTC.


This means that he can get his money back after 12 hours or Alice can spend the output immediately.  If she spends the output, she has to do it before 12 hours has passed.  This means that Bob has another 12 hours to use the secret to spend the first output.

The steps are

1) Alice picks secret and broadcasts her transaction
2) Bob verifies that her transaction is confirmed and then sends his transaction
3) Alice verifies that his transaction is confirmed and then spends his transaction (requires publishing the secret)
4) Bob uses the secret to spend Alice's transaction

To show that it is atomic, you have to show that it can be reversed if anyone refuses to continue.

Bob refuses to complete step 2)

Alice keeps the secret a secret and waits 24 hours to get her money back

Alice refuses to complete step 3)
After 12 hours Bob can recover his money
Alice has to wait 12 more hours to get her money back.  She needs to make sure to keep the secret a secret

Bob refuses to complete step 4)
He only harms himself by doing this.  After the 24 hour lockout, Alice can take back her money.  He needs to make sure to take back his money by then.

-----------------------------------------------------------------

Script execution

This is a step by step guide to the first script, when Bob spends it.

The script is initialized to

    <signature using Bob's public key 1> <secret> OP_1

When OP_IF fires, it will read 1 off the stack and execute the top branch.

    <signature using Bob's public key 1> <secret>

OP_HASH160 will read <secret> off the stack and then place hash(secret) onto the stack.

    <signature using Bob's public key 1> <hash(secret)>

<hash(secret)> will push hash(secret) onto the stack

    <signature using Bob's public key 1> <hash(secret)> <hash(secret)>

OP_EQUALVERIFY makes sure the top 2 elements on the stack match and fails otherwise (and removes them)

    <signature using Bob's public key 1>

<Bob's public key 1> will push Bob's public key 1 onto the stack

    <signature using Bob's public key 1> <Bob's public key 1>

and finally OP_CHECKSIG will verify the signature using the public key (and remove both)

If all goes well, OP_1 will be pushed onto the stack.

This counts as a successful script execution.

Think the closest thing to that at the moment is Tether (https://tether.to/faqs/), USD₮, EUR₮, and JPY₮.  It uses the Omni (formerly Mastercoin) layer.  I've seen USD₮ on the Poloniex exchange, but haven't come across the others.  

As for what's next, hopefully some talented coders start creating stuff to utilise this new feature and wallets start updating their GUIs to handle it.  This will result in increased resistance to regulatory shutdown (exchanges are easy to shut down), increased privacy (no need to register accounts and submit to KYC/AML) and increased security (not relying on third parties to store funds and you'll have full control over private keys for the pairs you're trading in) once it's all up and running.  All things that we should be striving for.

One possible (highly amusing) side-effect of a long-term successful USD crypto-proxy would be if the proxy started to approach the trade volume of and/or circulation velocity of actual Fed USD  :D The crypto copy could usurp the Fed issued version out of existence.  ;D

I feel like a lot of interesting features get lost because you need to be very knowledgeable to take advantage of them. I would like full support for all of this on the GUI.

so basically we have to make banks obsolete using technology and destroy other niche jobs in the process,

I used to not understand a majority of how everything actually worked in crypto land. However, after time, and enough actually wanting to know, I now feel like I have a decent grasp on it, the next step is for me to put it into action and start coding the things I would like to see within BURST, starting with simple tools and going from there.

My point here, is that I truly believe that most people in this forum, aside from the ones here to scam or the ones who don't really care enough to give it their attention, have the capacity to learn what is going on, but no, it is not something you can do unless you're adamant in it, and actually want to.



That being said, I'm 100% sure all of this will be done in a simple to use format with pretty buttons. (How else will any of us get mass adoption? We all know most people's main reason for the internet is Facebook.)

So yea, things take time, in this world things move insanely fast, I'm willing to bet we will start seeing these new additions popping up all over the place very shortly.


@Doom - I also would love to see BURST be the one to do the first with BTC, I think I will go out dev hunting soon, as I know vbcs could do it by himeself, but I think having a few more people to collab with would be great. But QORA will likely want to be the first as well, and seeing as vbcs is more QORA than BURST, maybe we can work out a 3-way scenario? xD. heh.

Actually, the 3-way thing is quite doable.  If both coins are ready in time, you could arrange it so that a Burst/BTC and a Qora/BTC cross chain transaction both make it into the same block on Bitcoin's blockchain.  Then they can take joint credit for being first.      :)

Also, I just realised we'll have Proof of Work, Proof of Stake and Proof of Capacity algorithms all acting in unison for the first time.  How truly momentous.

This would truly be awesome. I think it should be considered, for sure. :)

If anyone with ties to the mining community could give them a nudge to update, that would be great.  We need more version 4 blocks (http://data.bitcoinity.org/bitcoin/block_version/30d?c=block_version&t=a) before OP_CHECKLOCKTIMEVERIFY can come out to play and all of this cross-chain awesomeness can occur.

I found this bitcoinity link that graphically and textually shows how many miners out of the 1000 last blocks were using the necessary updated wallets. It shows we are 49.07% of the way to the threshold needed before OP_CHECKLOCKTIMEVERIFY can be used to start the awesomeness.

http://data.bitcoinity.org/bitcoin/block_version/5y?c=block_version&r=week&t=a

When you say you "found" it, do you mean you didn't see me linking to the same page in the text you just quoted?   :P

51% today, so at least we're half way there.

Sipa created a graph (http://bitcoin.sipa.be/ver-50k.png) which shows the average version number.

It is, finally we can get rid of corrupt exchanges, and scam exchanges.

Tons of scam exchanges just do inside jobs all the time, rigging prices, and more.

Time for trustless systems.