not convinced that's going to help long term tbh

Hong Kong is well-placed to be the blackmarket link into the Chinese industry from the rest of the world, not just geographically but logistically too (Hong Kong already plays this role and has done since before re-establishment of Chinese administration).

I don't know for certain, but Hong Kong probably already is the black market link from China to the rest of the world. Anything we can do to encourage independent Hong Kong businesses that are operating outside of Beijing's control is going to help Hong Kong more than buying masks for university students.



and that's ^^^ why.

These Hong Kong protesters feel like they're prepared for a war, but they're not soldiers, and they're not an army. Real soldiers from a real army are prepared to act as inhuman as it takes to change the protestor's minds. Right, wrong, justice; none of that matters to soldiers that are "just doing their job". sad, but true.

The protestors could go the physical route, but that means decades of asymmetric warfare. And that means being branded as domestic terrorists. If the do as I suggest, and create a parallel economy instead, they will probably still be branded as domestic terrorists. The difference is, that it's easy to get regular people to believe that a guerilla army fighting for freedom are really just terrorists, whereas smugglers and are harder to turn people against, especially if you're trading quality goods with the local people who the Chinese state need to sell their story to.

you can compile it anywhere you like, but my advice would be to put it somewhere in your user directory to keep things separate. then copy the bitcoind (and probably bitcoin-cli too) executables to /usr/bin (some people say it should be /usr/sbin, but it doesn't seem so important to me). then, the bitcoind.openrc script file goes in /etc/init.d, chmod it so it can execute, then rc-service bitcoind start (change the name from bitcoind.openrc to bitcoind first). you can add bitcoind to start-up with rc-update add bitcoind default (or to a different startup group to default, if you want)

dependencies huh? looking at the libraries I installed on my Bitcoin build VM, I have:

g++
autoconf
libtool
pkgconfig
libzmq5
libboostprogram-options-dev
libboost-chrono-dev
libbboost-date-time-dev
libboost-atomic-dev
libboost-thread-dev
libssl-dev
libevent-dev
protobuf-compiler

those ^^^ libraries are the Debian package names, so you'll need to find the equivalent name according to how Alpine has that particular code packaged. the protobuf one may prove annoying.

the -dev suffix is important for the boost libraries. and the version is important, there is a minimum version for boost (something like 1.60, typically more than one version of boost libs is available), but a maximum version for others. But for those with maximum versions, all the dependencies are bundled with the .git repo, as alot of them are part of the consensus rules and that's sensitive to change. that includes the annoying BDB 4.8 dep, which took me ages to figure out was part of the bundled deps.



and if you aren't using the GUI (I'd assume not), do ./configure --help to find the option that disables building the GUI, then you can avoid getting all the qt dependencies as well, which are entirely for the GUI and nothing else.

hmm. well it should be the same on everything really. you need that old version of BDB for the wallet, or you could just do ./configure --disablewallet and then that's not a dependency at all.

also, service files are different on Alpine, more configurable. https://github.com/bitcoin/bitcoin/tree/master/contrib/init has what you need, look at the the .openrc files

remember the error where it got stuck compiling?

something in your grub.cfg file that sounds like. It's hard, the recommendation is to let automated grub-mkconfig handle it by reading from /etc/default/grub, but if you look at /boot/grub/grub.cfg, it might seem more obvious what the problem is, might help with figuring out what parameters to put into /etc/default/grub. I know though, it's more trouble than it's potentially worth as it risks breaking the part that does work. I bet you could get it working when you get a good opportunity to try it out again



right, I've never bothered with docker. lxc might be more intuitive, although I've never tried that either!

glad to hear you stuck with Alpine though. it's kinda challenging to have to deal with an all cli interface, so choosing something tough and keeping going is good for the keyboard skills

how did this end up jack? did you get on with Alpine? It has a great reputation as a minimal distro, be interesting to hear more.

well, yes. that is the problem, many of the people reading this thread are doing so simply to save some time in choosing something out of the excess of choices. Equally bad even for the source-based distros I'm advocating; they've all got a different way of handling package installation, and learning them all to find out which you prefer would be too much

like in any market, good and bad products lead the pack. Red Hat are trying to use software engineering to change Linux into an entirely Red Hat product; bad. Debian was just a simple, reliable, conservative linux distro. Canonical and Mint started to infest Debian as a by-product of that success, Debian is now going (well, already gone) bad. Even in Gentoo, "purists" complain about antagonist devs pushing the distro in questionable directions. It'll probably remain like this till the closed-source model dies, and that's not going to happen soon.

this all sounds very elitist though (yet another Linux issue ). at the risk of contradicting myself, I'll say: if e.g. Ubuntu suddenly started getting massively popular against Windows, I wouldn't complain. At least not straight away

I now understand better the reason for having a high (95%) signalling threshold for entering soft fork activation periods; hard forks can be provoked with transactions that are crafted to break the rules introduced by the soft fork. So I guess something small was achieved out of all of this to-ing and fro-ing

i don't care to really

(i've since then agreed already that it's possible, why are you ignoring that?)


here's what we're supposed to be discussing:


this is wrong, by any definition

you've agreed it's wrong. you're not helping anyone in particular, least of all the OP

historically, such infrastructure has been built using private money, and it still is today. So your objection doesn't altogether make sense. but it is quicker and more organized/holistic when a centralized government performs it. well, sometimes it is



it'd be nice if we lived in a perfect world, where only trustworthy people attain positions of power in government. But those powerful positions always attract the crooked, posing cleverly as the trustworthy. Power is like that unfortunately.

buy things from people in Hong Kong who are resisting the Chinese Communist Party. That undermines the bullying regime in the most powerful way, without resorting to violence.

ok, well it's difficult then to see how any soft fork can be implemented without an inherent risk of a hard fork. You're basically saying that pre-fork nodes are blind to the new rules, and so one can break the new rules without the pre-fork nodes being aware, that's perfectly sensible.

But you're still wrong. The old nodes are not "accepting the new rules", as you said. They cannot be accepting any new rules, because they are not designed to recognize rules that did not exist before that version of the consensus rules were written, Bitcoin does not (yet) have an algorithm that can see into the future!

What's happening is that they do not understand any new rules, and blocks with transactions adhering to any new rules are interpreted as "no signature required", i.e. anyone can pay. How else, logically, could old nodes be capable of accepting tx's that both observe and violate a new soft-fork? It's because they don't know what the new rules are that they are able to accept both, that's how anyone-can-pay can function as a backwards compatible upgrade mechnanism, because it enables nodes following only the older rules to ignore any and all assessment of adherence to new rules with 1 universal rule: "this transaction is valid, because it has no spending conditions". Saying that's the same thing as accepting new rules (which you did) is not accurate.

You seem to be dancing around the semantics, for reasons that are

1. Not obvious. What is this achieving
2. Not relevant to the OP anyway


I could instigate an attack on the ambiguities of the way you've worded things too, but I'm not going to do it. Why do you think that is?

ok, instead of fanning the argument out into things everyone agrees with, let's stick to the point I disagreed with:


that didn't happen with segwit, it was implemented using the so-called "safe" soft fork design

you implied it could, and that was wrong

sure, but there's a limit to that....

the minimum output size (i.e. the smallest amount of possible BTC you can send) is currently 182 satoshis (and that's segwit outputs only, non-segwit outputs have a minimum size of 546 satoshis)

so that means things will change somehow before we get to 2140, otherwise the value of BTC will be in effect capped to 182 satoshis being equivalent to the smallest individual item one can buy (so maybe the price of a single nail in a hardware store? something like that)

But the idea always was that 1 BTC could continually divide into smaller denominations to reflect the increasing buying power of the currency. It seems now that 2.1 quadrillion (i.e. 21 million BTC multiplied by 100 million satoshis constituting each 1 BTC) is not going to be enough, whether BTC is a dominant currency or not. Milli-satoshis are already in use on the Lightning network, but I see Lightning as a medium term stop-gap to some other way of solving the various scaling issues. Maybe Lightning itself will evolve to becomes an all-encompassing solution with no compromises, but it doesn't quite seem like that just yet (I'd happily be proven wrong however).


So there's an unknowable scenario in store for Bitcoin; only once all innovation in efficient production of goods has ceased will we know how many decimal places we need to subdivide each satoshi into. And only then will we know what the economics of mining with only fees as a reward will be. I guess we could speculate on the range of possibilities, but that naturally includes different ways of mining and/or structuring the blockchain (innovation is innovative ).


But of course, none of this will matter for at least 100 years. There's alot to do between now and then without trying to tackle these issues seriously, maybe something that happens between now and then will make this sort of speculation entirely a moot point.

it seems disingenuous to describe the bolded behavior as a soft fork imo. it would be clearer to simply call the "safe" soft-fork plainly soft forks, and to popularize the "new rules can invalidate old rules" behavior as a... "permissive hard fork" is the expression that occurs to me from the top of my head. Maybe it's the wrong expression in some ways, but it's less misleading than the "impermissive" soft fork. If segwit had been implemented in such a way that, for instance, invalidated a common pre-fork consensus parameter, there would have been a least some orphaned blocks on that basis (and more likely an entire chain split, and a very likely failure of the segwit compliant fork). I am aware of no such event happening.

more simply; if a self-described soft fork can potentially produce a hard fork, then we need better words to describe what's really going on

yep

(but before you said "old nodes will accept new rules", which is not the same, and self-evidently not possible)



nope, you're wrong

if nodes that observe a soft-fork's rules rejected blocks containing previously valid transactions, that would fork the chain. which isn't possible in this case, because the segwit soft-fork does not reject any rules that were valid before it's activation, that's the definition of a soft fork

but I don't see much point in arguing this further, tell us which blocks have been rejected by any soft-fork's rule set, that would constitute evidence of your claim



yes.

But the old way of doing it is still valid, because soft-fork

yeah, but a pathologist with a bizarre record for making controversial claims in many many cases linked to questionable deaths of establishment figures. How strange that they wheel this guy out to be present at the autopsy, when there must be thousands of other pathologists perfectly capable of doing it. We need someone we can trust, right?

---

most of you sound crazy in this thread


this is a real case, involving real people, not some stupid fantasy TV show plot. If you really thought this was important, you'd quit the dumb mindless unsubstantiated claims, but because so many of you are making claims that have no evidence, you make the whole situation all look cerrrrrazzzyyyyy

and doing that helps Epstein, and his co-accused, many of whom are still alive. you may as well be working for those people, really, I'm sure they're really happy with the way you're presenting this story

This sort of statement has always (in the past, at least) ignored the issue of nuclear waste. There's always some large proportion of nuclear fuel that cannot be repurposed once it's life-cycle in the powerplant is complete. It tends to be the highly radioactive material with 100's or 1000's of years half-life, and it therefore needs incredibly long-term safe/secure storage facilities.

I can believe that the re-use of spent nuclear fuel is constantly improving, but there's always going to be some significant proportion that cannot be reused or re-processed, and it's always an unrepresented hidden cost of the entire "enterprise" (i.e. the long term costs of storing radioactive waste offset against the economics of running a nuclear power plant make it appear overall a very expensive way of producing electricity)

no

you could say more miners means more competition, and that pushes them to think harder about how to make their transaction choosing tech work more efficiently, but that's gonna have the tiniest effect to the users wanting to get money sent



Not that bothered myself if huge gains don't materialize next year. Too many people are getting into Bitcoin for the wrong reasons, it's far better to take exactly as long as it needs to get the scaling (and privacy and network strength and fungibility...) done right, rushing it carries an increase in the risk of a price of $0K


Saying that, there's more scaling tech coming next year: schnorr & taproot. Or at least, optimistically, they'll roll out next year, and they're on-chain related. Lightning will be improved by then too, too many Lightning improvements are coming to list quickly (and are all  easier to roll out than the schnorr & taproot)

You're doing the right thing, mining directly on the network is no joke of an undertaking, you need to be super certain that nothing is preventing you from finding valid blocks and getting a block in the chain


That's why you should test your setup on the Bitcoin testnet first. In many ways, it's become a testing ground for miners these days anyway

nope, that's wrong