Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smart contracts on Bitcoin

avc.com

Post reply on HN
Print view View original

231–240 of 246 posts

Re: Smart contracts on Bitcoin

#231

Post by jude- »

hanniabu wrote: post #204
opreturn wrote: post #96

Earlier quoted context omitted.

> except for mining security where did you see that? I don't think their security model has any connection with Bitcoin mining. They are not merged-mining with bitcoin

I believe they're using checkpoints similar to the security service that komodo was offering to other chains.

The system selects one of a set of competing miners to produce the next block via a VRF whose state is recorded to Bitcoin OP_RETURNs. There is at most one Stacks block per Bitcoin block, and the probability of winning is proportional to the relative amount of BTC burnt or transferred.

The system's design is well-documented via the SIP process. See https://github.com/stacksgov/sips (you'll want to read SIP-001 and SIP-007 in particular).

Re: Smart contracts on Bitcoin

#232

Post by jude- »

everfree wrote: post #126
X6S1x6Okd1st wrote: post #121

So it's a sidechain that ocassionally checks in it's state to bitcoin's main chain? And you can lock up BTC on the mainchain to use it on the sidechain?

In essence, yes, it's a sidechain. From their site: > Like Bitcoin, Stacks is a layer-1 blockchain. Proof of Transfer connects it to Bitcoin with a 1:1 block ratio.

Not really. The key difference is the degree of involvement Bitcoin miners have in Stacks mining. In side-chains, Bitcoin miners would need to opt-in to mining the side-chain and validate its blocks. In Stacks, Bitcoin miners only need to include the Stacks miners' block-commitment transactions into Bitcoin blocks. Since block-commitment transactions look like normal BTC transactions, no Bitcoin miner involvement is necessary beyond what they're already doing.

The full protocol description can be found in https://github.com/stacksgov/sips (see SIP-001 and SIP-007 in particular).

Re: Smart contracts on Bitcoin

#233

Post by jude- »

everfree wrote: post #134
muneeb wrote: post #15

Earlier quoted context omitted.

The smart contracts part comes with Clarity lang: https://clarity-lang.org/ Clarity contracts have direct visibility into Bitcoin state and can write logic against that.

How useful is it to have a read-only glass window into Bitcoin that your smart contracts can look through? The only practical application I can think of is atomic swaps, which can be accomplished any number of other, easier ways.

It means that Clarity smart contracts always have all the data they need to validate Bitcoin transactions. Unlike wBTC and friends, there's no need to copy header hashes from Bitcoin into the Stacks chain. By extension, this means there's no need to worry about catastrophic corner cases, such as the copied data being missing or invalid, the copied data not being mined in the canonical fork, or the copied data corresponding to a minority Bitcoin fork.

Re: Smart contracts on Bitcoin

#234

Post by jude- »

iso8859-1 wrote: post #65

How is consensus secured for the Stacks blockchain? Is it proof-of-work? How many nodes are there? What is the root of trust of Stacks? Does it have auto-update? If I take over your domain, can I take all Stacks? How can I independently verify how many mainnet coins have been locked as Stacks? How do I run a testnet node?

> How is consensus secured for the Stacks blockchain? Is it proof-of-work?

This is all described in SIP-001 (https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip...).

> How many nodes are there?

Here's a sample: http://seed-0.mainnet.stacks.co:20443/v2/neighbors

> What is the root of trust of Stacks? Does it have auto-update? If I take over your domain, can I take all Stacks?

Root of trust is the history of cryptographic sortitions in the Bitcoin chain (again, see SIP-001). The chain can soft-fork to upgrade -- a direct and desirable consequence of Clarity being a decidable programming language. If you want to attack the chain, you'll need to mine a longer Stacks chain (or attack Bitcoin).

> How can I independently verify how many mainnet coins have been locked as Stacks? How do I run a testnet node?

See docs.blockstack.org

Re: Smart contracts on Bitcoin

#235

Post by jude- »

everfree wrote: post #128
muneeb wrote: post #12

Earlier quoted context omitted.

Muneeb here, Stacks co-founder. Great question. You are right that Clarity smart contracts have direct visibility into Bitcoin, so you can write a contract that has logic triggered by pure Bitcoin transactions. Moving Bitcoin to Stacks is a bit more complicated and there are several ways: a) Wrapped assets. Tokensoft + Anchorage (custodian) have a solution that they're calling xBTC where a "wrapped Bitcoin" is issued…

Thanks for joining this thread. What exactly do you mean by "xBTC is secured by Bitcoin itself?" Do you mean that Stacks writes out its own block hashes to the Bitcoin blockchain, or something?

> Do you mean that Stacks writes out its own block hashes to the Bitcoin blockchain, or something?

Yes; the entire history of attempts of mining Stacks blocks, as well as the entire history cryptographic sortitions that select Stacks blocks (including forks), is written to the Bitcoin chain. See SIP-001 for details: https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip...

Re: Smart contracts on Bitcoin

#236

Post by inter_netuser »

hanniabu wrote: post #198
cocktailpeanuts wrote: post #154

Earlier quoted context omitted.

see my comment in sibling thread. with proof of work, it's not just about money. proof of work mining forces miners to invest through future commitment, which means you can't just bring some one time money and gain influence. For proof of stake it's only about the present.

When you buy mining power you are bringing money in to gain influence. There's literally no difference so I'm led to believe there's a bias making you think there is.

what influence do miners have?

Re: Smart contracts on Bitcoin

#237

Post by inter_netuser »

littlestymaar wrote: post #218
flashmob wrote: post #215

Earlier quoted context omitted.

> The security model of Bitcoin comes from proof of work This is not the security model, this is the consensus model. It's based on probabilistic finality, meaning that the probability that a transaction won't be reversed increases as more blocks are added on top. One major advantage of PoS is that it has "Absolute Finality" - after a certain amount of blocks, it's absolutely impossible to do a 51% attack. (See https…

Exactly. In addition, the Bitcoin proof of work is pretty much a proof of stake scheme in practice, where the stake are physical (specialized hardware and access to cheap electric power). So most of the GP's complaints about proof of stakes can be applied to bitcoin as well (“With proof of stake, the stakers only need to make an investment once in the beginning, so it results in rich get richer”). And the biggest dif…

not only hard-fork numerous times, but also adjust monetary arbitrary policy.

It's just like any other fiat, and of course for such applications PoW is irrelevant.

Re: Smart contracts on Bitcoin

#238

Post by iso8859-1 »

CryptoPunk wrote: post #185
grubles wrote: post #159

Earlier quoted context omitted.

Vitalik's claim is a lie. No "OP_RETURN wars" happened. It's a complete fabrication. See https://twitter.com/notgrubles/status/1187470076833697794

I remember the hostility by certain Core devs to OP_RETURN being used for "ulterior" purposes. I remember the push to reduce the size of OP_RETURN to 40 bytes to sabotage smart contracts. source: https://www.coindesk.com/developers-battle-bitcoin-block-cha...

Your Coindesk source is wrong, the limit was never lowered.

Here is the commit where it was raised from 40 to 80: https://github.com/bitcoin/bitcoin/pull/5286/commits/a930658...

If you believe if was ever lowered, show me the commit.

The Coindesk articles contains the phrase "OP_RETURN was originally meant to store 80 bytes of extra data in a bitcoin transaction". How do they know what it was originally meant to do? If it meant to do it, why wasn't it in the source?

Re: Smart contracts on Bitcoin

#239

Post by stocknoob »

TheDong wrote: post #171
stocknoob wrote: post #113

Earlier quoted context omitted.

I'm sure creating the first spreadsheet application was more expensive than hiring an accountant. But not doing it 1 million times. Someone will make "contracts as a service" and competition will drive down the cost, until it's nearly free (as spreadsheets are today).

I think there may be a difference. Accountants are humans that are trying to be computers. Smart-contracts are computers trying to be human. Most contracts are flawed and only really matter when things go wrong. I'd rather that a human be there when things go wrong to understand the human intent behind the contract than have a computer which does not know the human intent, but is able to enforce the (likely flawed) c…

That's a tradeoff left to the contractual parties. The same human process that infers ill-specified intent can be corrupted to not execute that intent. If you want a human bootstrap, you hire a lawyer as an oracle which decides whether to process the contract specified in the blockchain.

Re: Smart contracts on Bitcoin

#240

Post by bhaak »

iso8859-1 wrote: post #238
CryptoPunk wrote: post #185

Earlier quoted context omitted.

I remember the hostility by certain Core devs to OP_RETURN being used for "ulterior" purposes. I remember the push to reduce the size of OP_RETURN to 40 bytes to sabotage smart contracts. source: https://www.coindesk.com/developers-battle-bitcoin-block-cha...

Your Coindesk source is wrong, the limit was never lowered. Here is the commit where it was raised from 40 to 80: https://github.com/bitcoin/bitcoin/pull/5286/commits/a930658... If you believe if was ever lowered, show me the commit. The Coindesk articles contains the phrase "OP_RETURN was originally meant to store 80 bytes of extra data in a bitcoin transaction". How do they know what it was originally meant to do?…

The first comment in the pull request is: "The maximum size for OP_RETURN outputs used to be 80 bytes, then got changed to 40 bytes to be on the safe side. We have now been running with 40 bytes for about 9 months, and nothing catastrophic happened to the Blockchain, so I am proposing to increase it back to 80 bytes."

The commit that is referenced by this comment is "script: reduce OP_RETURN standard relay bytes to 40" https://github.com/bitcoin/bitcoin/commit/8175c790eb

There you can see that it was originally 80 bytes.

Post reply on HN