280 BTC total bets between Micon and mrb (are BFL ASICs real?)

[dooglus]

Dooglus, you need to install the Ubuntu package I mention a few comments above...

Thanks.  It took me a while to find the post you meant.  It was this, in case anyone else needs it:

Ok, I installed Mono (and libmono-system-windows-forms4.0-cil which is needed to run casascius's app)

It works for me now, and seems pretty straightforward.

Here's how it works, with a worked example:

'be an escrow agent' creates an escrow invitation, which is in two parts A and B:

A: einvaT9CMj3qdZQZejm9DSse9c9MXNk5udVN2SQhTRJ6GKwJiX8wvukbK2fZ2ZkNo5LqmiMBfJNnLUDYoXYLo9XPa dvW38NbGo34LNLf9b
and
B: einvbT9CMj1gj74paurHWzgX4UeCpDgKUdiftFVdQxxYct23YMD2dAcfXd49dp61cpDRoK3sPbgKypXwR1h5ts9Bw CtWBJpUAvTvTvRabW

'be a payee' takes one of these codes (A) and creates a payment invitation (P):

P: einvpT9CMj791RwFxhxZMX37bTYXLabdw9sgM6iekpjjacUvDXf8rYMTYXeozySvW5tRUs6HwsyUuYbYuqm2xR66G YG6a9ArfDve4eQQsW
and an address:
14xEG5KnP1F5Y4ShstgSYT5hQeeqrWnMTp

'be a payer' takes the other escrow invitation code (B) and the payment invitation (P), and creates the same address:

14xEG5KnP1F5Y4ShstgSYT5hQeeqrWnMTp

After all that:

  Escrow agent has A and B
  Payee        has A       and P
  Payer        has       B and P
  Nobody       has A and B and P

So all 3 parties have a different 2 of the 3 required pieces of information.

'collect your funds' takes all 3 codes (A, B, P) and creates both the address and its private key:

14xEG5KnP1F5Y4ShstgSYT5hQeeqrWnMTp
and
5JEiXmgXFYRxjPavisSaw5ipYAVpTjM5Vf7Xga33mrmyiBY834H

https://www.bitaddress.org/ has a 'wallet details' tab which confirms that that is the correct private key for the given address.

[1714858562]

1714858562

[1714858562]

1714858562

[1714858562]

1714858562

[SgtSpike]

No Micon, I do not want to make the same bet you and MRB made.  That bet is also based on whether they meet specific MH/Joule requirements, which I do not want to bet on.  I want to bet on them delivering an ASIC device that works (creates valid hashes for the Bitcoin network) by the end of 2013, regardless of speed or power usage to at least two forum members that prove they are running (video or pictures or ??).

If you believe they aren't going to deliver (which is what you keep stating over and over again), you shouldn't have any problem with this.

When making a wager, both sides must agree.  If you look at mrb's and my discussion, a standard practice is to suggest terms, then refine on both sides until both parties agree.

To have a 20 coin bet with me I would like:

-- statement of a certain Mhash/Joule that proves that this BFL ASIC is a significant step up from the current top miners - that is the point of ASIC - to hash the proof-of-work problem much faster and more energy efficient than current FPGAs, as I understand it the current top dog - they claim ~ 20x-30x as fast right?  current FPGA top metrics around 25 Mhash/Joule?    Let's find a number you and I are both comfortable with it - as your statement reads, BFL could ship you some thumbdrive that creates 1 valid hash using your CPU and you would win the bet.

Also there is no need for taunting - I won't say to you "why won't you bet me at same terms if you are so sure BFL will ship an ASIC based on specs they describe?" - I will simply go back and forth and list out the terms that would make me accept the wager.

What about a statement such as 10x shipments at 5x current top Mhash/Joule ratings?   And excuse the newb-ness to mining, but what is top Mhash/J ATM?   it is FPGA cards?

Fair enough - I shall taunt no more.

I'll bet that BFL will put out at least as efficient as Avalon's advertised specs.  So that's 400w @ 60GH/s.  Is that agreeable?  It is a vast improvement over even FPGA's, where 60 GH/s would consume almost 6,000w.

I'd rather not go as high as 10 end customers, simply because it might be difficult to find 10 individuals willing to post proof of ASIC delivery.  I'm not sure that there's even 10 different people who have posted pictures of FPGA's.

So then, my new bet proposal is this:

I'll bet 20 BTC that BFL will ship out an ASIC miner capable of at least 150MH/s per watt to at least 3 end customers by the end of 2013.

You have a bet if you make it by 7/1/2013 - they said they ship in Feb. and I don't want to wait all year for this bet to settle.  Those 40 coins could be worth $10k by then and I may need a WSOP main even buy in

  I feel 7/1 is more than fair given the current timeframe directly from BFL, it keeps everything nice and clean for me, and even allows you months and months of further delays past their posted timeframe.  If BFL is real, this seems like an easy win for you under these terms.

Ok, I can agree to those terms.

What's the next step?  I don't entirely understand Casascuis' escrow system yet...

Casascius - can you generate an escrow invitation for Micon and I on this bet?

[casascius]

Casascius - can you generate an escrow invitation for Micon and I on this bet?

If I'm to generate a code for a real money bet, I would prefer to use e-mail and/or PGP wherever it isn't too inconvenient, so perhaps you can PM me your e-mail address or a link to your PGP key if you're able to decrypt it.  (I just don't want all the escrow details to be in plaintext in the forum database where others can see it)

[mrb]

I sent a PM with an escrow invitation code to both Micon and mrb for a coin flip.

Micon, I PM'd you a payment invitation for this test -- the address is below and I already sent 0.001 BTC to it:
http://blockchain.info/address/1JUsk88BGbZbRs3R3JoKxeR4Mc9sxf74kQ

[Micon]

Casascius - can you generate an escrow invitation for Micon and I on this bet?

If I'm to generate a code for a real money bet, I would prefer to use e-mail and/or PGP wherever it isn't too inconvenient, so perhaps you can PM me your e-mail address or a link to your PGP key if you're able to decrypt it.  (I just don't want all the escrow details to be in plaintext in the forum database where others can see it)

oh certainly send both parts of the invites off-bitcointalk in some fashion.   I'm fine with a plain-text email from you on this 1 C

and again, TYTYTYTYTYTY for making this system casascius.

also tytytytyty to dooglus for an explanation of C's system that is concise & accurate.

[Micon]

I sent a PM with an escrow invitation code to both Micon and mrb for a coin flip.

Micon, I PM'd you a payment invitation for this test -- the address is below and I already sent 0.001 BTC to it:
http://blockchain.info/address/1JUsk88BGbZbRs3R3JoKxeR4Mc9sxf74kQ

kk checking / will fire .001 at it if it comes up same

edit:  not a valid escrow invitation code.  C was off by 1 extra character in that long string the 1st time, maybe it happened again.  I tried it 3x. 

[mrb]

I must have miscopied smthg. Will check things in 3h when I get home.

[Micon]

I must have miscopied smthg. Will check things in 3h when I get home.

1)  seems like it was C's invite code that was wrong, not the 1 you generated

2)  It's cool, I have errands to run and will be back on in a few hrs too.  no rush, but I'm excited to test it too

[casascius]

I think the length of the line entices things to break them up and that is causing transcription problems.  Check to make sure there isn't a space or something at about 2/3 of the way through the code.

I should come up with a scheme for a chunked multiline encoding for larger objects. Sort of like base64 but without + and / and = signs, and with self hashing capability.  Something that resembles PGP.

[mrb]

Micon, everything is fine. I copied and pasted the invitation out of the PM I sent you, and with my code A I am able to regenerate the same Bitcoin address. As you said, it seems that the pb is your code B.

PS: The space that casascius is talking about is inserted by the forum software (it's a space in a <span> with a negative margin!) to allow long words to wrap. This is really crappy... It should instead use <wbr> which doesn't break copy/paste (optional line break, finally standardized in html5).

[dooglus]

I should come up with a scheme for a chunked multiline encoding for larger objects. Sort of like base64 but without + and / and = signs, and with self hashing capability.  Something that resembles PGP.

Having the .net app ignore spaces and other invalid characters in the input fields would be a quick and easy workaround wouldn't it?

[casascius]

I have gone ahead and emailed SgtSpike and Micon a set of codes.

One feature I feel worth pointing out:  besides the codes starting with "einva", "einvb", or "einvp", I have made it so the following 5 characters are random but identical for a matched set.

I sent SgtSpike a code starting with einvaPoHB4
I sent Micon a code starting with einvbPoHB4
When they generate a payment invitation, it will start with einvpPoHB4
Notice PoHB4 is in all of them...this is deliberate, just so you have a quick visual way to see whether codes are part of a matched set.
Each time the Escrow Agent generates a new pair of invitation codes, these 5 characters are shuffled to something random.
In Dooglus's example above, they were T9CMj.

[SgtSpike]

I have gone ahead and emailed SgtSpike and Micon a set of codes.

One feature I feel worth pointing out:  besides the codes starting with "einva", "einvb", or "einvp", I have made it so the following 5 characters are random but identical for a matched set.

I sent SgtSpike a code starting with einvaPoHB4
I sent Micon a code starting with einvbPoHB4
When they generate a payment invitation, it will start with einvbPoHB4
Notice PoHB4 is in all of them...this is deliberate, just so you have a quick visual way to see whether codes are part of a matched set.
Each time the Escrow Agent generates a new pair of invitation codes, these 5 characters are shuffled to something random.
In Dooglus's example above, they were T9CMj.

Ok, I get Bitcoin address 1B3EAGAgXoALFd6o9762hitoCyH61JxF4Y.

What do I do with the payment invitation I generate?

[casascius]

Ok, I get Bitcoin address 1B3EAGAgXoALFd6o9762hitoCyH61JxF4Y.

What do I do with the payment invitation I generate?

Send it to Micon with the address and make sure he confirms he gets the same bitcoin address.

If you both agree you're seeing the same address, proceed to fund it.

[dooglus]

If you both agree you're seeing the same address, proceed to fund it.

What happens if player 1 makes a deposit to the address they both agree upon from his MtGox account, posts here saying "I sent my payment" and player 2 replies "no, I sent my payment".  Only one payment was sent, but we can't tell who sent it, and since it was sent from an MtGox address which neither of them controls, neither can sign a message with the sending address to prove it was them.

I guess they could use screenshots of their MtGox account, but that's easy enough to fake.  Maybe the answer is not to use a web wallet when making your payment.

[casascius]

If you both agree you're seeing the same address, proceed to fund it.

What happens if player 1 makes a deposit to the address they both agree upon from his MtGox account, posts here saying "I sent my payment" and player 2 replies "no, I sent my payment".  Only one payment was sent, but we can't tell who sent it, and since it was sent from an MtGox address which neither of them controls, neither can sign a message with the sending address to prove it was them.

I guess they could use screenshots of their MtGox account, but that's easy enough to fake.  Maybe the answer is not to use a web wallet when making your payment.

Seems like an unlikely enough scenario that I could just ask someone at MtGox to tell us who made the payment in the rare event it were ever to come up.  As the escrow agent I could take as long as I needed to be satisfied that I know who paid.  It's a lame attack with a poor chance of success so I can't imagine anyone bothering to try it.

[MPOE-PR]

If you both agree you're seeing the same address, proceed to fund it.

What happens if player 1 makes a deposit to the address they both agree upon from his MtGox account, posts here saying "I sent my payment" and player 2 replies "no, I sent my payment".  Only one payment was sent, but we can't tell who sent it, and since it was sent from an MtGox address which neither of them controls, neither can sign a message with the sending address to prove it was them.

I guess they could use screenshots of their MtGox account, but that's easy enough to fake.  Maybe the answer is not to use a web wallet when making your payment.

Seems like an unlikely enough scenario that I could just ask someone at MtGox to tell us who made the payment in the rare event it were ever to come up.  As the escrow agent I could take as long as I needed to be satisfied that I know who paid.  It's a lame attack with a poor chance of success so I can't imagine anyone bothering to try it.

No, actually, sounds like a major hole. This needs to be addressed somehow (not necessarily for the case at hand, but in general for the system).

Also the idea of relying on MtGox breaking their customer's confidentiality is bad. I know MtGox used to do this in the past, but since MPEx introduced standards for such that sort of shit doesn't seem to fly so well anymore in the public eye either. Frankly, I doubt they'd tell you, and if they did tell you they'd just be stupidly allowing you to rehash the ver-blockchain.info experiment.

You taking "as long as necessary" is yet another hole. The average person using escrow for any purpose is not interested in adding unspecified delays to their process.

[mrb]

One way to work around the flaw is via a slight change of process: before a person sends to the bitcoin address, he or she privately announces to the escrow the exact amount to be transferred (eg. 10.00001234 BTC when 10 BTC were supposed to be sent). Because the less significant digits have been predicted, the escrow can trust that this person originated this transfer.

Or, the proper way to solve the flaw IMHO is to have the escrow program generate not 1, but 2 bitcoin addresses: person A is supposed to send to address A, and person B is supposed to send to address B.

[MPOE-PR]

One way to work around the flaw is via a slight change of process: before a person sends to the bitcoin address, he or she privately announces to the escrow the exact amount to be transferred (eg. 10.00001234 BTC when 10 BTC were supposed to be sent). Because the less significant digits have been predicted, the escrow can trust that this person originated this transfer.

That method is logically sound (and what MPEx, the ROTA etc use), but it does run into the problem of people being people.

[Micon]

I have gone ahead and emailed SgtSpike and Micon a set of codes.

One feature I feel worth pointing out:  besides the codes starting with "einva", "einvb", or "einvp", I have made it so the following 5 characters are random but identical for a matched set.

I sent SgtSpike a code starting with einvaPoHB4
I sent Micon a code starting with einvbPoHB4
When they generate a payment invitation, it will start with einvbPoHB4
Notice PoHB4 is in all of them...this is deliberate, just so you have a quick visual way to see whether codes are part of a matched set.
Each time the Escrow Agent generates a new pair of invitation codes, these 5 characters are shuffled to something random.
In Dooglus's example above, they were T9CMj.

Ok, I get Bitcoin address 1B3EAGAgXoALFd6o9762hitoCyH61JxF4Y.

What do I do with the payment invitation I generate?

1B3EAGAgXoALFd6o9762hitoCyH61JxF4Y

got that with your payment invite.  copied that shit in a secure location.

I'll hit it with 20 coins right now and hope that everything works out.   Seems like the most logical plan.