I looked into this a bit last night and the distinction between miners and full nodes in terms of how the software perceives it isn't all that stark. For example, the bitcoin core implementation used to have a single option to enable mining, in addition to core's primary role of running as a full mode. That flag has since been removed although a form of it is available for verification and testing purposes. In terms of the software, the mining functionality is just part of the logic and corresponds to whether the primitives associated with mining are supported on the node, such as block creation.

(thats great stuff btw)I think you are looking at the history of versions too right? How do we measure backwards compatibility in bitcoin?

Some of this uncertainty is the nature of open source and unavoidable. With BTC you get some additional clarity by users voting with what variant they choose to install and run. That leads to more activity on support forums, bug tracking, etc. Over time that sorts out the winner.

Naturally with a fork of the protocol itself this becomes even more important because the stakes of which protocol version wins out are very high.

I'm not familiar with how BTC handles backward compatibility. For some distributed projects backward compatibility is very important, esp when you can't be assured that every node is able to upgrade quickly and often and run the most recent version of the protocol. For other projects they choose to force an upgrade by intentionally breaking compatibility. Both are valid strategies depending on the project.

That bluegrassplayer runs a node or an implementation doesn't solve the question of which is the correct implementation. But BGP runs a software in which nodes are separate from miners.

If someone was to come here and constantly correct people and assert that miners are nodes and nodes are miners...

they would naturally be moderated out of the dialogue.

In bitcoinSV, they believe in the canonical version of bitcoin and in that narrative miners are nodes and nodes are miners. Their argument extends from there and it is perfectly valid GIVEN the premise.

But neither PZ nor BGP accept "canonical-ness" as the basis for a premise.

Its very fortunate for me.

I'm trying to separate out the general process which is important but implicitly we agree on it...somewhere in the answer to backwards compatibility don't we need something like 'sees the same transactions' or aka 'sees the same blockchain'?

I'm not sure the distinction between miners and nodes is all the important outside the confines of the spec. I would guess or assume most nodes running as miners are also running as full nodes, whereas the opposite obviously isn't true.

In most projects there is a distinction between changes in data and in interface/protocol. Some use a concept of data hiding where the data isn't exposed and directly mutable but instead requires using the interface to change the data. This has advantages of limiting disruption when the internal data representation changes. From what I can see BTC's blockchain is fully exposed so changes are likely not backward compatible unless they choose to have the logic support multiple versions of the blockchain.

You need to be able to conflate them in order to reach the conclusions of the BSV narrative. For the btc implementations it is observable that you can run a node and not be a miner. What changed from the whitepaper days, like BGP said, you can now be a miner in a miner pool and use their node, and hence just be a miner and not run a node.

I don't have to convince either of you that nodes are not necessarily miners and miners are not necessarily nodes. But you are both pre convinced. If someone wants to compare the bsv implementation to the btc implementations the need a metric for comparison.


Not sure if we use the same language here. What does it mean that the blockchain is fully exposed? I've never heard 'exposed', sounds like ports and networking ;p

There is an understanding that changes going forward must be backwards compatible otherwise you have created a hardfork which most bitcoiners are very against. But again what counts as not backwards compatible? Is this what is specific to bitcoin?

BSV has had multiple double digit block reorgs. It is very insecure. The only reason people talk about it is for the purpose of trolling. Don't engage the trolls.

We need to be able to reference it tho so we can understand these things. Security, for example needs context. In BSV, and I'm not a proponent, a reorg is not a security problem. In fact its a feature and able to be compelled by law. What 'protects' btc from this?

Exposed just means it's directly mutable, as opposed to only being changeable through an interface that hides the implementation details of the data. It's not necessarily a bad thing, just a design choice.

The miner vs node thing isn't all that interesting to me. It's just additional functionality in the overall protocol from an engineering POV.

Not backwards compatible means the logic doesn't support a previous version of data or interface protocols, to the point of not longer being fully interoperable.

PZ have you looked at the definitions of soft fork and hard fork in the context of bitcoin? Are these words you would otherwise be familiar with (ie is that standard comp sci term?)

an exponentially greater hashrate

They're comparable to the concepts I've been discussing. A soft fork is backward compatible, meaning its changes to the protocol and/or data will not break previous versions of the software and/or data. This can happen if the changes are small, don't modify the protocol/data, or modify the protocol/data in a way where previous versions will either ignore the changes or treat them as inert. A hard fork is when the new protocol/data is not backward compatible with the old, either because the changes were too significant to keep compatible within reasonable efforts, or because the changes were intentionally made incompatible to force upgrades on the node to reject the old protocol/data.

For example by analogy, a casino changing to a new chip design but still accepting old chips would be a soft fork, whereas a casino changing the design to intentionally nullify the old chips (past some exchange period) would be a hard fork. They may do this for example if there was a large theft of the older chips.

If you were identifiable as a 'bitcoiner' (whatever that means) the term 'consensus rules' would have been in that post.

Hashrate secures the chain from external reorg attack, but what if the hashrate is evil? (did I ask that right?). What if miners are centralized, say in china, and they start deciding what the blockchain was, and is going forward?

There is beauty in that analogue.

Can we make a BSV thread for discussions about Satoshi/Craig.

god speed

Looking to 'coin up' if the miner capitulation ever comes...
dry powder gotta be dry and ready!

Miners have already been selling in bulk.

A more general question would be how do we know that the miners are mining using valid transactions or what is the mechanism that forces them to. Not really different than the question of 'what is the relationship between nodes and miners'. And you get different answers from different types of people.



Since you could do it yourself I'm assuming you more mean to keep it out of this thread, but I think you are implying that someone here is spouting SV nonsense in this thread. That's not happening here.

We are blessed to have an active mod that runs a btc implementation of bitcoin. For some there is no other brand of bitcoin implementation-luckily the active mod here runs a node and therefore has empirical evidence that nodes are not necessarily miners. i wouldn't still be allowed to post if the moderation power of this thread/section didn't have that quality/understanding.

BGP ended the ability in this thread to debate whether or not bitcoin is ponzi. The dialogue wasn't moving forward at that time. In the past multiple times I had pleaded with mods from here up to the owners to change that. It's great.

Beyond that, I want to say that I would nominate/recommend pocketzeros for the same. My endorsement doesn't mean ****. I have no idea if its otherwise appropriate. But I want to state this and explain the reason is because they have a very strong technical knowledge of how open source projects work (and the related subjects to bitcoin) AND most specifically that knowledge doesn't come from their bitcoin experience. We don't agree on the conclusions of what bitcoin is to be and whether or not it is a boon to our society it seems. So for that reason of being unbaised but yet having the technical knowledge. They would be a prime candidate.

I also want to be on record stating I think it would be the most important security benefit this site could have to give PZ modership powers over bitcoin content/dialogue.

+1

By validation and consensus of the nodes seeing transactions and blocks propagated to them. Invalid transactions are rejected by individual nodes and don't get propagated to other nodes. The less propagation the less likely a miner node will see the transaction and attempt to include it in a block. Once the block is created those transactions will be revalidated by nodes. Consensus forms around valid blocks.

Haha, thanks but moderation should be limited to those who have some measure of dispassion about the topic and that obviously isn't me.

That's it. But notice this can't happen in a system in which the nodes are necessarily miners and miners nodes. In BTC IMPLMENTATION and by btc definitions (that are held on bitcoin.org and the associated github listed) nodes are separate from miners and secure the network by holding miners to the consensus/standard. A miner does what it wants; a node only accepts valid proposals.

There is more to it...but in that nutshell its important to note that if nodes were miners and miners were nodes you wouldn't have this 'checked and balanced' relationship. In other words with the BSV language and narrative the nodes don't keep the miners in check. Put another way, Craig Wright is training a following of people that don't believe in the crux of the security of btc.

Definitions matter big time in this regard. And that is why I say that it is very important to understand (and for this group to hold) the proper relationship between nodes an miners.


I mostly mean to just point out the importance of a proper technical understanding, and to this extent you have clearly shown that you have it.