I know

In theory it should not be difficult provided money incentives are there.

Kristov Atlas identified sybil attack on the mixing parties as a possible weakness when he did his review.

Back then the count of mixing parties were 2, to increase speed. But 2 is very easy to identify the other party. So mixing parties got up to 3 to fix that. But 3 is still low and can be sybil-attacked. All one has to do is run multiple sybil-mixing-parties bots, all day long, to "catch" those mixing. The cost of doing so would be in the fees paid to do all the mixing. Now, if you have this thing running all the time, at some point you'll catch someone who is mixing alone and you can pretend to be all his other mixing partners. At that point you have verifiable evidence that at least one tx got deanonymized. Your bounty prize will easily exceed the fees paid.

Sybil attacking the mixing parties is much cheaper than sybil attacking masternodes. And this needs fixing.

Now send me the bounty

Aha. I'm under the impression that one needs txindex if they are going to swap wallets (which I do) and avoid reindexing (?).

But still, is the writing even necessary when launching and it does the 0-100%? I mean nothing has been downloaded since the last time the wallet was switched off, so it should be dominated by read-only operations.

If the writing can't be avoided, but it involves the same few files changing internally over and over, perhaps these changes could be done in RAM and then written to disk once (?).

Just throwing ideas on the table. If, as you say, there is potential for improvement, that's -in a sense- good news. The bad news start when there are no ideas on how to get further improvements

That's great news.

If you are going to do speed improvements for 0.14, can you also "profile" or check the I/O, and especially writes. I think there's something doing needless work there and it's also stalling the cpu which is waiting for the I/O to finish.

I have the blockchain on my mechanical disk, and while my connection is just 600kb/sec, if I sync to get the last 3-4 days (-blocksonly), this is generating a near constant 10-13mb/s read, and a 11-14mb/s write. Obviously my question was "wtf is it writing?" If I use full indexing support in the filesystem, and since writes have to be performed x2, speed goes down to a crawl.

I initially thought its a flushing issue or something... I was like "ok, if I'm 4 days behind, that's at most ~570mb... can't this be loaded entirely into RAM and then flush it in the end in some kind of batch change to avoid all these writes which kill I/O speed and slow down my sync? It would take just 4-5 seconds in the end..."

I started searching the source files for any file with "flush" and I found some parameters in main.h... So I did some changes in the main.h flush times in lines 97 and 99 (multiplied the defaults x100) but didn't have any obvious effect.

Then I realized that of course it wouldn't have any obvious effect because it's doing something else. With 600kb/sec download, the 11+ mb/s in writes are not the blockchain getting downloaded. It's some other process of rearranging files, writing undo instructions, writing logfiles etc.

So I left it for a few hours and I launched it a few minutes ago to sync the last 10 hours. I now noticed that there were 5-11mb/sec writes going on even in the phase where the bitcoin-qt launches and does the 0%-100% verification, and without having downloaded any extra blocks.

By doing an lsof -p 7464 (bitcoin-qt pid), I get that that the following files are loaded with write or exclusive write attributes:

bitcoin-q 7464    15uW     REG              254,1        .bitcoin/.lock
bitcoin-q 7464    16w      REG              254,1  .bitcoin/debug.log
bitcoin-q 7464    17w      REG              254,1       .bitcoin/db.log
bitcoin-q 7464    18w      REG              254,1      .bitcoin/blocks/index/LOG
bitcoin-q 7464    19uW     REG              254,1        .bitcoin/blocks/index/LOCK
bitcoin-q 7464    20w      REG              254,1     .bitcoin/blocks/index/003446.log
bitcoin-q 7464    21w      REG              254,1     .bitcoin/blocks/index/MANIFEST-003444
bitcoin-q 7464    22w      REG              254,1   .bitcoin/chainstate/LOG
bitcoin-q 7464    23uW     REG              254,1        .bitcoin/chainstate/LOCK
bitcoin-q 7464    24w      REG              254,1       .bitcoin/chainstate/749940.log
bitcoin-q 7464    25w      REG              254,1   .bitcoin/chainstate/MANIFEST-749938

...so the culprit is somewhere in there doing way too many writes for apparently no reason (?), or in a suboptimal way (?).

I also tried dbcache settings of 0 and 1000, they didn't make any difference in making this phenomenon of ~10mb/s writes disappear (whether in the bitcoin-qt launch, or later when syncing).

What is currently named Dash was

Jan 19 2014 to late January 2014: Xcoin
Late January 14 to mid-March 2015: Darkcoin
Mid-March 2015 to today: DASH

You don't need it.

However, if someone wants to acquire large voting power in STEEM, that's when they'd buy a lot of STEEM.

If your next question is why would anybody want a large voting power in STEEM, the answer is that voters with large power can get "curation income" from finding and upvoting good content.

A whale voter might get something like 1-2k usd per day (in steem power) just for voting. But they may need a stake which is in the 6 or 7 digits.

How about 6666.666

Deleting is similar to editing, in a sense. Because you can simply replace all the text with crappy text like ADASDIASFJIFJSADJASDAS. It wouldn't really prevent ragequit/rageprostest-deleting, or hacking vandalism (someone breaks the key of a known author and vandalizes their content).

Once enabled, these type of things might happen. So, at that point, having an option to display older revisions, like Smooth said above, could work. It would be like wikipedia, or the archive.org snapshots of the same page, over different periods.

Centralized-type approval would probably introduce many issues. The moment you centralize content control you also become more vulnerable to government intervention. The less content control there is, the better.

Imagine a scenario where a "celeb" top-earning author, bags 1000$ per day, and then decides to edit his old posts and remove his content because he had a lame disagreement with someone.

He's now bagged 29-30k over a month for pages that now look like

title: Deleted
content: blank

...I've seen various events like that happen in forums, where members would rage-delete old posts.

The edit window is for the first 24hrs. Then it's fixed for eternity...

666 here we come

=> https://steemit.com/msgivings/@bacchist/is-msgivings-a-sock-puppet-account  

You may disagree all you want but the reality of economics is that if you give the service for free or near-zero, it will attract abuse. And you can label that abuse as "use", to make the case for 10mb or 10GB blocks - which even them can be filled by abuse, and then you will be asking for 10 PB blocks: You implement circular logic, using the maxed transactions as evidence for "we can't have new users", forgetting that one can max out any tx limit if the cost for doing so tends to zero.

Your logic is also provably problematic, because altcoins have actually tried adaptive block sizes where the block just grows with use - and guess what happened.... Abuse happened. It started growing and growing in tx count, and then the blockchain was getting more bloated and more bloated, and guess what was the reaction... Minimum fee was raised. A LOT. So, in the end, while block size was "infinite" to cover any demand, in reality it was just only serving top-paying customers to keep bloat to a minimum and prevent spamming.

If the block has ample size for txs and if fee tends to zero, abuse will tend to max block size - just because some random hacker or script-kiddie wants to do that. You either implement a minimum fee threshold and larger sizes, or you let a block size that is ok for the market demands and allow a level of abuse with free/near-zero fees (like we have right now).

Has the thought occurred to you that all these problems "appearing" to prevent you from coding, may be of your own subconscious desire to self-sabotage yourself, for some reason that is consciously un-acknowledged (and will probably require some soul searching)?

Give it some thought (no need to share the answers - these are personal stuff).

Because some blocks are 1mb and some are less for whatever reasons the miners want.

Btw, it seems to have stabilized since May with a few spikes up and down: https://blockchain.info/charts/avg-block-size?timespan=1year

Yeah I think "average" is exaggerated. No it's not average behavior, indeed. It's gaming behavior like the one we had around a month ago.

There was an initial surge in comments and you could see people were trying to game it. There were bots making automated "conversation", there were human bots writing something like "wow very helpful!!!", there were people who didn't even read what you wrote and commented something that was irrelevant or half-relevant (some still do it), there were people who were posting (intelligent) comments in a serial fashion trying to make a buck, etc etc.

As rewards dropped and as the flagging threat elevated, it kind of slowed down. There still is some gaming attempted (bots running around and making idiotic comments, or upvoting old posts and saying "upvoted you") but it'll probably slow down further.


Yep...

Even when "blocks are full" and mempool queues are several megabytes long, there are always a lot of transactions served in the near zero cost segment.

He's probably alive and well, but he might have opted for cremation. He wouldn't want followers forming any kind of "religion" around the grave.

Yep, not likely.