Dawid Ciężarkiewicz

> After talking with @elsirion it's probably best we update `rand` in our libraries first. While even better, it doesn't seem necessary to do in the same PR. Any other...

I see #600 will update the crypto binaries. If you want to land it before the rand bump because it's more important that's fine with me.

> I think now we should be able to remove the `Rand07Compat` wrapper and use `OsRng` everywhere, right? Will be much cleaner that way. I hope so, yes.

We're not using nightly RN, and who knows if this lint even hits stable, so closing for now.

> Allow users to output additional fees to existing transactions either via a new BumpFee output type or by modifying the existing PegOut The problem is that UTXOs are a...

> Do they have more weight/ are more costly in general ? Because if user A pays 2sat/vbyte but then the fees suddenly rise (e.g 14sat/vbyte )and it gets stuck...

1 is probably a best approach to start with. However I would expect elements of 2 might become necessary eventually, so it's probably worth keeping them in mind.

> somebody maybe having the necessity to move funds quickly - being regarded as higher time preference It's not a moral judgment, just stating the fact of life. Sometimes we...

I tried and: > Unfortunately seems blocked on `bitcoincore-rpc` pulling in previous `bitcoin` version, which pull in old `secp256k1` which is still on `rand = 0.6`

Seems there's already a PR for that: https://github.com/rust-bitcoin/rust-bitcoincore-rpc/pull/234