06:51:09 <m-relay> <s​pirobel:kernal.eu> counterparty added evm support in 2014. the computations are determined to be valid / invalid in counterparty. bitcoin just does the ordering.
07:16:50 <m-relay> <s​pirobel:kernal.eu> the etherum 2014/2015 fantasy of smart contracts turning bike locks agentic in the "real economy" arguably did not come true.
07:17:58 <m-relay> <s​pirobel:kernal.eu> the ethereum 2014/2015 fantasy of smart contracts turning bike locks agentic in the "real economy" arguably did not come true.
07:24:04 <m-relay> <s​pirobel:kernal.eu> we got AMMs out of it in 2018 instead. Most liquidity is still on CEXs because of high transaction fees, slow settlement and MEV.
07:27:39 <m-relay> <s​pirobel:kernal.eu> multisig escrow + privacy has a better shot at solving the "contract specification and enforcement" problem than smart contracts. That does not mean that "smart contracts" are useless though. The substance behind the buzzword is turning completeness / more flexibility + account based vs utxo based.
07:32:24 <m-relay> <s​pirobel:kernal.eu> the bitcoiners have a taboo around account basedness + turning completeness. But that shouldnt keep one from looking at reality and seeing the purpose for this
07:33:35 <m-relay> <s​pirobel:kernal.eu> the bitcoiners have a taboo around account basedness + turing completeness. But that shouldnt keep one from looking at reality and seeing the purpose for this
07:33:41 <m-relay> <s​pirobel:kernal.eu> multisig escrow + privacy has a better shot at solving the "contract specification and enforcement" problem than smart contracts. That does not mean that "smart contracts" are useless though. The substance behind the buzzword is turing completeness / more flexibility + account based vs utxo based.
07:34:05 <m-relay> <s​pirobel:kernal.eu> *Turing
14:53:15 <m-relay> <z​hangyijia2022:matrix.org> jeffro256: Okay, I understand. I may be away for a while to study, keep up the good work!
17:33:32 <m-relay> <c​haser:monero.social> adding EVM compatibility before Ethereum launched is ambitious to say the least. I found no sign that this effort ever got anywhere, only rotten links and empty Github branches. I also fail to see how this could be practical. if there's a contract, and I make state transition `A` to it, while you make the contradicting state transition `B`, and both transactions are included in th<clipped messag
17:33:32 <m-relay> <c​haser:monero.social> e same Bitcoin block, whose transition is the valid one and why?
17:34:34 <m-relay> <s​yntheticbird:monero.social> The one that pay more fees win!
18:03:32 <m-relay> <s​pirobel:kernal.eu> the colored coins concept is based on the idea that you can use the transaction ordering and security properties from another chain to build new consensus rules that are enforced at the wallet level
18:03:51 <m-relay> <s​pirobel:kernal.eu> it is very straight forward when you wrap your head around it
18:04:41 <m-relay> <s​pirobel:kernal.eu> it is also very elegant in the sense that these additional rules only have to be evaluated by the users that are concerned about them and not the whole network
18:51:57 <m-relay> <c​haser:monero.social> I'm fairly familiar with the colored coins concept, and it doesn't solve the problem that the nodes sequencing the underlying blockchain (in our case, Bitcoin miners) don't/can't verify the supposed computation carried out on the colored layer, therefore you can't have a consistent state for computation that exceeds the programmability of the underlying chain. see my above example<clipped messag
18:51:58 <m-relay> <c​haser:monero.social> . I can't in good faith call that smart contract capability beyond what Bitcoin Script already provides.
19:54:25 <m-relay> <s​pirobel:kernal.eu> get more familiar
20:52:13 <m-relay> <j​effro256:monero.social> It's 0.3 XMR/min, regardless of block speed. Monero has changed the block speed once already. Monero doubled the speed, and halved the emission per block, so that the 0.3 XMR/min promise was kept.
20:53:57 <m-relay> <j​effro256:monero.social> Excuse me, flip those words around. Halved the speed, doubled emission per block. It *was* 1 minute block time with 0.3 XMR per block
20:58:47 <m-relay> <r​ucknium:monero.social> jeffro256: You have broken out of time
21:00:17 <m-relay> <j​effro256:monero.social> Oops I thought those messages were way newer than they are ;). My client's jumping around the history kinda weirdly
21:01:02 <m-relay> <j​effro256:monero.social> Pressing the down arrow to catch up doesn't really work in the Element desktop app
21:01:07 <m-relay> <j​effro256:monero.social> Sorry, endor00
21:01:13 <m-relay> <o​frnxmr:xmr.mx> This account wont even load the message