 Show Posts
|
|
Pages: « 1 2 3 [4] 5 »
|
|
No problem! I'll leave it and withdraw my offer for now.
|
|
|
|
|
Any more offers?
Still happy at 60 despite the increased BTC-USD exchange.
|
|
|
|
60 BTC Including shipping to the UK Not sure where you but as you state it has an EU plug, you're probably not so far away so shipping to the UK should be cheaper, please consider that when comparing my offer with any others  |
|
|
|
I'm not sure you need a worm hole. I think a large entangled set of photons would do. But however large the number of photons would be, you could only send a finite amount of data. But it might be enough if you plan on coming back on Earth some times to times (every century or so). Or if you accept visits from Earth. http://en.wikipedia.org/wiki/Quantum_entanglementQuantum entanglement does not allow FTL communication. |
|
|
|
When would a retailer ever accept a transaction on faith? We live in a business world where everyone lives to help themselves. I still think the debit account would be one of the fastest ways. But I agree that personal checks would take a lot longer and be a lot more risky.
Retailers accept a transaction on faith every time they accept a credit card. Or even cheques which were still used up to a few years ago. |
|
|
|
I wouldn't mind the confirmation so much if it was made obvious that I would have to wait. On Kiba's file, it said: "send at least 0.102 coins to <address>" So I went to my bitcoind and did sendtoaddress <address> 0.102 Everything seemed fine and I kept refreshing but it still wouldn't let me download the file. Then I remembered that bitcoin still only works in cents so I had to send another .01 and then wait for a confirmation before I was able to download the file. It was pretty confusing - maybe you should round up to the nearest .01 so that I can actually send the amount you require, since bitcoind didn't inform me that it only sent 0.10 when I tried to send 0.102. |
|
|
|
I thought of a possible problem with all these proposals: front-running by miners. This is where a miner sees an attempt to register a name, thinks it is a good name, and registers it for himself instead. Since domain registration fees are based on the value of average names, extra-good names wouldn't be covered by the fees and might be stolen in this way. Some existing registrars have been accused of a similar practice, registering names through agents after people query for name availability.
This is a very good point. Any domain registration message to the network could potentially be hijacked. It doesn't matter what the system is, if you're loosely connected and you send a registration message into the network, a well connected client on the network could simply resend the message using the same domain and possibly get to a larger proportion of the network faster than the original sender's registration message, causing his registration to be more likely to be included in the block chain. I'm not sure what the solution to that is. Of course the person who does this will have to spend whatever it costs to register a domain to do this attack, which will have a natural limiting effect on it, which may be the best we can hope for. Can anyone think of a solution? Perhaps having to mine a hash for the domain registration message with much less difficulty than mining for domaincoins/whatever, but just to slow anyone down from being able to instantly register a domain as their own. |
|
|
|
Anyway, I have registered domainchain.org, in case people like it.
Care to stick a wiki up on there? |
|
|
|
|
I like DomainChain as well.
I would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.
Do we have a wiki yet?
|
|
|
|
Revoking is a bit more risky. If 1% of generation power doesn't support revoking unlocking transactions, then there's a 1% chance that the revoke will fail. In this case a failed revocation is just an "accidental withdrawal", though.
Couldn't a block including a known revoked withdrawal be ignored as invalid by the other clients though? |
|
|
|
Are we seeing the first "pretty much impossible" collision here? How are the addresses generated? Although obviously there's technically a huge huge number of them, they are limited by the randomisation function used to generate them, unless the openssl libs do something a lot more clever (got as far as EC_KEY_generate_key, but got lost in the openssl source). Typically randomisation will be seeded by the clock value, which will probably be in milliseconds, so there seems that there's a definite/significant possibility of collisions. Hopefully someone can educate me on why this isn't a problem. |
|
|
|
Nonetheless this code looks really really weird certainly missing lines or context. // Okay let's initialize a variable to a fixed or random value
// If it's true
// Set it to true,
// then do something I don't think it's so weird, it's just ensuring it will only print that cpu info line for the first call of the function. |
|
|
|
It is settled.
Bencoder's download site will be used by Kiba from now on.
Bencoder's terms are VERY FAVORABLE compared to ubitious.
1. I don't have to pay a fee just to make money.
2. He only take 10% or .01, whichever is higher.
3. Files don't expire, period.
[teaser] More features will come on ubitio.us, including setting price and something else.. But core features like anonymous uploads/downloads, pay to upload and expiration will be there for sure. [/teaser] excellent  <3 competition |
|
|
|
Bencoder's terms are VERY FAVORABLE ... Files don't expire, period.
So I can back up my system to Bencoder's site any time I want, and all it costs me is 0.1 BTC if ever I need to restore my files. Bargain! Good luck backing that up through the web upload service with a small upload limit. It's a good point though, I need to investigate and make file size and upload terms more explicit. |
|
|
|
|
I just asked about a betting exchange in the irc today, didn't notice this thread before. I was thinking of starting to work on one for football(soccer, that is).
Any chance of being able to change the odds display? I can't understand American/US style odds very easily at all. Decimal makes the most sense to me, but lots of people swear by fractional - you should probably try and support all of them if possible.
How are you settling your bets by the way? That would seem to be the most difficult part to me, seeing as most of the live scores & results feeds available charge massive amounts. Been looking out for some decent free feeds for football results that are updated in a timely manner and not finding anything yet.
|
|
|
|
I missed something.. Where I can learn more about bencoder's site?
Sorry I only just made it last night, haven't advertised it at all yet except in the irc... but here it is: http://www.bitcoinservice.co.uk It still needs a lot of work and I think you've got a much better domain for yours but mine has an account based model rather than your instant anonymous uploads. Now that I have the accounting stuff I can add more features and services based around that than just file downloads. File downloads was a quick easy thing to implement and I wanted something that I could build quickly yesterday. Hope you don't feel too threatened by the competition |
|
|
|
Thank you very much for your reply. If more instances of running program with the same wallet isn't possible, I think it should be documented. But OK, so I can other scenario: I have 2 computers, one at home, one at work. I'm running bitcoin at home, then I shut it down, go to work, start running bitcoin there, with the same wallet. Then shut down, go to home, start bitcoin at home and so on. BUT: I don't synchronize files (~/.bitcoin). So I don't run more instances of the same wallet but I don't synchronize current state. It's this possible? Will be synchronized sent and received payments or are there other problems? Or rather I should use two different wallets, one at home and one at work? Thanks They won't be synchronised. It might synchronise for a little while until your 100 saved addresses are used up, but after that you'll be using different addresses on each machine, so it will become unsynchronised... so if you make a payment you'll get the change on one machine but you wont get it synchronised on the other, you'll just see the loss of money. I am curious if/how it would cause any problems beyond a forking of the wallet though. |
|
|
|
IP addresses are not a 100% replacement for domain names; try it with some of the seized domains and see what happens.
Assuming the web server is still running and you know the ip then just put it in your hosts file with the now defunct domain, so that your browser will send the correct host so the web server will serve the right site and any absolute links on the site will work as well. |
|
|
|
|
