|
Taking people's coins is not the same as taking coins that no one controls. Since you can't tell the difference just let it be.
|
|
|
|
|
You should contact mem and/or mc_lovin about maintaining the gambling section.
|
|
|
|
I can agree that the marketing ring to the article was a bit negative. However, it is a constructive article. Authors propose an improvement which will make 0-confirmation transactions safer.
If you read it carefully, the proposed alert mechanism may be very useful.
I read the suggestions presented in the paper, and I've personally proposed both over a year ago. Looks to me like someone has been lurking the forum and turned that into a school project. The 'listening post' solution that they present isn't even as hard as they imply, because there is a flaw in how they perceive transactions propagate. Normally, a transaction is transmitted to every peer once verified, but do not propagate those that fail validity at all. So any particular vendor is unlikely to ever receive both transactions in a race attack, as the only nodes that get both are, by definition, the "front" where the propagation waves of each transaction meet. Yet if a vendor, who accepts 0/conf transactions, were to modify his own client to send transactions to all peers except one (preferablely as far from himself along the network topology as he could determine) then that client could simply wait to get the 'correct' transaction from both his "nearby" peers and his chosen special peer from across the network. If they match & are good, then a (successful) race attack is very unlikely. If they don't match or the special peer never sees either transaction, then something has gone wrong and the trade should not be approved. This method doesn't require that a special service or a distant node owned by the vendor exist. Seems obvious now but I'd completely overlooked it. I was thinking that you could wait and see if you hear another with the same inputs. |
|
|
|
Very good paper and very timely.
Propagating alert is a very good idea, and I wonder why it was not implemented in the first place. Does it allow to flood the network with false alerts? I do not think so, because both TR_A and TR_V must be included in the alert.
However, I can see an opportunity to flood the network with alerts by very heavily overspending. Attempt to spend the same coin N times will generate O(N^2) alerts. An attempt to quadruple (4) spend the same bitcoin will generate 6 alerts to propagate through the network. An attempt to spend 5 times will generate 10 alerts. An attempt to spend 6 times will generate 15 alerts and so on. If someone wants to overload BitCoin network, he will overspend the same coin 100 times and send each transaction to a different peer. This will generate 4950 alerts! Nice DDoS opportunity!
The algorithm to generate alerts must be a little bit smarter. The alert must not be propagated if node has already sent (or propagated) an alert for similar (or identical) collision.
Right now it notices the repeated use of the same inputs and ignores it right? It could ignore unless it was related to a payment to your wallet no? In that case it should change the tx from 'unconfirmed' to 'warning' or similar and ignore it. By ignore I mean don't pass on as you normally would. |
|
|
|
I came across this paper on Twitter
I doubt you'll come across it in a peer-reviewed venue. Is this really a problem for fast transactions?
No. It's a problem for 0-confirm transactions, which has been obvious since the original Bitcoin paper. "Fast" transactions can mean lots of things. Sounds like the "researchers" who wrote this paper concocted the new term so they could flaunt the problems it has. Pointing out the flaws in "I didn't wait for confirmations and got hacked" doesn't have quite the same ring to it. The authors need to re-title their paper "here is yet another reason you shouldn't accept 0-confirmation payment for non-recourse transactions". I didn't read it all, but I'd suggest a title of "wait 30 seconds and you're in the clear" |
|
|
|
Ok, I'll look into this if I have the time. I'll probably just write it to a list and then do a manual sendmany if I get around to doing this (because this would require fewer testing).
Does anyone know the exact format for sendmany on the commandline? Is it:
sendmany accountOne {"Bitcoinaddress1":"0.001", "Bitcoinaddress2":"0.001", "Bitcoinaddress3":"0.001"}
Also, I have done some testing with a couple of users and the video quality has been greatly improved in v0.6.2 which has just been released.
Nice, if you get it up I'll give at least 10BTC to hand out. I think this is double nice because people can send the millies to performers too. |
|
|
|
|
I think there might be more strategy if you let people pick the same slot and made them share the prize. Then there is a tension between the more likely numbers being desirable but not wanting to split. Being first on the best number that doesn't get doubled up on (will depend on the number of slots a player expect to be bought) would be ideal.
|
|
|
|
|
This is interesting. There is strategy, but I don't think it is to pick 16 first!
|
|
|
|
New version available: 0.6.1 see https://bitcointalk.org/index.php?topic=78517.20 for details. Currently streaming porn at Max quality, 640x320 8fps let me know how it looks. Regarding the faucet, thanks for thinking with me  I think it is a good idea, but is there any readily made software package? Is it just a form that sores the address? How would I built a large multiparty Bitcoin transaction of all these tiny numbers? And finally, FreeMoney, do you have that widget available you guys were talking about? No, I have nothing. We're just scheming. |
|
|
|
Seals would sponsor that for a while if you want.
Hmmm, can you make something like a widged that you can enable/disable when ever you want? People can come to you ( your website ) and ask for sponsoring. Than you will give the code to embed the widget on their site where ever they want. The widget will be something like this, example: ------------------------------------------------------------------------------------------ Take your free 0.001 Bitcoin, insert here your address: [ ] [captcha] [button send] Sponsored by sealswithclubs! ------------------------------------------------------------------------------------------ Hmm, faucet in a box. Could make it so that many people can sponsor, just associate an address to sponsor in the wallet that pays out, then show the sponsor who is actually giving the millie. Rule could be to show the sponsor who has the most credit and deduct the credit from their amount while they are showing. The largest sponsor will show until they are equal to the second largest sponsor and it'll start switching between until there it gets down to the third then it would switch between the three and so on. Back on topic, someone should stream these videos: http://bitcoinmedia.com/patronage-bitcoin-and-scientific-music-my-story/ |
|
|
|
I think that integrating your service with something like dailybitcoins/coinad will help a lot. This because people will come to your website "everyday" just to take their free 0.001 bitcoin! So they will see everytime all the opened webcam-channels That is smart. Seals would sponsor that for a while if you want. Man in general that is a genius idea. For anything that has variable coolness and you need people to check back frequently just make sure they know there will be free bitcoins. I suppose I kind of did this at Seals. In the beginning of course there were no games. Having a freeroll every hour kept people coming anyway. |
|
|
|
WOW! You are a rock star! Very nice. Next up: secret Channels. |
|
|
|
|
If you want to try some play money PLO and O8 visit sealswithclubs.eu:9087
|
|
|
|
I was really hoping for more exciting snapshots  Which means that, for example, the 260,000 token tip that Mila got, the member paid around $20,000 or $26,000 (depending on how he paid for it) and she got $13,000 Sweet Jesus that is some fee. |
|
|
|
No offense, but bitcoin is going to need at least a decade (maybe century) track record to even be considered in terms of gold. It is experimental. Will the block chain become too bloated? Will it be cracked? Will the network collapse? Can it handle 100,000 transactions a second. To have Paul comment on bitcoin is really lame imho.
Thank god for Paul to make a complete fool out of Krugman.
+1 The internet too, 100 years minimum before I'll be comfortable using it. |
|
|
|
|
Must essentially be transaction insurance right? That's cool.
|
|
|
|
|
Sheesh, looks like half the asks are gone since yesterday.
|
|
|
|
|
That's BADASS and I'm not talking about the Bitcoin Advertising Association.
|
|
|
|
|
Might be cool to mix education and 'menial' online labor. Like they teach you about brain structures and then you practice your knowledge by actually learning. Maybe use pay to sort out surpluses if needed. It would be cool to have something like coinworker, but more advanced, like maybe you need a some skill and/or to take a 5-60 minute lesson.
|
|
|
|
There is an old saying that goes something like this, "If you criminalize guns, only the criminals will have them."
which i completely agree with, except for the police and military. now go vote! What's that other saying... "If you grant exceptions for the crimes of the overclass they can comfortably commit crimes in plain sight"? Is that right? |
|
|
|
|
Show Posts
