pull down to refresh
9 sats \ 3 replies \ @krawall 14 Feb \ on: The Solo Beef Block: analyzing a mysetrious block and a secret mining pool? bitcoin_Mining
*piqued not peaked.
Pretty much the easiest way to run your own node. Plus people still use it for transacting on the block chain. Bitcoincore + Coldcard is a very good solution. Bitcoincore is also very easy to script for your own projects...
It's easy with Lightning but takes a bit of work. Just add two nodes to your computer, one is the funding node, the other one is the receiving node.
Move your KYC to your funding node, send to your receiving node via Lightning, close channel. Done. They are on-chain now and non-KYC.
Great to see America is doing everything to obsolete itself. At least working for a goal, unlike the rest of the world. Obligatory "I'm not sure if it's good or bad but we'll find out".
I particularly like your questioning of needing passports and such. Isn't it such an odd thing to request from a person?
You need to show proof that you are who you say you are and we take that piece of paper that we will trust, but we will not trust you.
Seems to me that passports should be sued when one decides to commit crimes overseas.
Well if I can travel in time, then I can travel to the far future where they have FTL transportation through space :-)
Normally when node peers communicate with each other, they will agree on blockchain fees periodically. What can happen is that if the last time the blockchain fees where agreed is when the blockchain fees were high. Then let's assume (because it was a force close anyway!) that one of the parties became unresponsive and then the force close will happen with the agreed high blockchain fee.
As per the "RBF", this is tricky because replace-by-fee creates a new transaction id and this new transaction fee may be unknown to the lightning node(s) in question.
LND handles bump fee with "child pays for parent" so that the original funding transaction goes through no matter what. If you were to bump a funding transaction with RBF then your channel will not get opened at least by your counterparty because they are looking for the original funding transaction to go through. For close it's surely the same, now for Force Close, I agree, it could just RBF but that's all really above my pay grade here :-)
If only I could send more funds to Phoenix.. I only get "transaction will fail" when trying to send more than a few hundred K. Any phoenix dev here? I've been not having luck raising them.
How are you guys doing it? I'm looking to be around 6months behind release, or at least 3months but only if there are compelling reasons, so that I'm not on a any bleeding edge bug ... That's for the product nodes.
Private "for fun" nodes I keep updated unless I have wallets on them that contain coins.
Yes, neither of them will do what they say, but that's because Trump is just doing whatever he wants and says whatever is opportunistic in the moment or has a meltdown and rambles, and Harris because she has great intentions but will be blocked by GOP partisans. It's just simply what happens (disclosure: not American)
there seem to be a few different implementations out there... .for instance I never got AMP invoices paid with other wallets (including binance) for instance Muun ...
It's a tight rope act to deploy a lightning service that works for most wallets / exchanges.
thanks...
well binance is easy ... and I just happen to have funds arriving there (and we may have customers using binance to pay, too, I can't ask them to go to another exchange easily ...)
Hey @megaptera,
thanks yes ... I completely understand that this appears to be a problem with Binance, but it's rather silly too, I mean, not supporting Binance is a big(ger) deal... so I wonder if we can just create legacy invoices that don't have this present (like it was in the minor -1 update before, it's kinda strange that they go from 18.2 -> 18.3 and have a change that affects the biggest exchange's ability to send to ...)