Fortunately they can imagine all the regulations they want they will never be able to regulate further things than centralized platforms. They will never be able to stop people from exchanging cryptos p2p against goods, services, other cryptos or even fiats. They will never be able to stop people from creating and holding a seed wallet with some cryptos into it. Bitcoin has been designed to be fully decentralized and uncensorable. So I wish them good luck to try to regulate cryptos as if it was fiat money. If it was easy to do Bitcoin would have been replaced since many years.
right, this is the typical almost wilful misunderstanding of what they are (incapable of) dealing with. if there was any easy solution, it would have been floated by now, this is all just tacked onto the FTX whispering campaign, which is all rather pointless anyway as people are both ignoring and distrusting establishment figures more than ever before |
|
|
|
It was never done such for Bitcoin.
Are you daft? no need for a question mark, and you also misplaced the position of the words 'you' and 'are' in the sentence. Strange, as your english language skills are always very good achow101!  belated congrats on the new release everyone. |
|
|
|
The hashrate is going to grow 10% from month to month if the current epoch keeps going like this, are they telling me that suddenly they've just installed 600MW of wind turbines just now? I understand some of the things, I understand that you can play with numbers for your own interest but right now they are just bullshiting. Bitcoin Mining Is Technology Intensive, 58x+ In Efficiency In 8 Years First, the S19XP was announced in 2021, and the first batch just got delivered early this month, now if we add the fact that the S9 was launched and sold in 2016, we have an increase of 5x in 6 Years. Both numbers are current, but doesn't it scream manipulation? Also, I love their comparison with other industries, construction, gold, and freight, but something is missing from there, the obvious one, but we can't use that anymore because it won't look as nice as it did 4 years ago.  right, this is the gift that keeps on giving for the policymakers it's essentially impossible to balance the interaction of ALL externalities from industry with the natural world. And so it's nothing but a stick to beat the serfdom with in perpetuity. meanwhile, if you are one of the aforesaid serfs, and would like other natural things as a part of your life: - trees in your locale or 'property'
- clean water on your 'property'
- grow or eat unprocessed food
- rearing children without constant pressure to subject them to endless unnatural influences or substances
...you're somehow the worst person in the whole world. Better keep buying all those 'green' energy and products, made with vast (and increasing) amounts of plastics, metals and other mining products that ravage microhabitats and poison the air, ground and water, right? I somehow don't believe the oil/mining billionaires and European Royal families that push the climate panic are ok with changing into Amish people living in trees to stop the world setting on fire, call me cynical if you will |
|
|
|
If G. Ment were to lock coins in a recursive covenant which always requires their input to spend all future outputs, then those coins can never leave such a set up, are now non-fungible, and are effectively no longer bitcoin. that is true, but I did say "same outcome", because of course G. Ment will never give consent for A. Citizen (  ) to leave the cult scheme. Of course, A. Citizen can use some form of persuasion/coercion to change G. Ments' mind in the 2 of 2 scheme, whereas no amount of persuasion can undo an infinitely recursive covenant. I don't think such a case is possible though with OP_CTV, but I've ready quite a few conflicting opinions on the matter, hence my desire for links and more clarity. it was a totally unbacked, unexplained statement of fact, so worth as much as the author's reputation IOW 1. Don't enter into such schemes to begin with
2. Don't trade with people that do 1 is easy, 2 is impossible. It is simply not possible for me to know all the different trades you are doing and whether or not you have coins in any such covenants. Well, yes. It's only possible to cease trading after the fact, but it's still useful. Some people you trade with will always keep coins you trade with them away from such covenants, you can check for yourself. Preferentially trade with those that do so the longest, ideally those who you observe 'never' involve your (previous) coins in coercive covenants. And if a sufficient number of Bitcoiners stuck to this, it would be difficult for people to simultaneously maintain unencumbered outputs and outputs in coercive covenants. Then I guess we would check the rate at which the poison was spreading before we take any other route (not sure what, but probably carefully re-designed altcoin would be the most drastic option) Coercive covenants should be more easily identified onchain compared to coercive multisigs, so in that respect they're better. |
|
|
|
Do you have a link to these discussions? i'll look, can't remember who said it, but it was a recent bitcoin-dev post yeah, the claim is not that "they can't happen", but instead that "OP_CTV does not enable" them
the boat sailed on the "infinite covenant" issue quite a while ago, to wit: Imagine a dastardly bully (let's arbitrarily give him the name G. Ment) forces you to send your BTC to a 2 of 2, 1 key yours and the other his. He can force you to always construct transactions that pay the change in any transaction to an address with exactly the same multisig; 2 of 2, 1 key yours, 1 his. That scheme achieves the exact same outcome that bothers some people about infinite covenants, so we've been living with such a possibility since multisig (i think it was BIP34) was introduced, way back in 2011. And I think that "bare" multisig was even possible since the earliest or even the very first version of Bitcoin. The only thing covenants do to change the situation is to remove the key exchange: with the above scheme, we need to ask G. Ment for his address to compute the next multisig in the sequence. That negotiation is not in the Bitcoin protocol, so it would be a clunky setup. With covenants, restricting where you can spend money to would be enforced by the script, not the overall sig validation, and so the multisig is not even necessary. Bitcoin nodes would reject the transaction as invalid, same outcome. But don't worry. 1. Don't enter into such schemes to begin with 2. Don't trade with people that do To help with point 2, simply use the blockchain to trace if people you traded with go on to put the money you gave them into such covenants. To be extra tough, start doing this twice or even thrice removed ("you're trading with some other clown who burned perfectly good BTC in a coercive covenant! Begone!") |
|
|
|
didn't read the thread, but in case anyone didn't say this already... ....isn't the actual climate chang-ists argument that: all energy use is bad, and so it must all be monitored, and adjudicated? (essentially, politicizing it, as there is no objective way to determine which uses are deserving) and cynical old me, I would guess that we're also supposed to sit around in freezing cold/scorching hot apartments, in Metaverse, where we fight back the tears experiencing what we imagine even a normal life would be by 2010's standards. Then when some high level toady in the hierarchy gets ratted out by rivals for.. i dunno, smoking a cigarette, we're also supposed to be shocked and disappointed, then we have to diligently do some extra pedaling on our humanoid hamster wheels to pay for the carbon credits needed to annul 1 cigarette of CO 2? if Black Mirror producers are reading, then, yes, I am available for creative development roles |
|
|
|
|
it was cancelled, so any concern is already out of date
I'm not sure, I find the whole episode a little bizarre, but I considered the author's behavior was consistently... odd, in respect of the course of BIP119. So, consistently odd, is, well, at least consistent.
Still, show's over I think.
|
|
|
|
|
all Bitcoin script is executed in blocks, onchain. That would include OP_CTV (which only works on a private testnet, not the main bitcoin blockchain).
any second layer protocols are subject to the outcomes of script at the onchain level.
But you seem to have got this confused. Any scripting done using off-chain protocols must be the same as real (i.e. onchain) Bitcoin script. There cannot be scripting possibilities that do not execute onchain. So don't worry about changes to scripting somehow affecting different layers, Bitcoin script has exactly the same possible operations whether on or off chain.
The point is to change the details of the script for a transation while it's off-chain, then execute the script onchain if/when wanted. Or never go onchain, that's another option.
|
|
|
|
|
119 does not inherently do anything you mentioned.
What it does do happens at the level of the Bitcoin tx script, AFAIK (there are descriptions of ideas that work using protocols that use Bitcoin tx script i.e. lightning, but it seems as if the only time CTV is invoked is when the open/close tx's go on-chain)
I don't think there is any _meaningful_ ability to do black/whitelisting, as we have been reliably informed by script gurus that infinite recursion is not possible with CTV. However, better that we verify this for ourselves, Bitcoiners shouldn't want or need gurus IMO
|
|
|
|
Russia invaded Ukraine, and now the sufferers are Russian people and the Ukrainian common people. any sanctions are affecting mostly poor & middle class Russians living outside Russian. As one poster mentioned, goods are already smuggled into Russia through Belarus before the war started anyway, so @Stompix, I don't think Boeing care if they sell parts to a German or Czech middleman that end up in Russia. It's actually Europeans, Eurasians and North Africans that will be affected the most by all this. Ukrainian grain and rape seed oil is a big supplier to all those regions, and this affects cattle farming too (hence the price of most meat products will rise all over those regions, and across the rest of the world to some extent) The Europeans will get a triple slap, as not only do they rely on Ukrainian agricultural exports, but also on those from Russia, plus Russian crude oil and gas are relied on heavily in Europe. Ironically, the bureaucrats who wrote the sanctions are aware, and exempted Russian oil and gas. That might not last long if Putin continues to demand payment in rubles. The rest of the world aren't following the sanctions anyway, so this ultimately could affect Europeans most. Strange strategy for beating Putin; leave europeans cold, poor and starving while the rest of the world looks on in bemusement, and China and Russia start to cut deals to decrease US/EU influence. India and Saudi Arabia have done so already, Dollar settlement in trade is being supplemented by rubles and yuan deals. If the US threatened action against India or Saudi Arabia, use of military is their only credible/effective option. |
|
|
|
In an interview in Italian, Giacomo Zucco came back to the Taro affair. He stood by his previous stance (LL stole their code, and they even mocked their RGB name) to obtain funding with a stringer proposition "we invented a protocol to transfer assets over the bitcoin network", instead of saying, "we decided to rewrite an almost identical implementation of an open protocol to transfer assets over the Lighting Network". He also added that now the funding has been secured, "Her Starkness" finally returned calls to Giacomo Zucco to find an agreement about recognizing (some) credits to RGB devs. a somewhat strange position for LL to take... Osuntokun claimed on the lightning-dev mailing list to have read the spec for RGB, but failed to (fully) understand it. Another dev (not working on Taro, but commenting generally) replied in concurrence with that statement (that the RGB spec was not an easy read). If it's difficult for to read and/or understand a specification document. surely it's not easy to produce a spec for a very similar system and claim it as one's own original work? Unless we all read these documents (both RGB and Taro specs), it's not easy to know for sure. It's amazing how prone these technical professions are to descend into, frankly, public hair-pulling spats. Dear oh dear 
None of this will matter in the long term; if Taro is too commerically-driven somehow, or RGB is too difficult for devs or users to fathom, or both, then someone will one day come along with something better anyway, assuming that the whole concept is not cat-vids-on-teh-blockchain froth (which it slightly sounds like, in fairness) |
|
|
|
|
yeah, that's a pretty reasonable set of arguments, essentially a paraphrased "Sam Colt" argument (i.e. "god made man, and TCP/IP made him equal") and is difficult to argue with ultimately.
I still think that some attempt will be made, and perhaps it would involve actually attacking at the level of TCP/IP itself i.e. banks/warlords/govs/moms & dads lobby to replace TCP/IP with something 'safe' for all the poor lost little lambs to play their Facebook games on. That could be the biggest coup d'etat of all time, and I wouldn't put it past them.
Of course, TCP/IP (and reams of equipment and software that still runs it) would still exist. So success would be unlikely outside of total world war scenarios. Sounds like an extraordinary gamble, but well, you never know.
|
|
|
|
The only thing I could think of would be an attempt to lobby for legal regulation of Lightning Nodes, but that would hurt large operators more than small ones, as the first would only increase their overhead while trying to prosecute the latter would prove pretty much futile.
right, that was what I meant. I'm surprised at your incredulity, doesn't almost every commercial activity have taxes/regulation structures that favor the largest businesses? And don't the largest business simply pay any onerous costs of business, then leverage the tax system in (sometimes unrelated) ways to claim it all back? Some large companies claim so much tax back that they end up getting a net negative tax bill, i.e. the government is paying them to stay in business (and that's before counting any explicit subsidies) |
|
|
|
|
i.e. any profit margin is always thin in a free and open market
the typical behavior of large operators is to:
1. be unhappy
2. find a way to increase the fixed costs of business for everyone in the market, to drive the smaller operators out
3. find a way to (softly) get customers to accept higher prices (trying to manipulate how they think is quite usual)
so we can expect that to happen with Lightning node operators at some point, at least some kind of attempt at it
|
|
|
|
|
Note that I'm deliberately not calling anyone out by name.
The reason is to try to keep anything personal out of the discussion, but that's just my style for this, do as you feel when replying.
|
|
|
|
according to https://utxos.org/signals, the answer to my question is no. But if we look at: https://bitcoin/bips/blob/master/bip-0119.mediawiki...and https://github.com/bitcoin/bitcoin/pull/21702then it is a little less clear. Some reddit personalities (who are also devs in some cases) have expressed disquiet that the author of BIP119/CheckTemplateVerify is acting too unilaterally, and for sure, he is not following the process that previous soft-forks went through in order to gain acceptance. So I guess my question is not technical: is this not inherently political, even if BIP119's author intends it to be, or even realizes it at all? Because the proposal seems ok, but it seems that acceptance of this way of working sets a precedent for someone else to propose similar such fork-activations, only to claim "this is how forks are done now", then we might have the Classic/Unlimited/BIP10x/hard fork nonsense repeated again. usual thread rules; no trolling, no trolls sorry if off-topic, feel free to move |
|
|
|
And which is never the cause of price fluctuations. Lightning, SegWit, Taproot, Omni, Liquid, Dandelion, CoinJoin, CoinSwap, DEX and an endless list of other innovations in Bitcoin have never proved to affect the market.
any innovations have always tended to be designed in pursuit of Bitcoin's core value proposition: trustless money network. perhaps we could say there is an inbuilt marketplace assumption that cryptocurrencies will always upgrade their capabilities, but that those changes only strengthen a concept that is still the same as it always was. And that the value of the core concept is what is being traded, not the minor buttressing of it's upgrades. maybe Lightning itself could prove to be the exception to the above, which implies Lightning hasn't achieved sufficient network-effect to affect the Bitcoin market. It was said early on in Lightning's development (~2017-19) that significant use of Lightning would put a visible cap on supply to the marketplace (as the BTC quantity in channels could be easily discerned by checking for them in the UTXO set), although the appearance of Taproot and more exchanges on the network all occurred faster than Lightning gained any significant liquidity. I would still expect any explosion in Lightning usage/liquidity to coincide with an explosion in Bitcoin's market price. |
|
|
|
read the other post about this protocol Lightning Labs tweaked someone else's protocol, called it their own, and are now using rich backers to promote it. Laoula Osuntukon/Elizabeth Stark are increasingly looking like a grifter weirdos, who can't seem to find a corporate finance backed protocol development capture scheme they don't like... don't worry everyone, _every_ corporate backed protocol has always failed since day dot. The smart ones sucked as much money as they could from their dumb customers, then bailed out before the company started circling the drain. Lightning Labs will be no different |
|
|
|
CppBridge loads all wallets in the datadir and converts them to the new format on the fly. Old wallet files are ignored past that point. Those wallets that carry encrypted private keys will lead to a prompt in GUI to unlock them. The same password used to unlock them will be used to encrypt the new file.
some issues I found: 1. one (encrypted) wallet throws this exception: (INFO) ArmoryQt.py:4486 - Dashboard switched to "Scanning" mode
terminate called after throwing an instance of 'Armory::Wallets::IdException'
what(): [EncryptionKeyId] invalid key size
(INFO) ArmoryQt.py:5277 - BDM is safe for clean shutdown 2. Another converts, then scans, then logs these errors when resolving tx hints: -INFO - 2022-04-06 - 23:08:29.411: (BlockchainScanner.cpp:1671) xxx blocks hit by tx filters
-ERROR - 2022-04-06 - 23:08:34.169: (BlockchainScanner.cpp:1468) Block deser error while processing tx filters:
-ERROR - 2022-04-06 - 23:08:34.184: (BlockchainScanner.cpp:1469) raw data does not match expected block hash
-ERROR - 2022-04-06 - 23:08:34.184: (BlockchainScanner.cpp:1470) Skipping this block
-ERROR - 2022-04-06 - 23:08:34.186: (BlockchainScanner.cpp:1468) Block deser error while processing tx filters:
-ERROR - 2022-04-06 - 23:08:34.186: (BlockchainScanner.cpp:1469) raw data does not match expected block hash
-ERROR - 2022-04-06 - 23:08:34.186: (BlockchainScanner.cpp:1470) Skipping this block
-ERROR - 2022-04-06 - 23:08:34.186: (BlockchainScanner.cpp:1468) Block deser error while processing tx filters:
-ERROR - 2022-04-06 - 23:08:34.187: (BlockchainScanner.cpp:1469) raw data does not match expected block hash
-ERROR - 2022-04-06 - 23:08:34.187: (BlockchainScanner.cpp:1468) Block deser error while processing tx filters:
-ERROR - 2022-04-06 - 23:08:34.187: (BlockchainScanner.cpp:1469) raw data does not match expected block hash
-ERROR - 2022-04-06 - 23:08:34.187: (BlockchainScanner.cpp:1470) Skipping this block
-ERROR - 2022-04-06 - 23:08:34.187: (BlockchainScanner.cpp:1470) Skipping this block 3. Upon file->quit, we have this: (INFO) ArmoryQt.py:5277 - BDM is safe for clean shutdown
[2022/04/06 23:18:39:3578] N: __lws_lc_untag: -- [wsi|0|pipe] (0) 22.654s
[2022/04/06 23:18:39:3826] N: __lws_lc_untag: -- [vh|1|default||-1] (1) 22.677s
[2022/04/06 23:18:39:3826] N: __lws_lc_untag: -- [wsicli|0|WS/h1/default/127.0.0.1] (0) 22.677s
[2022/04/06 23:18:39:3826] N: __lws_lc_untag: -- [vh|0|netlink] (0) 22.677s
(ERROR) CppBridge.py:220 - Socket error: [Errno 9] Bad file descriptor
(ERROR) ArmoryQt.py:5288 - Strange error during shutdown
Traceback (most recent call last):
File "/home/user/bitcoinarmory/./ArmoryQt.py", line 5280, in closeForReal
TheBridge.shutdown()
File "/home/user/bitcoinarmory/armoryengine/CppBridge.py", line 390, in shutdown
self.clientFut.result()
File "/usr/lib/python3.9/concurrent/futures/_base.py", line 440, in result
return self.__get_result()
File "/usr/lib/python3.9/concurrent/futures/_base.py", line 389, in __get_result
raise self._exception
File "/usr/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/user/bitcoinarmory/armoryengine/CppBridge.py", line 259, in readBridgeSocket
response = self.bip15xConnection.decrypt(\
File "/home/user/bitcoinarmory/armoryengine/BIP15x.py", line 312, in decrypt
raise AEAD_Error("failed to decrypt payload: " + str(decryptionResult))
armoryengine.BIP15x.AEAD_Error: failed to decrypt payload: -1
(INFO) ArmoryQt.py:5290 - Attempting to close the main window! the ArmoryQt.py process does terminate ok. It seems like porting to a different Qt version/lib was pretty clean in terms of outcome, so that's something. The dashboard wallet scan animation was always a little "janky" under Xen, so some gui bugs are already fixed!  |
|
|
|
yep, that worked I created a new wallet. I can't see how it makes sense to scan the blocks for transactions in that case, but that happened, and all was well. Sadly, there was no surprise BTC It seems there are methods in cppforswig/BridgeAPI/WalletManager to convert the 0.96.x format to the new one? Can I call them somehow, or is there no userspace interface yet? |
|
|
|
|
Show Posts
