Nostr Archives

my investment firm ten31 has provided over $250 million to great bitcoin companies building great bitcoin products that make it easier to use bitcoin as money. we have zero interest in shitcoins or arbitrary data on bitcoin and are the only major firm that can say that. we are all in on bitcoin. https://ten31.xyz

💬 179 replies

Replies (50)

GFY19d ago

🦗🦗🦗

0000 sats

Rusty Russell18d ago

OTS transactions only exist to put non-financial data in the Bitcoin blockchain. Is that ok?

0000 sats

quietstacking18d ago

hm, rare signal

0000 sats

JackTheMimic18d ago

I reject the question of "is that okay?" I only submit whether the definition of spam is accurate. Your characterization of a transaction that is Open time stamped is not accurate. It is a financial transaction that is used as a timestamp proof. Like using a decentralized checkbook to prove you were in the store writing the check at a given time. The transaction is a transaction, the OTS correlated is coincidental. Again spam is when a field is exploited beyond the necessary data to make the transaction. OTS embedding doesn't add extra data and therefore burden on others.

0000 sats

Rusty Russell18d ago

And does this mean you're okay with transactions that transfer NFTs? Because that's a financial transaction?

0000 sats

BushRat6d ago

Why do you need a picture of a monkey printed on your receipt? If the nft was text only, proof of purchase, like they were originally before the money laundering fake art scams changed the meaning. But I think it's too late for the term nft, just call them decentralised proof of purchase or something.

0000 sats

sats>bits18d ago

I thank the lord every day I wasn’t born as miserable, depressed and useless as this fucking loser. Feeling blessed

0000 sats

GFY18d ago

OH YEAH YOU SOUND SUPER NICE AND HAPPY 🤣🤣🤣 CALLING OUT BULLSHIT IS USELESS TO YOU BECAUSE YOU'RE USED TO EATING GARBAGE, NOTICE HOW YOU DEBATED NOTHING I SAID BECAUSE YOU CANT

0000 sats

sats>bits18d ago

Pal. I genuinely feel bad for you. You don’t even believe the things you say. Find help before you hurt yourself or others

0000 sats

Alex18d ago

I’m new to this, what change did Core30 make that wasn’t possible on before?

0000 sats

Tacitocu 🤓⚡🌍18d ago

👀 https://www.youtube.com/watch?v=k8nGk8vLvrg

0000 sats

Alex18d ago

I was hoping to hear your own understanding instead of what some influencer says

0000 sats

ValderDama 🔑👽🌞17d ago

Man, you are like a bot. Maybe it would easier for you to create one 🤖

0000 sats

BitcoinIsFuture17d ago

We need to expose the lies of the Coretards. Bitcoiners deserve the truth and Bitcoin Freedom Money. Not spam inscriptions via exploits or large OP_RETURNs forced from compromised Core devs.

0000 sats

Curiouser17d ago

And yet you can’t answer the question: How does it serve Bitcoin’s function and quality as money, to violate the role and responsibility of Core’s job, and condescendingly force a change in Bitcoin’s protocol, to enable arbitrary data to be stored in the network? It’s not a lark you’re pissing away. Bitcoin is important to some of us.

0000 sats

BushRat6d ago

Remember kids, every accusation is a confession. When a zionist says you are controlled by Peter Thiel for no reason, what they're doing is telling you that they actually work for Peter Thiel. Projection is their only coping mechanism

0000 sats

sats>bits6d ago

So exactly what kratter has done for like 6 months now? You fell for the bait

0000 sats

Rusty Russell18d ago

It adds an entire transaction! Every time it does that, it uses up farmore space than an 80-byte OP_RETURN. So your conclusion is that it's not spam if it looks like a normal transaction to you?

0000 sats

JackTheMimic18d ago

If we are not conflating spam (content) with spam (quantity), yes. Data hidden via stagnography is not a future IBD issue. I am not a reactionary here, I just don't like the intentional mischaracterization of a reasonable approach. Creating more of a validation burden on future nodes is the threat, in my estimation.

0000 sats

BushRat6d ago

projection seems to be your only coping mechanism 🤔

0000 sats

sats>bits6d ago

I genuinely love my life. I am beyond blessed to live the life I have. No projection or cope, just genuine thankfulness for the life Christ and my parents have given me.

0000 sats

Tacitocu 🤓⚡🌍18d ago

Since Bitcoin Core v30 the "datacarriersize is increased to 100,000 by default, which effectively uncaps the limit (as the maximum transaction size limit will be hit first)" https://bitcoincore.org/en/releases/30.0/ The default value in the previous Bitcoin Core version was 83 bytes, that is enough for monetary use cases, e.g. Peg-In transactions to the Liquid sidechain require an OP-RETRUN size of 36 bytes.

0000 sats

Alex17d ago

So you’re saying all they changed was a default setting? Just change it back to 83 bytes. Problem solved, no fork needed

0000 sats

ODELL17d ago

changing the local policy default limit back wont have a major effect because 1) its not a protocol rule, but rather a local node one 2) these transactions started getting propagated around the network more effectively due to librerelay, not core, which is a node implementation that is basically the opposite of knots 3) bip110 is not about spam but rather ego and control

0000 sats

Rusty Russell17d ago

So, OP_RETURN is fine, as is annex data which don't increase validation burden? And cutting off OP_RETURN and driving those uses to fake pubkeys, which does increase future validation costs, is a threat?

0000 sats

JackTheMimic17d ago

OP_RETURN and taproot annex both expand the data burden on future nodes so I'm not really sure what you're talking about. (A pruned node can't be used for an IBD.) Fake pubkey outputs are still pubkey length and therefore not any harder on validation than a normal transaction. They are also a pro rata donation to the rest of us because they will never be spent. Also you are not " driving those uses to fake pubkeys." I'm not driving the thieves to my neighbor's house by locking my own doors. Steganography is not the issue here. If it looks like a normal transaction, the whys and wherefores are not up for debate.

000

BitcoinIsFuture17d ago

> "3) bip110 is not about spam but rather ego and control" That is a lie which is proven with real Bitcoin transactions already 📝 eb6b32a1…

0000 sats

BitcoinIsFuture17d ago

From BIP 110 wiki: " New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* payloads and witness stack elements exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) Witness stacks with a Taproot annex are invalid. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. " https://github.com/bitcoin/bips/blob/master/bip-0110.medi…

000

Rusty Russell17d ago

You only have to download and hash: you don't have to check extra signatures (our most expensive operation) or put them in the UTXO set (our most constrained memory resource).

0000 sats

JackTheMimic17d ago

Initial block download you check: Block- Syntax, PoW, timestamp, blocksize, and Txn- Syntax, signatures, inputs, and outputs So, I am not sure what you mean by "download and hash"

0000 sats

Rusty Russell17d ago

To check the signature, you hash the transaction. So the only cost that OP_RETURN is doing is the cost to download and hash it. If it's data in the annex you don't even need fi hash it, just download it.

0000 sats

JackTheMimic17d ago

I feel like we have gotten off on the wrong exit. OP_RETURN is a testing code that should have never been made standard in 2014. The sole problem of OP_RETURN and Annex are data storage burden. I admit with Moore's Law, it is likely not a storage issue. My contention is that processing, bandwidth and RAM do not adhere to Moore's. Both OP_RETURN and Annex increase the bandwidth necessary for expedient download. Especially with future low end hardware. To be clear, I find BIP 110 wanting. - My approach would be to modularize the reference code into about 5-6 manageable chunks instead of the monolithic codebase it is today. With node policy, consensus, the Bitcoin spec, and peer logic, so on as separate modules independent but adhering to the same spec. - Remove OP_RETURN standardness - Remove the witness discount - Review the BIP 341 OP_codes With that, spam would simply pay for their data usage and ACTUALLY compete on level ground with simple transactions. (Instead of at a 1/4 weight discount)

000

aj16d ago

You need to hash the annex to calculate the wtxid, which goes into the witness merkle root in the coinbase, which you check when validating a block though. You also hash it as part of taproot witness signature valuation, which is different from other witness data (eg inscriptions).

0000 sats