Bitcoin Forum
August 15, 2022, 07:40:40 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
1  Economy / Gambling / Re: ✅ SicoDice.com⭐ 200% Deposit Bonuses 2% House Edge ⭐High Faucet ⭐Daily Contests on: June 19, 2022, 03:24:46 AM
have been waiting 6 hours now for a withdrawal of 3.43LTC,
no response, nothing.

why would a dice site have manual withdrawals?

james
2  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: May 21, 2022, 03:32:34 PM


and? this doesnt prevent you from running it,
although it does suggest you should try a compiler thats a bit more recent that 2015  Roll Eyes
3  Bitcoin / Development & Technical Discussion / Re: Empty blocks on: May 16, 2022, 04:35:30 PM
as long as you can produce correct nbits for the next block (15 lines of c++), validate the previous header hash (using openssl lib, 5 lines of c++), you can test to see whether the blockheader you received is indeed accurate.
I didn't mean this. Sure, you can write a program that checks the validity of the block header, but if you haven't verified the entire chain until that point, you can't know for sure what's the previous block hash or if a transaction double-spends etc.

not including transactions (since you wouldnt know or be listening for txes) would actually improve your chances of nailing a block.
Yes, but it's little matter when it comes to earning millions of sats in fees.

understood, sure.
however given bitcoin's difficulty, it would be highly unlikely for some party to solve a blockheader where the contents were invalid (and you could easily test this).
additionally, if you let a spv program run for a little while before starting your stratum up... it would be trivial to test if the 'blocks heard' did in fact form a legitimate chain.

prevhash being the sha256d of the previous block.. easy to check

(edit) in fact, the most difficult part would be determining the block height - this is indeed part of the coinbase tx (bip34).. but you dont have access to it if you are just listening to headers.. you'd have to have this info ahead of time

james



The timestamp difference is likely not 3 minutes, though that would be indicative of some sort of block withholding/selfish mining but I highly doubt so. It is far more likely for an inaccuracy between the timestamp. From my past experience, my node always received the blocks within ~1-5 seconds of each other which is congruent with the propagation time of the network. You can still use the timestamp as a variable if for some reason you need it though.

The main problem with SPV mining (or mine now, validate at the same time) was the major fork back in 2015 by the various larger pools which has largely resulted in a huge income loss by the larger pools. If you read back on the issue and the topic at that time, they actually didn't really care if they validated the block or not which resulted in a total mess that the community had to deal with. The point at that time was that they wanted to gain an edge over the others, not because of bandwidth constraints. It simply made more sense to just get a server that does it for you or to just join a pool. The profits from the block transaction fee far outweighs the cost.

I highly doubt that any farms would bother to not include transactions because those up/down speed would be okay for stratum, considering the fact that you can still cut down on unnecessary transmissions to the pool. It is still faster and more cost efficient to rely on an external server to compile and feed the data instead of pure SPV mining. With that in mind, most of the larger miners/pools used to use Bitcoin Relay Network or now known as FIBRE but I'm not sure if its still in use or replaced again. They actually do have an edge over the others by that alone though SPV mining was a prominent practice at that time. I think there was some proof that it actually didn't really made sense now with all the optimizations.

Also, at some point in time, the empty blocks might've been due to covert ASICBoost but it isn't happening now that overt ASICBoost is so prominent.

P.S. I don't think intentional sabotage is likely because that is quite expensive in the first place, only happened once accidentally.

do you have any links for the 2015 event?
i dont recall this, but could be wrong.. bitcoin has always validated the block contents and transactions before accepting it.

james
4  Bitcoin / Development & Technical Discussion / Re: Empty blocks on: May 16, 2022, 01:51:55 PM
when a pool makes a blocksolve it knows it has a bit of time to quickly work on another block while the network is propagating its first block. so instead of wasting time collating transactions to make a new blockheader it just begins a 'empty block' and as the asics run through the first few rounds of their nonce/extranonce. the pool then starts adding transactions into a blocktemplate for the next header to send in the next round of hashing once then finished their attempts.
Actually almost all the time it is another pool that miners the empty block because they are "spy mining" and get the successful header before the block is even propagates and start working on the next block right away. Otherwise if it is their own block they don't need to "collect transactions" since they already know what transactions were included in that previous block.

This case could be the same too considering the coinbase string in the two blocks are slightly different (one has "Mined by unp1" and the other doesn't) that could mean 2 stand-alone servers.

Quote
oh and the '3 minutes' is not actual 3 physical minutes. its a use of the timestamp to add some extra 'nonce' possibility.
If the block is empty why would they change time, it is not like they have to compute merkle root hash by computing a thousand hashes?!

this is what i was alluding to.
back in 2015 i personally watched antpool mine 4 blocks on top of each other without relaying the blocks to the network.
this is possible by listening to their stratum.notify and watching prevhash change, while the network doesnt change.

james



worth mentioning as well, back in the day there would often be bitcoin mines setup with rigged power out in the expanse of china.. with the WAN link being an old 2g mobile phone.
the max send rate on 2g being around about 0.05-0.1megabit/sec (so 5-10kilobytes/sec).

with even a half megabyte block taking up to 1.5 minutes to get out onto the network, you can see why blocks with only the coinbase txn were mined.

james



Quote
Another possibility is the stratum/pool mining software responsible for this block is not connected to a full node, rather a lite or SPV node. To build a valid block, you really only need to know the previous block hash, the height and the coinbase reward. Running a bitcoin node again, is quite resource intensive - and the disk space alone is 405Gb (standard, not txindex) - I can fully see a situation where some clever software simply listening to the headers could work.
But, running a full node is a necessity if you want to be accurate and sure. Listening to an SPV node increases your chances to be beaten in propagation as you receive the info later than the others. (And you're trusting an entity that can set you up)

as long as you can produce correct nbits for the next block (15 lines of c++), validate the previous header hash (using openssl lib, 5 lines of c++), you can test to see whether the blockheader you received is indeed accurate. not including transactions (since you wouldnt know or be listening for txes) would actually improve your chances of nailing a block.

james
5  Bitcoin / Development & Technical Discussion / Re: Empty blocks on: May 15, 2022, 09:06:49 AM
Not an accident at all.

There really isn't any incentive to include transactions in blocks.
It's a modest amount of processing power required to test, pick and commit transactions to block (nearly a quarter of the bitcoin codebase is dedicated to this).
On top of that, if the node is behind a slow WAN connection - the time to propogate the block across the network could very well mean it is beaten by a more responsive node.
You could argue that the fees are the incentive to include them in a block, but when you are talking 6.25BTC ($184,000 USD) as the base - some aren't bothered by this.

Another possibility is the stratum/pool mining software responsible for this block is not connected to a full node, rather a lite or SPV node. To build a valid block, you really only need to know the previous block hash, the height and the coinbase reward. Running a bitcoin node again, is quite resource intensive - and the disk space alone is 405Gb (standard, not txindex) - I can fully see a situation where some clever software simply listening to the headers could work.

There are much more devious reasons as to why the block has no transactions, but will leave them to the readers imagination.
The majority of it stopped around April last year (2021) *cough*.

james

6  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~100 BTC total bounty to solvers! ==UPDATED== on: May 14, 2022, 12:27:47 PM
probably not going to be the code that finds it, but i notice people have posted python here so..

https://github.com/barrystyle/b58

is currently hardcoded for #64,
on my 11th gen i7-1165g7 manages around 124,000 keys/sec.
matches using the hash160 rather than the full base58 address for speed.

james
7  Economy / Gambling / Re: Vulnerabilities in gambling websites in past on: May 14, 2022, 05:49:37 AM
Every company is for surely keeping our email addresses and they've got a lot of purposes on it. And it's not just the companies that we used to sign up are the ones keeping it.
If there's someone who get to see it and they have ideas and database of keeping it, they'll sell it to the other parties. That's why we have no idea where these ads and promotions are coming from despite we just signed up for a few websites before.
This had been happening for long now without our consent, our private documents can be sold out without the prior permission of the owners. Just image little bride in the data of those companies holding out emails and private documents. All this can be exposed to the public or sold out to third parties which can be used to harm without we knowing how come it happens.

I am very conscious when I am giving out my information to websites or companies that ask for it. This is the major reason why I don't always support the use of exchanges especially those ones that ask for other identity information from customers.

what we can do is just limit the info that we disclose in these sites. as much as possible use a different email if you feel it is not for long-term usage. because using only one email in most of your transactions will subject you to high likelihood of being pawned or attacked by unnecessary actors from the net.
those collected data - of course, we don't know where they will end up with. so be cautious also on the unsolicited links sent to you. better discard it without opening the mail if you know it is just a spam.

simple. go buy a domain name from a service that offers an email forwarder (i know namecheap offers this, probably quite common place now).
then point it at your regular email address. when you start getting lots of spam or too many promotional posts, remove the entry and create a new one - again, pointing at your regular email.
have done this for years and has worked a treat.

james
8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][SUPER] SuperCoin v2 - The blazing fast, low fee coin - Tried and tested on: October 24, 2020, 06:39:57 PM
has anyone tried porting this up to the latest bitcoin codebase etc?

james
9  Bitcoin / Development & Technical Discussion / Re: Bitcoin Empty Blocks on: August 25, 2020, 12:01:39 AM
Quote from: DougM link=topic=5270775.msg55060150#msg55060150
Interestingly the timestamps for follow on blocks can be earlier in time...that was a bit of surprise to me at first, but I learned I can't assume sequential blocks are in temporal order.  For example:

https://www.blockchain.com/btc/block/32649  -->  2010-01-02 04:49
https://www.blockchain.com/btc/block/32650  -->  2010-01-02 02:50

Still reigns true now (https://github.com/bitcoin/bitcoin/blob/0.20/src/chain.h#L18-L30), unsure of the exact rational behind it..
10  Bitcoin / Development & Technical Discussion / Re: Bitcoin Empty Blocks on: August 24, 2020, 11:41:06 PM
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)..
Code:
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]

11  Bitcoin / Development & Technical Discussion / Re: Bitcoin Empty Blocks on: August 23, 2020, 12:18:57 PM
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  Roll Eyes

james
12  Bitcoin / Development & Technical Discussion / Re: Bitcoin Empty Blocks on: August 23, 2020, 11:29:38 AM
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
13  Bitcoin / Development & Technical Discussion / Re: getblocks vs getheaders on: March 25, 2020, 04:49:58 PM
It's there to prompt nodes to request the next 500 blocks. It's to ensure that they know there are more blocks to download. Relevant lines in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/v0.9.5/src/main.cpp#L3698 and https://github.com/bitcoin/bitcoin/blob/v0.9.5/src/main.cpp#L3344

thankyou.
where in the code does it 'set' this as the known tip? ive tried using hashStop/hashContinue but this doesnt seem to work..
14  Bitcoin / Development & Technical Discussion / getblocks vs getheaders on: March 25, 2020, 01:25:00 PM
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.

Quote
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
15  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [MOON] Mooncoin 🌙 mandatory update to 0.18.1 on: March 12, 2020, 07:44:07 PM
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/mooncoin

Will keep it up to date as time allows,

james
16  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [MOON] Mooncoin 🌙 mandatory update to 0.18.1 on: March 10, 2020, 07:02:55 AM
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.

Code:
       consensus.nPoWForkOne = 26850;
        consensus.nPoWForkTwo = 1100000;
        consensus.nPoWForkThree = 1250000;
        consensus.nRestoreValidation = 1801000;

Code:
   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:

Code:
   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
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [MOON] Mooncoin 🌙 mandatory update to 0.18.1 on: March 08, 2020, 03:47:00 AM
Quote
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).
18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [MOON] Mooncoin 🌙 mandatory update to 0.18.1 on: March 07, 2020, 10:35:32 PM
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#L1160

Protection in 0.18.1

https://github.com/MooncoinCommunity/wallet/blob/0.18/src/validation.cpp#L573


Now 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
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [MOON] Mooncoin 🌙 mandatory update to 0.18.1 on: March 07, 2020, 10:25:07 PM
Has anyone checked up on the court case, where the blocked funds originated from?
20  Bitcoin / Development & Technical Discussion / Re: SegWit, NOMP (Part 3) on: March 06, 2020, 05:41:38 AM
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.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!