Bitcoin Forum
May 22, 2019, 02:19:15 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 »
441  Bitcoin / Bitcoin Technical Support / Re: Setting up multiple bitcoin machines behind NAT on: May 16, 2010, 11:56:03 PM
At the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you're redirecting from another port number.

I'm not in a big hurry to fix this because I can't think of any benefit to having more than one incoming connection port.  If you're providing one incoming port, then you've done your bit to help the network.  Having two incoming ports to the same person doesn't help redundancy.

If you have many computers, then using the -connect switch on most of them to connect locally makes more sense.
442  Bitcoin / Bitcoin Technical Support / Re: removing bitcoin addresses on: May 16, 2010, 11:34:40 PM
SheriffWoody:
Bitcoin addresses you generate are kept forever.  A bitcoin address must be kept to show ownership of anything sent to it.  If you were able to delete a bitcoin address and someone sent to it, the money would be lost.  They're only about 500 bytes.

sirius-m:
Thousands of own addresses should not be any problem at all.  If you've generated 50000 BTC, then you already have 1000 own addresses, one for each 50 generated.  Those are hidden, they're not shown in the UI.

It would be a good idea to add a little code that keeps giving the same address to the same IP.  Here's what I did in C++ to keep giving the same key (aka bitcoin address) until they use it:

    // Keep giving the same key to the same ip until they use it
    if (!mapReuseKey.count(pfrom->addr.ip))
        mapReuseKey[pfrom->addr.ip] = GenerateNewKey();
    
    ...sends the key mapReuseKey[pfrom->addr.ip]

...later...

    // Received something with this key
    mapReuseKey.erase(pfrom->addr.ip);

If it's not convenient to know when you've received, just clear the cached keys every 20 minutes.

I want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address.
443  Bitcoin / Bitcoin Technical Support / Re: Exception: 9key_error error on: May 16, 2010, 10:53:59 PM
Does it happen every time you run it, or just happened once at some random time?

I've never seen that fail before.  It's a call to OpenSSL that I assumed would never fail, but I put an error check there just in case.  I can't imagine how it would fail.  Out of memory maybe.

The code is:

key.h:
    EC_KEY* pkey;

        pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
        if (pkey == NULL)
            throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");

NID_secp256k1 is a constant.
444  Bitcoin / Development & Technical Discussion / Re: URI-scheme for bitcoin on: May 16, 2010, 10:37:21 PM

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.


A bitcoin-link should be more like mailto: than magnet: IMHO.

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.


445  Economy / Trading Discussion / Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? on: May 16, 2010, 09:37:36 PM
I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.
That's a good idea.  At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

446  Bitcoin / Development & Technical Discussion / Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add on: May 16, 2010, 09:01:44 PM
When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes).  It's like generating a new PGP private key, but less CPU intensive because it's ECC.  The address space is effectively unlimited.  It doesn't hurt anyone, so generate all you want.
447  Bitcoin / Project Development / Re: Idea for file hosting and proxy services on: March 24, 2010, 06:02:55 PM
Mihalism Multi Host is a popular open source PHP file hosting server.

It's geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting.  They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed.

It doesn't have a bunch of client side scripting or anti-embedding junk to rip out.  It generates standard links that work normally.

There's a turnover churn in these free hosting sites.  Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth.  Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs.  It's a perfect example of a service where the needed price point is in the no-man's-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment.  It's in the gap between 0 and 19.95.  The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders.  It can't really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.

An example of a site running the software:
http://www.imagez.ws/

Forum:
http://www.mihalism.net/

Download:
http://code.google.com/p/mihalismmh/

What do you think?  If I made a Bitcoin payment integration for this, would anyone be interested in running it?  It might be the first fully automated service available to buy with Bitcoins.  The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops.  It would give a normal link directly to the file.
448  Bitcoin / Project Development / Re: Idea for file hosting and proxy services on: March 24, 2010, 06:01:57 PM
Title changed.

It helps that we have someone with actual experience running a proxy service.  Do you think Psiphon is the best one currently?  (sometimes the one you run was the best when you started but you found better ones later)
449  Economy / Trading Discussion / Re: Exchange Methods on: March 23, 2010, 05:35:34 PM
LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that.  The possibility to cash out through them would help support the value of bitcoins.

Bitcoin has unique properties that would be complementary.  LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts.  Bitcoin, on the other hand, is easy to get in small amounts anonymously.  It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods.

Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it.
450  Bitcoin / Bitcoin Discussion / Re: who is bitcoin.com on: March 23, 2010, 03:22:41 PM
It's unrelated.  There wasn't anything there when I started.

The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator.  Fortunately, it's standard for open source projects to be .org.
451  Bitcoin / Project Development / Re: Idea for file hosting service on: March 16, 2010, 08:17:34 PM
That's a great idea.  There's a thriving business in those services, but I've always thought the standard payment methods are at odds with privacy minded customers.

Would you consider making your software freely available so anyone could easily set one up?  I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.

I wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?
452  Bitcoin / Development & Technical Discussion / Re: On IRC bootstrapping on: March 16, 2010, 07:48:47 PM
Thanks soultcer for talking with the Freenode staffer.  Good to know it's OK at the current size, and now they know who we are.  They're supportive of projects like TOR so I hope they would probably be friendly to us.  We don't want to overstay our welcome.  If we get too big, then by the same token, we're big enough that we don't need IRC anymore and we'll get off.

We only needed IRC because nobody had a static IP.  In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days.  IRC was only intended as a temporary solution.  Bitcoin's built-in addr system is the main solution.

Bitcoin can get the list of IPs from any bitcoin node.  In that sense, every node serves as a directory server.

When there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.

How do you think we should compile the seed list?  Would it be OK to create it from the currently connected IPs that have been static for a while?

BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC?  IRC is a good directory server (I've heard it has other uses too), and there are mature IRC server implementations available that anyone can run. Smiley  Bitcoin's IRC client implementation is already thoroughly tested.
453  Bitcoin / Project Development / Idea for file hosting and proxy services on: March 15, 2010, 07:16:56 PM
When you want to upload an image to embed in a forum post, there are services like imageshack, but because they're free, they limit the number of views.  It's a minuscule amount of bandwidth cost, but they can't just give it away for free, there has to be something in it for them.  It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.

It's worse if you want to upload a file for others to download.  There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.

It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins.  Anyone with some extra bandwidth quota could throw it on their webserver and run it.  Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles.  Ideally, it should be MIT license or public domain.

Services like this would be great for anonymous users, who have trouble paying for things.
454  Bitcoin / Bitcoin Technical Support / Re: bitcoin auto-renice-ing on: March 15, 2010, 06:44:12 PM
It sets different priorities for each thread.  The generate threads run at PRIO_MIN.  The other threads rarely take any CPU and run at normal.

#define THREAD_PRIORITY_LOWEST          PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL    2
#define THREAD_PRIORITY_NORMAL          0

The priorities converted from Windows priorities were probably from a table like this:

   "The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.

nice value    Win32 Priority
-20 to -16    THREAD_PRIORITY_HIGHEST
-15 to -6    THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4    THREAD_PRIORITY_NORMAL
+5 to +14    THREAD_PRIORITY_BELOW_NORMAL
+15 to +19    THREAD_PRIORITY_LOWEST"

If you have better values, suggestions welcome.

Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes.  If that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.

    // threads are processes on linux, so PRIO_PROCESS affects just the one thread
    setpriority(PRIO_PROCESS, getpid(), nPriority);
455  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: March 05, 2010, 01:46:25 AM
This is strange... When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there's something wrong with the build or something.
sirius-m debugged this, it was 64-bit related. 

The fix is now available on SVN, file util.cpp.
456  Economy / Trading Discussion / Re: Money Transfer Regulations on: March 03, 2010, 04:28:56 AM
When there's enough scale, maybe there can be an exchange site that doesn't do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.

To make it safer, the exchange site could act as an escrow for the bitcoin side of the payment.  The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller.  The exchange service doesn't handle any real world money.

This would be a step better than e-bay.  E-bay manages to work fine even though shipped goods can't be recovered if payment falls through.
457  Bitcoin / Bitcoin Discussion / Re: New icon/logo on: March 02, 2010, 02:33:05 AM
We have the standard icon sizes, and the full size scales nicely to anything else.

I added the full size to the first post.
458  Bitcoin / Development & Technical Discussion / Re: wxWidgets 2.9.0 on: February 27, 2010, 09:22:53 PM
Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
In the Windows world, "unicode" means UTF-16 (wchar).

2.8 has two build variations, ANSI and UTF-16 (unicode).  The UTF-16 version is the "unicode" version provided in the Debian package.  I believe 2.8 and its UTF-16 build labelled simply "unicode" has been the source of build problems described in the forum.  We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell.  We cannot compile with UTF-16.

2.9 has only one version, UTF-8.  On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8.  On Linux I assume the codepage is already UTF-8.  By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.

Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given.

Curious, why is it incredibly hard to provide wxWidgets 2.9.0?  If you mean for users, that's why we static link it.

It's unfortunate that we require so many big dependencies, but we need them all.  At least on Debian/Ubuntu, all but wxWidgets are available as packages.  Eventually they'll provide a 2.9 package.
459  Bitcoin / Bitcoin Discussion / Re: New icon/logo on: February 27, 2010, 04:28:29 AM
How about an SVG version? That way we could automatically generate smaller and larger versions as needed.
I don't know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down.  I'll give the original when I'm finished.

I had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent.  Such is the challenge of making icons.  The original will be good for scaling to custom sizes between 48 and 500 but not smaller.
460  Bitcoin / Development & Technical Discussion / Re: Command Line and JSON-RPC on: February 26, 2010, 11:48:44 PM
Are you using wxWidgets 2.9.0?  I don't recommend using anything other than 2.9.0.

It looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase.

Removing -D__WXDEBUG__ from bitcoin's makefile would probably solve it.

If that doesn't work and you just want to get it working, you could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the wxASSERT_MSG.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [23] 24 25 26 27 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!