Bitcoin Forum
October 19, 2018, 10:11:25 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 ... 238 »
1001  Bitcoin / Development & Technical Discussion / Re: How does the protocol broadcast hidden services? on: March 16, 2015, 04:01:28 AM
When the core client runs through Tor and looks for seed nodes. Is DNS still used? And if so, does it go through the Tor proxy too?
DNS can't simply be used over Tor. What it does is it "connects" to the DNSseed names like they were regular peers and gets addrs from them and disconnects, causing the tor network to do the dns resolution and randomly select endpoints.  It's not great.

I don't think that Bitcoin Core does this, though it might be a good idea.
There is an open PR on making it use separate tor circuits to reduce the incidence of using the same exit node (but not preventing it: there isn't a way to prevent it without having a very low level interface with tor, AFAIK).  I think we previously got sidetracked with discussion on how to avoid breaking non-tor proxies. (The way you get different circuits for different connections in tor is to send different usernames; which doesn't work so well if you're using a non-tor socks proxy and it won't accept a username). I'll be in the next release in any case.
1002  Bitcoin / Development & Technical Discussion / Re: Row Hammer on: March 16, 2015, 03:55:15 AM
One thing I really liked was intECC DRAM chips: DRAM which is pin-compatible with the current non-ECC DRAMs but internally uses ECC. This will allow many people to preserve most of their hardware investments (mostly laptops) by just replacing the DRAM modules.
Progress is progress, perhaps that'll convince the cpu/chipset makers to stop price discriminating on ECC capability. That said-- internal ECC doesn't protect the data on the bus or in a number of failure points along the way, so it's not a complete replacement.

It's also, from what I've seen, not clear how much protection ECC actually provides... all data covered by the protection is in the same domain for row aliasing, and typical protection only provides single error correction; soo...

Ever since the first paper on this subject was published I've been running hosts doing anything important with overspec memory running underclocked, as an additional mitigation. A couple percent performance isn't worth any risk of corruption.
1003  Bitcoin / Development & Technical Discussion / Re: How does the protocol broadcast hidden services? on: March 15, 2015, 09:19:52 PM
If you don't do this, then Bitcoin will still work through Tor, and you might automatically make outgoing connections to hidden services, but you won't get any incoming connections. Bitcoin doesn't set up a hidden service for itself automatically.
Yep. Just so.

It can't setup a hidden service for itself. We've asked the tor project for some kind of ability to control HS setup from socks and/or the control port and they have a feature request for it (and have for a number of years), but it isn't there yet.

Same reason you need to tell bitcoin what your onion address is: there is no way for Bitcoin to find out on its own... only systems with effective access control (e.g. stock tor install on most Linux distros) it can't even read the relevant files to go find out for itself.

The file doc/ included with Bitcoin Core describes the settings.

Once set up it will do automatic discovery just fine. There is no need to use that fallback node list on the Bitcoin wiki ever.
1004  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 14, 2015, 03:34:50 AM
is there some reason the base client isn't using epoll?
Not portable by itself, and real no reason to use it: running large numbers of connections isn't good for the goodput of the network (data crosses in flight more often the higher the number of concurrency connections), makes the node more vulnerable to a number of DOS attacks, and burns external resources (esp if they're used to make outbound connections). Shipping that would just make the lazy abusive users even more abusive, and I've seen plenty of evidence to suggest that it would cause harm. So that takes it from low priority (no need, a pain to do portably) to basically negative priority.

We'll probably do so eventually but I would expect it to come after some much more powerful anti-abuse tools.
1005  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 13, 2015, 11:54:46 PM
You seem to be rather insecure about my remarks about Tor, Bitcoin and so forth.
Huh? Whats with the ad homenem?  You're making objectively incorrect statements, the result is a web of FUD that would mislead people into making poor choices.   Linking to a bunch of things totally unrelated to this discussion is a weird strategy-- no one in this thread disagrees that anonymity (or more importantly, simple privacy) is important. That question hasn't even come up. That it is important doesn't justify or legitimize making a incorrect claims about it.
1006  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 13, 2015, 10:08:28 PM
"Warning: Use of Tor and Bitcoin together may result in additional attack vectors that could compromise your privacy. Do you wish to proceed?"
This warning is incorrect for Bitcoin.  The risks described are that it may be somewhat more vulnerable to DOS attack. For wallet users the only consequence is that it might not work and, if they're in a hurry, they might choose to turn off tor and end up with the same non-privacy they would have had if they had not used Tor.

OpenBazaar is offtopic in this thread.
1007  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 13, 2015, 09:25:14 PM
On the TOR point specifically, numerous studies have been done that have revealed problems involving the use of TOR and bitcoin in combination, leading to vulnerabilities that have not yet been mitigated.
Your comment is confused and misleading.

The "problems" reported initially is that an attacker can DOS attack to cause IPv4 nodes to block nodes behind Tor. This is true, but we were always aware of that and implemented hidden service bitcoin nodes as a tool to improve that. The paper was revised to also point out that you could concurrently DOS attack hidden service nodes-- which is generally true with or without tor, but there are not as many HS nodes.

The end result of all that though is just a DOS attack. Maybe if an attack happened, which isn't currently happening, you might have problems getting a new connection after starting your software.  This is completely safe, it might be irritating but your privacy would not be compromised unless you took the affirmative (and obviously foolish) action of disabling Tor support in your wallet.

None of this is a reason to not use Tor-- it's a reason, among _many_, that Tor doesn't solve all possible problems but you lose nothing by using it.  It's harmful to the community for you to promote otherwise.
1008  Bitcoin / Development & Technical Discussion / Re: Possible security issue in wallet.dat encryption on: March 13, 2015, 08:54:21 PM
This is the reason that setting the passphrase forces a shutdown. Bitcoin core completely rewrites the wallet and deletes the old file.

Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.

This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
1009  Bitcoin / Development & Technical Discussion / Re: How to automatically create a bootstrap.dat file on a node on: March 12, 2015, 07:27:08 PM
This will not (reliably) create a valid bootstrap.dat.

A valid bootstrap.dat contains no orphans (block files contain orphans) and will have all the blocks in order (blocks in block files may be out of order).

There is a script included with bitcoin core called that is used to create bootstrap.dats.

Also, blocks themselves are self authenticating, there is no need to 'verify' as you've described.

Though with 0.10+ the marginal utility of a separate bootstrap.dat is low-- if you include the time it takes to download one it often slows down your synchronization time now.

1010  Bitcoin / Development & Technical Discussion / Re: Changing the block reward reduction to happen per block rather than one day on: March 12, 2015, 08:23:03 AM
And most people were mining for the fun of it at home.
This isn't at all an accurate reflection of how mining was, how weird and distorted things our view of the past is. Go count up the hashrate at that point in terms of ordinary GPUs (and a significant fraction of it was FPGAs)... mining was very much industrialized then.

By making the reward decrease more frequently you increase the points where it locally more profitable for a miner to orphan the prior miners block than it is to extend it.

This idea has already been alpha tested
by other things which have had serious, network ending flaws over and over again, which for the most part haven't been attacked.  Anything is secure if no one cares to attack the thing its protecting. Smiley

Could quite possibly be a shock event where the hashrate may drop dramatically.  Opening up the network to an attack event a lot easier and cheaply
A "shock event" that people have known about for years? I think you must have a weird defintion of a shock event. Indeed, the hashrate may go down-- it's gone down this year, in fact, but this itself doesn't magically make the network any more open to attack then it would be if the reward changed slowly and ended up with the same difficulty.
1011  Bitcoin / Development & Technical Discussion / Re: Distribution of nonce values on: March 11, 2015, 11:32:09 PM
I set out to test the claim: "Every nonce has an equal chance of winning."

The test that you've performed is also not a test of that claim.

Consider, assume that every nonce were equally likely to be a solution. Now also assume everyone looking starts at zero and increments.

What distribution would you expect to see after the fact? How would that distribution change as the probability of a hit changes?
1012  Bitcoin / Development & Technical Discussion / Re: Sending bitcoins without miner fees on: March 11, 2015, 09:59:57 PM
The minimum fee required for send a tx in the new bitcoin core is 1'000 satoshi,
This isn't true.  Transactions can happily be sent, relayed, and mined with no fee at all in Bitcoin core, if they have enough priority.
1013  Bitcoin / Development & Technical Discussion / Re: Protocol or Paper for Joint Random Secret Sharing (JRSS)...? on: March 11, 2015, 08:04:25 PM
To extend this to a t of n case they must make sure that each and all of the possible subsets of t signers hold the same multiplicative secret. I can see how this could possibly be done with a dealer but I canít understand how it is done without a dealer.
Of course this could just be due to my lack of understanding but I reserve the right to keep asking stupid questions in order to try and improve my understanding. Smiley
I don't see it either, except by repeating the process for each of the the m choose n satisfactions; which you can't do for a single secret without a dealer. Thats why I was asking in the other thread where this was implemented when someone said it was.
1014  Bitcoin / Development & Technical Discussion / Re: new paper: Securing Bitcoin wallets via threshold signatures on: March 10, 2015, 02:49:36 AM
The source is here:

They've eliminated the trusted setup requirement.
Hm. I cannot find the distributed setup in that source code.  Can you point me to it?
1015  Bitcoin / Development & Technical Discussion / Re: Quick elliptic curve security question on: March 09, 2015, 12:03:58 AM
Do take care that because your one more discrete log problem is secure doesn't mean that any larger system you embed it into is secure.
1016  Bitcoin / Development & Technical Discussion / Re: BIP 32 questions on: March 08, 2015, 09:51:09 AM
Another way to convert your custom string into an electrum wallet is to do a sha256sum md5sum of it. If you are on a nix system:
It's really really inadvisable to do this, short human generated strings have very low entropy even (or especially) when you think you're being clever about it. Many people have lost substantial amounts of Bitcoin this way.
1017  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 07, 2015, 10:59:52 AM
well I have a maximum of 3100 file descriptors on my system.
Select has a maximum of FD_SETSIZE (1024) FDs in use, and you will end up totally screwed up if you are beyond that. It doesn't matter what you've set your ulimit to.

When you run hacked up versions that which changes that you do not understand you waste everyone's time (including yours), and you provide bad service to other nodes. I shouldn't have to read between the lines to troubleshoot your private code based on the subtle implications of your offhand comments.

maybe some session hijacking method is used to set up a connection from an unsuspicious (but also malicious) node and then taking it over by one of the nodes with some TCP session hijacking method.
This would be pointless. If you are both hosts A and B, why bother having B pretend to be host A?   Also if you were having B pretend to be A your host would still think it was connected to A even if it were now B talking.  I'm doubtful any retail hosting provider of any scale is failing to run URPF these days in any case, since they'd constantly be a source of DOS attacks. Smiley

All that aside-- even ignoring what looks like some broken behavior in your node, this is moderately concerning.  What it looks like to me is a rather ham-fisted sybil attack trying to trick nodes into leaking private data to them, the nodes seem to fail to relay transactions too which hurts performance some-- it may even completely disrupt some less sophisticated wallets that don't have any protection against multiple output connections to the same /16. The Bitcoin protocol, when implemented correctly, has a degree of sybil resistance when it comes to partitioning and double-spend risk as an attacker must get _all_ your connections for those attacks, but this kind of activity can really violate user privacy since privacy attacks don't need to get all your connections; especially for SPV nodes which liberally broadcast their wallet addresses to nodes that they're using as servers.

We've been working slowly on some improvements in this space in Bitcoin Core but Bitcoin community (outside of core devs) interest level is pretty low, and due to not being SPV Core already has much better privacy. (In general I've be disappointed by how few people realize how important privacy and fungibility is for Bitcoin's viability as a currency).  It's not as simple as just blocking them (though you're free to do that yourself), as blocking on a global basis (instead of each user deciding for themselves) has significant collateral risk and would be easily evaded by anyone who thought it was okay to breach normal network behavior to violate user privacy in the first place; and then you have even less information about the attack.  Making it so the attack is harder to see doesn't make it go away.

This is also a reminder to always use tor with Bitcoin 100% of the time (and to use a full node if you can), as that reduces the incentives to pull this kind of stunt.
1018  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 07, 2015, 01:26:52 AM
Latest Bitcoin Core with 2000 connections allowed
2000 connections is not possible, you'll run out of file descriptors. If you edit the code remove the limits you'll end up with arbitrary memory corruption.

The code that limits outbound counts to one host per /16 is trivial, it's in net.cpp:1207.   Can you please get a getpeerinfo on the effected host while the naughty peers are connected and send me the diff with whatever changes you're running?

What happens if a malicious node is connected "outbound", then It disconnects itself, adds an inbound connection from itself, and uses "GETADDRS" to create a subsequent connection to the same subnet? This way it could slowly fill the connection list with inbound connections from itself?
Nothing?  Outbound and inbound connections do not compete with each other. You will still be limited in the number of outbound connections you have to a single /16.
1019  Bitcoin / Development & Technical Discussion / Re: Is someone monitoring large parts of the network? (evidence+firwall rules) on: March 07, 2015, 12:41:55 AM
What I noticed is, that the seed nodes (from time to time) return dozens of bitcoin addresses from the same subnet (from france).
Can you clarify what you mean by "the seed nodes". Do you mean DNS seeds?  Returning how? Need more details!

Edit: Okay, I see is returning a single 46.105/16 to me. Is this what you're referring to?
1020  Bitcoin / Development & Technical Discussion / Re: Slowing down block propagation on: March 05, 2015, 05:27:31 PM
e.g. 1MB block 0% haircut, 10MB block 10% haircut, 1000MB block 95% haircut.  Some polynomial could determine the formulae.
Diminishing fees doesn't work in the long run, as fees can be paid out of band. An alternative that has been proposed is adjusting the difficulty, though this only allows small adjustments.
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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 [51] 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 ... 238 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!