I'm a bit confused because I replied here to the previous poster taking part of the discussion and why my post was deleted. It seems I'm on the wrong foot with some of the moderators here.

My point was targeted at the "lightning child's play" of a previous commenter.

Glad if the post gets restored.

(But I guess this one will be removed as well..., not sure what I did wrong ...)

Lightning is a workable solution and we're using it all the time and it works well. Yes the force close and channel fee issue needs to be addressed (imho watchtowers should be able to process channel closures as well ... but that's another story)

And the protocol should be changed to have force close to a maximum of agreed fee, not the agreed fee per se.

There's a few things to be tweaked to get rid of those issues (the watchtower channel closure would be a big boon in reducing potential funds loss due to both inaccessible nodes.

I don't think it would be too difficult to co-sign a close transaction from both nodes that are weeks in the future and distribute them to watchtowers. Then watchtowers should be closing channels if they don't see sign of life for x weeks / months and should be able to also determine on-chain fees at the same time. You will lose a channel to a rogue node at most, but will never open a node with them anyway again so the loss is minimal.

It could be elective too so perhaps both parties need to agree to this.

Other than this, Lightning is spectacular. Who else gives you <1s settlement worldwide basically unlimited volume and you are STILL 100% SELF CUSTODIAL.

I think he's knowingly misleading people who now praise their leader for finally getting back to all these evil countries...

The only problem is that this `reciprocal` tariff is based on lies and fabrications...

If you import into the EU, then the custom tariff is mostly 0% but of course certain product groups have a small custom associated with them.

Then you pay ~20 GST on importing and this is seemingly what he uses as an attack point. However, businesses can just forward these 20% down the chain and it's how all taxation in Europe works, from internal or external sources. So ... in one word: It's all bullshit and he just, as usual, doesn't understand what he's rambling about.

Bitcoin Core 28.1 has been released but the banner here still says Bitcoin Core 28.0.

I think it's not great that bitcoin becomes this "toy" for rich people.

I don't know what Saylor's ultimate goal is but I think we should be weary. He has no kids, seemingly nobody to pass them on. I really wonder why he's doing this.

And yeah it sounds nice to hear that he's a Bitcoin maxi and whatnot, but I still would like to understand the guy. Not saying he has bad intentions, but I don't understand it and find it suspicious.

Maybe the best we can hope is that he DOES sell, so we can use Bitcoin again as it was intended. As a means of exchange.

There is so much FUD about it. I know someone who is heavily invested in Crypto, heavily! But yet I ask him if he's holding any Bitcoin and his answer was "which Bitcoin, there are so many". I said "BTC" to which he said, oh that one, no he's not.

He's invested in ETH and its offspring.

It's saddening to be honest. But then these people are just seeing it as an investment and don't really see the values of Bitcoin that most of us see here.

Not sure solo mining with this setup would be beneficial... even at 20TH you would have 683 years between blocks, according to solochance.org

I'm using the Coinbase Wallet, it's self custody, a continuation of the Bread Wallet (BRD). I think they were acquired 5 years ago.

It works well and has the advantage of tying as much as it can into the Coinbase ecosystem. It's still self-custody and I find it usable. It's not supporting lightning of course. (but then most lightning wallets do have some limitations, either they aren't really using lightning like Muun, or receiving constantly fails with Phoenix. Those are the two I tried and I could be an outlier having bad experiences with these)

Actually for lightning you could use your own node, that's what I'm doing. But it of course gets a bit more complicated then. I run LND and have a few scripts that can generate invoices and pay invoices, nothing fancy. you have to have a server running at leaset while transacting, which could be a problem and you will need to have access to that server.

I haven't explored the ready-made solutions like Raspiblitz or Umbrel yet.

I was thinking this thread is about mining in the Solar System, so I thought this is about having a blockchain on Mars etc... 

Great discussion though! Many users are mining and using excess heat for heating purposes, then the whole calculation changes a bit ...

I found Jimmy Song's "programming bitcoin" very interesting !

Thanks. Yeah if I had known it's deprecated I wouldn't have used it. If it's marked as such, I've overlooked.

But I've already developed it, so ... sunk cost fallacy :-)

Thanks, yes I'm doing this but to make it effective, I have to do another transaction with the final vsize...

I was wondering if there is another RPC that would allow me to get the vsize easily without building the transaction first.

Thanks a lot, very helpful!

Yeah, I'm actually quite comfortable with createrawtransaction from an API and parameter stand point. What I do is to always display the whole transaction (decoderawtransaction) including all inputs, outputs and fees and a breakdown in percentages to make sure that all is good.

I haven't tried on a bigger transaction and I'm too lazy to set up testnet, all my bitcoin dev was always done live and I've never lost any funds but for this project I'm a bit cautious for obvious reasons. I'm happy to experiment in the 10-20 USD range if blockchain fees allow.

Yes, if consolidating, picking up the fee for 1-2 transaction makes the cost negligible if you're consolidating >50 transactions anyway (and I try to keep them around 100 or a bit less - need to work out what is the best tradeoff in regards to diminishing returns and taking advantage of low blockchain fees at that moment is)

One thing I've not figured out is an easy way to see the size of the transaction beforehand to make a good calculation of the fee. I'm creating two transactions actually, first one with a dummy fee of 1sat, and then replacing this when I know the actual size of transaction and fire off only the latter one.

Thanks I'll check it out !

that's interesting. Would be cool to see the signing of messages solved again for other than legacy address in bitcoin core.

Thanks, however I seem to be unable to do this via the GUI. Even when selecting outputs manually it only shows those that have confirmations, I cannot choose an output that is unconfirmed.

So it seems CPFP is impossible via the GUI.

I haven't seen what happens if I try to do it via 'sendtoaddress' RPC but I'm pretty sure it will just say "insufficient balance" if I try to include the whole balance of confirmed and unconfirmed UTXO.

I believe creating a rawtransaction is the only way to do CPFP in Bitcoin Core and that's why I've implemented it this way. Please let me know if I'm wrong :-)

Thanks for the reply!

Yeah, I'm decoding the transaction afterwards to see if the transaction makes sense. I'm taking care of the fee, yes. The address I sent too isn't a new address so the `iswatchonly` is false (but then, the wallet I've tested this is a watch only wallet, ... (since it's a live server...)

We have a a few people now and then that send payments with too low a fee and we want to do the "nice" thing to speed them up when we consolidate so they don't have to wait forever. It worked well, but I've tested it on a cheap transaction (less than 100,000sats) and I want to see if there any common pitfalls before I deploy this as a general automated thing.

If Bitcoin Core would support including unconfirmed UTXO (perhaps from the enable(d) coin control features) that would be great. I think the change in the code may be minor, but I'm not a good enough coder to even try setting up compiling it myself.

Back to the topic, I'm actually making two transactions. I'm making one with a dummy 0.00000001 fee first, then see what the vsize is, then applying the correct fee for the final transaction throwing away the first one. Surely there must be a better way ?

And I can see the sendrawtransactions has a failsafe to send transactions with high feeds, I've of course set that to a prudent value. The default value of 0.1 BTC/vKB is way too high. The maxburnamount is set to 0.00 but as it's written in the doc it's not a guarantee that the output can't be spent under all circumstances.

But yeah, I'm just using these commands (create, sign, and send-raw transaction) and if there is no way I can create an unspendable output this way (considering fee and receive address) then I've something less to worry about.

Hi Guys,

I need your advice. I'm creating my own transaction using createrawtransaction / signrawtransactionwithwallet / sendrawtransaction (to overcome the missing CPFP in bitcoin core) ...

Is there any danger to create an output that is unspendable? I'm getting a few payments and sometimes people send with too low a fee, my idea is to consolidate and then include the unconfirmed UTXO from those senders.

But of course, I'm a bit worried to create an unspendable output by mistake. The documentation doesn't mention it, so I assume this cannot happen?

I did a test-run and I'm getting this

"spendable": true,
"solvable": true

when checking on the receiving wallet. Is this enough guarantee that the output can be re-spent?

TIA

Yeah this sideways movement is kinda boring. either go up or down, but do something Bitcoin!!