Stacks
Clarity Bitcoin Library for Stacks 2.1 #475
Replies: 20 comments 17 replies
|
I think this is a great idea! For anybody using the current clarity-bitcoin library this would be a huge improvement, and also gives us a chance to talk about what works, what doesn't, and what can be improved with 2.1. Would the clarity-bitcoin js library update have any overlap with the grant work done with the stacks-bitcoin-api? Tagging a few others who may be interested, feel free to share with/tag others, and if you can help out or want to join the discussions please leave a comment! @Jamil @yknl @dantrevino @radicleart @lgalabru @obycode @donpdonp @dumbledope @philipdesmedt @jcnelson @aulneau @orlandobtc |
|
at a glance, what needs to be added are segwit v0/v1 addresses compatibility and optimizations from the new functions. |
|
The bulk of the clarity bitcoin library is an implementation of the new |
|
Checks for previous blocks can be removed as well. |
|
Can we fund the activity? |
|
Given this expands on the grant work already done for the library and that the project has clear milestones I think it'd definitely be a candidate for a grant. We should estimate how many hours each milestone would take to complete to start. |
|
I put some numbers to the deliverables. Please verify. |
|
So that'd be 100 (101) hours, if we base that on $75/hr it's a $7,500 grant. Doesn't sound too bad, especially if we can confirm what entities need it and who else would signal support. From there it'd just be identifying who's responsible for what part of the deliverables, and possibly who (or how we) can receive the main payout to distribute. I'd have to look at the grant application structure again but I think that would knock out most the necessary info. |
|
Grant has been approved. Please let me know if you want to contribute parts so we can share the funding. |
|
Git repos of clarity-lib with some tests:
Git repo for js library: |
|
This will likely prove an essential library for the Stacks 2.1 environment. I can support to a limited extent with my Clarity and Bitcoin transaction knowledge, as well as by writing some of the supporting documentation. This proposal—a public library supporting in-Clarity bitcoin transaction parsing—would seem to fit the bill for a Stacks grant application. |
|
@friedger this is a perfect fit for a grant ( as noted by @mefrem ) - given the high priority of this work and your impeachable reputation ( 😀 ) the fastest way to awarding this grant would be for you to submit an application via grants.stacks.org . typically, we wait and do a full review with the Grants Review Committee, but we will make an exception for this. I will ask Jude / Jesse / Kenny to take a look and help with an expedited review. Very exciting! |
|
Grant submitted here: stacksgov/grants-program#803 |
|
This is approved. |
|
For documentation, I suggest to add a chapter to the clarity lang book: clarity-lang/book#35 |
|
Here is a working git repo with some tests for the currently deployed version: https://github.com/friedger/clarity-bitcoin |
|
@jcnelson Do you have any comments/ideas/suggestions for improving the contract? |
|
parse-tx vs concat-tx ? There are two ways to verify the btc tx in a contract and use the content of the btc tx: What is the preferred way? When using which approach? |
|
Can we have both on commented parts , some builders will definitely want to try other styles . |
|
I think parse-tx should be part of a second contract because handling segwit transactions adds unnecessary complexity. What do you think? @FriendsFerdinand |
|
I have added a first example to send stx to the first input (WIP) that clarifies how to use the library |
|
The tests have been converted for clarinet. Cost calculations show that the version for 2.1 has reduced costs of 50% of version 2.0. |
|
How and why the costs reduce ? With contract test ? |
|
Main reason is that the new version uses new native clarity function for slicing buffers, I guess. |
|
reverse buff has been optimized. |
|
Thanks Friedger, I'm currently taking a look. |
|
I'm wondering if there's any point in keeping the functionality that is never going to be executed/called? For example, when calling Though, after thinking about it for little bit, maybe it's best to keep the non-optimized version as reference. Others can optimize as need be. |
|
Let's optimize this one for daily use. And then document how to do generalized one. |
|
Contracts have been deployed to mainnet: clarity-bitcoin-lib-v2 as the main contract clarity-bitcoin-helper with some helper functions that are not always necessary stx-oracle: a price oracle based on the average of the last 10 bitcoin commits from miners stx-account: a read-only function to get the value of stx-account for a given principal Documentation is next.. |
|
And website completion ? |
|
v3 has been deployed with a fix of was-tx-mined Also content from readme was duplicated here: Work on verifying transaction with witness data is happeing here: https://github.com/FriendsFerdinand/clarity-bitcoin/tree/feat/segwit |
|
What's the fix? Do you have the commit or PR? |
|
the merkle proof needed to be used once in normal format and once reversed |
|
A new version of clarity-bitcoin-lib-v4 has been deployed to mainnet with support for segwit txs. https://explorer.hiro.so/txid/0x7442d23307f2d7e9ec67eb1d63d643321cdc8bb603a375888f9c1f5bed9fb5d8?chain=mainnet The git repo on github has been updated and more documentation and tests have been added: https://github.com/friedger/clarity-bitcoin |
|
A new version clarity-bitcoin-lib-v5 has been deployed to mainnet on 11th Dec 2023 that adds support for txid generation and improves security: https://explorer.hiro.so/txid/0xfe25941d97a1b965b09699b622ec1d701997be62708dbac2e7a8c36a49e3e9bc?chain=mainnet The git repo on github has the latest code and tests: https://github.com/friedger/clarity-bitcoin |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Objective & Scope
There are two contracts of clarity bitcoin library on mainnet that provides a method to check in a clarity contract whether a bitcoin transaction was mined. These contracts are written in Clarity 1. This Working Group is about developing a contract optimized for Clarity 2.
Deliverables
Timeline
Depending on working group members' commitment within a month (Feb 2023) To be confirmed.
Lead
Additional Context
Zest Protocol. Bitcoin Faces, Catamaranswaps have indicated interest in using an updated version
All reactions