|
For 3 BTC I can write a python script that does this for you.
I should be able to have it written for you within a day of whenever you give me the go-ahead.
|
|
|
|
You can get a list of ip addresses for a ton of tor exit nodes like this: curl http://exitlist.torproject.org/exit-addresses | grep -o -e "ExitAddress [^ ]*" | sed "s/ExitAddress //" > ipban.txt
If you run this in a bash terminal, it'll download a list of tor exit nodes from the tor project, format it in a nice, easy to use format, and save it to a file named ipban.txt. You might want to set up, eg. a cron job to run this and update the file every once and a while. Then, you just need to make your script deny anyone with one of these ip addresses. Then, nobody can access your site over tor. This is what that command gives me at the moment: http://pastebin.com/0iM6GrkM |
|
|
|
Yes, and that would be a fine independent variable, various min, max, averages per transaction. I could calculate it I had a dump of all addresses per block. Can the blk*.dat tell me that? I don't want to DoS blockexplorer with wget/curl requests.
Yep, it's all in blockindex.dat. You might want to look into this patch: https://bitcointalk.org/index.php?topic=724.0 |
|
|
|
When will IPv6 will destroy bitcoins  It won't - IPv6 makes no difference in the scope of things over IPv4. |
|
|
|
Thanks everyone!
Glad you've got it working. Just curious, what was the solution that worked in the end? |
|
|
|
If you run this command, sudo dpkg-reconfigure postfix
you'll eventually get to a screen like this:
┌──────────────────────────────────────────────┤ Postfix Configuration ├───────────────────────────────────────────────┐
│ Please specify the limit that Postfix should place on mailbox files to prevent runaway software errors. A value of │
│ zero (0) means no limit. The upstream default is 51200000. │
│ │
│ Mailbox size limit (bytes): │
│ │
│ 0___________________________________________________________________________________________________________________ │
│ │
│ <Ok> <Cancel> │
│ │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Right now, postfix is complaining that the maximum size of a single email is larger than the maximum size of the entire mailbox. You could simply type in a lager value for the entire mailbox at this screen, and it should fix that problem. 0 means no limit on the maximum size. I think the default maximum email size is 10240000, so if you do set a mailbox size limit, make sure it's more than that. |
|
|
|
I'm taking this proposal as an idea to possibly working on. The only thing pop me in mind is, Is this method won't be to hard for the average user ? I wanna keep every escrowed transactions easy for everyone.
Well, the idea is that this happens behind the scenes on the server side. The users might not even know you're doing it. The goal is that anyone who now hacks your server can't send the bitcoins to themself, only to one of the parties in the transaction. In other words, it becomes impossible for anyone to steal bitcoins off of the server, thus increasing security. |
|
|
|
Yes, please read us the logs. You can get the most recent log messages with: Also, have you configured postfix yet? You can do so with: sudo dpkg-reconfigure postfix
This should give you a nice user interface to help configure your server. |
|
|
|
It is already trivial to determine the country of an IPv4 address based on public information form IANA and the various RIRs.
Yeah, if your ISP really wanted to block your access to the Bitcoin network, they definitely wouldn't need IPv6 to do it. IPv6 would actually help the network because no more NAT means more nodes accepting incoming connections. That's good because it means data travels faster from node to node. |
|
|
|
1 and 2 is doable using the current system:
Upon receiving some funds you can create an temporary address/private key pair, send the funds to this new address, and use the generated private key to generate the two outgoing transactions. Now store both transactions and throw away the temporary private key.
That way the original address does not vanish and so no coins will be lost.
Nice, didn't think of that. Are there any escrow services that use this method? If not, there should be!
Agreed. Maybe we should contact Btcrow, and suggest it to them? (I don't think anyone's using it yet.) |
|
|
|
|
+1 The services board is really getting crowded with loans. Needs own sub forum.
|
|
|
|
In file(con, "r") : unsupported URL scheme
The URL scheme is, in this case https. This means that R doesn't have https support. Google suggests looking into the package RCurl. Note that I've never programmed in R before. |
|
|
|
|
It would be nice if you could automatically withdraw funds instead of making me manually watch the balance and withdraw. For example, every day you could send the balance of any account with over 0.01 BTC in it. Because you'd be sending all of the payouts at once you could use a sendmany to save on transaction fees. Sounds like a better idea to me.
|
|
|
|
Thinking of security, would it be possible to write the platform in a way which prevents the site owners, moderators and any intruders from having access to the funds?
You could generate a new address every time that a sponsor wants to sponsor a project. Then when payment arrives, generate one transaction for every possible outcome (one transaction that sends the bitcoins back to the sponsor, and one that sends it to the developer) but don't broadcast them. After that, you delete the address' private key. When the outcome is determined (bounty should be sent to developer or returned to sponsor), simply broadcast that transaction on the network. This way, the most damage an attacker could do would be to choose whether the bounty went to the developer or the sponsor. The attacker could never send any of the coins to himself (unless he was the dev/sponsor). This has a few downsides: - If the sponsor sends coins to an address after its private key is destroyed, those coins are gone.
- You still keep the private key around until a payment is received.
- All developers must be known before the bounty is moved to escrow. Any developer that appears late in the game cannot collect bounties held in escrow before he started work on a project.
It would be nice if we could create transactions that said to forward all funds sent to one address, present and future, to another address. That would kill problems 1 and 2. (Also useful for ex. importing an untrusted address into one's wallet.) If this isn't possible currently w/ script, it sure would be nice to see implemented. (Bounty anyone?  Gotta love irony.) |
|
|
|
|
Show Posts
