Too Embarassed To Ask - Your Bitcoin & Lightning Questions Answered \ stacker news ~bitcoin

Too Embarassed To Ask - Your Bitcoin & Lightning Questions Answered

2978 sats \ 73 comments \ @sn 1 Jun 2023 bitcoin

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!

view all related items

2269 sats \ 3 replies \ @TonyGiorgio 1 Jun 2023

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?

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

source: https://fiatjaf.com/drivechain.html

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)

66 sats \ 0 replies \ @TonyGiorgio 1 Jun 2023

The misaligned miner incentive problems are pretty big one IMO.

1320 sats \ 0 replies \ @DarthCoin 1 Jun 2023

2256 sats \ 7 replies \ @tmoney 1 Jun 2023

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?

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

1408 sats \ 3 replies \ @tmoney 1 Jun 2023

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.

40 sats \ 2 replies \ @ek 1 Jun 2023

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.

100 sats \ 1 reply \ @tmoney 1 Jun 2023

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.

30 sats \ 0 replies \ @ek 1 Jun 2023

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

132 sats \ 1 reply \ @criptopanas 2 Jun 2023

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???

66 sats \ 0 replies \ @ek 2 Jun 2023

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.

-- #187000

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.

628 sats \ 1 reply \ @mudbloodvonfrei 1 Jun 2023

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?

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).

-- https://jonatack.github.io/articles/how-to-contribute-pull-requests-to-bitcoin-core

470 sats \ 8 replies \ @BlokchainB 1 Jun 2023

How dangerous is it for me to run a clear net node? I am sick of tor and I want to route payments!

10 sats \ 7 replies \ @DarthCoin 1 Jun 2023

Dangerous from what?

132 sats \ 6 replies \ @BlokchainB 1 Jun 2023

You tell me! Everyone says to run a node behind Tor to not leak your IP address.

1373 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.

66 sats \ 0 replies \ @BlokchainB 2 Jun 2023

Main fears

Getting hacked
Node becomes huge and become a target for meatspace crime

217 sats \ 3 replies \ @DarthCoin 1 Jun 2023

tunnelsats.com - done If you want to route you must be public and visible and reliable. If you want privacy, then run private nodes.

1074 sats \ 1 reply \ @m00ninite 2 Jun 2023

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.

https://github.com/allyourbankarebelongtous/Pleb-VPN

0 sats \ 0 replies \ @DarthCoin 2 Jun 2023

LOL very cool name !

1293 sats \ 0 replies \ @l0k18 1 Jun 2023

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.

582 sats \ 7 replies \ @0307572b6c 1 Jun 2023

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?

198 sats \ 6 replies \ @TonyGiorgio 1 Jun 2023

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.

66 sats \ 5 replies \ @0307572b6c 2 Jun 2023

Why ideally in a multisig? Would it not initially be good to just replace your, say, Ledger wallet with a Seedsigner?

894 sats \ 4 replies \ @TonyGiorgio 2 Jun 2023

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.

66 sats \ 3 replies \ @0307572b6c 2 Jun 2023

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.

66 sats \ 2 replies \ @TonyGiorgio 2 Jun 2023

No I don't think it would be great on it's own. It greatly lowers the security.

116 sats \ 1 reply \ @0307572b6c 3 Jun 2023

Switching from a Ledger to a SeedSigner would greatly LOWER the security? Would you mind explaining a little further, I don't understand.

66 sats \ 0 replies \ @TonyGiorgio 3 Jun 2023

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

reply on another page

354 sats \ 9 replies \ @k00b 1 Jun 2023

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?

1131 sats \ 1 reply \ @TonyGiorgio 1 Jun 2023

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.

66 sats \ 0 replies \ @k00b 1 Jun 2023

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?

132 sats \ 6 replies \ @benthecarman 1 Jun 2023

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.

922 sats \ 5 replies \ @k00b 1 Jun 2023

But no direct incentives for relaying which is why many nodes don't relay given the tradeoffs, right?

922 sats \ 4 replies \ @benthecarman 1 Jun 2023

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.

922 sats \ 3 replies \ @k00b 1 Jun 2023

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.

922 sats \ 2 replies \ @benthecarman 1 Jun 2023

you relay between your different connections, you just don't accept inbound connections

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.

1744 sats \ 0 replies \ @benthecarman 2 Jun 2023

you can just add listenonion=1 to your config

reply on another page

172 sats \ 1 reply \ @mudbloodvonfrei 1 Jun 2023

When lambo?

Just kidding. Sorry, couldn't resist. That was a high time preference moment...

10 sats \ 0 replies \ @DarthCoin 1 Jun 2023

When Nissan micra?

361 sats \ 1 reply \ @benthecarman 1 Jun 2023

I don't get the hype around miniscript.

0 sats \ 0 replies \ @Lumor 3 Jun 2023

Harder to shoot oneself in the foot and easier for non-programmers to read?

1214 sats \ 0 replies \ @axzwk 2 Jun 2023

Can you have a cold lightning wallet? How?

1222 sats \ 1 reply \ @shyfire 1 Jun 2023

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?

0 sats \ 0 replies \ @DarthCoin 1 Jun 2023

That's called probing. And is kind of shity procedure, creating a lot of friction and waste.

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?

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.

-- https://github.com/bitcoin/bitcoin/issues/6100#issuecomment-98471846

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 CONTRIBUTING.md 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).

[0] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki [1] https://taproot.watch/ [2] https://bitcoincore.org/en/meetings/

21 sats \ 0 replies \ @kr 1 Jun 2023

appreciate the detailed response, thanks!

948 sats \ 3 replies \ @steepdawn974 2 Jun 2023

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?

431 sats \ 0 replies \ @orthwyrm 3 Jun 2023

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:

https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752

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.

100 sats \ 0 replies \ @Lumor 3 Jun 2023

Don't do it, having 6 of the words makes the last 6 feasible to brute force:

https://btctranscripts.com/andreas-antonopoulos/2020-04-08-andreas-antonopoulos-seed-splitting/

0 sats \ 0 replies \ @1sats 3 Jun 2023

deleted by author

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?

987 sats \ 3 replies \ @petertodd 1 Jun 2023

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.

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?

586 sats \ 1 reply \ @petertodd 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.

As for wallets, they would never create such scripts so they'd never show those scripts as part of their balance.

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

358 sats \ 2 replies \ @tmoney 1 Jun 2023

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.

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.

1563 sats \ 0 replies \ @tmoney 1 Jun 2023

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.

193 sats \ 0 replies \ @DarthCoin 1 Jun 2023

@petertodd ?

264 sats \ 0 replies \ @fiatbad 1 Jun 2023

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?

262 sats \ 0 replies \ @guts 3 Jun 2023

Is it profitable running a Lighting node and is it more recommended working with your own Lighting email?

198 sats \ 1 reply \ @fiatbad 1 Jun 2023

Why hasn't everyone read "The Creature from Jekyll Island" yet? It should be required reading for every person on this planet!

0 sats \ 0 replies \ @DarthCoin 1 Jun 2023

Because the creature is not running a LN node

66 sats \ 2 replies \ @chungkingexpress 2 Jun 2023

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’.

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!

834 sats \ 0 replies \ @chungkingexpress 2 Jun 2023

Thank you for this excellent answer! This cleared it up for me.

20 sats \ 1 reply \ @kr 1 Jun 2023

linking @moel’s question from earlier today as it hasn’t been answered yet:

#186720

249 sats \ 0 replies \ @DarthCoin 1 Jun 2023

yeah sometimes good post questions are lost in the ocean of repetitive posts with tweets and crap news... sad.