I think there are some advantages to be had if some of the centralised pools would mine through a p2pool node, effectively creating a superpool.

Firstly, the resulting sharechain would provide an easy way for those parties with an interest in accepting low-confirmation transactions to know which transactions the pools are actively mining.

Secondly, if multiple pools point their hashpower at the same p2pool node, they will all see reduced earnings variance and get a share of the p2pool donations. This would remove (or at least drastically reduce) the incentive for miners to join the largest pool in order to reduce variance.

It would allow for much more accurate estimation of network hashpower and the hashpower split between pools (assuming pools don't hide their identities), which would also allow us to determine the fraction of the network in favour of a given proposal (think of the p2sh voting) more rapidly and accurately.

Never in my life have I experienced such poor customer support. My account was one of those attacked on the 13th July with a password reset request. See
https://bitcointalk.org/index.php?topic=255630.0;all and http://www.reddit.com/r/Bitcoin/comments/1i7ydk/psa_reminder_do_not_store_anything_of_value_at_a/
for other reports of this attack. Incidentally I have yet to hear an explanation from mtgox of how the usernames of a large number of gox users leaked and how the attacker managed to request password resets even without the yubikey (in my case) which is supposedly required.

Anyhow, that is not even my complaint. Fact is, after picking up on the attack on the very same day it happened. I have still not been able to get access to my account to this day, more than 4 weeks later. When I enter my details in the password reset form I inevitably end up with a message "You have made too many recovery attempts, your IP has been blocked. Please click the help icon at the top of the page for assistance." This is  untrue and happens even when I attempt the reset from a different PC with a different IP. I have contacted gox support 15 times and counting. I have identified myself to their satisfaction, I have sent screenshots illustrating the problem, I have asked nicely, I have begged and ultimately I have lost my temper. All with the same result. Zero.

I have been told that the issue has been referred to the dev team and I waited more than a week before contacting them again after that. No progress whatsoever. On more than one occasion I have been told that the problem has been resolved, only to find that nothing has chhanged on my end. I have dealt with Danny, Dennis, Patrick and Linda. They have varying degrees of ineptitude and their first suggestion is inevitably that I go reset my password. Yeah dude, after four weeks of being locked out of my account do you seriously think that I have not tried that yet.

After giving them detailed information on the nature of my problem and identifying myself to their satisfaction and voicing my concern over whether my money is safe I got the reply:"
Hello Hennes,(sic)

We have increased the withdrawal limits for the account..."

Because when a hacker is attacking your account and you cannot even get access to tell if your money is still there, nothing sets your mind at ease like knowing that your withdrawal limits have been increased. 

In my latest contact with them I insisted that the developer which is supposedly working on this just drop me  an e-mail. Request denied. After repeatedly inquiring why this should be so vehemently opposed I was treated to the following "gem"

"As advised earlier developer do not communicate with users directly and they do not have email access and probably they are not even good at language so that is why we are there here to communicate issues to them."

So apparently the gox devs don't have email access. Starting to see why it might be tricky for them to debug password reset email sending functionality. Just how stupid do they think we are??

It is seriously time for these clowns to just go out of business.

Not even June 2011

Clearly there have been better and worse times to buy in. But even if you had bought in June 2011 for $32 and simply held, you would now be looking at a 40% return or in excess of 20% annualized. 

Been wondering about this for a while, finally decided to just ask here. From the wiki :

"It is illegal in some countries to possess/distribute certain kinds of data. Since arbitrary data can be included in Bitcoin transactions, and clients must normally have a copy of all unspent transactions, this could cause legal problems.

Unspent transactions can be safely forgotten if more than half of all users are forgetting those transactions. If a miner neglects to forget an unspent transaction and is in the minority, its blocks will be rejected by the majority if those transactions are subsequently spent."

What is meant here by "forgetting" a transaction? I understand that the tx itself can be pruned from the miner's local copy by using the merkle tree, but somewhere, someone needs to retain the original block and be willing to send it to peers on request. New nodes that are starting up cannot accept pruned blocks  since they have no way of knowing whether the pruned txs were spent or unspent. Therefore there always needs to be at least one node willing to resend blocks with illegal content upon request or it becomes impossible for new nodes to start up. Given that law enforcement can easily start up a node, see where it downloads the dodgy block(s) from and go after the owner of that IP, this is only viable if the relevant node is sitting behind a tor hidden service. But this requires that all new nodes starting up go through tor.

I'm hoping that Mt Gox will convert all their yubikey protected bitcoin accounts to multisig sooner rather than later. The clients private key can be computed from a passphrase using javascript "brainwallet style". Gox will then provide the second signature using their green address. Therefore I can then leave all my coins in a Gox wallet and they will be

- Safe, even if gox is completely pwned by hackers (assuming my passphrase is not password123 or something equally stupid).
- Immediately available for trading at any point without waiting for confirmations.
- Immediately available for spending to a merchant, who will not wait for confirmations if they trust Gox.

Of course anyone can provide this service, but Gox is uniquely well placed to do this since they have allready distributed thousands of  yubikeys to their users. (This model does not really work if you don't have a yubikey or some other 2-factor authentication device, since an attacker can then get all the access they need to your account by just using a keylogger).

Under this model an attacker would either have to compromise my PC AND steal my yubikey or compromise my PC AND hack Mt Gox.

I know the idea is not new (this is what multisig is for after all) I'm just wondering whether there is any official communication from Gox with regards to a roadmap for something like this.

 

The whole pirate debacle has been incredibly divisive. People on both sides have doubled down and then doubled down again on their opinions. When this train smash eventually plays out fully, there will be a lot of people with a lot of egg on their faces. I'm guessing if you were a pirate "investor" and he defaults, you would get tired pretty quickly of team ponzi asking you what you will buy with all your coin "once pirate pays out". Similarly, if pirate does pay out (yeah right (see what I mean about doubling down? (damnit  ))), Team Ponzi might get tired pretty quickly of being sent the odd satoshi along with condescending encouragement to "invest it wisely".

Perhaps  we need to provide an alternate forum where those who are  proved wrong can go to keep talking bitcoin without being continually reminded of "the events".

I suspect wheresmycoins.org and icallponzi.org are  both still available?

jk

http://thenextweb.com/insider/2012/08/20/bitinstant-may-bridge-virtual-real-world-currencies-international-bitcoin-credit-card/

I'm guessing this is the mysterious september announcement.

I've been thinking about 0-confirmation txs and how accepting them can be made safer. I'm of the opinion that they are already safe (well safer than competing options) for most applications. If you are buying something from a bricks-and-mortar retailer and attempting a double spend shortly after leaving the paypoint, there is a real chance that you can still be apprehended. The longer you wait before sending the second tx, the smaller the chance of being caught gets, but the chance of a successful double spend also shrinks very rapidly. In addition, CCTV footage of the paypoint means that you can still be identified and blacklisted, even if your double spend attempt failed.

However, there are applications where a customer could attempt a double spend with essentially zero risk of negative consequences. It is these that are of real interest. One example is a bitcoin vending machine. The second tx can be sent as soon as the machine dispenses the product, and the machine cannot reasonably delay more than a few seconds after receiving the first tx. CCTV could also be trivially defeated in this case (masks, hoodies, or even just holding your hand  in front of your face). The chance of a successful double spend is  still low, but since the risk is almost non-existent, we can expect many double spend attempts and consequently, some successes.

My proposal hinges on the way that miners handle the case when they see multiple conflicting txs. Today, they are supposed to accept only the first tx seen, but this behaviour cannot be enforced. A profit-optimising miner would accept whichever version carries the largest tx fee and no-one would be able to prove that it wasn't following the rules. This allows for miner bribing double spend attacks, where a larger tx fee is offered in order to increase the odds of one version of a tx winning the race into a block.

Others have proposed earlier that miners should include BOTH of these txs in a special "double-spend alert" section of the block. The problem remains that we have no way of knowing which of the versions goes to the merchant and which is the back-to-self version. I'm suggesting that we can improve matters without knowing which is which. BOTH versions of the tx become invalid and the money is effectively destroyed. Therefore, the merchant doesn't get paid, but the cheating customer does not get his money back either. Importantly, both the paying output and the change 
is destroyed.

So, if I am a vending machine operator, I may "safely" accept instant txs for a value of X, conditional that the input(s) used to pay me add up to at least 10 X (or some other multiplier of my choice, the more paranoid I am the higher). Then I know that the cash I accepted can still be burnt after I dispensed the product, but the customer would also burn 9 times as much of his own money in the process. This seems pretty safe to me. If I was really paranoid, I could buy insurance against events like these. The premium would be incredibly small, because there is no possibility of defrauding the insurance company. The only way to claim X would be to burn 10 X. In a rational world that never happens. In the real world, it happens very rarely and with very small amounts.

An improved variation, would be to burn only half the money and award the other half to the miner who reported the double spend attempt. This incentivises miners to mine these, while eliminating the "bribe-a-miner" attack.

Then the only way for someone to safely execute a successful double spend is to not broadcast the second tx and mine the block containing it themselves. This radically reduces the number of potential  perpetrators (essentially only a pool-op has a non-negligible chance of doing this). If we wanted to close this theoretical loophole as well, we could allow a double spend report to occur, one or two blocks AFTER the first tx had allready made it into the chain). This complicates book-keeping, since the tx fee reward for the first block is now effectively less than what is stated in the block, but it is certainly possible.

I realise that it is probably too late for this to be used in bitcoin as it would require a hard fork of the blockchain. Might be useful for an alt-chain though. Or am I missing something?

Hi all.

I used to think that I understood how tx pruning works. However, I recently realised that there is an important question which I cannot seem to answer. I understand how the merkle tree can allow us to verify the block hash even when most or all of the txs in the block have been pruned.

What I do not understand is how we can be sure that unpruned txs are unspent in the presence of pruning. To give an example let's assume a tx history like this
In block 1 - A mines 50 BTC
In block 2 - A pays 50 BTC to B.
In block 3 - B pays 50 BTC to C.

Normally these three txs form an unbroken chain from the unspent output (in C's hands) all the way back to the coinbase tx. If we start pruning txs and tx 3 is unspent and buried under enough blocks we may prune txs 1 & 2. Now the only thing that a new node that downloads the block chain sees is

block 1 - txs pruned but merkle tree can be used to verify hash
block 2 - txs pruned but merkle tree can be used to verify hash
block 3 - B pays 50 BTC to C.

We can no longer verify the history of B's coins all the way back to coinbase, but we can see that the network accepted the payment at the time, so it must be valid. However, what if a malicious attacker sends us the following history.

block 1 - A mines 50 BTC.
block 2 - txs pruned but merkle tree can be used to verify hash.
block 3 - B pays 50 BTC to C.

All the hashes check out, and the blockchain is intact, so we have no reason to reject this history. But according to this it would appear as if both A and C have 50 BTC to spend (After all the pruned tx in block 2 may been "Z pays 50 BTC to B" for all I know). If we are then sent a tx where A pays the 50 BTC to D we would accept it and unwittingly assist in a double spending attack on the network by attempting to mine a block that contains this fraudulent tx.

In Satoshi's own words : "The only way to confirm the absence of a transaction is to be aware of all transactions." Transaction pruning appears to contradict this principle. All is fine if I am pruning the transactions myself after having downloaded the unpruned block chain and verified it fully. But if I am accepting a pruned chain from another node, both versions of the tx history shown above are equally believable and I have no way of knowing which is genuine.

I am sure there must be a (simple?) answer to this but I cannot seem to grasp it. Please clarify.



     

First off, what follows is NOT a proposed change to bitcoin. Nor is it really an idea for a new blockchain. Bitcoin has forced me to think long and hard about the nature of money and the experiment described here is one of the things that still screws with my mind.

Suppose one coded a bitcoin variant that works as follows.

Difficulty still varies up and down to target a set number of block being generated in a set time period. However, the coinbase amounts are not following a hardcoded decreasing pattern to target a fixed final amount of issued currency, but are adjusting up and down to target a fixed exchange rate, for example pegging the currency to the dollar. (Please don't get stuck at this point on how undesirable this is, I'm not advocating for it, just trying to convince myself whether it would work.)

Exchange rate is determined by demand and supply. We have no control over demand but some control over supply (not perfect control, since we can't control when hoarders will choose to sell, but assuming some miners sell their coins soon after generation, we have control over this portion of supply). In order for the network to know what the coinbase amount for the next block should be it needs to know what the exchange rate is. Therefore the current exchange rate is also placed into every block. If the exchange rate in a block is incorrect for the time when the block was generated, the block is rejected. If the exchange rate goes above one (Fiatcoins become too valuable), then the coinbase transaction is increased and if it drops below one (Fiatcoins become too cheap) then the coinbase amount is decreased. This is analogous to a central bank increasing and decreasing the money supply via interest rates which in turn affects the exchange rate of the currency.

One important point is that this may well work, not because the feedback loop thus created is particularly effective, but because it creates an expectation of what the exchange rate "should be". If a large group of people believe that the exchange rate will tend to 1:1 in the long term they will buy when the rate dips below 1 and sell when it rises above 1. The built in mechanism can only affect the the exchange rate over long periods, but the expectation that the protocol will eventually force the rate back to 1 leads traders to keep the rate at unity, even in the short term.

Of course having the exchange rate in every block causes technical issues. If everyone is getting their rates from the same exchange, then the network has a single point of failure. If we get our rates from different exchanges, then as long as there is still a functional exchange somewhere that is reachable by most miners, the network remains functional. However, if miners are free to use exchange rates from any exchange, then I can't reject any block that has a price that doesn't match the price at my reference exchange exactly, since the rate may well be different at other exchanges. I can however reject anything that deviates by more than a small margin, since arbitrageurs should keep the exchange prices close to one another.

The power of expectations is unbelievable. Give people a plausible reason to believe that the exchange rate will tend to X in the long term and it becomes a self fulfilling prophecy. Another example is the bitcoin test network. On a technical level the test and production networks are indistinguishable (aside from scale), yet bitcoins are worth almost $17 dollars each (right now, who knows what they'll be worth in 5 minutes) while test network coins are utterly worthless. Why are they worthless? Because we expect them to be.

This messes with my mind




 

I'd ideally like to post this in the Development and technical discussion board, maybe a mod can move it there. Been frequenting the forum a couple of months now, but am more of a lurker than a poster. In this instance, however, I believe I have something worthwhile to contribute.

After the allinvain heist and the confirmation of the existence of a bitcoin stealing trojan, the boards have been awash with suggestions for securing bitcoin wallets, and while most of these will undeniably make it far harder, or even impossible, for a thief to steal significant amounts of bitcoin from a properly secured wallet, securing a large amount of BTC needs to be far easier to make it accessible to the general public.

What I would like to propose is an additional transaction type that would allow you to specify constraints on the use of funds from a specific address. This is analogous to the existence of cash withdrawal limits on an ATM card that the bank customer may configure. The CREATECONSTRAINT transaction would not move cash between adresses like normal transactions but would list a source adress (to which the constraints would apply, a MAXMOVE amount and a list of N safe haven adresses.

Once the constraint transaction has been incorporated into the blockchain, the network would disallow any subsequent transactions that attempt to move more than MAXMOVE bitcoins to any adress not in the list of safe haven adresses. This would be enforced on a per block basis, in other words nodes have to ensure that the total amount of bitcoins moved from the source adress in a specific block does not exceed MAXMOVE. If multiple transactions using that source address are received, any transactions targeting safe haven adresses will be prioritised, and all others would be added in, in the order received up to the point where adding the next transaction would violate the constraint.

In practice this would mean that I could safely keep thousands of bitcoins in a single address in a wallet, configure the address to not allow transactions of more than X BTC per block (where X is a reasonable number for everyday expenses) unless the receiver is one of a small list of alternate adressess that I control. Obviously this helps nothing if the private keys for the safe haven addresses reside on the same machine as that of the primary address, but these could be addresses that reside on my mobile, addresses of trusted friends or even a mybitcoin or mtg*x deposit address. I could also keep them on a USB stick with a live distro, but I probably don't need to keep the stick in a safe, since the adresses are usually empty.

If my primary address is compromised I can request the movement of my funds to one of the safe haven addresses and only lose a relatively small amount depending on how quickly I reacted. I can also do the same thing if the address is not compromised but I need to do a transaction larger than MAXMOVE.

Of course safe haven addresses are also adresses and as such could have their own constraints. The uber paranoid could create complex networks of wallets that need to be traversed before the money reaches an unconstrained address. Unless the attacker manages to compromise ALL the wallets in the chain, he will only be able to siphon money off very gradually (or not at all if MAXMOVE=0). Similar things could be achieved with multi-signature transactions, but this method has the advantage that small value transactions remain as simple as they are today even when sourcing funds from high value wallets.

A CREATECONSTRAINT transcation is checked for validity by ensuring that if any CREATECONSTRAINT transaction for this address allready exists, then the new transaction may only tighten the constraints (i.e. reduce MAXMOVE, specify a subset of previously listed safe havens) and never relax them. One could also consider having some default MAXMOVE amount defined for all adresses. The first CREATECONSTRAINT transaction that gets processed for a given address would be allowed to increase MAXMOVE from this default level.

This doesn't help if your wallet is compromised and you only realise it 10000 blocks later, but it would be simple for third parties to build payment notification services that would send you an SMS/e-mail every time BTCs are sent from one of your addresses.

If the extra kBs consumed in the blockchain are an issue one could always prevent gratuitous use of the CREATECONSTRAINT transaction by requiring a non-trivial transaction fee.

Comments?