Economics: On the nature, role, and relationship of miners vs nodes
11-03-2023
, 01:35 AM
Quote:
jbouton: What is the nature, role, and relationship between miners and nodes? And how does this question help us weed out fakes?
27offsuit: One does the work and the other confirms and rewards the work?
jbouton: That's a great start. But do you mean to imply they are necessarily different or not the same entity, etc.?
jbouton: And who decides what 'valid' means in regard to confirming the work?
27offsuit: No idea.
jbouton: Awesome. We can all get to the bottom of it together.
27offsuit: Emergent consensus?
jbouton: How can this be? Quoting Satoshi: "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." Source
jbouton: And consensus among whom?
27offsuit: One does the work and the other confirms and rewards the work?
jbouton: That's a great start. But do you mean to imply they are necessarily different or not the same entity, etc.?
jbouton: And who decides what 'valid' means in regard to confirming the work?
27offsuit: No idea.
jbouton: Awesome. We can all get to the bottom of it together.
27offsuit: Emergent consensus?
jbouton: How can this be? Quoting Satoshi: "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." Source
jbouton: And consensus among whom?
11-03-2023
, 02:22 AM
I like the approach of focusing on factual technical aspects, this provides a good neutral ground that nurtures other harder subjective and predictive questions.
Regarding the questions posited towards the functioning of the BTC network, I as well am not 100% sure on the inner workings, but the general idea that 27offsuit posits is what I understand ass well. The exact workings are something that I will only truly grok once I run my own node, but for now we can investigate superficially together.
I will expose my current understanding on the matter, make note of the questions, and later consult sources.
1- Every 10 minutes, every mining-node starts computing hashes, looking for a nonce that hashes to anything below the difficulty.
2- Once someone finds such a node, they announce it to the network.
3- The transaction-receiving-nodes , check the new block, to verify if their address is credited with any incoming BTC.
4- Either the miner node, or a transaction-mining-node that has been deputized by the miner node, checks a list of pending transactions, and if the reward is worth it, checks whether they prove that the transactions were initiated by the owner (and possibly distributes a new secret to the sender-node), and advertises the results. I have some ideas on how this could be done, but I'm not sure.
5- Difficulty is adjusted, possibly by a prepublished algorithm using the diff between the timestamp of the new block and the last one.
Repeat.
Verification sometimes taking a few blocks is probably so that miners of a single block can't claim that they are being transfered ridiculous amounts of money, the next block will just fail to verify that and will continue from the previous block.
Possibility for 4.
- Owner of new block plays crypto challenge-response with nodes to verify ****. For example:
-- Talk with sending nodes to verify that they authorized the sending transactions in the pending queue.
-- Publish the authorized tx in the new block.
-- Respond to verification requests from existing nodes?
Another question that didn't quite connect is how the nodes broadcast to each other, if they do at all. They may be following the block chain, and the address and port of the nodes may be published in the blocks. So verifying nodes would never be broadcasted so to speak.
I don't think there's any deputization, the only ones who can complete transactions, and receive rewards for doing so, are miner blocks. So mining and verifying are the same thing in that sense, but other nodes can also participate in the verification by doing transactions, as they must chose the block head, the must necessarily be following the blockchain and "verifying" everything, asking only the node that published the new block to publish and "verify" their transaction.
Unless I made a mistake, that should answer most questions. Including:
What is the nature, role, and relationship between miners and nodes? miners are nodes, they get rewarded for PoW and for verifying transactions, not all nodes mine, nodes may transact or passively observe as well.
And who decides what 'valid' means in regard to confirming the work? Diff hash solvers verify what the valid transactions are and what the previous block head was. The next diff hash solver verifies the previous diff hash by choosing it to publish their new block.
That's a great start. But do you mean to imply they are necessarily different or not the same entity, etc.? They are the same entity in that they are all of the same class, everyone has the same rights, but whenever someone mines a block, they get to play the role of the authority for 10 minutes. The only difference between a miner and a non miner occurs when they get a reward, otherwise they are just another nobody. There is no verifying node, and there is no transaction-miner, there's only miners who create a new block, and transactions who request the miner to add their transaction to the block, and observer nodes who follow what's going on without any stake.
" How can this be? Quoting Satoshi: "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.": In a sense it may be right, because the code that everyone is running was decided beforehand, you cannot modify it afterwards, take the algorithm that defines the difficulty hash, it cannot depend upon what the miner publishes, as they could just end the chain by publishing nonsense, all nodes need to agree on what the new difficulty is exactly independently, otherwise values near the limit could split the network.
That said, this was probably written before forks, which through consensus achieved bipartisan code changes.
new question: How does the network respond to 2 solves within the same timeframe. Possible response: The network will probably split, possibly geographically due to latency, but eventually a majority is reached.
But what happens if there is a tie and the network is irreversibly split? Suppose that one half believes they have a 51 against 49%, and the other half believes they have a 49% against a 51%.I know this might not make sense, since the disputes are resolved on an integer scale, since each vote is essentially a 10 minute block, so a 51% vs 49% would look like a dispute that spans over 1000 minutes! I don't see what guarantees that one half of the chain eventually desist. I say chain and not nodes, because I can see a node splitting their mining across two heads if they remain neutral and hedge their bets.
Regarding the questions posited towards the functioning of the BTC network, I as well am not 100% sure on the inner workings, but the general idea that 27offsuit posits is what I understand ass well. The exact workings are something that I will only truly grok once I run my own node, but for now we can investigate superficially together.
I will expose my current understanding on the matter, make note of the questions, and later consult sources.
1- Every 10 minutes, every mining-node starts computing hashes, looking for a nonce that hashes to anything below the difficulty.
2- Once someone finds such a node, they announce it to the network.
3- The transaction-receiving-nodes , check the new block, to verify if their address is credited with any incoming BTC.
4- Either the miner node, or a transaction-mining-node that has been deputized by the miner node, checks a list of pending transactions, and if the reward is worth it, checks whether they prove that the transactions were initiated by the owner (and possibly distributes a new secret to the sender-node), and advertises the results. I have some ideas on how this could be done, but I'm not sure.
5- Difficulty is adjusted, possibly by a prepublished algorithm using the diff between the timestamp of the new block and the last one.
Repeat.
Verification sometimes taking a few blocks is probably so that miners of a single block can't claim that they are being transfered ridiculous amounts of money, the next block will just fail to verify that and will continue from the previous block.
Possibility for 4.
- Owner of new block plays crypto challenge-response with nodes to verify ****. For example:
-- Talk with sending nodes to verify that they authorized the sending transactions in the pending queue.
-- Publish the authorized tx in the new block.
-- Respond to verification requests from existing nodes?
Another question that didn't quite connect is how the nodes broadcast to each other, if they do at all. They may be following the block chain, and the address and port of the nodes may be published in the blocks. So verifying nodes would never be broadcasted so to speak.
I don't think there's any deputization, the only ones who can complete transactions, and receive rewards for doing so, are miner blocks. So mining and verifying are the same thing in that sense, but other nodes can also participate in the verification by doing transactions, as they must chose the block head, the must necessarily be following the blockchain and "verifying" everything, asking only the node that published the new block to publish and "verify" their transaction.
Unless I made a mistake, that should answer most questions. Including:
What is the nature, role, and relationship between miners and nodes? miners are nodes, they get rewarded for PoW and for verifying transactions, not all nodes mine, nodes may transact or passively observe as well.
And who decides what 'valid' means in regard to confirming the work? Diff hash solvers verify what the valid transactions are and what the previous block head was. The next diff hash solver verifies the previous diff hash by choosing it to publish their new block.
That's a great start. But do you mean to imply they are necessarily different or not the same entity, etc.? They are the same entity in that they are all of the same class, everyone has the same rights, but whenever someone mines a block, they get to play the role of the authority for 10 minutes. The only difference between a miner and a non miner occurs when they get a reward, otherwise they are just another nobody. There is no verifying node, and there is no transaction-miner, there's only miners who create a new block, and transactions who request the miner to add their transaction to the block, and observer nodes who follow what's going on without any stake.
" How can this be? Quoting Satoshi: "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.": In a sense it may be right, because the code that everyone is running was decided beforehand, you cannot modify it afterwards, take the algorithm that defines the difficulty hash, it cannot depend upon what the miner publishes, as they could just end the chain by publishing nonsense, all nodes need to agree on what the new difficulty is exactly independently, otherwise values near the limit could split the network.
That said, this was probably written before forks, which through consensus achieved bipartisan code changes.
new question: How does the network respond to 2 solves within the same timeframe. Possible response: The network will probably split, possibly geographically due to latency, but eventually a majority is reached.
But what happens if there is a tie and the network is irreversibly split? Suppose that one half believes they have a 51 against 49%, and the other half believes they have a 49% against a 51%.I know this might not make sense, since the disputes are resolved on an integer scale, since each vote is essentially a 10 minute block, so a 51% vs 49% would look like a dispute that spans over 1000 minutes! I don't see what guarantees that one half of the chain eventually desist. I say chain and not nodes, because I can see a node splitting their mining across two heads if they remain neutral and hedge their bets.
11-03-2023
, 03:09 AM
Your definitions are inconsistent. We can lay down commonly use terminology, it will take a bit. bitcoin was proposed with a whitepaper to explain it. This is one of the sections:
https://bitcoin.org/bitcoin.pdf
https://bitcoin.org/bitcoin.pdf
Quote:
5. Network
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.
11-03-2023
, 09:16 AM
Quote:
Your definitions are inconsistent. We can lay down commonly use terminology, it will take a bit. bitcoin was proposed with a whitepaper to explain it. This is one of the sections:
https://bitcoin.org/bitcoin.pdf
https://bitcoin.org/bitcoin.pdf
11-03-2023
, 09:20 AM
"Nodes always work on the longest chain"
That probably solves the question on how to discern two blocks with similar timestamps. If the network is split temporarily into two, the half that solves the diff hash first will be considered and the other one would be discarded. Imagine how unlucky that would be! To solve the hash at the same time, and then lose the coinflip over whether the next hash is solved on your block or your competitor.
That probably solves the question on how to discern two blocks with similar timestamps. If the network is split temporarily into two, the half that solves the diff hash first will be considered and the other one would be discarded. Imagine how unlucky that would be! To solve the hash at the same time, and then lose the coinflip over whether the next hash is solved on your block or your competitor.
11-03-2023
, 09:29 AM
Quote:
1- Every 10 minutes, every mining-node starts computing hashes, looking for a nonce that hashes to anything below the difficulty.
2- Once someone finds such a node, they announce it to the network.
3- The transaction-receiving-nodes , check the new block, to verify if their address is credited with any incoming BTC.
4- Either the miner node, or a transaction-mining-node that has been deputized by the miner node, checks a list of pending transactions, and if the reward is worth it, checks whether they prove that the transactions were initiated by the owner (and possibly distributes a new secret to the sender-node), and advertises the results. I have some ideas on how this could be done, but I'm not sure.
Possibly
- Owner of new block plays crypto challenge-response with nodes to verify ****. For example:
-- Talk with sending nodes to verify that they authorized the sending transactions in the pending queue.
-- Publish the authorized tx in the new block.
-- Respond to verification requests from existing nodes?
5- Difficulty is adjusted, possibly by a prepublished algorithm using the diff between the timestamp of the new block and the last one.
1- Every 10 minutes, every mining-node starts computing hashes, looking for a nonce that hashes to anything below the difficulty.
2- Once someone finds such a node, they announce it to the network.
3- The transaction-receiving-nodes , check the new block, to verify if their address is credited with any incoming BTC.
4- Either the miner node, or a transaction-mining-node that has been deputized by the miner node, checks a list of pending transactions, and if the reward is worth it, checks whether they prove that the transactions were initiated by the owner (and possibly distributes a new secret to the sender-node), and advertises the results. I have some ideas on how this could be done, but I'm not sure.
Possibly
- Owner of new block plays crypto challenge-response with nodes to verify ****. For example:
-- Talk with sending nodes to verify that they authorized the sending transactions in the pending queue.
-- Publish the authorized tx in the new block.
-- Respond to verification requests from existing nodes?
5- Difficulty is adjusted, possibly by a prepublished algorithm using the diff between the timestamp of the new block and the last one.
Quote:
5. Network
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.
The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working on
extending it. If two nodes broadcast different versions of the next block simultaneously, some
nodes may receive one or the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other
branch will then switch to the longer one.
Seems like I was pretty spot on to me.
Here's a rough equivalency table if you are still confused.
Whitepaper's 1 - My 4
W2 - My 4
W3 - My 5, my 1
W4 - My 2
W5 - My 3
W6 -
Quote:
And who decides what 'valid' means in regard to confirming the work? Diff hash solvers verify what the valid transactions are and what the previous block head was. The next diff hash solver announces that the previous block was valid by choosing it to publish their new block there.
11-06-2023
, 10:27 PM
We need to be simpler than that. And we have an agenda so we can decide to use certain definitions that others may or may not approve of.
Here the distinction I want to point out between miners and nodes is one that isn't in the whitepaper.
In the beginning it made sense that everyone using bitcoin would be both a miner and a node. But the economics and game theory are such that the natural evolution is that some nodes don't mine, and some miners don't run a node.
This is a good check to see if someone understands bitcoin beyond just googling it, because this isn't really explained in the whitepaper (is it?).
Here the distinction I want to point out between miners and nodes is one that isn't in the whitepaper.
In the beginning it made sense that everyone using bitcoin would be both a miner and a node. But the economics and game theory are such that the natural evolution is that some nodes don't mine, and some miners don't run a node.
This is a good check to see if someone understands bitcoin beyond just googling it, because this isn't really explained in the whitepaper (is it?).
11-06-2023
, 10:33 PM
Our general or vague definition of a node is a software entity that has a interest in validating transactions, or blocks of transactions, based on the code and rules that the software entity runs.
A miner trades computational energy for a probabilistic based chance to receive bitcoin by brute forcing the answer to a computationally hard problem which is cryptographically tied to the solution provided by the last winner of the bitcoin auction .
A miner trades computational energy for a probabilistic based chance to receive bitcoin by brute forcing the answer to a computationally hard problem which is cryptographically tied to the solution provided by the last winner of the bitcoin auction .
Last edited by jbouton; 11-06-2023 at 10:46 PM.
11-10-2023
, 02:41 AM
This was written in 1999 by Nick Szabo:
https://www.fon.hum.uva.nl/rob/Cours...intrapoly.html
Here he cites two of satoshi's stated sources for creating bitcoin:
Szabo's is a polymath that has a brilliant blog of what he refers to as 'concise tutorials'. Here he formalizes a special observation:
He proposes that "..there is no algorithm running faster than q(n,k)p(n) which can invert f for more than a negligibly small number of values"
What he is starting to do I think is define a function that standardizes the computational power of a hardware's ability to brute force.
The conclusion tho is very important imo:
What his conclusion expresses is the concept of an "asic" bitcoin miner:
https://www.fon.hum.uva.nl/rob/Cours...intrapoly.html
Quote:
Originally Posted by Szabo
Intrapolynomial Cryptography
Copyright (c) 1999 by Nick Szabo
Copyright (c) 1999 by Nick Szabo
Spoiler:
Quote:
Originally Posted by Szabo
Researchers have proposed a variety of "client puzzle" or "busy-work" proposals like hashcash, MicroMint, bit gold, and compute-cost postage to create independent currencies or make spamming costly. The mathematical implication of these proposals is that there is such a thing as intrapolynomial cryptography.
Szabo's is a polymath that has a brilliant blog of what he refers to as 'concise tutorials'. Here he formalizes a special observation:
Spoiler:
Quote:
Originally Posted by Szabo
I propose the following formalization:
f: {0,1}* --> {0,1}* is called a strong k-benchmark function
for machine model M and k>=1 if the following hold:
1. f is computable in O(p(n)) time on M, where p is a polynomial.
2. f does not shrink the input more than q(n,k), where q(n,k)
is a polynomial of degree k.
3. For every randomized algorithm A running on M in time
less than q(n,k)p(n), there exists an N such that for n > N
Pr[A(f(x)) = f^-1(f(x))] < 1/q(n,k)p(n)
In other words, there is no algorithm running faster than q(n,k)p(n) which can invert f for more than a negligibly small number of values
f: {0,1}* --> {0,1}* is called a strong k-benchmark function
for machine model M and k>=1 if the following hold:
1. f is computable in O(p(n)) time on M, where p is a polynomial.
2. f does not shrink the input more than q(n,k), where q(n,k)
is a polynomial of degree k.
3. For every randomized algorithm A running on M in time
less than q(n,k)p(n), there exists an N such that for n > N
Pr[A(f(x)) = f^-1(f(x))] < 1/q(n,k)p(n)
In other words, there is no algorithm running faster than q(n,k)p(n) which can invert f for more than a negligibly small number of values
He proposes that "..there is no algorithm running faster than q(n,k)p(n) which can invert f for more than a negligibly small number of values"
What he is starting to do I think is define a function that standardizes the computational power of a hardware's ability to brute force.
The conclusion tho is very important imo:
Spoiler:
Quote:
Originally Posted by Szabo
There are at least two practical implications of the above analysis. One is that there is very little room for error in the analysis and implementation of compute-cost postage, hashcash, bit gold, MicroMint, and other such intrapolynomial cryptography schemes. Another is that, unless the opponent has a very low budget and is thus limited to standard personal computers, it does not make sense to analyze the security or cost of these schemes without reference to machine architecture. For example, spammers may be able to defeat compute-cost postage by using custom chips optimized for computing the particular puzzle function.
What his conclusion expresses is the concept of an "asic" bitcoin miner:
Quote:
Originally Posted by Szabo
...unless the opponent has a very low budget and is thus limited to standard personal computers, it does not make sense to analyze the security or cost of these schemes without reference to machine architecture. For example, spammers may be able to defeat compute-cost postage by using custom chips optimized for computing the particular puzzle function.
11-13-2023
, 12:10 PM
Szabo's formalization is important because it shows that there IS in fact some formalizable computational limit to the total computing power of a network. Theoretically in principle it could be throttled by a math rule. Most people credit Satoshi with this discovery. It was a less of a discovery and more of a formalization even as far back as 1999.
11-13-2023
, 12:23 PM
People often say that Satoshi solved the byzantine generals or consensus problems. Probabilistic Byzantine Consensus is what Nick Szabo defines 'nakamoto consensus' as:
It's reasonable to consider Szabo is referencing this paper from 1997
https://people.csail.mit.edu/silvio/...0Agreement.pdf
The problem.
"...up to 1/3 of the generals including the commander in chief-may be traitors.... traitors may represent their orders differently to different generals, they may not send any information to someone,and they may claim to have received nothing from someone else....they need is a way to exchange messages so as to always reach a common decision while respecting the chief's order, should he happen to be honest. They need Byzantine agreement.
Byzantine agreement.
"...we must first sketch its classic underlying communication model...Modernizing the motivating scenario a bit, generals are processors of a computer network....Every two processors in the network are joined by a separate communication line, but no way exists to broadcast messages. (Thus, though a processor can directly send a given message to all other processors, each recipient has no way to know whether everyone else has received the same message.) "
Quote:
Originally Posted by Szabo
A block-chain computer, in sharp contrast to a web server, is shared across many such traditional computers controlled by dozens to thousands of people. By its very design each computer checks each other's work, and thus a block chain computer reliably and securely executes our instructions up to the security limits of block chain technology, which is known formally as anonymous and probabilistic Byzantine consensus (sometimes also called Nakamoto consensus).
https://people.csail.mit.edu/silvio/...0Agreement.pdf
The problem.
"...up to 1/3 of the generals including the commander in chief-may be traitors.... traitors may represent their orders differently to different generals, they may not send any information to someone,and they may claim to have received nothing from someone else....they need is a way to exchange messages so as to always reach a common decision while respecting the chief's order, should he happen to be honest. They need Byzantine agreement.
Spoiler:
A motivating scenario. WE are in Byzantium, the night before a great battle. The Byzantine army, led by a commander in chief, consists of n legions, each one separately encamped with its own general. The empire is declining: up to 1/3 of the generals including the commander in chief-may be traitors. No radios (sic!) are available: all communication is via messengers on horseback. To make things worse, the loyal generals do not know who the traitors are. During the night each general receives a messenger with the order of the commander for the next day: either "attack" or "retreat." If all the good generals attack, they will be victorious; if they all retreat, they will be safe: but if some of them attack and some retreat they will be defeated. Since a treasonous commander in chief may give different orders to different generals, it is not a good idea for the loyal ones to directly execute his orders. Asking the opinion of other generals may be quite misleading too: traitors may represent their orders differently to different generals, they may not send any information to someone,and they may claim to have received nothing from someone else. On the other hand, should the honest generals always-say-attack (independently of the received orders and of any discussion), they would not follow any meaningful strategy? That they need is a way to exchange messages so as to always reach a common decision while respecting the chief's order, should he happen to be honest. They need Byzantine agreement.
Byzantine agreement.
"...we must first sketch its classic underlying communication model...Modernizing the motivating scenario a bit, generals are processors of a computer network....Every two processors in the network are joined by a separate communication line, but no way exists to broadcast messages. (Thus, though a processor can directly send a given message to all other processors, each recipient has no way to know whether everyone else has received the same message.) "
Spoiler:
As insightfully defined by Pease, Shostak, and Lamport [32], Byzantine agreement essentially consists of providing "the best alternative" to broadcasting when all communication is person-to-person (as in an ordinary telephone network) and some of the people involved are untrustworthy. In order to briefly describe what this alternative is, we must first sketch its classic underlying communication model, the most convenient and simplest one in which the need for Byzantine agreement arises. Modernizing the motivating scenario a bit, generals are processors of a computer network. Every two processors in the network are joined by a separate communication line, but no way exists to broadcast messages. (Thus, though a processor can directly send a given message to all other processors, each recipient has no way to know whether everyone else has received the same message.)
The network otherwise has some positive features. Each processor in it has a distinct identity and knows the identities of the processors on the other end of its lines.
The network is synchronous, that is, messages are reliably delivered in a sufficiently timely fashion: there is a common clock, messages are sent at each clock tick (say, on the hour) and are guaranteed to be delivered by the next tick (though not necessarily simultaneously). Each communication line is private, that is, no one can alter, inject! or read messages traveling along it. Indeed, the only way for an adversary to disturb the communication of two good processors is by corrupting one of them. IlTe will refer to such a network as a standard network since it is the one generally adopted for discussing the problem of Byzantine agreement. '
The network otherwise has some positive features. Each processor in it has a distinct identity and knows the identities of the processors on the other end of its lines.
The network is synchronous, that is, messages are reliably delivered in a sufficiently timely fashion: there is a common clock, messages are sent at each clock tick (say, on the hour) and are guaranteed to be delivered by the next tick (though not necessarily simultaneously). Each communication line is private, that is, no one can alter, inject! or read messages traveling along it. Indeed, the only way for an adversary to disturb the communication of two good processors is by corrupting one of them. IlTe will refer to such a network as a standard network since it is the one generally adopted for discussing the problem of Byzantine agreement. '
Quote:
Now assume that each of the processors of a standard network has an initial value. Then, speaking informally, a Byzantine agreement protocol should guarantee that for any set of initial values, the following two properties hold: 1. Consensus: All honest (i.e., following the protocol) processors adopt a come mon value.
1. Consensus: All honest (i.e., following the protocol) processors adopt a common value.
2. Validity: If all honest processors start with the same value, then they adopt that value.
1. Consensus: All honest (i.e., following the protocol) processors adopt a common value.
2. Validity: If all honest processors start with the same value, then they adopt that value.
11-13-2023
, 12:33 PM
That paper formalizes the problem of nakamoto consensus. But it also provides the solution:
The basic idea is when looking for consensus on valid agreements, the introduction of a probabilistic competent into the validity rules, sets a nice limitation to any 'dishonest' or 'counterfeiting' nodes trying to corrupt the consensus.
Note the authors foresee their solution as the birth of an important technology:
Satoshi isn't the one that solved this problem. He implemented the solution.
Quote:
Our solution. \Ve present a probabilistic-polynomial-time protocol that, reaches Byzantine agreement in an expected constant number of rounds (thus minimizing the round complexity) while tolerating the maximum possible number of faulty players and letting them exhibit a most malicious behavior.
Note the authors foresee their solution as the birth of an important technology:
Quote:
However, our results should have an indirect practical impact. Solving a long open problem always marks a technical advance in it given field, and it is reasonable to expect that in our case as well this increased level of understanding will eventually translate into more practical protocols than ours.
11-14-2023
, 05:19 PM
Was this thread started with a question in mind? I am not faulting anyone in the thread, but I found the whole thing -- unappealing to read. Is the question what is the difference between a miner and a node in the BTC network? If so, this seems more like an engineering question than a economic one.
11-14-2023
, 07:08 PM
Quote:
Was this thread started with a question in mind? I am not faulting anyone in the thread, but I found the whole thing -- unappealing to read. Is the question what is the difference between a miner and a node in the BTC network? If so, this seems more like an engineering question than a economic one.
If you were Nash/Satoshi how, ideally, how would you constitute adjusting the cost to mine each bitcoin invariantly when you can't know or predict the total computing power that will be mining it each period?
Is that a separate question from economics?
11-14-2023
, 07:58 PM
Quote:
Nash defined Ideal Money as being pegged to something cost invariant to produce.
If you were Nash/Satoshi how, ideally, how would you constitute adjusting the cost to mine each bitcoin invariantly when you can't know or predict the total computing power that will be mining it each period?
Is that a separate question from economics?
If you were Nash/Satoshi how, ideally, how would you constitute adjusting the cost to mine each bitcoin invariantly when you can't know or predict the total computing power that will be mining it each period?
Is that a separate question from economics?
In the current system, dollars are cost invariant to produce…
11-14-2023
, 08:06 PM
Why does everyone want to point out he is dumb? Its astounding ![Smile](https://d30akgybcov179.cloudfront.net/icons/smile-emoji.svg)
The goal was to find an apolitical basis OTHER than of the whims of a government. So you need a throttle. Cost invariance is a nice throttle. If its not cost invariant then the significance bestowed on it will have geo-political ramifications and supply shocks etc....
If we are to come up with a rule for ideality, giving control to a single government is the opposite of the intention...given we want something apolitical, we are looking for a commodity that can handle the burden of being 'special' (that can handle a 'gold rush').
The goal was to find an apolitical basis OTHER than of the whims of a government. So you need a throttle. Cost invariance is a nice throttle. If its not cost invariant then the significance bestowed on it will have geo-political ramifications and supply shocks etc....
Quote:
Originally Posted by Nash
Here Argentina and El Salvador can be mentioned. They are adopting (at least temporarily) expedients that put the value of their domestic money on a fixed relation to the U. S. dollar. And of course Panama has had such a situation for a long time previously.
This is not "ideal money" because the U. S. dollar is not an ideal standard for money value.
This is not "ideal money" because the U. S. dollar is not an ideal standard for money value.
Spoiler:
Quote:
Originally Posted by Ideal Money
Here Argentina and El Salvador can be mentioned. They are adopting (at least temporarily) expedients that put the value of their domestic money on a fixed relation to the U. S. dollar. And of course Panama has had such a situation for a long time previously.
This is not "ideal money" because the U. S. dollar is not an ideal standard for money value. But the countries adopting such expedients thus offer their citizens, at least for as long as they manage to or choose to continue it, a deliverance from a typical past tradition of national currencies of even less stable value than that of the (historically observed) U. S. dollar.
But if, for example, all of the countries of the world would base the value for their national currencies on the value of the British currency then this situation would appear singular and unstable, while it was not so singular for a lot of countries to base their currency value on gold.
This is not "ideal money" because the U. S. dollar is not an ideal standard for money value. But the countries adopting such expedients thus offer their citizens, at least for as long as they manage to or choose to continue it, a deliverance from a typical past tradition of national currencies of even less stable value than that of the (historically observed) U. S. dollar.
But if, for example, all of the countries of the world would base the value for their national currencies on the value of the British currency then this situation would appear singular and unstable, while it was not so singular for a lot of countries to base their currency value on gold.
Quote:
Originally Posted by Nash
But if, for example, all of the countries of the world would base the value for their national currencies on the value of the British currency then this situation would appear singular and unstable, while it was not so singular for a lot of countries to base their currency value on gold.
11-15-2023
, 12:04 AM
that is not what I said
It’s not a bike. You are overthinking it.
Who said anything about government?
Quote:
Quote:
11-15-2023
, 12:14 AM
Quote:
In the current system, dollars are cost invariant to produce…
Spoiler:
![](https://forumserver.twoplustwo.com/cache.php?img=https%3A%2F%2Fs3.amazonaws.com%2Ftwoplustwo-actually-definitely-helping-stud%2Fuserimages%2FBveVIKl.png)
The cost invariance is in regard to the idea of a commodity money, which could also be inherited if a money could be pegged to the price of a cost invariant resource or basket of resources in a trustworthy manner etc.
11-15-2023
, 12:18 AM
If satoshi went to nash to say what would be ideal here? And Nash said, make each bitcoin cost invariant to produce....
How does Satoshi account for all of the rush of computer architecture being created to mine bitcoin at an unpredictable and ever cheaper cost?
Knowing its got to be constituted BEFORE hand, if bitcoin is to have its covenants secured.
How does Satoshi account for all of the rush of computer architecture being created to mine bitcoin at an unpredictable and ever cheaper cost?
Knowing its got to be constituted BEFORE hand, if bitcoin is to have its covenants secured.
Spoiler:
![](https://forumserver.twoplustwo.com/cache.php?img=https%3A%2F%2Fs3.amazonaws.com%2Ftwoplustwo-actually-definitely-helping-stud%2Fuserimages%2FKD2kl5z.png)
11-15-2023
, 12:32 AM
If anyone that feels they know bitcoin well enough thinks they know the proper technical answer....I'm going to ask of it immediately..."does that make bitcoin cost invariant to produce?"
11-17-2023
, 09:49 PM
https://en.bitcoin.it/wiki/Consensus
Quote:
Originally Posted by wikiBitcoinConsensus
"Consensus" is an ambiguous and problematic word which can mean several different things, both in Bitcoin and elsewhere. It is often used to hand-wave decision issues as, "well, everyone will basically agree."
In Bitcoin, the word "consensus" is unfortunately used in several very different ways. Really, all of these usages should be replaced by distinct, different words, and the word consensus should never be used.
In Bitcoin, the word "consensus" is unfortunately used in several very different ways. Really, all of these usages should be replaced by distinct, different words, and the word consensus should never be used.
Quote:
Originally Posted by wikiBitcoinConsensus
Consensus rules
The consensus rules are the specific set of rules that all Bitcoin full nodes will unfailingly enforce when considering the validity of a block and its transactions.
The consensus rules are the specific set of rules that all Bitcoin full nodes will unfailingly enforce when considering the validity of a block and its transactions.
Spoiler:
Quote:
Originally Posted by wikiBitcoinConsensus
The consensus rules are the specific set of rules that all Bitcoin full nodes will unfailingly enforce when considering the validity of a block and its transactions. For example, the Bitcoin consensus rules require that blocks only create a certain number of bitcoins. If a block creates more bitcoins than is allowed, all full nodes will reject this block, even if every other node and miner in the world accepts it. Adding new consensus rules can generally be done as a softfork, while removing any consensus rule requires a hardfork. Rules regarding the behavior of the mere network protocol are not consensus rules, even if a change to the network protocol behavior breaks backward-compatibility. The consensus rules are only concerned with the validity of blocks and transactions.
Quote:
Originally Posted by wikiBitcoinConsensus
Rules regarding the behavior of the mere network protocol are not consensus rules, even if a change to the network protocol behavior breaks backward-compatibility. The consensus rules are only concerned with the validity of blocks and transactions.
Spoiler:
Quote:
Originally Posted by wikiBitcoinConsensus
These rules are called consensus rules because Bitcoin requires that all participants in the Bitcoin economy have consensus (with the meaning of the next definition) as to the consensus rules. If the economy disagrees about the consensus rules, then the currency and economy splits into two or more totally-independent pieces.
Unlike the other two definitions, this is a very concrete concept.
For clarity, these rules should be called hard rules or the rules of Bitcoin instead of consensus rules.
Unlike the other two definitions, this is a very concrete concept.
For clarity, these rules should be called hard rules or the rules of Bitcoin instead of consensus rules.
Quote:
Originally Posted by wikiBitcoinConsensus
If the economy disagrees about the consensus rules, then the currency and economy splits into two or more totally-independent pieces.
Unlike the other two definitions, this is a very concrete concept.
Unlike the other two definitions, this is a very concrete concept.
11-17-2023
, 10:04 PM
Quote:
Originally Posted by wikiBitcoinConsensus
The consensus rules are the specific set of rules that all Bitcoin full nodes will unfailingly enforce when considering the validity of a block and its transactions.
https://forumserver.twoplustwo.com/s...9&postcount=11
Quote:
Originally Posted by Byzantine agreement
Now assume that each of the processors of a standard network has an initial value. Then, speaking informally, a Byzantine agreement protocol should guarantee that for any set of initial values, the following two properties hold: 1. Consensus: All honest (i.e., following the protocol) processors adopt a come mon value.
1. Consensus: All honest (i.e., following the protocol) processors adopt a common value.
2. Validity: If all honest processors start with the same value, then they adopt that value.
1. Consensus: All honest (i.e., following the protocol) processors adopt a common value.
2. Validity: If all honest processors start with the same value, then they adopt that value.
But what is the difference between a miner and a node? It was Szabo that predicted, thru formalization, the mining race:
https://forumserver.twoplustwo.com/s...44&postcount=9
Quote:
Originally Posted by Szabo
...unless the opponent has a very low budget and is thus limited to standard personal computers, it does not make sense to analyze the security or cost of these schemes without reference to machine architecture. For example, spammers may be able to defeat compute-cost postage by using custom chips optimized for computing the particular puzzle function.
11-27-2023
, 09:09 PM
https://bitcointalk.org/index.php?to...sg1611#msg1611
Early on Satoshi explained of bitcoin:
But it was almost immediately that people saw in its current form that bitcoin didn't scale to serve the world with a globally used money. In trying to address the issue, and force the early group to confront it, Jeff Garzick proposed a patch that increased the blocksize. He suggested the community move to it before the entropy grew....
Theymos pointed out that the patch forks you from the propriety of the network...Satoshi immediately affirmed:
But Garziks stunt was an expression of the game theory he was playing out in his head...his point was made...
Yet Satoshi made the innocent statement that they can easily deal with the problem later:
And remember the bitcoin wiki says this:
https://en.bitcoin.it/wiki/Block_size_limit_controversy
So the statement of creating a flag day is said here to be a ruse.
Early on Satoshi explained of bitcoin:
Quote:
Originally Posted by Satoshi
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime...I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.
Spoiler:
Quote:
Originally Posted by jgarzik
[PATCH] increase block size limit
October 03, 2010, 08:13:42 PM
#1
We should be able to at least match Paypal's average transaction rate...
October 03, 2010, 08:13:42 PM
#1
We should be able to at least match Paypal's average transaction rate...
Theymos pointed out that the patch forks you from the propriety of the network...Satoshi immediately affirmed:
Spoiler:
Quote:
+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.
We can phase in a change later if we get closer to needing it.
Originally Posted by Satoshi
Quote:
Originally Posted by Theymos
Applying this patch will make you incompatible with other Bitcoin clients.
We can phase in a change later if we get closer to needing it.
But Garziks stunt was an expression of the game theory he was playing out in his head...his point was made...
Spoiler:
Quote:
You just described a whole-network upgrade. I'd call that an incompatible change Smiley
The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.
Originally Posted by jgarzik
Quote:
Originally Posted by martin
No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.
The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.
Yet Satoshi made the innocent statement that they can easily deal with the problem later:
Spoiler:
Quote:
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
And remember the bitcoin wiki says this:
https://en.bitcoin.it/wiki/Block_size_limit_controversy
Quote:
Originally Posted by Block size limit controversy
This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.
12-03-2023
, 11:42 PM
Long way to go and a short time to get there.
Join Date: May 2012
Posts: 19,410
Who ya talking to, buddy?
12-06-2023
, 08:52 PM
Its a question people want to ask and want to understand.
Feedback is used for internal purposes. LEARN MORE
Powered by:
Hand2Note
Copyright ©2008-2022, Hand2Note Interactive LTD