Aye 👩🏻‍💻 ⚡️

Mi trabajo actual en Bitcoin me hace agradecer todos los días la carrera de Ingeniería de sistemas. Programar transacciones Taproot no es para cualquiera.

@Bcuz21 a lot. decentralization, peer-to-peer, transactions, proof of work, etc made sense once I saw how it’s implemented

@ayebytes What did you discover?

i started studying Bitcoin more technically because i needed to verify it myself instead of trusting what others were saying

@thekaspaonion not necessarily. it depends on how those layers are designed, some preserve self-custody

@ayebytes So will people be pushed to layers with morphed self custody and property rights?

@thekaspaonion if too many users want to transact at once, fees rise and block space gets priced accordingly and higher layers end up handling most of the activity

Thanks :) Keep up the good work Here's me question Genuinely curious if you think this is a risk of not BTC has over 200M cold wallets BTC can only do 800k transactions a day Is there any risk that more than 5% of bitcoiners will want to use the network at once, to either open a lightning channel or send a base layer transaction Or do you think it's not a risk

@thekaspaonion sure

@ayebytes Do you mind if I ask you Bitcoin questions? I'm curious on your thoughts

@realvijayk yes and went a bit deeper. built Taproot transactions with multiple script paths, hardware wallet signing integrations, mainnet broadcasts, address derivation from xpubs without libraries and more (before ai)

@ayebytes Awesome. Have you sent a base layer transaction? Best way to learn is by doing imo

@thekaspaonion 🫶

@ayebytes Yay! That's fantastic!!! Satoshi is proud of you 🔥

@sashatoshi10 don’t trust, verify philosophy

@ayebytes I agree with you 💯 . I’m doing the same

@peterktodd @giacomozucco i had something simpler (and less flexible) than a Merkle tree in mind, something like a list of input/output indices that a signature commits to it wouldn’t allow reordering, but it would still let you sign specific sections of the transaction i’ll think more about this

@ayebytes @giacomozucco If you wanted full flexibility you'd need a merkle tree of inputs and outputs per signature to allow absolutely anything to be signed to anywhere. Of course, once you go down that path fully even transactions themselves become a fuzzy concept. Good homework problem!

Bitcoin has limitations when signing transactions. these limitations become relevant when building transactions between multiple participants, when inputs are independent, and when working with incomplete psbts (not all inputs and outputs are known at the time a user signs) the existing signature model doesn't allow arbitrary combinations of inputs and outputs Bitcoin signatures “sign” specific subsets of inputs and outputs, depending on the sighash flags. this creates a constrained set of valid commitments, where only certain patterns of input/output relationships are actually representable i created this image to illustrate these limitations: on the left, valid combinations and on the right, invalid combinations that cannot be encoded with the current sighash types (partial overlaps, asymmetric commitments, etc) this issue forces you to introduce additional transactions, or in some cases makes it impossible to implement the desired transaction structure this has probably been discussed before, and there are likely good reasons why these patterns are not allowed does anyone know more about that? (posting again. fixed some mistakes in the image)

“Emotions are contagious. We both transmit and absorb each other’s moods in a kind of hidden psychic economy, where some encounters are toxic while others are nourishing.”

@NoFinntech @BarNumberSeven @_einundzwanzig_ i found 3 Bitcoin stickers in a bar in Berlin

Finde alle Bitcoin & Einundzwanzig Sticker in der sagenumwobenen @BarNumberSeven in Prag

i think that’s exactly what i was running into my replacement was introducing a new unconfirmed parent, which explains the replacement-adds-unconfirmed error. the replacement had a higher feerate than the original transaction, but it was still rejected i realize i oversimplified the issue in my original description

@ayebytes Better replacement criteria were invented in the context of cluster mempool, but IIRC the upcoming Bitcoin Core 31 that will feature cluster mempool currently only allows package replacements in clusters of up to two transactions.

i’m sharing some Bitcoin theory that people like me might find interesting i was about to publish an RBF transaction and got this error: error code: -26 replacement-adds-unconfirmed that led me to check the validations executed during RBF: #L1118C5-L1124C6" target="_blank" rel="nofollow noopener">github.com/bitcoin/bitcoi… when constructing an RBF transaction, all inputs must descend from the same unconfirmed parent tree. in my case, my transaction attempted to spend two inputs coming from different unconfirmed transactions (image) at a structural level, the mempool is a directed acyclic graph (DAG) of transaction dependencies. each transaction tracks its ancestors and descendants, and the node maintains cached metadata for these relationships (fees, sizes, and counts) to enable efficient validation and fee prioritization RBF is designed to operate as a localized mutation within this DAG, replacing one branch with another without altering the global structure allowing a replacement transaction like mine would force the node to recompute ancestor and descendant relationships across multiple subgraphs, and the node may need to recompute large overlapping sets of transactions. this can cause (under certain conditions) quadratic computational cost and even denial-of-service risks for those of us building on Bitcoin and creating transactions, this implies that utxo selection must take into account which utxos are confirmed, and if not, what their ancestry is

@peterktodd it feels restrictive when building, but when i thought it in terms of mempool topology and attack surface it made sense

@ayebytes Yes, IIRC that check is my fault. Unfortunately miner incentives and other issues make this annoyingly complex, especially when RBF was first implemented a decade or so ago.

@jeremyalmond absolutely and the settlement time compared with the traditional financial system is another huge difference

@ayebytes Now imagine the impact on businesses when the cost of moving money is dramatically lower. I’ve spent years working on exactly that.

in Bitcoin, moving $300 can cost the same as moving $5 million the traditional financial system doesn’t work like that

En 2023 abrí esta cuenta para compartir arte sobre Bitcoin. Con 1900 seguidores vendí más de $10k en arte. Las regulaciones en Argentina dificultaron exportar mis obras. Pero sigo acá, convencida de algo: Bitcoin es una de las tecnologías más importantes de nuestra era.

@Stark_of_Zenon true and smaller payments tend to move to higher layers

@ayebytes This cuts both ways.

one of the most important distinctions in Bitcoin’s architecture is the difference between consensus rules and node policy two nodes can fully agree on what constitutes a valid block, meaning they enforce the same consensus rules, while still behaving differently in how they propagate transactions, prioritize them, or manage their mempool Consensus determines what blocks are accepted as part of the chain and Policy determines which transactions a node is willing to propagate before they are confirmed this distinction is critical when interpreting node distribution data. For example, Bitcoin Knots have ~22.6% of publicly reachable nodes, but that does not imply that 22.6% of the network is influencing consensus rules independently because Knots remains consensus compatible with Bitcoin Core what its presence actually means is that a group of node operators wants greater discretion over mempool policy, relay filtering, spam mitigation, and other operational parameters Knots is not competing with Core at the consensus layer; it is competing at the policy and operational philosophy layer Bitcoin Core dominates the deployed consensus surface, acting as the practical implementation for the rules that determine block validity the resulting structure is that: Core functions as the de facto of operational consensus, while Knots serves as the primary channel for practical policy divergence among node operators