|
It can be measured by the way - from CerebroSpinal Fluid - perhaps a bit messy
|
|
|
|
Oxytocin  Of course, there's no way for it to be measured, especially from a distance, but one can hope  People always said money can't buy you love - what if love was money? |
|
|
|
Describe a protocol in sufficient detail that it can be actually implemented (tiny details such as packet format etc don't matter, general operation does) and which has the following properties:
You've defined the requirements too weakly. Take bitcoin, add a requirement that a valid block must be signed by both bob and I (hard code the keys). Make the difficulty zero. Change nothing else. (If you also totally screw up a bunch of extra things, you could call the result 'solidcoin'). This meets your criteria because there is no central server. There are distributed servers. The system is secure so long as you trust that bob and I won't conspire to screw everyone. You can pay to the address in my sig, thanks! Oh, and no - bitcoin and other blockchain-based currencies forked from it do not count
|
|
|
|
|
Let's up this a bit.
Anyone who can solve this problem I will pay 50BTC.
Due to the higher payout, here's some more precise criteria:
No proof of work - no calculations performed for the purpose of making forgery of the transaction record computationally infeasible or impossible - you must find another means of keeping the transaction record intact.
No centralised server - it must be 100% P2P, but i'll allow a solution that bootstraps by grabbing some existing node IP addresses so long as those nodes are not trusted
No double spending - it must not be possible to send the same funds to 2 separate destinations
It must be possible to receive funds while your client is offline without needing to connect to a central server
If you can solve this you can probably make an absolute fortune with your genius in other ways and this 50BTC reward is a tiny and pathetically small bonus.
I promise to be fair in judging any proposed solutions, but my word is final unless at least 1 core developer of the bitcoin client and 1 founder/co-founder at either MTGox or TradeHill overrules me (and for that reason they're not eligible for this reward - sorry).
There you go, a serious challenge - if you have a serious solution, take it up.
|
|
|
|
I have an idea to reduce the amount of proof of work required for a given level of security. Does that count?
Unless you can reduce it to 0, no |
|
|
|
(My point: proof of work is central to making this whole thing work. To find a way to make it work without it, would be groundbreaking and far more valuable than 5 BTC.)
Yeah, but it's creative thinking: post presumably unsolvable problems in the newbies section and offer a small reward. After all, some important math problems have been solved by a student thinking it was homework  My point is much the same as casascius had: If anyone really does have a solution for this problem (in which case they can probably also solve the halting problem for me too), then let's see it! Otherwise, shut up. Think of it like a mini randi prize. |
|
|
|
|
Oh, and no - bitcoin and other blockchain-based currencies forked from it do not count
|
|
|
|
I've noticed a few threads popping up here about how "wasteful" the mining process is, so to get to the point here's my challenge. Describe a protocol in sufficient detail that it can be actually implemented (tiny details such as packet format etc don't matter, general operation does) and which has the following properties: - No reliance on a central server
- An unchanging record of past transactions that can not be altered
- No double spending
- Ability to receive funds while your client is offline
- No proof of work requirement
I will pay 5BTC to whoever can solve this challenge - remember it must match all points. |
|
|
|
Fees are a bit steep, but it's a much needed service. Nice work.
You might have a surprise later down the road We're currently offering the lowest fees at which we can sensibly offer this service, they will reduce with time as volume picks up. |
|
|
|
This came to me the other day, and i'm unsure on the details as I haven't went into the transaction scripts yet so please excuse me if the whole idea is nonsense.
Would it be possible to implement a PRNG in the transaction script in such a way that the payouts are automated to the winner of a gambling game? Something such as comparing the output of the PRNG specified in the transaction script with the last byte of the address and a small whitelist of addresses.
I presume that the scripting is turing-complete but space limited, but i'm not too familiar with this aspect of bitcoin myself.
Thoughts anyone?
Assuming it is turing-complete, you still need enough "random" data to seed your PRNG. Where are you going to get that data from in a way that isn't reproducible at a distance? If you could delay the transaction (i.e. don't process until block x) you could submit a transaction and then use the block hashes for the next 6 blocks (1 hour) as your seed data. Not sure if Bitcoin can (or will) support transactions which can't be processed until a certain date but if they do ... 1) Current block is 123 2) Transaction has a not before block 129 limit 3) Script skips block 124 and looks at block hashes of blocks 125, 126, 127, 128 4) Transaction is included in block 129, payouts according to rng in script. Would that work? Is that possible in Bitcoin (or possible in future)? If so it would eliminate operator fraud (well other than outright theft). Concept Game: Operator website could have a game. 10 BTC bet, One in 11 chance to win 100 BTC. The website provides user a deposit address. Players need no accounts, they can track their progress by looking up deposit address. Once there are 11 bets the website creates keep 10 BTC (the vig) and creates a 100 BTC transaction delay 6 block transaction using the hashes of the next 5 blocks as the seed and the addresses used by players as payout. If you win the 100 BTC comes right to your wallet. If you don't you know the game was fair. A simplified version wouldn't even need a RNG. Just take the xOR of the 5 blocks as your random data. Now start w/ least significant digit compare it to the least significant digit of player's addresses. Is there a match? Yes. The payout to matching addresses (payouts could be split - 1/58 chance). If not then look at next least significant. If there is no match for 10 digits (essentially quadrillions to one) then payout 10 BTC back to all players - void game. Any comments? This is exactly the kind of concept I was looking for |
|
|
|
This came to me the other day, and i'm unsure on the details as I haven't went into the transaction scripts yet so please excuse me if the whole idea is nonsense.
Would it be possible to implement a PRNG in the transaction script in such a way that the payouts are automated to the winner of a gambling game? Something such as comparing the output of the PRNG specified in the transaction script with the last byte of the address and a small whitelist of addresses.
I presume that the scripting is turing-complete but space limited, but i'm not too familiar with this aspect of bitcoin myself.
Thoughts anyone?
Assuming it is turing-complete, you still need enough "random" data to seed your PRNG. Where are you going to get that data from in a way that isn't reproducible at a distance? That's the whole point in fact - the data must be reproducible so that all players get the same sequence and same experience |
|
|
|
|
This came to me the other day, and i'm unsure on the details as I haven't went into the transaction scripts yet so please excuse me if the whole idea is nonsense.
Would it be possible to implement a PRNG in the transaction script in such a way that the payouts are automated to the winner of a gambling game? Something such as comparing the output of the PRNG specified in the transaction script with the last byte of the address and a small whitelist of addresses.
I presume that the scripting is turing-complete but space limited, but i'm not too familiar with this aspect of bitcoin myself.
Thoughts anyone?
|
|
|
|
|
I hope Yankee does not mind me mentioning this in public but I did ask him if it's wise to go on Bruce's show - he convinced me it was, and seeing the result i'm glad that he did.
Bruce may have a dodgy history, but nothing in that show should be taken as representing BitInstant as being associated with Bruce's past.
|
|
|
|
|
Yankee has very kindly spoke on my behalf in saying London would be easier for myself to get to and i'll back that up.
Having put my bias in writing, London is indeed a much greater financial centre than berlin, not to mention the lack of language barriers etc.
|
|
|
|
I wonder if anyone is willing to buy pie for bitcoin - anyone? Do you ship to Europe? I live in the UK and i'd basically just be putting in an order on your behalf to fortnum and mason, who only ship fresh food within the UK sadly. |
|
|
|
|
I wonder if anyone is willing to buy pie for bitcoin - anyone?
|
|
|
|
|
Yes, it's true - without pie BitInstant would not exist - I wrote most of the code while eating pie.
Specifically, poacher's pie from fortnum and mason - it's a pork pie with a layer of cheese inside and whole onions on top.
Just ask Yankee about me and pie, he will confirm - it's all pie-powered!
|
|
|
|
anyway its your job, cheers
Thanks for the tip anyway |
|
|
|
Just a feedback. I ordered exchange LR->MTGOX. Since the order and to its completion I got 5 emails with dosens confirmations and codes. It taked 2 hours while i figured out where is the mtgox code in this heap. It was in 4th mail from you.
Can't it be more simple and user-friendly?
Hello! Thank you for your feedback. The answer is yes, we are working on new software that will credit your funds instantly on your mtgox account instead of you having to credit the redeemable code automatically. Thank you for using our services! MTGox's API does not have a facility for doing direct deposits into other user's accounts. To clarify what I meant here - it is not possible at present to deposit into a user's account from a third-party website as the API does not allow it. This could be changed on gox's side - but has not been changed. Therefore there is no possible way you are currently working on actual code for this. |
|
|
|
|
Show Posts
