BitIDE - TapScript IDE with Local Testnet, Explorer and Custom Op Codes (P2TR)

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: kesibo on February 11, 2024, 04:15:37 AM

Great this IDE, I was looking for such a program 5 years ago, but could not find it.

I played around with the IDE and it works beautifully. Especially, the 'show all frames' is super helpful.

My question: I want to us HTLC like contracts, and want to use Opcodes "OP_CHECKLOCKTIMEVERIFY" and "OP_CHECKSEQUENCEVERIFY", but I couldn't get these to work. I get the following error:

Code:

[Error: Error: RuntimeError: Error: missing op code OP_CHECKSEQUENCEVERIFY in trace builder]

Furthermore, It would be great to have some more examples such as to create 2 out of 3 lock script etc etc.

Thanks again for this great tool!

Hey there!

We just released support for OP_CHECKSIG and added a wallet/key manager to generate script signatures in v0.8.6, and v0.9.0 should be out later this week with support for OP_CHECKMULTISIG/OP_CHECKMULTISIGVERIFY/OP_CHECKSIGADD/OP_CHECKLOCKTIMEVERIFY/OP_CHECKSEQUENCEVERIFY.

For those interested in test driving OP_CHECKSIG, you can check out this step-by-step video tutorial and update BitIDE as shown below:

Update BitIDE Bitcoin Core Edition:

Code:

docker pull qedprotocol/bitide:latest
docker run -p 1337:1337 -it --rm qedprotocol/bitide:latest

Update BitIDE Liquid Edition:

Code:

docker pull qedprotocol/bitide-liquid:latest
docker run -p 1337:1337 -it --rm qedprotocol/bitide-liquid:latest

Appreciate the feedback and apologize for the incomplete VM implementation, we are closing in on 100% coverage, but still have a few more ops to implement.

kesibo

newbie

Activity: 1

Merit: 0

Great this IDE, I was looking for such a program 5 years ago, but could not find it.

I played around with the IDE and it works beautifully. Especially, the 'show all frames' is super helpful.

My question: I want to us HTLC like contracts, and want to use Opcodes "OP_CHECKLOCKTIMEVERIFY" and "OP_CHECKSEQUENCEVERIFY", but I couldn't get these to work. I get the following error:

Code:

[Error: Error: RuntimeError: Error: missing op code OP_CHECKSEQUENCEVERIFY in trace builder]

Furthermore, It would be great to have some more examples such as to create 2 out of 3 lock script etc etc.

Thanks again for this great tool!

cmpeq

copper member

Activity: 33

Merit: 152

Just released BitIDE 0.7.0 which includes bug fixes and support for Liquid BTC + a new docker image which includes a local Elements 23.2.1 regtest testnet.

To upgrade to the latest version of BitIDE, run:

Code:

docker pull qedprotocol/bitide:latest
docker run -p 1337:1337 -it --rm qedprotocol/bitide:latest

To start a Liquid/Elements regtest + install the Liquid compatible version of BitIDE, run:

Code:

docker pull qedprotocol/bitide-liquid:latest
docker run -p 1337:1337 -it --rm qedprotocol/bitide-liquid:latest

You can also change the vm mode in the web version of BitIDE by selecting "Liquid" in the new IDE Settings tab:

Currently supported Elements/Liquid only op codes:

OP_ADD64
OP_SUB64
OP_DIV64
OP_MUL64
OP_LESSTHAN64
OP_GREATERTHAN64
OP_LESSTHANOREQUAL64
OP_GREATERTHANOREQUAL64
OP_NEG64
OP_SCRIPTNUMTOLE64
OP_LE64TOSCRIPTNUM
OP_LE32TOLE64
OP_OR
OP_XOR
OP_AND
OP_CAT

More will be added soon!

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: vjudeu on January 22, 2024, 12:48:43 AM

Quote

Password Recovery

When it comes to any puzzles, there is for example this puzzle: https://bitcointalksearch.org/topic/bounty-offered-to-crack-the-seeds-for-nist-curves-5469657

And then, people may think, that SHA-1 was used, to create them, and make TapScripts, unspendable by key:

Code:

1) OP_SHA1 <3045ae6fc8422f64ed579528d38120eae12196d5> OP_EQUAL
2) OP_SHA1  OP_EQUAL
3) OP_SHA1  OP_EQUAL
4) OP_SHA1  OP_EQUAL
5) OP_SHA1  OP_EQUAL

Imagine, how the person solving that would feel, if it would turn out, that those coins are unspendable, because of the wrong endianness.

So, instead of using unspendable key-path, it can be just "multisig behind all interested parties". It is possible to start with a single key, just like the creator of the famous puzzle, where keys #120 and #125 are sweeped, but nobody knows, if those keys are really broken, or if the author just moved those funds.

And if you have any kind of reward, then by using multisig, you can start with a single key, and then move those coins by key, to combine the same rewards into bigger coins. Which means, if Alice and Bob sent funds to some different keys, with the same attached TapScript, then they could move them to a multisig, and a TapScript. And that move may be more attractive to the puzzle solver, because having single coin is cheaper to move, than having thousands of small deposits (not to mention address reuse, which is a bad practice, and should be avoided).

Quote

Recursive Covenants + Trustless peg-in/peg-out for layer 2s

If you have more than one person, behind some coin, then it may be possible, that all of them will be online. In that case, there is no reason to use expensive TapScript path, and reveal the whole covenant on-chain. The group, which wants to be detached, can just propose a withdrawal transaction, and collect all signatures from all parties, and then it will look the same, as if everything would be owned by a single user.

To sum up: I cannot see a reason, why not to use multisig. If you are alone, then it gives you a chance to experiment with TapScript, without trapping your coins in unspendable paths. If there are at least two people (for example: Alice tells Bob that she will pay for Password Recovery), then, 2-of-2 multisig is applicable. If there are more than two people, then N-of-N multisig is applicable in a general case.

And then, for example if Bob cannot provide the password, Alice can say: "well, you tried cracking it for 10 years, and you failed, it is now useless information for me, so I sweep my funds, you don't have to work longer on that". And if Bob agrees, then it is at least possible for Alice to get her funds back. But if it is behind TapScript-only, then it may be unspendable forever. Also, there are obvious mistakes possible, for example wrong endianness, and then, key-path can be used to fix those cases, instead of losing coins forever.

Quote from: vjudeu on January 22, 2024, 12:48:43 AM

So, instead of using unspendable key-path, it can be just "multisig behind all interested parties".

Totally agree!
I think the rule of thumb is: use a multisig if you know the interested parties ahead of time, otherwise use NUMS.
For the example of the puzzle/hash cracking, one may have to spend a significant portion of time/compute to crack the hash, so if they original challenge holder can just transfer away the funds at will, it may be a disincentive to commit resources to the problem.

In the case of the layer 2, I would push back, however. To be secure, the multisig should be controlled by the owners of layer 2 wrapped BTC so they can reclaim the BTC on Layer 1 back whenever they like. This is impossible if the layer 2 BTC is transferrable.

Consider the following scenario:
3 bitcoin holders each bridge 10 BTC to layer 2, locking a total of 30 BTC in a multisig (lets call the set of keys in the multisig K), minting a total 30 l2BTC on the layer 2. Since the K should proportionally represent owners of l2BTC, they should each control a key in the multisig. The 3 original users then purchase NFTs on the L2 with their l2BTC on an L2-DEX, spending all 30 BTC. Now the original set K does not represent the token holders and is instead controlled by a group which owns no l2BTC.

vjudeu

copper member

Activity: 903

Merit: 2248

Quote

Password Recovery

When it comes to any puzzles, there is for example this puzzle: https://bitcointalksearch.org/topic/bounty-offered-to-crack-the-seeds-for-nist-curves-5469657

And then, people may think, that SHA-1 was used, to create them, and make TapScripts, unspendable by key:

Code:

1) OP_SHA1 <3045ae6fc8422f64ed579528d38120eae12196d5> OP_EQUAL
2) OP_SHA1  OP_EQUAL
3) OP_SHA1  OP_EQUAL
4) OP_SHA1  OP_EQUAL
5) OP_SHA1  OP_EQUAL

Imagine, how the person solving that would feel, if it would turn out, that those coins are unspendable, because of the wrong endianness.

So, instead of using unspendable key-path, it can be just "multisig behind all interested parties". It is possible to start with a single key, just like the creator of the famous puzzle, where keys #120 and #125 are sweeped, but nobody knows, if those keys are really broken, or if the author just moved those funds.

And if you have any kind of reward, then by using multisig, you can start with a single key, and then move those coins by key, to combine the same rewards into bigger coins. Which means, if Alice and Bob sent funds to some different keys, with the same attached TapScript, then they could move them to a multisig, and a TapScript. And that move may be more attractive to the puzzle solver, because having single coin is cheaper to move, than having thousands of small deposits (not to mention address reuse, which is a bad practice, and should be avoided).

Quote

Recursive Covenants + Trustless peg-in/peg-out for layer 2s

If you have more than one person, behind some coin, then it may be possible, that all of them will be online. In that case, there is no reason to use expensive TapScript path, and reveal the whole covenant on-chain. The group, which wants to be detached, can just propose a withdrawal transaction, and collect all signatures from all parties, and then it will look the same, as if everything would be owned by a single user.

To sum up: I cannot see a reason, why not to use multisig. If you are alone, then it gives you a chance to experiment with TapScript, without trapping your coins in unspendable paths. If there are at least two people (for example: Alice tells Bob that she will pay for Password Recovery), then, 2-of-2 multisig is applicable. If there are more than two people, then N-of-N multisig is applicable in a general case.

And then, for example if Bob cannot provide the password, Alice can say: "well, you tried cracking it for 10 years, and you failed, it is now useless information for me, so I sweep my funds, you don't have to work longer on that". And if Bob agrees, then it is at least possible for Alice to get her funds back. But if it is behind TapScript-only, then it may be unspendable forever. Also, there are obvious mistakes possible, for example wrong endianness, and then, key-path can be used to fix those cases, instead of losing coins forever.

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: ercewubam on January 21, 2024, 10:23:15 AM

Quote

For situations where a multisig is appropriate

Could you give any example, where it is not?

1. Password Recovery
Let's say I want to crack a sha256 password hash (your own personal password and not someone else's, of course).
If know the hash is 5bf01f36fa15d5ccf2dea7a53c777426d559a9a8d1384e58bc8d3dc423cd2f12, I could offer a reward in bitcoin for anyone who can provide the preimage to the password with the following script:

Code:

OP_SHA256
<5bf01f36fa15d5ccf2dea7a53c777426d559a9a8d1384e58bc8d3dc423cd2f12>
OP_EQUAL

You can try it out if you like on testnet (the password is supersecretpassword)

2. Recursive Covenants + Trustless peg-in/peg-out for layer 2s
Imagine we have a layer 2 which posts a withdrawals tree of the chain to bitcoin, and we want to allow users to trustlessly withdraw their bitcoins from layer 2.
When block producers submit a block they spend and existing block script which has two outputs:
1. an output to a withdrawal UTXO script which can be spent by the users who withdrew funds from layer 2 back to layer 1 in the most recent block (includes a withdrawal tree merkle root)
2. a new block UTXO for the next block (recurse)

The withdrawal script can only be spent by spending a recursive covenant which includes a delta merkle proof proving the validity of the spend of one of the withdrawals and an additional recursive covenant that creates a new withdrawal script with the updated withdrawal tree root (the withdrawal made is set to the null value so you can't spend a withdrawal more than once).

The locked BTC in the layer 2 block UTXO can only be sent to a script which publishes a new block (1 output) or a withdrawal script which allows users to withdraw a portion of the BTC and sends the rest to a new script with the updated merkle root (2 outputs).

In our withdrawal script, we verify a merkle proof which links the previously submitted state root/withdrawals tree root with a spender:

Code:

<0x8fe1e5f7bc9333914565f011a63942d988c88b00547b35af859635b00cbbc64c> // old root, must be this value as enforced by the block UTXO covenant
<0x7163998f26fec2e57db7413d706d30e7b9f14e13b416217160221ff05690fb65> // new root after spending the withdrawal and removing it from the withdrawals tree

// merkle proof siblings
<0x2f0935c2963ead8b3be0ee5d4d4dcb3af23646c6bbfc330e41e90a47ee8cf7f7> // sibling at level 14
<0xeac71276dd976b550cace2fb1097ad5d296193fea0359202ca4899b398ab2436> // sibling at level 13
<0x2c7011733c31c9c58e0d5cbe40be77c714a4b77b281ffd72155276af21452e24> // sibling at level 12
<0x5cc411ccc9b0ce4704798316824afffbbeb724d7fb06701bf7c57f1fa122102f> // sibling at level 11
<0x485a020e9ce6f948b88528bc38ac34838283bd4a001db1f99b84cbe87ebe3e99> // sibling at level 10
<0x885fb789bdd39eee523ade57bedba8fa308b9014c910d6db04b779732139c5b7> // sibling at level 9
<0x8b4578b4daaa30f78eaa2f5537142c9fe277a87fc4e8c5dd872ab95524d34c48> // sibling at level 8
<0xdcd5818eaddf2de1a4fd8792664403a1b1e24779baf3bfac02f169ae63b46d95> // sibling at level 7
<0x7900bfb52e43f1c0b93a87e4b42bc652a1de0c6e72becc37a4f1d26a3eac42a6> // sibling at level 6
<0x2013541c218b99def8301bb9b283f3696605e39a267e757e61692e47623bebdb> // sibling at level 5
<0x9e5a86f32a7231309e3f4bc44473a181b3482352acc8e332d10b493a8acca77c> // sibling at level 4
<0xca67e1b7055afe377bd9fb285335a3685472b1c08f94cf133481320b0fe63653> // sibling at level 3
<0xf464a8d91ca7029a4b88483b7d778403c310c2eaabf46a905874343f975b49a0> // sibling at level 2
<0xaa6ef54b7988700bbcffcaf327be3ade37a68573e9fd6a498a00600059644a28> //sibling at leaf level

<999> // index of the withdrawal leaf we are spending with in the withdrawals tree

// recursive covenant inputs...
<0x3905000000000000> // 8 byte spend amount (1337) 
<0xb4a2ef4141dfdedc3b548222b11fcf90bf81782ed6bf998b6552ab08978b2ce6> // spender
OP_2DUP
OP_CAT
OP_SHA256 // compute the withdrawal hash -> 0xeac7f4e4689862aa7baf72c1673a48a66561ab222eb6a6d8af38c32393265d90
OP_TOALTSTACK // move the withdrawal hash to the alt stack for later
// the rest of the recursive covenant code


// now only the merkle roots + siblings + index remains in the stack
OP_FROMALTSTACK // old leaf value computed earlier (withdrawal hash)
<0x0000000000000000000000000000000000000000000000000000000000000000>// new value
OP_ROT // move the index to the top of the stack



// start decompose the index into bits
// we decompose the number into bits which are stored on the alt stack
<8192>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<4096>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<2048>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<1024>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<512>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<256>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<128>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<64>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
<32>
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
OP_16
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
OP_8
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
OP_4
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
OP_2
OP_2DUP
OP_GREATERTHANOREQUAL
OP_DUP
OP_TOALTSTACK
OP_DUP
OP_TOALTSTACK
OP_IF
OP_SUB
OP_ELSE
OP_DROP
OP_ENDIF
OP_DUP
OP_TOALTSTACK
OP_TOALTSTACK

// end decompose the index into bits

// now the lowest bit of the index is on the alt stack

// compute old and new merkle roots
OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


OP_ROT
OP_ROT
OP_OVER
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256 // compute old merkle path at level
OP_ROT
OP_ROT
OP_FROMALTSTACK
OP_ROLL
OP_CAT
OP_SHA256  // compute new merkle path at level


// end compute old and new merkle roots

Now we just check the old and new roots from the inputs to make sure the match the computed ones (ie. proof that the withdrawal exists in the tree, and that the merkle tree with merkle root new root has all the same leaves as old tree, except for the leaf at the specified index that has just been spent (and has been nulled out):

Code:

/*

now the stack is as follows:

 // guarenteed correct via the covenant
 // attested by the spender

 // computed from the index/siblings/withdrawal hash value
 // computed from the index/siblings/nulled out value

*/

OP_ROT
OP_EQUALVERIFY // check that the attested new merkle root is a copy of the old tree with the spent leaf nulled out

ercewubam

newbie

Activity: 26

Merit: 62

Quote

For situations where a multisig is appropriate

Could you give any example, where it is not?

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: vjudeu on January 19, 2024, 12:32:07 AM

Quote

currently we just use a "Nothing Up My Sleeve" point which no one knows the private key of

You should not use that, unless it is strictly necessary. It is better to pick a public key, that is just N-of-N multisig of everyone involved. In this way, there is always a chance to spend by key (and make it cheaper) if everyone agrees.

In general, Taproot addresses should be "always spendable by key, and sometimes spendable by key, and by TapScript".

For situations where a multisig is appropriate Wink

vjudeu

copper member

Activity: 903

Merit: 2248

Quote

currently we just use a "Nothing Up My Sleeve" point which no one knows the private key of

You should not use that, unless it is strictly necessary. It is better to pick a public key, that is just N-of-N multisig of everyone involved. In this way, there is always a chance to spend by key (and make it cheaper) if everyone agrees.

In general, Taproot addresses should be "always spendable by key, and sometimes spendable by key, and by TapScript".

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: ?? on ??

I see this is not mobile friendly 😂 , but this is great to see people are actually developing something useful rather than trying to spam the network for more money.

Just wanted to tell you, fantastic work, amazing and thank you. Hope you could add some ECC related functions to have things in one place. 🤭

~~Btw, you founded QED? Any web address for it?~~ Oh I saw it on your profile.

No plans for a mobile version (don't code on your phone haha), but more features on the way, namely:
1. Export standalone bitcoinjs-lib code in the TapScript runner (so you can see how to perform all the steps programmatically as well)
2. Support for OP_CHECKSIG/other sig related stuff + basic wallet/key manager
3. Option to pay with keypath rather than script in the TapScript runner (currently we just use a "Nothing Up My Sleeve" point which no one knows the private key of)
4. Support for Liquid

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: d3bt3 on January 17, 2024, 08:29:00 AM

Quote from: cmpeq on January 16, 2024, 07:59:25 AM

Quote from: warpanomaly on January 14, 2024, 09:45:38 PM

Is BitIDE open source?

Cleaning up the source and adding some tests, will be open sourced this week =)

Will appreciate the source.
But is the real testnet version of this available?

Yep! BitIDE works with regtest, testnet and mainnet. To fund and unlock a script UTXO on the official Bitcoin testnet, just chose "Testnet" in the tapscript executor window and follow the steps below:

Note that Fund via RPC only works with regtest (you can't just mint testnet tBTC at will), so for step two you need to either faucet the address with a testnet faucet or send from your testnet wallet before clicking "Check for UTXOs"

d3bt3

jr. member

Activity: 51

Merit: 20

Quote from: cmpeq on January 16, 2024, 07:59:25 AM

Quote from: warpanomaly on January 14, 2024, 09:45:38 PM

Is BitIDE open source?

Cleaning up the source and adding some tests, will be open sourced this week =)

Will appreciate the source.
But is the real testnet version of this available?

warpanomaly

newbie

Activity: 19

Merit: 25

Quote

Cleaning up the source and adding some tests, will be open sourced this week =)

Awesome! Thanks!

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: warpanomaly on January 14, 2024, 09:45:38 PM

Is BitIDE open source?

Cleaning up the source and adding some tests, will be open sourced this week =)

warpanomaly

newbie

Activity: 19

Merit: 25

Is BitIDE open source?

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: garlonicon on December 19, 2023, 03:55:49 PM

Quote

You can make the outputs 0.

Not only that. You can also hide your scripts behind a TapScript, and then spend by key, if your TapScript will turn out to be unspendable or expensive.

Great idea, we will also added support for key paths in the next version!

In the meantime, for development purposes it shouldn't be an issue if you are using the docker image with bundled regtest + explorer and use Fund via RPC (regtest btc is free Wink

), as clicking the button first runs generatetoaddress to mine 50 btc to the default wallet, and then transfers 1 BTC to the P2TR address (see screenshot below).

cmpeq

copper member

Activity: 33

Merit: 152

Hey all, added docker image for offline development, integration with local testnet (regtest), a block explorer and and a GUI that walks you through how to perform a pay to tapscript (script path) transaction (I saw a lot of people have been asking about this on the forum, so hope this helps).

Grab the new version and start a new local testnet with a one liner:

Code:

docker run -p 1337:1337 -it --rm qedprotocol/bitide:latest

Also shot a quick tutorial video for anyone that wants to get started with TapScript:

Edit:
If you want to use bitcoin-cli with your testnet, just change the docker command to:

Code:

docker run -p 1337:1337 -p 18443:18443 -it --rm qedprotocol/bitide:latest

garlonicon

copper member

Activity: 821

Merit: 1992

Quote

You can make the outputs 0.

Not only that. You can also hide your scripts behind a TapScript, and then spend by key, if your TapScript will turn out to be unspendable or expensive.

cmpeq

copper member

Activity: 33

Merit: 152

Quote from: NotATether on December 19, 2023, 01:02:50 AM

It looks good, but there doesn't seem to be a desktop version. If this is using a JS framework, you know, like React or Angular or Vue or like that, you can just slap Electron on it and you'll be good to go on all platforms.

Maybe you can add a feature where a the compiled script can run on testnet if you deposit a small amount of BTC for the transaction fee. You can make the outputs 0.

Great idea! will definitely add an offline electron version in the next release. Also right now we are working on a 1-liner that spins up a clean regtest network in a docker container with funded wallets and automining so you don't have to mess around with faucets, but testnet integration also makes a lot of sense.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

It looks good, but there doesn't seem to be a desktop version. If this is using a JS framework, you know, like React or Angular or Vue or like that, you can just slap Electron on it and you'll be good to go on all platforms.

Maybe you can add a feature where a the compiled script can run on testnet if you deposit a small amount of BTC for the transaction fee. You can make the outputs 0.

Topic: BitIDE - TapScript IDE with Local Testnet, Explorer and Custom Op Codes (P2TR) (Read 502 times)