- Aug 19, 2015
- 511
- 803
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
@awemany To be clear, you're saying that the inherent assumption of a specific (arbitrary) timescale when asking how much hashpower a miner has means that "overpowered by an attacker" also has a timescale assumption baked in?
So that we cannot even really say the attacker is majority or minority until after the fact, at a certain distance in time after the event?
And in fact the very status of the miner as an "attacker" (in the sense of not following the rules set by the majority hashpower) is not determined until he turns out not to be in the majority (after more time has passed)?
And that the majority rules are anyway also only knowable in retrospect, after a comfortable amount of time, so that the chain tip is - if we are being precise and accounting for all cases - a radically uncertain place where the protocol rules themselves, the status of who is an attacker and who isn't, who is honest and who isn't, and who is "overpowering the network" and who is just "upgrading the network to a new ruleset" is yet to be determined?
This is ponderous, man. Really ponderous.
Plenty of room for (mis)interpretation that favors a propagandist's agenda.
So that we cannot even really say the attacker is majority or minority until after the fact, at a certain distance in time after the event?
And in fact the very status of the miner as an "attacker" (in the sense of not following the rules set by the majority hashpower) is not determined until he turns out not to be in the majority (after more time has passed)?
And that the majority rules are anyway also only knowable in retrospect, after a comfortable amount of time, so that the chain tip is - if we are being precise and accounting for all cases - a radically uncertain place where the protocol rules themselves, the status of who is an attacker and who isn't, who is honest and who isn't, and who is "overpowering the network" and who is just "upgrading the network to a new ruleset" is yet to be determined?
This is ponderous, man. Really ponderous.
Plenty of room for (mis)interpretation that favors a propagandist's agenda.
@Zangelbert Bingledack
I think too of the analagous evolutionary tree of life where today's life is represented by the outer tips of the tree. The inner branches represent life's evolutionary history, [the path of] current life's emergence.
[Edit]
Isn't this the essence of 'Emergent Consensus'? It describes the current state of what has emerged: that current state is dynamic, always subject to change.
I think too of the analagous evolutionary tree of life where today's life is represented by the outer tips of the tree. The inner branches represent life's evolutionary history, [the path of] current life's emergence.
[Edit]
Last edited:
BUIP055: Increase the Block Size Limit at a Fixed Block Height
https://bitco.in/forum/threads/buip055-increase-the-block-size-limit-at-a-fixed-block-height.2103/
https://bitco.in/forum/threads/buip055-increase-the-block-size-limit-at-a-fixed-block-height.2103/
@Zangelbert Bingledack : Yes, basically that's what I am saying.
Peter R. mentioned 'the collapse of the wave-function' somewhere when talking about how the uncertainty of the chain's exact state raises and then is 'collapsed into certainty' with a block arriving. However, certainty on a transaction never truly go to zero, it is all relative. 6 blocks down and all that
AFAIR we talked about this further, and this "Copenhagen Interpretation of the Blockchain" comparison actually lead to a couple quite curious analogies.
What also is interesting to look at is time cones and the lower end of time scales - and what information you actually have available, locally, at a node, to work with.
I wrote earlier that this event horizon causes for a floor to exist on the efficiency of 'xthin' or 'compactblock' or 'IBLT' block exchange, as there will be entropy of new transactions arriving in the network, but with *different* information arriving at different nodes, if you only make the time interval small enough.
I really like to find the time to ponder about this further, as I expect (though cannot prove) that along these lines, you'll arrive at a natural, physical lower limit for fees. So that one is able to strike out the "(assuming inflation)" from "A transaction fee market exists without a blocksize limit (assuming inflation)".
AFAIR @Peter R. tried this, but hasn't anything finished on that yet?
Peter R. mentioned 'the collapse of the wave-function' somewhere when talking about how the uncertainty of the chain's exact state raises and then is 'collapsed into certainty' with a block arriving. However, certainty on a transaction never truly go to zero, it is all relative. 6 blocks down and all that
AFAIR we talked about this further, and this "Copenhagen Interpretation of the Blockchain" comparison actually lead to a couple quite curious analogies.
What also is interesting to look at is time cones and the lower end of time scales - and what information you actually have available, locally, at a node, to work with.
I wrote earlier that this event horizon causes for a floor to exist on the efficiency of 'xthin' or 'compactblock' or 'IBLT' block exchange, as there will be entropy of new transactions arriving in the network, but with *different* information arriving at different nodes, if you only make the time interval small enough.
I really like to find the time to ponder about this further, as I expect (though cannot prove) that along these lines, you'll arrive at a natural, physical lower limit for fees. So that one is able to strike out the "(assuming inflation)" from "A transaction fee market exists without a blocksize limit (assuming inflation)".
AFAIR @Peter R. tried this, but hasn't anything finished on that yet?
go1111111
Active Member
My general claim was incentives between miners and users are not perfectly aligned. You seemed to disagree. IMO this was the main thing under discussion. The particular statement you refer to above was just an off-the-cuff example intended to make the general point obvious.
The following are my last two questions on the topic, which I'd be satisfied with just a 'yes' or 'no' answer to, unless you have a change of heart and actually want to discuss it.
(1) Do you think the incentives between companies and their customers are perfectly aligned?
(2) Do you think incentives between owners and management of a company are perfectly aligned?
To make clear why I'm harping on this issue: Zangelbert is one of the two best pro-big-block writers (along with Roger Murdock). If someone is smart but doesn't fully get the big-block / decoupled-consensus cause, I'm usually better off linking them to the writings of Zangelbert than trying to convince them myself. Zangelbert (and other big-blockers) being wrong about this issue (which IMO is relatively basic and should be resolvable via a bit of discussion) makes the big-block cause itself seem more questionable.
There is a choice. The practical effect of our disagreement is about how vigilant users should be about miner-punishing hard forks. If I'm right, then users should pay close attention to make sure miners aren't straying too far from behavior that benefits users. Users should be willing to change the PoW or threaten to, to keep miners in line. I see this as an important part of the balance of power.
If you're right, this is unnecessary. Users should never have to change PoW (unless perhaps a government or non-profit-motivated attacker gets control of 51%+ of hash power), because we should never expect profit-motivated miners to do anything against the interest of users. So users can just relax and not worry about what the miners are up to.
Last edited:
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
Nah. The simple fact is that the valid chain is what I and the person I am transacting with agree is the valid chain
go1111111
Active Member
I finally read through this chatlog w/ comments from CSW that people have been talking about: https://pastebin.com/gjsGpBb9.
The general claim is that SegWit will lead to miners not validating signatures at all. I don't see how the argument works. I'll try to summarize:
Traditional validationless mining apparently worked something like this:
(1) Get block header of the previous block
(2) Immediately start mining an empty block on the previous block header
(3) In parallel, download the entire previous block.
(4) When the previous block is downloaded, validate it.
(5) If you find a new (empty) block before you finish validating the previous one, publish it ASAP. If you finish validating before you find a new block, you can add transactions to the block you're working on.
Allegedly validationless mining with SegWit will look like:
(1) Get block header of the previous block
(2) Immediately start mining an empty block on the previous block header
(3) In parallel, first download the previous block without any signature data. This may be 1/4 the size of the entire block with signature data.
(4) Once you have the info from step 3, you can start adding in transactions to the block you're working on, because you know which outputs have already been spent.
(5) For some strange reason, never download and validate the signatures for the previous block.
Step 5 in the SegWit case is the questionable step. I don't see a good reason why miners wouldn't want to validate the signatures.
In the chat log, someone speculated that validating the signatures would make mining slower, but this isn't true. The ASIC is running a separate process on dedicated hardware, which isn't affected by efforts to download and validate the signatures.
Note that Greg Maxwell claims at that with SegWit, nodes don't actually send around transactions stripped of the witness data. That would mean that step 3 is incorrect / impossible without modifying the network code. However, even if CSW is right and Greg is wrong about this, I still see no good reason why a miner wouldn't want to download and verify the full blocks as a separate step. It would likely take a few seconds, and it would protect them against mining on a chain that is rejected by users because of invalid signatures.
There is some talk in the chat logs about how if no one else is validating the signatures, then miners also have no reason to validate the signatures. However, I don't see the argument for why people would suddenly all decide to stop validating the signatures at the same time, coinciding with SegWit activation.
Fundamentally, the chain which users care more about will be more valuable. As long as users have some way to distinguish which chain is which (by running full nodes, or asking someone they trust who runs a full node), then they will be able to identify the chain that they care more about, and demand more coins on that chain, causing its price to be higher, and making it more profitable to mine on that chain. The reasoning in the chat log I linked to seems to assume that users no longer care whether signatures are valid, and stop running full nodes.
Again, not sure why people think users would suddenly stop caring about which chain is which.
If I misrepresented the argument, can someone fill in the details? The chat log was kind of cryptic and hard to follow.
The general claim is that SegWit will lead to miners not validating signatures at all. I don't see how the argument works. I'll try to summarize:
Traditional validationless mining apparently worked something like this:
(1) Get block header of the previous block
(2) Immediately start mining an empty block on the previous block header
(3) In parallel, download the entire previous block.
(4) When the previous block is downloaded, validate it.
(5) If you find a new (empty) block before you finish validating the previous one, publish it ASAP. If you finish validating before you find a new block, you can add transactions to the block you're working on.
Allegedly validationless mining with SegWit will look like:
(1) Get block header of the previous block
(2) Immediately start mining an empty block on the previous block header
(3) In parallel, first download the previous block without any signature data. This may be 1/4 the size of the entire block with signature data.
(4) Once you have the info from step 3, you can start adding in transactions to the block you're working on, because you know which outputs have already been spent.
(5) For some strange reason, never download and validate the signatures for the previous block.
Step 5 in the SegWit case is the questionable step. I don't see a good reason why miners wouldn't want to validate the signatures.
In the chat log, someone speculated that validating the signatures would make mining slower, but this isn't true. The ASIC is running a separate process on dedicated hardware, which isn't affected by efforts to download and validate the signatures.
Note that Greg Maxwell claims at that with SegWit, nodes don't actually send around transactions stripped of the witness data. That would mean that step 3 is incorrect / impossible without modifying the network code. However, even if CSW is right and Greg is wrong about this, I still see no good reason why a miner wouldn't want to download and verify the full blocks as a separate step. It would likely take a few seconds, and it would protect them against mining on a chain that is rejected by users because of invalid signatures.
There is some talk in the chat logs about how if no one else is validating the signatures, then miners also have no reason to validate the signatures. However, I don't see the argument for why people would suddenly all decide to stop validating the signatures at the same time, coinciding with SegWit activation.
Fundamentally, the chain which users care more about will be more valuable. As long as users have some way to distinguish which chain is which (by running full nodes, or asking someone they trust who runs a full node), then they will be able to identify the chain that they care more about, and demand more coins on that chain, causing its price to be higher, and making it more profitable to mine on that chain. The reasoning in the chat log I linked to seems to assume that users no longer care whether signatures are valid, and stop running full nodes.
Again, not sure why people think users would suddenly stop caring about which chain is which.
If I misrepresented the argument, can someone fill in the details? The chat log was kind of cryptic and hard to follow.
cypherblock
Active Member
- Nov 18, 2015
- 163
- 182
First, please see peter todd's email to bitcoin dev list, as csw cited that and has some background on validationless mining under segwit. I didn't see any responses on dev list to his concerns, maybe it is no longer an issue or just not likely to happen.
Step 3 would happen naturally if you are running a non-segwit node which (I think) is possible even for miners when segwit is activated. Non-segwit nodes will just get blocks as normal but minus signature data in segwit txs.
Questions: Miners have their own relay network which many are using, so under that system, what is time difference to get full block(with witness) vs. full block without witness ? Also what is the time to validate an average Tx? Does compact blocks play into this at all (miners could run segwit node and validate sigs as txs arrive, when block comes in 90% of txs may already be validated in mempool)?
Step 3 would happen naturally if you are running a non-segwit node which (I think) is possible even for miners when segwit is activated. Non-segwit nodes will just get blocks as normal but minus signature data in segwit txs.
Questions: Miners have their own relay network which many are using, so under that system, what is time difference to get full block(with witness) vs. full block without witness ? Also what is the time to validate an average Tx? Does compact blocks play into this at all (miners could run segwit node and validate sigs as txs arrive, when block comes in 90% of txs may already be validated in mempool)?
BU ver 1.0.2.0 released
Download: https://www.bitcoinunlimited.info/download
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/v1.0.2.0/doc/release-notes/release-notes-1.0.2.0.md
Ubuntu PPA update in progress
https://www.reddit.com/r/btc/comments/6akhjs/bitcoinunlimited_1020_has_been_released/
Download: https://www.bitcoinunlimited.info/download
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/v1.0.2.0/doc/release-notes/release-notes-1.0.2.0.md
Ubuntu PPA update in progress
https://www.reddit.com/r/btc/comments/6akhjs/bitcoinunlimited_1020_has_been_released/
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
The idea that miners will stop caring about minning on a valid chain is a Todd( paranoid concern which has no bisist in reality ) the fact that they are willing to take a small risk and validate seconds later, should not be taken as evidence they might want to risk mining carelessly forever. header first mining is a smart calculated risk, not a slippery slope, if header-first-produced-blocks can be made to include new TX, we are better off.
cypherblock
Active Member
- Nov 18, 2015
- 163
- 182
Miners will probably take whatever short cuts they can, but I agree that there is little incentive to skip validating sigs. However they might want to get that data separately from rest of block, so that they can start mining full blocks as fast as possible. There is no way to do that (get sigs separate from block data) at the moment (in segwit code) as far as I know, so that could lead to skipping the download of that data entirely.
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
@cypherblock
IMO miners take short cuts at THEIR own risk, and thats just fine.
with Xthin or "compact" blocks downloading even 16MB blocks is probably quite trivial for miners. validation might be the most time consuming thing by far, so downloading the full block and building another full block on top without waiting for validation to finish might be a good idea for miners since block fees is no longer insignificant. maybe some are doing this already and dont want to admit to it... i think its a non issue, it's a fair and square calculated risk to take. IMO
But, it might be that validation time of a block can be cut down drastically by validating TX as they come in, and skipping thos already validated TX. "Thin-Validation" ? lol
IMO miners take short cuts at THEIR own risk, and thats just fine.
with Xthin or "compact" blocks downloading even 16MB blocks is probably quite trivial for miners. validation might be the most time consuming thing by far, so downloading the full block and building another full block on top without waiting for validation to finish might be a good idea for miners since block fees is no longer insignificant. maybe some are doing this already and dont want to admit to it... i think its a non issue, it's a fair and square calculated risk to take. IMO
But, it might be that validation time of a block can be cut down drastically by validating TX as they come in, and skipping thos already validated TX. "Thin-Validation" ? lol
BU Ubuntu PPA repositories updated to ver 1.0.2.0
https://www.reddit.com/r/btc/comments/6amott/ubuntu_ppa_bitcoin_unlimited_repositories_updated/
https://www.reddit.com/r/btc/comments/6amott/ubuntu_ppa_bitcoin_unlimited_repositories_updated/
The Bitcoin Unlimited Voting System is now live! Big thanks to @awemany for taking on and completing this huge initiative!!
https://www.bitcoinunlimited.info/voting/
Reddit thread:
https://www.reddit.com/r/btc/comments/6amlyq/bitcoin_unlimited_launches_new_buip/
https://www.bitcoinunlimited.info/voting/
Reddit thread:
https://www.reddit.com/r/btc/comments/6amlyq/bitcoin_unlimited_launches_new_buip/
Part of the page seems incomplete:
@throwaway: Indeed, good catch. Missing "proposal. ". Fixed now. Thanks!
go1111111
Active Member
I agree with @adamstgbit that this seems like another case of Peter Todd's paranoia. I'm not opposed to the fix he proposes because it doesn't really hurt anything, but I don't see this as a big deal.
The situation Peter is worried about is that miners mine a long invalid chain, and then at some point someone wises up to the fact that the chain is invalid, and there's a huge re-org. The thing that CSW seem to be saying will happen is that users will find out that the chain is invalid, and decide that they don't care, and that they want to continue using coins on the invalid chain. This seems extremely implausible to me.
If a miner chose to do that, it could happen, but a profit-seeking miner would not choose to do that because in addition to not knowing which blocks are valid, they would be missing out on fee income from SegWit transactions. There's no offsetting benefit to them to make it worth missing out on these fees.
After talking in the btcchat slack a bit after my post, I encountered a twist on the argument:
The claim is that miners would intentionally keep signature data private, and only share it among a cartel of large miners. Or they would charge money for revealing their signature data. This would essentially make it impossible for full nodes to validate the chain, without paying miners. It seems very likely that if a mining cartel formed to keep signature data private, they would be punished with a PoW-changing HF. This cartel essentially becomes one centralized entity at this point. People would not want to use this chain for the same reason you wouldn't want to use "Bank of America Coin", where Bank of America issued tokens and made up the rules for issuing more or spending them according to their whim.
This discussion on miners mining without validating the witness data is fascinating. From what I've gathered so far, the key points are:
1. In order to mine a non-empty block and claim fee revenue, a miner needs an up-to-date UTXO set.
2. With regular bitcoin transactions, it is impossible to update the UTXO set without having all of the data, including the signature data.
3. With segwit transactions, because the "witness is segregated," this is no longer true. A miner can update his UTXO set and begin mining non-empty blocks without the signature data.
With regular bitcoin transactions there is both an incentive for the miner who finds a block to transmit his solution--in its entirety--as quickly as possible (i.e., to reduce the chance that another miner finds a block at the same height [orphan risk]), and an incentive for the other miners to receive the solution--in its entirety--as quickly as possible (i.e., so that they can include fee-paying transactions in their block candidates).
Segwit changes this balance. With segwit, the other miners probably aren't in as much of a hurry to receive the witness data, because they can include fee-paying transactions in their blocks without it. Furthermore, the miner who finds the block is probably also in less of a hurry to propagate the witness data because most miners probably start mining on the block as soon as they've updated the UTXO sets anyways (i.e., longer propagation time for the witness portion will probably have less effect on orphan probability compared to longer propagation time for the main block).
And what happens if a miner mines a block and holds back the witness data by 5 minutes? Are the other miners really not going to mine on it?
Does this throw off the balance of incentives enough to render segwit transactions insecure? I don't know. It would be fun to try to come up with a model and work through the game theory.
1. In order to mine a non-empty block and claim fee revenue, a miner needs an up-to-date UTXO set.
2. With regular bitcoin transactions, it is impossible to update the UTXO set without having all of the data, including the signature data.
3. With segwit transactions, because the "witness is segregated," this is no longer true. A miner can update his UTXO set and begin mining non-empty blocks without the signature data.
With regular bitcoin transactions there is both an incentive for the miner who finds a block to transmit his solution--in its entirety--as quickly as possible (i.e., to reduce the chance that another miner finds a block at the same height [orphan risk]), and an incentive for the other miners to receive the solution--in its entirety--as quickly as possible (i.e., so that they can include fee-paying transactions in their block candidates).
Segwit changes this balance. With segwit, the other miners probably aren't in as much of a hurry to receive the witness data, because they can include fee-paying transactions in their blocks without it. Furthermore, the miner who finds the block is probably also in less of a hurry to propagate the witness data because most miners probably start mining on the block as soon as they've updated the UTXO sets anyways (i.e., longer propagation time for the witness portion will probably have less effect on orphan probability compared to longer propagation time for the main block).
And what happens if a miner mines a block and holds back the witness data by 5 minutes? Are the other miners really not going to mine on it?
Does this throw off the balance of incentives enough to render segwit transactions insecure? I don't know. It would be fun to try to come up with a model and work through the game theory.
Last edited: