Bitcoin Forum
March 02, 2024, 11:02:00 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: March 14, 2013, 12:02:00 AM
rPDjQEkxaXuJzhcp3HvYdbPX9ZmJ6YjMjd
2  Bitcoin / Hardware / Re: [Avalon ASIC] Batch #2 pre-Sale Thread on: February 02, 2013, 03:17:09 PM
I'm giving up now. I entered my contact information but walletbit screwed up and I didn't manage to pay.

I hope Avalon will email me and tell me how to pay them.
3  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: May 03, 2011, 07:42:41 PM
In case anyone is interested, here's what I have so far: http://www.flamewars.org/~phil/btcexchanger.git

This is incomplete. I'd hoped to finish the reference implementation and set up a test node before making this available but I've run out of time/energy for now. In fact I haven't worked on this since mid March.

The RPC mechanism and a basic web interface are working, but the backend which actually causes the Bitcoin transactions to take place is missing. I was thinking about using two separate bitcoin daemons with independent wallets for each transaction, to guarantee that the transaction history for the sent coins is isolated from that of the received coins. There should be a way to do that within a single daemon but I doubt that functionality is implemented currently.

Thoughts (and patches Wink) are welcome.
4  Bitcoin / Mining / Re: New mining pool for testing on: February 03, 2011, 03:16:33 AM
It would be nice to say to potential users that this version is vulnerable and may not be used in production.

Do you care to explain that statement? It resembles a baseless accusation.  Wink
5  Bitcoin / Development & Technical Discussion / Re: Tonal BitCoin benefits & neutrality on: February 02, 2011, 04:46:04 AM
There is a learning curve for someone used to decimal, but given a fair comparison,  it is actually much easier in practice.

Can you point us to such a comparison? I've been trying to withhold my judgement but it's hard.
6  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: January 30, 2011, 09:30:31 PM
By mixer I mean a service that has coins and will send coins from its wallet when it receives coins, ensuring they are not the same.

In that case, in my language a 'mixer' is a node. Based on what you've said in earlier posts, the difference seems to be that people trust mixers but not nodes (and that mixers are more 'sophisticated'). Or is there more to it?

On AML laws, are you seriously going to go in front of a judge and try to argue that Bitcoin is not a currency and users of a mixer/mixnet are not "customers" in some way? I would be interested to see the reaction to such an argument given that the system is called BitCoin and the front page title is "Bitcoin P2P Virtual Currency".

If I try to pay my taxes in bitcoins I'll get about the same reaction as if I tried to pay them in Monopoly money. Would you suggest that the government will prosecute me for creating a Monopoly money laundry?

The (important) difference between one and the other (for this discussion) is that people seem to think Bitcoins have more value than Monopoly money. Neither is a currency in the same sense that bank notes issued by a national government are currency.

I say again that node operators will have do their own homework regarding their local jurisdiction before they start.

This is all getting a little off point. The original purpose of this thread was to solicit comments regarding the general technical architecture and operating process of a Bitcoin mixnet. Since no one has commented on those aspects I will proceed towards a more detailed technical specification and reference implementation.
7  Bitcoin / Development & Technical Discussion / Re: Shy client patch on: January 30, 2011, 07:06:14 PM
This seems like a good idea

I agree.
8  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: January 30, 2011, 07:04:34 PM
I mean one "pro" mixer rather than several mixers.

In my model I have two things: nodes and mixnets. Each node belongs to (is operated and controlled by) a single entity (individual/organization). A mixnet is made up of any number of nodes greater than 1. (I also have clients and transactions (chained and not) but let's keep this simple.)

What is a 'mixer'? Is it a node or a mixnet or something else? Is it controlled by a single entity or by more than one?

Running a mixer is risky because various government regulations in US/EU require you to know who your customer is once you're doing transactions of above a certain level, I think.

I will read more about that once I get the chance, but here's the thing: I don't think any of those regulations apply because Bitcoin isn't a currency and mixnet nodes don't have customers, in the commonly understood definitions of those words. That's not a legal opinion and obviously node operators will have do their homework regarding their local jurisdiction before they start. I just expect that in many cases it won't be a problem until the law begins to recognize Bitcoin as a currency.

for the database it's possible to obfuscate

I may have misunderstood, but it looks like your DB has two garbage columns but then the two bitcoin addresses, in order and in plaintext. An attacker who seizes the DB will not have to compute keys or values and do lookups, he'll just dump the entire DB, discard the first two columns, and use column A as his key and B as his value.
9  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: January 29, 2011, 06:03:25 PM
One problem is the maximum amount you can mix is the min(all pool sizes), which is probably not that huge assuming reasonable fees.

That's not quite true. Since the client preparing a transaction knows what size transaction each mixnet node can accept, it can choose nodes with larger maximum transaction sizes. For example, for a 3-node chain, the largest possible transaction will be as large as the third largest node in the pool (ignoring the problem of trust for the moment).

Also, one of the suggested extensions in the document allows single transactions to be broken into smaller pieces and sent along different paths. That increases the largest possible transaction size to the sum of all node sizes (assuming that a 1-node chain is sufficient for that transaction).

Another problem is that - let's face it - running a mixer is going to be seriously risky for anyone who lives in the USA or Europe

I'm not sure I see why. People in Western countries run Tor nodes all the time, which carries similar risks. They are sometimes harassed by poorly-informed authorities but to my knowledge none of them have ever been fined or jailed.

Maybe it's different because Bitcoins are a carrier of value. Still, they are not a recognized currency. I think the political climate will have to change a lot before we begin to worry about government intervention.

So I think it's worth exploring not only a "mixnet" model of many co-operating coin mixers, but also a model in which a small number of sophisticated mixers with large coin pools and possibly special hardware can provide this service, whilst still providing the same kinds of privacy guarantees a large mixnet would provide.

Just to make sure I've understood you, you're talking about a single entity that runs many internal coin exchangers, essentially an entire mixnet controlled by one individual/organization? Wouldn't that organization be extremely vulnerable to subpoena/search and seizure? They'd have full knowledge of the sender and receiver of every transaction, so it would be easy for an authority to trace an individual they've taken an interest in, or to trace every single user of the mixnet.

The final weak point in zipslacks scheme is the mapping of local address -> destination address.

How do you mean? If the database is seized by some authority? In that case it's not going to matter what obfuscation you use, the attacker will be able to decode it. That's the whole reason behind multiparty mixnets: no individual has enough information to trace the entire path, and the path can be chosen to cross many jurisdictions to make traces that much harder.
10  Bitcoin / Development & Technical Discussion / Re: Anonymity on: January 28, 2011, 10:28:25 PM
I feel an irresistible need to post a link to this thread which I started last week: http://bitcointalk.org/index.php?topic=2893.0

I'm starting to think about implementation now. Given Bitcoin and anonymizing communications networks I am of the opinion that anonymous transactions are within our grasp.
11  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: January 21, 2011, 06:25:37 AM
Me and MagicalTux were discussing this. The concept we came up with to provide anonymity was:

That system is probably very secure against an attacking fourth party (meaning someone other than the sender, recipient, or mix node) but I think it's more complicated than it really needs to be, for most use cases. It also has a weakness: M knows every detail about the transaction, including the sender and final recipient (and in my opinion the biggest challenge for this type of mixnet is untrustworthy mix nodes). However most of what you describe could be done within the framework I described in the PDF, if the user wanted to be that paranoid. M would not randomize anything, rather A_x's client would specify each transaction to be made, including sizes and delays, and could choose to route the transactions through multiple mix nodes. (Technically it's not a mixnet if there's only a single intermediate node. Smiley )

If the threat model is as zipslack describes, then I think a "send to self" mixnet would work.

That's a very interesting suggestion. I think I need to learn more about exactly how coins are represented in the block chain, because I was under the impression this wouldn't work because no matter how many accounts a coin passed through, it would always be traceable through the chain back to every account it ever 'belonged' to.

So if I get a payment for 100 bitcoins composed of 20 smaller balances from 20 different accounts, and I trace those coins back and find that 1 week ago they all belonged to a single account, it's likely that the coins were passed through a "send to self" mix and the account from 1 week ago belongs to the same user who just sent me this payment. (Another way to say that would be, it's very unlikely that a user received a payment for (at least) 100 coins, then paid it out in 20 separate transactions to 20 different individuals who passed those coins through another series of transactions that coincidentally finally ended with accounts controlled by a single individual who made a payment of those coins to me. That's a slightly oversimplified example but still a realistic one I think.)
12  Bitcoin / Development & Technical Discussion / Re: RFC: Bitcoin Mixnet on: January 20, 2011, 09:17:17 PM
Can the attacker see all unencrypted IP traffic to/from the sender's node, or is the traffic tunneled through an anonymizing network like i2p or tor?

I am assuming that traffic between senders and nodes will be tunneled through an anonymizing network and I'm assuming that such network is secure. I'm really only trying to address the problem of transferring your coins (assumed to be tainted with your identity) to a recipient whose address you have, without allowing that recipient (or others) to learn your identity by examining the block chain. Problems of secure and anonymous communication are outside the scope.

Does the attacker know any of the sender's receiving bitcoin addresses?

I'm assuming not. The objective is to prevent the attacker from obtaining the sender's addresses.

Is the attacker willing and/or able to send 'marked bitcoins' to the sender?  Lots of them?

Again I am assuming not, since the attacker doesn't know the sender's addresses.
13  Bitcoin / Development & Technical Discussion / RFC: Bitcoin Mixnet on: January 20, 2011, 05:59:39 PM
http://www.flamewars.org/~phil/Bitcoin%20mixnet.pdf

From the linked document:
Quote
Bitcoin recipients can have perfect anonymity: they can create a new address at any time to receive a payment and there's nothing to connect that address to the recipient's identity or other Bitcoin addresses. Senders have to work harder to achieve that objective.

If we assume that participants can use existing anonymizing networks to exchange messages, we can design a mixnet to provide payment senders with the ability to send coins without identifying themselves.

This idea or one like it has very likely been discussed before. I've certainly seen people suggesting using Bitcoin exchanges as single-stage coin exchangers to limit the traceability of a transaction. This is mainly a suggestion for how to standardize that concept to allow for a scalable mixnet. It's a very rough and general document at the moment, but I think it's a good starting point for discussion.
14  Bitcoin / Mining software (miners) / Re: New demonstration CPU miner available on: December 21, 2010, 06:48:31 PM
main.cpp?  There's no such file in the cpuminer directory…

I think he's asking you to patch the Bitcoin client to which you are connecting your CPU miner, not the miner itself.
15  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 08:03:42 PM
anyway, i just take what i get.   Cheesy

Of course it's his choice whether or not he releases the source. I am very interested, however, in knowing why he doesn't want to release it. This is the last I'm going to say about it in this thread though.
16  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 04:44:23 PM
why do you want the source to be open?

Because right now slush and his server are each a single point of failure. If either one becomes unavailable we have to go back to mining individually. OTOH if the source is available any one of us can take over in that event.

it would just enable others to create new (and eventually cheating) pools, which is one of slush's reasons not to do it.

I'm not too worried about that. I expect that over time we will be able to tell whether or not a pool operator is cheating.

Oh, and about this:

Mtgox and MyBitcoin are close source. I think shutting down those sites will have much larger impact on bitcoin network and nobody is asking for opensource it.

I'm not asking for them to be open sourced because I don't use them. All the bitcoin software I do use is open source, except this one. Smiley
17  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 04:18:24 PM
Why don't you want to release the source?
18  Bitcoin / Pools / Re: Cooperative mining (>1500Mhash/s already, join us!) on: December 17, 2010, 03:37:18 PM
About opening source: I like coding it and currently do not need a help, thanks. I wish to open critical app parts for 'security review' soon, but I probably do not open source it fully. It is a service, as mybitcoin or mtgox is.
Pool is strongest when there is plenty of mhash/s, so I have no motivation in creating another pools.

I understand that. Nevertheless I would feel more comfortable if the source were available. That way we could continue the project if you ever get bored and decide to quit or are unable to continue for some reason outside your control.

Maybe we could buy the source from you. How much would you ask for it?

About competing pools:

Generating inside a pool doesn't increase your overall Bitcoin reward. It just offers you smaller rewards more often. The larger the pool the smaller your share of each generated block, but a larger pool will generate blocks more often. Pool size should have no impact on each member's reward over a long timeframe.

If what I wrote above is true, there's no incentive to create competing pools and no incentive to discourage anyone from creating competing pools.
19  Bitcoin / Pools / Re: Cooperative mining (>1100Mhash/s already, join us!) on: December 16, 2010, 06:13:08 PM
Yes, very small, approx. 800 bytes per request.

Alright. Thank you. If it makes one request every two seconds then a rough guess is ~1.4MB per hour. That's tolerable.

i need a portable file to run on certain computers where i don't have installation privileges

Just run the installer on a computer where you do have installation privileges and then copy the entire installed folder to the other computers. In fact that installer will probably run even without privileges if you install to a folder you have access to.
20  Bitcoin / Pools / Re: Cooperative mining (>1100Mhash/s already, join us!) on: December 16, 2010, 05:52:07 PM
does anyone know how much bandwidth this consumes? The miner is connecting via RPC to the server several times per minute, isn't it?

Bandwidth is not main concern, but roundtrips/latencies are. I'm working right now on very simple proxy application, which will pre fetch work for few seconds (say 20 sec) to your computer.  Then you will point miner to this local application. It will limit roundtrips (as there will be one request per few second) and latencies (miner will not wait to fresh data).

I'm just wondering how this is going to affect other users of my shared Internet connection. I suppose those RPC requests are very small?
Pages: [1] 2 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!