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

still going!

so is this coin still going?

I used to use it back in 2016.

Thanks for the update.

Hi, People are talking about this, but most of the Blackcoin community activity is on Discord these days. Please join us https://discord.gg/hjNUgWD

It is also not clear how many BLK are on that exchange or if they are already dumped on another exchange, like Bittrex.

I haven't heard of anyone with BLK on Livecoin, but myself. I have a small amount there. (sub 500BLK)

https://www.coindesk.com/livecoin-crypto-exchange-hack

Yet I'm 90% sure that doesn't look like a hack.

can you explain ? thank you.

I guess that nobody is talking about the Livecoin scam and the amount of BLK on that exchange because nobody is interested anymore..

ROFL  Dust Attacker is reading this ANN carefully - we got another fat Attack accounting now 55k Tx dusts - won't touch them motherfcuker

BTW - my wallet staking as usual

 

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.