Why is Bitcointalk Silent on Core vs Knots & the OP_RETURN Controversy? 1. There are some topics about it, even in this board: https://bitcointalk.org/index.php?topic=5560420.02. When it comes to OP_RETURN drama, then it is just a shitstorm. Most people don't understand technical details behind it, and they think, that something new was "introduced", while in practice, the only change is related to relay rules, and miners can make unlimited OP_RETURNs today (or even spend coins from future Segwit versions, and make 4 MB contiguous data pushes). So, no matter what Core would do, it wouldn't change the situation that much, because miners can already accept non-standard transactions anyway, and there are services like Slipstream. weird how dead this forum feels on actual bitcoin stuff I guess if someone would make a drama about sighashes, then most people would hear about their existence for the first time, even though they are implemented since 2009. nobody cares that core forced the op_return limit removal You don't have to upgrade. And you don't have to run a node, if you don't want to. Also, even if Core would lift all limits, and accept all non-standard transactions in mainnet, then still: each node operator can decide, what to do with that traffic. And if miners would keep lifting next limits, then expect standardness relay rules to disappear, because matching mined block templates is more important. Also, it is possible to relay even partially-signed transactions with negative fees, but include in block templates only valid things. In relay mode, people could seed torrents, or run HTTPS servers, and nobody would care. Because if your node does more things, than just relaying regular Bitcoin transactions, then nobody cares, because every node operator can introduce its own relay rules, if needed. The only important thing, is to match, what is mined, but on top of that, nodes can process a lot of irrelevant traffic, if they want to (for example by running P2P marketplace or P2P poker game from 0.1.0 version). now it’s just bounties, alts, and random price threads What else would you expect? Developers moved somewhere else years ago. This forum is just yet another social media platform. It is unique, because all posts are indexed by web crawlers, which makes it more resistant to censorship, but after all, most people are here, because of social interactions, and nothing more. If you would seek real, hard knowledge, you would just read more code, and talk with real developers, instead of being here. But then, you wouldn't complain about "silence", while this topic is "overheated", if you understand, why people are talking about OP_RETURN changes at all. There are more important things than that. And OP_RETURN is much better, than other kinds of spam, where consensus rules are enforced, and where data pushes cannot be ignored that easily, when you have to actually validate signatures, or make a more complex proof, to let other nodes know, that given transactions are valid. is it just me or did everyone move the real convo somewhere else? Serious discussions are in other places. But if you would want to reach them, then you wouldn't care about OP_RETURN drama at all, because you would know, that next limits will be lifted, one-by-one, and we are in 2025, and not in 2015. Which means, that standardness limits no longer works like 10 years ago, if miners can make services, which could confirm you any non-standard transaction (no matter which Core or Knots version you would pick). |
|
|
|
because it's "going to be easier for the network" It won't be easier. It can only be harder. If you have OP_RETURN, then a given output is automatically discarded, marked as unspendable, and then, only full archival nodes have to keep it. But when users push data through public keys, through hashes of public keys, or even through private keys, then it is not easier to process, but actually harder, because each and every OP_CHECKSIG call, will trigger a more complex procedure, than just "skip it, and mark is as invalid". Which means, that OP_RETURN is definitely easier to handle, than even "<randomData> OP_CHECKSIG OP_NOT". Because a single OP_NOT is what can be done, to make everything spendable again. What Knots should do instead, is to simply handle a subset of the mainnet traffic. If they want to enforce their rules on everyone, then it would only hurt them, if they fork the chain. There are ways to prune transactions and blocks, without any forks, and after that many years of experience, Luke should simply know, how to do it correctly, if he would seriously want to enforce his rules. So, the hard-fork way is just stupid, and if they try it, then they will only hurt themselves. |
|
|
|
Transactions don't have timestamps. They kinda have. Each and every transaction has "nLockTime" field. Which means, that each and every transaction, can be confirmed after a given block, or a given timestamp. Of course, users could just set nSequence to "0xffffffff", and then "nLockTime" is ignored. Or they could simply use "0x00000000" as their locktime, and get it confirmed at any time, after the Genesis Block. So, transactions don't have "reliable" timestamps, that you can "trust", but well, many wallets put the current block count inside locktime, to prevent an attack, where miners could constantly reorg a given block, and collect fees from transactions, which were made later. And by analyzing "nLockTime" field, maybe you cannot determine with 100% accuracy, when a given transaction was created, but you can at least assume, when a given user wanted to see it confirmed. Also, when some transactions are mined, then the more Proof of Work is put on top of it, the more you can be sure, that once some user decided to commit to some timestamp, it wasn't easy to change it, because it would require re-mining the whole transaction. Of course, users can also use locktime as a nonce, but then, it is not that different from what real miners do, by making their timestamps in a two hour window. So, for many transactions, locktime is not reliable. But if you have a user, which uses the default settings, then "nLockTime" can be pretty much accurate, and commit at least to the block, which was the tip of the chain, when that transaction was made. |
|
|
|
them making a consensus incompatible fork would mitigate risks for everyone Yes. If they want to shoot themselves in their foot, then they shouldn't be stopped. Of course, they are of the view that people *want* their filtered vision, but if that's correct then their fork will be very successful. I wonder, what would happen, if some people would show them, that filters don't work, because filtering the private keys is hard. And storing data there is possible, even BitMEX knows about it: https://blog.bitmex.com/the-unstoppable-jpg-in-private-keys/Another interesting thing is to try to apply ZK-proofs everywhere. Because even if some data "looks" random, then you can find many patterns, and reuse random values for different purposes. Which means, that they can say: "we don't filter that, because it is just a regular payment". And someone else can reply with "we have to filter that too, because this is used as a seed, to generate Super Mario Bros level in the MARIO protocol". Which means, that once filters will be deployed, they will be applied to more and more transactions, and finally, they will be applied everywhere. If you didn't want those, you'd just use paypal or whatever. Or signet. Because "multisig committee" is already implemented there, because signet miners have full control over what is included in the chain, and because it is the simplest implementation, which can combine Bitcoin and CBDC. Also, deploying signet on top of mainnet is actually a soft-fork (and can be easily turned into a no-fork), so if they would be serious, then they would never think about any hard-forks for such use cases, because it is quite obvious, how to do them in soft-fork or no-fork ways. |
|
|
|
do you think enough people would use a Knots fork coin to make it valuable Sure, why not. We have the whole altcoins like Ethereum. We have test networks, which are no longer worthless. Expect everything from crypto people. If one day, someone would deploy "the SPAM protocol", which would allow pushing up to 4 MB transactions through unused Segwit versions, then I expect many spammers will join it. in terms of negotiations with Core? Negotiations? We are in P2P world. Anyone can take the source code of Bitcoin Core, make its own changes, and use its own client. The problem with Luke, is that his code is hard to audit, because you cannot clearly get for example the difference between his version, and the official one. You have to dig it, commit by commit, and compare it manually, because instead of pulling Core changes, and making their own, on top of it, he manually pulls the content, alters it, and pushes it to the repo, without preserving information, who changed what in Core. I'm trying to get an assessment of what Knots users think about this subject. In 99% cases, they simply don't care, and blindly follow Luke's changes. Which is different than in Core, because otherwise, you would have more contributors visible in Knots. But you can see mainly Luke, and nobody else, as a commit author. And the fact, that people, who would like to make any changes, are sent back to Core, and make them there, to see them imported in both clients, only makes the situation worse for Knots, because then, you can see less contributors, than you could, if Luke would import changes correctly. Even altcoins, which are based on Bitcoin Core, are easier to audit, because then, at least you know, how a given altcoin was made, and how to update it, if needed. For example: https://github.com/cpuchain/cpuchain/commits/master/See? You have a CPU-mined altcoin. It is very far from being serious. But at least you can audit it easier than Knots, because you can see, what Core changed, and what altcoin creators added. You can compare these changes. You can check all differences between Core, and this altcoin. And you can see Core contributions, that are not altered, and pushed as "created by altcoin maker X". How the Knots' history looks like: luke-jr: Update manpages, bash completion, and example bitcoin.conf
luke-jr: doc/release-notes: Update for Bitcoin Knots 29.1.knots20250903
luke-jr: Merge rm_historical_relnotes_from_dist
luke-jr: Bump version to knots20250903
luke-jr: Update documented versions/BIPs for Knots
luke-jr: Merge knots_branding-29
luke-jr: uaspoof: If no value provided, just spoof equivalent Core version
luke-jr: NSIS: Drop "(64-bit)" from program name
luke-jr: GUI/Windows: Shorten FileDescription
luke-jr: nsis-header: 2025 Knots branding using OCR-Bitcoin font How it should look like: luke-jr: Merge #...: ...
luke-jr: Changed ... into ...
glozow: Merge #33313: test/refactor: use test deque to avoid quadratic iteration
glozow: Merge #33399: key: use static context for libsecp256k1 calls where applicable
luke-jr: Merge #...: ...
luke-jr: Changed ... into ...
luke-jr: Replaced ... with ...
achow101: Merge #33430: rpc: addpeeraddress: throw on invalid IP
achow101: Merge #33229: multiprocess: Don't require bitcoin -m argument when IPC options are used
glozow: Merge #33230: cli: Handle arguments that can be either JSON or string
luke-jr: Merge #...: ...
fanquake: Merge #33475: bugfix: miner: fix addPackageTxs unsigned integer overflow
ismaelsadeeq: miner: fix addPackageTxs unsigned integer overflow
luke-jr: Merge #...: ...
fanquake: Merge #33446: rpc: fix getblock(header) returns target for tip
fanquake: Merge #33158: macdeploy: avoid use of Bitcoin Core in Linux cross build
achow101: test: Remove convert_to_json_for_cli See the difference? In the first case, you know, that Luke is the author, but you don't know, what he changed, and what he just pulled from Core, and pushed with his name as the commit author. You don't know, where he simply imported things from Core, and where he decided to alter something. It is hard to audit. There are no Pull Requests, where you could trace, what Luke changed, and how, and easily revert the whole feature, while keeping everything else, as it is. So, my criticism is not social, like "what people should use", but strictly technical, like "how to see, who changed what and where". In case of Knots, it is just harder to audit, than it should be. But it is Luke's problem, and his followers, not mine, if they want to fix it, and how. Edit: By the way: when it comes to alternative clients, then this is what got my attention recently: https://hornetnode.org/paper.htmlWe will see, how exactly they will deploy it, but I donated some coins there, because it looks promising. But time will tell, what they will deliver in practice. |
|
|
|
both knobs and knots are both jokes Of course. Because people should use them in a different way. Instead of just downloading binaries, they should fork it, build it from source code, make their own improvements, and submit pull requests. Which means, that instead of just Bitcoin Core, and Bitcoin Knots, there should be one fork per user, where every node operator can reuse the same "base code", and add its own features on top of it (which would be compatible with consensus rules). The main problem with Luke, is that he pushes commits manually, which makes auditing the code hard. But: the fact, that he does it wrong, doesn't mean, that it cannot be done better. This is how Core should be used: https://github.com/achow101/bitcoinhttps://github.com/glozow/bitcoinhttps://github.com/fanquake/bitcoinhttps://github.com/ismaelsadeeq/bitcoinhttps://github.com/ajtowns/bitcoin/Every skilled user should fork it, build it from the source code, and all differences between the Core, and some custom version, should be visible. Then, it would be serious. Of course, some non-programmers can use the official version from Core, but for users with technical skills, that should not be the default. Some article about it: https://blog.lopp.net/knot-a-serious-project/ |
|
|
|
Unlike the Bitcoin where there is no such control or exploitation. There is a test network called "signet", which is very similar to CBDC. And anyone can make its own coin, just by picking the "signet challenge". So, if you have Bitcoin Core, then you can make your own signet, and call it "CBDC", if you want to. |
|
|
|
I can't mine today thinking about tomorrow. Mining is not a sprint, it is a marathon. It is not like Proof of Stake, where you can just sell your coins instantly. If you have real hardware, it takes time to deliver it, it takes time to sell it to someone else, and miners are not planning things in a one-day window, but many of them are thinking about tomorrow. just because they reject a transaction today, it will be worth more tomorrow But it is the case. What happens, when some transaction has too low fee, and is not picked for months? Nodes start dropping it, and then, it can be broadcasted again with the same fees (if some user has a lot of patience), or fees can be bumped. Of course, miners have to confirm some transactions, and if they would mine only empty blocks, then they would harm themselves in the long-term. But skipping transactions with too low fees simply means, that they will be picked by other miners, or they will wait days, weeks, or months, and then, users will decide to eventually bump them. A single miner may have a short-term incentive to include everything here and now, but in a long-term, the hashrate majority have an incentive, to skip low-fee transactions, and wait for users to bump them. It might not be worth more, because they don't even know if they'll mine a block tomorrow. People are paid for shares, not for blocks. A pool would be very unlucky, if people would mine enough shares, to drain all funds out of it, but find absolutely no blocks at the same time. And many payment schemes are well-protected from that scenario. Of course, some pools can be attacked, if miners would start sending shares, but dropping every block, which would meet the mainchain difficulty. But again, first, it is going to hurt them in the long-term, and second, dropping blocks will also drop the difficulty, so that one pool will be harmed, but other pools will benefit from such attack (and if all pools will be attacked in that way, then solo miners will get everything). In general, the hashrate majority can always drop the difficulty to the minimum. But then, the remaining minority will bump it again. |
|
|
|
the sidechains could have much less hashrate/security budget/attack cost than the main chain, and that would make an attack easier in this case You can pick any difficulty you want. It can be much harder, than overwriting the whole mainchain. For example: bc1qss67lljllhph4wnmzn7f8qpc3wh6q48hlpfpznt9sz2lntw963nssn6kzmWhen there is no Merged Mining, then this is how far you can get. You can pick a fixed difficulty, or adjust it with OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. Also, some people argue, that a coin without Merged Mining is better. In that case, they can just use it now in that form. And Merged Mining won't be there, as long as the community won't officially support sidechains, or activate them as a side-effect, by activating OP_CAT or other features, which would bring them indirectly. Or: if someone will come up with a better model, and deploy it, without any soft-fork. However, even if the sidechain is much weaker, than the mainchain, then still: you have to attack Bitcoin, to attack the sidechain. You have to make a real double-spend, get it confirmed on Bitcoin, and spend a lot of Proof of Work, by actively trying to make that double-spend. Which means, that it is similar, as if you would attack Lightning Network, by confirming the old state of the channel. Because that model can be built on top of other things, like LN. It doesn't have to use only Proof of Work: it can use Proof of Work, and any conditions you would pick. the peg-in/out protection has the security of a typical altcoin, because smaller miners often get the puzzle solved It has that security, when the transaction is already broadcasted to the mainchain. However, as long as it is relayed only inside the sidechain, then mainchain miners don't know the keys. They don't know the conditions. They don't even know, that some sidechain is there. They can see just a regular P2WSH, with unknown Script. Which means, that mainchain miners would have to join the sidechain, to actually know, which UTXO is in use (because public key can dynamically commit to the current state of sidechain mempools, so the address can change every time). Also, they would have an incentive, to broadcast their shares, and get sidechain coins. Which also means, that the most dangerous attack would happen, if some attacker would secretly grind the solution, and share it before all sidechain miners will collectively get there. But that can be also solved, if knowing the mining key would require knowing all sidechain keys. Which means, that the shared key can remain secret, as long as enough miners are online, and they are computing things under Homomorphic Encryption. Then, it is known, only when the sidechain block solver broadcasts it, and it gets decrypted by sidechain nodes, and shared on-chain. Which means, that it is then vulnerable only to short exposure attacks. But note that the amount of coins often make it not worth attacking. For example: you have this puzzle: bc1qn9vp8l5rs7huyl237s4q9lhrzcs0mzaajt528ysq3wgnzvlkay5sdfz6am. It requires grinding around 2^64 hashes, as long as half of the generator has the smallest x-coordinate, where the private key is known. And if you count the profitability, then it is more profitable, to mine the regular mainchain block, than to solve this puzzle (at least for now). So, instead of adjusting the difficulty, sidechains can just adjust the amounts. Then, if you want to send a huge transaction, you can use the mainchain. And if you want to buy a coffee, then you can use a sidechain. It is unlikely, that big mining pools will want to destroy their reputation, just to steal a bunch of satoshis. And the best thing is: there is no altcoin. Everything is covered by real BTCs. It is not the same as attacking some altcoin, because now, you are attacking real Bitcoin users. And also, even if Proof of Work fails, and gets attacked, then you can still fallback to LN, or other Script conditions, then it has comparable security assumptions, than alternative solutions, like pure LN without mining. Because you can attach Proof of Work to any Script you want, including doing that in some LN channel. Is my understanding correct? I think so. But we will know for sure, if people will start using such things, and building something on top of that. Now, it is still in testing stage. As always: it is recommended to first try doing all of that in test networks, and going to mainnet, when you will be comfortable with all of that. And even if mainnet puzzles were solved, testnet4 puzzles are still waiting there, so you can still get some of them even on CPUs, if you just understand, how the Segwit transaction is signed. Edit: Try to move these coins, to get started: tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d. And when testnet4 coins will be claimed by someone else, then you can repeat the same experiment in regtest. |
|
|
|
Day 14: {
"chain": "main",
"blocks": 914763,
"headers": 914763,
"bestblockhash": "00000000000000000001c36c54bd23b3a107a616ecf778bf860499dd6b12a600",
"bits": "170211ac",
"target": "0000000000000000000211ac0000000000000000000000000000000000000000",
"difficulty": 136039872848261.3,
"time": 1757915569,
"mediantime": 1757913154,
"verificationprogress": 0.9999992413889547,
"initialblockdownload": false,
"chainwork": "0000000000000000000000000000000000000000e2c97b4d884482c09d74a424",
"size_on_disk": 657476252,
"pruned": true,
"pruneheight": 914399,
"automatic_pruning": true,
"prune_target_size": 576716800,
"warnings": [
]
}Almost there (because of hidden day 13). I reached 1000 merits, so you don't have to send anything. |
|
|
|
That's literally wanting to lose $200! Because you think you should get $2,000 for the same type of transactions. Exactly. Because you have a choice between losing $200, and trying to get $2,000, or taking $200, and moving to the future, where you have exactly the same choice, but between $20 and $200. And later between $2 and $20. And so on, and so forth. Lowering fees is easy: you can convince users, because they pay less, you can convince miners, because they earn more (in the short-term), but all of that will be paid by future miners. Good luck convincing the community, that the fees should rise, if they will be too low in the future, and if miners will produce empty blocks with 1192 satoshis, like it is in testnet3. I wonder how many mining pools broadcast their transactions to the network and let other pools mine. None do! And I think it's good! Then you may be surprised: https://b10c.me/observations/12-template-similarity/Bitcoin needs miners, but miners also need people to use and move Bitcoin. Use and move? Sure. Fill blocks with non-consensus data? Not really. And who benefits from lower fees? Mainly spammers, because they can just attack the network cheaper. Regular users have small transactions, around 1 kB per transaction or so, and then, it means something like 1k sats as minimal fees (which is now lowered to just 100 sats for all of that). It's just nonsense designed to line their pockets and make it difficult for others to enter their mining business. Historically, fees were always lowered, if you count them in satoshis. Do you think, that they will also keep falling, when the block reward will drop to zero? |
|
|
|
If it's greed then they have a weird way to display it. The smaller the blocks are, the bigger the fees will be. If hashrate majority will decide to switch not from 1 sat/vB to 0.1 sat/vB, but to 10 sat/vB instead, then that could became de-facto standard. The same, if they would decide to shrink blocks from 4 MB to 1 MB witness, like it was done in Signet. The best they can do now is take what they can, be it an $1000 or $200 worth of BTC. You think only about short-term profits. Many miners are not like that. To make sure, that their blocks are valid, mining pools often are running full archival nodes, especially if they are handling a lot of coins. And then, the bigger the block size is, the worse for them, because it takes more space, and it gives less fees. So, mining pools have an incentive, to keep blocks small, because then, it is easier to run nodes, and it is more expensive to transact, so they can get more fees out of it. Would you feel secure if you knew anyone with a million dollars could buy enough gear to attack the network? It is true in many altcoins, and it was true in case of Bitcoin in the past. The average Joe will not spend a dime for this, he will always ask others to pay for it Of course he can. And of course a lot of users can contribute to the network's security, if each of them will pay a little. You can pay for security in two ways: one is transaction fees, another is Proof of Work. If you have more coins, then you can pay in satoshis. If you have more mining equipment, then you can pay in Proof of Work, and make even free transactions, as long as you can mine them. if this could be achieved with a guy from Australia But it can be. It is just a matter of doing yet another soft-fork, similar to Segwit, and increasing the size of the block from 4 MB to 4 GB, 4 TB, or making it unlimited. And then, the decision to reject a future upgrade is in node's hands. how would you feel? Not that much different than today, because I know, that it is very likely, that the mainchain will be heavily spammed in the future, when next limits will be lifted, one-by-one, and when developers will be responsible for nothing. Also, regulations like MICA will keep destroying Bitcoin anyway, so it is good to use it, while you can do so legally. But if Bitcoin will be illegal, just like gold was, or if you would need to pass through KYC to use it, then it won't surprise me, because it is already happening. I wonder if I should inscribe a block of my own, for as low as $500 per block, to be remembered for ages in the chain You won't "be remembered for ages in the chain", because when less and less users will run nodes, and they will be more and more pruned, some nodes may decide to stop serving you historical transactions. There are already much more pruned nodes, than there should be. And there will be only more, and they will be more pruned. If the chain will be still spammed, then future nodes will just store the subset of the mainchain traffic. And then, you will have a choice: wait years to fully synchronize the full chain, by connecting to full, archival nodes, or trust some pruned ones, and accept their proofs, that the chain is valid, without downloading everything. Because the ability to always fetch any transaction, from any block explorer, is temporary. When BSV became too big, then block explorers stopped handling it. And the same can happen with BTC, if the size of the chain will be bigger, than nodes will be willing to handle. what's the incentive for the user to send his coins so miners can take them? Because this is how you teleport coins between mainchain and sidechain. If you send one mainchain coin, then you receive one sidechain coin, and your mainchain coins can be moved anywhere. It is the same case, as if you open a Lightning Network channel: if you use one UTXO, and decide to leave the network, then your old UTXO can be handled by someone else, and you can get coins from a completely different channel. Also, sidechain miners are not working for free. If you use a given sidechain, then you pay mainchain fees, and sidechain fees. It is exactly the same as in LN, where you pay mainchain fees, if you want to join or leave some channel, but you also pay LN fees, when you move coins inside this network. Sweeping them isn't difficult I thought for a while, that sweeping dust is non-standard. But it seems only sending is, and sweeping can be done normally. I get the 40 sats, but why also send 6418 sats to bc1qt039dyk3u6x9x3t52nv0dw7evwg2ja7w05gx3v? Because it was in your example, as a change address. And I decided to send a small donation. |
|
|
|
I assume you used Mara Slipstream, right? Yes. And I also sent some more satoshis as a change, so you can sweep them from bc1qt039dyk3u6x9x3t52nv0dw7evwg2ja7w05gx3v. The current minimum fee is only 2 sat/vbyte, that's not bad at all. It is dynamically adjusted. Fortunately, as we can see, spending 40 satoshis is standard, only sending it is not. Which means, that if someone would spam the chain, then collecting it should be standard (I thought it would also lead to non-standard transaction, but it is flying in mempools, so it is probably standard). I thought about it, but decided it's not worth the effort. It is not yet worth it, but it may be in the future. And it is good to have an alternative, if on-chain fees will rise, because of next halvings, and if there will be some dust here and there. |
|
|
|
I don't know the magic behind the last step, have still to investigate if this is something I'm able to understand without a cryptography background. It is quite simple. If you know, how SPV wallets work, then you should understand it. Just imagine that instead of the merkle root of all transactions, you have a merkle root of UTXOs, and instead of transactions as leaves of the tree, you have transaction outputs, which can be used as inputs in the future. Which means, that initially, you can start from the empty UTXO set: SHA-256("")=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855And then, the owner of the first block is added: https://mempool.space/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098SHA-256(0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee)=6527751dd9b3c2e5a2ee74db57531ae419c786f5b54c165d21cdddf04735281f Then, the second block can be attached, and form a basic tree: https://mempool.space/tx/9b0fc92260312ce44e74ef369f5c66bbb85848f2eddd5a7a1cde251e54ccfdd5SHA-256(047211a824f55b505228e4c3d5194c1fcfaa15a456abdf37f9b9d97a4040afc073dee6c89064984f03385237d92167c13e236446b417ab79a0fcae412ae3316b77)=1be7e6b388892a76eb5119cd32d339cc0f64e3b7574cd4f1d00afaa844331e7c And now, you can connect two leaves of the tree, to compute the merkle root: SHA-256(utxo1)=6527751dd9b3c2e5a2ee74db57531ae419c786f5b54c165d21cdddf04735281f
SHA-256(utxo2)=1be7e6b388892a76eb5119cd32d339cc0f64e3b7574cd4f1d00afaa844331e7c
SHA-256(6527751dd9b3c2e5a2ee74db57531ae419c786f5b54c165d21cdddf04735281f1be7e6b388892a76eb5119cd32d339cc0f64e3b7574cd4f1d00afaa844331e7c)=7fb6e3044fa2b48ae2180b0f41ff88f3b7f48305538643993979e32cd14f1a6c Then, the root of the tree is set to 7fb6e3044fa2b48ae2180b0f41ff88f3b7f48305538643993979e32cd14f1a6c. And you can prove, that your UTXO is inside, by revealing, that the left branch is set to 6527751dd9b3c2e5a2ee74db57531ae419c786f5b54c165d21cdddf04735281f, the right branch to 1be7e6b388892a76eb5119cd32d339cc0f64e3b7574cd4f1d00afaa844331e7c, and you can reveal the UTXO behind the branch you own, by travelling down the binary tree, just like you can do the same inside merkle root for transactions. The nodes would have to store much less data in a "hot" database which changes all the time. Not only that. All updates can be logarithmic. If many parts of the tree are never changed, and coins are just staying, where they were, then once hashed data can be just copy-pasted, without being re-hashed again. If the "coin owners" have to provide the UTXO, I think they have to rely on a solid group of nodes who archive the whole blockchain and do not prune it, so they can query the UTXOs. Yes. If they know only their private keys, but nothing behind that, then they have a problem, if no node can give them any proof, that their transaction exists at all. Then, funds are still there, but if nobody knows, where they are located, then it is the same, as if someone would throw away the private key. Then, having keys is as important, as knowing the content of your transaction, and its location in the UTXO set. Or would this also work if all nodes prune the old blockchain data (e.g. because they're afraid to distribute certain parts of the blockchain)? If some user would backup the UTXO location, and a proof, that coins are located in a certain place, then that user should be safe. Can we expect this in the next years already? It is not a soft-fork. It is just a different client, that can be used by those, who want to consume less resources. As long as it is not mandatory, to provide UTXO proofs, to spend coins, it is fully optional. It can be mandatory, if there will be too much spam, so that nodes will be kicked out of the network. But it is not the case yet, as long as hashrate majority didn't turn BTC into BSV yet. Or is it something for the 2030s/40s? You can use it now, without asking for anyone's permission. Nodes can run any source code they want, as long as they stay compatible with the network. You can here and now, require UTXO proofs from people, to relay their transactions. Or you can accept no transactions at all, and just listen for new blocks. As long as there is no proposal, to make it mandatory, it is fully optional. It is in the same category, as transaction compression: you don't have to process over 600 GB. You can accept ZK proof during Initial Blockchain Download, if you want to. And you can compress any transaction data in any way you want, as long as you can decompress it, and share with the rest of the network in the old format, when needed. So, it is fully up to users, what they want to use. The official protocol dictates, what you need, to stay compatible. But behind it, you can use everything. A good example is "LOTR node": https://www.truthcoin.info/blog/bsv-data-avail/A. Intro Imagine we need to put The Lord of the Rings trilogy “on the blockchain”. Which blockchain, should we use? BTC or BSV? Well, BTC has a 4 MB blocksize limit. LotR is 176 GB. So LotR won’t fit “on” BTC… right? We have to use BSV. Wrong. I could put 10,000 copies of LotR “on” the BTC blockchain, right now. Or even a million copies. Or a million unique movies. There’s no limit. It would be different, if I wanted to put LotR “in” the BTC blockchain. “On” and “in” make all the difference. Which means, that even if someone will want to change the block size, then old nodes can stay unupgraded. Segwit is not mandatory, you can run a node, which knows nothing about it, and you will stay on the same chain. So, some kind of UTXO proof can be included, just like this: 7fb6e3044fa2b48ae2180b0f41ff88f3b7f48305538643993979e32cd14f1a6c. But it is all about nodes, to really validate it, make sure, that it is computed correctly, and that all coins are valid. And behind a single 256-bit number, you can store up to 2^64 bits of data, as long as SHA-256 is not broken. |
|
|
|
$ sha256sum running_node_day13.txt
32d3acbc4c6fe8ed191bb7346b6ae4673891f5bf0bf1ec0e424697837dd65803 running_node_day13.txt It is intentionally left unpublished on forum, to let other newbies earn more merits instead. I am close enough to 1000 merits, so I guess I should stop there. Edit: Hints for SHA-256 grinders, because the content can be guessed, or found on third-party websites, if you locate my node on bitnodes: $ hexdump -C running_node_day13.txt
00000000 44 61 79 20 31 33 3a 0a 5b 63 6f 64 65 5d 7b 0a |Day 13:.______{.|
00000010 20 20 22 63 68 61 69 6e 22 3a 20 22 6d 61 69 6e | "chain": "main|
00000020 22 2c 0a 20 20 22 62 6c 6f 63 6b 73 22 3a 20 __ |",. "blocks": _|
00000030 __ __ __ __ __ 2c 0a 20 20 22 68 65 61 64 65 72 |_____,. "header|
00000040 73 22 3a 20 __ __ __ __ __ __ 2c 0a 20 20 22 62 |s": ______,. "b|
00000050 65 73 74 62 6c 6f 63 6b 68 61 73 68 22 3a 20 22 |estblockhash": "|
00000060 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
00000070 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |________________|
00000080 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |________________|
00000090 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |________________|
000000a0 22 2c 0a 20 20 22 62 69 74 73 22 3a 20 22 __ __ |",. "bits": "__|
000000b0 __ __ __ __ __ __ 22 2c 0a 20 20 22 74 61 72 67 |______",. "targ|
000000c0 65 74 22 3a 20 22 30 30 30 30 30 30 30 30 30 30 |et": "0000000000|
000000d0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |________________|
000000e0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
*
00000100 30 30 30 30 30 30 22 2c 0a 20 20 22 64 69 66 66 |000000",. "diff|
00000110 69 63 75 6c 74 79 22 3a 20 __ __ __ __ __ __ __ |iculty": _______|
00000120 __ __ __ __ __ __ __ __ __ __ 2c 0a 20 20 22 74 |__________,. "t|
00000130 69 6d 65 22 3a 20 __ __ __ __ __ __ __ __ __ __ |ime": __________|
00000140 2c 0a 20 20 22 6d 65 64 69 61 6e 74 69 6d 65 22 |,. "mediantime"|
00000150 3a 20 __ __ __ __ __ __ __ __ __ __ 2c 0a 20 20 |: __________,. |
00000160 22 76 65 72 69 66 69 63 61 74 69 6f 6e 70 72 6f |"verificationpro|
00000170 67 72 65 73 73 22 3a 20 __ __ __ __ __ __ __ __ |gress": ________|
00000180 __ __ __ __ __ __ __ __ __ __ 2c 0a 20 20 22 69 |__________,. "i|
00000190 6e 69 74 69 61 6c 62 6c 6f 63 6b 64 6f 77 6e 6c |nitialblockdownl|
000001a0 6f 61 64 22 3a 20 66 61 6c 73 65 2c 0a 20 20 22 |oad": false,. "|
000001b0 63 68 61 69 6e 77 6f 72 6b 22 3a 20 22 30 30 30 |chainwork": "000|
000001c0 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 |0000000000000000|
*
000001e0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ |________________|
000001f0 __ __ __ __ __ __ __ __ __ __ __ __ __ 22 2c 0a |_____________",.|
00000200 20 20 22 73 69 7a 65 5f 6f 6e 5f 64 69 73 6b 22 | "size_on_disk"|
00000210 3a 20 __ __ __ __ __ __ __ __ __ 2c 0a 20 20 22 |: _________,. "|
00000220 70 72 75 6e 65 64 22 3a 20 74 72 75 65 2c 0a 20 |pruned": true,. |
00000230 20 22 70 72 75 6e 65 68 65 69 67 68 74 22 3a 20 | "pruneheight": |
00000240 __ __ __ __ __ __ 2c 0a 20 20 22 61 75 74 6f 6d |______,. "autom|
00000250 61 74 69 63 5f 70 72 75 6e 69 6e 67 22 3a 20 74 |atic_pruning": t|
00000260 72 75 65 2c 0a 20 20 22 70 72 75 6e 65 5f 74 61 |rue,. "prune_ta|
00000270 72 67 65 74 5f 73 69 7a 65 22 3a 20 __ __ __ __ |rget_size": ____|
00000280 __ __ __ __ __ 2c 0a 20 20 22 77 61 72 6e 69 6e |_____,. "warnin|
00000290 67 73 22 3a 20 5b 0a 20 20 5d 0a 7d 5b 2f 63 6f |gs": [. ].}____|
000002a0 64 65 5d 0a |___.|
000002a4 It is funny, that "code" tags broke forum post formatting, so I had to censor them from ASCII preview. |
|
|
|
He has attacked and killed coins he does not like Of course. If some coin is poorly protected, then it obviously will be attacked. And it is much better to show everyone, that there are bugs, than to let it exist, let it grow to more serious traffic, and see it attacked then. For the same reason, it is good, that Value Overflow Incident happened in the past, and not today. Because then, we got protections from having any UTXO above 21 million coins. And we also got an alert system, it worked for years, and then became deactivated. If some altcoin is launched without any testnet, and is trivially attacked a day after launching, then it is just poorly designed. Satoshi published the whitepaper months before launching the mainnet, and there were some tests in prenet, with 20 leading zero bits in block headers. If you were on IRC at that time, then you could potentially reorg the whole prenet with just a CPU. And altcoins with OP_EVAL taught us, that P2SH is much safer, than letting people execute anything they want. Imagine, how bad P2SH could be, if instead of "OP_HASH160 <fixedHash> OP_EQUAL", you could have "OP_TOALTSTACK OP_HASH160 OP_FROMALTSTACK OP_EQUAL" instead, and some buggy clients would interpret it as a valid P2SH, where anyone could push any Script on the stack, and see it executed. Also, what about scripts, like "OP_EVAL" alone? What about OP_EVAL wrapped inside OP_EVAL? Another important lesson is that Merged Mining should trace the heaviest chain of Proof of Work headers, to calculate the difficulty properly. Then, attacking such altcoins wouldn't be possible, if you wouldn't 51% attack Bitcoin. For that reason, P2Pool can still work, even today, as long as you can mine blocks with enough difficulty. When someone with a lot of hash power mines a cryptocurrency are they prohibited from turning off and leaving the difficulty sky high? See? The same could happen in testnets. Which is why there was "20 minutes rule", to let people mine the chain on CPUs, even if some ASIC will mine a lot of blocks, and leave the high difficulty. However, Gavin also made a mistake, by setting this rule as "mandatory", instead of making it "optional". If CPU blocks on testnets would work just like shares in P2Pool, and if they would be always reorged later, then we would have a nice, clean chain of block headers, with a proper difficulty, that could work, and be resistant to bumping the difficulty. By the way: if blocks would be always produced every 10 minutes, but if coin amounts would be proportional to the global SHA-256 difficulty, then there would be no problem with halting the chain. Then, instead of getting 50 coins every 10 minutes, people could produce 5k satoshis, by making million times weaker blocks. So, as you can see: it is not a problem, that Luke attacked some altcoins. The bigger problem is that such altcoins were poorly designed, so that anyone could easily destroy them. And there were a lot of red flags, when it comes to this specific altcoin. Anyone running code by Luke Jr. is risking their funds and computer security since he has proven he has poor OpSec The risk is similar, if you download the official Core client, and tweak it here and there, so you will use your own implementation. It is just Luke's implementation. If someone is "against spam", then that person can still use Core, with a different settings, or a tweaked code. People picked Luke's version, because they were told to do so, but they don't have to do that. Another thing is that you never know, how many clients are telling you the truth. Tor client also tells everyone, that the user is running Firefox on Windows, but it is quite often a lie, which allows to hide in the crowd of other users of the most popular browser and OS. Which means, that many clients can run "Foobar software", but it can send "Satoshi" as the client's name, and you have no way of knowing, if someone is really running the official version or not. So, I can also run Core, and set it in a way, where other nodes would think, that I am using Knots. Changing "User Agent" is trivial in browsers, and it is also trivial in Bitcoin clients. If you read how it seems to have happened, and how long it took him to notice you would not ever trust him with software that you run. Why? Garlo Nicon's account was also compromised some time ago, and it didn't affect the quality of his posts. Being hacked is one thing, and being right about things is another thing. If someone liked pizza, and his account was compromised, then it doesn't mean, that "pizza is bad". And, as usual, anyone's account can be compromised at any time. Domains where Core's binaries are hosted, were also hacked in the past, and many people downloaded malware, because of that. Does it mean, that everything they produced since then, is compromised? I don't think so. By the way, bitcointalk was also hacked in the past, but we are still using it today. Should we move somewhere else, just because of the past hacks? Will sync a node from scratch in a minimal amount of time. I rent a VPS, and it took me a week, to sync it from scratch. And it was running 24/7. For many people, it takes longer than two weeks, to sync everything, as you can read here: https://bitcointalk.org/index.php?topic=5480200 (and it is not surprising, if it took me around 7 days, and it was running 24/7, then someone running it from home for 8 hours would do the same in 21 days or so) |
|
|
|
strict SIGHASH_ALL It is risky to mine puzzles with SIGHASH_ALL, because then, you can never modify it later. Which means, that if you find a valid solution, and any of your inputs will be moved earlier by any participant, then you are left with invalid signature, even if it has required Proof of Work. I think miners should use at least SIGHASH_ANYONECANPAY, just to make sure, that on-chain fees can be bumped with any coins, without re-mining the solution. do fee-bumps via CPFP/RBF Using CPFP is hard, when you have to wait three months, and solve the next puzzle, to use it. Of course, other people doing peg-outs can potentially do CPFP, even unintentionally, but it is just a side-effect of being in the same transaction, and they may prefer to wait, instead of immediately moving their coins anywhere else. Use Schnorr/Taproot OP_SIZE does not work there. Work proves effort, not correctness Exactly like in the mainchain. You can have "Alice -> Bob" transaction, included by one miner, and "Alice -> Charlie" transaction, included by another miner, in another block. Then, only Proof of Work can decide, which one is valid. consider fraud-proofs/delayed finality to deter invalid headers It is delayed. Things like "<time> 13150 OP_ADD OP_CHECKSEQUENCEVERIFY" simply means, that each sidechain coin can be moved after 13150 blocks (around three months). Also note, that Lightning Network can be connected with such sidechains, and then, it is just about forming the closing channel transaction. Even in LN, funds can be stolen, if you successfully confirm some old channel state. Here, assumptions are not weaker, but stronger, because you can have exactly the same things like you already have in LN, and add Proof of Work just on top of that. Also, when it comes to fraud proofs, there is a limit of what mainchain can do. Because, similarly to LN, the mainchain should not know, what is inside LN, and the same is true here. It is up to users, to set up penalty transactions, to invalidate all old transactions, if they will ever be broadcasted. The mainchain can only accept a given transaction, and make sure, that it will be confirmed, and that it won't be easily altered in 10 minutes, if the whole network spent three months on grinding it. |
|
|
|
Why do you think people go for Knots like crazy Because they heard about "stopping the spam", and they don't have tools or skills, to really check, what is going on. I think this OP_RETURN change is more political, than it should be. To make it clear: lifting next limits is unavoidable. And more of them will be lifted in the future. People are tired of hearing all the time, that "Core decided about this or that", so quite soon, a lot of things will be left to the nodes, and then, there will be nobody to complain to, if more and more settings could be tweaked by each node operator. We no longer have fully centralized alert system. And other centrally controlled things will be also gone soon. Then, people will make their own decisions, and face the consequences. Your coins, your choices. One consequence of making things more decentralized, is that the choice to filter things or not, will be left completely to the users. And that means allowing everything by default, because it is easier to filter the traffic, than to bring back things, which were censored by previously executed code. and they don't try something that's not related to Core at all? Because of "bugward compatibility". Anyone can use any client. But if you are in a minority, then your client can reject a valid chain, and then it is your problem, if the rest of the world is using something else. It is far from obvious, how to implement some things, and sometimes, even mining pools make mistakes. Do you know, how to move coins from OP_TRUE? And from OP_CHECKSIG? And what about OP_CHECKSIG OP_NOT? What about a lot of different edge cases, like OP_CODESEPARATOR? There are many different things to implement, and all of that should be correct. If there are many different clients in use, and all of them are Open Source, then you may be able to halt some of them, by convincing them, that someone produced an invalid block, while the rest of the network will be unaffected, and continue mining on top of it. Also, some people think, that OP_RETURN always invalidates a given coin. Then what about "OP_IF OP_RETURN OP_ENDIF"? I guess some clients can be forked, by doing things like that, or they can start enforcing weird limits, even if there are no data pushes, and if someone uses OP_RETURN as "OP_FALSE OP_VERIFY". if this transition to Knots is happening because "you like Knots a lot", or because "you don't like Core anymore" It is more likely, that people don't like Core's relay policy, and they think, that spam should be actively censored. Also, I guess a lot of people, who are "against spam", don't really run any node in practice, because if they would, then they would also know some facts. For example: OP_RETURNs make the blocks smaller, because they are placed in legacy space, so if someone is producing 1 MB OP_RETURNs, instead of 4 MB TapScript inputs, then blocks are smaller, because of that (unless someone tries to pretend, that Segwit does not exist). Another truth is that checking OP_RETURN or some "OP_FALSE OP_IF ... OP_ENDIF" is actually faster, than validating some OP_CHECKSIG, or OP_CHECKMULTISIG, with fake keys or signatures. I don't think people suddenly started to "like Knots a lot", because the actual code is very similar. If someone wants to run a full node, then picking that client, or another, is a matter of personal taste. Using Knots is not that much different, than building Core from the source code, and adding your own tweaks here and there. If you download the Core, change some lines of code here and there, compile it, and start using your own version, which would be 99% compatible with the original, then most of the time, nobody would even notice, that you are running your own version (some people will see, that your client will show "99" as version number, but you will be hidden in a crowd of other developers, who also have their own not-yet-merged tweaks, or simply built the unmodified version from the source code). |
|
|
|
I think it should be possible to send bitcoins to a script containing two addresses. Of course it is possible. For example: OP_DUP OP_HASH160 OP_ROT
OP_IF
<aliceHash>
OP_ELSE
<bobHash>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG And then, it can be executed as: <aliceSignature> OP_TRUE <alicePubkey>
<aliceSignature> OP_TRUE <alicePubkey> <alicePubkey>
<aliceSignature> OP_TRUE <alicePubkey> <aliceHash>
<aliceSignature> <alicePubkey> <aliceHash> OP_TRUE
<aliceSignature> <alicePubkey> <aliceHash> <aliceHash>
<aliceSignature> <alicePubkey>
OP_TRUE But also as: <bobSignature> OP_FALSE <bobPubkey>
<bobSignature> OP_FALSE <bobPubkey> <bobPubkey>
<bobSignature> OP_FALSE <bobPubkey> <bobHash>
<bobSignature> <bobPubkey> <bobHash> OP_FALSE
<bobSignature> <bobPubkey> <bobHash> <bobHash>
<bobSignature> <bobPubkey>
OP_TRUE One address can unlock the UTXO at any time and the other can unlock the UTXO after a certain time with OP_CHECKLOCKTIMEVERIFY Then, it is just a matter of extending some conditions. For example: OP_DUP OP_HASH160 OP_ROT
OP_IF
<aliceHash>
OP_ELSE
<time> OP_CHECKLOCKTIMEVERIFY OP_DROP <bobHash>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG |
|
|
|
|
Show Posts
