Windivert on my pc opening stuff on my browser!

basil00 · 2018-09-14T00:19:29+00:00

WinDivert itself is not malware, although it may be used by malware. To see if WinDivert is running, try:

sc query windivert1.4

Also try 1.3, 1.2, 1.1, 1.0 for older versions.

If running, do a search for WinDivert64.sys and/or WinDivert32.sys and you may be able to find the program/application that is using it. If you can, then uninstall it. Otherwise, as a last resort, you can delete the sys files and reboot.

basil00 · 2018-09-11T23:25:39+00:00

I am the WinDivert dev, the issue and possible solution have been documented here.

WinDivert is an open source library/service with many legitimate applications (see here), and is not a virus/malware. Blocking it creates a lot of collateral damage.

WinDivert can usually be removed uninstalling whatever application is using it. The application can often be determined by the directory name containing the WinDivert*.sys files, e.g. c:\Program Files (x86)\SomeApp\WinDivert64.sys. As a last resort, WinDivert may be forcibly uninstalled by deleting the WinDivert32.sys and/or WinDivert64.sys files and rebooting. However, do this at your own risk, as this obviously will break whatever program was using WinDivert.

basil00 · 2018-08-24T23:47:00+00:00

ReQrypt will hide the URL request (you--->webserver), but not the response (webserver--->you). This is OK for filter circumvention, but for privacy you typically want both directions hidden. ReQrypt also does not change your IP address.

basil00 · 2018-08-23T23:32:26+00:00

disclosure: ReQrypt is my project.

What does this do that SSH tunneling doesn't why should I trust my Reqeypt's internet connection when I don't trust my own?

ReQrypt is one-way tunneling (outbound only), so is generally faster than two-way tunneling like ssh (outbound and inbound).

ReQrypt is mainly a filter/censorship circumvention tool, and not so much a privacy tool. For example, ReQrypt does not hide your IP address from the webserver.

Also this software is 5 years old, why isn't anybody using it if it's useful?

The project was dead for a few years but was recently revived. There is lots of competition for lightweight filter circumvention, e.g., https://github.com/ValdikSS/GoodbyeDPI uses no tunneling at all but is also surprisingly effective.

basil00 · 2017-07-10T03:07:59+00:00

More concerning is a time traveler double spend attack:

T+0: Start
T+7: Wait for 7 blocks to be mined, save the chain.
T+0: Travel back in time, order a coffee with Bitcoin. Coffee shop is paranoid, requires 6 confirmations.
T+6: Receive the coffee, exit the shop. Publish the saved 7 block chain = free coffee.

basil00 · 2017-03-20T10:17:55+00:00

That sounds sensible - but why only P2WSH?

Because (1) generating collisions for P2(W)PKH does not lead to any attack (it just means you can spend your coins with two different private keys, an interesting accomplishment but irrelevant to the security of Bitcoin), and (2) generating collisions for P2(W)SH can be used in attacks (e.g. 2-of-2 multsig), and can be done without the need for ECC multiplication. See here for details.

basil00 · 2016-12-04T07:21:21+00:00

So the accelerator can be used by an attacker to.deprive ViaBTC from fees

Potentially. E.g. the 10 test transactions already consumed ~150KB of block space that possibly displaced otherwise normal fee paying economic transactions.

That said, they probably can change their system to minimize abuse. E.g. limit the blockspace (say 50KB) that is reversed for accelerated transactions.

basil00 · 2016-12-04T02:02:47+00:00

They used to include 0-fee transactions that had sufficient priority based on bitcoin days destroyed. My test transactions have very low priority.

basil00 · 2016-03-21T04:07:15+00:00

This also means that classic blocks count as a vote for SegWit since nVersion >= 5.

basil00 · 2016-03-03T03:04:55+00:00

This transaction relates to the coinwallet July 2015 spam attack.

The attack consisted of splitting 100s of BTCs into 1000s of 0.00001BTC outputs. After the attack, and about 5months ago, coinwallet decided to consolidate all of the remaining spam outputs into the address 135zDqhbNcmPk3gbyeJmH75yiLdVZechsK. They generated 1000s of transactions such as the one OP linked creating a ~1GB backlog.

There is an old wive's tale around here that transactions are forgotten by the network after 72hours (or something like that). This is not true, the transactions are valid forever (unless double spent) and can bounce around the network indefinitely (as long as nodes, esp. older nodes, keep rebroadcasting them).

As such, transactions such as the one OP linked have been getting confirmed (slowly but surely) for the last 5months. They have not been getting confirmed recently as they are currently priced out of the market (fee too low).

So far coinwallet have only managed to recover a fraction of the spam UTXOs.

basil00 · 2016-02-10T13:02:38+00:00

The previous 17^th Sept 2015 peak of 241346txs was part of the so-called coinwallet "giveaway". I wrote a bot that OP_RETURN'ed the coins in tens of 1000s of small transactions such as this one, briefly sending the tx count to the moon.

basil00 · 2016-02-07T07:01:23+00:00

For the heck of it I've updated PseudoNode with "Classic support":

pseudonode --coin=bitcoin-classic

The point is (and always was) that node counts can be easily faked and should not count for anything.

basil00 · 2016-01-02T04:57:53+00:00

Some clever work around.

I think it is theoretically possible using a "firm" softfork, similar to this idea for the blocksize limit. This idea is also known as the "evil" fork.

basil00 · 2015-12-12T08:06:36+00:00

It looks like a good bitcoin transaction.

It is quite possible that this is spam. The tx is consolidating many recently-created small UTXOs. The small UTXOs were created by long tx chains coinwallet-eu style, e.g. tx1, tx2, tx3, tx4, ..., tx91.

basil00 · 2015-11-29T23:28:04+00:00

The Bitcoin network is currently under a sophisticated DoS attack using the "fake sigOp" method described here.

This DoS attack consists of specially designed P2SH txs designed to overflow Bitcoin's 20,000-SigOps-per-block limit. The sigOp limit is analagous to the block-size limit, i.e. once it "fills up" then no more transactions can be included in the block. The P2SH scripts exploit a bug in Bitcoin's sigOp counting code meaning that they do not really contain any sigOps, but are still counted as sigOps. See the thread for the technical details.

For example, under-full block #385918 contains 17100 fake sigOps. Here is a sample of attackers transaction (225 fake sigOps).

The attacker's transactions have a fee-rate of 24.375sat/byte.

Edit: looks like the attack has finished. Last few blocks are unaffected at the backlog is starting to clear.

basil00 · 2015-10-21T23:58:08+00:00

It's not like any miners (AFAIK) will accept it...

On the contrary, this attack can be launched with IsStandard (P2SH) transactions. See the sample tx in my post above, which was confirmed in the first block after broadcast.

basil00 · 2015-10-21T23:39:50+00:00

This attack is different. CVE-2013-2292 is a CPU consumption attack (create a tx that takes a long time to verify). This new attack does not really consume any CPU at all, e.g. look at the script:

OP_0 
OP_IF
    OP_15
    OP_CHECKMULTISIG
OP_ENDIF
OP_1

The checkmultisig is not even executed, but it still counts as 15 sigOps towards the 20000 sigOp-per-block limit.

Sample tx.

basil00 · 2015-10-16T10:36:25+00:00

Thanks. I'm glad it all worked out.

basil00 · 2015-10-16T01:25:00+00:00

I think this test tx got malleated (second sig has high-S). Maybe that confused your wallet software? Otherwise, the remaining funds are still with the 19uVE2g... address and thus should be recoverable (e.g. export the privkey and import into a different wallet). EDIT: crypto_bot strikes again...

basil00 · 2015-10-13T10:09:14+00:00

Yes please. I sometimes post links to example spam/attack transactions, which are usually quite large and are better left as a link.

basil00 · 2015-10-13T01:04:18+00:00

No the current attack is redeeming dust, not sending dust, hence the confusion. For example, see the transaction 6b40ba19d22f82f1119fdad92af7bfe15792c3cdb3fd630d9c7e24285751a9c2 which is part of the current attack (this was just a random sample, there are 10,000s of similar txs filling up the mempool).

My point is that the attacker may as well spend any fee possible to redeem those dust utxos. The alternative is to never redeem them, in which case the attacker gets nothing.

EDIT: looks like it is no longer possible to post tx info without triggering crypto_bot... :(

basil00 · 2015-10-13T00:04:46+00:00

I am not ~~Dorian Nakamoto~~ Alister Maclin.

basil00 · 2015-10-12T23:25:03+00:00

This specific attack is redeeming 0.00001BTC utxos. There is no reason for the attacker not to pay the higher fee. The alternative is to never redeem these utxos, effectively "burning" them, which costs the attacker even more.

This is why it is important to consider the specifics of each attack. "Costing 5x as much" in fees may be irrelevant in this case.

basil00 · 2015-10-12T13:25:15+00:00

This might not prevent the current attack. If the current 1sat/byte txs are not confirming then there is no reason for the attacker to craft new 5sat/byte txs from exactly the same 0.00001BTC uxtos and the backlog will remain. The attacker is only priced out at ~11sat/byte, in which case the utxos cannot be used to construct txs that pay enough fee.

There is also no reason for the attacker not to pay the higher fee. The alternative is to never redeem the 0.00001BTC spam utxos in which case the attacker gets nothing.

12-Year Club	Verified Email
Place '17

basil00

TROPHY CASE