Topic: [ANN] Blackcoin Lore [BLK] | Home of PoS 3.0 | No ICO | No Pre-mine - page 4. (Read 32663 times)

thanks again to the Devs for the new release - now working like charm with a 40k tx dust attack - GOOD WORK!!!!!!!!!
 

Download (v2.13.2.7-4e1e6e83f @ 2020-11-24)



new Release is out since 24.11.2020



https://blackcoinmore.org/


updated article about Dust Attacks
https://blackcoin.nl/a-dust-attack-affected-legacy-blackcoin-clients-in-late-sept-2020/




many thanks to the Devs!

Found some good read ups to the Dust Attack:


https://bitcointalksearch.org/topic/bitcoin-dust-5269771

https://bitcoin.stackexchange.com/questions/193/how-do-i-see-the-ip-address-of-a-bitcoin-transaction#:~:text=The%20blockchain%20doesn't%20store,down%20by%20some%20other%20means.&text=The%20Bitcoin%20protocol%20does%20not%20record%20this%20information%20by%20itself.





And most important is BIP 78

https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki


Motivation

When two parties (later referred to as sender and receiver) want to transact, most of the time, the sender creates a transaction spending their own Unspent Transaction Outputs (UTXOs), signs it and broadcasts it on the network.

This simple model gave birth to several heuristics impacting the privacy of the parties and of the network as a whole.

    Common input ownership heuristic: In most transactions, all the inputs belong to the same party.
    Change identification from scriptPubKey type: If all inputs are spending UTXOs of a certain scriptPubKey type, then the change output is likely to have the same scriptPubKey type, too.
    Change identification from round amount: If an output in the transaction has a round amount, it is likely an output belonging to the receiver.

We will designate these three heuristics as common-input, change-scriptpubkey, change-round-amount.

The problems we aim to solve are:

    For the receiver, there is a missed opportunity to consolidate their own UTXOs or making payment in the sender's transaction.
    For the sender, there are privacy leaks regarding their wallet that happen when someone applies the heuristics detailed above to their transaction.

Our proposal gives an opportunity for the receiver to consolidate their UTXOs while also batching their own payments, without creating a new transaction. (Saving fees in the process) For the sender, it allows them to invalidate the three heuristics above. With the receiver's involvement, the heuristics can even be poisoned. (ie, using the heuristics to intentionally mislead blockchain analysis)

Note that the existence of this proposal is also improving the privacy of parties who are not using it by making the three heuristics unreliable to the network as a whole.

15% * 60m blk = 9m minting blk
9m blk / 500 = 18k blk max split size

significiantly lower than 18k blk, at least the half or better a quarter.

Lets see.. We actually have 60 million coins. And normally around 15-20% is used for staking. How does this effect your calculation?

edit: 500 blocks for a stake to mature and 67 seconds block interval

My calculation on this topic.

A successful mint matures for about 10 houres. With one minute medium block interval it's 600 blocks in total. After 600 blocks they can mint again.

We have a total of about 77 Million coins. If they would mint alltogether in an even way, the absolute maximum fragment size would be 77.000.000 blk / 600 = 128.000 blk.

Not all are minting, of course, and some coins get lost, so the optimal split size should be much lower than 128k. To be cautious, one could double the size from time to time until it fits. So the devs could double the split size from 1k blk to 2k blk on a next release.

Regarding this and the attack, not only the processor load is affected, but the resident memory load too.

On many PoS coins the processor load rises on small transaction sizes. If this is not the case with blackcoin, it's ok then. If the load is an issue, then the fragment size could be ten times larger, between 5000 and 10000 BLK.
[/quote]

So, it is true that the processor load rises on small transactions. But as far as I know, the staking process is single threaded. But it is a very good question, and if you want you can try different stakecombine or stakesplit configurations. There is the possibility, but it is currently hardcoded in the code.
You would need to alter the code and compile it yourself (or send an PR on Gitlab and we can compile it for you)

the code is here
https://gitlab.com/blackcoin/blackcoin-more/-/blob/master/src/wallet/wallet.cpp#L50

and from here on
https://gitlab.com/blackcoin/blackcoin-more/-/blob/master/src/wallet/wallet.cpp#L801

We are currently trying to combine inputs, so it will always contain an x amount of dust txs. (lets say 100 inputs <= 0.004)

Thanks!
Michel
 
[/quote]

This combine could help, but it can only be useful, if the fees/costs for it are less than the fees/costs for the attacker.

I testet to combine by hand, but the fees for it are much higher than the input.
[/quote]

A Coinstake transaction doesn't have fees, but it only happens when you win the stake

example:
https://chainz.cryptoid.info/blk/tx.dws?8753783.htm

This combine could help, but it can only be useful, if the fees/costs for it are less than the fees/costs for the attacker.

I testet to combine by hand, but the fees for it are much higher than the input.

Hi, thanks there is progress to the dust attack. Since my first post it stopped for some days but now the attacks are back, daily.  Wallet size bloasts up and working time too.

Therefore i kindly ask how far is the progress with the upcoming 2.17 More release?

thx





More can be downloaded from https://blackcoinmore.org

Thanks

So, it is true that the processor load rises on small transactions. But as far as I know, the staking process is single threaded. But it is a very good question, and if you want you can try different stakecombine or stakesplit configurations. There is the possibility, but it is currently hardcoded in the code.
You would need to alter the code and compile it yourself (or send an PR on Gitlab and we can compile it for you)

the code is here
https://gitlab.com/blackcoin/blackcoin-more/-/blob/master/src/wallet/wallet.cpp#L50

and from here on
https://gitlab.com/blackcoin/blackcoin-more/-/blob/master/src/wallet/wallet.cpp#L801

We are currently trying to combine inputs, so it will always contain an x amount of dust txs. (lets say 100 inputs <= 0.004)

Thanks!
Michel
 

On many PoS coins the processor load rises on small transaction sizes. If this is not the case with blackcoin, it's ok then. If the load is an issue, then the fragment size could be ten times larger, between 5000 and 10000 BLK.

How can I rise the fees in blackmore?

I found it!
https://blackcoin.nl/we-are-asking-all-nodes-to-raise-the-optional-fee-rate-to-prevent-dust-attacks/

Thanks, this helps a lot.

I'm using blackmore v2.13.2.6 on ubunto 18.04 LTS for some weeks before the attack. Last days I migrated from the old wallet to a new one to get rid of the dust, but the attack persists as described. The attack leads to a heavy processor load until the wallet process disrupts or forks. So it's not only the legacy client, but the more client too.

Dumping and restoring private keys makes no sense, because the dust is persisting.

Sounds sensible, staying current protocol on any blockchain improves security and ultimately helps the coin long term prospects and they'll always be someone trying to cause trouble of some sort especially for personal gain.    Good to see a plan to counter the transaction abuse being made possible, hopefully people will realize its needed and be 'awake' enough to update their clients as everyone is part of the network in proof of stake system.

It is important that people upgrade/migrate to Blackcoin More v2.13.2.6 and (optionally) raise the fees to avoid relaying these transactions. We will have to raise the fees in the next version to mitigate these attacks

Next More version will be v2.17.0 and is based on BTC Core code 0.17.

More can be downloaded from https://blackcoinmore.org

Thanks

It is not the staking that leaves a lot of the dust. The wallets that are staking are being attacked with dust transactions.

The Blackcoin network is being attacked with spam/dust

check out this post
https://blackcoin.nl/a-dust-attack-affected-legacy-blackcoin-clients-in-late-sept-2020/

thanks

Can you give an example how that would like?

thanks

Staking leaves a lot of dust in the blockchain, consisting of many 0.00005500 BLK parts.

Is there any possibility to configure a stakecombine or stakesplit?

https://blackcoin.nl/a-dust-attack-affected-legacy-blackcoin-clients-in-late-sept-2020/



Those dust attacks still going on, now in October 2020 daily.
It's bloating up the wallet.dat and therefore consuming more and more RAM.

here's an article about BTC dust attacks:
https://www.coindesk.com/dust-attacks-bitcoin-wallets

what is interesting that it's used to de-anonymize ppl's addresses




a solution is to raise the txfee


https://blackcoin.nl/we-are-asking-all-nodes-to-raise-the-optional-fee-rate-to-prevent-dust-attacks/



hope we can have a discussion about that and if possible better solutions to identify the attacker