Closed Zk2u closed 2 years ago
So we have 3 functions here.. Would u pls explain a little what does each of them do?.. Tnx
So we have 3 functions here.. Would u pls explain a little what does each of them do?.. Tnx
(get-btc-tx? (txid (buff 32)))
Retrieves a bitcoin transaction that's parsed into a Clarity tuple, so a contract could call this function to get a Bitcoin transaction and easily verify if it was confirmed or not, the values of input addresses etc. This one has some more technical fields in it, so most of the time I'd expect contracts to use (get-btc-tx-compact? (txid (buff 32)))
which takes out some of the lesser-used data to be less expensive
(get-tx? (txid (buff 32)))
Retrieves a Stacks transaction and parses it into a Clarity tuple. Same as above, but simpler (Stacks transactions are simpler to parse) so contracts can get data from a Stacks transaction (whether it's confirmed or not, who sent it etc)
We may have to add another function that is identical to get-tx?
but is get-stx-tx?
for app chains, so they can retrieve STX transactions (their burn chain), their own transactions (on the app chain) and bitcoin transactions (from the base layer).
On native Stacks, get-tx?
and get-stx-tx?
would be identical, but on burn chains they would retrieve a tx from their own chain and retrieve one from the Stacks chain respectively.
We can do this since each Stacks node needs a Bitcoin node to 'find' the Stacks blocks to download (the main reason you need to 51% Bitcoin in order to 51% Stacks, because Stacks nodes just steal the security of BTC by checking for its own blocks on the burn chain).
Awesome! .. What about flash blocks or missed Bitcoin blocks?.. I mean those stacks blocks that miss their relevant anchored Bitcoin blocks and are sent to next.. Does that influence your logic?
What about flash blocks or missed Bitcoin blocks?... does that influence your logic?
No, since these aren't tied to one another. The Stacks/app chain node would retrieve the Bitcoin transaction from the Bitcoin node it's connected to (when retrieving Bitcoin transactions)
Naming could be get-burn-tx?
and get-tx?
where get-burn-tx?
has a parameter for the level chains. On an app chain on an app chain on stx on btc you could call (get-burn-tx? 3 txid)
to get a bitcoin tx. (get-burn-tx? 0 txid)
would be equal to (get-tx? txid)
.
have updated this proposal with @friedger's suggestions
I think we need extra fields for segwit flag and witnesses in btc tx structure.
I think we need extra fields for segwit flag and witnesses in btc tx structure.
@friedger what would this look like?
@jcnelson what are your thoughts on this?
While I agree that Clarity programs should be able interact with any burnchain transaction, I don't think this is the right way to go about doing it.
First, this is expensive. In order for such methods to work reliably, the Stacks node would need to download and store not only every single Bitcoin transaction into its own chainstate, but also an index over them so that they could be efficiently queried by txid. This is at least 400 GB of extra space today -- over 30x the size of the Stacks chainstate.
Second, this is inefficient. Nearly every Bitcoin transaction will not be queried by Clarity smart contracts, so we'd be storing them for nothing. Even if every Stacks transaction from 2.1 onwards queried a unique Bitcoin transaction, it would take decades to query them all (since after all the Bitcoin chain is growing in tandem with the Stacks chain).
Instead, I think Clarity should have native methods for the following:
If it can do both of these things, then the system would achieve the goals of this issue: it would store only the Bitcoin transactions that Clarity programs actually need, and it would ensure that any stored Bitcoin transaction was actually mined in a Bitcoin block.
This can kinda-sorta be done in Clarity today, but it would be better to have native support since then the methods wouldn't be limited by Clarity's type system (i.e. you wouldn't need to know the lengths of any data in advance).
This sounds awesome. thinking about it, that is definitely the way to go.
Uses aliases defined in #48
Add functions to retrieve parsed burn chain & native transactions for use in contracts.