Bitcoin Forum
February 20, 2019, 08:38:57 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 [374] 375 376 377 »
7461  Bitcoin / Bitcoin Discussion / Re: Defending Bitcoin against interventionists on: July 09, 2010, 05:12:00 PM
BitCoin already has all the defense it needs: you can't change the core behavior of BitCoin and still be compatible with the "official" BitCoin software.
7462  Bitcoin / Development & Technical Discussion / Re: Anonymity on: July 07, 2010, 06:53:04 PM
I don't know how this is currently handled. It might already be fixed. I haven't looked at the source.
7463  Bitcoin / Development & Technical Discussion / Re: Anonymity on: July 07, 2010, 06:35:21 PM
Everything I mentioned could be user-configurable, and most of it wouldn't slow down actual transactions. Even if you had all of these security features disabled, just having them implemented would give you plausible deniability in certain cases.

Block generation would be slowed in the case of a network split, so executing a double-spend would be even more difficult. I was thinking more of a problem like the Cogent-Level3 peering dispute, where there is no path between two ISPs for a long while. In this case, lots of transactions would be lost when the network is recombined and one of the chain's branches is discarded.
7464  Bitcoin / Development & Technical Discussion / Anonymity on: July 07, 2010, 04:54:44 PM
The current BitCoin implementation is certainly better than using a credit card, but I wouldn't use it in environments requiring strong anonymity without a lot of changes.

The history of a coin is publicly available. Anyone can see the flow of BitCoins from address to address.



This becomes a problem when certain points in the "transaction chain" become known to the attacker. In the image below, the attacker controls both the source of Mr. Doe's BitCoins and the destination. Since Doe bought his coins using non-anonymous methods, he is easily identified. His identity is tied to an address in the transaction chain.



A more likely scenario is for your BitCoin balance to come from transactions made over insecure channels (email, this forum, etc.). If you're particularly careless, the destination can just Google all of the addresses in the transaction chain. Maybe he'll find that one of them is in your forum signature here.

I've thought of two ways to make this harder. The first is to randomly send your coins to new addresses that you've generated just for this purpose. The coins are still part of your balance, but it's impossible for an outsider to prove that you sent the coins to yourself instead of a real person. However, the transaction chain still has your identity in it. In a real investigation, you would be targeted for close examination because you either know (directly or indirectly) the real person who is under investigation, or you are that person.



The second way is for an external service to take the coins of many different people, mix them up, and send similar amounts back to those peoples' addresses. If the mixer keeps no logs of who gets which coins, any investigation must stop here.



For maximum security, BitCoin should have the capability to automatically send coins through several external mixers. Assuming at least one of them doesn't keep logs (and all of them actually return your coins), this should keep you completely safe.

There's a problem with safely coordinating all of this. You want all of your coins to be mixed at least once, but keeping track of this in a database will ruin your plausible deniability. Probably you'd have to initially keep track, but then delete the database after all the coins have been made safe.

Unrelated to the chain issues above, BitCoin is vulnerable to network analysis. If an attacker can watch all of your incoming and outgoing traffic, he can easily see which transactions are yours. If the connection is unencrypted (as it is now), he can see when you broadcast a transaction that you didn't receive.

Even when encrypted (through Tor or a built-in mechanism), it's not impossible for an attacker to see which transactions are yours if he can see both ends of one of your connections to the BitCoin network.

Your transactions can be identified through Tor like this:
1. The attacker fills the BitCoin network with IP addresses that he controls.
2. When one of these "evil nodes" receives a packet, the attacker sees if it was received close to the time when he saw you send a packet. If this happens a few times, the attacker knows who you are and can see your transmissions to the network.
3. When you send a transaction, the attacker knows it's yours if you send it without receiving a packet in a while.

To fix this, BitCoin should implement encryption, padding (to prevent any size-based identification), dummy packets, and randomization in sending times. Some plausible deniability could also be added if BitCoin could export and import transactions to/from a file (importing would broadcast the transaction to the network, while exporting would not). Then you could transmit this file in other ways (a flash drive, for example).

I also see two structural problems not related to anonymity:
- If the network is segmented at the network layer (because the PoTUS executed his "Internet kill switch", for example), the block chain will be forked. This would be really bad.
- It's very easy for an attacker with lots of IP addresses to fill the network with cancer nodes. I'm not sure how badly BitCoin could be affected by this.
7465  Economy / Marketplace / Re: 1250 BTC for Osmos on: July 07, 2010, 02:36:06 PM
I'll do it for 1600.

I'd have to do the "gift" process, though:
http://www.hemispheregames.com/faq/#buy_gift
We couldn't legally "share" the game.
7466  Economy / Trading Discussion / Re: Money Transfer Regulations on: July 01, 2010, 03:31:45 PM
What country are you in, MadHatter? That sound very different from what (little) I know of US law.
7467  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 25, 2010, 07:18:54 AM
Linux on an overclocked Pentium D:
- 1 core: 565 khash/s, 1.01 kW h/day
- 2 cores: 1100 khash/s, 1.78 kW h/day

The new version seems to give me an improvement of 20-30 khash/s (with two cores) over SVN 80 with laszlo's patch.

Does anyone know what I have to change in the makefile so that I don't have to add LD_LIBRARY_PATH pointing to the dependency libraries when executing BitCoin? I already have -I and -L pointing to the single, correct location. (This isn't caused by the new version; I've always had this problem.)
7468  Bitcoin / Development & Technical Discussion / Re: Dealing with SHA-256 Collisions on: June 14, 2010, 06:09:58 AM
Quote from: lachesis
Wouldn't all the old transactions then be compromised (because they could be trivially recomputed)?

After thinking about this some more, I've realized that breaking the hash function used in blocks would be more disastrous than I had originally thought. But it should still be possible to change the hash function "on-the-fly" by including secure hashes of each real block in the old chain with the new BitCoin release. Some mechanism of doing this (hopefully more elegant) would also have to be used for a gradual hash change.

Quote from: Xunie
Wouldn't the users lose their coins?

Everyone's balance is publicly available, so it should always be possible to preserve this data, no matter what changes are made to BitCoin.
7469  Bitcoin / Development & Technical Discussion / Re: Dealing with SHA-256 Collisions on: June 14, 2010, 02:34:57 AM
I don't think that broken cryptography could ever be the end of BitCoin if it becomes popular. Since the block chain can be forked without losing too much data, modifications to all aspects of BitCoin are possible. If SHA-256 was broken, a new version of BitCoin would be released that would switch to a stronger hash function for addresses. Changing the hash function used for blocks might not be necessary if the weakness still required some non-trivial amount of computation. The new version would ignore SHA-256 blocks after a certain point in time, but most old transactions would survive.

In case the weakening of SHA-256 is gradual instead of sudden (much more likely, IMO), BitCoin could stretch the process of switching to a different hash algorithm over a long time. First accept SHA-512 (or whatever) in addition to SHA-256, then use SHA-512 by default, and finally stop accepting SHA-256 for new blocks.
7470  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: June 11, 2010, 07:55:33 PM
You need to recompile your kernel with support for "owner match support" for netfilter. I was always running into this problem (wanting exotic iptables filters), so I have all of the netfilter modules enabled, even though most of them seem useless to me right now.

I agree that proper authentication would be good, but it's not very important right now. Very few people are running BitCoin on actual multi-user machines, I think.

Quote
if I were root, couldn't I just...

Of course. But packets that originate from the "root" account will still be blocked unless you remove the iptables rule.
7471  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: June 11, 2010, 06:56:41 PM
Try loading the "xt_owner" kernel module.

Quote
Setting the UID to my username will block the packet for everyone but me (and root, obviously), right?

Yes. Root will also be blocked unless you add that user as well.
7472  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: June 11, 2010, 05:06:59 PM
iptables -A OUTPUT -o lo -p tcp --dport 8332 -m owner --uid-owner root -j ACCEPT
iptables -A OUTPUT -o lo -p tcp --dport 8332 -j REJECT
7473  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: June 11, 2010, 04:46:09 PM
You can block it for everyone but your intended users with iptables.
7474  Economy / Trading Discussion / Re: A Heroin Store on: June 10, 2010, 08:34:21 AM
You could build an anonymous trust system by combining some aspects of BitCoin with a web of trust. In this system, anyone would be able to send as many "trust coins" as they want to other identities, but how many of these transactions you view as valid would depend on who you trust in the network. You might say that certain identities can send unlimited coins, while others can send up to 50. No identity would have an objective balance -- the balance would be determined entirely by how you process the public list of transactions.

Example:
-You know Identity A personally, so you allow him to send unlimited trust coins.
-He buys a CD from Identity B. Since it went OK, A sends B 100 trust coins.
-Randomly and over a long period of time, B sends these coins to addresses he controls. It is impossible for an observer to know whether any of these transactions were to real people or not, so B has plausible deniability. (This is clearly more secure if there are more real people between B and you, though.)
-B wants to sell you heroin online. To prove his legitimacy, he tells you one of his anonymized trust addresses. When you enter it into your software, you see that he has a number of trust coins, somehow gotten from your trusted peers (possibly in a very indirect way, but directly in this case).
7475  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: June 09, 2010, 05:41:43 PM
Thanks for clearing that up, fergalish!
7476  Bitcoin / Bitcoin Discussion / Re: Multiple BitCoin clients on same public IP (same household) questions on: June 08, 2010, 05:53:52 PM
Each hash your CPU computes gives you a very small chance of solving a block, which wins you 50 BitCoins. Better CPUs can compute more hashes per second. Doubling the number of CPUs you have generating will halve the average time it takes for you to win 50 coins if they all generate at the same speed. How these CPUs are connected to the network doesn't matter at all as long as they are connected.

To make the best use of network resources (yours and other peers'), one computer should be connected to the Internet and have port 8333 forwarded to it. All other computers on that IP address should be started with "-connect x.x.x.x" to connect only to that one computer.
7477  Bitcoin / Development & Technical Discussion / Re: What is the incentive to collect transactions? on: June 05, 2010, 07:55:40 PM
That's a clever (and very free-market) solution. How does BitCoin currently deal with transactions that aren't published in a block for a long time? Is there any risk of them being lost?
7478  Bitcoin / Development & Technical Discussion / What is the incentive to collect transactions? on: June 05, 2010, 04:26:09 PM
Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?
7479  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: June 05, 2010, 04:21:18 PM
Quote
I wonder if it writes to the debug log when it has success.

BitCoin does say when it has solved a block. Search for "proof-of-work found".

Quote
In Bitcoin, aren't multiple nodes working on the same block?

No. Each node's block is unique because it contains their unique public key. Functionally, every hash gives you a totally random number between 0 and the maximum value of a 256-bit number. If the random number is equal to or below the target, you win. So the probability of winning with one hash is target in max.

Starting on another block because somebody else won requires almost no work.

See the BitCoin Wiki "block" article and the BitCoin paper for more info.
7480  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: June 05, 2010, 03:02:57 PM
The main part of the formula that I'm uneasy about is the "target probability" of 0.5. 0.5 is used for calculations involving brute-forcing passwords, but maybe this is different. If your blocks consistently take double the amount of time that the formula predicts, use 1 instead.
Pages: « 1 ... 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 [374] 375 376 377 »
Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
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!