When it comes to validating a block, depending on the composition of transactions, it can take upwards of a few seconds (even more in some pathological/adversarial scenarios) to complete.
perhaps if you use a commodore64.. doublesha of the raw transaction data per transaction in block, store in list, then hash the list, then compare this hash with the one provided in the blockheader, then hash the blockheader and ensure its below target, we're talking milliseconds here.. heres an example from dash (x11 is a bit more harsh than sha256d, only enforcing the point).. 2020-08-24 23:37:04 received: block (452 bytes) peer=0
2020-08-24 23:37:04 received block 4829e011bc551411c903f35b1f436f92c2a021d89e3e9b2a12be1ffd632cb736 peer=0
2020-08-24 23:37:04 - Load block from disk: 0.00ms [0.01s]
2020-08-24 23:37:04 - Sanity checks: 0.02ms [0.01s]
2020-08-24 23:37:04 - Fork checks: 0.03ms [0.01s]
2020-08-24 23:37:04 - Connect 2 transactions: 0.01ms (0.007ms/tx, 0.015ms/txin) [0.01s]
2020-08-24 23:37:04 - Verify 1 txins: 0.03ms (0.026ms/txin) [0.02s]
2020-08-24 23:37:04 - IS filter: 0.01ms [0.01s]
2020-08-24 23:37:04 - GetBlockSubsidy: 0.01ms [0.00s]
2020-08-24 23:37:04 - IsBlockValueValid: 0.02ms [0.01s]
2020-08-24 23:37:04 - IsBlockPayeeValid: 1.63ms [0.62s]
2020-08-24 23:37:04 - Loop: 0.01ms [0.07s]
2020-08-24 23:37:04 - quorumBlockProcessor: 0.04ms [0.41s]
2020-08-24 23:37:04 - deterministicMNManager: 3.06ms [1.14s]
2020-08-24 23:37:04 - GetTxPayload: 0.00ms [0.00s]
2020-08-24 23:37:04 - BuildNewListFromBlock: 1.40ms [0.56s]
2020-08-24 23:37:04 - CSimplifiedMNList: 3.39ms [1.19s]
2020-08-24 23:37:04 - CalcMerkleRoot: 3.05ms [1.08s]
2020-08-24 23:37:04 - CalcCbTxMerkleRootMNList: 8.81ms [3.20s]
2020-08-24 23:37:04 - GetMinedAndActiveCommitmentsUntilBlock: 0.19ms [0.07s]
2020-08-24 23:37:04 - GetMinedCommitment: 0.01ms [0.09s]
2020-08-24 23:37:04 - Loop: 0.01ms [0.01s]
2020-08-24 23:37:04 - ComputeMerkleRoot: 0.01ms [0.00s]
2020-08-24 23:37:04 - CalcCbTxMerkleRootQuorums: 0.24ms [0.18s]
2020-08-24 23:37:04 - CheckCbTxMerkleRoots: 9.09ms [3.39s]
2020-08-24 23:37:04 - ProcessSpecialTxsInBlock: 12.22ms [5.01s]
2020-08-24 23:37:04 - Index writing: 0.07ms [0.03s]
2020-08-24 23:37:04 - Callbacks: 0.01ms [0.00s]
2020-08-24 23:37:04 - Connect total: 14.15ms [5.76s]
2020-08-24 23:37:04 - Flush: 0.09ms [0.04s]
2020-08-24 23:37:04 - Writing chainstate: 0.01ms [0.00s]
|
|
|
|
Yes, most mining pool are able to choose their own transactions. But there isn't any rational mining pool which would intentionally include only the coinbase transaction when they are trying to maximize their profits.
this topic gets quite deep, you're correct - but if a pool isnt mining fairly, referring to the SPV/selfish mining paradigm before; segwit actually causes interference in this situation due to the signature data - as there are no other nodes present when calculating the witness, so it is easier to just not include any transactions at all. a lot of the chinese pools run a 'dead miner' on the stratums of their competitors, as this is the only way to ensure they have the latest prevhash when a network node may not have relayed it to the network. if you search the forums here for a fairly famous incident involving kano's pool and f2pool (i think), was 2016-2017.. some good reading to be had there The scenario given is a block being mined 4 seconds after the previous block. It's true that mining pools can issue a message to update the data but in this case, the mining pool likely wanted to utilise the small amount of time that it took to reconstruct their merkle root. My hunch is that they did issue a mining.notify and that they didn't include any transactions as of yet. You can observe how only the blocks with quick succession are empty but the others are populated (to a reasonable capacity).
four seconds is more than enough time for the stratum to issue getblocktemplate to the daemon and receive a response (template containing the txlist as well). not to mention custom setups where they just query the mempool directly via getrawmempool etc. in fact this could be done in as little as 125ms (or less) depending on the daemon's network load etc. Yep, selfish mining. Would it work for Antpool though? They only have an estimated 9% of the network's hashrate, they're more likely to lose out from this attack.
antpool used to be much closer to 40-45% of the network hashrate back then. i personally witnessed antpool mine three blocks in quick succession without relaying any of them to the network; as i was monitoring the stratum mining.notify broadcasts - but they lost all of them as another (honest) pool found and submitted a block as they were going for the fourth.. and another pool quickly followed suit.. they would've easily lost $75k USD in moments, due to their own greed  james |
|
|
|
the stratum chooses whichever transactions it likes out of the mempool to include in a block. generally all the open source stratums will just include as many as they can (example: https://github.com/tpruvot/yiimp/blob/next/stratum/coind_template.cpp#L390-L487), however the big mining pools which run their own software know this isnt always economical and will select a set that results in them netting the most coins. there is no penalty for doing this and is encouraged almost; as it creates a fee market. even with the yiimp example, you can see the total amount of transactions included can be adjusted ( https://github.com/tpruvot/yiimp/blob/next/stratum/coind_template.cpp#L428-L432). the 'spv mining' answer is incorrect; as the stratum is additionally free to refresh the merkleroot hash at any time (generally this is done every 30-40s), regardless of whether a new block has been sighted on the network. it does this by issuing a mining.notify broadcast to all miners ( https://slushpool.com/help/stratum-protocol#example) which includes the updated data. around 3-4 years ago, some of the big pools would not include any transactions in a block, as well as not relaying the block as it was found. this gives them an advantage over the rest of the network, as they can begin mining a new block ahead of everyone else. after they had mined 2 or 3 blocks whilst 'isolated' from the network; they would reappear on the network and solve an additional block on their hidden chain, but this time in public; which would immediately cause all other nodes to request the brand new blocks, as it would have significantly more chainwork than the existing chain. having zero transactions in the block, besides the coinbase transaction, ensures the blocks are propogated quickly and increases the chance that they will be accepted by the network. james |
|
|
|
thankyou. where in the code does it 'set' this as the known tip? ive tried using hashStop/hashContinue but this doesnt seem to work.. |
|
|
|
Hi everyone, I'm currently mid way through converting Bitcoin 0.19 based client so that it can properly synchronize from a pre-0.10 clients chain. Those who are in the know should automatically know exactly which currency i'm talking about. So far i'm having good luck but seem to run into an unusual and undocumented problem. Every 500 blocks received via INV request, seem to come with an extra block at the end that reflects the current chains tip. Everywhere i've read suggests that *only* 500 blocks are sent, but I always seem to get this extra block tacked onto the end. 2020-03-24T15:44:05Z ComputeNextStakeModifier: prev modifier=0x000000105dbc2bd6 time=1545703144
2020-03-24T15:44:05Z ComputeNextStakeModifier: no new interval keep current modifier: pindexPrev nHeight=499 nTime=1545703144
2020-03-24T15:44:05Z UpdateTip: new best=0000000105a7e280f68b5d030282998640d6da2fa0eb107e9dd65a3e7ccad9d8 height=500 version=0x00000003 log2_work=8.9686668 tx=521 date='2018-12-25T02:01:18Z' progress=1.000000 cache=0.1MiB(676txo)
2020-03-24T15:44:06Z ERROR: ProcessNewBlock: AcceptBlock FAILED ( (code 0))
2020-03-24T15:44:08Z ComputeNextStakeModifier: prev modifier=0x000000105dbc2bd6 time=1545703144 It doesnt actually affect sync at all, but it bugs the s**t out of me. Yes neckbeards, this isnt technically 'bitcoin only' discussion; but I think its a heartwarming change from 'howTO cloening of the cOIN'.. and technical discussion, which this forum has sorely lacked over the past few years. james |
|
|
|
Hi all, As promised; * Mooncoin using classic consensus rules rebased over Bitcoin 0.19.1 * Full validation of block target from block zero to chain tip * Rewritten equivalency 'forbiddentx' code * All tests corrected and compiled https://github.com/barrystyle/mooncoinWill keep it up to date as time allows, james |
|
|
|
just noticed something as well at https://github.com/MooncoinCommunity/wallet/blob/0.18/src/validation.cpp#L3557-L3571 and https://github.com/MooncoinCommunity/wallet/blob/0.18/src/chainparams.cpp#L70-L73. consensus.nPoWForkOne = 26850;
consensus.nPoWForkTwo = 1100000;
consensus.nPoWForkThree = 1250000;
consensus.nRestoreValidation = 1801000;
if (nHeight >= consensusParams.nRestoreValidation) {
// Check proof of work
if(nHeight >= consensusParams.nPoWForkOne && nHeight < consensusParams.nPoWForkTwo){
unsigned int nBitsNext = GetNextWorkRequired(pindexPrev, &block, consensusParams);
double n1 = ConvertBitsToDouble(block.nBits);
double n2 = ConvertBitsToDouble(nBitsNext);
if (std::abs(n1-n2) > n1*0.5){
return state.DoS(100, error("%s : incorrect proof of work (DGW pre-fork) - %f %f %f at %d", __func__, abs(n1-n2), n1, n2, nHeight),
REJECT_INVALID, "bad-diffbits");
}
} else if (block.nBits != GetNextWorkRequired(pindexPrev, &block, consensusParams)){
return state.DoS(100, error("%s : incorrect proof of work at %d", __func__, nHeight),
REJECT_INVALID, "bad-diffbits");
}
}
if we do a bit of substitution here (for the non-coders amongst us), this reads as follows: if height is equal to or greater than 1801000 then
if height is equal to or greater than 26850 AND height is less than 1100000 then
meaning nbits for every block before 1801000 is not being tested. just for fun, i've put together a client based on bitcoin 0.19.1, considering quickly rebasing it over what is available for bitcoin 0.20; community is free to decide whether they support it or not. edit derp - just checked past couple pages.. james |
|
|
|
We brought up a solution which could be adopted by the communtiy that only certain outputs should be blocked, but again thats a community decision to change the "forbidden tx" protection solution.
Only certain inputs are blocked. Phrased like that - it sounds like youre saying all uxto's are blocked, which would mean the chain cant move. Having said that, the 65 million/billion (if memory serves?) is not a legitimate claimable amount - it is common knowledge that this amount came from Cryptsy, and was most likely moved by Big Vern himself. There was a class action suit against Cryptsy where people were able to state what they lost, prove it and receive compensation. This time has passed, well and truly (was during 2018). |
|
|
|
Alright I try to explain it again. Mooncoin_Foundation gave the 3 Addresses: - 3 Adresses are blocked via consensus 2QovBjnVke4fgn9UXdz9osheNLxQCk3d8R (the 1st one with 62B) 2DMfpxPiMtpVDVyrxQAAmfBbZnDH4XCMfK (Dec, 2014 thefts) 2JA3Cqf9on8YuxngxdXStCFKanAGnaQU5A (Dec, 2014 thefts) I relayed these 3 Addresses to Peter. Peter used the same technique to block these coins as already done in 0.13.9 Who did implement these protection in first place? -> Barry ( 0.13.9 codebase )How does this protection work? Barry did implement it that way that it blocks all UTXOs that were sent to these addresses, so all TX'es that had a destination to those 3 addresses are blocked. So what got changed in 0.18.1? Same as in 0.13.9 - All Tx'es towards these addresses got blocked, but now on the consensus level instead of the mempool level. These completely ensures that the coins can't be spent. ( On 0.13.9 you could mine your own blocks and include these transactions ) So to sum it up. - This exact protection was in place since the 0.13.9 release as said ( @Michi your 23f1ade1a9 is in the list on 0.13.9 of blocked transactions )Here are the 2 links again to the Github of 0.13.9 and 0.18.1 Protection in 0.13.9 https://github.com/MooncoinCommunity/wallet/blob/0.13.9.1-segwit/src/main.cpp#L1160Protection in 0.18.1 https://github.com/MooncoinCommunity/wallet/blob/0.18/src/validation.cpp#L573Now to the "insecure wallet problem" Mebagger is partly right on that one, 0.18.1 should add the historical validation I completely agree with that. But it couldnt have been done on the initial release, otherwise it would have rejected 0.13.9 instantly which shouldnt be done that way. 0.17 has the historical validation in place which works and was a good job of the 0.17 team, it just should have done ( in my opinion ) after the 0.18.1 set height to set validation in place. But as said, should be added to 0.18.1 whatever that version will be called then, lets call it 0.18.5. So what would need to be done right now is porting the 0.17 historical validation to 0.18.1 and make 0.18.5. About the "forbidden tx" protection, thats up to the community how you guys want to handle that. 0.18.1 - As its part of the consensus right now, if you guys decide to lift that protection, pools and exchanges would need to update on the 0.18.5 release, but again thats up to you. I've talked to Peter and the best would be to modify the "forbidden tx" protection that it only blocks specific UTXOs ( But that would be a new system, not the one that got introduced in 0.13.9 which blocks all UTXOs ) So that issue should have been brought up way earlier, but seems like nobody looked into it until now, as that "issue" persisted for over 2 years ( since 0.13.9 ) release. Happy to help/assist on the 0.18.5 or to clarify any other questions that come up. Kind regard, ChekaZ I implemented the forbiddentx routines way back in Mooncoin 0.10 ( https://github.com/mooncoindev/mooncoin/blob/master/src/main.cpp#L939-L1073). Mooncoin 0.13.9 is not mine, this was done afterwards by Valhalis ( https://github.com/mooncoincore/wallet), who based it on my initial port ( https://github.com/mooncoindev/mooncoin-0.13). My forbiddentx routine did its job, but certainly had its flaws; and I have since improved (vastly) my methods for blocking given inputs. Contained within are the blocked funds inputs from the court case I mentioned, which were passed onto me by Mooncoin Foundation. james |
|
|
|
|
Has anyone checked up on the court case, where the blocked funds originated from?
|
|
|
|
This is an interesting experience. Hopefully someone else will find these posts and learn as I have.
...
The difficulty here would be generating a coinbase transaction correctly using the new address types (bech32 etc). There isn't much information available on this topic - I've had some success with yiimp however. All you need to do is encapsulate the address type correctly. |
|
|
|
I want to using bitcoin-cli to listen new block and make notification when there have a receive transaction. i didnt want to have a ancient block, how to run bitcoin core without sync ancient block but just current blockheight
What you are after is done partially in https://github.com/bitcoin/bitcoin/pull/9483. While it isnt true SPV mode, it will only synchronize the blockheaders on the chain; then request only blocks which are relevant to the inputs you hold in your wallet. Hope this helps. |
|
|
|
i find it amusing that gatra posted a bounty to bring riecoin up to 0.16, then basically disappears, with the work now being done for free.. smart lad  |
|
|
|
|
may as well throw my hat in the ring also; i'd submitted my progress on a Bitcoin/Riecoin 0.16 port to gatra on the 18th July, but hadn't had time to revisit and hadn't heard much back. however looking at the volunteer work, i'm happy to share my code if any bits could be picked out. from memory the bitshift maths (esp considering uint256/arith_uint256 constraints) in pow.cpp was quite tricky, but i ended up with correct results..
james
|
|
|
|
0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000
██╗00██╗0██████╗0██████╗0██╗000██╗0█████╗0███╗000██╗0000███╗000██╗███████╗████████╗██╗0000██╗0██████╗0██████╗0██╗00██╗
██║0██╔╝██╔═══██╗██╔══██╗██║000██║██╔══██╗████╗00██║0000████╗00██║██╔════╝╚══██╔══╝██║0000██║██╔═══██╗██╔══██╗██║0██╔╝
█████╔╝0██║000██║██████╔╝██║000██║███████║██╔██╗0██║0000██╔██╗0██║█████╗00000██║000██║0█╗0██║██║000██║██████╔╝█████╔╝0
██╔═██╗0██║000██║██╔══██╗╚██╗0██╔╝██╔══██║██║╚██╗██║0000██║╚██╗██║██╔══╝00000██║000██║███╗██║██║000██║██╔══██╗██╔═██╗0
██║00██╗╚██████╔╝██║00██║0╚████╔╝0██║00██║██║0╚████║0000██║0╚████║███████╗000██║000╚███╔███╔╝╚██████╔╝██║00██║██║00██╗
╚═╝00╚═╝0╚═════╝0╚═╝00╚═╝00╚═══╝00╚═╝00╚═╝╚═╝00╚═══╝0000╚═╝00╚═══╝╚══════╝000╚═╝0000╚══╝╚══╝00╚═════╝0╚═╝00╚═╝╚═╝00╚═╝
0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000
Korvan is an experimental digital currency forked from Bitcoin 0.16.2 that enables instant payments to
anyone, anywhere in the world. Korvan Network uses peer-to-peer technology to operate
with no central authority: managing transactions and issuing money are carried
out collectively by the network. Korvan is the name of open source
software which enables the use of this currency.
The project name is a play on the archaic word korva meaning edge - referring to the focus we have on developing cutting edge technology and to be the most efficient cryptocurrency for on-chain utilities in the blockchain sector. Korvan will start life as a proof-of-work only blockchain til our titan release is completed which is a currently in active development shortly have launch you can track our progress on branch proof-of-stake note all updates will be released in a easy to understand format bi-weekly. Currently the team consit of Simon a university graduate in computer science looking to change how business is done on the blockchain and Zack a self-taught developer fulent in many programming languages seeking to build disruptive technology. Interested in running a pool or other services built on Korvan feel free to join us on discord to discuss partnerships. A small coin sale [32 Masternodes] on discord will take place to jump start project growth, any unsold coins will be burned. These funds will cover exchange listing fees, design cost, marketing, and roadmap development. Each feature in our roadmap will have it's own whitepaper followed by the Korvan purplepaper currently being refined.
Korvan is the second blockchain to implement the 'Balloon' memory-hard hashing function, superior in strength to Argon2, while remaining resistant to cache/side-channel attacks.
Additionally, the Balloon Hashing function does not require anywhere near as much memory to demonstrate its memory-hardness; making it possible for low-memory devices to verify proofs. Balloon supports both CPU and GPU mining. Balloon makes it easy to introduce different length inputs, memory and mixing parameters so we can always prevent asic and fpga mining. Whitepaper: https://eprint.iacr.org/2016/027.pdf
wheras i dont mind people cloning the balloon algorithm (was bound to happen); i do take issue with most of the content/ANN being ripped directly from deft ( https://bitcointalk.org/index.php?topic=4396753.0). barrystyle/deft. |
|
|
|
|
it's more than simply an algorithm change, the blockheader has also jumped from 80 bytes to 144 with the addition of two fields.. thats a big cubehash512
|
|
|
|
bla bla bla
Now - if we can get some clarity on the code, that would be fantastic.
#crysx
chrys, belg has been very open and communicative about the work he has done, providing beta compiles for people to try; receiving a very warm response in doing so - and has been kind enough to then open source the code. i'd actually forked that to the deftchain repo ( https://github.com/deftchain/cuballoon) whilst leaving the fee in place, as anyone is free to remove it if they deem necessary; additionally i have some improvements i'm about to push to the repo (in the realm of 2x hashrate) which are free for all to try. please check things out with me first; as you mightnt have been aware of the nice deeds of individuals on the discord. james |
|
|
|
I've been trying to learn about this project over and over, but still don't get a hint on what is this project really working for?
Is there any easier material that can be read to know about the project?
You're not the only one in this thread, that doesn't understand what is this project made for... something about algorithms and password history i guess) I'm not sure what you mean exactly, maybe it's lacking a roadmap but at least it's not just some ICO token for pump and dump only. thank you  some people are really getting hung up on this aspect; i stopped reading whitepapers years ago after realizing less than 5% of coins actually follow through with their promises. |
|
|
|
|
the only credible gpu miner at the moment is still in testing by @Bel (a discord member).
happy to admit fault in any other case, a little evidence perhaps?
james
|
|
|
|
|
Show Posts
