5 ms·

Edit 3: See my nested child comment. My understanding (from a 2010 conversation with a friend who was deep in btc) was that there was a time where bitcoin scrip

Edit 3: See my nested child comment. My understanding (from a 2010 conversation with a friend who was deep in btc) was that there was a time where bitcoin scripting could cause transactions to appear onchain that would look valid to a novice but would not actually perform the actions described such that a scam could be perpetrated. I have not done the work to validate these claims. I stand by my comments on Eth and Satoshi Dice. The crazy thing is: bitcoin was ethereum. The community killed scripting because it was antithetical to the thing that makes money in BTC: trust. The constant flow of n00bs coming in who got their transactions reversed by OP codes and said "BUT I THOUGHT BITCOIN TRANSACTIONS WERE IRREVERSIBLE!!?!?!!?!?!1111" was eroding trust in the ecosystem. Really, I think the beginning of bitcoin jumping the shark was Satoshi Dice: https://www.coindesk.com/company/satoshidice https://www.coindesk.com/company/satoshidice. Anyways, Bitcoin off-chain scripting won't replace Eth anymore than any other off-chain scripting system will replace Eth. If this kills Eth it will be because people don't want on-chain scripting, not because people want off-chain scripting on bitcoin (ergo, the meta problem is that on-chain scripting doesn't scale in every sense of the word scale; fees, tx speed, finality, etc). Caveat emptor: it's entirely possible this company could work or take off. In crypto, sometimes truth is stranger than fiction. Edit: Just to be extra clear, the problems with ethereum, to me at least, aren't actually on-chain scaling; that feels solvable. What feels unsolvable to me is two things: 1) turing completeness and 2) compilation malleability (if the compiler/machine can change but the code can't, guess what, old code's behavior becomes less predictable over time... computing systems with longevity gain minimal entropy over time). Edit 2: The only rational way I can make sense of turing completeness and compilation malleability as features is if the ecosystem is engineering ecological behavior in, that is to say: old programs should become less valuable unless they accurately predicted the future. Maybe that's rational?

eMGm4D0zgUAVXc7 6y ago
> The community killed scripting because it was antithetical to the thing that makes money in BTC: trust. The constant flow of n00bs coming in who got their transactions reversed by OP codes and said "BUT I THOUGHT BITCOIN TRANSACTIONS WERE IRREVERSIBLE!!?!?!!?!?!1111" was eroding trust in the ecosystem. I never heard of all of this having happened. To my knowledge Bitcoin's scripting language was not trimmed, it was in fact extended over the years by various BIPs [1]. What's your source for these statements? [1] https://github.com/bitcoin/bips https://github.com/bitcoin/bips
- garmaine 6y ago
  He has no idea what he is talking about.
  - josh2600 6y ago
    I talked to a friend in 2010 who claimed that some opcodes could cause transactions to appear as valid on the chain but not actually result in the movement of funds to the targeted address. I realize now that I have not done the work to validate those claims beyond that conversation and will retract my statement until I speak to him.
    - garmaine 6y ago
      I think you or your friend might be conflating malleability, which was a UX issue in 2013 that caused people to be confused about whether a tx was confirmed or not, with the disabling of a handful of script opcodes in 2010 for security reasons (they had buggy implementations and were the cause of a severe vulnerability). Edit for detail: In 2010 the "worst bug in bitcoin's history" was discovered, which let anybody spend ANY output on the chain, due to an obscure feature of the bitcoin scripting system allowing the signature script to simply "return true" before the actual script is executed. This was when OP_RETURN's semantics were changed to unconditionally fail the script if ever encountered rather than the short-circuiting behavior implied by its name and present in early versions. A quick emergency audit was simultaneously done and ALL opcodes that were unused at the time and moderately complex to review were "disabled" as a precaution. It's not clear that the developers understood at the time that they would not be able to re-enable those opcodes for existing scripts without a hard-fork. The distinguishing between soft-forks and hard-forks were still being worked out back then. So large parts of script were in fact removed, but it was done as part of an emergency bug-fix and the permanent disabling may not have even been intentional. The disabled opcodes weren't really that important to smart contracts though, at least not without additional primitives that bitcoin never had. There are various proposals to add these features in to segwit script or the upcoming taproot extension.
- ryebit 6y ago

eMGm4D0zgUAVXc7 6y ago

> The community killed scripting because it was antithetical to the thing that makes money in BTC: trust. The constant flow of n00bs coming in who got their transactions reversed by OP codes and said "BUT I THOUGHT BITCOIN TRANSACTIONS WERE IRREVERSIBLE!!?!?!!?!?!1111" was eroding trust in the ecosystem. I never heard of all of this having happened. To my knowledge Bitcoin's scripting language was not trimmed, it was in fact extended over the years by various BIPs [1]. What's your source for these statements? [1] https://github.com/bitcoin/bips https://github.com/bitcoin/bips

garmaine 6y ago
He has no idea what he is talking about.
- josh2600 6y ago
  I talked to a friend in 2010 who claimed that some opcodes could cause transactions to appear as valid on the chain but not actually result in the movement of funds to the targeted address. I realize now that I have not done the work to validate those claims beyond that conversation and will retract my statement until I speak to him.
  - garmaine 6y ago
    I think you or your friend might be conflating malleability, which was a UX issue in 2013 that caused people to be confused about whether a tx was confirmed or not, with the disabling of a handful of script opcodes in 2010 for security reasons (they had buggy implementations and were the cause of a severe vulnerability). Edit for detail: In 2010 the "worst bug in bitcoin's history" was discovered, which let anybody spend ANY output on the chain, due to an obscure feature of the bitcoin scripting system allowing the signature script to simply "return true" before the actual script is executed. This was when OP_RETURN's semantics were changed to unconditionally fail the script if ever encountered rather than the short-circuiting behavior implied by its name and present in early versions. A quick emergency audit was simultaneously done and ALL opcodes that were unused at the time and moderately complex to review were "disabled" as a precaution. It's not clear that the developers understood at the time that they would not be able to re-enable those opcodes for existing scripts without a hard-fork. The distinguishing between soft-forks and hard-forks were still being worked out back then. So large parts of script were in fact removed, but it was done as part of an emergency bug-fix and the permanent disabling may not have even been intentional. The disabled opcodes weren't really that important to smart contracts though, at least not without additional primitives that bitcoin never had. There are various proposals to add these features in to segwit script or the upcoming taproot extension.
ryebit 6y ago