stuhood

1) Yes and no... the QT client has default/"suggested" transaction fees, but unless a block is completely full you're not likely to see any difference in processing time if you exclude a fee entirely [a]

2) As of recently [b], yes... you can add a small amount of junk data

3) When you send a transaction using input address(es) that don't add up to exactly the desired amount, there will be some "change", which needs to go to a new address. Thus, some of your change comes back to you at a new address.

4) Yes, that's possible. But you probably don't want to do that, since it leaks information [c]

----

[a] subject to some limitations: https://en.bitcoin.it/wiki/Transaction_fees#Sending

[b] https://bitcoinfoundation.org/blog/?p=290

[c] https://medium.com/p/7f95a386692f

Because bitcoin acts as a proxy between the buyer's local currency and the seller's local currency, regardless of what those are. Particularly in the case of digital goods, this opens a buyer up to accepting business from anywhere in the world.

Coinbase will let you sell up to 50 BTC per day, so if you don't mind waiting 2 or 3 days you can certainly buy a car with bitcoin.

You can donate BTC: https://archive.org/donate/bitcoin.php

The section on forkIO vs forkOS is interesting because the author does not mention implementing green threads atop the JVM. It would be feasible for Frege and its core libraries to use an implementation of "green threads" based on Promises or CPS under the covers in order to implement a concurrency model indistinguishable from Haskell's.

While it is true that the vast majority of JVM code you interact with is blocking and expects to own whatever OS thread it is running on, that could be treated as a concern of FFI, where untrusted/blocking code in Java land gets dedicated OS threads (similar to FuturePools/execution-contexts for scala Futures, or how you would manually isolate blocking code for Erlang or Go FFI.)

Additionally, the comment dismissing STM seems like an afterthought, because there are at least three JVM implementations (Clojure's, Scala's, and Multiverse)

But the main comment I was referring to was:

  To do serious concurrent work in an JVM environment is
  different and it will thus require different knowledge

... which suggests that the author isn't interested in supporting Haskell's idiomatic concurrency model atop the JVM, and is instead fine with the status quo of blocking code.

The conclusions of http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-fre... lead me to believe that the author knows significantly more about Haskell than about either the JVM or concurrency. I hope that the language is able to attract a healthy number of contributors in those areas before it begins to accrete it's own idiomatic concurrency patterns.

Well, you don't necessarily need to cash out to USD to withdraw from MtGox. Instead, you can transfer to an offline wallet with a few physical and/or cloud+encrypted backups.

@locksley: Couldn't the operator of blockchain.info game this by manipulating the output of their API?

Bitcoin is a decentralized system, so there is no reasonable place to put these IP restrictions.

If there is a single Bitcoin mining node (out of thousands[0]) that will accept your transaction, you can play.

[0] http://blockchain.info/connected-nodes

If you like loops, here it is with a for-comprehension:

  def complete_items(completed_binindex: Int, bin: ItemBin, nonterminal: Nonterminal, value: Value): MoreItems = {
    for {
      (item, v) <- bin.items
      _ <- expectedSymbol(item)
      nextValue <- grammar.nextValue(document, item.origin, bin.binindex, completed_binindex,
        nonterminal,item.ruleindex, item.dot, v, value)
    } yield {
      item.inc -> nextvalue
    }

La petite mort?

>$2,000,000 pizzas.

Haven't used it, but http://betsofbitco.in/ seems to have some traction.

Actually, assuming they had your permission, they could record all of this data remotely, just as you can: http://docs.timdorr.apiary.io/

Are you certain? https://en.bitcoin.it/wiki/Trade

"Cold storage" in Bitcoin parlance is a wallet that is completely disconnected from the network. Since a "wallet" is really just a collection of private keys, one example of cold storage is to scatter pieces of the wallet (M of N splitting) in physically secure locations like safe deposit boxes.

Bitcoin runs well over Tor: https://en.bitcoin.it/wiki/Tor

> (Everywhere excluding Iran, I guess. Is Bitcoin big in Iran?)

I wouldn't say 'big' exactly, but the participation is non-zero: http://blockchain.info/nodes-globe?series=48hrs

See http://en.wikipedia.org/wiki/Deniable_encryption

The current encoding of bitcoin on the wire allows for division to 8 decimal places, but there is discussion around improving the encoding sooner, rather than later. https://en.bitcoin.it/wiki/Divisibility_extension

Since the block reward is the only source of 'new' bitcoin, the rate of bitcoin creation will be halving as well. So there will be two competing effects:

1) 'monetary' inflation will decrease, because the rate of bitcoin creation will drop from 7200BTC/day to 3600BTC/day

2) miners will be earning half as much when denominated in BTC

If the decrease in inflation doesn't cause a large enough corresponding increase in price, mining would be less profitable, causing some fraction of miners to drop out, and meaning longer transaction confirmation times (for at most 2 weeks, while the network adjusts to the change in capacity).

My guess is that the huge change in inflation will adequately compensate both miners and investors, and cause a significant enough increase in price to avoid lengthening confirmation time.

https://en.bitcoin.it/wiki/Controlled_Currency_Supply

EDIT: by inflation, I mean 'monetary' inflation, rather than price inflation.

Dated April 2nd.

Sorry... not hex: base64 (or whatever the bitcoin variant is.)

There is an interesting scheme called 'firstbits', which uses the blockchain (global, public, immutable) to determine the shortest prefix which uniquely identifies an address. At this point in time, an address can usually be identified with 5-6 hex digits.

Your 19HcFgnnJseANJAHUjFifVwz68AGYrHc7v address for example, firstbits down to 19HcFgn: http://firstbits.com/

> Pay it off every month and you won't pay interest.

You're skipping the part where she needs to have a bank account, check book, and possibly postage stamps in order to pay her credit card bill.

> ... transfer money (takes 5-7 days) from your bank account...

> ... seller might want to wait until the network confirms a transaction...

She is already familiar with financial institutions taking forever to process payments/clear checks. Additionally, she is familiar with checks bouncing, and with cards being declined.

> Then when you want to pay for something put in the person's bitcoin address

Or, as seen in the linked article, she hits 'Send bitcoins', and then waves her phone at the recipients phone.

> I was one of those people.

It's brave of you to admit that you did not research the thing you invested in. Many of us have.

> If it's not simple enough to explain to someone's mom it's not going to flourish as a serious currency.

Do you think that the way the Visa/MC network is implemented is simple enough to explain to someone who does not understand computers? No? Hm, I wonder how people use it...

The point of articles like this is usually to highlight usability improvements for a particular solution, and in this case, to highlight the fact that their is no hardware requirement for bitcoin.

Also, re: the difficulty of acquiring bitcoin: mobile apps like this mean that if one party in a transaction has bitcoin, the other party can go from 0 to 60 on accepting bitcoin in the time it takes to download the app from their app store.

By almost any metric (including value) bitcoin is healthy, and slowly growing: http://blockchain.info/charts

And in the interest of full disclosure: yes, I have an investment in bitcoin, because I truly believe in the strength of the concept.

Since this is almost pure sendfile() work (aside from the headers), it really doesn't seem like a very useful example... there isn't much static content left on the web.

We definitely appreciate the work that you and Typesafe are doing: thanks! I apologize for my brusque reaction in that tweet.

Regarding macros: it's quite clear that they simplify the job of the compiler writer: you can provide more features, more efficiently to the end user. But every feature has a cost, and increasing the end user's surface area onto the language by providing 1) macros, 2) new features enabled by macros, is very much a double edged sword. Being enabled by a compiler flag definitely helps to minimize end-user exposure to the former.

Macros in lisps can be used as a replacement for many of the features that Scala provides, including call-by-name parameters, (certain types of) implicits, and many uses of generics. If we could deprecate some of those features in Scala by replacing them with macros, then this would seem like more of a net win to me. But that doesn't seem likely: instead we will probably have all N, and Scala programmers will need to decide which of the growing list of ways to accomplish cat-skinning is best.

Attacks against this type of phrase will almost certainly use dictionaries for the next decade, until it becomes practical to do rainbow tables of size 64^76. So adding elements to avoid dictionary words definitely helps (for now).

This is not a 'cutscene' in the pre-rendered-and-then-compressed-as-video sense. The site clearly states that it was rendered in realtime: it is a very short path to interactivity.