The authors argue that if a "selfish" mining pool of size above a certain threshold keeps newly discovered blocks secret, this pool will be able to build a private block chain that is temporarily longer than the public one, frequently enough to make the selfish strategy more profitable than the honest one (by revealing longer private chains just before the public one catches up), so in theory more and more rational miners will join the selfish pool, which will therefore quickly grow to control a majority of all nodes.
In theory. There are many complex and subtle issues that must be thoroughly analyzed before passing judgment on this paper. For example, what if other miners, instead of joining the selfish pool, decide to create their own competing selfish pools? Also, as nullc points out elsewhere on this thread[1] and the Bitcoin Forum[2], peering between miners is already so extensive that temporarily keeping blocks secret could be much costlier than assumed by the authors of the paper.
The Bitcoin community must go through this paper in detail, but IF the authors' logic and math prove correct, this could be a real vulnerability.
While it does seem like this would give pre-existing selfish pools a competitive advantage (in addition to making the whole Bitcoin network less efficient), if you suppose that the selfish pool allows newcomers to join then it itself gains a sizable vulnerability- namely, that its advantaged position relies upon a secret (its extended block chain) that it must share with any potential collaborators.
An actor concerned with the viability of Bitcoin, in this scenario, would simply join the selfish pool and turn double-agent, broadcasting the selfish block chain. Assembling enough human Bitcoin operators to dominate the present-day Bitcoin network that way, and keeping such a rowdy band of idealists in line, sounds implausible.
I don't think that would work. Bitcoin miners only need a small header (the root of a hash tree, essentially) in order to mine, but you need the full contents of the block in order for it to be broadcast into the honest network.
In short, the new thing here is the assumption that the attacker uses a network positional advantage to eliminate the loss associated with delaying blocks.
I am not fond of their proposed solution, since it creates a size advantage for large miners (of sizes which have already existed) in all cases, even without the network attack.
I'd rather initially focus on strengthening the network against the formation of the positional advantage in the short term. (There is already some belief that there is extensive peering between miners making the attack ineffective, but its impossible to know if its adequate, so there is no harm in in strengthening that some.)
If you're still reading: wouldn't having a gamma value significantly larger than 0 mean that for each miner, it has more malicious peers than honest ones?
For example, let's assume a "levels" topology, where mined blocks propagate in discrete turns from the miner to its peers, then to their peers, etc. If there are more honest peers on the first level, wouldn't the "honest" block (X in the paper) propagate faster than the pool block, P?
BTW, I found the paper absolutely fascinating regardless of this relatively minor issue. As you said, even with gamma=0, an attack is feasible.
Nope, I was wrong and misunderstood the attack. (like most people) They would likely make the attack easier to accomplish, rather than less.
Unfortunately there's very little we can do to defeat this attack, other than have miners use strategies that aren't strictly economically rational in the short term for them. In practice a sufficient amount of miners may be willing to do this, but if they aren't we're going to need better countermeasures than that.
"We propose a simple, backwards-compatible change to the Bitcoin protocol to address this problem and raise the threshold. Speci cally, when a miner learns of competing branches of the same length, it should propagate all of them, and choose which one to mine on uniformly at random."
Former algorithmic trader here. This solution does not appear to be incentive-compatible.
Suppose there are two branches, 0 and 0'. Miner receives 0 first. The probability of mining a block is proportional to the time spent mining. Miner thus (a) starts mining 0 immediately upon notification and (b) has a greater probability of finding a block on 0 than 0'. It is thus in Miner's interest for 0 to become the blockchain versus 0'. Since other miners are following a similar logic, it is in the miner's interest to propagate 0 over 0'.
Randomly selecting which branch to mine is rational only if (i) both branches arrive at the same time and (ii) there is no information about which branch other miners are showing preference towards.
You're being downvoted for some reason, but you are right. This is a variation of the Gambler's fallacy, where the miner thinks that because it has mined on branch 0 for some time, the expected time to mine a block on branch 0 in the future will be shorter than on branch 0'.
By way of directly illustrating this, consider slot machines with identical payouts. Grandma has been inserting coins into slot machine A for twenty minutes, when suddenly slot machine A' is turned on. There's no difference between continuing to pump coins into slot machine A and switching slot machine A', the expected payoff is the same either way.
The argument depends crucially on how the hash space is searched. If you could avoid inputs that yield previously seen hash outputs then it would be the case that time previously spent mining would decrease the expected time until getting a valid hash. That doesn't happen by design.
Analogies to slot machines and flipping coins obscures this fact.
How would one productively store previously seen hash outputs? The problem is multi-fold:
Storing the minimum target nonce seen during mining has a key-space of size 256+96=352bits { midstate + { merkle_root, ntime, nbits } }.
So 1/2^352 chance of ever having a collision. Or 2.725094297605216460742E-107. 107 zeros between the decimal and the first interesting digit.
However you wouldn't have indexed this because ntime (the current time) is always going to be unique, and nbits (the current difficulty) might as well be too.
A single bit change in any part of the key completely changes the result, so there is no pattern you can infer by only storing a prefix.
Such a strategy is doomed.
EDIT: ntime is effectively unique as it is the Unix time and will roll over after many years, but the Bitcoin network requires mined blocks to have an ntime within threshold of the current actual time.
This is mostly true. Sometimes it's worth it to continue playing on the original slot machine if it has some sort of progressive feature like a jackpot that isn't shared with other machines of the same type.
> Suppose there are two branches, 0 and 0'. Miner receives 0 first. The probability of mining a block is proportional to the time spent mining. Miner thus (a) starts mining 0 immediately upon notification and (b) has a greater probability of finding a block on 0 than 0'.
Your mistake is in the last point. The probability of finding a block in the next X time units is completely independent of what you did in the past (unless you managed to break the underlying cryptographic hash somehow ;-)). You can think of mining as repeated coin throws (with an extremely biased coin).
This is spot on, no one would actually follow that protocol.
Tangentially, the best side effect of HFT seems to be that a lot of technical people have become more sophisticated in understanding incentive structures and contracts. I wonder how that affects funding decisions for startups of the ex-HFT crowd.
For people that don't get it. The idea is simple. If you're a pool with 25% hashing power you can sort of make this happen. What you do is that you mine like a regular pool. In fact it's not a dishonest pool but it's called selfish because it acts like a normal pool. Say you find a block, which happens like any other pool. Instead of publishing it, you keep it private. This is the key.
Now with enough tries it will happen that you find two blocks in a row - again happens all the time with pools. But what you do is that you wait until the other pools find theirs. Once they find the block (you already found it remember?), or they've wasted many cycles finding it, you publish yours that you've found already.
By doing this you kind of selectively publish the blocks you find, wasting other pools cycles and sort of giving you a heads start for the next block search. It's all actually about building a pool that selectively publishes blocks so that it can get you a heads start for the next mining cycle. Miners will likely join this selfish pool because they'll have a heads start and not feel as though their hashing power is going to waste since it's constantly being invalidated by the selfish pool (by publishing blocks at specific times).
The paper assumes there's only one selfish pool. I presume that if a selfish pool arises, there will also be a variety of other selfish pools arising at the same time. If all pools are acting this way, then there's really no incentive for miners to go to any specific pool (avoiding centralization). So it will just be like regular mining again.
> If all pools are acting this way, then there's really no incentive for miners to go to any specific pool (avoiding centralization). So it will just be like regular mining again.
Are you sure? It seems like it might be skewed towards the larger pools.
For instance, right now, a pool with 25% of the computation will get 25% of the mining revenue. If everyone is selfish, though, perhaps the 25% pool gets more share of the revenue, at the expense of the other selfish pools?
>If all pools are acting this way, then there's really no incentive for miners to go to any specific pool (avoiding centralization). So it will just be like regular mining again.
The rewards enjoyed by selfish miners are super-linear in the size (power) of the pool. So it makes sense for selfish miners to merge their pools.
I have a question about the terminal state. In your blog post it is phrased as a takeover which is inherent in the proof-of-work protocol in the currency.
It seems to me, though, that as soon as a cabal of defectors successfully captures the mining process, a next generation of defecting cabals would immediately form, using the advance information from the previous winning group, and the process would simply repeat in waves.
That is, what we currently have is a group of miners who all share their information with each other as soon as they find it. That's exactly what a sub-group exploiting the instability you identified would look like once it won.
This is a summary of my understanding of their method after a very quick scan of their docs:
They assume working as a malicious/selfish pool having less than 50% of hash rate, but still a significant portion of the total hash rate. All other miners that are not part of the selfish pool are called honest miners.
When selfish pool finds a block, they don't advertise it but continue mining their forked, private blockchain. They have an advantage of one block over the public blockchain now. Of course they have no chance of building longer blockchain in the long term, as they have less than 50% of hashing power and the public blockchain will always get longer after some number of blocks. But what they count on is this:
Scenario 1: honest miners discover a block and the public blockchain gets the same length as the selfish blockchain. They immediately publish their block as soon as they discover someone else discovered a block. They hope to create a race condition and a public blockchain fork - so that some hones miners will get the “honest” block, but some of honest miners will get their “selfish” block and start mining using it as a base. Having some of the honest miners on their side they have a chance that their fork will get longer and the “honest” fork will be declined by the network.
Scenario 2: selfish pool is lucky and discovers another block, giving their blockchain two blocks advantage over the public blockchain. They continue mining and they publish one block for every block discovered by the honest miners. This creates race condition with some of the honest miners on their side, but they still have some blocks found and not published. They publish all their remaining blocks as soon as their advantage decreases to one block. The network chooses their branch as it's longer and they get all the reward coins from their secretly mined chain.
Now, I know nothing about blocks discovery/notification mechanisms over the network and how fast it works, so an important question to someone knowledgeable is if this is a probable scenario that their block published only after some competing block has been found and published has still a chance to get to some significant number of honest miners first so that they start mining over their block - as this is required for their strategy to work.
If the above is viable, then this strategy of course requires some significant hash rate share, but I remember that even having 10% of total hash rate, the probability that you will mine couple of blocks in a row is quite high - and that's all you need to create situations when you have two-three blocks advantage over the public blockchain.
In scenario 1 the selfish pool will lose the block in most cases. Modern pools have a lot of connection to the network, so as not to waste mining on orphaned block. It will get the honest block before the selfish pool block.
This is interesting since I have found very little information about Bitcoin operating on poorly connected networks (i.e. most nodes are not directly reachable from any given node.) Given the current trend toward internet censorship, I wonder if Bitcoin will have to adapt to such networks as the norm.
The key idea is very simple and is very clearly explained on pages 6-7:
"When the public branch is longer than the private branch, the sel fish mining pool is behind the public branch. Because of the power di fferential between the selfi sh miners and the others, the chances of the sel fish miners mining on their own private branch and overtaking the main branch are small. Consequently, the selfi sh miner pool simply adopts the main branch whenever its private branch falls behind. As others find new blocks and publish them, the pool updates and mines at the current public head."
"When the sel fish miner pool finds a block, it is in an advantageous position with a single block lead on the public branch on which the honest miners operate. Instead of naively publishing this private block and notifying the rest of the miners of the newly discovered block, sel fish miners keep this block private to the pool. There are two outcomes possible at this point: either the honest miners discover a new block on the public branch, nullifying the pool's lead, or else the pool mines a second block and extends its lead on the honest miners."
"In the first scenario where the honest nodes succeed in finding a block on the public branch, nullifying the sel fish pool's lead, the pool immediately publishes its private branch (of length 1). This yields a toss-up where either branch may win. The selfi sh miners unanimously adopt and extend the previously private branch, while the honest miners will choose to mine on either branch, depending on the propagation of the noti fications. If the selfi sh pool manages to mine a subsequent block ahead of the honest miners that did not adopt the pool's recently revealed block, it publishes immediately to enjoy the revenue of both the first and the second blocks of its branch. If the honest miners mine a block after the pool's revealed block, the pool enjoys the revenue of its block, while the others get the revenue from their block. Finally, if the honest miners mine a block after their own block, they enjoy the revenue of their two blocks while the pool gets nothing."
"In the second scenario, where the sel fish pool succeeds in finding a second block, it develops a comfortable lead of two blocks that allow it with some cushion against discoveries by the honest miners. Once the pool reaches this point, it continues to mine at the head of its private branch. It publishes one block from its private branch for every block the others find. Since the sel fish pool is a minority, its lead will eventually reduce to a single block with high probability. At this point, the honest miners are too close, so the pool publishes its private branch. Since the private branch is longer than the public branch by one block, it is adopted by all miners as the main branch, and the pool enjoys the revenue of all its blocks. This brings the system back to a state where there is just a single branch until the pool bifurcates it again."
I don't really see much benefit on this: I might be wrong but I understand the pool cannot spend btc from a discovered block until it's been confirmed 120 blocks later (around 10 hrs).
The attacking pool will need enough hashpower to discover blocks 0 and 121 before the network discovers block 121, even then, they will only get paid 25 btc + transaction fees for their trouble.
Also, 10 hrs is plenty of time for paranoid miners to figure out and mitigate such an attack.
This isn't about 'cheating' in any direct way, it's about a better strategy for winning the block race.
They are playing odds, but they are behaving such that 'on average' they have an advantage over the honest peers. When they get lucky, they can use their temporary advantage to race ahead, until eventually settling back into the normal flow and thus generate the (legitimate) block chain for a short period. Because of this control, they get more bitcoins than average miners.
They aren't generating illicit coins, lying about transactions, double spending, or anything like that. They are happy to wait for the 120 block confirmation and spend the coins whenever.
From what I recall, this isn't a new discovery - in fact there was even suspicion amongst some Bitcoin users that the Deepbit pool was using this strategy, though I don't think there was any real evidence.
I think it would be fairly easy to detect by just looking at repeated chains of consecutive blocks by same pool orphaning blocks from all the other miners.
That's also addressed in the paper - the pool does not need to declare that it is a pool, nor use the same IP address, wallet or similar to publish the block.
I find the very idea of doing anything that would undermine the Bitcoin network to be self defeating and therefore highly unlikely. Miners have a vested interest in high prices, and seeing as doing anything which undermines the network would cause a loss of faith in Bitcoin and cause the price to drop precipitously, I can't imagine the mining community would be particularly interested.
They can already do that with a 51% attack anyway. Maybe I'm being naive, but I agree that I can't see the mining community letting such an attack happen.
It's also realistic to say that if an attacking entity started a selfish pool, there would be a percentage of the population that would join that selfish pool.
It's obviously the wrong move, but just because you're a sociopath doesn't mean you're smart.
I hear people say to me all the time that it's "ok if I'm the only one doing it". If this papers strategy is effective, it is a realistic threat that lowers the bar necessary to destabilize the network. 33% to take over the network, but much less to start the ball rolling.
Isn't the future viability of a system irrelevant when you're trying to game it for money at today's price?
Does a "vested interest in high prices" stop anyone from gaming any economy, or is it a vested interest in current high prices that causes them to?
I would think miners have an interest in their profitability which happens to be exponentially squandered every day as hashing power joins the network, and every two weeks as difficulty is re-calculated.
We had an old CGI host recently compromised for bitcoin mining, a southern China IP had installed a bot: 100% CPU usage for a couple of hours before we noticed. Maybe a few cents here and there for very little effort on their part?
The proposed selfish mining strategy in a nutshell is: when you find a block, keep it secret in the hope of finding a second one that will give you the leverage to start messing around. If someone else finds a block before you find your second, go ahead and publish.
Since by hypothesis you have a minority of the total computing power, usually someone else will find a block before you find your second.
But by the time you become aware of this, at least some other miners are also aware of it, whereas no others are yet aware of your block. With the 'first wins' tiebreaker, usually that means your block gets lost. So most of the time you lose out. So on average, selfish mining loses, at least as long as your computing power is small compared to the network total.
Check out section 6.1. It briefly describes how the selfish pool can use a Sybil attack to selectively forward blocks, greatly increasing the probability of winning the 'first wins' tiebreaker.
I can't see this posing a serious threat to Bitcoin. If I understand this correctly the idea relies on mining a block and keeping it secret so that the selfish miners can start mining on the next coin. But they can't change the properties of the network. They'll have to respect Bitcoin's difficulty calculation, since if they try to change that, the main Bitcoin network will reject their chain. Plus, they'll need tons and tons of hashing power to stay ahead of the network.
Correct me if I'm wrong, but even if you've got future blocks precomputed for weeks in advance, all it takes is someone else finding the current block by chance to completely invalidate your private chain?
The threat is that the unfairness rises with pool size, encouraging the largest pool to become even larger. Once a pool becomes very large (e.g. over 50% of the hash rate) it can DoS the entire Bitcoin system or use the threat of DoS as a form of blackmail to make changes to the protocol.
even if you've got future blocks precomputed for weeks in advance, all it takes is someone else finding the current block by chance to completely invalidate your private chain?
No, because peers use the longest valid chain (more or less) regardless of when it is revealed.
Can anyone read the paper? I don't understand how a minority group of colluding miners could privately mine a longest fork of the blockchain. Wouldn't this take more than 50% hashing power?
On average, yes. But mining is a probabilistic process. Occasionally, a minority group will get lucky and mine two blocks in quick succession. If they keep their blocks secret, then they can cause the rest of the network to waste time mining on obsolete blocks and thereby increase their effective share of the network's hash power.
Could they double-spend some coins by spending them on the public chain, and then get their chain where they didn't spend them accepted as the new public chain?
Not effectively. Whichever chain ultimately wins still defines the outcome of "double-spent" coins, so if they tried to double-spend, one transaction would still be rejected when its chain is rejected by the mining community.
If I understand correctly, the only way to do this would be to get a private chain longer than the typical number of accepted confirmations, which is currently 6 for most merchants. In this method, you spend the coins, wait for 6 confirmations, the merchant ships the product, and then you reveal a longer chain where those coins were never spent. However, getting a chain advantage of that length is extremely unlikely without a massive fraction of the network power.
The attack described is for pools where they lack a majority of the processing power, but still have enough power to occasionally make chains at least a couple blocks longer than the rest of the miners.
Mining a longest fork and maintaining it is probable if you have more than 50%. If you have less than 50%, there is still a chance, but eventually, the main chain will catch up.
For example, even if I'm a pool with 25% of mining power, I could still occasionally find 2 blocks in a row. But I won't maintain that lead because in general, over time, for every 1 block I find, 3 other blocks will be found.
It looks like this paper's technique is to take advantage of those temporary situations where one pool is lucky enough to get ahead.
In Bitcoin's (admittedly short) history we've seen miners voluntarily switching away from more profitable mining pools because those pools were approaching a majority share of the network.
I have a hard time seeing a majority of miners sabotage themselves like this, but preemptive solutions are definitely worth looking at.
The key idea behind this strategy, called Sel sh Mining, is for a pool to keep its discovered blocks private, thereby intentionally forking the chain. The honest nodes continue to mine on the public chain, while the pool mines on its own private branch. If the pool discovers more blocks, it develops a longer lead on the public chain, and continues to keep these new blocks private. When the public branch approaches the pool's private branch in length, the sel sh miners reveal blocks from their private chain to the public.
I don't see how this will work in practice. If you're keep discovered blocks private, how are you taking part in bitcoin as a whole? You're just sitting on private info about transactions that may as well be made-up.
I haven't read the paper yet, but from this snippet you've provided it sounds like the idea is to keep your blockchain private until some point in the future. At that point, every node that views your forked blockchain will accept it as the true blockchain because it is the longest.
The private chain will probabilistically become shorter than the public chain over time, unless more than 50% of mining power is devoted to the private chain.
That's why miners are normally incentivized to release a block as soon as they find it. If they don't, and a different block is found and then a block is found that builds off that one, the "secret" block will probably never be part of the longest blockchain. And the longest blockchain is "the blockchain."
Sorry this comment can't be more helpful, I haven't read the paper yet.
Your thinking is sensible, the additional assumption they're adding is that their attacker can sibyl attack the network and get between the miners so that when the honest miners find a block that triggers the release of their delayed block.
By doing this, assuming they can, they don't suffer from orphaning due to their delays.
I assume the target is the double-spend they could do. They would transmit transactions to the public blockchain, but put different transactions in their private blockchain.
Let's make it simple. Take Y = I order 100k USD from some bank, pay with bitcoin. Y' = I pay 100k USD equivalent in bitcoin to myself. Suppose I discover a block significantly ahead of the public mining pool
Public: X + Y
Mine: X + Y'
Now I reveal the X + Y' chain to part of the network, but not the part where the "target" of the Y transaction is located. And suppose I can get 50% hashrate working on my chain that way. Evolution
Public X + Y + Z1 + Z2 + Z3 (bank confirms transaction after 3 blocks, pays out my 100k USD)
Mine X + Y' + Z1 + Z2 + Z2
At this point I put all my spare chips in. I suddenly "discover" 2 blocks. Result
Public X + Y + Z1 + Z2 + Z3
Mine X + Y' + Z1 + Z2 + Z3 + Z4 + Z5
And I re-unify the network at this point. All miners accept the "mine" blockchain, and I was able to confirm one transaction, get the payout, and undo the payment.
(obviously in reality, you'd use many tiny transactions, not one big one, and Z1 + Z2 + Z3 + Z4 + Z5 would only be able to contain transactions from the traitor network + whatever miners joined it after it was X + Y', and and and and and ... But I don't see a good reason it couldn't work)
Maybe you could make this work if you had an internet partition. (happens all the time, but you'd need a pretty big one)
I believe the described system would work fine without needing double spending.
Even simply acquiring the bids to verify transactions into the chain could make it worthwhile. When the "selfish" chain is published, it takes two blocks of transactions from anyone else, plus it has given the "selfish" miners the entire period from when they last discovered a secret to when they played their hand to mine for the block that will follow.
It may allow them to capture a greater portion of the main chain by denying information to other chain agents unless beaten or trumping.
Actually, that would be a good term for the method. "Trumping" the chain.
There is a lot of discussion of the propagation of publishing blocks and reacting to the publication of a competing block. In this strategy, the 'selfish' pool could take a probabilistic approach, and simply hold on to their private block for "a while" based on the probability of someone else providing the competing block (obviously still publishing instantly if a competing block is found).
This means they still get some advantage, in a time lead over the general network, but they balance out some of the costs and risks of waiting. They will get their lucky block-ahead of the network less often, but perhaps it is a better strategy. Fascinating stuff.
On a somewhat unrelated note, I'd love to have something like Heroku for mining. Basically, you sell me computing units at some USD rate, and I get BTC as the computing units mine. If I am lucky, the payout in USD-equivalent BTC is larger than my payment to you. Way easier than the DIY mining rigs, so charging a nice premium wouldn't be unacceptable.
It seems to me that anyone wanting to make a profit from maintaining such a cloud of hardware would be best served by just doing the mining themselves rather than renting it out to people who could make more in mining than they pay in rent.
In an ideal market (e.g., with perfect knowledge of utilities to be realized by all decisions from all participants) this might be true. In real markets where outcomes are in fact uncertain and different participants both have different perceptions of the expected utilities and risks and, even to the extent those perceptions align, different sensitivities to risk, its quite possibly optimal for one participant based on their perceived utilities and risk sensitivity to provide minining hardware for rent while also optimal for some othe participant to rent that hardware for mining.
(Note that essentially the same consideration applies to making and selling mining hardware vs. making it and keeping it to use to mine.)
Mining contracts happen when two parties have different predictions about future difficulty and thus profitability; the buyer believes that mining will be more profitable than the seller believes. I suspect most of the buyers have lost money because people who run mining data centers for a living probably understand it better than anyone else.
There's also risk distribution: if you rent your hardware for 80% of the value, you're sure to get 80% of the value, while the risk is portioned up among many smaller investors, all of whom could reasonably stand a loss; if you don't, you're stuck holding the bag entirely if something goes wrong (eg, the has rate speeds up more than predicted).
There is a value in risk distribution that can cause mining hardware to be a good idea to rent out pieces of even if you're likely to make money on it, as long as the risk of losing money isn't trivially small.
Originally I wrote it with a p. Since there's no way to verify the ids of anyone involved in bitcoin, there's no safeguard against anyone who has the resources to dominate it using brute force (let alone subverting the algorithms).
Even it this was true, one of bitcoin's design goals is exactly not to rely on anybody's honesty or virtues. If you want to do that, you might as well use a trusted third party, making the whole design much, much simpler.
In theory. There are many complex and subtle issues that must be thoroughly analyzed before passing judgment on this paper. For example, what if other miners, instead of joining the selfish pool, decide to create their own competing selfish pools? Also, as nullc points out elsewhere on this thread[1] and the Bitcoin Forum[2], peering between miners is already so extensive that temporarily keeping blocks secret could be much costlier than assumed by the authors of the paper.
The Bitcoin community must go through this paper in detail, but IF the authors' logic and math prove correct, this could be a real vulnerability.
--
[1] https://news.ycombinator.com/item?id=6669735
[2] https://bitcointalk.org/index.php?topic=324413.msg3476697#ms...
--
Edits: moved paragraphs around and added sentence about and footnotes pointing to nullc's thoughts.