no


please listen, I am telling you the following for the second time:

some people will happily eat the opportunity cost as a way to pay for the privacy benefits lightning channels can offer.


please stop beating this horse, it was dead before you began (although perhaps you could explain why you don't want to listen to anyone?)

okay, that seems fair enough

but your premise is still based upon telling other people they're using their property in the "wrong" way, and your argument seems to be: wrong because other people have any reason to say it too ("I don't think miners use too much electricity, but my neighbors do..."


sorry, but you're still equally wrong for equally unethical reasons. the miners paid to consume that electricity, and it's none of your business or anyone else's.

if we agree that any arbitrary reasoning of anyone else is sufficient to override other people's peaceful use of their property, it should be pretty obvious that the consequences of that is constant appropriation and re-appropriation, then huge conflicts.


It should be obvious to you too, please think before you suggest endlessly destructive principles as the basis for solving a non-problem.

indeed, except not the figures you're citing

the whole anthropogenic climate change argument is the actual problematic data, as it was proven, beyond any doubt, to be fraudulent over 10 years when significant people in the IPCC fraternity were caught red-handed discussing the falsification of climate data in order to "prove" the non-existent case for anthropogenic climate change


the entire premise for this thread is a sham, you should be ashamed of yourself for helping to promote this propaganda

the whole point of the tech behind Bitcoin was always to reinforce the age-old principle of "it's my life, and hence none of your fucking business"

guess what? it applies here (as well as everywhere, seeing as it's a principle)


if the oil industry/government sponsored plans to get us digital serfs to pay for breathing air was actually based in factual science, then I could understand your point. But you'd have to be a complete moron to believe that nonsense, right?


Again, please stick to looking cool and feeling slightly smug about your pub-stool honed native wit; politics, science and really anything requiring the faintest level of acquired intellect are not your strong point

not really

hiding branches in a script isn't anything like the privacy offered by e.g. Monero. All that happens is the transaction doesn't need to write unused parts of the script to the blockchain, it's a waste of storage space. The part (i.e. branch) of the script that does get used in a transaction is still written to the blockchain, and any third party who takes an interest in a taproot transaction will therefore still know what happened, they just won't know what alternatives could have happened



not quite.

a taproot address makes any script based spending conditions more private, not just multisignature conditions (multisignature is just one possible type of script)

possibly, but it depends alot on whether they're sensitive to the noise


you can only find out by.... (you guessed it).....

talking to them. Talk to your neighbours, that is the answer to your question (not necessarily about this, as if it bothers them, they will take an opportunity to bring up the pacing in a future conversation anyway)

lol

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

big news indeed.



the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

how can there be justice in a court which has no mandate to exist, let alone conduct trials?

the ICJ is assuming ultimate authority over justice on the planet, and as such sets an incredibly dangerous precedent. whether this vaunted authority prosecutes genuine crimes or not is irrelevant, the power of a singular organization playing the role of a global supreme arbitrator is simply too dangerous.

Any risk that the ICJ itself becomes corrupt is so compelling that it should never even have been conceived, and cannot conscienibly be supported if one considers this unacceptable risk. Those involved and who continue to support the ICJ clearly do not understand legends such as Icarus or the Tower of Babel; blindly striving for ideals risks making an imperfect world even worse.

please correct this lazy usage of the expression "double spending"


double spending is not possible in the Bitcoin protocol, you are referring to something else (abusing people who accept zero confirmation tx A by outspending the fees on tx A with tx B that includes the same inputs as tx A, but with a higher fee).

This technique should have a more appropriate name, "replace scam" or somesuch. If double spending was possible in Bitcoin, the outcome of this technique would be that both the sender and the receiver would  get the BTC from the outputs in tx A, and tx B would also be confirmed providing it was seen by the miner before tx A is mined. Also, the 21m supply limit would of course be circumventible, and rampant inflation would ensue

again, Bitcoin cannot be double spent

hey jack

in your lesson fortnight thread, you ought to amend the wording concerning SIGHASH_NOINPUT and OP_CHECKSEQUENCEVERIFY. The current text implies that SIGHASH_NOINPUT is a usable opcode in Bitcoin script, and that OP_CHECKSEQUENCEVERIFY is not usable, whereas the opposite is in fact the truth! OP_CHECKSEQUENCEVERIFY was activated by soft-fork (as BIP68 IIRC) several years ago, maybe 2016, while the precise details of a SIGHASH_NOINPUT opcode (including both it's precise fashion of operating _and_ in turn it's final name) have been subject to debate in the development community for many months, that process has not yet finished (although 1 proposal was accepted as a draft BIP... edit BIP118 authored by Christian Decker)

I think you've just mixed historical documents together with documents that look to future upgrades, should be easy to untangle.

right, but if you use the mytrezor.com web wallet, I ***think*** the website can access the extended public keys (xpub) for each address chain for your seed. If that's correct, SatoshiLabs have access to all the information about all transactions for all addresses generated from your Trezor seed, despite not knowing the seed itself (this is assuming the way the mytrezor.com web-wallet operates, I may be wrong)


the ways to use a Trezor hardware wallet with address privacy in mind are:

• using the python-trezor cli tool from https://github.com/trezor/python-trezor
• using the HWI cli tool from https://github.com/bitcoin-core/HWI
• doing either of the above only ever using addresses from hardened derivation keypaths (which means any leak of xpubs doesn't leak any of your public keys)
• doing all the above using a reasonably secure OS (i.e. not window or macos)

I myself use python-trezor at the moment (with the help of some bash scripts that use both the trezorctl and bitcoin-cli command line utilities). Future incarnations of the HWI tool will be more integrated into the Bitcoin Core wallet, the 0.20.0 release in May includes a big step forward in that direction (a vast overhaul of the wallet code that allows the flexibility to, i.e. in this case let the Trezor act as the transaction signer for a watch-only wallet kept on the computer running Bitcoin Core). In the end, IIUC the goal with HWI is to make a GUI interface that's accessible from within the Bitcoin Core Qt GUI, maybe some of that will be included in 0.20.0 with any luck (ping @achow101 who's part of the work on HWI)

You cannot really mitigate calling him a twat that way. "Twat" literally means "vagina", and tends to be used as a perjorative to describe someone who is submissive, weak, lacking courage and/or lacking wisdom, and yet over-confident (which is, in addition, shall we say rather a short-sighted way of regarding the many facets of the wondrous organ we may refer to with a little more affection as the pussy)

It's somewhat ironic that you yourself often display behaviour and attitudes that are submissive and bereft of courage, and yet still over-confident (although seemingly founded on a selfish form of wisdom). Notice how I'm telling you what you are without feeling the need to use perjorative language to do so.

Ross may have been short-sighted, but he had the courage to try to change the world, and will always be remembered for doing so. Nobodies die. Somebodies live

why?

it's a supply and demand equation, but with privacy incentives distorting the supply-side. It seems more likely to me that the market will always tend toward liquidity over-supply (which is obviously better than under-supply), and so fees will frequently or always be at or lower than any "specialized" node could tolerate

dunno folks, I suspect this whole border crossing charade will become increasingly anachronistic as the decade rolls on, not least driven by how much of a pain in the ass it's becoming (but also by new tech of various kinds)

if you can avoid it, don't create the swapfile on the SD card but instead on an external disk, preferably an SSD (swapping memory pages between the swapfile and RAM is a performance bottleneck). The constant writing to the SD card will kill the card far quicker than you would expect otherwise.

Also in relation to privacy/fungibility over Lightning, here is a link to another write-up by the same author (ZmnSCPxj) Darosior linked on a Coinswap-like procedure using the Lightning protocol:

https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002245.html

yeah, Raspi's have always had underpowered CPUs. The RPi4 is a step forward, but really because of the 2/4GB RAM variants. CPU is better, but not alot. I think it has more crypto instructions in the ISA (Cortex A72 I think), but not SHA256 sadly. Supposedly SHA256 acceleration only improves Bitcoin tx validation performance on x86_64 by 5%, but maybe the improvement would be bigger on a future RPi, as it would be improving from a lower performance baseline.