[HN Gopher] Taproot, Bitcoin's long-anticipated upgrade, has act...
___________________________________________________________________
Taproot, Bitcoin's long-anticipated upgrade, has activated
Author : G3rn0ti
Score : 133 points
Date : 2021-11-15 10:13 UTC (12 hours ago)
(HTM) web link (www.coindesk.com)
(TXT) w3m dump (www.coindesk.com)
| nanna wrote:
| When will BTC move to an energy efficient protocol?
| JohnJamesRambo wrote:
| It will never. Best option is just invest in Ethereum which has
| Proof of Stake (not energy-intensive) coming next year. The
| changeover to it being the top coin is inevitable. It only
| needs to double its market cap right now to do so, which isn't
| that difficult in something as wild as crypto. And I say that
| without bias and I'm about 80/20 BTC/ETH right now. I think the
| coming months may be the last hurrah for BTC. There's no need
| to use that much energy and it will only get more important
| with time. I have lost an incredible amount of money backing
| the wrong horse the past year or two and being in Bitcoin as
| Ethereum has eaten its lunch.
|
| BTC maximalists will file in below me with bogus attestations
| that proof of stake is bad and none of it will be correct or
| factual. Proof of stake actually increases decentralization and
| eliminates the fact that now to mine btc you need to be near a
| very cheap electricity source and have ties that can get you
| the fastest asic mining machines as soon as they come out.
|
| Source: Myself, a former crypto miner.
| Gosper wrote:
| Ethereum's current approach to PoS is insecure. It will take
| a lot more work to get to a secure enough place to switch
| over, if a switch is even possible at all.
|
| I pointed to the latest vulnerabilities in another reply:
| https://news.ycombinator.com/item?id=29229084
| cblconfederate wrote:
| It's not jsut maximalists, every day people will tell you
| that the richest people invariably create cartels and it ends
| up badly. This time is not different
| capableweb wrote:
| Wouldn't the right question be "Will BTC move to an energy
| efficient protocol?". As far as I know, there is no plans from
| the Bitcoin developers to move away from Proof of Work, but I'd
| be happy to be corrected.
| saalweachter wrote:
| I believe the simple answer is "when BTC stakeholders stand
| to lose money by not moving away from PoW".
| jstx1 wrote:
| I think there's too much ideology, politics and tribalism
| involved to simplify it like this.
| javert wrote:
| You can't move bitcoin off proof of work. You can fork it,
| and the fork can become more dominant, but the fork won't
| be bitcoin. Similarly for changing the 21M coin limit.
| Bitcoin is an idea, not a democracy.
| lugorrr wrote:
| When will everyone only do energy efficient things. Stop the
| global party.
|
| https://blog.bitmex.com/bitcoins-carbon-footprint/
| robbie-c wrote:
| I skimmed this but it seems pretty heavy motivated reasoning.
|
| > However, despite being extremely energy intensive, per unit
| power consumed, Bitcoin mining is probably one of the most
| environmentally friendly activities in the world. This is due
| to the unique flexibility with respect to where the power is
| required. This means miners often choose renewable power due
| to the low stable costs or miners are able to use otherwise
| wasted or stranded energy. This is a fact often claimed by
| Bitcoin proponents and it is probably true. Per unit power
| consumed Bitcoin is likely to be exceptionally
| environmentally friendly.
|
| Ok, but what's actually happening? We can pontificate about
| how bitcoin mining could be hypothetically switched over to
| entirely renewable power because it is geography and time
| independent, but what's the cold hard reality?
|
| What % of energy used in bitcoin mining is from coal or other
| fossil fuels?
|
| What's the delta amount of fossil fuels burned compared to
| bitcoin not existing? How does that compare to other ways of
| sending money digitally?
|
| Any defence of bitcoin on environmental grounds that dodges
| that question is flaky at best.
| vageli wrote:
| > What % of energy used in bitcoin mining is from coal or
| other fossil fuels?
|
| > What's the delta amount of fossil fuels burned compared
| to bitcoin not existing? How does that compare to other
| ways of sending money digitally?
|
| How would it be possible to answer any of those questions
| reliably when any individual could set up a miner at their
| home?
| robbie-c wrote:
| I'm only talking analytics-quality data here, at the very
| least you would look at the major players and see where
| they are based. You would at least want to include anyone
| capable of doing setting up their own power plant
| specifically for mining, like these guys
| https://www.bbc.co.uk/news/av/technology-58020010
| [deleted]
| thegreatpeter wrote:
| When will we stop asking this on HN?
| cblconfederate wrote:
| To me, the fact that bitcoin is so inefficient means that a
| government cannot coopt it because it would be politically
| untenable. That's trading a bad thing for a good thing
|
| Ultimately though, side chains with various insured instruments
| (aka banks) will prevail due to their ease-of-use, and most
| real-world transactions will use unstable side coins (aka fiat
| currency).
| TekMol wrote:
| The mining reward is similar to a military budget. The higher
| the amount, the harder it is for someone to mess with peoples
| freedom to spend their money.
|
| Currently it is about $10B per year.
|
| The military budget of the USA alone is over $700B per year.
|
| It is a tricky issue. How can we create security from malicious
| actors without spending much on defense?
|
| How much does the world spend on locks? Probably a lot. It
| seems we have not found a cheaper way yet.
|
| Maybe proof of stake will be as reliable and cheaper. We will
| see in a few years.
| egypturnash wrote:
| Does Taproot do anything to reduce the absurd power consumption?
| If not then it just feels as useful as rearranging deck chairs on
| the Titanic to me.
| [deleted]
| Tepix wrote:
| Bitcoins biggest innovation is moving transactions off of
| bitcoin. That tells you all about it's capabilities really. Why
| bother with this outdated tech when there are vastly more
| capable coins out there?
| drak0n1c wrote:
| Yes it does, the byte size of transaction processing is
| smaller, and additionally many more transactions can be batched
| together when processing happens due to the more efficient
| algorithm.
| aron_misj wrote:
| > absurd power consumption
|
| lol.
| loceng wrote:
| Shhh.. Just keep looking at only the positives and the future,
| no time for criticism and addressing the known pitfalls!
| Glench wrote:
| A snarky tweet from Bram Cohen of Chia (which has had taproot and
| graftroot enabled since launch in March):
|
| > Congratulations to Bitcoin for joining the club of UTXO-based
| cryptocurrencies which have taproot enabled.
|
| https://twitter.com/bramcohen/status/1459755439294275584
| traceddd wrote:
| Seems petty. Of course it's easier to make changes when you
| just launched and there are less parties and more
| centralization at a leadership level. 8 months doesn't really
| seem like something worthy to brag over.
| Glench wrote:
| Well, Bitcoin still doesn't have graftroot so it's 8 months
| and counting :)
|
| And Lord help me I'm talking about crypto on hacker news but
| Chia seems just better engineered overall: -
| uses between 300x and 10000x less energy for the same
| security as Bitcoin - has the most number of
| farmers/validators of any blockchain - supports around
| ~25 transactions per second (as opposed to bitcoin's 5)
| - very efficient and auditable on-chain language (much better
| than Solidity afaict)
|
| The Chia team did a good job taking everything that works
| well from Bitcoin while also learning from its shortcomings
| and improving. Chia is now the table stakes for what other
| blockchains have to compete with.
| wmf wrote:
| It's easy to build something better engineered when you
| don't have an installed base. Getting adoption is the hard
| part. Chia is doing pretty well for a new chain but we'll
| see what happens long term.
| Hjfrf wrote:
| The biggest problem with chia is still that Bram owns
| almost all of the tokens.
|
| I see no reason to donate to his personal charity.
| freddiecoleman wrote:
| Incorrect. Please see
| https://twitter.com/0xfreddieC/status/1457289838470782978
|
| Disclaimer; I run a Chia blockchain explorer
| WhisperingShiba wrote:
| Fuuaarrrk. Got' Em.
| zaptrem wrote:
| > ~25 TPS
|
| Still a couple orders of magnitude away from being a
| significant difference.
| gruez wrote:
| > - uses between 300x and 10000x less energy for the same
| security as Bitcoin
|
| right, but instead of mostly electricity being poured into
| mining, now it's hard drive components. It's still the same
| amount of dollars (resources) poured into mining. The only
| difference is shifting it from opex to capex.
|
| >- has the most number of farmers/validators of any
| blockchain
|
| valid point, although I wouldn't really chalk it up to it
| being "better engineered". bitcoin supports validation at
| the miner level (ie. you can do the validation, rather than
| trusting/relying on the pool) as well via getblocktemplate.
| It's just not widely adopted for whatever reason.
| vmception wrote:
| real money testnets have often been useful to help Bitcoin
| reach consensus on constitutional amendments
| space_rock wrote:
| Centralised scams live off comparing themselves to a
| decentralised currency like bitcoin
| TekMol wrote:
| A crazy thing with Taproot is:
|
| A company could create a virtual bank to handle all transfers
| with its suppliers by doing a single onchain transaction.
|
| From the outside, it would look like a normal "Someone sent some
| coins from address A to address B" transaction.
|
| But internally, a key needed to spend the funds is only valid if
| the company and all of its suppliers sign it.
|
| This means every time there is a transaction between the company
| and one of its suppliers, the company would send out a signed
| message with the new spending conditions (the new balance of the
| company and every supplier) to the supplier network. Everyone
| signs it and that's it. It does not go on chain.
|
| Only if a participant becomes uncooperative, the latest state
| will go on chain and everyone will get what they own.
|
| So in the future, two transactions on the Bitcoin chain a few
| years apart could be "Someone sent something somewhere in
| December 2021 and then they send something somewhere in June
| 2025". Or it could be "BMW did ten thousand transactions with its
| suppliers". You don't know. Both look the same on chain. And all
| of the transactions were free, instant and possible 24/7.
| kjrose wrote:
| How does this handle someone spending bitcoin outside of the
| virtual bank?
| TekMol wrote:
| Different approaches come to mind.
|
| One is that one of the participants is a virtual bank on its
| own. This would be similar to the old banking system. How do
| you send money to someone who uses a different bank? By
| telling your bank to talk to their bank.
| [deleted]
| teekert wrote:
| "And all of the transaction were free", Wait? Since when are
| transactions free and instant? Is that part of this upgrade?
| The only costs are with the "bank transaction"?
| TekMol wrote:
| A second layer transaction does not involve the Bitcoin
| network.
|
| When Katy wants to pay [?]3 to Billie, Katy just sends a key
| (via email or some API) to Billie which enables Billie to
| withdraw [?]3 from the account of Katy. But Billie does not
| do that. Billie just keeps that message like you keep your
| login to your bank account.
|
| When Katy wants to pay another [?]5 to Billie, Katy sends a
| key to Billie which enables Billie to withdraw [?]8 from the
| account of Katy.
|
| Now Katy paid Billie [?]8 in two transactions. All via email,
| letter, telephone or - most likely - API. Nothing at all
| happened on the Bitcoin network.
| KptMarchewa wrote:
| Can you send 8worthless$ using that method, then move money
| out of the account via normal transfer?
| gruez wrote:
| no, because the funds are locked down while in the
| lightning channel. see:
| https://news.ycombinator.com/item?id=29228483
| piaste wrote:
| However, if nothing happens on the Bitcoin network, then
| the funds aren't locked down, are they?
|
| In other words, Billie has no guarantee that the key she
| holds will be valid tomorrow; Katy could empty that account
| at any time, and Billie would then hold nothing except the
| evidence of Katy's wrongdoing.
| kordlessagain wrote:
| Bitcoin supports post dating transactions. The
| transaction can be updated between parties, off chain.
| Lightning Network. If a bad actor gets involved, the last
| transaction updated between both parties rules and is the
| remainder is refunded upon the timeout of the post
| dating.
|
| This function is provided by script:
| https://en.bitcoin.it/wiki/Script
| TekMol wrote:
| Katy could empty that account at any time
|
| That would be a pretty lame virtual bank then :)
|
| Realistically, the spending conditions are either limited
| by time. So Billie knows she needs to withdraw until a
| certain date or Katy could betray her. Or the spending
| conditions contain a punishment for betrayal. So if Katy
| tries to withdraw money she assigned to Billie, Billie
| can intervene, get her money and punish Katy.
| gruez wrote:
| > However, if nothing happens on the Bitcoin network,
| then the funds aren't locked down, are they?
|
| they are locked down. the funds in a lightning channel
| are locked in a 2 of 2 multisig address, and can only be
| moved upon mutual consent (ie. by updating the state of
| the channel), or by one party after sufficient time has
| passed (in case of an uncooperative peer).
| zaptrem wrote:
| Don't LN channels require a (quite expensive) transaction
| to open and close?
| gruez wrote:
| >quite expensive
|
| Are you talking about compared to regular transactions,
| or because network fees (per byte) are high?
| pkulak wrote:
| Whoa now, how did we start talking about lightning? Has
| it been lightning all the time? Because that's always
| supported instant, near-free transactions (with a _bunch_
| of problems too, that I'll not worry about).
| kordlessagain wrote:
| > In parallel to that, we plan to use Taproot's new
| "tapleaf" script versioning scheme to implement
| Simplicity, our upcoming blockchain programming language.
|
| https://medium.com/blockstream/taproot-activation-
| enhanced-t...
| tgb wrote:
| Does this stop a double spend?
| gruez wrote:
| Yes, why wouldn't it? The funds are locked in a 2 of 2
| multisig address.
| tgb wrote:
| I'm confused then, doesn't this still need one
| transaction in the block chain for every transaction?
| HashBasher wrote:
| No, the transaction is fully signed and can be broadcast
| at any time by either party to settle. It doesn't have to
| be broadcasted and further transactions can be done on
| top and they just keep it private between themselves.
| tgb wrote:
| I'm missing how you can have a transaction that is not
| broadcasted but that prevents a double spend. Can't I
| give two different people signed transactions for the
| same bitcoins? How could the second recipient know I've
| already spent the balance on the first? Apologies for the
| no-doubt naive questions, it just sounds impossible.
| Jeff_Brown wrote:
| Is it that the not-on-the-Bitcoin-blokchain account gets
| updated on a separate "layer 2" Blockchain that's
| cheaper? If so, why would that second chain stay cheaper?
| PKop wrote:
| What do these LN dynamics (which seem to have existed for
| a little while already now) have to do with Taproot?
|
| OP was describing something in the context of Taproot and
| now you and others are talking about Lightning. What is
| the new development here?
| G3rn0ti wrote:
| Roughly, Taproot will make Lightning Transactions much
| more efficient and indistinguishable from simple
| transactions by introducing a new ,,Pay-To-Taproot"
| validation type.
|
| https://blog.chainalysis.com/reports/bitcoin-taproot-
| upgrade
| louloulou wrote:
| Lightning channel opens/closes are 2-of-2 multisig
| transactions. Taproot would make them indistinguishable
| from singlesig transactions.
| G3rn0ti wrote:
| Parent talks about the ,,Lightning Network" -- a Layer 2
| scaling solution for Bitcoin. Beware: I am still a crypto
| noob but I am still going to try to explain how I understood
| the system so far. Edited: Minor terminology and typos.
|
| Roughly speaking the Lightning Network works similar to a
| ,,current account" that businesses have between each other
| but does not require the actors to trust each other. The
| parties initiate a transaction by each one sending Bitcoin to
| a public multi signature address. The resulting transaction
| cannot be spent by any one alone. Now, this unspent
| transaction serves as an initial balance and opens a channel
| between the parties on the layer 2 network. Bitcoin may now
| be wired back and forth between the parties on layer 2 w/o
| needed to be settled individually on the Bitcoin block chain.
| Finally, if all parties agree by signing a second, settling
| transaction the resulting balance is written back to the
| Blockchain to whatever address the participants initially
| agreed upon. Theoretically, there could have been billions of
| Bitcoin transactions over the years on the Lightning Network
| which would be eventually represented by only two
| transactions on the chain.
|
| Now, taproot improves this scheme by introducing Schnorr
| signatures. Up to now every member of the multisig
| transaction I just talked about needed to contain the public
| keys of all parties which in turn needed to be verified
| against all their private keys. Since transactions are
| limited in their size, this limited the applicability of
| multisig transactions. Now, Schnorr signatures allow for
| aggregation of public keys so the transaction only needs to
| contain a single number instead of hundreds or thousands. Of
| course, this also speeds up validations of transactions.
|
| I hope this all made sense. I have yet to see practical
| applications of a Lightning Network ,,scheme" but I heard El
| Salvador is using it for cheap Bitcoin transactions (although
| not applying Schnorr signatures yet).
| nybble41 wrote:
| The other half of the Taproot update besides Schnorr
| signatures is support for MASTs: Merklized Abstract Syntax
| Trees. This allows you to create scripts (smart contracts)
| where only the _used_ part of the script needs to be
| revealed when the funds are transferred. Other parts which
| were not used--for example, the clauses related to
| recovering funds in the event of a non-cooperating peer in
| a Lightning channel when the channel is closed normally--
| need not be included in the transaction, which both
| improves privacy and reduces the transaction size (and thus
| also the fees).
| TekMol wrote:
| Parent talks about the ,,Lightning Network"
|
| I was not talking about the Lightning Network in
| particular. The LN is a system that does settlement on the
| Bitcoin blockchain.
|
| So is the "BMW and its suppliers" network I imagined. But
| this network is simpler and more customized to the needs of
| this particular use case.
|
| Of course using the LN would be a viable alternative to a
| custom solution.
| G3rn0ti wrote:
| I see, so in principle, taproot would facilitate to set
| up custom scaling solutions for Bitcoin payment schemes.
| space_rock wrote:
| "Bitcoin may now be wired back and forth between the
| parties on layer 2 w/o needed to be settled individually on
| the Bitcoin block chain." Cooperatively update the final
| state would be more precise. And if one party is
| uncooperative then a timeout contract becomes valid. Your
| understanding is generally correct. Also bitcoin doesn't
| use the word crypto which is closely associated with scams.
| Bitcoin is about the 21 million coin limit so only one
| currency not cryptocurrencies.
| 323 wrote:
| BMW and it's suppliers have zero problems moving money today.
| anonporridge wrote:
| People had little problem with transportation when all they
| had was horses and sailboats.
|
| Just because you don't technically have a problem doing
| something now and no one is complaining, doesn't mean there's
| not a drastically more efficient way to do the thing, and
| those organizations that start doing the more efficient thing
| rapidly out compete and make irrelevant those who hold onto
| the legacy ways.
| loceng wrote:
| Bitcoin is the horse and buggy in this comparison - while
| attempting to naively remove control possibilities and
| making it "trustless" aka a free for all/wildwest where
| nations can't use financial levers to try to economically
| punish known bad actors, e.g. Magnitsky Act.
| anonporridge wrote:
| I think it's a grand experiment.
|
| Perhaps the primary output of bitcoin will be that it
| lights a fire under the lazy ass of government to
| actually have a service mindset towards people, because
| they now have an alternative that they can use however
| they want.
|
| We'll see.
| TekMol wrote:
| How do you know?
| 323 wrote:
| Because there are no articles about big companies having
| money transfer problems with their suppliers.
|
| The complains are about the "buy now pay 90 days later"
| part, not about the actual money transfer.
| TekMol wrote:
| How hard did you try to find such articles?
|
| I would imagine the suppliers of Wirecard _do_ see it as
| a problem that the $2B WireCard said it has in the bank
| did not exist. In a blockchain setup, they would have
| known it.
|
| Ducking for "supplier" and "insolvency" brings up quite a
| lot of stuff about this topic:
|
| https://duckduckgo.com/?q=insolvency+suppliers
| 323 wrote:
| Supplier insolvency has nothing to do with money
| transfer.
|
| And if you think that you can "lock bitcoin" into an
| account to avoid this, you obviously don't know much
| about how these things work. Hint: you can also "lock
| dollars" today, it's called "escrow". But it wasn't used
| in WireCard (I take your word for it, I don't know the
| case).
|
| Explained like I'm five: BMW will not accept it's bitcoin
| being locked for 90 days, so that it's supplier can be
| sure it will receive it's pay. Because if BMW would have
| accepted such a thing, it would pay today, not 90 days
| later. So crypto doesn't solve any problem here, because
| BMW doesn't want this problem solved.
|
| And today, the supplier would use "factoring" so that it
| can receive the money instantly, instead of 90 days
| later, and the bank which provides the factoring service
| will make sure to take it's money from BMW later. Hint:
| you need capital to be able to provide factoring, since
| it involves credit risk, so crypto can't replace that
| either directly (it could with some fancy smart contracts
| that pool liquidity and yield)
| TekMol wrote:
| BMW will not accept it's bitcoin being locked for
| 90 days
|
| The way I see the future, BMW will not only lock their
| Bitcoin for 90 days but much longer. And not only the
| Bitcoin they owe to one supplier. But a large portion of
| their Bitcoin. Aka their virtual bank account. They can
| still use their account however they like. But if one of
| their suppliers feels that the balance goes dangerously
| low, the supplier can block further spending or settle
| everything.
| johnday wrote:
| Surely suppliers want to be paid? Accumulating a huge
| pile of IOUs is of zero benefit to someone who has actual
| real-world costs, such as taxes, payroll and capital
| outlays.
| TekMol wrote:
| What do you mean by "be paid"?
|
| Usually, one is "paid" when "the money is in the bank",
| right?
|
| And this is what happens here. The initial step is to
| _create_ a bank and then "payments" happen there.
|
| As for how to pay someone who is not "customer" of this
| bank, see my answer to this question:
|
| https://news.ycombinator.com/item?id=29227788
| jessaustin wrote:
| Lots of firms, especially those whose value is based
| partially on "predictable" profits, want to schedule
| payments in Q2 rather than Q1.
| x86_64Ubuntu wrote:
| And Net X(Net 90 in your case) is part of business, so
| it' not going away because of a blockchain.
| coralreef wrote:
| Tesla didn't like paying banks to store its money in Europe
| via negative interest rates, so they moved in into Bitcoin.
|
| https://www.techtimes.com/articles/263185/20210721/elon-
| musk...
| 323 wrote:
| That has nothing to do with transferring money.
|
| Tesla also holds bonds and other stuff that pays a
| dividend.
| tromp wrote:
| > the latest state will go on chain
|
| You'll need to have a revocation mechanism to punish older
| states being put on chain. That may not be so simple when
| (many) more than 2 parties are involved.
|
| > Or it could be "BMW did ten thousand transactions with its
| suppliers". You don't know.
|
| Amounts are still visible as well as number of entities paid by
| the settlement. Recipients may become identifiable through
| follow-up transactions or re-use of known public keys.
|
| > And all of the transactions were free
|
| All but the initial funding tx and the final settlement tx.
| TekMol wrote:
| Yes, it will probably take years before we all settle on
| standardized ways of doing these things. But in theory, they
| are possible now.
|
| Yes, the initial tx and the final tx will provide data for
| forensic analysis.
|
| Yes, the initial and final tx need some time to settle
| (something like an hour) and cost some money (something like
| a few dollars at current rates).
| lalaland1125 wrote:
| How is this different from the lightning network?
| pyrale wrote:
| So basically, does that mean KYC/AML are officially dead in
| BTC's environment? The picture was not bright before, but with
| this kind of innovations, it seems impossible for this network
| to build banking systems that respect regulations.
| ulzeraj wrote:
| Good riddance. I don't think KYC/AML are a force for good.
| Its just more box ticking laws that serve to give a false
| sense of security while poor people are being excluded from
| the banking system and normal people have their all their
| data stolen from centralized databases.
|
| Real dangerous criminals don't give a damn about KYC/AML laws
| and operate freely within the banking framework. The European
| Central Bank chairwoman is a felon convicted for massive
| government payouts.
| baby wrote:
| BTC is not built to support KYC/AML.
| bigdubs wrote:
| Then it's going to be weaponized to launder money and be
| made illegal eventually.
| aron_misj wrote:
| > launder money
|
| means different things in different places
|
| > made illegal
|
| it's already illegal here and there
| throwaway55421 wrote:
| There is no future tense here.
|
| Bitcoin is designed to be fungible - it's digital cash.
| baby wrote:
| That's an argument that has been made yes.
| vb6sp6 wrote:
| > Then it's going to be weaponized to launder money
|
| We should stick with USD. No one does anything illegal
| with USD
| mikevm wrote:
| Yes, which is why all ransomwares ask money in USD,
| right?
| skeaker wrote:
| Your point being what? That because USD is uncommonly
| used in ransomware it can't be used to commit crimes? Do
| you really think that no extortion has ever taken place
| via USD? Because I can guarantee you that money-related
| crimes and scams happen in just about every single form
| of currency, even things that technically aren't even
| currency like gift cards.
| aron_misj wrote:
| > ransomwares
|
| this is not even worth looking at compared to other
| money-related crimes (just new and in media so people are
| scared)
| nanna wrote:
| Can anyone explain why my genuine question below -- "When will
| BTC move to an energy efficient protocol?" -- was flagged? Seems
| a bit gratuitous?
| dang wrote:
| That's a classic flamewar topic, so if your comment didn't have
| anything new and interesting to say, users will tend to flag it
| as flamebait. (I haven't seen the comment.)
| Gosper wrote:
| I don't know why you were flagged, but if your question was in
| earnest:
|
| Bitcoin almost certainly won't move. Because those touted
| energy efficient protocols come at the cost of much weaker
| security guarantees which undermine a key point of Bitcoin.
|
| Proof of stake, the forerunner of energy efficient protocols,
| may work better for networks that have different aims, although
| smart contract oriented blockchains still need good security to
| be trusted.
|
| The stupendous levels of complexity involved in trying to
| hammer out proof of stake into a viable method of energy
| efficient mining make the approach look ever more unpromising.
|
| Ethereum keeps delaying the switch and the touted 2022
| migration has once again been kicked into the long grass after
| this paper from a few weeks ago:
| https://arxiv.org/abs/2110.10086
|
| Lead to: https://nvd.nist.gov/vuln/detail/CVE-2021-42764
| https://nvd.nist.gov/vuln/detail/CVE-2021-42765
| https://nvd.nist.gov/vuln/detail/CVE-2021-42766
| [deleted]
| baby wrote:
| > Because those touted energy efficient protocols come at the
| cost of much weaker security guarantees which undermine a key
| point of Bitcoin
|
| That's FUD. Protocols like Bitcoin can fork, whereas others
| don't. Thus, Bitcoin, and proof-of-work, are less secure
| protocols.
| DennisP wrote:
| Here's one of Ethereum's lead researchers talking about the
| attacks in that paper. The fixes are simple and not expected
| to delay the merge.
|
| https://blog.ethereum.org/2021/11/02/finalized-no-31/
| nanna wrote:
| It really was in earnest! I don't keep up with crypto news so
| just assumed this was something being worked on somehow.
|
| Your answer would have fitted well with the thread that
| responded to my question!
|
| As difficult as the vulnerabilities of PoS are to solve, at
| least there's nothing yet to say that they can't be solved
| given enough work; wheras, from what everyone is saying, the
| energy problem is essential to PoW as such?
| aeternum wrote:
| With PoW all that burned energy creates a strong root of
| trust.
|
| How do you establish that root of trust with PoS? Currently
| approaches are ultimately circular, IE trust it because the
| majority holders of the coin are continually voting to
| trust it.
| Tepix wrote:
| You need a good initial distribution.
|
| With Bitcoin mining pools it looks like there's just as
| much centralization (if not more) as with proof of stake.
| troyvit wrote:
| I don't know but I came here with the same question in mind.
| Like, "Oh maybe they upgraded to suck less coal out of the
| ground?" Nah, other reasons entirely it seems.
| randomhodler84 wrote:
| Because it is offensive. Bitcoin is, always will be, a proof of
| work cryptocurrency. If you do not understand why, take time to
| learn why.
| baby wrote:
| It's highly unlikely that Bitcoin will move towards a proof of
| stake protocol without strong incentives (like regulations).
| The whole point of the proof of stake was to make the protocol
| censorship resistant.
| atweiden wrote:
| > Overcoming censorship is not possible in a PoS system, as
| the censor has acquired majority stake and cannot be
| unseated. As such PoS systems are not censorship-resistant
| and the theory is therefore invalid.
|
| https://github.com/libbitcoin/libbitcoin-
| system/wiki/Proof-o...
| sowbug wrote:
| I didn't flag, but if that's what you wrote, it's off-topic.
|
| It's also tedious. We get it. It uses energy by design. You can
| count on any HN Bitcoin discussion to bring out the
| environmentalist in almost anyone.
| The_Colonel wrote:
| It's not that much off-topic given that this discussion is
| about Bitcoin protocol upgrade and switch to PoS is a
| potential protocol upgrade as well.
| drexlspivey wrote:
| Because it's a loaded question and an attempt to start a
| flamewar. The genuine answer to the question is 'never'.
| benzible wrote:
| You're assuming the motive of the commenter, who followed up
| and clarified that it was asked in earnest. It's a reasonable
| question for someone who doesn't follow crypto closely to ask
| rawtxapp wrote:
| One of the most interesting things in this experiment was the
| speedy trial imo. We now have an agreed way to change/improve
| consensus rules. It's very difficult to get a handful of people
| to agree on something, let alone all the different participants
| in this global/borderless system.
| wmf wrote:
| Taproot was proposed 2.5 years ago; maybe that's speedy in
| "Bitcoin core time".
| Tepix wrote:
| It's not a hard fork, is it?
| aantix wrote:
| Bitcoin is centralized.
|
| If you want any chance at mining, you'll need an ASIC miner.
|
| And the few companies that sell them, are sold out.
|
| Or there's some shady dealers that only will accept Bitcoin for
| payment, so you basically have no insurance if they don't
| deliver the miner.
| 323 wrote:
| That's because bitcoin is so centralized these days, that you
| can get all the people that matter in a room and hash things
| out.
|
| Note how half of the Bitcoin network nodes don't support
| taproot yet, but it's irrelevant. The few nodes that matter do
| support it.
| rawtxapp wrote:
| > That's because bitcoin is so centralized these days
|
| Citation badly needed.
|
| For taproot to rollout, you need wallet providers, exchanges,
| nodes and miners to agree. There are hundreds/thousands of
| different participants in each one of these categories across
| the world. Specifically, 90% of nodes need to signal for it.
| 323 wrote:
| It says right in the article that wallets don't support
| taproot either at the moment.
|
| > Specifically, 90% of nodes need to signal for it.
|
| Wrong, 90% of mined blocks need to signal it, not 90% of
| nodes. Big difference:
|
| > at least 90% of the blocks mined in any of the designated
| two-week difficulty periods "signal" their support for the
| upgrade, then the activation process can begin. To be more
| precise: 1,815 out of 2,016 blocks mined within a period
| have to include a little piece of encoded information that
| indicates that the miners who mined those blocks are in
| favor of the upgrade.
|
| https://www.coindesk.com/tech/2021/06/12/locked-in-
| bitcoins-...
| Jach wrote:
| There are a number of ways to achieve consensus, rawtxapp
| is right in general that many decentralized parties need
| to agree. For Taproot in particular, it uses BIP 8 (see h
| ttps://github.com/bitcoin/bips/blob/master/bip-0008.media
| wi... and https://github.com/bitcoin/bips/blob/master/bip
| -0343.mediawi... and more generally
| https://bitcoinmagazine.com/technical/bip-8-bip-9-or-
| modern-...) with LockinOnTimeout=true. The effect of this
| is that miners cannot block the upgrade so long as the
| (eventual) majority of nodes wishes to have the upgrade,
| they can only hurry things along and mostly protect the
| minority of older clients who have yet to upgrade.
| anonporridge wrote:
| You don't strictly _need_ mass consensus for a softfork.
|
| Taproot is a softfork, which means a tightening of the rules.
| There are basically a set of placeholder script types, that
| are currently undefined by the network ruleset. By being
| undefined, you can basically add whatever garbage you want,
| and it will technically be valid.
|
| So, blocks that are mined now with taproot transactions are
| still considered valid by nodes and miners that haven't
| upgraded or don't support the change. Their nodes just see
| these transactions as unintelligible garbage, but still
| permissible.
|
| However, the risk these nodes take on by not upgrading
| support, is that they might receive a block, assume it's
| valid even though there are transactions they don't
| understand, but in fact are invalid taproot transactions and
| rejected by the upgraded network. This is a _much_ greater
| concern for miners than regular nodes, because miners have
| severe economic risks associated with incorrectly assuming an
| invalid block is valid, whereas non mining nodes don 't have
| as great of a risk, because they generally wait for several
| confirmed blocks before assuming their transactions were
| confirmed.
| vmception wrote:
| Interesting take, I found the trial to be aggravatingly slow
| because the bitcoin community is too risk averse and also
| inattentive, whereas people (person) disagreeing with you
| basically have no idea how long it actually took and use it to
| bolster their view that bitcoin is centralized and amorphous.
| lightweb wrote:
| Ignore at your own potential peril..
|
| BTCers don't care, apparently
|
| https://coingeek.com/could-taproot-privacy-features-make-btc...
| anonporridge wrote:
| There's game theory at play here that transcends the legal
| system.
|
| Yes, the US and the EU _could_ deem these cryptocurrencies to
| be illegal. However, as we saw in China, all that accomplishes
| is squeezing it out of your borders, or squeezing it to the
| black market. Making it illegal would also be an insanely
| strong signal to the entire world that this thing actually is
| uncontrollable by our current governments, and that they 're
| scared of it.
|
| Knowing they can never actively kill it, just drive it
| elsewhere, these societies have to take a gamble. Either assume
| it's eventually going to wither and die after they ban it,
| thereby protecting their citizens from wasting time and money
| on the system, or assume it's going continue to grow into being
| the foundation of a new global monetary system that's going to
| automate and consume everything that's existed before, and
| severely miss out on being at the vanguard of that industry.
| snarf21 wrote:
| Serious question: Can't a government block it at the ISP
| level? They could also make out of country VPN illegal. How
| would BTC work in practicality under those conditions?
| aftbit wrote:
| That becomes a cat-and-mouse game. See the Great Firewall
| of China.
| ulzeraj wrote:
| Then we go to spaaaaace https://blockstream.com/satellite/
|
| Semi-serious jokes aside (the block stream satellite can
| receive blocks but not broadcast), the protocol can operate
| under Tor in which the bitcoin core daemon is very well
| integrated. If worst come to happen, sneaker net is
| somewhat popular (https://opendime.com) and people have
| transacted using radio waves as a proof of concept
| (https://satoshi.radio.br/wp/).
| anonporridge wrote:
| It's just information.
|
| You could broadcast it on any communications medium. You
| could theoretically run it over a global ham radio mesh
| network.
|
| Lots of the network is already running on Tor, so you'd
| also have to shut that down.
|
| You could embed the information in the pixels of cat
| pictures and broadcast it via instagram posts.
|
| Unless there exists a global, horrifically authoritarian
| constriction on the information we are allowed to share,
| it's not going to happen.
| G3rn0ti wrote:
| All Layer 2 scaling solutions would also be obfuscating
| transactions because all _out of_ chain transactions are
| invisible _on_ chain.
| vmception wrote:
| Exchanges that delisted privacy coins were not doing so because
| they were viewed as illegal. Those businesses just didn't have
| the risk profile to ever take anything to court to solidify the
| obvious reality that they're not illegal. Their relationship
| with the regulators is too important for them.
|
| Fortunately, CeFi exchanges are less of the volume these days
| than DeFi and institutional OTC. When I was using institutional
| OTC in the United States, they would make markets for me in
| Monero if I asked. If I said "I want to trade this random erc20
| altcoin for Monero" they'd say "say less, we got you", and
| quote me a very competitive price. Same for moving dollars in
| and out.
|
| But I've been using DeFi AMMs all year.
|
| The DeFi bridges for bitcoin are fine as well. There are only 1
| or 2 permissionless ones for Bitcoin itself, for now, but
| they're okay. Moving a few billion in volume already this year.
| The permissioned ones operate under the same risk profile and
| regulatory profile as exchanges do, so its not a deal breaker
| if you already use CeFi, and the user experience on any bridge
| can still be better - depending on what you want to do.
|
| Even Monero has a permissionless bridge too now, on the Secret
| Network. so you don't even need any exchanges or those sketchy
| centralized swapping services to move in and out of Monero
| anymore, and from Secret Network you can bridge to the broader
| DeFi ecosystem.
|
| This should get even better.
___________________________________________________________________
(page generated 2021-11-15 23:01 UTC)