OK.. The miner (as a participant in the system) defines, guards, and adheres to the same consensus rules for himself And: all the rest of the participants (both miners, and non-miners) also define, guard, and adhere to. So what this system is supposed to do when there is a disagreement between miners, and non-miners? Or between miners, and miners... or between non-miners and non-miners... Who, how and why is going to "define, guard, and adhere to" the consensus rules then? I'm just trying to imagine the system that the bitcoin core team is building for us. The one in which miners won't matter.  And I am asking these question not only because I don't know the answers. But because I am pretty sure they don't know these answers as well. |
|
|
|
Who:
Every participant in the Bitcoin system is responsible for either defining and guarding the consensus rules for themselves, or for delegating that responsibility for someone else to handle for them.
How:
Participants can write their own software, or they can choose to use software written by someone else. If they choose to use software written by someone else, then they either verify what consensus rules that software implements, or they trust someone else to verify those rules on their behalf.
Why:
If a user runs software with incompatible consensus rules, they could potentially reject blocks and transactions that the overwhelming majority of users agree are valid, or they could potentially accept blocks and transactions that the overwhelming majority of users agree are invalid. Either would result in the user's blockchain splitting off from the blockchain that the overwhelming majority of users are using. As such, they would be vulnerable to various attacks that result in the user receiving worthless transactions.
Note:
If a user can get enough other users to all agree to use their fork of a split chain, the transactions could establish an agreed value that could be more, less, or the same as equivalent transactions on the other side of the fork.
Sure - this all make sense. Doesn't it? Just makes you wonder why stupid Satoshi bothered with introducing the concept of mining into the system. I mean, according to the rules above, the participant in the Bitcoin system might just as well do their job without any mining involved. And all this energy that gest wasted on something that bitcoin has never really needed - that's just outrageous ;P |
|
|
|
|
In case nobody answers and my topic gest buried, I just want to elaborate on the matter.
I am not a big fan of jgarzik, ever since he banned a guy from the IRC channel, just for suggesting that disallowing citizens of Iran accessing bitcoin's github repo isn't right. I've also not been very excited by the changes he's been trying to introduce into the blockchain protocol, along with his shady friends like Andresen or Hearn.
But what bitcoin core team has done by merging the PR into 0.15 - this isn't much better.
This is totally against the very principles of bitcoin.
Some people obviously lost their minds, if they think that "Bitcoin system" is going to allow them to control the consensus rules.
Moreover, I cannot understand why you'd even want to control the consensus rules.
Do you realize how dangerous it would be, being the only people who can change the bitcoin consensus rules?
And everybody knows their names... Why would you even wish to put yourself in such a position?
Either someone has already forced you to do so, or you are just mad - I seriously cannot see a third option.
Either way, it's not going to work - mark my words.
This system has been designed to resist any kind of centralized control.
I am pretty sure that it is going to resist your tries as well. And when it does, you're all going to loose.
And again: mark my words - you're not going to believe me now, you're going to patronize further, because you obviously think that you have a better understanding of the bitcoin ecosystem... but I don't believe you do. And one day I will come here and say "I told you so". Just like I can tell it now to Andresen, Hearn and a few other arogant idiots from the history of Bitcoin.
|
|
|
|
As the comments in this PR have been locked, I'd like to move the discussion here. Apparently I present a "misunderstanding of the Bitcoin system" Well, please help me to understand it, then. I would like the supporters of this change to answer my question: Who, how and why defines (and guards) the consensus rules? Can you try to give me a "technical" answer? (as opposed to a "political" answer) |
|
|
|
0.14 is "faster" at relaying transactions, much faster in fact, but it has higher _delay_ because the delays are intentional and older versions had a bug that bypassed the original privacy protections for transactions, and also wasted a lot of bandwidth in the process. I was just thinking, might this lower performance be caused by the memory pool feature, that groups txs so the blocks could be miner for more dosh? Nah. Ancestor feerate handing is very efficient. It does take a little bit of time, but we have since made the rest of the processing much faster to compensate. E.g. since 0.12 we eliminated _disk_ accesses which always happened for accepting an unconfirmed transaction to the mempool, as you can imagine that was a pretty big speedup. Nodes are not supposed to relay transactions as fast as possible, doing so leaks the origin of transactions in the network pretty badly. It also wastes bandwidth from sending single transactions at a time in INV packets and from transactions crossing in flight. Unfortunately performance enhancements back around maybe 0.8 or so broke the original transaction relay delays. In recent versions transactions are queued to be advertised to peers, then sorted by dependency (to eliminate orphans) and fee-rate (so most tx most likely to get mined quickly relay faster), any replaced or evicted or remotely advertised transactions are eliminated, and what remains is sent on a random timer (with a 5 or 10 second expected time, which ends up being 100ms scale for the node in aggregate) and rate limited to a couple times the networks nominal total rate. I expect that as further privacy improvements happen, the average delay will go up somewhat further. These delays are still negligible in general. You can read more at https://github.com/bitcoin/bitcoin/pull/7840 and in the release notes. That explains everything. Thanks. So the tx relay delay is introduced by design and is to be expected from the new software. Also it's likely that the main reason you see more transaction traffic from old nodes is that they don't implement fee-filter so they will relay you a lot of stuff that you just will discard, like low fee spam.
No, I don't think so. Normally I don't even send fee-filter messages. And when I do, I'd not increase the peer's tx counter upon received tx with a fee that is too low. I've just tested it with min-fee set to 50 SPB... pre 0.13 are still ones to send me the most new txs. It basically looks like this:  |
|
|
|
Could you show us the numbers you are getting for relay time and the methodology you used to get those numbers?
I can't give you numbers, but I can tell the methodology. Basically you count how many new txs (that ended up in mempool) you received from each host. To make it more reliable, you count them only in the last X minutes,or just divide total txs by the time connected. It's always pre 0.13 nodes that end up on top - they send you the biggest number of new txs. I'm sure you can do this kind of tests yourself, but if you want I'm happy to provide some more data from my env. It's pretty visible - I'm certain it's the case. You can see it even better dropping (e.g. each few minutes) a peer that has sent you the least txs during the last period. Then, after a couple of hours, you end up with mostly pre 0.13 peers That's why I think the new ones must be slower. Because there is much more of them on the network. |
|
|
|
|
I was just thinking, might this lower performance be caused by the memory pool feature, that groups txs so the blocks could be miner for more dosh?
Honestly, I dont know how this grouping is actually implemented, but however I imagine doing something like this, it seems like some heavy stuff. Especially when your memory pool is tens of thousands txs big. It's a lot of sorting and quite often.
|
|
|
|
|
What I have seen by monitoring the network is that 0.14.x software has been (so far) the fastest to relay blocks.
Which is understandable as it relays blocks before verifying it.
What is not understandable for me, though...
Why pre 0.13.0 software is faster in relaying transactions?
I know 0.12 got secp256k1, but 0.13 and 0.14 also had it...
So why is 0.12.x faster in relaying txs than any version that came later?
It is actually even more weird: it seems that even 0.10.x and 0.11.x are quicker in relying transactions than 0.13+
And these still used openssl for EC operations.
|
|
|
|
Currently there is absolutely no procedure to make a cold storage that is 100% safe
And there never will be. Any security can be attacked, just like any bank can be robbed. What you want to have is a cold storage wallet that is too expensive to attack. And as for the hardware wallets, they are not "cold" per se - you always connect them to a PC that is connected to the internet. |
|
|
|
If I were making graphs like yours, I think I'd logically merge all transactions that have unconfirmed parents into their parents, and show the combined rate. I believe that graph will be monotone.
OK. That would be interesting. But I don't quite understand how to group them. For instance I have "parent" transactions A and B - both spend only confirmed inputs. Then I have: C - spends input from A D - spends input from B E - spends input from both, A and B Do all five (A, b, C, D, E) end up in one group then? |
|
|
|
|
Thank you, I didn't know about that.
Where is it in the code? Who made it?
|
|
|
|
Here you see it even better:  It's a fresh one, mined 5 minutes ago. And it took ~30 minutes to mine it. |
|
|
|
|
This pattern is very common, across different pools.
I think it's something that bitcoin core must be doing.
Unless some mining software that assembles the blocks is so common as well.
|
|
|
|
It's not an issue, but I find in intriguing and would like to understand the reason. When I draw a chart for each block that presents a fee (in SPB), in relation to how far the tx was placed inside the block, it almost always looks somehow like this:  What I mean is that the chart in general goes form the highest SPB to the lowest one. - which is understandable. But what is strange for me is that it isn't smooth. There are spikes - in some places inside the block you have a tx whose fee is "too high" for that place, but that is sort of compensated by a tx placed next to it whose fee is to low to end up there. So what is the reason for placing the txs like this? Is it because of the Child Pays for Parent feature, or is it something else? Sorry, I know I can figure it out by reading the code, but hope that someone can just help me here. I mean, by referring me to the specific code that is responsible for this behaviour. |
|
|
|
ELI5
What does this mean? Good or bad?
Good or bad? It's bad for miners who use 1hash pool, as they are loosing profit by wasting their hash power on mining useless blocks. It's good for all the other miners, as they are gaining profit, as the result of 1hash pool mining useless blocks. For me - it's neither good or bad. Just found it interesting. |
|
|
|
I have one question: What will happen to theese invalid blocks? They rejected by all nodes and became orphans or what?
They are just invalid - don't even qualify to be orphans. So inconsistent with the protocol that it's quite impossible to build on top of them. Pools can mine whatever or however the fuck they please. That's the freedom nature of Bitcoin.
Sure. As far as I am concerned, everybody has freedom to throw his money into a fire. |
|
|
|
How do you analyse the block after the fact? I mean what tools do you use etc.
It's more of a process, rather than a tool. E.g. for #477115 My node informed be that it rejected the block with a message like this: AcceptBlock: Unknown input TxID: 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d Looking into the code of the node, I see that this basically means that the block was trying to spend an input from an "non-existing" transaction (its ID is printed) So I save the block on a disk in a separate file and then use a code like this: package main
import (
"fmt"
"io/ioutil"
"github.com/piotrnar/gocoin/lib/btc"
)
func main() {
d, _ := ioutil.ReadFile("477115-0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b.bin")
println(d)
bl, _ := btc.NewBlock(d)
println(bl)
bl.BuildTxList()
println(len(bl.Txs))
for i, tx := range bl.Txs {
fmt.Println(i, tx.Hash.String())
for ii, inp := range tx.TxIn {
fmt.Println(" ", ii, inp.Input.String())
}
}
}
... it will print all the TxID inside the block, as well as the inputs they are spending: https://pastebin.com/LtMKi8pCBrowsing the results for the problematic TxID (9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d), I see it in two places: 22 7a122ef22468e4af16b010d7acf7aa81e5af3636423c613fd98246c179d79800
0 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d-001
[...]
90 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d
0 796c96815be92f9351cbdd0cb52df426d4af18504a3734a3a4a8f5352555c4f2-000 This means that tx number 22 was trying to spend output from tx number 90. Meaning: invalid block. As for the other block (#474294) Looking for the missing tx (b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0e), you don't find it inside the invalid block. So you go to blockchain.info and look for it: https://blockchain.info/tx/b11a78c6c61af1cb37586f639050d74b95c2b0fd525623b6cb6a4bb4fba46a0eThere you see that it was confirmed in (alternative) block #474294. Which gets you to the conclusion that if (any) block #474294 was trying to spend it, while not including it, it obviously is the reason for it to be invalid. |
|
|
|
I believe 474294 had a similar problem, because I think I was checking it back them when in happened.
474294 is missing the parent entirely. Yes, you're right. Sorry |
|
|
|
Both blocks are invalid because they included a transaction without including its unconfirmed parent.
For what I can see the transaction is there, but is placed later in the block. See the 477115 one... In this block, tx number 22 (while 0 is coinbase) is spending output 1 from txid 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d 9639dd073e67efc879abb1075fafa4fa23d5fa427c129b2b1dd4f5a5520b408d is included in that block, but at index 90 - so too late. I believe 474294 had a similar problem, because I think I was checking it back them when in happened. |
|
|
|
|
Show Posts
