I can confirm that Lear has discussed with me the results of his research a day before the paper by Eyal and Sirer was published.

If I understand this correctly, some coins will be destroyed in the process, which is not what we want.

Vitalik Buterin, head writer of The Bitcoin Magazine, has recently honored us with a visit to Israel. During this time we invited him to give a special guest lecture, on the topic of "Quantum Computing and Bitcoin".

Video: http://youtu.be/DkUpZkeqhF4
Slides: https://bitcoil.co.il/files/Quantum%20Computing%20and%20Bitcoin.pdf

More details about this event at http://www.meetup.com/bitcoin-il/events/145566422/.

My thoughts on the matter:
http://fieryspinningsword.com/2013/11/06/hashrate-amplification-attacks/

I'd like to point out that a primitive version of this attack is 3 years old:

https://bitcointalk.org/index.php?topic=2227.msg30064#msg30064
https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083

A miner in a traditional pool doesn't have the information needed to publish a block on his own. He has to submit the header w/ nonce to the pool, and then the pool broadcasts the block.

You define your own standard of matching inputs and outputs. Colored coins transactions need to be carefully constructed to conform to this standard and make such matching possible.

A transaction like you propose will uncolor the coins because it mixes inputs of several colors into the same output, and is this something to avoid.

Please see https://bitcoil.co.il/BitcoinX.pdf for a worked example with order-based coloring.

You could do it in CC with advanced color kernels. However note that people will still be able to do mixing transactions.

JR should comment on the ability to do it with Mastercoin.

Right.

The main use case is company stock. You have to believe in the company of course, but you don't need to rely on any centralized, cumbersome stock exchange.

This is useful for tag-based coloring (as opposed to order-based coloring), however without a network rule enforcing the color tags the usefulness is limited.

Note that colored coins' use of the blockchain is already much less hostile than Mastercoin's current implementation.

P2pool is a p2p pool. As far as reward methods go, I would use any pool that has a hopping-proof method.

The thing that is described at https://bitcoil.co.il/BitcoinX.pdf and http://coloredcoins.org/.

Technically, there is no feature in colored coins to enable this directly, but it could be done in an ad-hoc way. Economically, I don't think this would work in Mastercoin either.

Yes.

I think that Bitcoin is as big as I think it is - a $2B economy with >10K businesses and hundreds of thousands of users.

Based on data from http://www.similarweb.com/website/bitcointalk.org, it looks like the forum gets about 1M pageviews per day.


You do know that Google search results and autocomplete are targeted? If you look at Bitcoin all day, it will give you Bitcoin-related results... It has little to do with Bitcoin's popularity.

I didn't mention CPPSRB except perhaps in the context of the list of pools and their methods in the end; and I didn't use the term "long-term uncertainty". Of course, this doesn't contradict the statement that it is newer than the paper; the paper is 2 years old.

The closest thing I can think of is in the reward method triangle, I've probably mentioned that PPLNS can achieve any tradeoff between variance and maturity time.

The main problem with CPPSRB, as with all other methods that I refer to as broken, is that it is not hopping-proof. The hoppability is low, but still exists.

בכיף.

כן, בוא לאחד המפגשים ויהיה לך ממי לקנות במזומן.

כמו כן יש חלפנים מקצועיים שעובדים עם העברות בנקאיות.

באילו סכומים מדובר?

It's a trivial calculation, and numbers have been published multiple times.

Use the right terms, Bitcoin mining is a Poisson process. The number of blocks in a period of time follows the Poisson distribution.

The numbers are good but I think it is more useful to think in terms of the time until the next block, which follows the exponential distribution. If the average is 10 minutes, the chance that the next block will be later than a day (1440 minutes) is exp (-1440/10) = 2.9 E-63.

As for the original question re a week, that's exp(-7*1440/10) = 1.7 E-438.

Did I say terrible communication already? Turns out what they wanted me to pay is completely distinct from the invoice I received. And of course, they never mentioned that other payment previously.

I don't know how many have heard about Netsolus, so I hope I'm not doing them a favor by merely mentioning them.

But Newton's 3rd law states that for every action there is an equal and opposite reaction. And the reaction to their atrocious behavior is that I let you all know that they're terrible.

Netsolus is a server hosting company that, among other things, works in collaboration with BFL to offer hosting to owners of BFL hardware (yes, we know about the problems with BFL, let's not make this thread about them).

Having purchased 3 BFL 500 GH/s rigs, with the original plan being hosting them with Inaba, I was offered to host them with Netsolus (actually at first it was a different host, also not so great).

Since the rigs arrived one by one, the situation was a bit messy. Whenever I asked them for clarification about the status of my rigs, I either received no response at all, or a belated and incomplete one. I believe that for extended periods of time, rigs that were in their possession were not actually running, and it was a struggle to extract from them some information to allow me to investigate this.

The most egregious incident is for a rig that was delivered to their premises last Monday. I inquired last week, got a template response. After the weekend, again a template response.

This morning I received an invoice, I had to leave early so I noted it for future handling. Not having heard anything about the new rig I inquired again. First, I was told that the rig hasn't been brought online because of the outstanding invoice - that's no way to treat a customer who has already paid past invoices, trusting them with expensive equipment generating $200 per day. Second, they said that they have multiple times informed me that the outstanding invoice is a blocker to putting the rig up - which is a lie, they have not once said anything about this invoice beyond the automated invoice generation message, which of course did not say anything about being a blocker.

Their behavior has probably caused me more losses than the payment to them, which itself is arguably too pricey. That's on top of all the time (which I have very little of) wasted chasing them for some answers.

I'm highly dissatisfied.

It seems to me that if the blockchain itself needs to recognize shares it will be very bloated.