I downloaded Electrum-3.3.4.tar.gz, unpacked, and ran ./run_electrum.

I get:

  File "./run_electrum", line 53
    sys.exit(f"Error: {str(e)}. Try 'sudo python3 -m pip install <module-name>'")
                                                                               ^
SyntaxError: invalid syntax

I didn't want to "update", but my balance-monitoring using 2.9.3 stopped working at some, it's just perpetual "Synchronizing".

So shoddy all round.  Not an ongoing solution to anything, will find new solution for monitoring address balances.

Due to unavailability, I wanted to ensure I have proper records of Kraken's corporate identity.

On their web site and in their emails, they don't seem to give their incorporated name or registration number. Normally a company would present this information, along with the jurisdiction in which they're registered, all over the place, for example at the foot of every web page and email.

Even at https://www.kraken.com/en-us/legal, they seem to just refer to themselves as "Kraken".  Okay, "Kraken" is a trading name.  But what is their corporate identity?

Can anyone help out with this?  Normally there is some kind of company name with a special ending like Ltd or AG (in California Inc / LLC / LP?), some kind of company number (in California, Entity Number), and a registered office address for serving legal notices or making contact (in California "Agent for Service of Process" / "Entity Address").

I can't work out the details of how Poloniex's daily limit works.

Supposing someone has L2 verification, 25k daily limit.  Does this mean the customer can't withdraw more than 25k's worth in any 24 hour period?  Or is it a daily limit in the normal sense of the term?  If so, what time zone is used to determine when the new day starts?

On June 8, I asked Bitstamp a question about their service via a ticket.

On June 26, I got a holding reply with "thank you for reaching out", "rest assured that we shall address your issue in the shortest amount of time possible" kind of bullshit.

On August 14, I chased up on the same ticket for a response.

On August 17, I created a new ticket to ask for a response on the previous ticket.  BItstamp ask customers to only create one ticket per query, but given the exceptionally long time I'd waited, I opened a new one.  Perhaps something caused the chaser on the old ticket to not be seen, whereas perhaps they would see a new ticket.

On August 18, I chased up again on the new ticket.

The total time without response to the original query is now 2 months and 11 days.

No money is at stake on this particular ticket.  But I was planning to start liquidating a load of digital currency through Bitstamp to buy a house.  I am now concerned that something is seriously wrong with this exchange.

... when it could be worth meeellions?

Last year when I bought a load of coins, I funded mtgox via a direct bank transfer in GBP.  Now I go to Funding Options in my account, and there is only an international wire option.  Is it really not possible to fund gox in GBP via BACS?  What are other people doing?

I'm always amazed to see people saying things like "I bought in at X, it's now X+10, I might sell if it goes down to X+5 to lock in some gains, or at X+15, cos that would be a great profit", or various combinations of that.  Unless you are performing very disciplined market making in a volatile market, such behaviour is going to at best even out in the long term, before fees are taken into account.  After fees are taken into account, you are going to be way, way down.

I want to provide a simple example of a strategy that is a long term bet on Bitcoin's success.  This is independent of any coins which may be bought for day to day use.

Using 5% of one's salary after tax each month, buy the same value of Bitcoins each month, as valued in the currency in which one's salary is paid.  Send the coins straight to a set of cold storage wallets.  Around once a year, evaluate whether one's savings have put one in a position where one can make any significant long term changes to one's life.  If so, decide what, if any, changes one will make.  That's it!  No frittering away on exchange fees, no wasting time on relatively small (taking the long view) fluctuations.

It's still speculation, but it's long term, less work, and the potential upside is greater.

I know many people advocate this under the name dollar cost averaging.  Which is fine if your main currency is dollars!  Just thought I would mention the strategy again to give some perspective to all the short termers playing the currenct market.

[were not]

Having spent a long time reading all of "How a floating blocksize limit inevitably leads towards centralization" and related threads, I want to summarise the proposals for introducing adaptive maximum block size to the protocol.

For focus's sake, please only join in with this thread if you are willing to operate under these assumptions for the scope of the thread:

• in the long term, incentive to secure bitcoin's transaction log
     must come from transaction fees
• Bitcoin should have potential scalability for everyone on the planet
     to make regular use of it, but equilibria are required to
     ensure scaling happens at a manageable rate

I appreciate that not everyone shares those assumptions, but please keep this thread for a discussion that locally accepts them for the sake of the discussion!

The idea of an adaptive algorithm has to be to make use of a negative feedback loop to achieve an desired equilibrium.
The canonical example of this in bitcoin is the way the difficulty of solving a block is related to the frequency of recently-found
blocks, producing an equilibrium around the interval of one block every ten minutes.

In the rest of this post I evaluate several proposals based on the equilibrium they are attempting to establish, making my own thoughts on the matter clearer towards the end.

First up we have:

How about tying the maximum block size to mining difficulty?
[...]

This provoked a fair bit of discussion.  The idea seems to be that miners will quit if it's no longer profitable for them to maintain
the full transaction log and mine.  It is unclear what equilibrium objectives this approach has, and I find it difficult to intuitively
say what equilibriums, if any, would be achieved by this adaptation.

Next up we have:

[...]
Second half-baked thought:

One reasonable concern is that if there is no "block size pressure" transaction fees will not be high enough to pay for sufficient mining.

Here's an idea: Reject blocks larger than 1 megabyte that do not include a total reward (subsidy+fees) of at least 50 BTC per megabyte.

[...]

It should be clear that this does not scale very far.  The cost is linear, and is predetermined per unit of data.  By the time you've reached blocks of 8 MB, transactors are spending 100% of the monetary base per annum in order to have the transaction log maintained. The equilibrium is that block size is simply limited by the high cost of each transaction, but the equilibrium is not precisely statable in terms of desirable properties of the system as a whole.

We also have:

[...]
How about
*To increase max block size by n%, more than 50% of fee paying transactions(must meet a minimum fee threshold to be counted) during the last difficulty window were not included in the next X blocks. Likewise we reduce the max block size by n%(down to a minimum of 1MB) whenever 100% of all paying transactions are included in the next X blocks.
[...]

The issue with this is how you set the minimum fee threshold?  You could set it to a value that makes sense now, but if it turned out that bitcoin could scale really really high, the minimum fee threshold would turn out to be too high itself, and is not itself adaptive. This approach is going along the right lines, but it doesn't seem to stem from an quantitative, fundamental objective to do with the bitcoin network.

Also:

[...]
Here's yet another alternative scheme:

1) Block size adjustments happen at the same time that network difficulty adjusts

2) On a block size adjustment, the size either stays the same or is increased by a fixed percentage (say, 10%). This percentage is a baked-in constant requiring a hard fork to change.

3) The block size is increased if more than 50% of the blocks in the previous interval have a size greater than or equal to 90% of the max block size. Both of the percentage thresholds are baked in.
[...]

This doesn't take the opportunity to link the size to transaction fees in any way, and seems vulnerable to spamming.

Then there's:

Since this locks in a minimum fee per transaction MB, what about scaling it with the square of the fees.

For example, every 2016 blocks, it is updated to

sqrt(MAX_BLOCK_SIZE in MB) = median(fees + minting) / 50
[...]

Same objection as to the 50 BTC per MiB proposal.  It just doesn't scale very far before all the value is being eaten by fees.
This time we get to around 64 MiB per block before 100% of the monetary base is spent per annum on securing the transaction log. Again, it is unclear what the objectives are for any equilibrium created.

Nearly finally, we have people suggesting that max block size doubles whenever block reward halves.  No dynamic equilibrium is created by doing this, and it's pure hope that the resulting numbers might produce the right incentives for network participants.

It seems to me that the starting point should be "what percentage of the total monetary base should transactors pay each year, in order to secure the transaction log".  This is a quantity about the system that has economic meaning and technical meaning within the protocol.  It basically keeps its meaning as the system grows. Why transactors?  Because in the long term holders pay nothing (the initial-distribution schedule winds down), and thus transactors pay everything.  That seems immutable.  Why per year?  This makes it easy for humans to reason about.  Annual amounts can be converted to per-block amounts once we're done setting the value.

Thus, this:

1) Block size adjustments happen at the same time that network difficulty adjusts (every 210,000 tx?)

2) On a block size adjustment, the size either stays the same or is increased by a fixed percentage (say, 10%). This percentage is a baked-in constant requiring a hard fork to change.

3) The block size is increased if more than 50% of the blocks in the previous interval have a sum of transaction fees greater than 50BTC minus the block subsidy. The 50BTC constant and the threshold percentage are baked in.

is a pretty decent starting point.  It allows unlimited growth of the maximum block size, but as soon as transaction fees, which are what secure the transaction log, dwindle below the threshold, the maximum block size shrinks again.  Equilibrium around a desirable property of the system as a whole!  Easily expressed as a precise quantitative statement ("long term, transactors should pay n % of the total monetary base per annum to those securing the transaction log, so long as the
max block size is above its floor value").

The exact proposal quoted above sets the amount at 6.25%-12.5% p.a., whereas I intuitively think it should be more like 3%.  I would probably also just state it in terms of the mean transaction fee over the last N blocks, as that is more directly linked to the objective than whether half of transactions are above a threshold.  3% p.a.  would work out at a mean of 12 BTC per block, so would be 0.0029 BTC per transaction to lift the block size off its 1 MiB floor.  Seems about right.

My full reply and subsequent discussion with misterbigg is at
https://bitcointalk.org/index.php?topic=144895.msg1546674#msg1546674 .

Hope that's a useful summary of all the adaptive algorithms proposed so far, even if you don't agree with the assumptions or
my conclusions.

Sorry if this has already been noted, but http://www.google.com/trends/explore?hl=en#q=buy%20bitcoins&cmpt=q

Since the minting of new coins is on a fixed schedule, would it make sense to count them all when doing a total valuation?

In a similar way to how if you were estimating the value of all the oil in the world, you would include proven reserves (ie reserves that are reasonably certain of being recoverable under current economic and political conditions)?

Or if only 50% of a company's shares are outstanding (the other 50% being treasury shares, ie owned by the company), the valuation of the company would be share price * total number of shares, not share price * number of outstanding shares?

If this approach is used, bitcoin's total value has exceeded the half billion USD point.

I'm trying to write a parser for the blockchain, but I can't find a written specification of the format.  Does such a thing exist?  I don't really fancy reverse engineering it from the data or another parser's source code, but I guess I'll have to if it's not specified.

The last price on MtGox's web interface shows 9.51 GBP.  This is clearly wrong; recent trades have been around 9.72.  Is this a known issue?  Are they showing last price based on a trade in a different currency, converted, or is it just buggy?

MtGox's times don't have any timezones.  As it's a business with global customers, this is surprising.  What timezone are the times shown in?

For safe keeping I am transferring a fixed amount to each of a number of addresses, which I've created in a single wallet in bitcoin-qt.  I've named each address and printed out their private keys to store somewhere. 

I've just noticed that it doesn't appear possible to view per-address balance in bitcoin-qt.  You can view the balance for the wallet as a whole in the "Overview" section.  You can view per-address transactions by right-clicking and choosing "Show transaction details" in the "Transactions" section.  But you can't view per-transaction balance?  Gah!

Can I also just check that conceptually, wallets are a purely client-side concept, just a way that a client aggregates multiple addresses together?

For around 7 minutes, there has been a crossover on Intersango.  The bids at 10.00 GBP have not executed against the asks at 9.79 GBP.  What gives?

When will the price reach 10 GBP on Intersango?

My bet is that it's some time in the next one minute.

I'm interested mainly in the UK situation for this, but also interested in how other countries with CGT handle this.

This must apply to other commodities where you can't tell one unit from another.  What I'm wondering is: if you bought several different batches of coins at different prices, and then you sell some coins, which ones should you / can consider yourself to be selling for CGT purposes? 

Is it "first in, first out"?  "last in, first out"?  Or can you choose, so long as each purchased unit is only counted a maximum of once in disposals? 

Does the answer differ depending on whether I took delivery of the bitoins (in which case I can mostly distinguish them), or left them on an exchange the whole time (in which case I can't distinguish them)?

So the forum software gives an resource "Show unread posts since last visit."

If I click on that, there's a list of threads that have replies to a post by me, but I can't see any way of clicking straight to the reply to my post.  I have to guess which page of the conversation it's on, and find it by inefficient scanning / searching.  Am I missing something?

Bids on Intersango GBP are worth a good few percent more than asks on Mtgox USD at the moment.  I would have thought someone would be arbitraging between this pair, but it seems not?  To do the arbitrage, obviously you need funds ready on both exchanges (the reason I'm not going to Mtgox USD right now is due to the delay that would occur in funding the account).  But I thought I'd read that arbitrage between the main exchanges was being taken care of fairly well these days?  It's annoying because there is pretty much no ask depth on Intersango GBP.  You could push it up to 12 GBP (18.82 USD)  with only a couple of thousand GBP.

Bids on Intersango GBP are worth a good few percent more than asks on Mtgox USD at the moment.  I would have thought someone would be arbitraging between this pair, but it seems not?  To do the arbitrage, obviously you need funds ready on both exchanges (the reason I'm not going to Mtgox USD right now is due to the delay that would occur in funding the account).  But I thought I'd read that arbitrage between the main exchanges was being taken care of fairly well these days?  It's annoying because there is pretty much no ask depth on Intersango GBP.  You could push it up to 12 GBP (18.82 USD)  with only a couple of thousand GBP.