Alice sends the private key to Bob using Tor or i2p or whatever. Nobody sees this. If there are intermediaries (such as in my last posting) it gets just better. Think of it as a remixing cascade for bitcoins, if you wish.

If Alice uses the bitcoin client to send money to Bob, everyone sees it in blockexplorer.

Nice idea !


Exactly.

Moreover: It speeds up turn around of bitcoin.

Alice spend 2 BTC to Bob by passing the private key of her 2 BTC address. Bob sends them to Carol. Carol to Daniel. Daniel to Eve. And Eve finally to Oscar.

This all is done without any checking, waiting for a new block or two or three to be generated. It is very fast and accomplished within 2 minutes.

In the mean time, Bob starts to get those new socks ready for shipping to Alice, Carol gets those pens reads for shipping to Daniel and so on. And, before they ship, they all check the block chain. They have to wait for two or three blocks anyhow.

An external observer doing network analysis just sees the money vanishing from Alicens address and he sees the money popping up at Oscar's address. The observer will even have the IP addresses of Alice and of Oscar. But the people in between, Bob, Carol, Daniel and Eve exchange their informaiton just by passing the private key in PGPencrypted email - they are completely protected from every kind of monitoring whatsoever.

Not the only advantage.

Right now you can do pretty much of somce decent network analysis just by following payment patterns. You can safely assume that one bitcoin address is one person.

In the new pattern it means that a bitcoin address can be two persons.

Once you have realized the mechanism, you can easily extend the scheme: Bob receives the private keys and immediately passes them on to Carol for one of his payments (can be done by a bot automatically). So one key / address could belong to 10 persons or more. it just means a bit more of patience for the block chain to settle.


I always can be screwed at any time by anyone in the chain before me. Always. The only thing which protects me is a bit of patience, waiting for the transaction to "sink in" deep enough in the block chain. So, I will always wait a number of blocks before assuming that a payment has been made.

We can pass the private key of an address along, to two, three, four, five people and more. Then, before sending the merchandise I have to check if all these facts are confirmed by the block chain. It's just as in consensus protocols: Being a bit patient and not always insisting on a pessimistic protocol can pay off one in a while.

It is just a trade-off between waiting time, security and privacy. If we wait long enough the proposed variant still is secure, but it certainly offers more privacy.


Yes? You can find out very interesting things with a network analysis of the block and transaction chain. I would not bet on bitcoin privacy without protocol amendmendts 

No. The difference is just the moment in the protocol where this is prevented.

Suppose Alice double spends a coin to Bob and Carol in the traditional Bitcoin protocol. Where will this be found? When forming and stabilizing the block chain, so Bob will know some 20 - 25 minutes later. Therefore, Bob will wait 20 - 25 minutes to make sure, everything is fine.

Now have a look at the proposal. Suppose Alice keeps a copy of the private key. Alice sends the private key to Bob. In order to make sure the money is his Bob immediately uses the private key to forward the money to a fresh address where he is the only one to have access to. Suppose Alice tries to cheat by transfering the money before Bob has done so. Bob will know 20 - 25 minutes later.

So in both cases Bob will wait some 20 - 25 minutes later.

Welcome back careful reading of forum proposals. 

Of course. That was an essential part of the procedure.

If the client does so for me automagically, it makes no difference for the user - but provides more anonymity.

This would be done automatically by a client(extension), so no additional work.

Advantage is that an attacker has MUCH more difficult task when tracing payments.

Maybe this has a stupid drawback or has already been discussed - but let me just put a thought on the board for discussion.

Currently we send money by sealing transactions in a block chain. This approach is higzhly susceptible to network analysis attacks. Although the bitcoin addresses are pseudonyms, all transactions are public and you can follow payment streams. I am currently doing some analyses here, but that's a different story.

Now, suppose we did different:

Alice wants to send 5 BTC to Bob. So she prepares a fresh bitcoin address, posts 5 BTC to this address and sends the private key [sic] for the address to Bob. Now, Bob can use this private key for spending this money.

Wait a minute, how can Bob be sure that Alice isn't using his money before he is. Well, this is a non-problem. Even in the traditional bitcoin protocol Bob has to wait some time until the transaction is cleared. So, in this case, Bob just uses the money to move it to yet another bitcoin address and waits until this transaction clears out. So there is no difference in this regard, but there is an important advantage: An attacker can no longer make the assumption that one bitcoin address corresponds to one person. Now, let's make it even worse for the analyst: Every 2 hours alice generates a new bitcoin address and shuffles here money from her old addresses to her new addresses. One in a while she buys merchandise from Bob and in this case she just forwards Bob the current private keys and Bob continues this address shuffling.

So...just think of bit coins to be private keys to addresses and no longer money attached to addresses, Conceptually, this becomes a different world.

And, voila, bitcoin now is really anonymous.

Feedback?

Wieso?

Bei denen ist ja die Person ab Ausstellung erfasst! Zumindest durch die Kreditkartennummer des Käufers.

And it is exactly this possibility which will be outlawed.


You will, very conveniently, pay with your credit card or your mobile phone. Every single of your purchasing acts WILL be linked to your identity. This WILL be the basis of state-wide data mining. This data mining operation WILL be, of course, restricted to fighting terrorism (for all other applications, information security laws will be in place, at least in theory). If your are against this type of data mining you ARE promoting terrorism, which will carry a penalty of 10 years minimum.


Starts???

Have you been sleeping for the last 15 years? In this case: Good morning!!

Did you ever have a class in history? Every 80 - 120 years humanity produced a really big mess-up. We are right in the middle of the process of preparing the next one. It will be connected with privacy and data mining.

I had a similar problem and wrote a small html page with embedded javascript. It checks the blockexplorer and the exchangerate and produces a nice web page where it lists all my accounts, with my btcs and converted into EUR - without having to start the bitcoin client with my wallet and the private keys.

There are 4 files you need, bitcoin.js with the script funcitonality, config.js (where you should edit the addAccount lines, replacing the FILLIN stuff with your bitcoin addresses, style.css for some cometics and sum.html as main file. I am using a bit of jquery, so you should make sure that all files including jquery_min.js (to be picked at the jquery website) reside in the same directory.

Then just load it with firefox version 3 and confirm the security dialogue. You will have to navigate to about:config and set signed.applets.codebase_principal_support to true as well.

I am including the files below. They are very far from perfect but help me solve my problem. They do not run in firefox 5 (mozilla removed the privilege manager), but version 3.6 is fine for this purpose. Do NOT put the code on a web server, it has security issues if you do not understand what I am doing here.

=== config.js:


// URL of the block explorer
const SERVICE_URL = "http://blockexplorer.com/address/";

// URL for the exchange rate
const EXC_RATE = "http://bitcoincharts.com/t/weighted_prices.json";

// default exchange rate
const CURR = "EUR";

// default weighting
const WHEN = "24h";

addAccount ("1PFILLIN", "Eligius");
addAccount ("1FILLIN", "Other");
fakeAccount ("1PRCQbVgLkNjUCWafA8UYsmBH1Ay7zyvu8");

exRate();
dobit();

=== bitcoin.js

var accounts=[];

function addAccount (address, name) { accounts.push ({address:address , name: name , org:true});}
function fakeAccount (address) {accounts.push ({address:address, name:"other", org: false});}

/// try to log a text in case console.log is defined
function myLog (text) {
  if (console && console.log) {
    try {console.log (text);} catch (x) {}
  } else {
    // alert ("Console not found for logging");
  }  
  return;
}

var request = false;
 
var sumReceived = 0;
var sumSent = 0;
var timesSent = 0;
var timesRcv = 0;
  
function makeRequest(account, mine, title) {
  url = SERVICE_URL+account;
  
  // check if we are loading from local file system
  if (!location.href.match(/^file.*$/)) {alert ("Incorrect location for privilege escalation; rejecting; probably attempted attack"); try{alert (location.href);} catch(e){} return;}
  try {netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");} catch (e) {alert("Permission UniversalBrowserRead denied.");}
 
  var request = false; request = new XMLHttpRequest(); if (!request) {alert('Cannot create XMLHTTP instance');return false;}
 
  request.title = title;
  request.mine = mine;
  request.account = account;
  
  request.onreadystatechange =  function () {
    myLog ("readystatechanged: "+ request.readyState + " " + request.status);
    if (request.readyState == 4) {
      if (request.status == 200) {
 
        myLog ("returned");
        if (!request.mine) {myLog ("Skipping output, not mine"); return;}
        
        var string = request.responseText;
        var received, sent, rTx, sTx;
        $(string).filter(".infoList").children().filter(":contains('Received BTC:')").each(function(idx,elem){
          received = elem.textContent;
          myLog(" "+elem.textContent);
          
        });
        myLog ("second");
         $(string).filter(".infoList").children().filter(":contains('Sent BTC:')").each(function(idx,elem){
          sent = elem.textContent;
          myLog(" "+elem.textContent);
          
        });
        
        $(string).filter(".infoList").children().filter(":contains('Received transactions:')").each(function(idx,elem){
          rTx = elem.textContent;
          myLog(" "+elem.textContent);
          
        });
        
        $(string).filter(".infoList").children().filter(":contains('Sent transactions:')").each(function(idx,elem){
          sTx = elem.textContent;
          myLog(" "+elem.textContent);
          
        });
        
        received = received.substring(14);
        sent = sent.substring (10);
        rTx = rTx.substring(23);
        sTx = sTx.substring(19);
        
        received = parseFloat (received);
        sent = parseFloat (sent);
        rTx = parseInt (rTx);
        sTx = parseInt (sTx);  
        timesSent += sTx;
        timesRcv  += rTx;
        
        sumReceived += received;
        sumSent += sent;

        try{$("#last").remove();} catch (x){} // before append, remove a last line (if exists)
        try{$("#curr").remove();} catch (x){} // before append, remove a last line (if exists)
      
        $("#mytable").append("<tr>" + "<td class='c1'>"+ request.title + "</td><td>" + request.account + "</td><td class='c2'>" + received + "</td><td>" +rTx + "</td><td class='c3'>" + sent + "</td><td>" +sTx+  "</td><td class='c4'>" + (received-sent) + "</td></tr>" );  
        
        finalize();  // calculate overall sums
        
     // alert(string);
      } else {
        alert('There was a problem with the request:'+request.status);
        console.log (request);
      }
    }
  }
  
  try {request.open('GET', url, true);} catch (e) {alert ("Exception on opening XHR"); alert(e);}
  try {request.send(null);} catch(e) {alert ("Exception on sending XHR"); alert (e);}
  
  try {netscape.security.PrivilegeManager.revertPrivilege ("UniversalBrowserRead");}
  catch (e) {alert ("error on reverting");}
}
 
function finalize() {
  $("#mytable").append("<tr id='last' style='font-weight:bold;'>" + "<td>"+ "Totals in BTC"+ "</td><td></td><td>" + sumReceived + "</td><td>" + timesRcv + "</td><td>" +sumSent + "</td><td>" +timesSent+ "</td><td>" + (sumReceived-sumSent) + "</td></tr>");
  $("#mytable").append("<tr id='curr' style='font-weight:bold;'>" + "<td>"+ "Totals in "+ CURR +" of "+ WHEN + "</td><td></td><td>" + sumReceived*exRate + "</td><td></td><td>" + sumSent*exRate + "</td><td></td><td>" + (sumReceived-sumSent)*exRate + "</td></tr>");
}

function dobit () {
  for (var i = 0; i < accounts.length; i++) {makeRequest (accounts.address, accounts.org, accounts.name);} }  

// get the exchange rate
function exRate() {
  
  // standard start
  if (!location.href.match(/^file.*$/)) {alert ("Incorrect location for privilege escalation; rejecting; probably attempted attack"); try{alert (location.href);} catch(e){} return;}
  try {netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");}  catch (e) {alert("Permission UniversalBrowserRead denied");}
  var request = false; request = new XMLHttpRequest(); if (!request) {alert('Cannot create XMLHTTP instance');return false;}
  
  request.onreadystatechange =  function () {
    myLog ("readystatechanged: "+ request.readyState + " " + request.status);
    if (request.readyState == 4) {
      if (request.status == 200) {
        myLog ("returned exchange rate");
        var string = request.responseText;
        var exch = JSON.parse (string);
        exRate = exch[CURR][WHEN];
        } else {
        alert('There was a problem with the exchangerate request request:'+request.status);
      }
    }
  }
  // standard end
  try {request.open('GET', EXC_RATE, true);} catch (e) {alert ("Exception on opening XHR"); alert(e);}
  try {request.send(null);} catch(e) {alert ("Exception on sending XHR"); alert (e);}
  try {netscape.security.PrivilegeManager.revertPrivilege ("UniversalBrowserRead");}  catch (e) {alert ("error on reverting permission at exRate()");}
}  
  
=== sum.html

<html>
<head>
<title>Bitcoin Summary</title>
<script src="jquery_min.js"></script>
<LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen>
</head>
<body>

<table id="mytable">
<tr id="row"><td class='c1'>Account</td><td class=''>Address</td><td class='c2'>BTC Rcvd</td><td>Tx Rcvd</td><td class='c3'>BTC Snt</td><td>Tx Snt</td><td class='c4'>BTC Total</td></tr>
</table>

<script src="bitcoin.js"></script>
<script src="config.js"></script>

</body>
</html>


=== style.css


html table tr td {font-family:verdana,sans-serif; font-size:smaller;}

#row {font-weight:bold; background-color:Aquamarine;}

#mytable {width:100%;}

tr {background-color:Bisque;}

.c1 {}

.c2 {}

.c3  {}

.c4  {}

#last {background-color:Aquamarine;margin:10px 0px 0px 0px;}

#curr {background-color: LightPink;}


=== and jquery_min.js from the jquery site


Enjoy !

Thanx a lot - this was very helpful.

The bitcoin client is actually constructed in a very smart manner. 

Once in a while timestamps are moving backwards.

Block 32649 is from 09:49:06 and the next block 32650 is from the same day 2 hours earlier, 7:50:31. 

This is not the only example, there are quite many - and it is also not just 3 or 6 minutes but hours.

I am trying to understand that phenomenon - but I don't. even if there is a chain reorganization, the chains mut be built in sequence - and the code shoulod check linearity in time.

Where is my mistake?

Ok. So essentially you are telling me you trade a fixed amount of gold against a fixed amount of btc. There are two possible cases:

Case 1: Your gold is too cheap. Everyone will buy your gold and that's it.

Case 2: You gold is too expensive. Everyone will sell gold to you and that's it.

So, this is of a great service and, in fact, yes, it will stabilize the course of the btc. I agree.

In the end there is no economic benefit for you. There is only economic benefit for me, and I just have to make my choices, depending on which case is true.

But: Why should I do it? Every day my spam filter filters out some 5 or 6 emails where people want to share millions from a dead nigerian general with me. There is only economic benefit in this concept for me. I still do not do it.

The issue here is: I do not see the economic rational reason for you to damage yourself. And since I do not see it, I am not ready to make the deal, because I assume that there a strings attached to it.

That is the line of reasoning, my brain also uses all the time.  

That's exactly the reason why I am not sure whether it is true.  

I am asking myself whether there are additional reasons or motivations for mining beyond profit from the 50 BTC mining bounty.

1) Staying part of the community, staying current in know how.

2) Heating your flat.  

3) Burn in of your equipment.  

4) Future benefits from the transaction fees.

5) Future benefits we all do not know about yet and which we will understand upon release of bitcoin version 0.5cr (cr denoting conspiracy release)

6) We are not mining for bitcoin, we are part of a big social experiment / ponzi scheme / clever attempt of the nsa to break sha256 / clever attempt of wikileaks to break the encryption of yet another video (add your favorite conspiracy theory here).  

7) I have a very good reason and I am not going to tell in public  

Just following the crowd. Everybody's mining so it can't be a bad move to do so.  

Well, I do not know. But I am interested in other theories. (to be honest: I want to understand it for myself, why I am mining)

How much is needed to destabilize it?

And how big a share of a major financial institution's yearly earnings is this?

And, given the potential of bitcoin to change the financial world in the internet, would that be a good investment, if you want to keep the fees for traditional institutions flowing?

I am not suggesting to do it. For me, trust just means to think about possible threats. Trust, in the sense of open eyes. So we should know the answers!

Gongcheng

Why would I want to trust you that I will really get my gold?

If bitcoin crashes, everyone will want his gold back and this will be hugely damaging for you. How do I know that you do not just pull a Maddoff? So it is not about trust in gold, but it is about trust in you.

Why on earth should I trust a single person with a shiny web site more than 10.000 people with their GPUs? Wasn't bitcoin made for exactly that reason - not having to trust in a single person or bank or institution?

Maybe I do not understand your concept, but I cannot see a single reason how this would help bitcoin. Economically, I rather see the contrary: IF such a business opens up then this opens up big possibilities for manipulating bitcoin. We already today see how the Mt Gox case with Mt Gox being one of the largest exchanges, is damaging the reputation and exchange rate of bitcoin. Why would I want additional dependency of a single entity? Assume, you have a car accident; assume, your wife files for a divorce. What securities do I have that your wife does not take the gold into her pension fund? What securities do I have that your employees know the proper passwords? Why would I want to concentrate risk on one person and his promises? I do not see a good reason.

You write. I will still trade 3 bitcoins for 1 gram gold until my store of gold last Thats fine. But what if your store of gold is not lasting any longer? What, if it is stolen? What, if it is confiscated by your ex-wife? How do I know that I can trust you more than these guys in my inbox who every other days want my support to recover the inheritance of that nigerian general?

Oh. I forgot. I do see a good reason.

If someone wants to damage bitcoin, the logical move would be to go for more concentration and for more centralized structures.

If I were Visa or Mastercard: I would use a small percentage of my wealth to do some rollercoaster gameing with bitcoin. Buying some, letting hackers steal some, writing about it, selling a lot to dump the course again. Destroying trust.

So let me see... Just assume you do this business... More and more people buy into that gold backing stuff. And then, one day there is an SQL injection at some Mt Gox 2.0 and the exchange rate drops down. Some people want their gold backing. And, for some very interesting reason you are, umm, just not able to fulfill their demand immediately. DDOS maybe or what have you. 48 hourse of negative reporting ... bitcoin crashes even more.

In the end, at the price of a few kilograms of gold, you have successfully destroyed bitcoin's reputation.

This certainly is better than the perspective of losing the credit card fee business model all together.

Yes. If I were Visa or Mastercard, I would do it.

The dead man's switch is a nice idea. 

Regarding script.cpp, I just checked if the opcode is there and not the logic. It looked to me that this is not a threshold scheme but a "you must present two signatures" scheme - so that's why I wrote about "increasing risk of loss". Moreover, wouldn't it also have to be used by the sender of the coins?!

Thank you for pointing this out. I checked this in the code. With the exception of script.cpp and script.h it is not used. Especially, it si not part of the GUI.

Guess we should make it available ASAP.

Still it is only part of the solution. It increases the risc of loss. Now you should not lose TWO things. Before that, you whould not lose ONE thing.


Ok. Then replace "secure device" in my sentence by "usb drives/smartcards/whatever".

There is a thing which holds your key. This thing gets broken - you lose your money. You copy this thing - you increase your risc of having it stolen and you have to redo the copy every time you generate new keys.

The solution I am contemplating takes care of BOTH aspects.

You cannot be compromised so easily, because you need more than one device to access your money.

You do not increase your risk of loss, because you "things" are replaceable.

With the suggest form of secret sharing you get both advantages for one price. 

Rule number zero: You can change the protocol. Any time you want. It's a peer to peer system.

The issue just is: If not enough users pull your change into their version, you just damage yourself by improving your protocol and losing acceptance.

Rule numer minus one: At every moment, you can roll your own bitcoin. It's an open source system.

There are numerous regional alternative and parallel currencies, cupons, voucher systems. Their value depend on the acceptance and on the stamina of their originators to make 7 billion people accept them.

I am trying to work that out right now.

The idea is, that the account holder also has access to a majority of devices holding the shares. So, the account holder would press the "redistribute secret" button on all the devices he has access to, and the devices would generate and distribute new shares using a suitable protocol. Those devices which are not present at that moment, would not get their new share, and their old share would, from that moment on, be useless.

It is probably easier (but less secure) to have a single trusted device redistribute the secret.

To my knowledge there are no open source tools which do that. So it would be a matter of implementing and having it subjected to peer and community reviewing. The good part is, that it does not affect Bitcoin at all and would be a seperate piece of software, using the RPC API of bitcoin.


Is this multiple signature feature for m of n or is it rather for 2 of 2. What I saw in the code was rather a 2 of 2 kind of scheme - and I did nto check if it is really turned on or just in the code but disabled.

Getting the coins to a new address with keys is certainly possible and fun for the freak, for the John Doe user it is a no-go. Just compare: This new fine leather wallet is secure. You just have to move your coins into a different one every other day!


I agreed with that until yesterday. 

Imagine you lose the secure device. Or drop it. Or your cat pees on it. Your son runs his bike over it. There goes the access to all your bitcoins.