The PGP Strong Set is the largest set of user keys for which ever member of the set is connected through a web of trust to every other member of the strong set. Who is a member?

• Sipa
• Keefe
• sneak
• theymos

Anyone else?

[willing to accept payment in bitcoin and vow not to exchange those bitcoin for fiat money?]

Are developers, merchants, or anyone offering goods or services willing to accept payment in bitcoin and vow not to exchange those bitcoin for fiat money?

Are consumers more likely to pay for services and goods if the receiving party vowed not to exchange those bitcoin for fiat money?

I would. On both counts. If requested, I would sincerely vow not to exchange for dollars, euros nor any fiat currency, bitcoin that I received for any goods (tupilak, crafts, etc) or services (programming) I offer, particularly if the counter party took the same vow. Likewise, I'd be more willing to offer bitcoin if I trusted s/he would use the bitcoin within the bitcoin community. Anyone else?

[bitcoin did not originate as commodity]

Many economists have argued against bitcoin's adoption as a money because while it could be a medium of exchange, unit of account, and store of value, bitcoin did not originate as commodity. Many have argued that this historical property is not necessary, others like me have argued that a scarce bitcoin derives value from the transactional service that bitcoin makes possible, while others claim that the computational power required to validate the transactions back up the digital commodity. Few are confident with these assertions and therein lies the problem.

What if a bitcoin unit represented a promise to execute computation (or store encrypted data)? Either within the bitcoin network directly or externally but payed for in bitcoin. The idea is inspired directly from a slashdot dissenter quoted in part below. Bitcoin already has a scripting language, indeed all transactions are a common and immediately executed signed script.

Suppose one could compile a multi-threaded script and pay bitcoin "transaction" fees to have it executed by the enormous computational power of the network. Perhaps with different GPU vs CPU costs (memory, speed, etc). Then suppose that one could simply produce computational credit, the promise to compute a specific number of cycles. Block reward would simply be an inflationary tax for otherwise 'idle cycles' as it more or less is today.

I have not yet come up with a way to merge useful computational proof-of-work with validation (hash < target), but I believe if an elegant solution (both economic and technical) were discovered, bitcoin would be unstoppable.

If a bitcoin had been a promise to do some computation work in the future, then it may have had some value, because people need computational work done. For example, something like Amazon's compute cloud could potentially back a currency, because the service of running a VM for some number of CPU seconds is fungible and - importantly - people actually want it. No one wants the work that is done to generate a bitcoin, so the coin itself is worthless. Its value is based entirely on the premise that other people will want it in the future, but that's just a pyramid scheme.

I'm not a religious man, but I find it interesting that Judeo-Christian-Islamic teachings strongly opposed usury and debt. In fact, the entire motif of original sin, through redemption, judgement and forgivess are all related to debt. If you replaced every instance of the word 'sin' in the bible with 'debt', I think it would make just as much, if not more sense.

Sin in original Greek hamartia (ἁμαρτία) and Hebrew hatta'at or hata' (חָטָא) means "to miss the mark" or failure to repay DEBT, and could be repaid through sacrifice. Satan tempts us with debt, the fortunes of the flesh now with pain and suffering in the future. We are born with original debt.

According to David Graeber:

In Sanskrit, Hebrew, Aramaic, ‘debt,’ ‘guilt,’ and ‘sin’ are actually the same word. Much of the language of the great religious movements – reckoning, redemption, karmic accounting and the like – are drawn from the language of ancient finance.

Despite the many advantages of bitcoin, they don't make pricing easy. If your operations are tied to a particular fiat currency (euro, dollars, peso...), how do you set your prices in bitcoin, last close, weighted average? And how much do you mark up prices as a hedge against inflation risk? Do you take other precautions?

From 8 June to 9 September, each bitcoin has lost about a dollar in value on average every three days. Over those three months (93 days), bitcoin has devalued 88%. The largest single day drop was 46% on the 11th of June and a 42% drop just last week. Certainly there have also been spectacular gains, but the seasonal trend has been down and the volatility risks great.

Despite this volatility, a merchant is in no way required to hold bitcoins. The value only needs to hold between setting a price and purchase. Any longer is market speculation. Do merchants hedge against 40% drops and for 2% daily inflation, perhaps marking prices up 22% ?

Code:

 Date   High-Low Devaluation
======   ======== ===========
11 Jun   24 - 13       45.83%
 6 Aug   10 - 5.7      43.00%
8-9 Sp   7.2- 4.2      41.66%
 1 May   4.1- 2.5      39.02%
 9 Sep   6.5- 4        38.46%
26 Aug   10 - 7.5      25.00%

[Greenlandic tupilaks]

Hi sub-arctic friends, I'm selling Greenlandic tupilaks which are traditional magic figures made from bone (sorry I'm not exporting human bone, don't ask), claws, tusks, or more recently from precious metals. These often-grotesque statues are used to curse or magically kill enemies, though none of those I'm selling will have been 'activated' . All of them are hand made from native wild animals such as reindeer, muskox, pheasant, fox, seal, whale, walrus, and polar bear (can not export sea mamals to most countries). Shipping is a bit slow and expensive from Greenland, but otherwise I can get good deals on the pieces and the profits will be shared with the artists. They come in numerous shapes and sizes, from cute to ugly and scary. Key chains are about 7 BTC, large complex pieces can be 50 BTC or much more. I'm also selling beautiful hand-made modern and traditional knives, but first, I'd like to scope out the interest. Let me know what country you are in so we can trade only legal animal products. Note that the Greenlanders use and consume all of the animal even when killed in self defense, the sale of these products support the local economy. Wikipedia has a decent description Google images

I'm traveling tomorrow, with few internet access opportunities, and concerned about the bitcoin market at the moment. I wonder if anyone is offering investment management services. Are their published rates, performance records, satisfied customers, otc-ratings, etc? Similarly, is there already, or is anyone interested in starting, a bitcoin trading club?

[blocks aregenerated every 10 minutes]

Why was a ~ten minute block generation rate chosen rather than say ten seconds?

Perhaps someone can point me to an extant article or discussion regarding this topic. I would like to read previous arguments. In Satoshi's paper I only see one reference (when discussing disk space).

A block header with no transactions would be about 80 bytes. If we suppose blocks are
generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems
typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
1.2GB per year, storage should not be a problem even if the block headers must be kept in
memory.

Is that the crux of it - to reduce the size of the entire block chain stored in RAM? Or is network latency considered - minimizing the number of competing longest block chains by assuming ten minutes is sufficient time to propagate a single block to the entire network? Perhaps there are other (psychological, economical) arguments?

Too often I can't find previous articles despite providing excellent search queries. For example, if I know most of the words in the TITLE and the original poster's USERNAME, I still might get zero (0) hits. Perhaps the search form should just redirect input to google appending site:forum.bitcoin.org ?

GOLD to go (gold dispensing ATM in Madrid, Spain)

http://www.digitaljournal.com/video/?448570901

Early last month, while trying to understand keys, wallets, security, and backup, I believe I inadvertently attempted to double spend. The client is not handling it gracefully (the UI displays two semi-duplicate transactions neither of which occurred and a zero balance even after thousands of blocks). While I am not entirely sure about the order of events, I believe the following steps might be correct:

I created a wallet (A), received coins, sent coins, closed client.

I copied wallet, rescanned with new copy (B), and sent the same coins to different addresses.

Now, when I open wallet A, I see a transaction sent to <blank> address with almost 7000 confirmations. In the new client I ALSO have a similar transaction sent to an address not known to the blockexplorer with the exact same June timestamp but with 0/unconfirmed.

While I would like to think the coins are still available to me, I believe they were actually sent (from the copied B wallet). I'll be happy to disclose the addresses in question to client developers (PM me) in order to improve the client transactional log.

--

But aside from this odd behavior, it highlights the need for more address transparency. I can not see to what address the transaction is sending (abnormal), nor can I see from which address the coins are coming (normal). In this case, I can guess at the sending addresses because I've received with a limited number of addresses. I do not know what addresses are 'hidden' in my wallet, and therefore do not know whether wallet A is a pure subset of B and can thus be deleted.

My personal feeling on the UX matter is to think of and display addresses as accounts and a wallet as a portfolio. I think the wallet metaphor creates confusion.

[When will Mt. Gox start trading?]

There seems to be great anticipation for trading to begin on Mt. Gox. So rather than wait for coding to completion, I thought I'd offer a Futures Bet (which I'll process manually at closing time). I'll be around here and on irc (typically otc).

=======================

Event: When will Mt. Gox start trading?

GeneralRules: http://pastehtml.com/view/ay9nwzagt.html

EventAddress: 1B2oHq8dCwLegguskVJEyuXSsz68HRJi9g

OpeningTime: 2011-06-25 00:00 UTC ("June 24 at 8pm in New York", "25 June 02:00 in the morning in Paris" and "08:00 in Beijing")

ClosingTime: 2011-07-05 00:00 UTC ("July 4 at 8pm in New York", "5 July 02:00 in the morning in Paris", "08:00 in Beijing"). All bets posted one full hour before the hour in which Mt. Gox begins trading will be retro-actively invalid (funds returned to sender minus TransactionFee).

ExpirationTime: same as ClosingTime (expect at least 24 hours to post calculations, and receive payouts).

BetPosition: represents the hour after 2011-06-25 00:00 UTC in which Mt. Gox. begins trading (and sustains trading for at least 60 minutes).

EventRules and Comments:
What follows are additional rules, exceptions, and comments to the General Rules: http://pastehtml.com/view/ay9nwzagt.html

The BetPosition is indicated with the fourth, fifth, and sixth decimal place of the Wager. For example, a bet of 1.000001 sent to the EventAddress is a Wager of 1.000001 predicting trading commencing 2011-06-25 between 01:00 and 01:59:59.99 UTC. A bet of 1.000100 sent to the EventAddress is a Wager of 1.0001 on position 100, in other words a prediction that trading will commence 4 days, and 4 hours later (2011-06-29 04:00-04:59:59.99 UTC).

All participants should read the General Rules. Payouts are weighted, based upon the valid block timestamp in which the wager was sent! Bets before the OpeningTime 25 June have 100% risk and thus 0% penalty. All bets after the ClosingTime will produce no profit. Bets made in three days (28 June) have about a 50% penalty (penalties are part of the pool, penalty is roughly (hour/240)^2). Use a local wallet to send bets, because payouts will be returned to the same address (do not use an e-wallet).

The rules are open to discussion, but will not likely change unless there are severe calculation errors or clarification requirements.

General Rules: http://pastehtml.com/view/ay9nwzagt.html

=======================

Suppose a small nation or colony decided to accept bitcoins to pay taxes and as a means to pay debt. Would that have positive or negative implications for the goals of the bitcoin community. And what would it take for bitcoin to be ready for this position if such a nation were shopping for a new currency?

I use (or would like to use) multiple wallets. For example, 1. public and 2. secure/backup. However, because internet usage is very expensive and slow, I want to reuse much of the .bitcoin/database. Simply removing the wallet.dat file (bitcoin.conf keypool=1) and restarting will crash the client on close. Having a theory as to why, I removed both the addr.dat and wallet.dat files and relaunched the BitCoin client.

Are only the addr.dat and wallet.dat files associated with a particular set of address/key pairs?

Is everything else generic distributed database stuff?

Or, as I suspect, is there data related to my wallet and thus my identity still scattered among the files, such as log files and blkindex, etc.

It seems to me data related to my wallet and identity should be distinctly isolated from the public distributed database files. My wallet/identifying data should change at a minimum. In my opinion, generating new addresses for change (even when 0 BTC) is an implementation detail that should either be manual or optional. The default 100 address pool has unexpected consequences, giving a false sense of backup security until perhaps loosing all money much later in time when restoring from backup. The binary nature of the wallet keeps people from merging, spliting, and generally understanding and maintaining their own wallet. If I want to 'launder' money and increase anonymity, I should distribute coins multiple times and at random intervals, not as a predictable operation along with every transaction which decreases my ability to restore from failure.