Bitcoin Forum
January 30, 2023, 05:08:00 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 »  All
  Print  
Author Topic: Taproot proposal  (Read 11144 times)
Wind_FURY
Legendary
*
Offline Offline

Activity: 2450
Merit: 1487



View Profile
May 31, 2021, 02:46:49 PM
 #341

Is anyone really surprised to see that Marathon pool is the only one not signaling for Taproot activation?

i am not surprised but not because of their clean block nonsense but because they are running a very tiny mining pool and from what i remember from last soft fork we had the tiny pools are not going to signal until the very last moment.


They might not be actually a “friend” to Bitcoin. Here’s also something the company had done in the past, that should raise some concerns on who these people really are.

https://en.wikipedia.org/wiki/Marathon_Digital_Holdings

Quote

Marathon Digital Holdings (formerly Marathon Patent Group) is a patent holding company that is the parent of Uniloc, known as a patent troll company. Marathon purchased patents related to encryption in the 2010s


1675098480
Hero Member
*
Offline Offline

Posts: 1675098480

View Profile Personal Message (Offline)

Ignore
1675098480
Reply with quote  #2

1675098480
Report to moderator
1675098480
Hero Member
*
Offline Offline

Posts: 1675098480

View Profile Personal Message (Offline)

Ignore
1675098480
Reply with quote  #2

1675098480
Report to moderator
1675098480
Hero Member
*
Offline Offline

Posts: 1675098480

View Profile Personal Message (Offline)

Ignore
1675098480
Reply with quote  #2

1675098480
Report to moderator
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675098480
Hero Member
*
Offline Offline

Posts: 1675098480

View Profile Personal Message (Offline)

Ignore
1675098480
Reply with quote  #2

1675098480
Report to moderator
Karartma1
Legendary
*
Offline Offline

Activity: 2310
Merit: 1422



View Profile
May 31, 2021, 03:12:07 PM
 #342

Is anyone really surprised to see that Marathon pool is the only one not signaling for Taproot activation?
I am not surprised at all, but problem is they are growing in hashrate with their new 73,000 miners starting to run in Texas with plan to have total of 103,000 miners with 10.36 EH/s hashrate.
I really don't know what to expect from them after ofac compliant ''clean'' blocks...
Better because agreeing 100% is never a good thing. Cheesy
Anyway, whether they signal or don't, who cares, we don't care.
They're bound to have to adapt to taproot and then I'll be really interested to see how taproot will make life difficult for them on the privacy side.
fillippone
Legendary
*
pizza
Offline Offline

Activity: 1694
Merit: 11779


Merit Rascal - Pizza Maker


View Profile
May 31, 2021, 05:04:21 PM
Merited by JayJuanGee (1), ETFbitcoin (1)
 #343

Apparently, Marathon is going to signal Taproot Activation:


https://twitter.com/michael_saylor/status/1399407493839732744?s=21

From Marathon Press Release
Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,” said Fred Thiel, Marathon’s CEO. “Over the coming week, we will be updating all our miners to the full standard Bitcoin core 0.21.1 node, including support for Taproot. By adopting the full standard Bitcoin core node, we will be validating transactions on the blockchain in the exact same way as all other miners who use the standard node. We look forward to continue being a collaborative and supportive member of the Bitcoin community and to realizing the vision of Bitcoin as the first decentralized, peer-to-peer payment network that is powered by its users rather than a central authority or middlemen.”




JayJuanGee
Legendary
*
Offline Offline

Activity: 3248
Merit: 7767


ESG, KYC & AML are attack vectors on Bitcoin


View Profile
May 31, 2021, 05:51:04 PM
 #344

Apparently, Marathon is going to signal Taproot Activation:


https://twitter.com/michael_saylor/status/1399407493839732744?s=21

From Marathon Press Release
Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,” said Fred Thiel, Marathon’s CEO. “Over the coming week, we will be updating all our miners to the full standard Bitcoin core 0.21.1 node, including support for Taproot. By adopting the full standard Bitcoin core node, we will be validating transactions on the blockchain in the exact same way as all other miners who use the standard node. We look forward to continue being a collaborative and supportive member of the Bitcoin community and to realizing the vision of Bitcoin as the first decentralized, peer-to-peer payment network that is powered by its users rather than a central authority or middlemen.”


hahahaha

Are they going to just temporarily behave well or go back into dumbass mode when it seems opportunistically beneficial to them.. .. time will tell.. and yeah, there are likely some miners who are not exactly committed to the "core tenets of Bitcoin" even though they will talk the talk for a while and even walk the walk in order that might be able to wait for a better time to fuck around with their own dumbass sucking up to the PTB values that might be deeper within them...  Hey, but bitcoin was built for the ability to tolerate friends and foes from within and surely the incentives may well beat up upon some of the ones who play around too much.. .  We will see.. we will see. 

Nice to hear the statement though (even if it might not be their true feelings and thoughts).. so don't get me wrong about that.

Of course, we have to deal with ESG, KYC & AML, but each of them are attack vectors on Bitcoin to be avoided or minimized.

Put BTC here: 35EVP8EePt8dyvKHaB7bXaRmKLm22YgRCA

How much alt coin diversification is necessary? if you are investing in Bitcoin, then perhaps 0%?
pooya87
Legendary
*
Offline Offline

Activity: 2982
Merit: 8169


uFo-35?


View Profile
June 01, 2021, 02:40:14 AM
Merited by JayJuanGee (1)
 #345

Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”
I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

Wind_FURY
Legendary
*
Offline Offline

Activity: 2450
Merit: 1487



View Profile
June 01, 2021, 10:50:52 AM
 #346

Apparently, Marathon is going to signal Taproot Activation:


https://twitter.com/michael_saylor/status/1399407493839732744?s=21

From Marathon Press Release
Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,” said Fred Thiel, Marathon’s CEO. “Over the coming week, we will be updating all our miners to the full standard Bitcoin core 0.21.1 node, including support for Taproot. By adopting the full standard Bitcoin core node, we will be validating transactions on the blockchain in the exact same way as all other miners who use the standard node. We look forward to continue being a collaborative and supportive member of the Bitcoin community and to realizing the vision of Bitcoin as the first decentralized, peer-to-peer payment network that is powered by its users rather than a central authority or middlemen.”


hahahaha

Are they going to just temporarily behave well or go back into dumbass mode when it seems opportunistically beneficial to them.. .. time will tell.. and yeah, there are likely some miners who are not exactly committed to the "core tenets of Bitcoin" even though they will talk the talk for a while and even walk the walk in order that might be able to wait for a better time to fuck around with their own dumbass sucking up to the PTB values that might be deeper within them...  Hey, but bitcoin was built for the ability to tolerate friends and foes from within and surely the incentives may well beat up upon some of the ones who play around too much.. .  We will see.. we will see.  

Nice to hear the statement though (even if it might not be their true feelings and thoughts).. so don't get me wrong about that.


I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

ETFbitcoin
Legendary
*
Offline Offline

Activity: 2408
Merit: 5691


DO NOT store your coin on third-party service!


View Profile
June 01, 2021, 11:12:45 AM
 #347

Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”
I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

It's more likely investor realize censorship (by excluding certain address/transaction) isn't very profitable.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

First of all, the full node software must have feature to detect who mine block. However, i don't know any full node software which have such feature, so i guess it's not possible (at least for now).

fillippone
Legendary
*
pizza
Offline Offline

Activity: 1694
Merit: 11779


Merit Rascal - Pizza Maker


View Profile
June 01, 2021, 11:44:14 AM
 #348

Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”
I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

It's more likely investor realize censorship (by excluding certain address/transaction) isn't very profitable.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

First of all, the full node software must have feature to detect who mine block. However, i don't know any full node software which have such feature, so i guess it's not possible (at least for now).

My feeling is that stock price has little to do with this back-pedalling.
Sure, MARA stock has been lagging the market recently, but I. Guess their performance is highly correlated with bitcoin price.

I would rather point to the appointment of the new CEO: Fred Thiel has been nominated CEO since April 26th.

So he has been at the helm of MARA for a little bit more of one month.


Still,  I cannot figure out if this change in policy is the effect or the cause of this new appointment.
But I think this analysis, albeit very interesting, is quite off topic in this thread.

Karartma1
Legendary
*
Offline Offline

Activity: 2310
Merit: 1422



View Profile
June 01, 2021, 12:27:13 PM
Merited by fillippone (2)
 #349

Quote
“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”
I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

It's more likely investor realize censorship (by excluding certain address/transaction) isn't very profitable.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

First of all, the full node software must have feature to detect who mine block. However, i don't know any full node software which have such feature, so i guess it's not possible (at least for now).

My feeling is that stock price has little to do with this back-pedalling.
Sure, MARA stock has been lagging the market recently, but I. Guess their performance is highly correlated with bitcoin price.

I would rather point to the appointment of the new CEO: Fred Thiel has been nominated CEO since April 26th.

So he has been at the helm of MARA for a little bit more of one month.


Still,  I cannot figure out if this change in policy is the effect or the cause of this new appointment.
But I think this analysis, albeit very interesting, is quite off topic in this thread.

What if it's just a way to take time, comply with the bitcoin governance and secretly planning for counteroffensive? I always look for the motives behind the actions, I'm a kind of action-reaction guy. They have an agenda but for the time being it's not clear what they'll do but I guess we'll know soon.
Thanks for the info stallion
franky1
Legendary
*
Offline Offline

Activity: 3752
Merit: 3334



View Profile
June 01, 2021, 06:56:50 PM
 #350

i know its gonna get deleted but oh well..
once activated... pools can still fill blocks with native transactions.
all that happens is a pool not analysing every byte in a block may end up accepting a block that other pools reject.
EG if a malicious pool X:
(1)makes a broken taproot tx
(2)puts it into a block
(3)manages to be first to broadcast the solved block...
the pool Y not analysing all the data would just blindly accept it because they dont know the new taproot rules. and as such. would fork themselves as they would then be building on the wrong chain. as the other95% of pools would have rejected a block instantly as they have upgraded and seen its a broke tx and not include it.
the pool Y not analysing all the bytes might build on that block to create their own chain. or they orphan it off a few blocks later once they see other nodes orphaned that block

a pool cannot just push in a block with a duff transaction and think it will last. unless all the other pools dont know the ruleset.
hense needing solid majority to have upgraded. before even allowing a new tx format

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms

though i have no use for taproot atleast this time its a fair voting system with no backdoors to force it in. so if it activates. it activates


I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 3836
Merit: 7254



View Profile
June 01, 2021, 07:30:47 PM
Last edit: June 01, 2021, 08:11:43 PM by gmaxwell
Merited by JayJuanGee (1), ETFbitcoin (1), Karartma1 (1)
 #351

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms
Agreed, though the merchant in that case can be protected against an unupgraded miner by the merchant themselves upgrading.  If the merchant is upgraded they won't see the invalid confirmation.

A miner that intentionally produces an invalid block can cause non-validating clients to see a false confirmation is always true, not unique to taproot.  It is, however, a pretty expensive attack.

The high hashrate means that any invalid confirmations will go away quickly, and confirmations that go away after a block or two is already a thing people need to be prepared to handle due to reorgs.

So if you're upgraded you're protected by your upgrade, and if you're not-- you're still protected by the high hashpower.   If you're not validating at all, you're only protected by high hashpower, taproot or not.

One wrinkle in this is that right now many (most?) hashpower spends part of their mining time mining on non-validated work, because this is an easy 'optimization'.  I don't think it's a rationally justified optimization because you can get the same speedup from other approaches without losing validation but not validating has a low upfront cost.  This can cause short chains of invalid blocks where otherwise there would just be a single invalid block.  It really hurts the security assumptions of lite clients.  Fortunately, for the moment these non-validated blocks also contain no txn except for the coinbase, this isn't fundamental either but again its the easiest thing to do,  so wallets should probably not count chains of consecutive empty blocks as confirmations for confirmation counting purposes.

PrimeNumber7
Copper Member
Legendary
*
Offline Offline

Activity: 1414
Merit: 1859


Copper Member


View Profile
June 02, 2021, 03:20:07 AM
Merited by JayJuanGee (1)
 #352

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms
Agreed, though the merchant in that case can be protected against an unupgraded miner by the merchant themselves upgrading.  If the merchant is upgraded they won't see the invalid confirmation.

A miner that intentionally produces an invalid block can cause non-validating clients to see a false confirmation is always true, not unique to taproot.  It is, however, a pretty expensive attack.
A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules. A delay between a soft fork being “locked in” and when it is actually implemented reduces the risk that invalid blocks will be propagated by major pools.

A pool that doesn’t implement a softfork they oppose after said fork has been locked in can be compared to someone burning money. Any blocks they mine that violate the softfork rules will be orphaned by other miners.

███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████
.
█ █▀█ █▀█ █▀█  ▄  ▄▀▀ █   ▄▀█ ▀█▀ ▄▀▀ ▄███▄
█ █▀█ █ █ █ █ ▀█▀ ▀▀█ █   █ █  █  ▀▀█ ▀███▀
█ █▄█ █▄█ █▄█     ▄▄▀ ▀▄▄ █▄▀  █  ▄▄▀   
                                        █
████████████████████████████████████ 
███▀▀▀▀▀▀██████▀▀▀▀▀▀██████▀▀▀▀▀▀███ 
█▀▄██▀███▄▀██▀▄██▀███▄▀██▀▄██▀███▄▀████▄
█ █ ▀ ▀███ ██ █ ▀ ▀███ ██ █ ▀ ▀███ █████
█ ██    ▄█ ██ ██    ▄█ ██ ██    ▄█ █████
█▄▀██  ▀█▀▄██▄▀██  ▀█▀▄██▄▀██  ▀█▀▄████▀
███▄▄▄▄▄▄██████▄▄▄▄▄▄██████▄▄▄▄▄▄███
████████████████████████████████████
.
.
CRYPTO'S FASTEST
GROWING CASINO
         ▄▄▄████████████▄
     ▄▄████████████████████▄▄▄
   ▄███████████████████████████
  ████████████████████████████▀
 █████████████████████████████
███████████████████████████████
███████████████████████████████
███████████████████████████████
 █████████████████████████████
  ███████████████████████████
███████████████████████████▀
 █████████████████
███████▀▀
         ▀▀▀███████▀▀▀
                        ▄█████▄
           ▄▄           ███████
         ▄██            ▀█████▀
  ▄▄▄▄▄ ██▀▄▄██▄▄   ▄
 ▀▀▀▀██████▀▀▀▀      ██▄
   ▄██▀▀▀██▄     ▄▄▄▄▄██ ▄▄▄▄▄
  ██▀     ▀██▄     ▀▀▀█████▀▀▀▀
  ▀        ████     ▄██▀ ▀▀██
            ████   ▄██      ▀
       ▄▄▄████████████▄▄
    ▄█████████████████████▄
  ▄█████████████████████████▄
▄█████████████████████████████▄
.
..PLAY NOW..
pooya87
Legendary
*
Offline Offline

Activity: 2982
Merit: 8169


uFo-35?


View Profile
June 02, 2021, 04:38:15 AM
Merited by JayJuanGee (1), ETFbitcoin (1)
 #353

A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules.
This is unlikely because the bitcoin network (ie. full nodes verifying everything) by default won't propagate invalid transactions. New nodes because they validate Taproot and reject if it is invalid and old nodes because they see it as non-standard so even if they receive an invalid Taproot tx they simply won't relay.
The miner (or the pool) is also running a full node that doesn't accept version 1 witness program on its old node since it would see it as non-standard.

The only possible outcome of not upgrading is building on top of an invalid block. This is also unlikely because as I said above miners won't include anything they can't validate so it is already unlikely to see an invalid block.
A malicious miner could mine an invalid block intentionally but it costs a lot of money (wasted) and again we have the same arguments about propagation, the nodes won't propagate the block to reach the other miner to build on top of.

cygan
Legendary
*
Offline Offline

Activity: 2688
Merit: 4496


Icarus CEO 🔐


View Profile
June 02, 2021, 01:58:29 PM
 #354

the minerpools arkpool and okkong mined their first blocks signalling for taproot readiness Smiley


https://twitter.com/hampus_s/status/1399960827374063616

mara pool is still missing... Roll Eyes
https://taproot.watch/miner/MARA%20Pool

                 ██▄▄▄
                  ██████▄▄

   ▄█▄             ████████▄
  █████▄    ▄▄▄▀▀▀        ███
 ███████▄▄▀▀           ▄▄█████
███████▀             ▐█████████
█████                ▐█████████
█████▄▄▄▄             █████████
 █████████             ▀██████
  ████████▄▄             ▀▀██
   ▀██████████▄  ▄▌    ▄█▄
     ▀▀███████████▀  ███▀▀
         ▀▀▀██▀▀▀     ▀
.
.FortuneJack.......
         ▄█████▄
         ███▀▀██▄
  ▄▄▄▄▄ ▄██▌  ▐██  ▄█████▄▄
███▀▀██████    ██████▀ ▀███
 ██▄  ▀███▌ ▐▌ ▐███▀   ▐██▌
  ▀█▄ ▄  ▀  ██  ▀▀  ▄  ███
   ██▌ █▄  ▄██▄   ▄█▌ ▐██▌
   ▐█▌ ▐████████████  ▐██▌
    ██  ███████████▌  ███▌
    █▌  ▀▀▀▀▀▀▀      ▄███
    ▐█▄▄▄███▀▀██▀▀▀▀▀▀██▌
    ▐██▄    ▄▄▄▄▄▄▄▄▄▄██▌
     ▀█████▀▀▀▀▀▀▀▀▀██▀▀
▄█████▄▄   ▄▄▄        ▄▄                     ▄▄▄▄ ▄▄▄▄
██▌  ▐██▄█▀▀▀▀███▀▀▀█▀▀██▄█▀▀▀█▄█▀▀██▄███▀▀▀▀▀█▀▀▀█▀▀▀█▄
▐█▌  ▐███   ▄  █   ██   ██  ▄  ██   ██        ▌   █▌  ▐█
▐█▌  ████   █      █▀   ▀   ▀   █   █████  ▐██▌  ▐█   ██
██▌  ▀▀▀█  ▐█  ▄█▄▄  ▄▄█▄   ▄   █  ▐█▀▀██  ▐███▄▄   ▄█▀
██      ▐█▄   ▄███▌  ▐██▌  ▐█  ▄▌      █▀   ▐████   █▌
██▄▄██▀▀▀▀▀▀██████▄▄▄█████▄█████▄▄▄█████▄▄▄▄██████▄▄██
   ██      ▐██▀  ▀██▀▀   ▀████  ▀▀██▀   ▀  ▀▀    ▀██▀
  ▐█▌  ██▄▄██▀ ▄   █▄  ▄   ██  ▄  █▀   ▄  ▐█  ▄▄▄██▀
  ▐█▌  █    ▀       ▌  ▀  ▄▀          █▀▀▀█      ██
  ▐█▌  ▀▀  █   █▄  ▐▌    ▀▀▌   █   ▌  ▀▄  ▐█  ▀▀▀▀█▌
   ▀█▄    ▄█▄  ██▄▄▄   █▄▄█▄  ▐█▄▄▄█▄    ▄█▌  ▄▄▄▄██
     ▀▀███▀▀▀███▀ ▀████▀▀▀▀▀▀███▀   ▀████▀▀███▀▀▀
.
MAJESTIC
▄▄▄███████▄▄▄
▄▄█▀▀ ▀▄▄▄▄▄▄▄▀▀███▄▄
▄█▀▄▄█▄███████████▄▄▀███▄
██ ██████▀▀▀▀▀▀▀▀▀████▄▀███
██ ██████         ▄██████ ███
██  █████   ▄██   ▄████████ ███
██  █████████▀   ▄█████████ ███
██  ████████▀   ▄██████████ ███
██  ██████▀   ▄██████████ ███
██▄ ▀█████████████████▀▄███
▀██▄▄▀▀██████████ ▀▀ ▄██▀
▀▀███▄▄▄▀▀▀▀▄▄▄█▄██▀▀
▀▀▀███████▀▀▀
.
.......6 BTC WELCOME OFFER .....Join Now .>....
PrimeNumber7
Copper Member
Legendary
*
Offline Offline

Activity: 1414
Merit: 1859


Copper Member


View Profile
June 02, 2021, 09:55:49 PM
 #355

A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules.
This is unlikely because the bitcoin network (ie. full nodes verifying everything) by default won't propagate invalid transactions. New nodes because they validate Taproot and reject if it is invalid and old nodes because they see it as non-standard so even if they receive an invalid Taproot tx they simply won't relay.
The miner (or the pool) is also running a full node that doesn't accept version 1 witness program on its old node since it would see it as non-standard.

The only possible outcome of not upgrading is building on top of an invalid block. This is also unlikely because as I said above miners won't include anything they can't validate so it is already unlikely to see an invalid block.
A malicious miner could mine an invalid block intentionally but it costs a lot of money (wasted) and again we have the same arguments about propagation, the nodes won't propagate the block to reach the other miner to build on top of.
How do you think an invalid block would be mined in the first place? After a softfork, a miner including an invalid transaction in their block will result in an invalid block.

The miners' nodes are also more-or-less all connected to each other because the miners all want to be able to start mining on top of the most recent block as quickly as possible and waiting for blocks to naturally propagate throughout the network can take precious seconds (or longer) that a miner would be spent on building on top of what is not the most recent block. This means that any block that is propagated by a major miner, valid or otherwise will generally be seen by the other miners.

███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████
.
█ █▀█ █▀█ █▀█  ▄  ▄▀▀ █   ▄▀█ ▀█▀ ▄▀▀ ▄███▄
█ █▀█ █ █ █ █ ▀█▀ ▀▀█ █   █ █  █  ▀▀█ ▀███▀
█ █▄█ █▄█ █▄█     ▄▄▀ ▀▄▄ █▄▀  █  ▄▄▀   
                                        █
████████████████████████████████████ 
███▀▀▀▀▀▀██████▀▀▀▀▀▀██████▀▀▀▀▀▀███ 
█▀▄██▀███▄▀██▀▄██▀███▄▀██▀▄██▀███▄▀████▄
█ █ ▀ ▀███ ██ █ ▀ ▀███ ██ █ ▀ ▀███ █████
█ ██    ▄█ ██ ██    ▄█ ██ ██    ▄█ █████
█▄▀██  ▀█▀▄██▄▀██  ▀█▀▄██▄▀██  ▀█▀▄████▀
███▄▄▄▄▄▄██████▄▄▄▄▄▄██████▄▄▄▄▄▄███
████████████████████████████████████
.
.
CRYPTO'S FASTEST
GROWING CASINO
         ▄▄▄████████████▄
     ▄▄████████████████████▄▄▄
   ▄███████████████████████████
  ████████████████████████████▀
 █████████████████████████████
███████████████████████████████
███████████████████████████████
███████████████████████████████
 █████████████████████████████
  ███████████████████████████
███████████████████████████▀
 █████████████████
███████▀▀
         ▀▀▀███████▀▀▀
                        ▄█████▄
           ▄▄           ███████
         ▄██            ▀█████▀
  ▄▄▄▄▄ ██▀▄▄██▄▄   ▄
 ▀▀▀▀██████▀▀▀▀      ██▄
   ▄██▀▀▀██▄     ▄▄▄▄▄██ ▄▄▄▄▄
  ██▀     ▀██▄     ▀▀▀█████▀▀▀▀
  ▀        ████     ▄██▀ ▀▀██
            ████   ▄██      ▀
       ▄▄▄████████████▄▄
    ▄█████████████████████▄
  ▄█████████████████████████▄
▄█████████████████████████████▄
.
..PLAY NOW..
kano
Legendary
*
Offline Offline

Activity: 4060
Merit: 1700


Linux since 1997 RedHat 4


View Profile
June 02, 2021, 11:37:55 PM
 #356

Alas there is a bigger issue, that the large majority of the mining hash rate doesn't verify any transactions when they first generate work after a block change.

Since this small window exists, there is the quite reasonable chance of another pool finding a block on top of an invalid block.
If this next block is valid, the questions follows of what do all these pools do when they see this valid block built on top of an invalid block?

History shows that they just continue on when this happened once before.
The issue being how tightly is the pool work generation tied into a full bitcoin daemon that would reject both of these blocks?
... and unless every large pools just copies code from every other large pool, there will no doubt be many different answers to this question.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
NotATether
Legendary
*
Online Online

Activity: 1134
Merit: 4772


Defend Bitcoin and its PoW: bitcoincleanup.com


View Profile WWW
June 03, 2021, 12:04:38 PM
 #357

The issue being how tightly is the pool work generation tied into a full bitcoin daemon that would reject both of these blocks?

Given that pretty much all the pools are using stratum that means this is a question of how often the stratum servers are querying bitcoind. Mining hardware can't stop hashing while it waits for bitcoind to do its verification because it doesn't even know when and at what rate it's running.

If this next block is valid, the questions follows of what do all these pools do when they see this valid block built on top of an invalid block?

History shows that they just continue on when this happened once before.

If a pool submits a block immediately without doing any verification, then eventually when a split happens and the pool's chain is outrun then its mining rewards will be invalidated. And if a pool risks verifying before submitting the block then another pool might submit a block before them and they lose out. So there isn't really a benefit for pool to push for either case, so naturally, most go for the short-term route of submitting the block as quickly as possible, which means that there's always going to be cases of invalid blocks sneaking into the chain at least temporarily.

gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 3836
Merit: 7254



View Profile
June 03, 2021, 03:09:44 PM
Merited by JayJuanGee (1)
 #358

can't stop hashing while it waits for bitcoind to do its verification
Actual validation typically takes under 50 milliseconds or so-- and even faster on hardware with sha-ni--, typically because almost all the validation is cached. During that amount of time you might as well stay on the prior block because you have a non-zero chance of winning on the prior block anyways in a race, and not including transactions will greatly reduce your income.

But the validation isn't the only, or largest, source of delay.  E.g. constructing a block template takes time.  Miners could instead always mine on already validated tips, but include a very suboptimal block (including empty) on the initial work they generate on a new block, but that would take more work to implement than just monitoring other miners and mining whatever other header they mine on.  It also avoids worrying about various other block propagation DOS vectors.   But it really trashes the security assumptions of SPV pretty bad.

It's kind of a circus, eventually some miner going to do that is going to get a SPV user robbed, and since all the miners are helpfully identifying themselves, they're going to get sued for damages by the robbed user and it's going to turn into a complete circus.  Years ago I talked a major exchange out of attempting to sue miners that mined txns which weren't the same ones the exchange saw first... took some real effort to get them to understand that just because they saw the other spend first that didn't mean the miner did.

Fortunately, you can opt out of the exposure by running your own full node and keeping it up to date, or by treating high value transactions from untrusted parties as unconfirmed until they have a dozen confirmations or so.
nibor
Sr. Member
****
Offline Offline

Activity: 438
Merit: 290


View Profile
June 03, 2021, 07:55:09 PM
Merited by JayJuanGee (1)
 #359

gmaxwell - do you think that many pools are reliant on patched bitcoind nodes to maximise their profits (since most are pps - it is their profit not the miners that is impacted by orphans/empty block trade-off).

Those 20 pools are arguably the most critical users of bitcoin core. And should it not include every possible optimisation (even if at expense of SPV) to ensure they run vanilla code. As that then ensures that future soft/hard forks go smoothly as those 20 users just have to do an upgrade from version 2x ->2y - rather than having to try to merge in some old patch and try to test it works as expected.

Or is issue that those patches are proprietary and what gives them their competitive advantage.

I guess since the pools are operating off 2.5% margin on pps - it magnifies by a factor of 40 P&L impact of orphans.
gmaxwell (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 3836
Merit: 7254



View Profile
June 03, 2021, 10:47:43 PM
Merited by JayJuanGee (1), ETFbitcoin (1)
 #360

Or is issue that those patches are proprietary and what gives them their competitive advantage.
It's mostly not patches but external mining software. Some of the less good things they do are done because thats whats easy to do outside of the daemon. Not so fun to reimplement consensus rules, so why bother?

The viabtc mining code is public and you can see many such approximations.  E.g. they decide if an incoming block meets the target by the deriving a number of leading zeros off the floating point difficult number rather than an accurate target test.  So if you make a block with a lot of leading zeros but still doesn't meet the target, that code will temporarily switch to it and mine children that will be ignored by every bitcoin node an wallet.   There is no meaningful computational cost in doing the test accurately-- it's just more implementation effort for an external codebase. The fact that it's fairly easy to attack (mining hardware ordinarily returns sub target work, so it would be easy enough to filter that for work that met the relaxed test but not the real target... Presumably they'd fix it once they noticed they lost blocks to it.

Quote
I guess since the pools are operating off 2.5% margin on pps - it magnifies by a factor of 40 P&L impact of orphans.
One thing to consider is that 2.5% PPS is pretty much guaranteed to go bankrupt per kelly criterion with a reasonable bankroll.  Computationally bounded rationality can be a problem when your system's assumptions depend on rational self interest. Tongue

One place where Bitcoin suffers is that it's very stable, and you can keep running old versions. As a result multicryptocurrency pools spend a lot of attention on trashfire altcoins that needs constant emergency fixes, and less on Bitcoin. There have been problems with stuff like newer bitcoin needing a compiler no less than 3 years old but some large miners have much older operating systems.  I don't think there is any real fix except increasing the rate of change-- it's a point I've raised in disagreements that argue that Bitcoin's conservative approach is safer. To a point that's true, but there is a point where being too slow to introduce changes introduces its own risks.

Hopefully taproot marks the end of a one time dry spell and with renewed confidence that clear improvements can be activated without disruption more will be written.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!