There is a bot grabbing secrets every hour, on the hour. We feel proud someone took the time to actually do it  Now, just a small detail about how the timepoints are created; the hour part needs to have 2 digits, so have a 0 (zero) prepended if < 10. Meaning '20121206:9' needs to become '20121206:09'. Added some text to "how to use" to make it clear. you might want to parse that a little more robustly. I can, and I would but this is always a question of code complexity vs security&performance. It is much easier to introduce an exploitable bug when we start catering for special cases in public APIs, but you know that for sure. Of course this is a simple example, but I try to keep that as a rule of thumb for all machine interfaces. Humans tend to guess and be inventive, machines just do what they're told to do. |
|
|
|
Not using enough inputs for the output, using spent inputs or (more likely) need to add fees for transaction to be accepted.
I couldn't be using spent inputs since I list them with listunspent and also using enough inputs judging by the code, is there a way to check how much transactions fees do I need to pay for said transaction? most of the time you'll get away with 0.0005 BTC fee, though that depends on a number of things. You can also patch your bitcoin daemon to not enforce fees, but then your transactions may take a long time to be included in blocks, if they ever are (depends on miners accepting them). |
|
|
|
|
Not using enough inputs for the output, using spent inputs or (more likely) need to add fees for transaction to be accepted.
|
|
|
|
td;du
(too dumb; didnt understand)
Which means the message is not of importance to you But in case you are planning on making use of the JSON API all I meant was someone has a script that grabs secrets as they become available, using a call like https://lbaat.net/getSecret.json?timepoint=20121206:9 and if you try that you'll see the response does not have any real data. To get the data from that timepoint you need to prepend a zero to the hour part (digits after colon) to make it 2 digit long, so https://lbaat.net/getSecret.json?timepoint=20121206:09 will work as expected. |
|
|
|
There is a bot grabbing secrets every hour, on the hour. We feel proud someone took the time to actually do it Now, just a small detail about how the timepoints are created; the hour part needs to have 2 digits, so have a 0 (zero) prepended if < 10. Meaning '20121206:9' needs to become '20121206:09'. Added some text to "how to use" to make it clear. |
|
|
|
Would my above-proposed method of using multiple LBAAT-like services work (encrypt the message using the "product" (?) of n public keys from n independant services and then everyone would be able to decrypt it once the n secret keys are revealed) or am I misunderstanding something?
It would work assuming other time keeping services existed, sure. Assuming the encryption step itself was done offline to keep things safe, that would be a good solution although there's an extra step that happens behind the scenes at lbaat, and that is timestamping and checksumming (sort of) the plain message before encrypting, to prevent attacks where someone provides garbled text stating it is an lbaat encrypted message, or simply provide the wrong timestamp for decryption. With your multiple services approach that part is lost, though it might not be important for whatever use case you are considering, of course. |
|
|
|
|
It is quite different for private keys and for messages. The former is just a contract in the form of lbaat holding a secret (that it knows ahead of time) but not disclosing it before the agreed time. Knowing the secret gives no advantage to lbaat, and the only "attack" possible would be not disclosing the secret at all, making the address unusable and any coins sent there lost. This particular issue will be addressed shortly.
The latter usage with the messages is trickier, because the message is disclosed plainly to lbaat at encryption time. One option would be to provide the user with tools to do asymmetric encryption with a public key, the result of which would then be encrypted by lbaat. Once decrypted when the secret is revealed the user would then use his private key to retrieve the plain message, but this presents a usability challenge; making this easy to do for unskilled users is a problem, and making sure said users keep the private key safe is another.
Maybe the ability to use some password to encrypt the text prior to sending it to lbaat? It could be a simple, not all that safe password, but it would add a layer that would make it harder for lbaat to misbehave and read the secret messages.
|
|
|
|
If you are thinking about turning this ability of yours into a BTC business, how about you providing carrier service for items sold here and in bitcoin auctions between the two sides of the pond? How much weight can you carry? I mean, many times have I given up on a deal because it would be expensive to ship (heavy or bulky) and I'd have VAT on my side too (21%). If you would charge 5~10% over the sale price that would be much cheaper for me and a good deal for you. There's obviously the issue of trust and once on the EU side you'd have to ship the item so I could receive it, so not straight forward. Just an idea really... (I would love it if you could carry a rack mountable server for me ). |
|
|
|
What is the reasoning behind showing every single possible bet on the page for each pick rather than just ones that have been submitted? This makes them incredibly hard to read, and just seems completely unnecessary. If it was toggleable then I'd be satisfied.
We have added detailed/resumed views to the Pick pages, you can find the toggle below the numbers table. Whatever you choose will be used thereafter, assuming you have cookies enabled. Do let us know if it improves your experience. Thanks for the feedback! |
|
|
|
I can't say for sure how long it has been, but from a day or two ago I have 0 accepted (and 0 rejected) shares? Wtf? cgminer reports the speed accurately (2.4.1 on openwrt) but that's that, basically.
Are you seeing accepted shares in cgminer, but not on website under "my account" -> "workers" ? You are sure you are using the correct credentials in your cgminer config? If you send me your BitMinter user name I can have a look at things on the server side. You can email me at operator@bitminter.comNo accepted shares on either cgminer or website, and yes, I'm sure the credentials are correct (unchanged). I'll email you the username. Following up on this issue, the problem lays in endianess. I will submit a pull request for this to cgminer, it is working fine for both default work fetching and GBT, haven't tested on stratum yet. |
|
|
|
|
And we are adding a Pick 5 to the games available!
This means there's 1 in a million chances of hitting for each new block, more precisely one in 1.048.575.
Each bet costs 0.1 BTC and you can send your wager to 15TaABLmhxiRQ9DTX6ZcZ9S9RknVZmP5jX.
Good luck!
|
|
|
|
I can't say for sure how long it has been, but from a day or two ago I have 0 accepted (and 0 rejected) shares? Wtf? cgminer reports the speed accurately (2.4.1 on openwrt) but that's that, basically.
Are you seeing accepted shares in cgminer, but not on website under "my account" -> "workers" ? You are sure you are using the correct credentials in your cgminer config? If you send me your BitMinter user name I can have a look at things on the server side. You can email me at operator@bitminter.comNo accepted shares on either cgminer or website, and yes, I'm sure the credentials are correct (unchanged). I'll email you the username. |
|
|
|
|
I can't say for sure how long it has been, but from a day or two ago I have 0 accepted (and 0 rejected) shares? Wtf? cgminer reports the speed accurately (2.4.1 on openwrt) but that's that, basically.
|
|
|
|
|
We have a winner! Sent from the address '19ZzbTTqNouSpNND5anz5QvaZX98Pxvzdf' came the winning bet.
If this address is yours (you will have received 2 satoshis when the raffle ended) please prepare a message with your name and shipping address and sign it using the winning address, then send both to me by PM.
If you need help in doing this post a message here or PM me and we'll walk you through the process.
Congratulations!
|
|
|
|
|
It looks like we're picking up speed; the last Pick 3s were record breakers at BTC 8.613 and BTC 8.217 pots and the running Pick 4 has a whooping BTC 28.809 pot at this moment.
Good luck!
|
|
|
|
And the raffle hasn't found a winner yet! There's still time to place your bets, folks. This is the longest running Pick 4 game we've had to date (but we have been running for very little time still ). |
|
|
|
|
Hi Jan,
Are you planning on open sourcing or at least providing the server to selected individuals so that redundancy can be achieved by community effort?
|
|
|
|
It seems the bitcoin client used for processing payments is refusing to sign the payout transaction, which is quite awkward as it should only happen if the transaction or the block was rolled back, which isn't the case. I'll keep trying to fix this, but in the mean time I'll send you a manual payment. If I do fix this there's a good chance you'll get a double payment, which I'm sure will greatly upset you |
|
|
|
|
Show Posts
