Live data from Hacker News

Smart contracts on Bitcoin

avc.com

241–246 of 246 posts

Re: Smart contracts on Bitcoin

#241

Earlier quoted context omitted.

These are of course multiple well-publicized but zero-fact assertions used as propaganda to trick people into ethereum and other altcoin bags.

It's hard to believe people are still repeating these verifiable lies.

The narratives are designed to be earwormy, and everyone wants to live in a spy novel filled with scary conspiracies, so when they hear it, it slips in the backdoor cognitive holes, and they do only minimal "verification" if any at all, and accept it, and then repeat it. It's also very easy to blame an all-powerful adversary for all your woes—did you lose money trading?

Oh, that was gmax's fault.

Did you get scammed?

Oh, that was blockstream's fault. If they'd just did X, then the scam wouldn't have happened in the first place.

Did your friend tell you something secretive that "only he knows" and it's "not public knowledge"?

Well obviously the core devs are behind it.

The absurdity is great when the altcoiners are staring at Bitcoin's behemoth economy with jealous eyes amplifying the narratives they sometimes even know are totally false.

More insidious of course are the lies that are false but simple, where the factually verifiable truth is directly contrary but complex, like the foolish lie about gmax stealing credit, or Vitalik asserting that he was planning Ethereum until the core devs blocked him.

It's easy for outsiders to be infected via their usual lines and information feeds. And, of course, Bitcoin has no marketing department, so obviously defence thereof is a long, painstaking process of careful dismantling and debunking over a long period of time.

Thankfully, the actually helpful, intelligent, and ultra-competent people that are the safest to align with are people on whom these kinds of lies are basically completely ineffectual, so we tend to win, in that respect, just by default.

Re: Smart contracts on Bitcoin

#242

Earlier quoted context omitted.

I firmly believe this. It is taking the digitization of the world to the last economic layer: governance and law. But I also believe we are very very early, and it will take maybe 30 years to develop to start massively transforming industries.

> governance and law. from the very few I know, I didn't see governance and law in blockchain projects. What I perceived is a never ending shared network of operations that can basically replace companies.

The conceptual model is of the governance being in the consensus layer, which operates independently of other political systems, and the law being in the programmatic contracts the blockchain executes.

But yes, there are other ways it can be conceived, and yours seems valid.

Re: Smart contracts on Bitcoin

#243
post #233

Earlier quoted context omitted.

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 corresp…

Interesting. If you don't mind, what's an example of a practical application where it would be useful to validate a bitcoin transaction without the ability for a smart contract to custody it?

Just asking because, again, the value proposition in practical terms is a little unclear to me.

Re: Smart contracts on Bitcoin

#244
post #233

Earlier quoted context omitted.

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 corresp…

Interesting. If you don't mind, what's an example of a practical application where it would be useful to validate a bitcoin transaction without the ability for a smart contract to custody it? Just asking because, again, the value proposition in practical terms is a little unclear to me.

Well, the intended use-case is to make it so the act of transferring BTC to a particular address will cause xBTC tokens to be minted in a Clarity contract by the principal that sent the transaction. From there, you can move the xBTC tokens around in Stacks.

This would be paired with a STX-collateralized service that would ultimately let you trade your xBTC back for BTC. The service would put STX up as collateral, which would be depleted if the service quality degrades. The Clarity contract for the collateral would track the service's xBTC to BTC transfers, and would allow the service to post the BTC transactions it sends as proof of good service quality (thereby staving off depletion).

Other ideas come to mind:

* Proof of (attempted) mining a STX block. A Blockstack app could use a Clarity contract to determine if a user was also a miner, and offer them in-app perks for helping to secure the network.

* Backwards-compatibility with BNS 1.0. Stacks 1.0 implemented a naming service (BNS) on Bitcoin, and Clarity's access to Bitcoin state can be leveraged to allow users to prove that they are OGs -- i.e. that they registered a BNS name before Stacks 2.0 went live (or did something specific with it, like updated it to have a particular owner or have a particular content hash).

* Proof of payment to a particular address. Many organizations, including open-source projects, take BTC for donations. A Clarity contract could be written to identify Stacks users who donated to a particular organization earlier.

* Proof of payment channel. You could demonstrate to a Clarity contract that you have opened a payment channel with a particular amount to a particular address, and post collateral that will be slashed if your payment channel closed before a particular Bitcoin block height.

Re: Smart contracts on Bitcoin

#245
post #92

Earlier quoted context omitted.

Muneeb answered this here: https://forum.stacks.org/t/what-is-the-difference-between-bl...

> Blockstack enables users to use arbitrary storage backends like Dropbox, Amazon, Google as “dumb drives”. Only pointers to the storage backends are stored with Blockstack and encrypted/signed data is kept at storage providers. I stopped reading after that.

Why? That is the thing that excites me the most. Though it isn't thightly locked with the whole STX-side of things which isn't as interesting to me.

Only needing some "dumb" storage media to store your application data and "cloud" files unlocks suddenly a user-centric way for everyone to store data. It also unlocks real competition on the infrastructure layer.

You don't make your own generator and make your own power, -- you don't buy power from say Dell because it needs "Dell electricity". Data should be like this too, ability to be owned and controlled purely by the user (as in you have solar panels + battery) or what most people would do: delegate the work to a power provider.

Ofc not real competition in the "power provider" case since there's physical stuff happening, but for data storage (and batch/"offline" computation and event/webhook handling) a user will be able to set up their own raspberry pi or just use say Amazon to store the encrypted data. :)

I find it fits 100% in to the world I'd want to live in. ^_^

Re: Smart contracts on Bitcoin

#246
post #240

Earlier quoted context omitted.

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 4…

What do you mean by "originally"? It looks like it was introduced as 80 bytes here, so it had only been 80 bytes for a year or so: https://github.com/bitcoin/bitcoin/pull/2738

I recognize the commit where the limit was lowered, though I don't believe it was actually released before being raised again.

Post reply on HN