Timechain
Search Donate
Sponsors
Cake Wallet, private Bitcoin and Monero walletSideShift.ai, no-signup crypto exchangeOrangeRock, non-custodial bitcoin spot and perps tradingBraiins Hashpower, buy and sell Bitcoin hashrateLayer Two Labs, drivechains for Bitcoin
Topic

Nodes and networking

202 writings, oldest first

  1. Private email (Adam Back)

    Citation of your Hashcash paper

    I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure I have the citation right. Here's what I have: [5] A. Back, "Hashcash - a denial of service counter-measure,"…

  2. Private email (Wei Dai)

    Citation of your b-money page

    I was very interested to read your b-money page. I'm getting ready to release a paper that expands on your ideas into a complete working system. Adam Back (hashcash.org) noticed the similarities and pointed me to your site. I need to find…

  3. bitcoin.org

    Bitcoin: A Peer-to-Peer Electronic Cash System

    Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto satoshin@gmx.com www.bitcoin.org Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without…

  4. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf The main properties: Double-spending is prevented with a peer-to-peer…

  5. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB…

  6. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Thanks for bringing up that point. I didn't really make that statement as strong as I could have. The requirement is that the good guys collectively have more CPU power than any single attacker. There would be many smaller zombie farms…

  7. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years. Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella…

  8. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Ray Dillinger: Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number…

  9. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Hal Finney wrote: Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it. That does not need to be…

  10. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone. A transaction will quickly propagate throughout the network, so…

  11. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: They both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We'll suppose exactly half received one first, half the other. In a short time, all the…

  12. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either…

  13. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: When there are multiple double-spent versions of the same transaction, one and only one will become valid. The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve…

  14. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context. A number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute…

  15. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Hal Finney wrote: Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a…

  16. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions. Ray Dillinger (Bear) wrote: Only the buyer signs, and there's no blinding. Identities are…

  17. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    Ray Dillinger wrote: Right, it's ECC digital signatures. A new key pair is used for every transaction. It's not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a…

  18. Cryptography mailing list (metzdowd)

    Bitcoin P2P e-cash paper

    James A. Donald wrote: I mean a node only needs the pending-tx pool for the best branch it has. The branch that it currently thinks is the best branch. That's the branch it'll be trying to make a block out of, which is all it needs the…

  19. Cryptography mailing list (metzdowd)

    Bitcoin v0.1 released

    Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority. See bitcoin.org for screenshots.…

  20. Private email (Hal Finney)

    Re: Crash in bitcoin 0.1.0

    I was temporarily able to reproduce the bug and narrowed it down to the "mapAddresses.count" in the following code. It was absolutely the last piece of code to go in and mainly only got tested with the MSVC build. It's not essential and…

  21. Private email (Hal Finney)

    How's v0.1.2 going?

    Well this doesn't look good. After you upgraded to 0.1.2, your node responded to one or two messages and then stopped replying to messages. It's still accepting connections and seems to be alive on IRC. That could happen if…

  22. Private email (Hal Finney)

    Re: v0.1.2 debug.log

    OK, so no crash or exception window or anything. debug.log is all I need then. It looks like there's a "select failed: 10038" error (the sockets select function failed) and then network communication goes quiet after that (except for IRC…

  23. Private email (Hal Finney)

    select failed 10038 fix

    I believe I've fixed the bug related to "select failed: 10038" (error WSAENOTSOCK). The select error is not a big deal, but it led the communications thread to get blocked on a socket that should have been in non-blocking mode but wasn't.…

  24. bitcoin-list (SourceForge)

    [bitcoin-list] Bitcoin v0.1.2 now available

    Bitcoin v0.1.2 is now available for download. See http://www.bitcoin.org for the download link. All the problems I've been finding are in the code that automatically finds and connects to other nodes, since I wasn't able to test it in the…

  25. Private email (Hal Finney)

    Re: select failed 10038 fix

    It definitely looks like 0.1.3 solved it. It was getting so there were so many zombie nodes, I was having a hard time getting a reply to any of my messages. Now, four inventory messages go out, four getdata messages come back. Did you get…

  26. bitcoin-list (SourceForge)

    [bitcoin-list] Bitcoin v0.1 Alpha release notes

    Release notes for Bitcoin v0.1 Alpha Bitcoin is a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority. You can find screenshots and the…

  27. bitcoin-list (SourceForge)

    [bitcoin-list] Bitcoin v0.1.3

    It looks like we're through with the worst of the Internet connection issues. 0.1.3 fixed a problem where your node's communications could go dead after a while. The network is running much more smoothly now with this version. If you've…

  28. Private email (Dustin Trammell)

    Re: Bitcoin v0.1 released

    Sweet, I was looking for a group like that on Usenet at one point to see what I would use if I needed, and nothing really fit. I'm sure Google groups is a lot easier to post to. There are some scenarios where a Usenet or Google group…

  29. Private email (Dustin Trammell)

    Re: Bitcoin v0.1 released

    There's at least one node who's inbound IP keeps changing all the time within the same class B. Maybe every time the program is run. I wasn't expecting that. Do you mind if I CC the rest of this to bitcoin-list or Cryptography? BTW,…

  30. Cryptography mailing list (metzdowd)

    Bitcoin v0.1 released

    I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow…

  31. Private email (Dustin Trammell)

    Re: Bitcoin v0.1 released

    I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow…

  32. Private email (Dustin Trammell)

    Re: Bitcoin v0.1 released

    I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow…

  33. bitcoin-list (SourceForge)

    Re: [bitcoin-list] Bitcoin v0.1 released

    I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow…

  34. bitcoin-list (SourceForge)

    [bitcoin-list] Bitcoin v0.1.5 released

    Version 0.1.5 is now available. It includes the fix for the problem Nicholas had, checking for disk full and changes to try to improve things that were confusing. Special thanks to Nicholas and Dustin for all their help and feedback!…

  35. P2P Foundation forum

    Bitcoin open source implementation of P2P currency

    I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at…

  36. P2P Foundation p2p-research list

    [p2p-research] Bitcoin open source implementation of P2P currency

    I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at…

  37. P2P Foundation p2p-research list

    [p2p-research] Bitcoin open source implementation of P2P currency

    Martien van Steenbergen wrote: </i>><i> His concept makes sure money is anonymous unless it is compromised, i.e. </i>><i> the same money spent more than once. As soon as it's compromised, the </i>><i> ‘counterfeiter’ is immediately…

  38. P2P Foundation p2p-research list

    [p2p-research] Bitcoin open source implementation of P2P currency

    Martien van Steenbergen wrote: > Would love to also see support for not having to supply and > managing money. Would make it easier and cheaper to maintain > and results in have sufficient money, always and everywhere. > No scarcity, no…

  39. P2P Foundation p2p-research list

    [p2p-research] Bitcoin open source implementation of P2P currency

    Michel Bauwens wrote: </i>><i> able to use it in real life? </i> It's fully operational and the network is growing. If you try the software, e-mail me your Bitcoin address and I'll send you a few coins. We just need to spread the word and…

  40. P2P Foundation p2p-research list

    [p2p-research] Bitcoin P2P e-currency v0.1 released

    Announcing the release of Bitcoin, a new open source peer-to-peer electronic cash system that's completely decentralized, with no central server or trusted parties. Users hold the crypto keys to their own money and transact directly with…

  41. P2P Foundation forum

    Bitcoin open source implementation of P2P currency

    Could be. They're talking about the old Chaumian central mint stuff, but maybe only because that was the only thing available. Maybe they would be interested in going in a new direction. A lot of people automatically dismiss e-currency as…

  42. P2P Foundation forum

    Bitcoin open source implementation of P2P currency

    It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow: - Whenever someone finds proof-of-work to generate a block, they get some new coins - The proof-of-work…

  43. bitcoin-list (SourceForge)

    Re: [bitcoin-list] Bitcoin v0.1.5 released

    Hal Finney wrote: The current version will work fine. They'll each connect over the Internet, while incoming connections only come to the host that port 8333 is routed to. As an optimisation, I'll make a switch "-connect=1.2.3.4" to make…

  44. Private email (Mike Hearn)

    Questions about BitCoin

    Hi Mike, I'm glad to answer any questions you have. If I get time, I ought to write a FAQ to supplement the paper. There is only one global chain. The existing Visa credit card network processes about 15 million Internet purchases per day…

  45. Private email (Mike Hearn)

    Questions about BitCoin

    Mike Hearn wrote: My best guess - it is the length of the global chain, and the rapid advance at the start is as the software downloads and verifies the preceding blocks in the chain as being valid. Right. I'm trying to think of more…

  46. Private email (Mike Hearn)

    Questions about BitCoin

    I started implementing a marketplace feature earlier that facilitates offering things for sale and taking orders, it's only half done though. A bit like e-bay but without auctions, just "buy now". Among other things, it would make it easy…

  47. Private email (Mike Hearn)

    Questions about BitCoin

    Got the 50. Transactions sent to a bitcoin address will always say "from: unknown". The transaction only tells who it's to. Sending by bitcoin address has a number of problems, but it's so nice having the fallback option to be able to…

  48. Private email (Martti Malmi)

    Re: Bitcoin

    Thanks for starting that topic on ASC, your understanding of bitcoin is spot on. Some of their responses were rather Neanderthal, although I guess they're so used to being anti-fiat-money that anything short of gold isn't good enough.…

  49. Private email (Martti Malmi)

    Re: Bitcoin

    mmalmi@cc.hut.fi wrote: That would be great! I added you (dmp1ce) as a dev to the sourceforge project and gave you access to edit the web space and everything. Definitely. This will be an absolutely essential feature once things get…

  50. Private email (Martti Malmi)

    Re: Bitcoin

    \> Next I'm going to implement the "minimize to tray" feature and the Now that I think about it, you've put your finger on the most important missing feature right now that would make an order of magnitude difference in the number of…

  51. Private email (Martti Malmi)

    Re: Linux build

    heapchk() is just a MSVCRT debugging thing that's not being used. It can be a no-op on Linux. OpenSSL automatically uses /dev/urandom to seed on Linux, so RandAddSeedPerfmon can also be a no-op. Don't let it connect to the network before…

  52. Private email (Martti Malmi)

    Re: Linux build, proxy

    Great, I've been looking forward to working on the Linux build. If you connect to Freenode's hidden service, then they tell you they've also banned TOR from that due to abuse and it kicks you off. There's a several step procedure you can…

  53. Private email (Martti Malmi)

    Re: Linux build

    I merged the linux changes into the main trunk on SVN. It compiles and runs now. I think all the problems are in the UI. The menus quickly quit working and it doesn't repaint when it's supposed to unless I resize it, and the UI is getting…

  54. Private email (Martti Malmi)

    Re: Proxy

    mmalmi@cc.hut.fi wrote: debug.log moved to the data directory "%appdata%/bitcoin/debug.log" 7 inbound and 2 outbound sounds about as expected. My last SVN commit included an overhaul of the code that selects the order of addresses to…

  55. Private email (Martti Malmi)

    Forum

    Now that the forum on bitcoin.sourceforge.net is catching on, we really should look for somewhere that freehosts full blown forum software. The bitweaver forum feature is just too lightweight. I assume the "Forum" tab on the homepage can…

  56. Private email (Martti Malmi)

    Re: Linux build ready for testing

    In the debug.log, it requests the block list, receives the block list, then begins uploading the list of blocks requested. It doesn't receive the blocks, but it didn't run long enough for me to be sure it would have had time yet.…

  57. Private email (Martti Malmi)

    Re: Linux build ready for testing

    Liberty Standard wrote: About how long did it take to start? It could be the node that you happened to request from is slow. The slow start is consistent with the slow download speed. I'd like to look at your current debug.log file and…

  58. Private email (Martti Malmi)

    Re: Linux build ready for testing

    Thanks for that, I see what happened. Because the first one was slow, it ended up requesting the blocks from everybody else, which only bogged everything down. I can fix this, I just need to think a while about the right way. There's no…

  59. Private email (Martti Malmi)

    Re: Linux - dead sockets problem

    I see what happened. All your sockets went dead somehow. You had no communication with the network, but because you had 8 zombie connections, it thought it was still online and kept generating blocks. You can tell this is happening when…

  60. Private email (Martti Malmi)

    Re: Linux - linux-0.1.6-test2

    I fixed a few places I found where it was possible for a socket to get an error and not get disconnected. If your connections go dead again, it should disconnect and reconnect them. I also implemented an inactivity timeout as a fallback.…

  61. Private email (Martti Malmi)

    Linux - linux-0.1.6-test3

    Right now (04:50 GMT) my node is connecting to yours and getting zombie connections each time. The socket isn't returning an error, just zombie without notice. If you're running the linux build right now, it would be interesting to see…

  62. Private email (Martti Malmi)

    Re: linux-0.1.6-test7

    Finally an easy one. I see a way that could happen on a long operation such as the initial download. The TryLock bug is unrelated to the db stuff. Fix will be in test8. I've been able to reproduce the db::open/close exception 3 times now…

  63. Private email (Martti Malmi)

    Re: Db::open/Db::close "Bad file descriptor" exception

    Thanks. The db::open/close errors confirm the pattern. More interesting is the zombie sockets activity towards the end, and the socket thread monitor tripped but didn't get it going again. Was the machine disconnected from the net?…

  64. BitcoinTalk

    Repost: Bitcoin Maturation

    -------------------- bitcoinbitcoin: Bitcoin Maturation Posted:Thu 01 of Oct, 2009 (14:12 UTC) From the user's perspective the bitcoin maturation process can be broken down into 8 stages. 1. The initial network transaction that occurs…

  65. BitcoinTalk

    Re: Repost: Bitcoin Maturation

    It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated. 1) During generation (when the status bar says "Generating" and you're using CPU to find a…

  66. BitcoinTalk

    Re: Repost: Request: Make this anonymous?

    There will be a proxy setting in version 0.2 so you can connect through TOR. I've done a careful scrub to make sure it doesn't use DNS or do anything that would leak your IP while in proxy mode.

  67. BitcoinTalk

    Repost: How anonymous are bitcoins?

    -------------------- bitcoinbitcoin: How anonymous are bitcoins? Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and…

  68. BitcoinTalk

    Re: Repost: How anonymous are bitcoins?

    > Can nodes on the network tell from which and or to which bitcoin > address coins are being sent? Do blocks contain a history of where > bitcoins have been transfered to and from? Bitcoins are sent to and from bitcoin addresses, which…

  69. Private email (Martti Malmi)

    Re: Bitcoin.org

    mmalmi@cc.hut.fi wrote: That's strange, I've seen Firefox 3.5 on XP anti-alias large fonts. Well anyway, your way is safer. I changed it back to text for now though so I can keep tweaking the colours. Drupal puts the <span> tags and junk…

  70. BitcoinTalk

    Re: A few suggestions

    Helpful suggestions, thanks. That's a good idea. The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake. Any portscan would only get a dead connection that doesn't volunteer to…

  71. BitcoinTalk

    Re: A few suggestions

    That's a good approach for mobile. Programmatic API used by PHP (any language) to present a web UI covers remote admin, mobile and any other client that can't be online all the time with a static IP. It would be like webmail. It would be…

  72. BitcoinTalk

    Re: Questions about Bitcoin

    1-3: For that level of anonymity you need to connect through TOR, which will be possible with version 0.2, which is only a few weeks away. I'll post TOR instructions at that time. 4: Version 0.1.5: backup the whole %appdata%\Bitcoin…

  73. BitcoinTalk

    Re: A few suggestions

    Right, the SVN has the almost-release-candidate 0.2 source, which can also be built and run on Linux. It hasn't been tested on FreeBSD. That would be a big help. TOR users wouldn't have to worry about how to get seeded, and we wouldn't…

  74. BitcoinTalk

    Re: A few suggestions

    Mac support would be nice. wxWidgets really pays off for cross platform. Please don't try PPC. PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a…

  75. BitcoinTalk

    Re: Is my second Transaction working correctly? +Transfer Question

    The transfer is immediate if you send by IP address. If you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it. Also, the recipient needs to be synced up with the block chain…

  76. BitcoinTalk

    Re: Number of connections?

    Coins generate at the same speed with any number of connections >= 1. More connections just add redundancy. If you only had one connection, what if that node is slow or busy, or only connected to you? Having several connections increases…

  77. BitcoinTalk

    Re: TOR and I2P

    I've been thinking about that for a while. I want to add the backend support for .onion addresses and connecting to them, then go from there. There aren't many .onion addresses in use for anything because the user has to go through a…

  78. BitcoinTalk

    Re: A newb's test - anyone want to buy a picture for $1?

    Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time. I…

  79. BitcoinTalk

    Re: A newb's test - anyone want to buy a picture for $1?

    The recommended ways to do a payment for an order: 1) The merchant has a static IP, the customer sends to it with a comment. 2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This…

  80. BitcoinTalk

    Re: Questions about Addresses

    Port forwarding forwards a port to one computer. It tells the router which computer handles connections to that port. So that's the computer receiving. If you didn't set up port forwarding, then incoming connections won't go to any…

  81. BitcoinTalk

    Re: TOR and I2P

    When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes. If you're using another port, it would assume it might…

  82. Private email (Martti Malmi)

    Re: Bitcoin API research status

    I noticed this in the docs for wxSocketServer::Accept(bool wait = true): "If wait is true and there are no pending connections to be accepted, it will wait for the next incoming connection to arrive. \*\*Warning: This will block the GUI."…

  83. BitcoinTalk

    Proof-of-work difficulty increasing

    We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009. The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that. For most of last…

  84. BitcoinTalk

    Re: Repost: Request: Make this anonymous?

    When you send to a bitcoin address, you don't connect to the recipient. You send the transaction to the network the same way you relay transactions. There's no distinction between a transaction you originated and one you received from…

  85. BitcoinTalk

    Re: Simple to implement feature requests

    There are command line options: bitcoin -addnode=1.2.3.4 to tell bitcoin about a node to connect to bitcoin -connect=1.2.3.4 connect only to the specified node(s) You can use more than one of these, for instance bitcoin -connect=(first to…

  86. BitcoinTalk

    Re: What's with this odd generation?

    There's a small transaction fee for very large transactions. The node that generates the block that contains the transaction gets the fee. If the same money gets sent again, it won't incur the fee again. If all you have is generated coins…

  87. BitcoinTalk

    Re: Repost: Request: Make this anonymous?

    True, sending by IP through Tor trades one problem for another. The Tor exit node can see the text of your message and potentially MITM you. Best to only send to bitcoin addresses then. Payments by bitcoin address are broadcast over the…

  88. BitcoinTalk

    Re: What's with this odd generation?

    Yes. Almost all transactions are free. A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount. A transaction over the size limit can still be sent if a…

  89. BitcoinTalk

    Re: What's with this odd generation?

    Right. Otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating. In a few decades when the reward gets too small, the transaction fee will become the main…

  90. BitcoinTalk

    Re: Proof-of-work difficulty increasing

    14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 2009 1.00 30/12/2009 1.18 +18% 11/01/2010 1.31 +11% 25/01/2010 1.34 +2% 04/02/2010 1.82 +36% 14/02/2010 2.53 +39% Another big jump in difficulty yesterday from…

  91. BitcoinTalk

    Re: Setting up multiple bitcoin machines behind NAT

    Right now there isn't a port number setting to do that. It's a feature yet to be implemented. You can only set up your NAT to port-forward to one of the computers. (I said something earlier about NAT port translation, but that wouldn't…

  92. BitcoinTalk

    Re: Proof-of-work difficulty increasing

    2 seconds of latency in both directions should reduce your generation success by less than 1%. Probably OK, but I'm not sure. The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes…

  93. BitcoinTalk

    Re: Number of connections

    Nodes stop trying to initiate connections once they have 15. If you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15. I don't know if there's any reason to have 15…

  94. BitcoinTalk

    Post your static IP

    It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works. If you can accept incoming connections and you have a static IP address, post it here! Anything sent to these…

  95. BitcoinTalk

    Command Line and JSON-RPC

    Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC. On Linux it needs libgtk2.0-0 installed, but does not need a GUI running. Hopefully gtk can be installed without having a windowing system…

  96. BitcoinTalk

    Re: Command Line and JSON-RPC

    OK, I made a build target bitcoind that only links wxBase and does not link GTK. Version 0.2.7 on SVN. I split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure UI. ui.h provides inline stubs if wxUSE_GUI=0.…

  97. Private email (Martti Malmi)

    Re: Bitcoind

    Does it still do it if you didn't do getinfo? You could comment out the CreateThreads listed below, then re-enable them one at a time until it does it again. Then we would know which thread the problem is in. net.cpp, under // Start…

  98. Private email (Martti Malmi)

    Re: Bitcoind

    That narrows it down a lot. It didn't print any IRC activity in debug.log, so I guess it couldn't have gotten past the RecvUntil. Eyeballing it I don't see anything obvious. I guess it would have to be either in ConnectSocket or…

  99. Private email (Martti Malmi)

    Re: Bitcoind

    It's in RecvUntil, but I still can't see anything wrong with it. The only thing I can think of is if the socket is receiving a spew of characters. Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. mmalmi@cc.hut.fi wrote:

  100. BitcoinTalk

    Re: On IRC bootstrapping

    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…

  101. BitcoinTalk

    Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?

    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.

  102. BitcoinTalk

    Re: Setting up multiple bitcoin machines behind NAT

    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…

  103. BitcoinTalk

    Re: Ummmm... where did my bitcoins go?

    It's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time. How long is the initial block download typically taking? Does it slow down half way through or is about the same speed…

  104. BitcoinTalk

    Re: Odd amount of generated coins

    In the SVN version, if a transaction requires a transaction fee, it says "This transaction is over the size limit. You can still send it for a fee of #, which goes to the nodes that process your transaction and helps to support the…

  105. BitcoinTalk

    Re: Hostnames instead of IP Addresses

    The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled. The future plan for sending to an IP is to make it a bitcoin…

  106. BitcoinTalk

    Re: Proof-of-work difficulty increasing

    That's a good idea. I'm not sure where exactly to fit that in, but it could certainly calculate the expected average time between blocks generated, and then people would know what to expect. Every node and each processor has a different…

  107. BitcoinTalk

    Re: On IRC bootstrapping

    Bitcoin has its own distributed address directory using the "addr" message. It's about time we coded in a list of the current long running static nodes to seed from. I can add code so new nodes do not preferentially stay connected to the…

  108. BitcoinTalk

    Re: Hostnames instead of IP Addresses

    SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert. Instead…

  109. BitcoinTalk

    Re: Technical clarifications

    3) Nothing, if sending by bitcoin address 5) It is decentralised. After you have connected to the network the first time, you no longer need IRC.

  110. BitcoinTalk

    Re: What is the incentive to collect transactions?

    The premise is false. Adding more transactions to the block you're working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a…

  111. BitcoinTalk

    Re: URI-scheme for bitcoin

    http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345 or http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00 But as long as the link is already doing the typing for you, I don't see much benefit…

  112. BitcoinTalk

    Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG

    The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The…

  113. BitcoinTalk

    Re: On IRC bootstrapping

    The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed…

  114. BitcoinTalk

    Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel

    We need more details about what happened MadHatter. Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected. 0.2 can find other nodes without IRC if it's ever been connected before, but a new…

  115. BitcoinTalk

    Re: On IRC bootstrapping

    This seems like a good idea. What does everyone think, should we make the switch for 0.3?

  116. BitcoinTalk

    Re: 0.3 almost ready

    Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it: (see below for download links)

  117. BitcoinTalk

    Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel

    Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo's option is a much better fit for us. I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start…

  118. BitcoinTalk

    Re: 1.3 almost ready

    Changed the version number to 1.3 and removed "Beta". (links removed, see below) Uses irc.lfnet.org.

  119. BitcoinTalk

    Re: Bitcoin mobile.

    I think that's the best option right now. Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses. They could make a smaller version of the site optimized for mobile. If there was…

  120. BitcoinTalk

    Re: Bitcoin Faucet changes

    Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B. If you can't solve the problem, you can always keep lowering the amount of…

  121. BitcoinTalk

    Re: Feature Request: Limiting Connections

    Thanks for the feedback on this. One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of…

  122. BitcoinTalk

    Re: Beta?

    OK, back to 0.3 then. Please download RC4 and check it over as soon as possible. I'd like to release it soon. http://bitcointalk.org/index.php?topic=199.msg1927#msg1927 Other than the version number change, which included changes in…

  123. BitcoinTalk

    Re: Feature Request: Limiting Connections

    I reduced max outbound connections from 15 to 8 in RC4. 15 was way more than we needed for redundancy. 8 is still plenty of redundancy. As the nodes upgrade to this version, this will cut in half the number of connections that inbound…

  124. Private email (Martti Malmi)

    0.3.0 released

    I uploaded 0.3.0 beta to sourceforge and updated the links on bitcoin.org. I still need to post the announcement message on the forum and mailing list. Here's what I've prepared: Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!…

  125. BitcoinTalk

    Bitcoin 0.3 released!

    Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally…

  126. Private email (Martti Malmi)

    \[bitcoin-list\] Bitcoin 0.3 released!

    Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally…

  127. bitcoin-list (SourceForge)

    [bitcoin-list] Bitcoin 0.3 released!

    Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally…

  128. BitcoinTalk

    Re: On IRC bootstrapping

    Everybody needs to connect to the same IRC server and channel so they can find each other. It might not be good if we suddenly rushed freenode with a ton of users all at once. The fallback is our own seed system. irc.lfnet.org is pretty…

  129. BitcoinTalk

    Re: Anonymity

    It's hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world. Any node with access to both sides would automatically flow the block…

  130. BitcoinTalk

    Re: Security

    I'll start thinking about how to do this. At the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don't let it connect…

  131. BitcoinTalk

    Re: Stuck on 513 blocks

    This is the second time I've seen this "Live Protection" problem reported. It must be blocking the program's network communication. It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any…

  132. BitcoinTalk

    Re: Warning this block was not received by any other nodes

    Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it's connected, but they are silent because the data is being blocked. You need to…

  133. BitcoinTalk

    Re: Scalability

    The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It…

  134. BitcoinTalk

    Re: 0.3.1 release candidate, please test

    Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it…

  135. BitcoinTalk

    Bitcoin 0.3.2 released

    Download links available now on bitcoin.org. Everyone should upgrade to this version. - Added a simple security safeguard that locks-in the block chain up to this point. - Reduced addr messages to save bandwidth now that there are plenty…

  136. BitcoinTalk

    Re: Bitcoin snack machine (fast transaction problem)

    I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less. The network nodes only accept the first version of…

  137. BitcoinTalk

    Re: Bitcoin snack machine (fast transaction problem)

    I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards. No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.…

  138. BitcoinTalk

    JSON-RPC password

    I uploaded to SVN my changes to add a password to JSON-RPC. If you're set up to build, please test it. The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind. bitcoin -rpcpw=<password> -- runs with…

  139. BitcoinTalk

    Re: Scalability and transaction rate

    The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it…

  140. BitcoinTalk

    *** ALERT *** Upgrade to 0.3.6

    Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6! If you can't…

  141. BitcoinTalk

    Re: *** ALERT *** version 0.3.6

    Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime.

  142. BitcoinTalk

    Re: Transaction disappeared in the void...

    If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it. I'll shorten that length of time in a future…

  143. BitcoinTalk

    Re: Protocol Buffers for Bitcoin

    The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do…

  144. BitcoinTalk

    Re: What happens when network is split for prolonged time and reconnected?

    creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it's not hearing the hum of the world…

  145. BitcoinTalk

    Re: Bitcoind x86 binary for CentOS

    I'd rather you didn't make a build of the 1000 node connecting version available. It won't take very many people running that before we have to make another release just to limit the incoming connections.

  146. BitcoinTalk

    Re: Flood attack 0.00000001 BC

    Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it…

  147. BitcoinTalk

    Re: Flood attack 0.00000001 BC

    If you're only going to have one person work on building the block, that could take days. Oh, do you mean send a different variation to each node with the tx fee written to them? The way it is now, it's whoever builds this gets it. If we…

  148. BitcoinTalk

    Re: latency and locality

    Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?

  149. BitcoinTalk

    Re: Bitcoin minting is thermodynamically perverse

    It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.…

  150. BitcoinTalk

    Connection limits

    SVN rev 125: - Always make 8 outbound connections even if have 8 inbound - Limit outbound connections to one per a.b.?.? range - Switch -maxconnections=# I added the (currently undocumented) switch -maxconnections=#. You shouldn't use it…

  151. BitcoinTalk

    Re: Not a suggestion

    This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible. Originally, a coin can be just a chain of signatures. With a timestamp service, the old ones…

  152. BitcoinTalk

    Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.

    It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old…

  153. BitcoinTalk

    Re: Not a suggestion

    Are you back to talking about the existing Bitcoin system here? I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch…

  154. BitcoinTalk

    Re: Bitcoin Watchdog Service

    Which doesn't matter because you can't access sourceforge to download the software either. If you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is…

  155. BitcoinTalk

    Re: Not a suggestion

    I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage? If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and…

  156. BitcoinTalk

    Re: overflow bug SERIOUS

    Starting at 67000 is perfect. Yeah, at the moment you'll stop at 74638. It should start slowly creeping up as more nodes upgrade and generate. Linux build links below. The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes…

  157. BitcoinTalk

    Re: 0.3.10.1 Question on where block should be

    I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up…

  158. BitcoinTalk

    Re: 0.3.10.1 Question on where block should be

    For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.

  159. BitcoinTalk

    Re: overflow bug SERIOUS

    If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes. For today, try adding these parameters: -addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14 See http://bitcointalk.org/index.php?topic=828

  160. BitcoinTalk

    Re: overflow bug SERIOUS

    1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations. 2) If you didn't remove your blk*.dat files, you're not…

  161. BitcoinTalk

    Re: overflow bug SERIOUS

    The bad chain is also slowed down as more nodes upgrade. We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would…

  162. BitcoinTalk

    Re: overflow bug SERIOUS

    It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now. That means it's no longer necessary to delete blk*.dat before upgrading. You can…

  163. BitcoinTalk

    Re: [PATCH] Automatic block validation

    That's a difficult approach. We need to cause a reorg, which will disconnect the invalid chain. This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best. Here's what I was thinking of.…

  164. BitcoinTalk

    blocks minus 1

    I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1: "0 connections 0 blocks 0 transactions" It's always been "nBestHeight + 1" because it's…

  165. BitcoinTalk

    Re: [PATCH] Automatic block validation

    This is what I ended up doing in SVN rev 139. Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.

  166. BitcoinTalk

    Re: overflow bug SERIOUS

    Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is…

  167. BitcoinTalk

    Re: Difficulty: More nodes active, or faster nodes?

    The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all…

  168. BitcoinTalk

    Re: Hypothetical question on lost coins / transfers

    That's right. You don't need to be re-broadcasting your transactions for it to work. When any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain. The entire network…

  169. BitcoinTalk

    Development of alert system

    I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have. Nodes can do two things in response to an…

  170. BitcoinTalk

    Re: integrating digital payments into p2p protocols

    Hey Zooko! I wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the Cryptography mailing list.

  171. BitcoinTalk

    Re: Development of alert system

    It can't do arbitrary actions remotely. Maybe some of you are responding to other posters who suggested the alert system should do more? If there is an alert, the following json-rpc methods return an error: sendtoaddress getbalance…

  172. BitcoinTalk

    Re: Development of alert system

    WRT the alert system, who cares? The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade. All nodes keep running and generating, the network stays up. If…

  173. BitcoinTalk

    Re: RFC: remove DB_PRIVATE flag

    Can you provide more details about what removing DB_PRIVATE does? I can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code. Does removing DB_PRIVATE make it safe for other processes…

  174. BitcoinTalk

    Version 0.3.11 with upgrade alerts

    Version 0.3.11 is now available. Changes: - Some blk*.dat checking on load - Built the -4way code with -march=amdfam10, which makes it a little faster - Warning if your clock is too far off - Warnings/errors/alerts can also be seen in the…

  175. BitcoinTalk

    Re: Warning : Check your system ( Help me )

    Any suggestions for better text to put for this error message so the next person will be less likely to be confused? It's trying to tell them their clock is wrong and they need to correct it. It's relying on 3 time sources: 1) the system…

  176. BitcoinTalk

    Re: Always pay transaction fee?

    Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee. The…

  177. BitcoinTalk

    Version 0.3.12

    Version 0.3.12 is now available. Features: - json-rpc errors return a more standard error object. (thanks to Gavin Andresen) - json-rpc command line returns exit codes. - json-rpc "backupwallet" command. - Recovers and continues if an…

  178. BitcoinTalk

    Re: Version 0.3.12

    Bitcoin clients currently only create and recognize transactions that match two possible templates. Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will…

  179. BitcoinTalk

    Re: Memory leak

    Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch? Did you compile it or is this a release build, and what version? I'm not sure how the 200Kb/sec, since it waits at least a…

  180. BitcoinTalk

    Re: The case for removing IP transactions

    Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default. In storefront cases, you would typically only want customers to…

  181. BitcoinTalk

    Re: Warning : Check your system ( Help me )

    I don't understand, are you under the impression that the program sets the system clock? It doesn't. We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an…

  182. BitcoinTalk

    0.3.13 RC1 for Windows, please test

    0.3.13 release candidate, to be released soon so please test: http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe - don't count or spend payments until they have 1 confirmation http://bitcointalk.org/index.php?topic=1306.0…

  183. BitcoinTalk

    Re: BitCoin Wikipedia page DELETED!!!

    If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is. I wish rather than deleting the article, they put a length restriction. If something is not famous…

  184. BitcoinTalk

    Version 0.3.13, please upgrade

    Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you…

  185. BitcoinTalk

    Re: Version 0.3.13, please upgrade

    Code: diff -u old\main.cpp new\main.cpp --- old\main.cpp Sun Oct 03 20:57:20 2010 +++ new\main.cpp Sun Oct 03 20:57:54 2010 @@ -2831,6 +2831,10 @@ bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) || (fAMD && nFamily * 10000…

  186. BitcoinTalk

    Re: Version 0.3.13, please upgrade

    Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain. Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the…

  187. BitcoinTalk

    Re: Memory leak

    You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet. IRC seems to be working. It ought to have other nodes to try. There may be something I need to do to make…

  188. BitcoinTalk

    Re: Version 0.3.13, please upgrade

    Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.

  189. BitcoinTalk

    Re: Tor connections not working reliably, many seednodes offline

    Maybe you were just unlucky to have an exit node without reverse lookup. The IRC server's response doesn't look like it was disconnecting you for that. It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.…

  190. BitcoinTalk

    Version 0.3.14

    Version 0.3.14 is now available http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/ Changes: - Key pool feature for safer wallet backup Gavin Andresen: - TEST network mode with switch -testnet - Option to use SSL for…

  191. BitcoinTalk

    New getwork

    I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601) m0mchil's external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn't want to add additional…

  192. BitcoinTalk

    Re: RFC: ship block chain 1-74000 with release tarballs?

    I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes. If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very…

  193. BitcoinTalk

    Re: RFC: ship block chain 1-74000 with release tarballs?

    Despite everything else said, the current next step is: In particular, I suspect that more read caching might help a lot. Then something more specific was wrong. That's not due to normal initial download time. Without more details, it…

  194. BitcoinTalk

    Re: Version 0.3.18

    I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added. That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes. I also support a third transaction type for…

  195. BitcoinTalk

    Re: Fees in BitDNS confusion

    Not locktime. There's a possible design for far in the future: You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend…

  196. Private email (Martti Malmi)

    Re: Writing about BitCoin

    Gavin Andresen wrote: Great True You're the best person to do it. EFF is really important. We want to have a good relationship with them. We're the type of project they like; they've helped the TOR project and done a lot to protect P2P…

  197. Private email (Mike Hearn)

    More BitCoin questions

    I reached the same conclusions about client only nodes and this is what I've been implementing. I'm nearly there ..... I have block chain download, parsing and verification of the blocks/transactions done, with creation of spend…

  198. Private email (Mike Hearn)

    More BitCoin questions

    By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum: http://www.bitcoin.org/smf/ind ex.php?topic=2699.0 Hal (i presume this is Hal Finney) Yes, it's him. He was supportive on the…

  199. Private email (Mike Hearn)

    Open sourced my Java SPV impl

    I hope you are doing well. I finally got all the lawyers happy enough to release BitCoinJ under the Google name using the Apache 2 license: It's incomplete - notably it doesn't properly handle block chain splits yet - but the rest is…

  200. Private email (Mike Hearn)

    Open sourced my Java SPV impl

    See these threads: http://www.bitcoin.org/smf/ind ex.php?topic=1786.msg22119#msg 22119 http://www.bitcoin.org/smf/ind ex.php?topic=2181.msg28729#msg 28729 I see. So right now fees are tricky because you have to decide up front what the…

  201. Private email (Mike Hearn)

    Holding coins in an unspendable state for a rolling time window

    If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and…

  202. P2P Foundation forum

    Bitcoin open source implementation of P2P currency

    Authenticity disputed

    I am not Dorian Nakamoto.

All topics · Search the archive

0:000:00