pull down to refresh
77 sats \ 0 replies \ @lightcoin OP 18 Nov \ parent \ on: Great Script Restoration Project Q&A with Rusty Russell and Julian Moik bitcoin
I have muted the person whose post you linked to so not going to bother responding to it. He is constantly churning out bad takes, one of the lowest signal to noise people I've encountered on this site. I suggest getting your information from a better source.
Feel free to peruse these websites if you are interested in better understanding covenants and their use cases:
https://covenants.info
https://bitcoin.softforks.org
based their track record so far it seems to me that the technical bitcoin community is good at sorting real problems from bs and coming to rough consensus on solutions to the challenges that arise and implementing those solutions with thoughtfulness, care, and the appropriate level of urgency. so I feel good about their/our ability to address potential quantum threats with effective solutions on a reasonable timeline.
there was also a quantum bitcoin summit back in july, which may be of interest: https://www.youtube.com/playlist?list=PL8Qx0853DvlPqutRekO3feBCmn2iRkC1k
Has it, or has it not, always been standard to embed up to 10,000 bytes of data using segwit witness envelopes and up to 400,000 bytes of data using taproot witness envelopes?
I agree with Peter that it's better to have a debate about consensus protocol than relay filters.
The end conclusion will be more or less the same: it's not possible to prevent arbitrary data onchain. Trying to do so will hurt monetary use cases, and may cause collateral damage to node runners too by pushing arbitrary data publishers to cause various forms of bloat e.g. in unspendable addresses.
The solution, as ever, is to outbid the spammers. Anything else is delusion and cope.
I didn't ignore any responses to that thread. Quite the opposite, I actually responded to every critical or questioning reply, because the goal of the thread was to educate. If you see a reply you think I missed, please link to it and I will respond to it.
Now I have some questions for you:
Has it, or has it not, always been consensus-valid to embed up to ~1 MB of data using OP_RETURN?
Has it, or has it not, always been consensus-valid to embed up to ~4 MB of data using witness envelopes?
c52f39725a1c62b36a1a47ebdbeabf2b7ce84d381c600fab9241ca437d51fc32
The sooner we acknowledge this and deal with it the better we can address it ethically and fully, legally, with long-term solutions that bring about REAL adoption
what do you have in mind here?
This section of a post I published before the last UASF in 2017 may be helpful:
A UASF relies on the fact that it is not the miners but the economy of bitcoin users that set the rules of the bitcoin network by throwing their economic weight behind one rule set over others.Once a UASF is enforced by a given full node, any blocks produced by miners that do not comply with the rules of the UASF will be rejected by that node. If enough economic nodes enforce the UASF, then miners will be strongly incentivized to comply with the rules so that they’ll be able to sell the bitcoin mined in their blocks (and avoid losing their block rewards in a reorg).
And this post is not specific to UASF but may help you build a better understanding of how consensus changes work in bitcoin:
By increasing the size of OP_RETURN, we enable criminals to insert illegal data
The premise of that line of thinking in Vlad's thread is false from the start. Changing the default policy in Bitcoin Core isn't "enabling" any new behavior, it simply makes the existing behavior (via modified -datacarrier settings or custom clients like Libre Relay) standard so that users of larger OP_RETURNs can expect timely confirmations, which are required by some L2 designs.
For the people worried about the legal implications of relaying illegal images embedded in transactions, are you also worried about relaying transactions from US government sanctioned addresses?
No, but if this does become a legal issue, then it has broader implications than just bitcoin. Everyone running a box on the internet that other people's bitcoin data packets flow through could be implicated. INAL but this is probably already protected under the law somehow, since people have been using the internet to do crime since forever.
why is there only a single bulletpoint about bitcoin in this "bitcoin tech talk" newsletter, and it's not even about bitcoin tech?
btw @jimmysong any response to this? Or are you gonna pretend like you aren't spreading misinformation to your followers?
Absolutely! From trust-minimized BTC bridging with BitVM to more scalable and private multisig with FROST and MuSig2, Taproot has given us some really great improvements.
btw @jimmysong any response to this?
fair. your statement "the greatest Bitfinex hack.... that end in creating tether" had a different order of operations but these events could have still been related yeah. I will look at the links you shared (I did not see them before)