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

[casascius]

Casascius: when clicking the Done button to generate the Bitcoin addr, the app throws an ugly warning which doesn't make sense to me:

The Payment Invitation Code appears to have been generated from the same Escrow Invitation Code you entered, and not its mate. You might be verifying a Payment Invitation you produced yourself, rather than one produced by your trading partner.

I did not produce the payment invitation myself, Micon did!

This is a display-only bug I have yet to fix.  Basically I've got it decided to throw a fit over using the A code specifically, as though that's always the payer.  It can be safely ignored.

[mrb]

Casascius: ok.

Micon: let's raise the stakes. I feel confident about using Casascius' self-escrow app. Can we put down at least an additional 90 BTC each?

[becoin]

Can we put down at least an additional 90 BTC each?

How about putting 9000 bitcoins?

[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...

[Micon]

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...

Casascuis would send us 2 parts of an invite code - one starting envsomethignA and one starting envsomethingB we both put the codes as either the "payer" or the "payee" and we generate the same bitcoin address.   When one of us conceeds, the loser sends the winner the invite code they don't have.  Winners puts both codes together in this btc-address program C will have to give you to download and somehow that generates the private key and then somehow those coins can then move at your whim.   I hope

[casascius]

Casascuis would send us 2 parts of an invite code - one starting envsomethignA and one starting envsomethingB we both put the codes as either the "payer" or the "payee" and we generate the same bitcoin address.   When one of us conceeds, the loser sends the winner the invite code they don't have.  Winners puts both codes together in this btc-address program C will have to give you to download and somehow that generates the private key and then somehow those coins can then move at your whim.   I hope

Exactly.

And if neither side is willing to concede, I have the both codes the other needs, so I can force it if I need to.

Very briefly, the mathematical basis is a three-factor elliptic curve multiplication equation where the two participants only know two of the factors plus an elliptic curve point related to the factor they don't have.  That's enough for them both to generate a bitcoin address whose private key would be produced with all three factors, without having all three.  When the loser concedes to the winner (or the escrow agent forces it), the loser gives the winner the invitation code that contains the factor he doesn't have, so the winner ends up with all 3 factors, and the program is able to compute the private key with simple multiplication.

[Micon]

Casascius: ok.

Micon: let's raise the stakes. I feel confident about using Casascius' self-escrow app. Can we put down at least an additional 90 BTC each?

I am interested in betting more as well.  Some of my close poker associates are watching the entire BFL thread & this bet thread.  Give me 24 hrs and let me see how much interest there is with my friends, and either way I'll personally fire more coin on BFL failure on a very similar statement than what we already have.

anyone like dooglus do that forensics on that address yet?   Kinda wanna see what happens / if it's cool / if it works, etc.

[dooglus]

anyone like dooglus do that forensics on that address yet?   Kinda wanna see what happens / if it's cool / if it works, etc.

I took a look and noticed that there are two 10 payments of 10 BTC each to the address and that both transactions were included in the same block.  Other than that I don't see what else there is to see.  It's a regular bitcoin address like any other.  Anyone with the private key can spend the contents.  I can't tell whether the address was created using casascius' escrow code, the standard bitcoin client, or anything else.

[casascius]

Anyone with the private key can spend the contents.

The cool part about this is nobody has the private key, yet there's no reason to sweat it.

All that is known is that the private key can expected to be calculated by the eventual winner.

[SgtSpike]

Alright, that makes sense.  How do we generate the Bitcoin address from the code?  (windows machine here...)

[mrb]

Casascius: ok.

Micon: let's raise the stakes. I feel confident about using Casascius' self-escrow app. Can we put down at least an additional 90 BTC each?

I am interested in betting more as well.  Some of my close poker associates are watching the entire BFL thread & this bet thread.  Give me 24 hrs and let me see how much interest there is with my friends, and either way I'll personally fire more coin on BFL failure on a very similar statement than what we already have.

Ok. Let me know as soon as you are ready to send 90 BTC. I can send my coins first.

[casascius]

Alright, that makes sense.  How do we generate the Bitcoin address from the code?  (windows machine here...)

Assuming I have sent you the Escrow Invitation code, go to the "Be a Payee" screen, paste the invitation code, and click "generate a payment invitation".

This will give you two things: a code that starts with "einvp" and a bitcoin address.  Send both of these to Micon (and not to me, at least do not share or publish the "einvp" code to anyone but Micon).  If he is able to generate the same bitcoin address with your "einvp" code as well as the "einvb" invitation I sent him, and you both can verify that, then you're good to go, and can pay the address.

[Micon]

mrb - do you want to do a 1 bitcoin bet on something arbitrary that is happening tomorrow (like a cricket match or some other sporting event with a 50/50 chance, really anything with a spread) and do it with the escrow system, generate one winner, and basically verify it works before we start dumping coin after coin into a black-hole btc address?  (I'm not saying C isn't on point here, I'd lay 10-1 that this shit works perfectly, but you know, just good practice to try it with 1 coin before increasing the bet to $1700 USD and climbing)

[casascius]

You can also generate your own escrow code sets and see it work for yourself.  I don't have a secret weapon on escrow invitation codes, I just used the same program, the only magic I have added by generating it myself is the willingness to intervene in a dispute if needed, which isn't needed for testing. You can generate unlimited code sets on the "be an escrow agent" screen and practice funding and claiming funds like 0.01 BTC.

I haven't had time to work on the code (just been catching up on orders since CES- almost done) but I expect to fix the save and print buttons so it will be easier as the escrow agent to manage deals. And fix that message about "you used your own code" when you didn't.  Soon though, unless someone beats me to it.

Also... Just so you know, the fact that you are seeing the same Bitcoin address from the A vs the B code is a pretty viable proof everything worked the way it should, since the A code and the B code are totally different codes, they just share a provable mathematical property that, if not true, could never result in the same Bitcoin address coming from the independent address generation process done by both parties.

[mrb]

Good idea. We don't have to bet on a real-world event. Let's just do a test with .001 BTC each. Let's decide that you "win", and you can keep the coins for this test.

Casascius: I think it is important that *you* generate us another (a,b) pair the exact same way you generated them so far. What if you accidentally run a version of BtcAddress.exe  that happens to be a debug version you accidentally left on your system in your PATH that generates invite/escrow codes that fail to lead to a valid private key? I don't know. I am just being overly cautious here. I am a software veteran and can think of dozen of bugs why this wouldn't work, although I am 99% sure everything works, as you said the bitcoin address is the same.

[casascius]

I can do another pair but am replying from my phone so will have to do that later.

Even if I had a debug version, if I can get the x and y values your version thinks were used, the code could be hand recovered with a calculator. The x value is totally represented in the A code and the y value is fully represented in the B code.  If you have Gx and y, and someone else has Gy and x, and the sameness of the result proves the product of these two is the same for both cases, there is no question about the recoverability of x and y given both (assuming I didn't somehow give the same Gx and y to both parties and lose the x value, which is impossible in this case given that I have already successfully recovered a private key for a bitcoin address you provided based on that escrow invitation pair.)

This is why I insist you both get the same Bitcoin address independently... Your ability to do so counts as proof of so many little things all along the way.

Tonight though... I will generate another pair. You can each contribute 0.01 BTC and I will flip a coin and award it at random.

[Micon]

I'm in.  

further more I'll do the coin flip for 1 full btc if mrb wants to  

you can ustream it if you really want  or skype to me and I can ustream it on my channel.

I know C is not the only 1 to generate escrow codes, but since no one else has really played with this tech I would trust dooglus to download that btc-address.zip from C and generate us the a & b escrow codes (and in essence agree to be our arbiter)

[dooglus]

since no one else has really played with this tech I would trust dooglus to download that btc-address.zip from C and generate us the a & b escrow codes (and in essence agree to be our arbiter)

Way ahead of you...  I downloaded it yesterday, but couldn't get it to run:

chris@chris:~/Programs/btcaddress$ mono BtcAddress.exe

Unhandled Exception: System.TypeLoadException: Could not load type 'BtcAddress.Program' from assembly 'BtcAddress, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'BtcAddress.Program' from assembly 'BtcAddress, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
chris@chris:~/Programs/btcaddress$ lsb_release -a
LSB Version:   core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID:   Ubuntu
Description:   Ubuntu 12.10
Release:   12.10
Codename:   quantal
chris@chris:~/Programs/btcaddress$ dpkg -l | grep mono
ii  fonts-tlwg-mono                     1:0.5.0-5              all                    Thai TlwgMono font
ii  libmono-addins-gui0.2-cil           0.6.2-2                all                    GTK# frontend library for Mono.Addins
ii  libmono-addins0.2-cil               0.6.2-2                all                    addin framework for extensible CLI applications/libraries
ii  libmono-cairo4.0-cil                2.10.8.1-5ubuntu1      all                    Mono Cairo library (for CLI 4.0)
ii  libmono-corlib4.0-cil               2.10.8.1-5ubuntu1      all                    Mono core library (for CLI 4.0)
ii  libmono-csharp4.0-cil               2.10.8.1-5ubuntu1      all                    Mono.CSharp library (for CLI 4.0)
ii  libmono-i18n-west4.0-cil            2.10.8.1-5ubuntu1      all                    Mono I18N.West library (for CLI 4.0)
ii  libmono-i18n4.0-cil                 2.10.8.1-5ubuntu1      all                    Mono I18N base library (for CLI 4.0)
ii  libmono-posix4.0-cil                2.10.8.1-5ubuntu1      all                    Mono.Posix library (for CLI 4.0)
ii  libmono-security4.0-cil             2.10.8.1-5ubuntu1      all                    Mono Security library (for CLI 4.0)
ii  libmono-sharpzip4.84-cil            2.10.8.1-5ubuntu1      all                    Mono SharpZipLib library (for CLI 4.0)
ii  libmono-system-configuration4.0-cil 2.10.8.1-5ubuntu1      all                    Mono System.Configuration library (for CLI 4.0)
ii  libmono-system-core4.0-cil          2.10.8.1-5ubuntu1      all                    Mono System.Core library (for CLI 4.0)
ii  libmono-system-drawing4.0-cil       2.10.8.1-5ubuntu1      all                    Mono System.Drawing library (for CLI 4.0)
ii  libmono-system-security4.0-cil      2.10.8.1-5ubuntu1      all                    Mono System.Security library (for CLI 4.0)
ii  libmono-system-xml4.0-cil           2.10.8.1-5ubuntu1      all                    Mono System.Xml library (for CLI 4.0)
ii  libmono-system4.0-cil               2.10.8.1-5ubuntu1      all                    Mono System libraries (for CLI 4.0)
ii  mono-4.0-gac                        2.10.8.1-5ubuntu1      all                    Mono GAC tool (for CLI 4.0)
ii  mono-gac                            2.10.8.1-5ubuntu1      all                    Mono GAC tool
ii  mono-runtime                        2.10.8.1-5ubuntu1      amd64                  Mono runtime
ii  ubuntu-mono                         0.0.49                 all                    Ubuntu Mono Icon theme
chris@chris:~/Programs/btcaddress$

What am I doing wrong?

[mrb]

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

[casascius]

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

Seems to me that cooking this program into a command line version for escrow activities might not be a bad idea.  I have cut out all the "model" classes into their own folder so the UI is totally replaceable (done for iPhone).  All of the crypto magic is done in those classes.  Making a command line edition of this that would be more linux-friendly wouldn't be a bad idea and importantly would not be that difficult.