Category Archives: Bitcoin

Let’s do some Taleb

Taleb recently published “Bitcoin, Currencies, and Fragility“, in which he makes a number of reasoning and understanding errors. Let’s dig in.

technologies that, ironically, all came out of the academic literature[3]

I have no fucking idea what’s supposed to be wrong with that.

Gold and other precious metals are largely maintenance free,

Gold requires storage and guarding, costs of which are very far from insignificant.

do not degrade over an historical horizon, and do not require maintenance to refresh their physical properties over time.

Wait, since when is that the case for Bitcoin? For all I care miners could stop mining for 500 years, after which they could very well start again, I’d still have my buttcoins safe and sound, and after a couple of weeks, difficulty adjustment kicking in would make the network as secure as it needs to be.

Not even mentioning that the less people mine Bitcoin, the more they get incentivized to get back at it. Moving on.

A central result (even principle) in the rational expectations and securities pricing literature is that, thanks to the law of iterated expectations, if we expect now that we will expect the price to vary at some point in the future, then by backward induction such a variation must be incorporated in the price now. […] Earnings-free assets with no residual value are problematic. The implication is that, owing to the absence of any explicit yield benefitting the holder of bitcoin, if we expect that at any point in the future the value will be zero when miners are extinct, the technology becomes obsolete, or future generations get into other such “assets” and bitcoin loses its appeal for them, then the value must be zero now.

The reciprocal being quite obviously that given the current market price of Bitcoin no one seriously expects the “miners to extinct” (how would they?), “the technology becoming obsolete” (spoiler: Bitcoin’s value is not in its technology), or “future generations favouring some random shitcoin”.

Metals have ample industrial uses

The “Bitcoin has no fundamental value” meme has been done to death by now, come the fuck on.

We cannot expect a book entry on a ledger that requires active maintenance by interested and incentivized people to keep its physical presence

The bit Taleb seems to be missing in his understanding is that Bitcoin does not require “active maintenance”, as explained earlier. Miners could theoretically all shutdown and get back up a year later without my Bitcoins disappearing, or being stolen. And again, the existence of miners is a stable equilibrium, the less mining there is, the higher the incentive to fire up a miner.

While the path dependence concept is sound, its application to the existence of Bitcoin is based on dubious reasoning, faulty premises, and a complete disregard on mining incentives.

As discussed in[7], technologies tend to be supplanted by other technologies

Except Bitcoin really isn’t a “technology”. If its value were based on its technological superiority it would indeed be worth ~0. There’s much more sophisticated (technologically speaking) cryptocurrencies around, why haven’t they taken over Bitcoin despite being around for years?

Furthermore bitcoin is supposed to be hacker-proof and is based on total infallibility in the future, not just at present. It is crucial that bitcoin is based on perfect immortality; unlike conventional assets, the slightest mortality rate puts its value at 0

Bitcoin history shows that this is not true. He forgets the human element. Some very serious bugs were found, and fixed in coordination with the large miners. An example of this is the 2013 fork bug, where common incentives and interests allowed developers and miners to coordinate an emergency fix.

Bitcoin would be allowed to escape a valuation methodology had it proven to be a medium of exchange or satisfied the condition for a numeraire from which other goods could be priced. But currently it is not, as we will see next.

Let’s translate: “Bitcoin fits no valuation model I know of, so let’s normatively declare it to be worth zero”.

There is a mistaken conflation between success for a “digital currency”, which requires some stability and usability, and speculative price appreciation.

Conversely, there is a mistake conflation by Taleb between his own personal opinions and aspirations, and what is either interesting or relevant.

Transactions in bitcoin are considerably more expensive than wire services or other modes of transfers

Try transferring a couple million dollars, see how that compares.

while you can instantly buy a cup of coffee with your cell phone, you would need to wait ten minutes if you used bitcoin

At this point I’m starting to feel slightly stupid for expecting better from Taleb.

I’ll stop here, I don’t really feel like getting into the whole economic side of the discussion, the first part of the article already disqualifies Taleb on the whole matter, and whether one thinks commodity-based money is a good idea or not is largely irrelevant, Bitcoin is not going anywhere.

Bye Mircea

Yesterday I found out about Mircea Popescu having drowned at sea. That made me quite sad indeed. Hannah confirmed it, and by the replies she left on her comments it does seem to actually be Hannah.

Although we weren’t friends and I didn’t expect to be invited for tea anytime soon, I still kept
an ear out for what the man had to say.

Because I valued his view of the world, I valued the way he didn’t give a shit about whatever anyone thought of him. I saw him as someone who valued speaking the truth as he saw it, and most of the time I felt his view of the truth was something that the world gained to know, if only to think about.

His view on Bitcoin matched my own, as something essential and fundamental, something that didn’t ask permission to anyone to be its own, new, thing. Something that had more in common with a new fundamental law of physics than a simple piece of software.

His view on life in general and on personal relationships in particular got me thinking, because he was asking the hard questions. What’s the point of life if not to live it fully, uncompromisingly, according to one’s own ethics? What is the point of personal relationships, if one’s time is spent calculating and working around other’s feelings and expectations?

I feel for the ones he held close to him and my thoughts go to them. I was very upset when I saw trilema.com had gone down, and especially upset at myself for not having kept a copy of its texts, hopefully the dulap mirror download that’s currently in progress on my computer will finish without errors so that I’ll be able to set up a mirror if trilema doesn’t end up coming back up.

Bye Mircea, the French guy will miss you.

mp_en_viaje: shocking, i suppose, but in the end, it’s what we’ve got.

Bitcoin et valeur intrinsèque

Quand les gens parlent de Bitcoin et de son absence présumée de “valeur intrinsèque” ils peuvent penser à deux choses différentes. “L’utilité résiduelle”, ou bien “la mesure d’une valeur qui serait absolue et indépendante de l’observateur”.

Cette seconde notion n’a pas de fondement réel, il n’existe pas de valeur qu’on pourrait attribuer auc choses qui serait objective et indépendante d’un observateur. La valeur est nécessairement subjective, et plus encore elle dépend du contexte.

Pour s’en convaincre il suffit de faire une expérience de pensée élémentaire.

Un observateur dispose d’un fusil, d’une saucisse knacki, et d’un Bitcoin dans son brainwallet.

La valeur que l’observateur accordera à ces trois objets changera nécessairement en fonction du contexte. Si on demandait à l’observateur de choisir un seul de ces objets, sa réponse dépendrait de la situation.

À l’approche d’un animal menaçant il est bien évident que l’observateur choisirait le fusil. Dans un contexte de pénurie généralisée et de famine, la knacki aurait subjectivement une valeur bien plus élevée.

S’il s’agit de se soustraire à un régime oppresseur, et dans la perspective d’une fouille au corps il est bien évident que le Bitcoin aurait la faveur de notre sujet.

La valeur d’une chose est donc nécessairement empreinte de subjectivité, il n’existe pas de mesure scalaire qu’on pourrait attribuer aux choses indépendemment de l’existence d’un observateur.

L’autre sens qu’on peut donner à la notion de “valeur intrinsèque” est celle “d’utilité résiduelle” (qui est implicitement présentée dans ce genre d’argument comme le fondement de la valeur de marché observable). L’idée étant que l’absence d’utilité résiduelle de Bitcoin le rendrait valorisé de manière purement spéculative par le marché.

Pourtant il apparaît bien évident que Bitcoin possède une grande valeur d’usage dans la mesure ou il permet de transmettre de la valeur de manière souveraine (sans l’intervention d’aucune partie qui serait en mesure de censurer ou d’empêcher une transaction). Il permet de posséder physiquement une unité de valeur, de la transporter dans sa tête, tout en ayant l’assurance qu’aucun pouvoir politique ne pourra en altérer la nature et la quantité (et c’est précisément cette indépendance par rapport au politique et à la majorité bien-pensante qui est nécessaire pour son usage en tant que valeur de réserve neutre).

L’argument “Bitcoin n’a pas de valeur intrinsèque” est donc doublement dénué de substance.

Removing the wallet from TRB, first thoughts

This article summarizes my first thoughts about the correct way a Bitcoin client should enable its operator to issue transactions. It is based on my reflexion as well as my experience in broadcasting dozens of hand-crafted transactions for which the bitcoin-core built-in wallet repeatedly demonstrated its ineptitude.

As it currently stands, the wallet is an embedded part of the reference implementation. This is problematic for a variety of reasons, the most fundamental one has been exposed by Mircea Popescu in “How to cut the wallet“.

The job of the node is to connect to others via the Internet, and to exchange information with them. The job of the wallet is to prevent others from connecting via the Internet, which makes the tension quite evident.

Today, a Bitcoin client consists of three main pieces:

  1. The network protocol management part, that connects to peers and exchanges data with them;
  2. The data storage and validation part;
  3. The wallet, which uses the previous pieces to create transactions, sign and broadcast them.

The point of this discussion is to show that cutting the wallet entirely off of TRB is (1) desirable, and (2) requires only a small interface for a subset of (a) and (b)’s functionality to allow much better wallets to be built on top of TRB.

There are numerous reasons for which detaching the wallet is, in my opinion, highly desirable:

  • the job of the node and the wallet are very different (there only exists a functional dependence on the former by the latter);
  • as already stated, their coexistence in the same binary creates a fundamental tension between what the node requires, and what the wallet tries to avoid;
  • there exists no valid reason to keep the code for a wallet embedded right in the code that operates a critical piece of infrastructure, except for the current lack of a sane alternative;
  • the wallet code touches a lot of parts in TRB and adds complexity and bloat to the whole thing, I want TRB generating my addresses as much as I want my e-mail client generating my PGP keys;
  • it does a very bad job at crafting transactions with a lot of shitty heuristics, assumptions and places various artificial and unwarranted constraints are enforced on the operator;
  • external wallets, talking to a small and clearly delimited interface of TRB, could be made as very simple overlays managing a set of keys, with as much control given to the operator as his particular use case mandates;

The required interface for an external wallet, at TRB-level, is quite limited:

  • Query the UTXO for unspent outputs given a set of addresses.
  • Put an arbitrary transaction in the mempool, optionally nuking any conflicting ones[1]

While the latter doesn’t present much implementation challenges, the former is a whole different story, depending on the particular way it is implemented. In my opinion, the correct way to implement it would be to index every single UTXOs with its address (or even all TXOs, soyons fous) in order to be able to efficiently return the set of UTXOs (or TXOs if history’s required) for a given set of addresses. A lighter option would be to allow the operator to specify a list of addresses he’s interested in, and index only those.

The second option is what already exists, but it forces the conservation of the “reindexing” logic,  a list of monitored addresses along with a lot of wallet-related code. The first option allows TRB to remove this functionality completely, serve an arbitrary number of wallets, and get rid of any “sensitive” information, such as the list of addresses an operator is interested in.

This TXOs-indexed-by-address is essentially the index Electrum servers are maintaining, different implementations manage to pack this data in 20 to 50gb (the latter being the index packed pretty inefficiently and keeping not only UTXOs but also partial history for all addresses, up to a certain arbitrary count). The indexing of only a specific set of address would obviously come orders of magnitude cheaper but leave the node coupled to the wallet by having to know which addresses are part of the wallet, and which aren’t, or more precisely those which are ~definitely not~ part of the wallet.

Keeping the history indexed by address doesn’t really make much sense to me, it seems to me it’s the wallet’s job to keep the various receipts until they’re binned or archived (which doesn’t prevent a blockchain scan to be performed, should it be necessary to retrieve it again).

Yet another option might simply be to naively scan the UTXO set for any “gimme the unspent outs for these addresses” request the client gets. As of today the UTXO set is ~1.6gb. Obviously this means the transaction history for addresses can’t be directly queried from the node without a full blockchain rescan.

Whatever the approach, the node simply has to output UTXOs, and receive signed transactions as input for broadcast.

To be continued, comments more than welcome !

 


[1] Unlike PRB, which somehow thinks whatever’s already in your mempool has precedence over what you’re explicitly telling it to swallow.

Two cans, one string. Kraken edition.

Mauritius is a pretty boring country, and given the apparent lack of proper casinos I elected to give Kraken a chance and try out their “margin trading” feature[1].

Long story short I ended up opening a short for 20 BTC around 749 EUR per. My lack of faith, disturbing as it was, ended up promptly rewarded with a well-deserved beating. After some additional servings of the same flavour of fail I figured that ending the blood-bath was well overdue.

Equipped with this firm intention, I merrily headed to the Kraken web interface, opened up the “positions” dashboard, and (naively, I confess) clicked the “Close position” button, or whatever it was labeled.

This opened the “New order” screen, with fields pre-filled to perform a margin trade in the opposite direction for the same amount, the logic being that it’d cancel out the existing position, effectively liquidating it.

Having proceeded to innocently click on the inviting “Submit” button I ended up blocked with a “Margin allowance exceeded message”. Pause. What the fuck did it even mean to not have enough margin to close a position? A second attempt yielded the very same result.

My subsequent message to their support plainly stated the issue:

Hello,

I’ve been unable to close a 20 BTC short I opened around ~749 XBT/EUR.
I have more than enough funds on my account to take this loss without problems, yet your interface keeps telling me that closing my position would « Exceed my margin » !

This position is quite clearly in the red which is my responsibility, letting me close it and take my loss is your responsibility. I obviously can’t accept the loss part that’s due to your system not working correctly.
I should obviously not be limited by « margin » considerations when the trade I’m making is reducing my exposure and decreasing the size of my net position.

The position I want closed was opened with the [redacted] order, my account name is [redacted].

Please let me know ASAP.

David FRANCOIS

A day later, after some excuses about “busy”, “working hard to clear the queue”, I got an actual answer from Mike, let’s call him Luc.

Hi David,

I am consulting with our trading specialists at the moment to confirm exactly what the cause of this may be. I do note that you currently have 4 open orders (albeit untouched ones). Can you cancel these orders and then attempt your position closing order again and let me know how it goes?

Best regards,

Mike
Kraken Client Engagement

Luc was indeed correct, I did have four untriggered STOP[2] bids, they had however never been activated (the confusion in the vocabulary between “untouched”, as in “in the book but not yet touched” and “untriggered” as in “in the pending stops, but not triggered, and as such not even in the order book” continued throughout).

So far there were two problems: the first being that liquidating the position apparently required some sort of “margin allowance” in other words “borrowing money”, and the second being that Kraken’s support suggestion was to try something that should have had no effect on one’s ability to borrow money (cancelling orders that hadn’t been activated).

I therefore, logically, answered that:

If your engine has a measure of « allowed margin » that is impacted by these orders and prevented me from closing the position, then that’s obviously a bug on your end that requires fixing on your end, and compensation for the extra loss I’m incurring due to my impossibility to close the position.

After consulting with the “trading specialists”, Luc ended up telling me that, lo and behold, these untriggered orders somehow did indeed count against a borrowing limit, nevermind that closing a position shouldn’t require additional borrowing, and nevermind that I should have theoretically received the bulk of the funds required to buy back the shorted Bitcoins through the very sale of… the shorted Bitcoins!

Hi David,

We have confirmed that your open orders, even while untouched do count towards your total margin borrow limit due to this there was insufficient remaining EUR margin borrow limit for you to place one single order to close your position.

Your original position was a XBT/EUR sell on margin, meaning that the security borrowed for this was XBT so was counted against your XBT margin borrow limit.

Your original closing orders and the further closing position where you encountered the error are all XBT/EUR buy orders on margin which are counted against your EUR margin borrow limit. There is no way for us to tell in advance which pending orders you may have which will close or even reverse an open position so all are counted towards your margin borrow limit.

[Additional servings of apologies for inconveniences and SFYLs]

After pointing out to them how their own documentation plainly contradicted the actual behaviour of their system, they came back with the following gem:

The only problem we acknowledge here is that we could be more explicit in our documentation about the fact that orders placed which will create margin positions are counted towards your Margin Borrow limit as soon as they are created, regardless of whether they have been fully or partially filled yet. We will be updating our support centre documentation on Margin Borrow limits to make sure this is clearer.

So here we are, let’s kick back and let it sink in for a minute.

Ready? The translation reads: “yes, our software doesn’t behave like its documentation said it should, we will update this documentation, but this isn’t a bug[3], because reasons”. In other words: “Fuck you and SFYL lol”.

The gist of the insanity can be enumerated as follows:

  • Liquidating existing positions is somehow subjected to borrowing limits, in addition to those already checked against when opening the position,
  • These “borrowing limits” are computed by also taking into account orders that haven’t activated at all (not untouched, not filled partially, not filled completely, but NOT ACTIVATED AT ALL),
  • When closing a position there’s suddenly no trace of the proceeds of the initial trade which created the position, which in any system that’s not completely insane, would obviously be used in priority when liquidating,
  • Given these insane rules you can put yourself in a position where it is not possible to liquidate a position other by dicking around manually in small chunks and without the ability to place STOPs[4]!

In conclusion I’ll point out once again the fucking elephant in the room: the proceeds of a trade with borrowed assets are somehow not yours to use to make the opposite trade in order to return said borrowed assets. Because Kraken is a special, and because they’ll soon update their documentation to redefine the meaning of the word “borrow”, and because “sorry for the inconvenience, don’t forget to protect your account with a second authentication factor”.

 


[1] Margin trading, for the noobs among us, basically consists in trading funds one doesn’t have by borrowing them, on the premise that one should at least provide enough cash upfront to cover for the variations in value of the resulting position.

For example, should one want to bet on a Bitcoin’s price increase, one could provide 1`000 EUR upfront, borrow 10`000 EUR and buy the equivalent of these 10`000 EUR in Bitcoin. Should the price of Bitcoin appreciate, one could, at any time, liquidate this position by selling the Bitcoin, return the 10`000 EUR to the lender, and pocket the difference as profit. Should one’s prediction end up incorrect, the loss would be accounted against the cash deposit. This is also referred to as “leveraged trading”. Usually, to minimize counterparty risk, the lender can force a position to be liquidated when the net loss gets close the to the deposited cash, also referred to as “collateral”.

[2] Again, for the noobs among us, STOP orders are orders that get automatically activated once the price reaches a certain point, they’re quite useful to automatically take a profit on profitable positions, or cut losses on unprofitable ones.

[3] Once in a while, paedopedia makes itself useful and aptly notes that: “A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways”

[4] For example, their “Margin borrow limits” state a Tier-3 trader could borrow 150 BTC and 25kEUR for the purpose of margin trading. If such a trader were to short BTC up to the borrowing limit, and given the current BTC market price (around ~900 EUR per), it would not be possible to liquidate this position in one go without hitting the EUR borrowing limit. In other words one would have to do it manually in at least six passes. And since apparently untriggered STOPs also count against these limits, one would not have the option to place stop-loss or take-profit orders for 100% of the position size. If that doesn’t demonstrate a completely broken design, I don’t know what else could…

BitBet conclusion statement

As the final settlement transaction has been broadcast, the receivership is now considered officially closed. All BitBet customers with outstanding bets have either been fully refunded, or paid out of their winnings.

While the receivership itself was of moderate complexity, my job was made considerably easier by the help and professionalism of Mircea Popescu and Matic Kočevar. I thank both of them very much for entrusting me with this task. I hope they, and the other stakeholders, are satisfied with my service.

The Bitcoin Foundation’s tax, due on the receiver’s fee, has been paid.

BitBet proposed settlement transaction

As promised after the successful sale of the BitBet assets and after the correct reception of the rest of the cash, the final settlement transaction is being put on display as an opportunity for the public to voice any complaints or concerns.

If no valid points are raised that would require modifications by Wednesday the 20th of April the transaction will be signed, broadcast, and the BitBet receivership will be considered closed.

Please not that amounts going to identical addresses are aggregated, the amounts owed to Mircea Popescu have already been deducted.

As usual, questions and comments are welcome.

Second version of the raw transaction.

The raw transaction.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

TXID of the the second version of the unsigned BitBet receivership final
settlement transaction being put on public display today.

ab1e4c34b1108c5e8d7285ff8761ab8a2768b2263bab894a695c3f693521c3fb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXEoIhAAoJEBMojqsBcTQoDHEH/RDbZ8QNrKiTfQIBDr9e5l8x
yxn573jDVUf9NyfYJDZkF1dgxcWUN7WLu5C2z1MWqA5e9loLrDNGP9YCJzrOeksk
3nvBg6/MOb6l2+Ivaona5bWoeZF2SnZircq+QhFgSMtZUzrw9nOkM87ONW29Zeq6
A96FPVsmI9SgiJS7geRT5Cu4txKov9xbwYG2akVPqF5zT/0XE9L9lz8bGtEd10Zj
XcfuEY6RZfyd77DFx/TeUWzpyDwUZaIRIS5fsUcn10tYQursDZe2zgOMYnVhGFON
YvA0NitGEwgGxi6ThyyYJaylH/94TXGse3ySqeiCX2tSm57Lxf7X9VK2sJRdrnc=
=xz+S
-----END PGP SIGNATURE-----

BitBet receivership third progress report

April 14th update: As discussed in #trilema [1, 2], it appears BitBet owes Mircea Popescu the sum of 0.8 BTC for the seeding of bets that has not been billed to the company yet, as was normally the case. This includes all bets[5] that were seeded after the last report certified by both representatives. This amount has been accounted for in the liabilities.

Erratum: BitBet’s receivership first report mentioned a hot wallet amount that was off by 0.00040948 BTC, the report has been corrected.

State of the receivership process

As planned, the assets auction ended last week. The 86 BTC payment has been received
and confirmed. The actual assets have been transferred, eight bets have been resolved[1], the rest will be refunded.

Assets: 1`040.78385211 BTC, detailed as:
  - Cash: 1`040.78385211 BTC (of which 841.33337474 BTC is currently under my control): 
    (1) Outstanding bets: 942.81955914 BTC,
    (2) Unpaid resolved bets: 8.75451297 BTC,
    (3) Zeroconf bets on unhandled proposals: 1.99978000 BTC,
    (4) Gracious donations: 1.21000000 BTC,
    (5) Sale of the assets: 86.00000000 BTC.    

Liabilities: 961.58027519 BTC, detailed as:
 - House bets paid for by Mircea Popescu: 0.8 BTC
 - Receiver's fee: 13.37 BTC
 - Bettor winnings: 331.01977044 BTC[2]
 - Bettor refunds for unresolved bets: 614.38072474 BTC[3]
 - Bettor refunds for zeroconf bets on un-handled proposals: 1.99978000 BTC
 - Bitcoin transaction fee for the payout transaction: 0.01000001 BTC[4]

Net surplus: 79.20357692 BTC

This net surplus is to be distributed to shareholders. The 5 million MPEx-traded shares are being guaranteed a minimum value of 0.00001 BTC per amounting to a 50 BTC total. This leaves 29.20357692 BTC to be split equally between Matic Kočevar and Mircea Popescu, joint holders of the rest of the 10 million BitBet shares.

See the detailed liabilities table for more information and don’t hesitate to point out any errors or inconsistencies in the comments.

[1] The resolved bets:

[2] The ‘bettor winnings’ item does not include the house bets winnings as a liability anymore (0.67314231 BTC). The sum of the house bet winnings and the bettor winnings differs from the previously reported sum by 115 satoshi as a result of rounding being applied in one case to the lump sum, and in the other case to each one of the amounts that will be paid out.

[3] The ‘bettor refunds for unresolved bets’ does not include the house bet refunds as a liability anymore (2.15000000 BTC)

[4] This particular amount was picked because the payout transaction will be quite large, and because an even number of satoshis was needed for the amount to split among the BitBet representatives.

[5] The bets that were seeded, but not billed to the company:

+---------------------+--------------------------------------------------------------------+
| Seeded              | Title                                                              |
+---------------------+--------------------------------------------------------------------+
| 2016-03-11 17:12:55 | John Kasich gets the Republican Party Nomination                   |
| 2016-03-07 04:31:49 | UK referendum will result in favour of remaining in EU             |
| 2016-03-01 20:21:45 | Bitcoin to top $900 before Sep 2016                                |
| 2016-02-29 16:50:15 | Donald Trump will win the 2016 United States Presidential Election |
| 2016-02-12 06:16:02 | AlphaGo will defeat Lee Sedol overall in March 2016 match          |
| 2016-02-12 06:00:42 | Ethereum to top $1 billion market cap before 2017                  |
| 2016-02-04 17:46:50 | Parties SMER-SD and SNS to win supermajority in Slovak parliament  |
| 2016-02-04 06:42:37 | Ted Cruz will be the Republicans' 2016 Presidential Nominee        |
+---------------------+--------------------------------------------------------------------+

BitBet auction: a winrar is znort987

Update April 8th: The payment has correctly confirmed, BitBet’s new owner can take possession of the actual goods and is kindly asked to issue a receipt to the receiver.

As announced, the BitBet auction has taken place, and after a few deadline extensions and an almost-winner, znort987 (9F1C2534ACEE115E18EF02A5FD5AA2A5E26602B0) ended up being the last man standing.

In order to proceed, he is kindly asked to transfer the sum of 86 BTC to 1DavouTAsveznCFHsz688xvbrRAq4u2qm8. Once the payment is confirmed, the assets will be transferred.

I will then start working on creating the final settlement transaction paying all outstanding liabilities. Once the transaction is ready it will be put on public display for a few days. If no complaints are made or discrepancies pointed out, it’ll be signed and broadcast.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In order to complete the sale of the BitBet assets to 9F1C2534ACEE115E18EF02A5FD5AA2A5E26602B0,
the sum of 86 BTC is to be transferred to the 1DavouTAsveznCFHsz688xvbrRAq4u2qm8 address.

Once the payment is confirmed, the assets will be transferred to their new owner.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJXBvLGAAoJEBMojqsBcTQo1rkH/0tm8u8f91+Tt4JjU7L1ZPj6
CE5MoOSjlLyYoFZyBbH3yJImJseDpvDxO+DA+MDK+SPoS8WEP7bpSLcA7xlwdc7h
kPhvq4klSUSvHcAFXwYpjq/E1QxgPL2+tPVWSgT7eMWmflXKhjBpBtb47cUZwJCz
x9z7KCqhjzcwqSB7iRNJnbuIZv707VYaROd211/4N8AvKanPZLVTUlDOladyCkdS
M9Cyf6nG8RsMkB2blb2jad9FlWgXWb8ZlrifoEp9WFKXeYpw1AeJkhqWl1rTuXrm
uYjWcmuSwOQWF7tC4Fy+bm3YJYdNjOuvzA9weaHo40+DHfFWpayGWogx2X/8bsM=
=wK75
-----END PGP SIGNATURE-----

BitBet auction deadline postponed (slightly)

As Pete Dushenski aptly points out, “the end of Wednesday the 6th of April” doesn’t precisely define a deadline for the BitBet assets auction.

Therefore it appears to me that, in the interest of maximizing the auction revenue, the most sensible course of action is to interpret this as “the end of Wednesday the 6th of April in whatever timezone this event happens last”.

The precise auction deadline is therefore 2016-04-06 23:59:59 GMT-12, which conveniently reduces to “Thursday the 7th of April at noon GMT”.

As already said the auction ends one hour after the last best bid improving the previous one by over one Bitcoin has been posted, or at the specified deadline, whichever comes last.

The conclusion of all of this naturally being:

<mircea_popescu> you’re like totally a noob receiver and everything.