The pace of innovation in Bitcoin is faster than ever, and the scope of projects being built in the ecosystem continues to expand.
As the BItcoin ecosystem grows, this naturally means there are fewer and fewer people who are knowledgeable in all aspects of Bitcoin and Lightning.
Unless keeping up with Bitcoin development is your full-time job (and even if it is), we're all prone to developing gaps in our knowledge and understanding of how Bitcoin, Lightning, and the projects built on top of these protocols work.
To solve that problem, we thought it would be fun to open the floor today for anyone to ask all the Bitcoin & Lightning questions they've felt too embarassed to ask until now.
There is no topic too elementary, and no question too complicated. Just jump in with all your burning questions, and help others solve their questions if you see one you can answer!
I don't get the hype around imaginary chains like statechains, space chains, drive chains, galaxy chains, Arc, etc.
Perhaps I'm a moron or perhaps I've seen enough BS in the past to not care (other merge mining projects), or perhaps I'm a lightning maxi. But anyone can give a tl;dr on why it is worth exploring despite the trade offs?
reply
1725 sats \ 1 reply \ @ek 1 Jun 2023
I can only speak for drive chains. The main arguments are:
  • It enables experimentation and new use cases for Bitcoin
  • It solves conflicts and infighting
  • It solves “scaling”
  • It solves the blockchain security budget issue
  • It keeps Bitcoin decentralized
what trade offs do you mean? I have looked briefly into drive chains during my research on prediction markets (Paul Sztorc did a lot of ground work for prediction markets on bitcoin using drive chains) and I have seen no real downside to them except that people are emotionally against the idea because it sounds like "shitcoins on bitcoin" (which is basically a feature not a bug lol)
reply
The misaligned miner incentive problems are pretty big one IMO.
reply
For single sig, is it best practice to keep your backup seed and hardware device together in a home safe? With the seed, once an attacker has physical access it's game over. If it was only a hardware device, then maybe they would have more trouble getting the actual private keys, but then where would you put your seed?
reply
152 sats \ 6 replies \ @ek 1 Jun 2023
is it best practice to keep your backup seed and hardware device together in a home safe
No, I would say best practice is to always keep your hardware device and seed separate.
Only the seed is valuable. I don't have much experience with other wallets but trezor wipes your seed after 16 unsuccessful unlocking attempts so I think it's pretty safe to say that an attacker can do nothing with your hardware device (let's ignore nation-state threat actors for now).
I keep my trezor always with me on my key chain. The only downside is that people may notice that I am into bitcoin imo. But the people who will see my key chain and thus may notice my trezor are mostly the same people I would tell about bitcoin anyway.
My seed is hidden in a (hopefully) non-obvious way and I regularly check that it's still there.
However, at the end you need to know your threat model. What are you trying to defend against? Against theft, loss, natural disasters? Or against a sophisticated hack using malware, phishing, surveillance, ...?
edit: in case someone reads this and thinks that's a good idea: DO NOT CARRY YOUR SEED PHRASE WITH YOU
reply
threat model would for regular pleb who saves in bitcoin (maybe a years worth of savings? small enough that they don't do multisig). I think the biggest threats are natural disaster and theft from someone that knows they have bitcoin.
In your example of having a hidden seed, why not just have your hardware wallet with it? I don't envision people needing to sign with a hardware wallet so much that they would want it physically on them.
reply
Yeah, I think for a regular pleb your threat model makes sense. I would also add "loss" however. Sometimes, you yourself are the weakest part in the chain.
In your example of having a hidden seed, why not just have your hardware wallet with it?
Because I see no need to hide my hardware wallet. Hiding it at the same place with my hidden seed would even make it worse: Every time I access my cache, there is a risk that someone might find out where it is.
I don't envision people needing to sign with a hardware wallet so much that they would want it physically on them.
That's true. Since Lightning, I don't use onchain that often anymore. But keeping it physically on me is a protection against accidental loss. That wouldn't mean my funds are gone but it would still mean I lost something which did cost me around $80. So I basically keep my HWW where I keep other things I don't want to lose: on my key chain.
reply
Every time I access my cache, there is a risk that someone might find out where it is
I hadn't thought of that before! My cache game is not strong. Something I probably need to consider more.
reply
Yeah, a good cache is a trade-off between convenience of access, security and not being that good that even you yourself don't find it anymore, lol
last point is another reason why you should regularly check on your seed: to not forget where it is
reply
Why do you keep your trezor with you all the time??? IMO thats a big mistake.
Hardware wallet is for long term storage and transactions every now and then.
If you need to send or receive in a daily basics, I'd be using a good software wallet as Samourai, Phoenix, etc...
Do you know about thr $5 wrench attack???
reply
Why do you keep your trezor with you all the time??? IMO thats a big mistake.
So I basically keep my HWW where I keep other things I don't want to lose: on my key chain.
If you need to send or receive in a daily basics, I'd be using a good software wallet as Samourai, Phoenix, etc...
I use that
Do you know about thr $5 wrench attack???
Yes, I do. How will me not keeping my trezor on me help me against that? Most people won't notice that I have my trezor on me.
reply
I'm a python developer. Self-taught, no fancy CS degree. Not a 10x developer. 1x on a good day, but very stubborn and a team player.
What technologies/languages should I learn to get involved with Bitcoin professionally?
reply
753 sats \ 0 replies \ @ek 1 Jun 2023
I think it depends on how you want to get involved: L1 protocol stuff? Definitely C++ since core is written in C++. However, with Python, you can also improve the core test suite. For L2 protocol stuff, I think Golang or Rust are good candidates (LND is written in Go, CLN in C/Rust) If you just want to build applications like SN, you can use any stack basically. SN uses NextJS + Postgres.
Jon Atack has a lot of resources on how to contribute: https://jonatack.github.io/articles.
But don't forget that reviewing and testing also counts as contributing. That's where most people are needed:
Remember that testing issues and reviewing are the most effective ways you can contribute as a new contributor (and will teach you more about the codebase than opening PRs).
reply
How dangerous is it for me to run a clear net node? I am sick of tor and I want to route payments!
reply
Dangerous from what?
reply
You tell me! Everyone says to run a node behind Tor to not leak your IP address.
reply
1425 sats \ 1 reply \ @ek 1 Jun 2023
Depends on why you don't want to leak your IP address.
Most of the times, people overestimate what can be done with an IP address.
reply
Main fears
  1. Getting hacked
  2. Node becomes huge and become a target for meatspace crime
reply
tunnelsats.com - done If you want to route you must be public and visible and reliable. If you want privacy, then run private nodes.
reply
Shameless plebvpn plug. Only for raspiblitz right now, but we're working on adding MyNode support and creating a "turn-key" solution for hosting your own instance.
reply
LOL very cool name !
reply
I'm checking out a thing called hoppy sometime later this month. Basically the solution for if you don't have control of a static IP address, and all the hassles that can cause, but it also acts as a second filter against locating where the keys are.
You should check out zgrok too. It's really not hard to rent a vps anonymously and set up a persistent ssh tunnel to it and attackers have no way to get at your real IP address.
If you can get decent internet, and have a failover set up with mobile network and UPS or a battery included device like a laptop I don't see why you can't run a channel on it.
If the network is crappier than 30mbit maybe avoid but that's not many places anymore.
reply
I love this. Great idea.
Question - Regarding the SeedSigner. The concept seems great. I have one that somebody gave me.
What do I need to be worried about when using it?
reply
Protecting the cardboard that it needs to scan to get the private keys, every time. Better to use a steal QR code plate.
Then making sure to power off the device after each use, since private keys are in memory.
Ideally you use seedsigner in a multisig.
reply
Why ideally in a multisig? Would it not initially be good to just replace your, say, Ledger wallet with a Seedsigner?
reply
With ledger your key lives on a secure chip on the device that used to be incredibly difficult to get off for security reasons. Now they offer it as a service...
With seedsigner the key does NOT live on the device at all. It lives as a QR code that it needs to scan every time you use it. Someone sees it or takes it then you just lost all your funds.
reply
Right, I got that. So it sounds like you're saying - replacing a ledger (or the like) with SeedSigner is great, even better would be to set up a multisig wallet.
reply
No I don't think it would be great on it's own. It greatly lowers the security.
reply
Switching from a Ledger to a SeedSigner would greatly LOWER the security? Would you mind explaining a little further, I don't understand.
reply
My previous comments explain it as best as I can simplify it. You might want to watch a tutorial on how seed signer works.
With seed signer the key is on a piece of paper or steel plate you have to keep along side the device when you want to use it. With ledger the key is on a secure element inside the device that requires significant effort to get off.
Secure element > piece of cardboard
Is anyone aware of advanced discussions or proposals on paying for tx routing/relaying as a way of directly incentivizing node running?
I realize that this is very nontrivial which is why I think it's interesting to think about. We pay miners because they are doing a lot of provably hard work, but is it possible to trust minimally pay for less provable or less hard work?
reply
For bitcoin core node running?
Dandelion is probably the most advanced and well talked about protocol for transaction relaying, but that's significant IIRC, and no monetization.
There's no way to prove that transactions you relayed to another person eventually gets relayed to a miner. Instead of paying people for a possible service, IMO it's best to rely on the default bitcoin core logic which does it's best to ensure propagation while trying to protect privacy the best it can. Or to broadcast over tor to blockstream, mempool, etc. for privacy reasons. Perhaps you can pay them if you want but I don't think they'll care about charging for that.
reply
There's no way to prove that transactions you relayed to another person eventually gets relayed to a miner.
I know there's no current way to, but that's kind of the point of the thought exercise. Is there a way to hypothetically?
reply
There's already direct incentives to run a node. It's not monetary but you have much better privacy and sovereignty if you run a node.
reply
But no direct incentives for relaying which is why many nodes don't relay given the tradeoffs, right?
reply
Most people don't because they don't have a public ip. It's not really the end of the world if 99% of nodes don't allow inbound connections. As long as a decent size do, it should be fine.
reply
Is that true? Most of us behind nats are on tor but still don't relay. I might be missing something though.
Regardless, the question isn't so much "why should we" but "how could we." I suspect the answer is interesting even if it's undesirable/impractical/pointless. ie I'm not asking the question because I want this in Core. I'm asking as an exercise in incentive design for decentralized systems.
reply
you relay between your different connections, you just don't accept inbound connections
reply
922 sats \ 1 reply \ @k00b 1 Jun 2023
That makes sense. But why aren't we all accepting incoming on tor if it makes no difference?
That is, assuming it's not privacy or bandwidth or some other form of "self-defense" that could be marginally influenced with incentives.
reply
you can just add listenonion=1 to your config
When lambo?
Just kidding. Sorry, couldn't resist. That was a high time preference moment...
reply
When Nissan micra?
reply
I don't get the hype around miniscript.
reply
Harder to shoot oneself in the foot and easier for non-programmers to read?
reply
Can you have a cold lightning wallet? How?
reply
I know it''s possible to check whether my LN node can find a route to pay an invoice. Is the reverse possible? I.e., is it possible to check whether a node can route a payment from it to my node?
reply
That's called probing. And is kind of shity procedure, creating a lot of friction and waste.
reply
121 sats \ 2 replies \ @kr 1 Jun 2023
one thing i don’t understand well is how bitcoin protocol changes are made.
is there a specific framework or decision making system bitcoin core maintainers use to determine whether an update should be merged?
is there a specific process for aspiring bitcoin core maintainers to become one?
if the answer to either of those questions is no, my follow up is why not?
reply
989 sats \ 1 reply \ @ek 1 Jun 2023
Good questions! I try to regularly review PRs and even have a PR merged into core but I am still mostly oblivious about how bitcoin protocol development and maintenance is organized.
is there a specific framework or decision making system bitcoin core maintainers use to determine whether an update should be merged?
Regarding frameworks, there is USAF which was used for SegWit and "Speedy trial" which was used for Taproot [0,1]. I think controversy in PRs is also considered.
There is also a system of abbreviations:
Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.
Tested ACK - Reviewed the code changes and have verified the functionality or bug fix.
ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.
NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
like used here. Extensive use of ACK'ing specific commits can be seen here.
The definitions of these terms are all over the place however.
For example, afaict, it's no longer mentioned in doc/developer-notes.md. Seems like the explanation moved to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review which is missing utACK and tACK however but mentions the difference between Concept ACK and Approach ACK.
is there a specific process for aspiring bitcoin core maintainers to become one?
The discussion in the PR about glozow becoming a maintainer gives some insights about the process (or lack of).
reply
appreciate the detailed response, thanks!
reply
It safe to deterministically split your seed in two parts (e.g. words 1-6 ==> part1, and 7-12 ==> part2), and store them separately? Or can the whole seed be guessed/restored from just knowing one part?
reply
It's very difficult to brute force 6 words, but not beyond the realms of possibility. Here's an example of someone brute forcing the last 4 words of a 12 word seed phrase in a day:
Note: It's much easier to bruteforce the last word as this is just a checksum.
But the BEST reason not to do this is because it's just inferior to using a passphrase. Both are 2-of-2 schemes, but a passphrase is A) Easier to memorise, B) Gives you plausible deniability with the seed-only wallet and C) Is an industry standard supported by every hardware wallet.
reply
Don't do it, having 6 of the words makes the last 6 feasible to brute force:
reply
deleted by author
reply
351 sats \ 8 replies \ @ek 1 Jun 2023
How do legacy nodes verify SegWit transactions?
I read something about that they consider them "anyone can spend" transactions. But doesn't that mean they thought they could have spend that output, too?
reply
They don't. From their point of view segwit outputs are weird scripts that anyone can satisfy – anyone can spend outputs.
That's basically how all soft forks work: we tighten the rules on something that previously didn't really have rules. Eg my own soft fork, CheckLockTimeVerify, reused NOP3, which previously did nothing at all.
reply
132 sats \ 2 replies \ @ek 1 Jun 2023
Thanks for your answer. But I am still confused
They don't. From their point of view segwit outputs are weird scripts that anyone can satisfy – anyone can spend outputs.
Isn't this a contradiction? They think anyone can spend it but they don't think they can? I think that's where my confusion is: Wouldn't legacy wallets show a false balance by including these "anyone can spend" outputs as spendable outputs?
For me, a node validating transactions is similar to a wallet checking which utxos it can spend. Or is there something wrong with this analogy?
reply
You're assuming Bitcoin nodes have intelligence that they don't. They don't "think". They're computer programs that follow rules. Pre-segwit rules allow those outputs to be spent by anyone; post-segwit rules don't.
As for wallets, they would never create such scripts so they'd never show those scripts as part of their balance.
reply
235 sats \ 0 replies \ @ek 1 Jun 2023
You're assuming Bitcoin nodes have intelligence that they don't. They don't "think". They're computer programs that follow rules. Pre-segwit rules allow those outputs to be spent by anyone; post-segwit rules don't.
Okay, this makes sense and clears things up, thanks!
As for wallets, they would never create such scripts so they'd never show those scripts as part of their balance.
Okay, interesting. Thanks! I have to look more into how wallets behave
reply
How I think about it
Segwit transaction outputs are locked by a condition that looks like this 0x0014<20 byte-key-hash>. An old node would look at that and interpret it as push an empty array on the stack, then push 20 bytes on the stack. There are no signature checks or anything. By it's rules, anybody could spend it, even by just putting 0x00 in the scriptSig of the input that spends the utxo. A post-segwit node would look at 0x0014<20 byte-key-hash> and see it as a template for a P2WPKH transaction and only verify it if it provided the correct pubkey and signature in the witness part of the transaction.
Let's say you had a pre-segwit node and were running a separate program that looks for transaction outputs whose locking conditions are only data pushes and then spends them. After segwit, your program would not work because it would try to spend the outputs, but the rest of the network would say you need to have signature in the witness part of the transaction.
reply
187 sats \ 1 reply \ @ek 1 Jun 2023
After segwit, your program would not work because it would try to spend the outputs, but the rest of the network would say you need to have signature in the witness part of the transaction.
I see, thanks!
I think that's also where the discussion about "what is a full node" comes up since a legacy node does not validate the new rules thus it does not validate all rules. So is it no longer a full node?
I encountered this topic recently in a TG group I am in. People were discussing what a full node is in the context of banning ordinals.
reply
Interesting! I've never thought about a full node in that way but my initial reaction is that it still counts as full because i can send/receive any bitcoin with a wallet that uses that node.
reply
Question:
Has CoinKite added Taproot support to the ColdCard yet? Is there a firmware update I can do for my ColdCard to add Taproot?
If so, will it require more than just an upgrade, or will I need an entirely new wallet with new seed words?
reply
Is it profitable running a Lighting node and is it more recommended working with your own Lighting email?
reply
Why hasn't everyone read "The Creature from Jekyll Island" yet? It should be required reading for every person on this planet!
reply
Because the creature is not running a LN node
reply
If I broadcast a transaction and it is in the mempool, what is the exact mechanism if I try broadcasting that same UTXO spend to a different address again (before it is mined). How does the software know which transaction is valid? Also, can you force a miner to mine the same UTXO twice e.g. offband, what is the mechanism for the miner to know which spend of the UTXO is valid?
This sounds obvious maybe, but I want to understand the exact function that handles this the order / priority of ‘the same spend’.
reply
1325 sats \ 1 reply \ @fanis 2 Jun 2023
Handling of concurrent transactions (two transactions spending the same UTXO, eg "double spending") is a local policy, meaning each node is free to use whatever rule they want as long as it doesn't break any of the protocol's rules.
Now there is, of course, the default policy in Bitcoin Core, which often ends out being the default policy of most of the network. Historically it was a "first-seen" rule: nodes would consider that the first version of the transaction they see is the "right" one, and hence consider any subsequent attempt at spending the same coins as invalid.
Then came Opt-In RBF, which is the current default in Core. Through this mechanisms, transactions can signal (using nSequence) that it's ok for them to be replaced by a concurrent transaction, under some conditions. One of the conditions is that the replacing transaction must pay more fees than the original one, and enough so to prevent spam/DoS attacks. So, to put it shortly, the version of the transaction that pays the most fees takes priority.
However, it is still possible to double spend a transaction that doesn't signal RBF. That's because some nodes implement a distinct policy, which is to allow any transaction that pays more fees to replace the original one. This policy particularly makes sense for miners, as it allows them to extract more revenue. Some nodes in the relay network also implement this policy, and even if a small portion of the network does, it might be enough for my transaction to reach a miner, although it will probably take more time to propagate.
That's one of the arguments in favor of Full-RBF, which was merged into Bitcoin Core a few months ago but is off by default. Full-RBF essentially looks a lot like Opt-In RBF, but without the requirement for transactions to actively signal they're eligible for replacement.
So to more directly answer your question: it depends! There will be two (or more) concurrent transactions, out of which only one can ultimately be mined into a block. But they're strictly speaking all valid. You can nudge other nodes, and notably miners, to consider the transaction you'd like to be mined as the "real one" by setting higher fees, but that's ultimately up to them. You can't force them. Once your transaction is out there in the wild and you want to replace it, all you can do is hope miners learn about the replacement transaction and decide to mine it over your initial transaction. Which is the case 99% of the time, because miners want money.
TL;DR: we used to use a "first seen" priority rule but it doesn't align with miners incentives and can yield different results across the networks. The current widespread rule is that whichever transaction pays the most fees is the one that takes priority. But anyone can implement whatever stupid rule they want on their own node. If their rule is really stupid, they'll just disagree with everyone else more often, but converge onto the most-work chain anyway.
Got a bit verbose here, but I hope it helps answer your questions!
reply
Thank you for this excellent answer! This cleared it up for me.
reply
20 sats \ 1 reply \ @kr 1 Jun 2023
linking @moel’s question from earlier today as it hasn’t been answered yet:
reply
yeah sometimes good post questions are lost in the ocean of repetitive posts with tweets and crap news... sad.
reply