You're unlikely to break the blocks db just learning the basic commands, but there are blocks commands cli that could potentially mess it up (invalidateblock for instance)



Put any backup on a different disk, then both disks would need to stop working at the same time to force you into total re-sync

RISC-V is the only open instruction set out there, or at least the only modern design (the older MIPS stuff was open sourced recently if I remember rightly)

The only way to get total control of an open ISA as an end-user is to validate the chip design all by yourself, then fabricate the chip yourself in your garden shed. Presumably that's what you intend to do?

Sounds interesting, hopefully it's implemented in Epochtalk too (or is easily done)

Another useful feature would be to filter such a list by rank. Not much point in keeping track of newbies posting in dubious threads

It exists: the RISC-V ISA

The Bitcoin developers are ahead of the game somewhat, Bitcoin core 0.18.0 release will have RISC-V binaries

And compare that to typical internet banking uptime; 2 outages in 10 years, and now up for 5 years and counting is an unbeatable record



Some people are already on a meshnet

Some threads are (to me) only started with the intent to troll, and I don't read or post in them if I suspect that


The author is displayed on the board's page, but I'm also interested in a list of those who reply. Those who reply are either too dumb to realise the thread is trolling, or they can tell too but they're happy to perpetuate the thread for whatever reason.

A function to get a list of people who posted in a given thread would be useful, trawling the thread for usernames manually would be time consuming (and only gives it more views)

You're right, I don't know how I skipped over that



I see your point: multi-sig using Musig looks like a 1 input transaction when spending from a Musig address, regardless of how many signers are needed to pass the threshold. But the way I understand it, it's Schnorr's additive keys property that confers that quality, and not Musig per se.

Certainly, Musig is designed at least in part to prevent the attack I described in my previous post, an attack which is a consequence of using additive public keys to generate the public key for a multisig address. So it seems logical that it's Schnorr that's improving multisig privacy, and Musig that mitigates the risks of using Schnorr signing for a multisig address.

Remember that these are confined to the network layer of Bitcoin:

1. With BIP156, your IP address will no longer be tied to your personal transactions from the perspective of connected Bitcoin nodes.
2. With BIP151, all relayed transaction data will be encrypted from the perspective of someone analysing internet traffic (but connected Bitcoin nodes will still see the transactions unencrypted).


Neither of those BIPs will change the ability to analyse transactions on the blockchain



No, Musig Schnorr makes using multiple inputs less expensive. This only incentivises coinjoins, it does not make them any more private.

edit: Musig is for threshold based multisig that is safe to use with signature aggregation (without Musig, the last person adding their sig to an n of n aggregated public key could cheat by throwing out all the previous keys and replacing them with 1 key that belongs to them, and pretend that all the previous people's keys are aggregated together into it, so they can steal everyone's money). And so Musig doesn't have anything to do with privacy or anonymity on the blockchain either

Brock Pierce is only an enthusiast for living with convicted paedophiles and attending dubious parties where teenagers are invited to do drugs with adults from the US entertainment industry (Brock Pierce is a former child movie actor himself). That's more than controversial.

I think only the chainstate database changed format, and I would assume the torrent file contained only the blocks. It makes no difference anyhow, the torrent is probably not being seeded anymore, and of course using Bitcoin to do the IDB is, as you say, quicker in any case

I doubt that's being updated any longer, it was superseded by "headers-first" downloading in version 0.10 (parallel downloading didn't work before headers-first. Bittorrent only downloads, it doesn't check the blocks, which is what really takes all the time). Version 0.10 was a very long time ago.

A future feature called "Splicing" will enable this functionality. It's a fairly new idea though, it will take a while to get implemented in Lightning software.

The idea is for both "Splice-In" (what you're asking for: adding on-chain funds to a pre-existing channel, without closing the channel), as well as "Splice-Out" (withdrawing funds from a channel using an on-chain tx, without closing the channel)

The Eclair developers will apparently release a new version later this year that lets you receive lightning payments

There's a handful of people (3 or 4 I think) that have merging rights to add or remove from Bitcoin's code. Then there's dozens of contributors who offer changes. The 3-4 that push the merge button only do so when they get the agreement of at least another 3 or 4 code contributors who are regulars on the project. If it's something totally trivial, like changing documentation, the mergers might not bother wasting time getting agreement first, though.

It's pretty informal overall (and typical for an open source project in that regard).

You don't need to "want to believe", it's already much simpler if you stick with wallet default settings.


The simplest, and default way to setup a Lightning wallet is like this:

1. Send some BTC to your wallet
2. Wait till the wallet finishes automatically opening some channels

That's true, it's 100% routable if it's a direct channel



Those steps are only needed if you want more control. By default, lightning wallets will use an autopilot mode that handles the detailed setup

Are you suggesting as such on your site (opening a channel to your node)? That's a pretty good way of making your node well connected and routing alot of payments

This demonstrates the lightning model; any regular business can encourage their clientele to open channels direct to them, which makes financial sense for regular clients. You're basically your own mini-payments service, VISA can't compete with that.

We've discovered an issue though: it's possible to confuse "dual-funding" and "bi-directional". Maybe there's a different phrase that could be used to make them both more distinct. Perhaps "dual-funded" channels could be referred to as "balanced" channels, and "single funded" channels as "unbalanced"

also, people might get the idea that channels only flow one-way (as you did). Perhaps that can be made clearer somehow too.

You made a mistake using racism as an argument. It's guaranteed to end in an unproductive, confrontational thread.

And of course, you're now being labelled racist. These sorts of arguments are very predictable like that, you have yourself to blame in not doing so

There's no need to open a channel with the store. As a user, the minimum setup is 1 channel, to any well connected node. The software and the network takes care of the rest.

That doesn't mean you can't do all the configuration yourself, as you describe. But the idea is to simplify the process, what you've written is the most complicated way, and in the case of the channel with the store, unnecessary.