You mean to say the win/lose status of the bets are only disclosed when there's at least one confirmation - that is the information needed to know whether to double-spend with better fees to erase any losses.
Yes, I realized that almost immediately after doing the change. In fact it was a good mistake as it allowed me to capture two winning bets from the same attack before they were paid, reducing ever so slightly the loss. |
|
|
|
This particular attack we endured doesn't seem to be related to lockntime, as far as I can tell. The coins are originally sent back and forth across a few addresses a few times in small values and finally they get aggregated in one address like A ( http://blockchain.info/tx-index/46601326/e586b0cfa885c5fc8960205a9bfec228dc0dfa496c04b20172c66d1f9760076d) and B ( http://blockchain.info/tx-index/46646986/2076b8e5be0fcaed6e6652ea2a89a45d755462764f852e3e3b9fcda3bb035e3e). One vout from each of A and B (18 and 1 is one particular example) are then aggregated into C, which is then bet on Martingale at DoC with tx D. The long chain of tx without any fees takes a long time to get confirmed by the network and somewhere along the line C is replaced by another Tx, completing the double spend. The now rolled back transactions C and D were: {
"hex" : "0100000001f677169e7a5739be1e4c462e88fb1cc394a4ea061e4a1defc1f4d0e4e4aca9cf000000008b483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdcffffffff016a48c323000000001976a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac00000000",
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "cfa9ace4e4d0f4c1ef1d4a1e06eaa494c31cfb882e464c1ebe39577a9e1677f6",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d01 04e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc",
"hex" : "483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 2ddfe9616ddf358d81546a3a18034fc88b349656 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"15BZeHbK4gX8YugqBsHwyTnUAqF5GJjgBW"
]
}
}
]
}
{
"hex" : "0100000001c0e62a6ec5b1088d9341154de1855568e38c31b63702fb1d951f6e04b3ec1c2b000000008b4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415fffffffff016a48c323000000001976a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac00000000",
"txid" : "acaebd04202864eef6af5b9df8ca70b88875bc4cf540a6d0f8b010a87f00145c",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"vout" : 0,
"scriptSig" : {
"asm" : "30450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e501 04696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f",
"hex" : "4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 7d3b0ada4990415ac12b968174371c8e67dc691b OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1CRACKLiwFrZbAQz1yb9w22onHCMLbiMTY"
]
}
}
]
}
|
|
|
|
And diceoncrack fell on to this attack, it seems... https://bitcointalk.org/index.php?topic=138988.0I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update. I think that there are only two things I can do at this point; don't accept 0 confirmation wagers without fee and make sure the coins used on the wager tx are already on a block. Had I these measures in place the attack would have failed. That or simply not take 0 confirmation wagers, of course. If anyone need details about this attack let me know, I can dig the transactions that got rolled back. |
|
|
|
|
Ok, so it was a full on double spend attack and all my prevention methods failed miserably.
Until I find a new way DoC will only process bets after they have been included in a block, but we are trying to come up with a safe way to address this limitation.
|
|
|
|
|
Yeah, if the low bet volume we have on DoC gave me a good 10 minutes of anxiety parsing transactions to make sure no foul play was involved (and I'm still not sure) I can imagine what a major block reorg would do to SD...
|
|
|
|
|
So I'm not sure what happened yet, but it looks like diceoncrack.com was caught in a major blockchain reorg, either due to a split or a double spend attack.
I initially believed it was an attack as the rolled back transactions were almost all on the lost wagers, but a closer look made me realize the rolled back tx for winning bets not only existed, but they actually were of a total value of close to the lost wager ones. If it was an attack, it didn't go too well.
We have a few protections against the double spends but there's only so much you can do when accepting 0 confirmation tx, so for now and until I get to the bottom of this bets are processed immediately but only paid out when there's at least 1 confirmation on them, sorry for the hassle.
|
|
|
|
How come there aren't like... five million copycat sites of this yet? All I can think of is BTCDice and it doesn't even seem to work?
I think because it actually is harder to get it right than it seems. You need a deep understanding of the bitcoin protocol as most of the stuff you have to do is beyond the capabilites of the standard client. Besides BTCDice if I remember correctly I think there were one or two additional 1:1 copies that also went down quickly. And SDice will have forever the first-mover advantage, so any 1:1 copy will have a very hard time. If you want to compete with SDice you have to differentiate, not just copy (which is what I am trying with bitbattle.me  ). Actually I don't think there's much of a first mover advantage, if a site copied SDice exactly (actually I prefer the old SDice interface, so copy that please), with a well known operator, has reasonable max bet (minimum 200 BTC at the top), and a slightly less house edge (like 1.7%). I'd switch to the new site in a heart beat. There is one which is not a copy but an extrapolation based upon the basic principles of SD. The win cap is low because it has had only limited action and the code was maturing and the operator is an old forum member. I'm not saying what it is to avoid the shameless plug... |
|
|
|
|
Just so we're clear, I'm still not sure this is a good idea and gmaxwell does make a great counter point, but I would argue that the moment we implemented a second hashing algo that was not yet supported by the higher end hardware there would be a huge influx of mining capacity there, by virtue of the idling hardware already in existence, particularly so if it was one that was already supported by miners, such as scrypt.
Of course there would be FPGAs and ASICS for scrypt in the long run if the reward is big enough, but that would most certainly "even the score" across all grades of miners. I'm not talking about an open ended schema where user defined algos can be plugged in, of course. It has to be well thought of and probably the first network upgrade would be a huge PITA, but even if it took 6 months to 1 year for adoption it would still leave the network in a harder to subdue state, I believe.
The point about short term reversals being easier I don't believe is completely valid with proper adoption paths. The initial diff for a new algo would match that of the existing one, for example, making the reward very, very small in the initial run, and having the same diff change rules that the current client enforces would allow miners to slowly switch to the better algo for their hw, thus equalizing diffs in a safe way.
But, again, I'm not sure it is a good idea or even possible in the short run.
|
|
|
|
While discussing alternative uses for FPGAs now that ASICS will (or so I believe) make things a little less interesting for non-ASIC miners ( https://bitcointalk.org/index.php?topic=138183.0) I posted about supporting multiple hashing algos, not really thinking it thoroughly, but now that I've entertained the idea a little longer it sounds like something we could, in fact, integrate in the bitcoin protocol. It might seem a bit out there, but there are two major points in favor of this idea as far as I can see: - Makes it a lot harder for someone (read company or government) to just throw money at hardware and overtake the network - Prevents a potential flaw in sha256 or quantum computing from killing the blockchain (even if temporarily, I understand that we can always address that as needed by just changing the algo, but still) So the very simplistic view I have of this is that instead of block hashing having to be done exclusively by sha256(sha256()) there would be a flag indicating which hashing algo was being user per block, with, for example, scrypt or sha3 added. Of course the list would have to be definitive per client version and the majority of the miners would have to agree, as always. A separate difficulty would be kept per hashing algo, so with ASICS taking sha256(sha256()) by storm, GPU users could use litecoin's approach of scrypt. Difficulty per algo would be calculated prorated between the hash counts, so the algos that have the larger work force would have the higher diff. It seems to me this isn't too complex to implement, bar the fact there would have to be an agreement between miners, and those invested in ASICS would be hard to convince to allow scrypt or whatever, but in the long run this would also protect them, as it would make the network as a whole much more hardened. What do you think? Should I start sleeping more or is this something that could be done? |
|
|
|
|
dibs on 1, 45, 91 and 100!
return earnings to 1HTonKbkim22nNXYv2NrA5H1Yoe7ogY5i9
|
|
|
|
|
Yeah, I didn't really think this through, of course, so this might be total bs, but it is possible to change the validator so that the hashing algo is something set on the hash, say sha256(sha256()):BLOCKHASHGOESHERE or scrypt:BLOCKHASHGOESHERE, and this way bitcoind could still validate all blocks irrespective of the hash. Surely the list of available algos needs to be fixed, though that would in theory be upgradeable by new versions of the software.
Not really knowing the validator code I can't say how complex it would be to manage multiple difficulty points, one for each algo, but all in all this would further future proof the system. If sha256 gets broken we can invalidate it using the majority vote for not accepting it on new blocks...
|
|
|
|
|
So, I don't really want to get into an 'alt-chain' discussion, but what if multiple hashing algos were available, each having a distinct difficulty attached to it, all usable on the same blockchain? This way ASICS would bring sha256(sha256()) difficulty up a lot, but GPU users could still use scrypt and FPGAs sha3. All in the same client, all in the same blockchain...
|
|
|
|
|
Would it be too expensive to ship to Europe?
|
|
|
|
O preço é em libra, pois é nessa moeda que os vouchers são comprados. Vai ter de criar uma conta na amazon se ainda não tiver (mas pode usar conta de qualquer amazon, não apenas uk). O voucher deve ser comprado aqui: https://www.amazon.co.uk/gp/product/B006AUF6X0/gcrnstsNeste momento 1 BTC custa £11.6, não esquecendo que com certeza vai ter custos extra no cartão de crédito. Se quiser fazer negocio eu prefiro user o IRC com utilizadores registados no bitcoin-otc. Me encontra por lá com o nick nelisky. Isto porque tem um grande risco para mim e tenho de ter a certeza que estou enviando BTCs para a pessoa certa. |
|
|
|
|
What's the CPU / RAM / HD on that one? How much would shipping be to somewhere in the EU (say, France, for example)? Are you willing to use escrow or send first for a well trusted member?
|
|
|
|
|
Bem, não é um negócio constante, mas eu estou vendendo alguns BTCs em troca de vouchers da Amazon.co.uk que podem ser comprados com CC. Ponho uma percentagem em cima para recomprar as moedas (alta, mas posso baixar para aqueles em quem confio) no entanto tem sempre taxas para usar um CC em moeda estrangeira, não sei se vai sair mais barato...
|
|
|
|
Can you also do amazon.co.uk vouchers?
my amazon account is created on amazon.de . do you know if i can make them on uk too? Well, the account will work in all amazon sites, but gift card balance I think is not usable across sites. I don't know how you obtain the vouchers, but if you are simply buying them, it should be fine. Can you verify this? |
|
|
|
|
Show Posts
