[
{
"id": 1,
"satoshi_id": 1,
"thread_id": 1,
"source_id": "1",
"poster_name": "Satoshi Nakamoto",
"poster_url": "http://p2pfoundation.ning.com/profile/SatoshiNakamoto",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
"date": "2009-02-11T22:27:00Z",
"text": "\nI'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 the screenshots and design paper:
\n
\nDownload Bitcoin v0.1 at
http://www.bitcoin.org\n
\nThe root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.
\n
\nA generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.
\n
\nIt's time we had the same thing for money. With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.
\n
\nOne of the fundamental building blocks for such a system is digital signatures. A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership. It works well to secure ownership, but leaves one big problem unsolved: double-spending. Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.
\n
\nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle. For details on how it works, see the design paper at
http://www.bitcoin.org/bitcoin.pdf\n
\nThe result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.
\n
\nSatoshi Nakamoto
\n
http://www.bitcoin.org Great stuff.
\n
\nThis is the first real innovation in money since the Bank of England started to issue its promissory notes for gold in the vaults, which then became known as banknotes.
\n
\nI believe an open source currency has great potential. A bit like Google becoming the default search engine for many of us.
",
"nested_level": 0
},
{
"id": 3,
"thread_id": 1,
"source_id": "3",
"poster_name": "Sepp Hasslberger",
"poster_url": "http://p2pfoundation.ning.com/profile/Sepp",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9478",
"date": "2009-02-14T15:30:00Z",
"text": "Dante, in an email, has mentioned a UK project called Open Coin. It seems to go in a similar direction.
\n
\nCould there be synergies with bitcoin?
\n
\n
http://opencoin.org/ ",
"nested_level": 0
},
{
"id": 4,
"satoshi_id": 2,
"thread_id": 1,
"source_id": "4",
"poster_name": "Satoshi Nakamoto",
"poster_url": "http://p2pfoundation.ning.com/profile/SatoshiNakamoto",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9493",
"date": "2009-02-15T16:42:00Z",
"text": "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.
\n
\nA lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.
",
"nested_level": 1
},
{
"id": 5,
"thread_id": 1,
"source_id": "5",
"poster_name": "Joerg Baach",
"poster_url": "http://p2pfoundation.ning.com/profile/JoergBaach",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9543",
"date": "2009-02-17T10:42:00Z",
"text": "Hi Satoshi,
\n
\nwe are actually really talking about the old Chaumian central stuff. That was because a) it was there b) it was patent free (we have to think a bit about the US). I had a read of your paper on the weekend - thanks a lot for doing that work. Interesting read.
\n
\nWhat I did not understand about your system - how would you use it for a currency of any sort? Everybody can create a coin as they like, as far as I understood, so therefore there is no trusted supply of tokens / coins.
\nOr the other way around: if you don't trust the double spending database, because its a central instance, you surely couldn't trust a central issuer to issue and redeem. How would a currency work otherwise? Would you use it for a mutual credit system in which the transactions are shown online?
\n
\nCheers,
\n
\nJoerg
",
"nested_level": 2
},
{
"id": 6,
"thread_id": 1,
"source_id": "6",
"poster_name": "Sepp Hasslberger",
"poster_url": "http://p2pfoundation.ning.com/profile/Sepp",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9559",
"date": "2009-02-18T14:41:00Z",
"text": "I have two questions, Satoshi.
\n
\nthe first one ties in with Joerg's doubts about the trusted supply of tokens/coins.
\n
\nAs far as I understand, there will be a limit of the total amount of tokens that can be created, and a changing gradient of difficulty in making the tokens, where the elaboration gets more and more difficult with time. Is that correct?
\n
\nIt is important that there be a limit in the amount of tokens/coins. But it is also important that this limit be adjustable to take account of how many people adopt the system. If the number of users changes with time, it will also be necessary to change the total amount of coins.
\n
\nIs there a formula to decide on what should be the total amount of tokens, and if so, what is the formula?
\n
\nIf there is no formula, who gets to make that decision and based on what criteria will it be made?
\n
\nI will keep my second question for later. One thing at a time...
",
"nested_level": 2
},
{
"id": 7,
"satoshi_id": 3,
"thread_id": 1,
"source_id": "7",
"poster_name": "Satoshi Nakamoto",
"poster_url": "http://p2pfoundation.ning.com/profile/SatoshiNakamoto",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9562",
"date": "2009-02-18T20:50:00Z",
"text": "It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow:
\n
\n- Whenever someone finds proof-of-work to generate a block, they get some new coins
\n- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)
\n- The coins given per block is cut in half every 4 years
\n
\nYou could say coins are issued by the majority. They are issued in a limited, predetermined amount.
\n
\nAs an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything.
\n
\nTo Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things. If there was some clever way, or if we wanted to trust someone to actively manage the money supply to peg it to something, the rules could have been programmed for that.
\n
\nIn this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up, which could attract more users to take advantage of the increasing value.
",
"nested_level": 2
},
{
"id": 8,
"thread_id": 1,
"source_id": "8",
"poster_name": "Sepp Hasslberger",
"poster_url": "http://p2pfoundation.ning.com/profile/Sepp",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9578",
"date": "2009-02-20T08:53:00Z",
"text": "So in other words, \"the early adopter finds the worm\" in this system.
\n
\nThis would mean that - the earlier someone gets in on the bitcoin system establishing a node, the more chance they have of becoming lucky and being able to generate coins. Nothing against that, it would work to promote adoption of the system.
\n
\nHowever there should also be a method of adjusting the total number of coins extant. I would propose to link the total number of coins to the number of active nods.
\n
\nThis way, you have two parameters that keep a balance. One is the halving of coins given per block, the other is a continual (or periodic?) adjustment of the target total of coins to the number of active users. That should self-balance the system.
\n
\nThe reason balance of the system is important: if it's going to be used for payments, you don't want to have large changes in the value of the coins. It would lead to distortions, I believe, by continually increasing the \"purchasing power\" of a single coin.
\n
\nStability of the coins' value is desirable for long term use.
",
"nested_level": 3
},
{
"id": 9,
"thread_id": 1,
"source_id": "9",
"poster_name": "Russ Nelson",
"poster_url": "http://p2pfoundation.ning.com/profile/RussNelson",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17271",
"date": "2010-03-15T17:27:00Z",
"text": "The London Mint was unable to make enough small coins in Isaac Newton's day. Private minters stepped in. If bitcoin can't make enough coins and small enough coins so that people can trade at the value they want, then it will be replaced by something that can.
",
"nested_level": 3
},
{
"id": 10,
"thread_id": 1,
"source_id": "10",
"poster_name": "Jost Reinert",
"poster_url": "http://p2pfoundation.ning.com/profile/JostReinert",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:18222",
"date": "2011-01-07T10:23:00Z",
"text": "Quite interesting project. I am curator of a micro-currency in Germany called Rheingold.
\n
It is based on cash. Therefore the problem of \"trust\" is not solved. However, we do not have a central bank giving money as credit, but here, every single issuer of his own money gets it printed himself. So Rheingold is rather a group of many de-central-banks. Therefore the seignorage everybody gains himself.
\n
And our money is debt-free.
\n
\n
I would like to promote your project on our blog http://rheingoldblog.wordpress.com. Maybe you could even become Rheingolder yourself with your own cashbill. Since we pretend to be an art-project, the whole project will be shown in a museum in future. We already have more than 1.000 members, mostly in Germany. Our website http://www.rheingoldregio.de
\n
Any idea about a cooperation?
\n
As far as I can understand it we are dealing here with another glorified form of LETS, or CCs in electronic form ofcourse. The question is this. How will this help to change the big issues of our world such as global warming, food security, population, et al? This is what really matters at the end of the day. Moreover, whether we like it, or not ,we still have to deal with the \"big boys\" (ie. governments, corporations, banks,et al) at some point.
\n
\nOfcourse, if most people were to accept a new decentralised \"made up\" currency (sans banks,and bankers)then we would
\nhave something serious to discuss about!!! As far as I am concerned energies would be better spent in improving my project known as Transfinancial Economics.
",
"nested_level": 0
},
{
"id": 12,
"thread_id": 1,
"source_id": "12",
"poster_name": "Russ Nelson",
"poster_url": "http://p2pfoundation.ning.com/profile/RussNelson",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17280",
"date": "2010-03-22T21:08:00Z",
"text": "No, nothing like LETS at all. LETS is book entry for one, and for another the total amount of currency is always zero. When you issue a credit to someone else because they've done something for you, you receive a debit. The trouble with a LETS is that you can walk away from an account which is in debit. That functions to inflate the currency -- more people have credits who want something than there are people to do or sel something for the credits.
\n
\nLETS was invented by somebody who doesn't understand money, and promulgated by more people who don't understand money.
",
"nested_level": 1
},
{
"id": 13,
"thread_id": 1,
"source_id": "13",
"poster_name": "Michel Bauwens",
"poster_url": "http://p2pfoundation.ning.com/profile/MichelBauwens",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17285",
"date": "2010-03-24T07:14:00Z",
"text": "Dear Satoshi,
\n
\nCould you propose a text for our regular p2p blog, with eventual responses to the main questions here? Our regular blog has a lot more readers (about 10x) than our Ning community blog,
\n
\nMichel
",
"nested_level": 0
},
{
"id": 14,
"satoshi_id": 4,
"thread_id": 1,
"source_id": "14",
"poster_name": "Satoshi Nakamoto",
"poster_url": "http://p2pfoundation.ning.com/profile/SatoshiNakamoto",
"subject": "Bitcoin open source implementation of P2P currency",
"url": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:52186",
"date": "2014-03-07T01:17:00Z",
"text": "I am not Dorian Nakamoto.
",
"disclaimer": "Because this post was made years after Satoshi’s acknowledged disappearance, its authenticity demands scrutiny. In one instance, Satoshi’s P2P Foundation account was compromised due to an email hack in September 2014, although there is currently no clear indication that the account was compromised at the prior time of this post. Read more about the hack here.",
"nested_level": 0
},
{
"id": 15,
"satoshi_id": 5,
"thread_id": 2,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Welcome to the new Bitcoin forum!",
"url": "https://bitcointalk.org/index.php?topic=5.msg28#msg28",
"date": "2009-11-22T18:04:28Z",
"text": "Welcome to the new Bitcoin forum!
The old forum can still be reached here:
http://bitcoin.sourceforge.net/boards/index.phpI'll repost some selected threads here and add updated answers to questions where I can.
FAQ
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQDownload
http://sourceforge.net/projects/bitcoin/files/--------------------
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 when you first click Generate Coins.
2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.
Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?
--------------------
sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)
As far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating the next proof-of-work. The CPU usage is 100% when you're generating coins.
In this example, the network connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.
",
"nested_level": 0
},
{
"id": 17,
"satoshi_id": 8,
"thread_id": 3,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Repost: Bitcoin Maturation",
"url": "https://bitcointalk.org/index.php?topic=6.msg31#msg31",
"date": "2009-11-22T18:34:21Z",
"text": "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 proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.
2) When you successfully generate a block, it is immediately broadcast to the network. Other nodes must receive it and link to it for it to be accepted as the new latest block.
Think of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.
After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent. Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours. You don't have to be online during that time.
",
"nested_level": 0
},
{
"id": 18,
"satoshi_id": 7,
"thread_id": 4,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Repost: Request: Make this anonymous?",
"url": "https://bitcointalk.org/index.php?topic=7.msg30#msg30",
"date": "2009-11-22T18:32:00Z",
"text": "--------------------
anonguy54:
Request: Make this anonymous?
Posted:Thu 15 of Oct, 2009 (19:58 UTC)
Are there any plans to make this service anonymous?
e.g; Being able to route BitCoin through Tor.
",
"nested_level": 0
},
{
"id": 19,
"satoshi_id": 9,
"thread_id": 4,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Repost: Request: Make this anonymous?",
"url": "https://bitcointalk.org/index.php?topic=7.msg32#msg32",
"date": "2009-11-22T18:35:15Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 20,
"thread_id": 4,
"source_id": "3",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Repost: Request: Make this anonymous?",
"url": "https://bitcointalk.org/index.php?topic=7.msg262#msg262",
"date": "2010-02-06T18:50:09Z",
"text": "--------------------
anonguy54:
Request: Make this anonymous?
Posted:Thu 15 of Oct, 2009 (19:58 UTC)
Are there any plans to make this service anonymous?
e.g; Being able to route BitCoin through Tor.
Someone correct me people, but I thought it IS already anonymous! Can the person I'm transferring money to know my IP or something?
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 another node that you're relaying in a broadcast. With a very small network though, someone might still figure it out by process of elimination. It'll be better when the network is larger.
If you send by IP, the recipient sees you because you connect to their IP. You could use TOR to mask that.
You could use TOR if you don't want anyone to know you're even using Bitcoin.
Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution.
",
"nested_level": 0
},
{
"id": 22,
"thread_id": 4,
"source_id": "5",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: Repost: Request: Make this anonymous?",
"url": "https://bitcointalk.org/index.php?topic=7.msg277#msg277",
"date": "2010-02-07T19:19:50Z",
"text": "You could use TOR if you don't want anyone to know you're even using Bitcoin.
Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution.
Tor is a extra layer of privacy and anonimity, but it isn't the ultimate answer. Check out
http://www.torproject.org/download.html.en#Warning, to understand what Tor does and doesn't do for you.
Tor can be dangerous, like exit nodes that log information like passwords and the like.
So a major question about the security of Bitcoin when using it with Tor (or any other proxy service) arises:
- So what exactly does Bitcoin send when it connects to an IP?
- Is everything encrypted that we send over the line?
- Can someone 'steal' bitcoins by listening at the end of a proxy (or in Tor's case an \"exit node\")?
Speaking of security, we might just want to add a simple version checking procedure in bitcoin that will alert a user if s/he is running an \"insecure version of bitcoin\".
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 network as part of the normal network traffic. All communications with the network are broadcasts of public information.
",
"nested_level": 0
},
{
"id": 25,
"satoshi_id": 10,
"thread_id": 5,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Repost: How anonymous are bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=8.msg33#msg33",
"date": "2009-11-25T18:15:57Z",
"text": "--------------------
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 from? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?
",
"nested_level": 0
},
{
"id": 26,
"satoshi_id": 11,
"thread_id": 5,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Repost: How anonymous are bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=8.msg34#msg34",
"date": "2009-11-25T18:17:23Z",
"text": "> 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 are essentially random numbers with no identifying information.
When you send to an IP address, the transaction is still written to a bitcoin address. The IP address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.
Blocks contain a history of the bitcoin addresses that a coin has been transferred to. If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.
The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.
For greater privacy, it's best to use bitcoin addresses only once. You can change addresses as often as you want using Options->Change Your Address. Transfers by IP address automatically use a new bitcoin address each time.
> Can nodes tell which bitcoin addresses belong to which IP addresses?
No.
> Is there a command line option to enable the sock proxy the first
> time that bitcoin starts?
In the next release (version 0.2), the command line to run it through a proxy from the first time is:
bitcoin -proxy=127.0.0.1:9050
The problem for TOR is that the IRC server which Bitcoin uses to initially discover other nodes bans the TOR exit nodes, as all IRC servers do. If you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such:
bitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress>
If someone running a node with a static IP address that can accept incoming connections could post their IP to use for -addnode, that would be great.
> What happens if you send bitcoins to an IP address that has multiple
> clients connected through network address translation (NAT)?
Whichever one you've set your NAT to forward port 8333 to will receive it. If your router can change the port number when it forwards, you could allow more than one client to receive. For instance, if port 8334 forwards to a computer's port 8333, then senders could send to \"x.x.x.x:8334\"
If your NAT can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but I'll look into it.
",
"nested_level": 0
},
{
"id": 27,
"satoshi_id": 12,
"thread_id": 6,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Repost: Linux/UNIX compile",
"url": "https://bitcointalk.org/index.php?topic=9.msg36#msg36",
"date": "2009-11-27T17:17:22Z",
"text": "--------------------
scott:
Linux/UNIX compile
Posted:Thu 08 of Oct, 2009 (05:49 UTC)
Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great.
",
"nested_level": 0
},
{
"id": 28,
"satoshi_id": 13,
"thread_id": 6,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Repost: Linux/UNIX compile",
"url": "https://bitcointalk.org/index.php?topic=9.msg37#msg37",
"date": "2009-11-27T17:27:09Z",
"text": "The Linux version is on its way. Martti's Linux port was merged into the main code branch and New Liberty Standard has been testing it. It'll be in the next release, version 0.2.
Command line is on the to-do list after 0.2.
",
"nested_level": 0
},
{
"id": 29,
"satoshi_id": 14,
"thread_id": 7,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "[OLD THREAD] Bitcoin version 0.2 development status",
"url": "https://bitcointalk.org/index.php?topic=10.msg38#msg38",
"date": "2009-11-27T22:48:39Z",
"text": "We've been working hard on improvements for the next version release. Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout
- Setup EXE for Windows, in addition to the archive download
I've been working on a number of refinements to the networking code and laying the groundwork for future functionality. Also coming in version 0.2:
- Multi-processor support for coin generation
- Proxy support
",
"nested_level": 0
},
{
"id": 30,
"thread_id": 8,
"source_id": "1",
"poster_name": "madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=11",
"subject": "A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg40#msg40",
"date": "2009-12-09T05:34:46Z",
"text": "Hey,
First off I must say that this is an amazing concept. I have been dreaming of a P2P money system for a LONG time.
You have my complete kudos and respect.
I have a few suggestions:
- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.
- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.
- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).
- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.
- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).
![\"Smiley\"](\"/static/img/emoticons/smiley.gif\"/)
Helpful suggestions, thanks.
- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
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 identify itself.
- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.
I have thought about eventually SSLing all the connections. I assume anything short of SSL would be pointless against DPI. Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2.
- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.
That's one of the main things on the agenda after 0.2.
- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).
Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.
- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.
I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?
- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).
I'm still thinking about how best to structure the management interface. Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. That would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?
Thank you for this effort. A P2P payment system has been needed for a long time.
Shane
",
"nested_level": 0
},
{
"id": 33,
"thread_id": 8,
"source_id": "4",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg44#msg44",
"date": "2009-12-10T14:00:17Z",
"text": "Most modern P2P software tries UPnP by default. You can (of course) disable it (usually) in the options.
Hmm. I had thought about that as well. Your first idea is probably best. That way you can run the server daemon \"headless\" and have your choice of a front end. (One of the front ends could be a PHP [or C++ CGI] program that runs on your favorite webserver).
This would also enable you to run the front end and back end on different machines. (Ex. headless on a linux server that has a static IP to make receiving payments easier [pay by ip mode] and a front end client for management that can be ran on windows/mac/or something else). Front ends can also be ran on clients with very low cpu power such as mobile phones. *nudge nudge*
![\"Wink\"](\"/static/img/emoticons/wink.gif\"/)
One other thing I have thought of is the seeding. The app could be pre-seeded before downloading. You could prepare a new archive daily that is pre-seeded. That would do away with the IRC connection. (Or it could be used as a fallback, I suppose. I still haven't audited the IRC connection code. I am thinking of a few exploits but I don't want to mention them until I am sure they exist.) Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.
![\"Tongue\"](\"/static/img/emoticons/tongue.gif\"/)
Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).
Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out. I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.
Cheers!
I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?
I'm still thinking about how best to structure the management interface. Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. That would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?
Front ends can also be ran on clients with very low cpu power such as mobile phones.
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 easier for new users to get started if they only need to create an account on a website, not install software.
The app could be pre-seeded before downloading. Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.
Yeah, we can phase out IRC when there are enough static nodes to preprogram a seed list. Once you get seeded, you don't need IRC.
Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).
There were some issues in 0.1.5 where the initial block download could get bogged down. 0.2 has code to make sure it goes smoothly. It ought to take less than an hour, I think. I need to hurry up and get 0.2 out the door.
The blocks increase linearly, it'll be decades before it's millions. In theory, the block download time should top out 8 months from now when Moore's Law will be growing faster than the block chain.
Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.
It's SVN on sourceforge. PM or e-mail me your sourceforge account and I'll give you access.
I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.
That's great because that's where I have less expertise. For instance, I haven't researched the best way to do the \"Start Bitcoin on system startup\" feature on Linux. On Windows, the option adds/removes an icon in the Startup folder.
Okay, let me get registered on SF and get you my username. I haven't used SF in years so I'll have to familiarize myself. Will this give me access to the current branch you fellows are currently working on? (0.2)
I have been trying to think of the options that will be needed for the backend process. I wonder which would be better: a long set of command line switches or a configuration file. Hmm...
I have a lot of servers spread across the globe. If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.
I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).
I think that a simple network monitor plugin for Nagios would be helpful as well. Something that can emulate a connecting client, and retrieve a valid status code from the backend process. I have a lot of ideas.
In any event, I would like to help. I have a lot of time and a project like this one is very exciting.
Thanks for letting me be a part of it.
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.
If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.
That would be a big help. TOR users wouldn't have to worry about how to get seeded, and we wouldn't depend on IRC.
It can be run in a few simple modes without access to the UI if you don't mind a minimized window on the desktop. (0.1.5 doesn't have -min so it would be an open window)
To only run a seed:
bitcoin -min -gen=0
You could sort of monitor it by looking at debug.log. To stop it, kill the process, the database won't mind.
To generate:
bitcoin -min -gen
To get the generated bitcoins, you'd have to copy wallet.dat (with version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin and transfer the coins to your main account. (With version 0.1.5 you'd have to copy the whole \"%appdata%/Bitcoin\" directory.) There is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory.
I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).
I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels everyone through a few proxy servers. I just committed a fix to SVN for this. If it gets \"433\" name already in use (it was error 433, right?), it'll retry with a non-address random username.
In any event, I would like to help. I have a lot of time and a project like this one is very exciting.
That's great, any help is really appreciated!
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST!
I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
I already run a great deal of TOR and I2P nodes so for me to add this app to those same servers is a snap.
I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.
I'll keep toying around with the source code and see what I can come up with.
Suggestion :
Since the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.
So, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA.
",
"nested_level": 0
},
{
"id": 39,
"satoshi_id": 20,
"thread_id": 8,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg54#msg54",
"date": "2009-12-12T17:52:44Z",
"text": "The average total coins generated across the network per day stays the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they wouldn't get more coins than before.
We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.
",
"nested_level": 0
},
{
"id": 40,
"satoshi_id": 21,
"thread_id": 8,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg55#msg55",
"date": "2009-12-12T18:17:10Z",
"text": "I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST!
I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
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 potentially byte-swapping node out there. PPC is on its way out anyway.
Considered autoconf. Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it. I'd rather keep the makefile simple as long as possible.
I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.
My head hurts just thinking about that. Funnelling all the UI backend through a TCP connection would make everything twice as hard. There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.
I'd rather have command line control, that would get us remote admin and batch automation.
given any thought to using autoconf?
I'd choose cmake instead of autoconf if we want build automation at some point.
Suggestion:
Add IPv6-Support for payments.
",
"nested_level": 0
},
{
"id": 43,
"thread_id": 8,
"source_id": "14",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg59#msg59",
"date": "2009-12-13T06:44:04Z",
"text": "Okay, Mac PPC is EOL now anyway. Console mode would be awesome.
",
"nested_level": 0
},
{
"id": 44,
"thread_id": 8,
"source_id": "15",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg60#msg60",
"date": "2009-12-13T06:46:30Z",
"text": "Um, so command line only mode could be selected at compile-time? Perhaps with a define? And that would shut off the graphical UI stuff?
Just want to be on the same page here.
One quick question about \"natural deflation\" (as I call it). I have noticed that it is possible to spend to old addresses that no longer work. In essence the coins can not be claimed. Wouldn't there be a natural deflation effect because of this? I mean if the coins max out at 21,000,000 wouldn't the number of coins slowly work backwards due to payment errors?
",
"nested_level": 0
},
{
"id": 46,
"satoshi_id": 22,
"thread_id": 8,
"source_id": "17",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg62#msg62",
"date": "2009-12-13T16:51:25Z",
"text": "There would be a command line switch at runtime to tell it to run without UI. All it needs to do is not create the main window. A simplistic way would be to disable \"pframeMain->Show\" and \"ptaskbaricon->Show\" in ui.cpp. The network threads don't care that the UI isn't there. The only other UI is a message box in CheckDiskSpace if it runs out of disk space.
Then a separate command line utility to communicate with it to do things. Not sure what it should be named.
\"natural deflation\"... I like that name for it. Yes, there will be natural deflation due to payment mistakes and lost data. Coin creation will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation.
",
"nested_level": 0
},
{
"id": 47,
"thread_id": 8,
"source_id": "18",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg63#msg63",
"date": "2009-12-14T09:29:44Z",
"text": "Okay, thanks for the tips. I am going to try running bitcoin 0.2/svn on FreeBSD tonight in console-only mode. I'll create some notes / patches / etc.
",
"nested_level": 0
},
{
"id": 48,
"thread_id": 8,
"source_id": "19",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg64#msg64",
"date": "2009-12-14T13:09:48Z",
"text": "Got it working on FreeBSD! I'll submit my work here soon.
$gmake -f makefile.fbsd
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o headers.h.gch headers.h
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/util.o util.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/script.o script.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/db.o db.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/net.o net.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/main.o main.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/market.o market.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/ui.o ui.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/uibase.o uibase.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -O3 -o obj/sha.o sha.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/irc.o irc.cpp
g++ -O0 -Wno-invalid-offsetof -Wformat -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o bitcoin -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/usr/local/lib/db47\" obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o obj/ui.o obj/uibase.o obj/sha.o obj/irc.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l wx_base-2.8 -l wx_gtk2_core-2.8 -l wx_gtk2_html-2.8 -l wx_gtk2_richtext-2.8 -l crypto -l gtk-x11-2.0 -l gthread-2.0 -l SM
$ file ./bitcoin
./bitcoin: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, not stripped
",
"nested_level": 0
},
{
"id": 49,
"thread_id": 8,
"source_id": "20",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg66#msg66",
"date": "2009-12-14T15:01:39Z",
"text": "Can anyone shed some light here?
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I\"/usr/include\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/include\" -I\"/usr/local/boost_1_41_0\" -I\"/sw/include/db4\" -I\"/usr/local/ssl/include\" -I\"/usr/local/lib/wx/include/mac-ansi-release-2.8\" -o headers.h.gch headers.h
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:421: error: no matching function for call to 'CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*&, <anonymous enum>, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
uibase.h:673: note: candidates are: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int)
uibase.h:651: note: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(const CGetTextFromUserDialogBase&)
ui.h:423: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)
ui.h:424: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
ui.h:428: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
make: *** [headers.h.gch] Error 1
Can anyone shed some light here?
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I\"/usr/include\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/include\" -I\"/usr/local/boost_1_41_0\" -I\"/sw/include/db4\" -I\"/usr/local/ssl/include\" -I\"/usr/local/lib/wx/include/mac-ansi-release-2.8\" -o headers.h.gch headers.h
...
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
It looks like the implicit conversion from std::string to wxString isn't working. \u00a0That's used everywhere, the conversion needs to work.
wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. \u00a0You can get that problem on Windows if the \"unicode\" (meaning wchar) build is used, so that wxString is wchar and std::string is char.
It's probably some wxWidgets compile defines or build configuration. \u00a0What \"configure\" options did you use?
I'm not sure __WXMAC__ is the right define. \u00a0It may be the Mac Classic support that's complicating wxString, and we only want OSX. \u00a0Try __WXOSX__ (or see below)
http://docs.wxwidgets.org/stable/wx_cppconst.html\"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:
\u00a0\u00a0 \u00a0* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.
\u00a0\u00a0 \u00a0* If you want to test for any GUI Mac port under OS X, use __WXOSX__.
\u00a0\u00a0 \u00a0* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__\"
Okay, I will look into the std::string issue. It is also throwing the same std::string issue on the latest version of Ubuntu Linux. So this isn't just OSX related. I have to say that my main background is C, not C++ so I am still learning some of the C++ data types/headers/and other specifics \"as I go\".
There are only defines for __WXCOCOA__ and __WXMAC__ in wx/defs.h (I must be missing something here..maybe my wxwidgets needs to be rebuilt -- I'll try that). I have tried combinations of those existing defines without success. The other option is to use gtk on OSX but the windowing will be slower and (my opinion) \"ugly\". Carbon would be the best selection for OSX. \u00a0I'll keep hacking at it until I get it working.
I also now have a working startup script for FreeBSD that will launch xorg's virtual framebuffer onto the localhost, fire up bitcoin and have the X11 screen output get stuffed into memory (instead of the monitor). This is a real big hack, but it does enable someone to run bitcoin as a pseudo unix daemon. I have had the code running for over 12h now and I don't detect any memory leaks or other weirdness.
Also I have a simple network monitor that will detect if bitcoin has crashed/stopped responding on port 8333, send me a page, and start the daemon back up again. This setup is ideal. I have started deploying seeds on servers I control that are all over the world.
One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?
I will include these tools once I get SF setup.
Cheers!
Okay, I am on SF now. Username \"madhatter2\".
It is also throwing the same std::string issue on the latest version of Ubuntu Linux.
Then it must be something you're doing differently with building or configuring wxWidgets.
What options did you use on the wxWidgets \"configure\" script?\u00a0 The options I used are in build-unix.txt.
One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?
Never heard of that happening.\u00a0 Is there anything in debug.log?\u00a0 If you touched the file, that sounds like something is there.\u00a0 Does the program have write access to the file?
I used the default build options. I will try the options from your txt file. On FreeBSD it just worked right from the normal ports system. Which is excellent. It means that installing bitcoin via the same ports system (my goal) will be a snap.
Yes, the debug.log has the proper permissions. I'll re-read the source. There must be something I am missing.
",
"nested_level": 0
},
{
"id": 55,
"thread_id": 8,
"source_id": "26",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg72#msg72",
"date": "2009-12-16T15:49:23Z",
"text": "I worked around the string problem by using wxWidgets 2.9. It worked with the default configuration.
",
"nested_level": 0
},
{
"id": 56,
"thread_id": 8,
"source_id": "27",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "FreeBSD build patch",
"url": "https://bitcointalk.org/index.php?topic=12.msg75#msg75",
"date": "2009-12-17T13:21:49Z",
"text": "[madhatter@10 /home/madhatter/src/bitcoin]# diff -u headers.h.orig headers.h\u00a0 \u00a0 \u00a0
--- headers.h.orig\u00a0 \u00a0 \u00a0 2009-12-14 12:29:39.000000000 +0000
+++ headers.h\u00a0 \u00a02009-12-14 12:41:08.000000000 +0000
@@ -35,7 +35,12 @@
\u00a0#include <limits.h>
\u00a0#include <float.h>
\u00a0#include <assert.h>
+#ifndef BUILD_FREEBSD //malloc.h is part of stdlib.h on FreeBSD
\u00a0#include <malloc.h>
+#endif
+#ifdef BUILD_FREEBSD
+#include <netinet/in.h>
+#endif
\u00a0#include <memory>
\u00a0#define BOUNDSCHECK 1
\u00a0#include <sstream>
[madhatter@10 /home/madhatter/src/bitcoin]# cat makefile.fbsd
# Copyright (c) 2009 Satoshi Nakamoto
# Distributed under the MIT/X11 software license, see the accompanying
# file license.txt or
http://www.opensource.org/licenses/mit-license.php.
ifneq \"$(BUILD)\" \"debug\"
ifneq \"$(BUILD)\" \"release\"
BUILD=debug
endif
endif
ifeq \"$(BUILD)\" \"debug\"
D=d
DEBUGFLAGS=-g
endif
INCLUDEPATHS= \\
\u00a0-I\"/usr/include\" \\
\u00a0-I\"/usr/local/include\" \\
\u00a0-I\"/usr/local/include/db47\" \\
\u00a0-I\"/usr/local/include/wx-2.8\" \\
\u00a0-I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\"
LIBPATHS= \\
\u00a0-L\"/usr/lib\" \\
\u00a0-L\"/usr/local/lib\" \\
\u00a0-L\"/usr/local/lib/db47\"
LIBS= \\
\u00a0-Wl,-Bstatic \\
\u00a0 \u00a0-l boost_system -l boost_filesystem \\
\u00a0 \u00a0-l db_cxx \\
\u00a0-Wl,-Bdynamic \\
\u00a0 \u00a0-l wx_base-2.8 \\
\u00a0 \u00a0-l wx_gtk2_core-2.8 \\
\u00a0 \u00a0-l wx_gtk2_html-2.8 \\
\u00a0 \u00a0-l wx_gtk2_richtext-2.8 \\
\u00a0 \u00a0-l crypto \\
\u00a0 \u00a0-l gtk-x11-2.0 -l gthread-2.0 -l SM
WXDEFS=-D__WXGTK__ -DNOPCH -DBUILD_FREEBSD
CFLAGS=-O0 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(WXDEFS) $(INCLUDEPATHS)
HEADERS=headers.h util.h main.h serialize.h uint256.h key.h bignum.h script.h db.h base58.h
all: bitcoin
headers.h.gch: headers.h $(HEADERS) net.h irc.h market.h uibase.h ui.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/util.o: util.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS)
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/script.o: script.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS)
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/db.o: db.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS) market.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/net.o: net.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS) net.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/main.o: main.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS) net.h market.h sha.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/market.o: market.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS) market.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/ui.o: ui.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS) net.h uibase.h ui.h market.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/uibase.o: uibase.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 uibase.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
obj/sha.o: sha.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 sha.h
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -O3 -o $@ $<
obj/irc.o: irc.cpp\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 $(HEADERS)
\u00a0 \u00a0 \u00a0 \u00a0 g++ -c $(CFLAGS) -o $@ $<
OBJS=obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o \\
\u00a0 \u00a0 \u00a0 \u00a0 obj/ui.o obj/uibase.o obj/sha.o obj/irc.o
bitcoin: headers.h.gch $(OBJS)
\u00a0 \u00a0 \u00a0 \u00a0 g++ $(CFLAGS) -o $@ $(LIBPATHS) $(OBJS) $(LIBS)
clean:
\u00a0 \u00a0 \u00a0 \u00a0 -rm obj/*
\u00a0 \u00a0 \u00a0 \u00a0 -rm headers.h.gch
To build on FreeBSD:
Install all of the required software from /usr/ports and then compile using the makefile.fbsd
\"It just works\".
That's good, is it running fine on FreeBSD?
I committed the changes to headers.h.\u00a0 For consistency, I used __BSD__.\u00a0 The complete list of defines is at
http://docs.wxwidgets.org/stable/wx_cppconst.html#ifdef __BSD__
#include <netinet/in.h>
#endif
malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble.
Hi.\u00a0 I would like to second the headless/non-GUI mode for /*nix/i systems.\u00a0 It would be useful to be able to start the Bitcoin software from an initscript or one's ~/.bashrc (or equivalent) file and let it run in the background, silently cranking away.
Also, what would the feasibility of changing the location of the wallet.dat file be for the Win32 client?\u00a0 I ask this because I was playing around with the .zipped Windows Bitcoin client yesterday, and it struck me that it would make a good portable application.\u00a0 I was toying with the idea of decompressing it into a TrueCrypt volume on a USB drive so that it could, say, be taken on the road, run for a few hours, and then shut down just before the volume was unmounted, but it created the wallet.dat file in the C:\\Documents and Settings\\username\\Application Data\\Bitcoin directory.\u00a0 In effect, using a portable version of Bitcoin to eventually grow a portable wallet.
",
"nested_level": 0
},
{
"id": 60,
"satoshi_id": 27,
"thread_id": 8,
"source_id": "31",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: A few suggestions",
"url": "https://bitcointalk.org/index.php?topic=12.msg79#msg79",
"date": "2009-12-18T17:37:48Z",
"text": "What you can currently do is set \"Minimize to the tray\" in options, then run it as \"bitcoin -min\" so it starts minimized. \u00a0The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. \u00a0Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty.
We didn't have time to implement the \"Start Bitcoin on system startup\" feature on Linux in time for 0.2 so it's greyed out. \u00a0I figured Linux people wouldn't mind doing that manually anyway. \u00a0I guess they need to know about the -min switch to do it right.
You can locate the data directory where you want with the \"-datadir=<directory>\" switch. \u00a0I know someone is already doing that to put it on a TrueCrypt USB drive.
",
"nested_level": 0
},
{
"id": 61,
"thread_id": 9,
"source_id": "1",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Questions about Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=13.msg43#msg43",
"date": "2009-12-10T13:13:51Z",
"text": "Hi, yesterday I stumbled upon this great payment option.
I read my way through many sites but now I have some questions that couldn't get answered.
1. Is Bitcoin really anonymous? I mean totally and completely? Is my ISP able to detect, that I have sent or received a Bitcoin payment? Maybe he is even able to see that I am running Bitcoin right now?
2. If I understood this correctly, my payment partners are not able to see who I am. Does this mean, they can not see my real IP adress? Only the Bitcoin-adress? Even if they monitors their network connections and stuff?
3. If there is a way for my ISP to tell that I am running Bitcoin or for my payment partners to find out my IP, would it be more safe to tunnel the network traffic through a VPN (payed with Paysafecard for example)? Could this be dangerous, because the VPN provider will be able to capture my payment?
4. What files need to be backed up for not losing my \"money\"? Only the wallet.dat or the whole Bitcoin AppData directory ?
5. Isn`t it possible to multiply a wallet and use it on different machines? This way you would double your money without doing anything for it.
Are there security measures for this case?
6. When someone loses his wallet, will there be a way to recreate the lost coins in the system ? Else the 21 million maximum will not be correct.
(I mean not to recover the lost coins for one person, but if all the 21mio coins were created, and someone loses his wallet with 1mio coins, will the the others be able to create these 1mio coins now or are they totally lost for the bitcoin network?)
7. I have read that there currently are about 130k blocks out there. At my pc it only shows me about 24k. Is there something wrong or is this a normal behaviour ?
8. I`m afraid I didn`t understand everything about the bitcoin creation. How many coins are created by a machine in 24h in average?
9. I know that port 8333 should be forwarded to the bitcoin-running machine. Now I ask myself if this goes for the TCP or the UDP.
And is this port required for generating coins? Or only for payment transactions?
10. I`ve seen that the source code for bitcoin is open for everybody. Can this be an actual danger? If the code is manipulated people can create more bitcoins than others, can`t they? This would be a massive leak of security.
11. I`ve seen a formular to clalculate the coins that will be created in a certain amount of time. It had something to do with the maximum cpu speed and the availabe. Can`t find it anymore, so I`m asking you to explain me the coin creating. Do slow machines produce as much coins as high-end ones?
12. Are there any other exchanging systems or potential payment partners except for new liberty standard?
13. What happens when my system crashes? Is the wallet saved automatically or only when bitcoin gets closed manually? (Maybe even real-time saving when a coint is created or payment is made?)
14. Is there a way to see how many bitcoins have been generated this far? And how old is Bitcoin already?
I know .... Many many questions but I am really interested in your service and want to know everything before I start using it more frequently.
(Sorry for my bad English...)
EDIT 2014-10-31: grammar and typos
",
"nested_level": 0
},
{
"id": 62,
"satoshi_id": 17,
"thread_id": 9,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Questions about Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
"date": "2009-12-10T20:49:02Z",
"text": "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 directory.
Version 0.2: you can backup just wallet.dat.
5:
Nope. The whole design is all about preventing that from working.
6:
Those coins can never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes down.
7:
It's currently 29,296 blocks. The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.
If you only have 24k blocks, it must not have finished the initial block download. Exit bitcoin and start it again. Version 0.2 is better/faster at the initial block download.
8:
Typically a few hundred right now. It's easy now but it'll get harder as the network grows.
9:
Good question, it's TCP. The website needs to be updated to say TCP port 8333.
The port forwarding is so other nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes. You also need it to receive payments by IP address.
10:
No, the other nodes won't accept that.
Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it's essential for a program of this nature to be open source.
11:
Slower machines produce fewer coins. It's proportional to CPU speed.
12:
There are more coming.
13:
It uses a transactional database called Berkeley DB. It will not lose data in a system crash. Transactions are written to the database immediately when they're received.
14:
For now, you can just multiply the total blocks by 50. The Bitcoin network has been running for almost a year now. The design and coding started in 2007.
",
"nested_level": 0
},
{
"id": 63,
"thread_id": 9,
"source_id": "3",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Questions about Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=13.msg48#msg48",
"date": "2009-12-11T17:20:29Z",
"text": "Wow, thanks alot for these detailed answers.
But today another question came to my mind.
Lets say we know, that our neighbar uses Bitcoin, and we also know that he will receive a payment soon (maybe because he owns an internet shop and accepts bitcoin as payment option).
Also, we know that he uses WLAN and his network is unsecured or weak protected. Same goes for router configuration.
We now could log into his router configuration, change the ip adresses for the forwarded port 8333 to our system ip.
Now every payment would be received by our bitcoin client.
Is this actually going to work ?
I know this is highly criminal and the scenario is .. well, lets call it \"uncommon\", but in theory it should work, right ?
(Not that I have an interest in harming people, but I know that criminal people will try many ways to get some money.)
BTW: same should work when you are on a LAN party with unprotected router config.
Edit: Or are these scenarios totally impossible because no matter which ip adress uses the port, the payment will go to the bitcoin or ip adress that was defined from the payer ?
",
"nested_level": 0
},
{
"id": 64,
"satoshi_id": 18,
"thread_id": 9,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Questions about Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=13.msg49#msg49",
"date": "2009-12-11T17:58:57Z",
"text": "That's true, with the send-to-IP option, you are sending to whoever answers that IP. Sending to a bitcoin address doesn't have that problem.
The plan is to implement an IP + bitcoin address option that would have the benefits of both. It would still use a different address for each transaction, but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver.
",
"nested_level": 0
},
{
"id": 65,
"satoshi_id": 25,
"thread_id": 10,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin 0.2 released!",
"url": "https://bitcointalk.org/index.php?topic=16.msg73#msg73",
"date": "2009-12-16T22:45:36Z",
"text": "Bitcoin version 0.2 is here!
Download links:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/downloadhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/downloadhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/downloadNew Features
Martti Malmi
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version (tested on Ubuntu)
Satoshi Nakamoto
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download
Major thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version.
So, I finally got my client to start generating and after I got my laptop optimized for the task and waited over night. My first transaction completed resulting in +50 Coins. Yay!!
However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?
I have a Screen Shot if needed. Sorry if this is a basic question but I'm sure someone will ask if I don't.
Thanks for taking the initiative on this project Mr. Satoshi.
![\"Grin\"](\"/static/img/emoticons/grin.gif\"/)
Maybe one day I can fire my bank once and for all.
EDIT: I decided to stop playing around and I set BitCoin up on my high powered gaming rig, forwarded 8333 to it, and started generating on it instead of my laptop. So then I transferred my previous 50 coins to that client but it's been an hour and nothing has shown up for me to accept the transfer. Both computers are on the same wireless LAN. I sent it to just the BitCoin address because I wasn't sure if I was supposed to send to my internal or external IP. I assume external because the transaction needs to be verified by other nodes. Right? I also assumed sending to the BC address only would make sure it goes through the proper channels. Did I just throw my coins away or should I wait longer? I'm new at this. Sorry.
So, I finally got my client to start generating and after I got my laptop optimized for the task and waited over night. My first transaction completed resulting in +50 Coins. Yay!!
Congratulations and welcome to the forum
![\"Cool\"](\"/static/img/emoticons/cool.gif\"/)
However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?
The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One \"generated\" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a \"block\" a bit confusing on the first sight.
EDIT: I decided to stop playing around and I set BitCoin up on my high powered gaming rig, forwarded 8333 to it, and started generating on it instead of my laptop. So then I transferred my previous 50 coins to that client but it's been an hour and nothing has shown up for me to accept the transfer.
There's no confirmation of incoming transactions when someone sends to your Bitcoin address, all transactions are automatically completed. Did the transaction show up in the transaction list?
Both computers are on the same wireless LAN. I sent it to just the BitCoin address because I wasn't sure if I was supposed to send to my internal or external IP. I assume external because the transaction needs to be verified by other nodes. Right?
Other nodes aren't going to know which IP you're sending to, your client just connects directly to it. Both IP's are fine as long as the connection routes to the right computer. Anyway, I'd use the inner address inside a network for simplicity.
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 before it'll see the received transaction. That means the status bar at the bottom needs to say at least 33000 blocks, like \"x connections 33200 blocks x transactions\".
However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?
The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One \"generated\" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a \"block\" a bit confusing on the first sight.
Would it be clearer if the status said \"x confirmations\", like:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations
Each block essentially means another node has confirmed that it agrees with all transactions up to that point.
Can bitcoin be compiled to run on 64 bit systems yet? -m64 seems to break the compile.
(Not trying to nag or anything).
On a side node: I have noticed that the network is about 3x larger than normal now. I see more nodes!
I haven't tried compiling 64-bit yet. 64-bit wouldn't make it any faster, since it uses 64-bit numbers in only a few places and SHA-256 is a 32-bit algorithm, but it may be convenient for those running a 64-bit OS. If I get a chance I'll try -m64 and see what the problem is.
You can run the 32-bit version on 64-bit Linux by installing ia32-libs. (sudo apt-get install ia32-libs) If we made a Debian package, it could automatically pull that in as a dependency.
",
"nested_level": 0
},
{
"id": 71,
"thread_id": 12,
"source_id": "3",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: 64bit support",
"url": "https://bitcointalk.org/index.php?topic=18.msg103#msg103",
"date": "2010-01-16T23:16:56Z",
"text": "All modern computers are amd64/EM64T. It should be able to be compiled on either platform. It is a hassle to compile all of the dependancies in 32-bit mode just to run one program. I know the 32-bit/64-bit stuff is seamless on windows platforms but on *NIX platforms it is a major pain since they are usually either one or the other by default.
As a workaround I am in the process of compiling FreeBSD 32-bit jails (aka virtual server images) just for running bitcoin on our network. It should make it easier for me to deploy more nodes as they can simply be zipped up / scp'd / extracted / launched. After I have a working system image based on FreeBSD-8.0 I may post a link for download.
Thanks and keep up the good work. I can't wait to see how many exchangers are willing to trade BT. The stability of the exchangers and their longevity is everything. If the exchangers stick around big businesses may use this system to get around service fees / chargebacks / and the general faults caused by the credit card industry.
Keep up the great work!
I second the request for 64-bit support, even if it wouldn't make the app run faster. I'm no expert, but I can't see any harm in it. On the other hand, it's a good way to embrace the future.
",
"nested_level": 0
},
{
"id": 73,
"satoshi_id": 38,
"thread_id": 12,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 64bit support",
"url": "https://bitcointalk.org/index.php?topic=18.msg174#msg174",
"date": "2010-01-29T00:42:49Z",
"text": "I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0.
There was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0.
wxWidgets 2.9.0 is UTF-8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support.
I compiled and ran on 64-bit Ubuntu 9.10 Karmic.
I think the only bug left is where the status number is mashed up. I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked into it.
build-unix.txt is updated and two makefiles on SVN:
makefile.unix.wx2.8
makefile.unix.wx2.9
Unfortunately there's still no debian package for either version of wxWidgets we use. They only have the wchar (\"unicode\") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets 2.9. So you still have to get it and build it yourself.
",
"nested_level": 0
},
{
"id": 74,
"thread_id": 13,
"source_id": "1",
"poster_name": "RogerRabbit",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=22",
"subject": "Number of connections?",
"url": "https://bitcointalk.org/index.php?topic=21.msg102#msg102",
"date": "2010-01-16T14:27:15Z",
"text": "What exactly does the number of connections do for me? Do I generate more coins with more connections, or is it equivalent no matter what?
It seems that from time to time, Tor gets tied up and can go for a few hours with 3 or 4 connections. Then, when I restart bitcoin or restart Tor to refresh my connections, I can get 7,8, or even more (9 currently).
I haven't really been able to tell if coins generate slower or not with less connections, but I was curious if it does correlate. If not, how exactly will having more connections help me out compared to less?
",
"nested_level": 0
},
{
"id": 75,
"satoshi_id": 30,
"thread_id": 13,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Number of connections?",
"url": "https://bitcointalk.org/index.php?topic=21.msg112#msg112",
"date": "2010-01-20T20:07:15Z",
"text": "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 the certainty that you're well connected to the network. That hasn't been a problem in practice, the network is very thoroughly connected. If you have 2 or 3 connections, you're fine.
",
"nested_level": 0
},
{
"id": 76,
"thread_id": 14,
"source_id": "1",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "TOR and I2P",
"url": "https://bitcointalk.org/index.php?topic=22.msg104#msg104",
"date": "2010-01-16T23:22:55Z",
"text": "Hello,
I have had another idea.
It would be very cool to be able to have TOR and I2P seeds. For example: I could run BT within TOR-land on a .onion address. A client could connect their BT to TOR and have it seed from a .onion address and use it as a connected peer. (Likewise for I2P: someone could run a .i2p service that is -- well -- BC).
I might setup a couple of nodes in this fashion and post the tunnels on this forum. I already run a lot of I2P and TOR nodes so adding BC to the mix is quite trivial.
I support the idea of making BC compatible with TOR and I2P to increase the privacy of the system. I mean: why re-invent the wheel? There are thousands of mix network nodes just sitting there that can be used to enhance BC.
![\"Cheesy\"](\"/static/img/emoticons/cheesy.gif\"/)
Cheers!
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 number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way.
",
"nested_level": 0
},
{
"id": 78,
"thread_id": 14,
"source_id": "3",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: TOR and I2P",
"url": "https://bitcointalk.org/index.php?topic=22.msg120#msg120",
"date": "2010-01-24T20:52:59Z",
"text": "Yeah, I2P is much easier to automate in that regard. I could setup some .onions manually and post them to the list to be used as seeds. I have always-on nodes that can just be tied to Tor with minimal effort.
I used to be a big advocate of Tor, but after I started using I2P I found it to be much, much better in a lot of ways. Biggest improvement is speed.
Too bad they wrote it in Java.
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 number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way.
I also run a Tor relay and exit node and had similar ideas for Tor integration with Bitcoin.
Tor can be very fast if you edit your config correctly. You just need to limit the connectivity with slow servers and only use the fastest nodes where possible. I also like to block any nodes in 'problem' internet countries, which also tend to have slower connectivity, this also increases overall privacy somewhat. I also block Unnamed, ididnteditheconfig, any servers that I don't like the name of and unstable servers.
This config. example is only good for non-relay / non-exit personal use. Although its great for P2P
AvoidDiskWrites 1
ExcludeNodes SlowServer,{sd},{pk},{tn},{ae},{by},{in},{bh},{th},{ye},{mm},{eg},{sg},{ma},{cu},{qa},{sa},{by},{md},{tm},{tr},{et},{jo},{sy},{om},{ir},{az},{uz},{kz},{kg},{af},{cn},{bd},{vn},{ng},{gh},{ro},{lb},{ru},{iq},{ly},{ve},{zw},{my},{mo},{kr},unnamed,ididnteditheconfig ...etc.
StrictEntryNodes 1
EntryNodes (Select Fast Entry and Authority Servers from
http://trunk.torstatus.kgprog.com/index.php?Fast=0 )
StrictExitNodes 1
ExitNodes (Select Fast Exit Only from
http://trunk.torstatus.kgprog.com/index.php?Fast=0 )
It's also a good idea to alter the time which Tor takes to automatically switch circuits and some other custom settings
https://www.torproject.org/tor-manual.htmlHope this helps
OK So, I tried to set-up a sudo-anonymous crypto 'Bitcoin Bank' experiment using Tor.
Whilst it was mostly successful using the standard 9050 socks port 'default setup' i.e. I got connectivity to other Bitcoin nodes through Tor; I did encounter various issues and multiple Warning messages.
\"Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider
using Socks4A (e.g. via polipo or socat) instead.\"
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3FI eventually fixed this using Privoxy and Stunnel (because i'm more familiar with those) However, you could use polipo and Stunnel.
However, I still get occasional warnings for these ports 8333 (expected Bitcoin 'default') and 6667 (which if i'm not mistaken is an IRC port !?)
Connecting Bitcoin through Tor also makes Tor repeatedly change exit nodes looking to establish 'missing' connections to a [scrubbed] address. At first I assumed that this was because Tor exits might be blocking port 8333 or 6667, but that is mostly not the case !
Other P2P applications through Tor can 'ignore' IP addresses that they cannot connect to and the application can still get the job done without 'warning'. However, Bitcoin
must try to connect with all nodes to check its not missing any blocks ! So, if an IP range where only 1 Bitcoin node is running is blocking Tor exit nodes, then presumably this will always be the case ?
This is problematic for many reasons.
![\"Huh\"](\"/static/img/emoticons/huh.gif\"/)
\"Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider
using Socks4A (e.g. via polipo or socat) instead.\"
Bitcoin is using ip-adresses, not hostnames, so there's no need for dns. Tor thinks that since bitcoin is trying to connect to an ip without looking it up through tors internal dns, it's using a regular dns.
However, I still get occasional warnings for these ports 8333 (expected Bitcoin 'default') and 6667 (which if i'm not mistaken is an IRC port !?)
Bitcoin is using port 8333, even though it's relaying it through tor on port 9050..
6667 is irc, bitcoin uses an irc-server to distribute the nodelist. (If you know the ip of another computer running bitcoin, you can specify the -connect option to avoid using the nodelist).
However, Bitcoin must try to connect with all nodes to check its not missing any blocks !
No, it's enough if you're just connected to one single node, as long as it's got a copy of the longest block-chain.
OK thanks riX.
So, once Bitcoin has connected to at least one node then the -connect option will eliminate the 6667 warnings.
Is Bitcoin using any kind of 'peer exchange' or DHT because this still does not seem to prevent the constant Tor 'exit' warnings and therefore Tor's requirement to try a new 'exit' node for connection. (which is problematic ! For Tor anyway, not Bitcoin
) This is really what I meant by \"However, Bitcoin must try to connect with all nodes to check its not missing any blocks ?\" I just communicated it incorrectly.
I2P would seem to be a much easier solution to implement to increase a Bitcoins users anonymity.
http://forum.i2p2.de/viewtopic.php?t=3946&sid=213e3cd998db98c4511675ecbba17af4I'm also testing JonDonym
http://anonymous-proxy-servers.net/ (only the paid services support socks !) However, they do accept paysafecards which can currently be brought in exchange for Bitcoins.
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 be a regular old normal proxy and would keep retrying IRC at longer and longer intervals. You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin might be trying to overcome it by reconnecting. You should use port 9050.
As riX says, the \"is giving Tor only an IP address. Apps that do DNS...\" warnings are nothing to worry about. Bitcoin doesn't use DNS at all in proxy mode.
Since Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes. It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected. It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected. For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts. Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old.
",
"nested_level": 0
},
{
"id": 84,
"thread_id": 15,
"source_id": "1",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg118#msg118",
"date": "2010-01-24T09:52:48Z",
"text": "Hello all. I've decided to give Bitcoin a try. As a test, I want to see if I can make $1 USD from selling a picture. According to
this, 500 Bitcoins should roughly be a dollar (after PayPal fees), right?
If I understand this correctly, I should be told the Bitcoin Address of anyone who Sends me Bitcoins, right? And you have the ability to attach messages to the Send? If so, then I guess I could Send 0 Bitcoins in return, with a message containing a download link for the full image. Is this how things are supposed to work, or am I mistaken? To get the picture, please send the coins to me and then send a Private Message stating the time you sent them. I will reply to your Private Message with a link to the picture.
The image I'm selling is my own creation, with a resolution of 1280x960 - great for a desktop background. Here's a low-quality preview:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FCityGen_demo.png&t=589&c=lQ-awpROyhEEFw\"/)
Anyway, it's been a pleasure to meet you all. My Address is 1BHtsCnpmTvpgJEP7eMKEVhpJFunxSM8vq. If this generates any interest, I could offer some more of my pictures...
Hmm.. I am not sure if you can send a 0-coin payment. Can anyone confirm this?
",
"nested_level": 0
},
{
"id": 86,
"thread_id": 15,
"source_id": "3",
"poster_name": "RogerRabbit",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=22",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg124#msg124",
"date": "2010-01-25T02:42:13Z",
"text": "Simple solution to that. If it's for sale for 500 coins, just have them send 501 and send 1 back
I assume you tested it, then, and it didn't work? Very well. Hm, what about decimals? I notice that my balance is 0.00. Could I send 0.01 coins?
",
"nested_level": 0
},
{
"id": 88,
"thread_id": 15,
"source_id": "5",
"poster_name": "RogerRabbit",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=22",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg126#msg126",
"date": "2010-01-25T04:06:03Z",
"text": "I, have not tested it. Just giving ideas. Besides, 1 coin, according to Liberty Standard's exchange, is less than a penny. I wouldn't get hung up on decimals.
",
"nested_level": 0
},
{
"id": 89,
"thread_id": 15,
"source_id": "6",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg129#msg129",
"date": "2010-01-25T07:40:02Z",
"text": "Hello all. I've decided to give Bitcoin a try. As a test, I want to see if I can make $1 USD from selling a picture. According to
this, 500 Bitcoins should roughly be a dollar (after PayPal fees), right? If I understand this correctly, I should be told the Bitcoin Address of anyone who Sends me Bitcoins, right? And you have the ability to attach messages to the Send? If so, then I guess I could Send 0 Bitcoins in return, with a message containing a download link for the full image. Is this how things are supposed to work, or am I mistaken?
Unfortunately you can't attach a message when you send to a Bitcoin address. It's possible only when sending to an IP. Sending 0 coins is also not possible.
If you want to track payments, you can give a new Bitcoin address to each customer. How to make a new address: Options -> Change your address. We could perhaps make this easier by adding next to \"Send Coins\" a button \"Receive Coins\", which would create you the new address and ask for its label.
You can't send messages to Bitcoin users unless it's the IP? That seems unnecessary. Any reasoning behind this? I think people will use Bitcoin addresses a lot more often than the IP address when sending or receiving coins.
",
"nested_level": 0
},
{
"id": 91,
"thread_id": 15,
"source_id": "8",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg131#msg131",
"date": "2010-01-25T17:36:10Z",
"text": "No messages that way? That seems less than ideal. Very well, what would be a more correct way to do this?
For now, if anyone sends 500 coins and tells me in Private Message the time they sent it, I shall respond with a link to the picture.
",
"nested_level": 0
},
{
"id": 92,
"thread_id": 15,
"source_id": "9",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg132#msg132",
"date": "2010-01-25T19:25:29Z",
"text": "You can't send messages to Bitcoin users unless it's the IP? That seems unnecessary. Any reasoning behind this? I think people will use Bitcoin addresses a lot more often than the IP address when sending or receiving coins.
I think it was some technical limitation. Satoshi could tell more about this?
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 very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.
Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA.
",
"nested_level": 0
},
{
"id": 94,
"thread_id": 15,
"source_id": "11",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: A newb's test - anyone want to buy a picture for $1?",
"url": "https://bitcointalk.org/index.php?topic=25.msg162#msg162",
"date": "2010-01-28T05:13:04Z",
"text": "Yes, encryption of messages would be a very good thing... So the problem is not that you can't store the message on the network, but rather, that you do not yet have a good way of encrypting it?
",
"nested_level": 0
},
{
"id": 95,
"thread_id": 15,
"source_id": "12",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Encrypted Message is Worth the Extra Size",
"url": "https://bitcointalk.org/index.php?topic=25.msg164#msg164",
"date": "2010-01-28T09:58:17Z",
"text": "I certainly wouldn't mind a larger Bitcoin application if it meant we could send an encrypted message along with each transaction. Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins. About how many MB do you think it would add? Of course these messages will add to the size of the confirmation blocks being stored, so there should probably be a maximum size. Perhaps 256 characters would be a good maximum since
the maximum size of an email address is 254 characters.
It would also be nice if transactions included a return address so that if a product or service being purchased can't be delivered the seller could more easily and reliably refund the bitcoins.
A balance between extended transaction data while NOT becoming an instant messenger client would be nice.
Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins.
Why don't you make them send the email before the transaction? Then you could reply to that email with a new and unique bitcoin address. You don't even need to use email, it would be equally secure, although not that anonymous, to announce the customers email together with the bitcoin address on the frontpage of your site.
The method you are using now is equal to someone sending you cash in an envelope anonymously, including a note with the time he posted it, after which you send goods back to the first person calling you stating the time and amount in the envelope. (Including the mailman and anyone who has access to you mailbox).
Sending the email before the transaction is equal to someone calling you, getting a unique box address which to send the money to. When the money arrives to that post box, you send the goods to the customer.
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 will be the standard way for website software to do it.
RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.
",
"nested_level": 0
},
{
"id": 99,
"thread_id": 16,
"source_id": "1",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Bitcoin crash when sending coins",
"url": "https://bitcointalk.org/index.php?topic=27.msg135#msg135",
"date": "2010-01-25T23:07:16Z",
"text": "Lately when I've been trying to send coins, the following popups twice, then the application terminates.
EXCEPTION: St13runtime_error
SendMoney() : wtxNew.AcceptTransaction() failed
c:\\Documents and Settings\\username\\bitcoin-0.2.0\\bitcoin.exe in
CMyApp::OnExceptionInMainLoop()
When i restart bitcoin.exe, the transaction is showing as 0/unconfirmed. The status do not change even when the total block count increases.
I'm running two instances of bitcoin in my home LAN, one at my desktop computer, and one in a virtual machine on my laptop, with the switch -connect=192.168.0.2 (ip of desktop computer).
This occurs when I send to my own bitcoin address, to my other computers bitcoin address and to an other bitcoin address not currently active anywhere. I'm not sending by ip.
I've been moving wallets and index-files back and forth, could this have something to do with this?
That is what happens if you copy wallet files around. If you copy your wallet file to a second computer, then they both think the money in the wallet is theirs. If one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit.
Now that it's clear this is a key error message, it ought to be something more like \"the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer.\"
You can move or backup your wallet file, but it needs to have only one \"lineage\" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies.
This brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message.
",
"nested_level": 0
},
{
"id": 101,
"thread_id": 16,
"source_id": "3",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: Bitcoin crash when sending coins",
"url": "https://bitcointalk.org/index.php?topic=27.msg157#msg157",
"date": "2010-01-27T22:14:20Z",
"text": "Yes, I thought it had something to do with that.
It would be nice if there was a wallet tool for merging wallet files, removing unused bitcoin addresses and as you say resyncing. (I tried to just re-download all the blocks, but as you know the transactions stayed anyway.)
What about resyncing in the future when the Merkle-tree is pruned?
",
"nested_level": 0
},
{
"id": 102,
"satoshi_id": 35,
"thread_id": 16,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin crash when sending coins",
"url": "https://bitcointalk.org/index.php?topic=27.msg170#msg170",
"date": "2010-01-28T23:08:02Z",
"text": "The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent. That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent. Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.
A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem. With resync, you could do about the same thing by sending all the money from one wallet to the other. The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.
",
"nested_level": 0
},
{
"id": 103,
"satoshi_id": 39,
"thread_id": 16,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin crash when sending coins",
"url": "https://bitcointalk.org/index.php?topic=27.msg219#msg219",
"date": "2010-02-03T23:29:57Z",
"text": "I uploaded this fix to the SVN. It watches for spent coins and updates your wallet on load and also continuously as blocks come in. I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.
If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit).
",
"nested_level": 0
},
{
"id": 104,
"thread_id": 17,
"source_id": "1",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Blocks never stop generating?",
"url": "https://bitcointalk.org/index.php?topic=28.msg137#msg137",
"date": "2010-01-26T02:48:41Z",
"text": "Hello. My understanding of Bitcoin is not perfect, so I would like to ask questions about its operation. When Generating, the user will gain 50 coins after creating 120 blocks. Why does the program continue generating blocks after that point? And why does one not gain another 50 coins after generating 240 blocks?
Also, I sent a few coins to someone to test the transaction system. Even though it was just a few coins, that transaction's status currently reads \"166 blocks\". It seems that it will continue incrementing indefinitely. Why is this?
I thank responders for increasing my knowledge.
",
"nested_level": 0
},
{
"id": 105,
"thread_id": 17,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Blocks never stop generating?",
"url": "https://bitcointalk.org/index.php?topic=28.msg139#msg139",
"date": "2010-01-26T04:43:44Z",
"text": "The user gets 50 coins when he has created 1 block. The coins can be used (they \"mature\") when 120 blocks have been generated by the whole network after he created the block. The number of blocks of a transaction means the number of new blocks in the whole block chain after the transaction. The whole block chain grows ad infinitum.
",
"nested_level": 0
},
{
"id": 106,
"thread_id": 17,
"source_id": "3",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: Blocks never stop generating?",
"url": "https://bitcointalk.org/index.php?topic=28.msg141#msg141",
"date": "2010-01-26T18:16:23Z",
"text": "So that transaction will eventually read \"1000 blocks\" or more? Is this information important?
",
"nested_level": 0
},
{
"id": 107,
"thread_id": 17,
"source_id": "4",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: Blocks never stop generating?",
"url": "https://bitcointalk.org/index.php?topic=28.msg142#msg142",
"date": "2010-01-26T22:51:47Z",
"text": "Yes it will.
Importance is relative. You can use the number of blocks to calculate some statistics. Also, if you press ctrl+[numpad+], you will see the serial number and hash of the blocks. (At least on windows).
",
"nested_level": 0
},
{
"id": 108,
"satoshi_id": 34,
"thread_id": 17,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Blocks never stop generating?",
"url": "https://bitcointalk.org/index.php?topic=28.msg160#msg160",
"date": "2010-01-28T01:08:33Z",
"text": "Where it says \"# blocks\" in the status column I'm changing it to say \"# confirmations\". That might be clearer.
If you doubleclick on the transaction you get a little more information.
",
"nested_level": 0
},
{
"id": 109,
"thread_id": 18,
"source_id": "1",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Payment server",
"url": "https://bitcointalk.org/index.php?topic=29.msg143#msg143",
"date": "2010-01-27T07:51:02Z",
"text": "As I have read in some topics (
https://www.bitcoin.org/smf/index.php?topic=12.0,
https://www.bitcoin.org/smf/index.php?topic=19.0), a payment server is needed for a broader acceptance of Bitcoins.
I want to create a php webapplication which can process Bitcoins transactions. I have a LAMP system up and running, but until now I used bitcoins on Windows only. Can anyone help me to create a linux installation of Bitcoins with a command line interface?
Server runs Ubuntu 9.10 32-bit. Or should I use a different distribution?
My idea is simple:
- visitor wants to buy something;
- payment page shows him the amount of Bitcoins he has to pay, including an orderid and a ip-address of the server (because messages can only be sent through ipaddress-transactions);
- visitor makes a payment with his Bitcoin application and places the orderid in the message of the payment;
- server receives payment and checks orderid and amount;
- payment is received, visitor is sent a downloadlink/confirmation of purchase/etc.
Think this is possible with Bitcoin 0.2?
Instead of an ip-address, an unique bitcoin address should be created, and is also way less vulnerable. This is all that is needed for the server to keep track of incoming bitcoins.
You will have to do some programming to get command-line access to the needed functions.
I bet you could get someone to do it for you for some bitcoins
Instead of an ip-address, an unique bitcoin address should be created, and is also way less vulnerable. This is all that is needed for the server to keep track of incoming bitcoins.
Sirius-m said (
https://www.bitcoin.org/smf/index.php?topic=25.msg129#msg129):
Unfortunately you can't attach a message when you send to a Bitcoin address. It's possible only when sending to an IP.
And:
I think it was some technical limitation. Satoshi could tell more about this?
Is it possible in Bitcoin 0.2 to attach messages when using a bitcoin address?
No, you can't send a message when sending to an ip, but that's what the _unique_ bitcoin address is for.
When the customer places an order, the server creates a new bitcoin address to be used for that order only. (This can be seen as the orderId if you want).
When the customer makes a payment to that bitcoin address/orderId, the server will know who it's from.
There's no need for a message.
",
"nested_level": 0
},
{
"id": 113,
"thread_id": 18,
"source_id": "5",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: Payment server",
"url": "https://bitcointalk.org/index.php?topic=29.msg150#msg150",
"date": "2010-01-27T11:56:17Z",
"text": "This means that a server can process one payment at a time. Unless a server is capable of having more than one bitcoin address.
",
"nested_level": 0
},
{
"id": 114,
"thread_id": 18,
"source_id": "6",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: Payment server",
"url": "https://bitcointalk.org/index.php?topic=29.msg151#msg151",
"date": "2010-01-27T12:49:07Z",
"text": "Wallets already support multiple bitcoin addresses.
You should check out \"Options/Change your address\" in your bitcoin app
Wallets already support multiple bitcoin addresses.
You should check out \"Options/Change your address\" in your bitcoin app
riX, you are absolutely right!
![\"Embarrassed\"](\"/static/img/emoticons/embarrassed.gif\"/)
Now all I need is a command line version of Bitcoin.
Command line is on the to-do list after 0.2.
Satoshi, when we may expect the new command line-abled version of Bitcoin? Or is it possible to compile Bitcoin 0.2 in a way it can be used by command lines?
That's the right way to do it as riX says. The software can generate a new bitcoin address whenever you need one for each payment. \"Please send X bc to [single-use bitcoin address] to complete your order\" When the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.
Adding command line support is a high priority. It's just a matter of getting the time to code it.
",
"nested_level": 0
},
{
"id": 117,
"thread_id": 19,
"source_id": "1",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "We accept Bitcoins [moved to bitcoin.it/wiki/Trade]",
"url": "https://bitcointalk.org/index.php?topic=30.msg144#msg144",
"date": "2010-01-27T09:10:16Z",
"text": "To promote the use of Bitcoins in commerce, I've started this topic. Now anyone can post sites where Bitcoins are accepted
edit by sirius-m: Traders' list has been moved to the wiki.http://www.teslamap.com/This site removed the possibility to pay with Bitcoins. Too bad.
![\"Cry\"](\"/static/img/emoticons/cry.gif\"/)
http://newlibertystandard.wetpaint.com/The mother of all Bitcoin-accepting websites
",
"nested_level": 0
},
{
"id": 120,
"thread_id": 19,
"source_id": "4",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg161#msg161",
"date": "2010-01-28T01:16:26Z",
"text": "Good idea, made sticky
http://www.livingsoulnation.org/ \"LivingSoulNation.org is now using Bitcoin as its currency. Use it to trade with us or use it to donate Bitcoin(s).\"
Not sure what they trade, though
",
"nested_level": 0
},
{
"id": 122,
"thread_id": 19,
"source_id": "6",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg194#msg194",
"date": "2010-02-01T22:26:11Z",
"text": "I'm starting to offer Bitcoin eCurrency exchange services through my new website
http://www.bitcoinfx.cz.cc/I'm also looking into offering Bitcoin users a web based Forex API to day trade the BTCUSD currency pair in the future. However, I first need to generate enough Bitcoins to act as the broker
http://btc2psc.bt.funpic.org/ Sell your Bitcoins for 10\u0080 Paysafecard codes.
",
"nested_level": 0
},
{
"id": 124,
"thread_id": 19,
"source_id": "8",
"poster_name": "livingsoulnation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=32",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg241#msg241",
"date": "2010-02-05T06:23:14Z",
"text": "http://www.livingsoulnation.org/ \"LivingSoulNation.org is now using Bitcoin as its currency. Use it to trade with us or use it to donate Bitcoin(s).\"
Not sure what they trade, though
We are selling 'indulgences' just like the Roman Catholic Church used to. Just kidding.
Utilizing someone's exchange service would be nice. We are accepting donations to start, and if someone wanted us to link back to their site (links or banners), or promote their exchange we would certainly do that for some BitCoins. We are associated with PNNAC.ORG, a private freedom-based society that may also be interested in the same things. Their contact info is on the site.
Let's start some dialogue and see where it takes us. I'll check out the existing exchanges and if they look reasonable I'll contact them.
This will be what makes bitcoin successful, being able to exchange it for goods & services(not just an exchange service).
Virtual currency (nothing like bitcoin) can become successfull in being accepted for real goods & services, it just takes a little time. Qcoin was popular here in China but is being put down by the Chinese central bank.
See here
http://en.wikipedia.org/wiki/Tencent_QQ#Q_coin and here
http://online.wsj.com/public/article/SB117519670114653518-FR_svDHxRtxkvNmGwwpouq_hl2g_20080329.htmlWell I'm in China, for things like getting documents translated to Chinese and maybe some goods (starting with cheaper items) I can post. I also have access to plenty of poor students who I might be able to convince to contribute their time (for programming, website design, logo design etc.) for bitcoins.
I myself am an English teacher so I haven't much to offer as a remote service.
Hi, one thing just came to my mind and I want to share the idea with you guys.
Is there any free/cheap software or CMS for building an online auction house like ebay ?
I really like the idea of eBay with BTC
EDIT: ok, found some stuff here
http://www.hotscripts.com/category/php/scripts-programs/auctions/, maybe i will set something up, hmm ...
I have started an experimental service for anonymous storage using encfs, sshfs and TOR:
http://isj6esrpkl5kgi5r.onion/Please let me know what you think
you should state some info about your service on the page.
couldn't find anything about up/download speeds or traffic limits.
",
"nested_level": 0
},
{
"id": 130,
"thread_id": 19,
"source_id": "14",
"poster_name": "ec",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=42",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg373#msg373",
"date": "2010-02-16T09:38:51Z",
"text": "you should state some info about your service on the page.
couldn't find anything about up/download speeds or traffic limits.
Thank you for your interest! My server sits on a 100MBit network, but I guess the bandwidth is somewhat limited by TOR, so it's \"unlimited\". Actually, the 1GB \"limit\" isn't enforced for this reason either
While I will do my best to keep my server on line, I of course don't expect anyone to trust me, and I therefore suggest that other people set up similar services and let people have multiple backups at different places (maybe combined with unionfs-fuse or similar).
I of course can't compete with dropbox etc, but this should be an excellent place to back up sensitive (your encrypted bitcoin wallet?) data limited in size.
To promote the use of Bitcoins in commerce, I've started this topic. Now anyone can post sites where Bitcoins are accepted
I am interested in real goods exchange for BITCOIN
I am looking for Corn, Malt (Hopped or not), Malted wheat, barley and rye
I am going to \"mix my labor\" with these resources to generate a product that I will accept bitcoins in exchange for...
I know the e-trade aspect is the easy link to increase the usage and therefore value of this exchange product, but without a real product exchange, you will be hard pressed to gain the widespread usage for stable value and common usage...
I will send you physical comic books for your bitcoins. I'll try to work out a more formal system in the future, but for now you can pm me your interests or contact details and I'll let you know what I have that might fit and we can make a deal.
",
"nested_level": 0
},
{
"id": 133,
"thread_id": 19,
"source_id": "17",
"poster_name": "seq2010",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=53",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg573#msg573",
"date": "2010-02-28T02:52:40Z",
"text": "I would like to offer my services in exchange for Bitcoins. I am a master certified mechanic, and can offer a help desk style phone in service for anyone stuck trying to fix their car and needs some help.
PM me if your interested.
steve-
",
"nested_level": 0
},
{
"id": 134,
"thread_id": 19,
"source_id": "18",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg605#msg605",
"date": "2010-03-02T17:42:20Z",
"text": "I have 244 Travian Gold that I am willing to trade for bitcoins. They are transferable to *.se servers only.
I will edit this post if I trade them.
",
"nested_level": 0
},
{
"id": 135,
"thread_id": 19,
"source_id": "19",
"poster_name": "SheriffWoody",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=55",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg636#msg636",
"date": "2010-03-05T02:39:07Z",
"text": "I am planning on getting a dedicated website for this, maybe a tor hidden service, but anyway.
I am a university student and I highly believe in free education, so I will be gradually uploading the notes from all of my classes so that the general public can become more educated. This is just the beginning of my notes, and as I am a psychology major, the next upload sprees will be specializing more in psychology with the higher level courses.
I am not going to charge anything, however, bitcoin donations would be appreciated.
If you wanted to donate to me, here is my address: 1JfyQHPFQoMnyWUmUeLzm6zbi1Rc3hGrKY
Psychology101:
http://rapidshare.com/files/359091364/Psyc_101.zip.htmlFamily:
http://rapidshare.com/files/359091228/Family.zipChinese Culture:
http://rapidshare.com/files/359094826/Chinese_Culture.zipLink2VoIP (
www.link2voip.com) accepts Bitcoin as payment.
Now you can get phone service for Bitcoins.
How's that for useful?
Link2VoIP (
www.link2voip.com) accepts Bitcoin as payment.
Now you can get phone service for Bitcoins.
How's that for useful?
It would be infinitely more so If I could find the BTC Rate....
I emailed support and asked them. (I've been a customer for 4 years. I was also the one who suggested that they accept BCs.)
They told me that they are matching New Liberty Standard's BC/USD rate for the time being.
I sent them a payment today and I received a credit. Looks like it works.
So their unlimited service is $9.99 a mo (correct?)
That would equate to:
$9.99 * 146.22 BTC/$
1458.54 BTC/mo.
Unless there are people local to me that wish to purchase my consumer goods for BTC the marginal use of BTC does not exceed $ for me yet....
",
"nested_level": 0
},
{
"id": 140,
"thread_id": 19,
"source_id": "24",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg744#msg744",
"date": "2010-03-17T15:33:04Z",
"text": "I pay $9.99 for a local phone number. Been a customer for 4 years. It works great.
I also use them to connect my mobile calls. (Mobile calls here are seriously an arm+leg with our local provider.)
Oh, and I also resell some of their stuff to friends to make a few extra bucks.
",
"nested_level": 0
},
{
"id": 141,
"thread_id": 19,
"source_id": "25",
"poster_name": "DannyM",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=51",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg746#msg746",
"date": "2010-03-17T16:01:07Z",
"text": "Unless there are people local to me that wish to purchase my consumer goods for BTC the marginal use of BTC does not exceed $ for me yet....
I know I'm probably not local, but what are the consumer goods you are selling?
Hehe, that was my idea you thief
But there was a lack of customers, so I closed my service.
Good luck with that
You'll get customers eventually. Stay patient!
Actually, we just polished up our Bitcoin integration. Payments into our system are fully automated now.
Link2VoIP (
www.link2voip.com) accepts Bitcoin as payment.
Now you can get phone service for Bitcoins.
How's that for useful?
Link2VoIP (
www.link2voip.com) accepts Bitcoin as payment.
Now you can get phone service for Bitcoins.
How's that for useful?
that rocks madhatter. i love link2voip. progressive!
Our Society (The Canadian Free Man On The Land Society -
www.pnnac.org) accepts Bitcoins as a donation. We use the funds to pay for our monthly VPS hosting bill with Link2VoIP.com.
What a small world.
I have recently revised my Liberty Reserve Exchange Service website - BitcoinFX -
http://www.bitcoinfx.cz.cc/ I will soon be funding and maintaining the availability of both BTC and LR at a 100% ratio against the exchange rate.
I have chosen to use a
http://www.nic.cz.cc/ domain because it is purposefully obscure ! It is a paid domain for 2 years and is automatically renewable. Its an extremely inexpensive method for hosting a domain with SSL support and Privacy Protect. ( Less than $5 for 2 years ) I have full control over my A Record etc. and the web host is very stable. In the future I will be adding SSL and the LR and Bitcoin API's to make the exchange service 100% automated, as long as their are available funds.
I'm also advertising in Bitcoin in Money Share Forums / e-currency Investment Forums
http://www.moneyshareforum.com/index.php?showtopic=3513 - Bitcoin P2p Cryptocurrency, Bitcoin P2P Cryptocurrency - Free - Open Source Software Project !
Whilst I would
not recommend 'investing' in most of the 'sites' on this forum. Searching through the posts and links will give some of you an incite into just how popular e-currencies are with this type of community. This type of activity makes up a massive percentage of e-currency transactions and I consider it very relevant in the successful future of Bitcoin.
Thank you.
For those of you that don't already know; most of these 'investments' are ponzi schemes.
",
"nested_level": 0
},
{
"id": 150,
"thread_id": 19,
"source_id": "34",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg953#msg953",
"date": "2010-04-16T05:57:34Z",
"text": "For those of you that don't already know; most of these 'investments' are ponzi schemes.
Indeed they are and you should exercise extreme caution before even considering 'investing' and also view most HYIP's as a game of chance.
I can be considered a trusted admin and my Private Investment Club opportunity is intentionally 'low level' and 'low risk'.
Sabunir had expressed interest in the original BitcoinFX Private Investment Club opportunity, so I have offered a 100% free share, for my usage of the banner designs. I will offer more free shares to Bitcoin Forum members in the future.
Please understand that what I'm effectively doing is 'backing' Bitcoins with my profitable Forex Trading abilities, as well as, creating an interest and demand for Bitcoins with existing e-currency users at the same time. I have 'backed' both projects with $1000 LR to avoid any issues.
This is a much more logical approach than just offering an 'exchange' service where you are effectively just 'giving away' USD or EUR for 'digital tokens' ...
However, I fully understand your concerns.
Vekja.net Presents a Bitcoin Exclusive:
True Anonymous Web & Email Hosting
Our goal: Contribute to the Bitcoin economy and thus destroy the bankers ability to control our destiny through their printing press.
Our strategy: Provide Highly Secure Anonymous Web & Email Hosting at Cost, and provide it only through Bitcoin!
(A Vekja Account is free, and so is a Vekja Bitcoin Account once you have a general account. The Vekja Hosting Account is our first billable offering. You can choose to activate that or not, independent of your general and Bitcoin accounts.)
Sign up now and experience a 30 minute free trial of a Hosting Account.
Visit
https://vekja.net and sign up for more details!
Vekja.net Presents a Bitcoin Exclusive:
Awesome! I'll add a \"Trade\" page on the bitcoin.org main site, where we can list btc-accepting services.
hello
i found these urls while surfing on i2p:
mybitcoin.i2p (resolves to nwpqc65o333ifqq7wqovo2ito5y3ca6rfygz3p6pusau26t6tpca.b32.i2p)
xqzfakpeuvrobvpj.onion (on tor. they advertise this url in the login area)
mybitcoin.com (loads the same site from the public internet. they use cacert for ssl.)
(some sort of web-based wallet for bitcoin)
privacyshark.com
(sells domain names for bitcoins)
",
"nested_level": 0
},
{
"id": 154,
"thread_id": 19,
"source_id": "38",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1047#msg1047",
"date": "2010-05-02T19:00:39Z",
"text": "That mybc thing is nice for non-geeks. I signed up last night to try it out. This is something I can setup for my 'ol pappy and he'd be able to actually use it.
I would like to point out then that
http://vekja.net has always provided a Free web based Bitcoin account even better than the mybitcoin service mentioned above (in addition to the non-free Email and Web service that I announced earlier).
I should have announced this separately before, as there is such great value in a Bitcoin Web App. The value is not just for Grandpa, but is also for anyone who wants to use Bitcoin on a mobile device (or any platform where there is no client yet available).
If you haven't done so already, please come check out the
https://Vekja.net Bitcoin web app. Registration is free and does not require an email like the mybitcoin service currently does.
If you have any questions or suggestions, just use the built in messaging system to send a message to admin. I will be glad to help.
For the record: I hereby promise that the Vekna.net Bitcoin account will always remain free (that includes spam free). This was always my intent from the beginning.
I signed up for a vekja free Bitcoin account. Very nice. It is very simple. Almost too simple for my tastes tho. :/ I mean, I'm sure it works as expected but the interface is really lacking features.
MyBitcoin has some nice stuff like payment history, the ability to change your Bitcoin address (which I totally need btw), some basic statistics, and an addressbook (very handy; try typing in a long ugly Bitcoin address from a Blackberry or iPhone -- no thanks).
The need for an email address mystifies me also. I wonder why they require that. Service announcements?
Edit: I see a transaction history page. I must have scrolled right past it. The interface is all on one page??
Edit 2: Looks like MyBitcoin can do payment notes too (I wonder if/how this works to/from Bitcoin and MyBitcoin).
",
"nested_level": 0
},
{
"id": 157,
"thread_id": 19,
"source_id": "41",
"poster_name": "thufir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=135",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1068#msg1068",
"date": "2010-05-04T23:12:54Z",
"text": "Yes, there is a transaction history.
I was always planning an address book. I just wanted to break up the interface into multiple pages first.
I will also add the ability you request for creating new (and multiple) addresses.
Thank you for the feedback and suggestions madhatter2!
",
"nested_level": 0
},
{
"id": 158,
"thread_id": 19,
"source_id": "42",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1070#msg1070",
"date": "2010-05-05T08:55:36Z",
"text": "I just added
a second line to my graphs showing the closing price of bitcoins at the
Bitcoin Market.
Hmm.. looks like MBC has PGP-signed email payment notifications. Also looks like they don't require the email address to signup. Maybe they read this forum?
Hey! *waves @ MBC's owners* Sign up and tell us your plans!
Haha! I actually have some of my elderly family members using MBC now.
Maybe mum should get 9,000 coins for Mother's day!
I run the MMO A Tale in the Desert. We charge $13.95/month for the game, and pay about $0.74 in merchant and gateway fees.
We'll now accept Bitcoins as an alternate payment method. The price per month is 2000 BTC, which according to the exchange is a discount right now.
Instructions:
Visit
http://www.atitd.com and download the game client. Native Windows, Linux and OSX versions are available.
Install + Run the client, and create a trial character.
If you like the game, send 2000 BTC to: 17CJvRrNdqSPN3Zs2dWfNY6GoCiMRfNG2T to activate your account.
In the message field, include your character name and shard; I'll then credit you for a month of gameplay.
Right now this is done manually, so the lag could be anywhere from minutes to the next morning.
Teppy
Teppy, just so you know, you can't include a message if you send to a bitcoin address, only if you send to an IP address. The way we usually do it is we issue a new address to each person we ask to send us money so that we know it was that person who sent it.
",
"nested_level": 0
},
{
"id": 163,
"thread_id": 19,
"source_id": "47",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1161#msg1161",
"date": "2010-05-19T19:52:42Z",
"text": "Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.
",
"nested_level": 0
},
{
"id": 164,
"thread_id": 19,
"source_id": "48",
"poster_name": "teppy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=206",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1163#msg1163",
"date": "2010-05-19T22:33:33Z",
"text": "Hmm - is there any text field associated with an address based transaction? It does make accepting Bitcoins a bit more cumbersome. Would including such a text field as part of the protocol compromise anonymity somehow?
Hypothetically, a short text message could be encoded into transactions by charging, say, 2000-2000.999999 Bitcoins and encoding the text portion in the fractional part of the amount.
Or does that solve a problem that doesn't exist?
Is there already a protocol in place to say \"make me a new address to send BTC to\" ?
",
"nested_level": 0
},
{
"id": 165,
"thread_id": 19,
"source_id": "49",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1164#msg1164",
"date": "2010-05-20T02:41:51Z",
"text": "You can create new addresses all you want.. the way most people are doing this is they generate a new address for the user and display it to them. When payment is received to that address it credits the user. You can just generate a new address for each transaction, like a transaction ID essentially. Link2VOIP automated it all and some others have as well, simply by using the built in JSON-RPC functionality.
Satoshi would have to address the other questions about including messages..
",
"nested_level": 0
},
{
"id": 166,
"satoshi_id": 106,
"thread_id": 19,
"source_id": "50",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: We accept Bitcoins",
"url": "https://bitcointalk.org/index.php?topic=30.msg1169#msg1169",
"date": "2010-05-20T21:43:42Z",
"text": "Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.
Almost but not quite. Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn't use it because it's an order of magnitude bigger and would have been impractical.
1) What would happen if one attempts to send an amount of coins to an IP address that isn't running the program?
2) What would happen if one attempts to send an amount of coins to a invalid Bitcoin Address?
3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?
4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?
I thank answerers for expanding my knowledge.
",
"nested_level": 0
},
{
"id": 168,
"thread_id": 20,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Questions about Addresses",
"url": "https://bitcointalk.org/index.php?topic=34.msg187#msg187",
"date": "2010-02-01T10:44:43Z",
"text": "1) What would happen if one attempts to send an amount of coins to an IP address that isn't running the program?
2) What would happen if one attempts to send an amount of coins to a invalid Bitcoin Address?
Not possible, the software doesn't allow that.
3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?
4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?
I guess the money will just be lost in that case.
What happens to Bitcoins sent to an IP address where the sub-net computers are each running Bitcoin software ?
Do they all receive an equal share of Bitcoins ? lol
![\"Roll](\"/static/img/emoticons/rolleyes.gif\"/)
If I remember correctly I think I was told that they would be sent to the first bitcoin application with whom the sender connects.
",
"nested_level": 0
},
{
"id": 171,
"thread_id": 20,
"source_id": "5",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: Questions about Addresses",
"url": "https://bitcointalk.org/index.php?topic=34.msg198#msg198",
"date": "2010-02-02T01:36:13Z",
"text": "Relatedly, what protections are in place for preventing someone from forging a Bitcoin Address?
",
"nested_level": 0
},
{
"id": 172,
"thread_id": 20,
"source_id": "6",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Questions about Addresses",
"url": "https://bitcointalk.org/index.php?topic=34.msg199#msg199",
"date": "2010-02-02T02:34:26Z",
"text": "What happens to Bitcoins sent to an IP address where the sub-net computers are each running Bitcoin software ?
The coins go to the machine that the sender connects to. You need to do port forwarding to direct the incoming connections at port 8333 to the correct subnet address. Instructions:
www.portforwarding.com.
Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine.
However, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !
Bitcoin node (1) 192.168.0.2
Bitcoin node (2) 192.168.0.3
So, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?
Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine.
However, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !
Bitcoin node (1) 192.168.0.2
Bitcoin node (2) 192.168.0.3
So, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?
The connection won't get through at all if the port is not forwarded.
Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine.
However, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !
Bitcoin node (1) 192.168.0.2
Bitcoin node (2) 192.168.0.3
So, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?
The connection won't get through at all if the port is not forwarded.
Not so ? I have had 2 machines connected (getting 4+ connections on each) and generating Bitcoins on the same static IP address. The port 8333 is of course forwarded for connection through my firewall, which I guess is what you mean. However, connections to other nodes are made without port 8333 being specifically forwarded through my router to a specific machine (sub-net IP), which is of course the best way to max connectivity. I understand Bitcoin only requires 1 other connection for transactions, yes ?
I think my original question was valid and thanks for clarifying this everyone. NewLibertyStandard I think is correct \"If I remember correctly I think I was told that they would be sent to the first bitcoin application with whom the sender connects.\"
I dislike communication on forums, it's hard to discuss topics sometimes when all parties mean the same thing and communicate it in a different way !
I have enough internet connections, routers and PC equipment - So, I'm off to make an 'official' test for myself whilst I RTM
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 computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent. When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.
Someone should post their static IP so people can try out sending by IP and also give that user free money.
There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.
If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost. A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka \"natural deflation\".
",
"nested_level": 0
},
{
"id": 177,
"thread_id": 20,
"source_id": "11",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Questions about Addresses",
"url": "https://bitcointalk.org/index.php?topic=34.msg227#msg227",
"date": "2010-02-04T09:48:34Z",
"text": "Someone should post their static IP so people can try out sending by IP and also give that user free money.
Thanks for clarifying that satoshi.
I'm more than happy to share my static IP for testing - I run a Tor Relay from this IP so the address is already publicly available at
http://trunk.torstatus.kgprog.com/ for example.
Please note that this is
not the IP address from where I will be running my 'Bitcoin Bank' / exchange service. It's a personal IP address and is effectively my project contribution and testing 'Lab' for other open source projects. I'm a big contributor of Grid Republic etc.
*** N.B. Post has been edited after the successful testing ***
Anyone is still welcome to make a test payment to my IP.
Please send me a forum PM first and stipulate in the comments if you are making a test payment or a donation, so that I can return your Bitcoins to you, if you wish. Any donations will be much appreciated and will help to set up the separate 'exchange service' faster.
Please email:
bitcoinfx @ gmail.com regarding any issues. (EDIT: no longer in use 2014)
You can also visit my website: BitcoinFX -
http:// www .bitcoinfx .cz.cc EDIT: Domain no longer active - An early manual e-currency exchange by email only - the domain only provided contact info. etc.
Thank you.
2x 0.01 BTC sent.
0.01 BTC per Bitcoin adress and 0.01 BTC per IP-adress.
I don't need it back
BTW:
http://trunk.torstatus.kgprog.com/ is telling me I'm using TOR, but I`m not. It shows my real IP.
Thanks SmokeTM.
Both Micro donations were successfully received.
3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?
4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?
I guess the money will just be lost in that case.
Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?
Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?
That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it.
It's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost.
I wanted to document an issue I encountered when first installing and using the Bitcoin software.
Despite a correct installation and port forward settings I noticed that Bitcoin was not generating any coins or 'blocks' despite having 20+ connections for the first 24hrs. The block count just remained at 0. After realizing that Bitcoin was not 'catching up' with the collective network block download or generation I opened up the Task Manager to investigate the issue further.
I noticed that the bitcoin.exe process seemed to be 'fighting' for CPU usage against MsMpEng.exe (Microsoft Security Essentials). I hadn't noticed any system slowdown due to having a fairly high spec. PC. After adding bitcoin.exe and the appropriate program folder locations to Exclude 'Files and Locations' and 'Exclude Processes' - Bitcoin instantly started generating blocks and the CPU processes returned to normal.
I did not have any virus alerts or even 'false positive' identifications for Bitcoin. I know that the software is 100% OK. I'm assuming that the 'Live Protection' engine in Microsoft Security Essentials just doesn't 'play well' with some aspect of the CPU hungry cycles used in 'block' generation.
I have yet to do more testing, however I also encountered the same issue when using Comodo Internet Security (free version).
This is obviously going to be an issue for lots of new Bitcoin users who will perhaps be less 'tech savvy'. Has anyone else encountered any similar issues ?
",
"nested_level": 0
},
{
"id": 183,
"satoshi_id": 40,
"thread_id": 21,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Win32 CPU Cycles vs 'Live Protection' Engines ?",
"url": "https://bitcointalk.org/index.php?topic=35.msg220#msg220",
"date": "2010-02-03T23:36:54Z",
"text": "Thanks for that. Which version of Windows?
",
"nested_level": 0
},
{
"id": 184,
"satoshi_id": 43,
"thread_id": 22,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg249#msg249",
"date": "2010-02-05T19:19:12Z",
"text": "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 year, we were hovering below the minimum. On 30 Dec we broke above it and the algorithm adjusted to more difficulty. It's been getting more difficult at each adjustment since then.
The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year. That means you generate only 55% as many coins for the same amount of work.
The difficulty adjusts proportionally to the total effort across the network. If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.
For those technically inclined, the proof-of-work difficulty can be seen by searching on \"target:\" in debug.log. It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block. It gets adjusted every 2016 blocks, typically two weeks. That's when it prints \"GetNextWorkRequired RETARGET\" in debug.log.
minimum 00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000
date, difficulty factor, % change
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%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
05/08/2010 352.17 +44%
15/08/2010 511.77 +45%
26/08/2010 623.39 +22%
",
"nested_level": 0
},
{
"id": 185,
"satoshi_id": 58,
"thread_id": 22,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg346#msg346",
"date": "2010-02-15T06:28:38Z",
"text": "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 1.82 times to 2.53 times, a 39% increase since 10 days ago. It was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time.
",
"nested_level": 0
},
{
"id": 186,
"thread_id": 22,
"source_id": "3",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg361#msg361",
"date": "2010-02-16T02:15:49Z",
"text": "[Edit: I later found that I was generating quite a bit more than that, just didn't realize it because of the \"matures in xx more blocks\" concept. I still think it will be a major headache when the difficulty significantly increases though. I apologize for my silliness
]
Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create \u0e3f50.00! With older PCs it will take forever. People like to feel that they \"own\" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making \u0e3f50 every 20 hours, make \u0e3f5 every 2 hours?
I don't know if that means reducing the block size or reducing the 120-block threshold to say 12-block only or what, but because the difficulty is increasing I can imagine that a year from now the situation will be even worse (3+ weeks until you see the first spendable coins!) and we better find a solution for this ASAP.
I would like to comment that as of late, it seems almost as if I am generating nearly no Bitcoins. Indeed, my rate of acquisition seems to be greater than ten times slower. If I cannot stay online for about fourteen consecutive hours (very hard to do on a satellite connection!), I actually get nothing at all.
How this exactly relates to the difficulty adjustments is beyond my knowledge; I offer this feedback as a kind of \"field report\".
",
"nested_level": 0
},
{
"id": 188,
"thread_id": 22,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg371#msg371",
"date": "2010-02-16T06:01:51Z",
"text": "I generated 5 blocks today on my Pentium processor. Two of them were within 3 minutes of each other.
I have noticed some slowdown since the adjustment, but I still generate a lot of coins. My computer is off while I'm sleeping, and BitCoin bootstraps quickly when I turn it back on. Do you guys-who-are-having-trouble have the BitCoin port open?
",
"nested_level": 0
},
{
"id": 189,
"thread_id": 22,
"source_id": "6",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg372#msg372",
"date": "2010-02-16T08:51:51Z",
"text": "My port is open, both in my software and hardware firewall. My router is handling it appropriately. Perhaps it has to do with my connection's very high latency (2000ms or more on average) and/or my high packet loss (sometimes up to 10% loss)?
",
"nested_level": 0
},
{
"id": 190,
"satoshi_id": 60,
"thread_id": 22,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg376#msg376",
"date": "2010-02-16T17:36:40Z",
"text": "Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create \u0e3f50.00! With older PCs it will take forever. People like to feel that they \"own\" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making \u0e3f50 every 20 hours, make \u0e3f5 every 2 hours?
I thought about that but there wasn't a practical way to do smaller increments. The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.
The algorithm aims for an average of 6 blocks per hour. If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long. It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.
If I cannot stay online for about fourteen consecutive hours (very hard to do on a satellite connection!), I actually get nothing at all.
Can Satoshi confirm whether the computations your machine had made carries on if the session was interrupted, or do you need to start all over if you disconnected before generating at least one block? If it carries on, maybe a little meter indicating the % left until your block completes can be a nice addition so people would have some hope (actually, it will be a nice addition anyway whether the computations get carried on after disconnection or not!)
I generated 5 blocks today on my Pentium processor. Two of them were within 3 minutes of each other.
Ok, I just realized that I didn't understand how Bitcoin worked to begin with. The blocks get generated anyway whether you're generating coins or not. The average amount of creation conformed what I observed before (120/20 hrs, or 6/hr). This has got absolutely nothing to do with your CPU power, it's constant for all practical purposes. The CPU power determines the \"transactions\" that get created and \"matures in xx blocks\". My head just got a bit bigger now
This also means theymos that there was probably a coincidence or error for your 3-minute interval observation!
. Perhaps it has to do with my connection's very high latency (2000ms or more on average)
2 seconds of latency in both directions should reduce your generation success by less than 1%.
and/or my high packet loss (sometimes up to 10% loss)?
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 you're connected to until received. If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap. Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.
How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?
",
"nested_level": 0
},
{
"id": 194,
"thread_id": 22,
"source_id": "11",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg425#msg425",
"date": "2010-02-21T18:52:43Z",
"text": "How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?
My understanding is that every Bitcoin client has the same algorithm (formula) built into it to automatically adjust the difficulty every so many blocks. Not only that, but I think that Bitcoin will not accept blocks generated at a different difficulty, so if a modified Bitcoin client tried to send out more easily generated blocks, all the authentic clients would reject the fake blocks.
The automatic adjustment happened earlier today.
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
24/02/2010 3.78 +49%
I updated the first post.
",
"nested_level": 0
},
{
"id": 196,
"thread_id": 22,
"source_id": "13",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg533#msg533",
"date": "2010-02-25T04:34:59Z",
"text": "How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?
My understanding is that every Bitcoin client has the same algorithm (formula) built into it to automatically adjust the difficulty every so many blocks.
Then how is it dependent on how many CPU's are connected to the whole network?
Not only that, but I think that Bitcoin will not accept blocks generated at a different difficulty, so if a modified Bitcoin client tried to send out more easily generated blocks, all the authentic clients would reject the fake blocks.
We need Satoshi to confirm that because clients accept blocks generated at easier difficulties all the time whenever the PoW's difficulty increases.
The formula is based on the time it takes to generate 2016 blocks. The difficulty is multiplied by 14/(actual days taken). For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49. Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.
I don't know what you're talking about accepting easier difficulties.
",
"nested_level": 0
},
{
"id": 198,
"thread_id": 22,
"source_id": "15",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg541#msg541",
"date": "2010-02-26T01:35:08Z",
"text": "I don't know what you're talking about accepting easier difficulties.
We were essentially discussing Sabunir's question about what prevents someone from messing with the program's source code to adjust block-generating difficulty to be very easy, then make a network on his own and create a, say, 50,000-block proof-of-work within seconds then finally propagate it across the real network to steal \"votes\" towards his new fake blocks as technically, his proof would be \"the longest\". So is there a way to verify how much work was actually put into a given PoW (for eg. how many zero's are at the beginning of each hash or something)?
It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.
Since we're at it, what's the approximate time for proof-of-work propagation across a network of about 100,000 machines? Is there a way to optimize connections so that broadcasting is done via a pyramid-form to minimize the needed time? For example, the block creator sends it to 10 nodes, then those 10 send it to a 100 provided that none of those 100 were among the original 11, then those 100 tell a 1000 provided that none of those 1000 were among the original 111, etc to save time.
This overclocked i7 still hasn't generated any keys after 8 hours...
",
"nested_level": 0
},
{
"id": 200,
"thread_id": 22,
"source_id": "17",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg550#msg550",
"date": "2010-02-26T07:03:09Z",
"text": "This overclocked i7 still hasn't generated any keys after 8 hours...
It may take longer than 8 hours to generate a block.
Have you previously generated bitcoins? Are the number of blocks listed at the bottom of Bitcoin greater than 42650? Those need to download before it can start generating coins. How many connections are listed at the bottom of Bitcoin? Did you click Options > Generate Coins? How much CPU does your process viewer show that Bitcoin is using? Is your Internet connection steady? I had problems when I tried sharing Internet from my smartphone to my computer.
This overclocked i7 still hasn't generated any keys after 8 hours...
It may take longer than 8 hours to generate a block.
Have you previously generated bitcoins? Are the number of blocks listed at the bottom of Bitcoin greater than 42650? Those need to download before it can start generating coins. How many connections are listed at the bottom of Bitcoin? Did you click Options > Generate Coins? How much CPU does your process viewer show that Bitcoin is using? Is your Internet connection steady? I had problems when I tried sharing Internet from my smartphone to my computer.
No, but..42663 blocks..8 connections..and yes, generating. Bitcoin uses 50-80 CPU..but it only has access to two cores until I bump the VM it is in to 4 cores..Operating over tor by the way.
I think that no bitcoins generated in 8 hours from within a VM utilizing two modern cores is probably not unusual. Keep it running for a few days and I expect that you'll generate more than a few packs of bitcoins.
",
"nested_level": 0
},
{
"id": 203,
"thread_id": 22,
"source_id": "20",
"poster_name": "Legion",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=48",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg560#msg560",
"date": "2010-02-26T22:09:19Z",
"text": "I wonder what I could generate with all eight threads...
",
"nested_level": 0
},
{
"id": 204,
"thread_id": 22,
"source_id": "21",
"poster_name": "dmp1ce",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=171",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1046#msg1046",
"date": "2010-05-02T17:46:13Z",
"text": "I don't know what you're talking about accepting easier difficulties.
We were essentially discussing Sabunir's question about what prevents someone from messing with the program's source code to adjust block-generating difficulty to be very easy, then make a network on his own and create a, say, 50,000-block proof-of-work within seconds then finally propagate it across the real network to steal \"votes\" towards his new fake blocks as technically, his proof would be \"the longest\". So is there a way to verify how much work was actually put into a given PoW (for eg. how many zero's are at the beginning of each hash or something)?
I am also wondering about Suggester's question. It seems like modifying the code to give a node an advantage in generating coins might be possible.
I am confused as to why each node on the network is actually doing when set to generate coins. What problem are they solving that takes 100% CPU?
Your CPU is creating SHA-256 hashes. It's not possible to cheat: if the hashes you create are invalid, no one else in the network will accept them. If you inject a 50,000-block chain of \"easy blocks\" into the network, everyone will immediately see that the hash for the first block in the chain is above the current target and ignore it and every block derived from it.
",
"nested_level": 0
},
{
"id": 206,
"thread_id": 22,
"source_id": "23",
"poster_name": "fergalish",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=39",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1111#msg1111",
"date": "2010-05-11T12:12:08Z",
"text": "Interestingly, using laszlo's mac os version of bitcoin, one can see how many hashes per second the computer is performing. I'm currently getting about 1 million hashes per second. Given the current difficulty 0000000013ec53, I'll have to perform about 2^35~3x10^10 hashes before I have a decent chance of getting one below the target, and at 10^6/s, that should take about 30000 sec, or about two per day. The actual interval varies a lot - it's a random process, but that seems to be more-or-less the correct amount.
Satoshi, could you update the first post in this thread, with the complete history of difficulty-of-work increases please? I'd try, but for some reason, I've lost my logfiles. Fortunately the wallet is safe.
",
"nested_level": 0
},
{
"id": 207,
"thread_id": 22,
"source_id": "24",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1112#msg1112",
"date": "2010-05-11T13:13:07Z",
"text": "Maybe someone with a little background in this statistics/math stuff can shed some light on this..
The way this thing works is it takes a (basically random) block of data and alters a 32 bit field inside it by starting at 1 and incrementing. The block of data also contains a timestamp and that's incremented occasionally just to keep mixing it up (but the incrementing field isn't restarted when the timestamp is update). If you get a new block from the network you sort of end up having to start over with the incrementing field at 1 again.. however all the other data changed too so it's not the same thing you're hashing anyway.
The way I understand it, since the data that's being hashed is pretty much random and because the hashing algorithm exhibits the 'avalanche effect' it probably doesn't matter if you keep starting with 1 and incrementing it or if you use pseudo random values instead, but I was wondering if anyone could support this or disprove it.
Can you increase your likelihood of finding a low numerical value hash by doing something other than just sequentially incrementing that piece of data in the input? Or is this equivalent to trying to increase your chances of rolling a 6 (with dice) by using your other hand?
",
"nested_level": 0
},
{
"id": 208,
"thread_id": 22,
"source_id": "25",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1113#msg1113",
"date": "2010-05-11T21:50:51Z",
"text": "The way I understand it, since the data that's being hashed is pretty much random and because the hashing algorithm exhibits the 'avalanche effect' it probably doesn't matter if you keep starting with 1 and incrementing it or if you use pseudo random values instead, but I was wondering if anyone could support this or disprove it.
Yep, your understanding here is correct. It does not matter what exactly gets hashed, and no, you can't cheat without first breaking SHA-256, which is considered difficult.
The salient property of cryptographic hash functions is that they are as random as is possible while still being deterministic. That's what their strength depends on -- after all if they weren't random, if there were obvious patterns, they could be broken that way. So the ideal hash function behaves just like a random number generator. It does not matter what you feed in, timestamp or not, whatever's put in there, the hash should still behave randomly (i.e. every possible outcome has the same a-priori probability of occuring). Incrementing by one works just as well as completely changing everything every step (this follows from the avalanche property). However, the initial value, before you start incrementing, must be (pseudo-)randomly chosen, or every computer will start at the same point, and the fastest one always wins, which is not what is wanted here.
A nice addition to the GUI would be an estimate of how many hashes/sec it's computing. Either present this as a raw number or a \"you can expect to generate X packs of bitcoins per week.\"
This might partially solve the frustration of new users not getting any Bitcoins right away.
",
"nested_level": 0
},
{
"id": 210,
"satoshi_id": 115,
"thread_id": 22,
"source_id": "27",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1323#msg1323",
"date": "2010-06-02T18:45:38Z",
"text": "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 public key in its block, so they're guaranteed to be scanning different territory.
Whenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer.
",
"nested_level": 0
},
{
"id": 211,
"thread_id": 22,
"source_id": "28",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1327#msg1327",
"date": "2010-06-02T23:21:14Z",
"text": "I created a little performance counter for myself to use locally, you guys are welcome to try it.
Satoshi, maybe you could integrate this or something similar and put an option in there to turn it on/off? It spams up your debug.log and shows the performance of each thread.. it also shows on the UI in the status bar where it used to say 'Generating'.
Patch:
http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patchScreenshot:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fheliacal.net%2F%7Esolar%2Fbitcoin%2Fbcgen3.jpg&t=589&c=5xBkAUPAh08o0g\"/)
Can someone share the math required to compute the estimated amount of time to generate a pack of bitcoins?
Basically, a formula that integrates the difficulty (either as a hex number (currently 000000000f675c00000000000000000000000000000000000000000000000000) or as the difficulty factor (currently 16.62)) and number of hashes checked per second (currently like 1M for me) which would return the average time between blocks found?
",
"nested_level": 0
},
{
"id": 213,
"thread_id": 22,
"source_id": "30",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1347#msg1347",
"date": "2010-06-04T05:31:31Z",
"text": "chancePerHash=target/max
numberOfHashesToWin=0.5/chancePerHash
numberOfSecondsToWin=numberOfHashesToWin/hahesPerSecond
(0.5/(target/max))/hashesPerSecond
(0.5/(0x000000000f675c00000000000000000000000000000000000000000000000000/0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff))/1000000
=
35689 seconds
About one block per 9.9 hours. Does this match your observations? I'm not totally sure about the math.
Sounds completely reasonable. I just started generating today, so I'll let you know once I get more blocks. Thanks!
",
"nested_level": 0
},
{
"id": 215,
"thread_id": 22,
"source_id": "32",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1359#msg1359",
"date": "2010-06-05T02:38:14Z",
"text": "Laszio, I've remade your patch to spam the debug log less (1/10th as often). I also the extended JSON-RPC library to add \"gethps\" (which returns the same string displayed in the UI). It also adds listgenerated, which returns a list of the strings from the UI representing generated blocks. In the third and final patch, I modified net.h to compile with -O2 on my machine (which it wouldn't before).
Here are the patches:
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-perfcounter-less-debug-spam-2010-06-05.patch <- Apply Laszio's patch first, then this one.Sorry, that patch ^^ is completely broken. The changes are trivial (the same line in 3 places), but I failed at diffing. I'll upload a better patch when I have time.
http://www.alloscomp.com/bitcoin/bitcoin-svn-80-rpcextended-2010-06-05.patchhttp://www.alloscomp.com/bitcoin/bitcoin-svn-80-netpatch-2010-06-05.patchThanks to Laszio for the original performance patch.
Cool, I was just playing around with trying to make it adjust the rate without taking much of a performance hit.. that's why it tries to adjust that variable, to keep it to a few per second or so.. maybe you can figure out a better formula, I just kind of did that by experimenting around with it.
",
"nested_level": 0
},
{
"id": 217,
"thread_id": 22,
"source_id": "34",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1363#msg1363",
"date": "2010-06-05T06:15:52Z",
"text": "About one block per 9.9 hours. Does this match your observations? I'm not totally sure about the math.
My system has jumped up to about 1200 khps. Also, I got Bitcoin running on a VPS which is giving about 2350 khps. The formula which you posted (and I arrived at myself later) predicts a block every 8.2 hours for my laptop and one every 4.2 hours for the VPS. Since I started yesterday afternoon, I've only generated the one block.
Sound strange? Or am I just having bad luck?
The main part of the formula that I'm uneasy about is the \"target probability\" of 0.5. 0.5 is used for calculations involving brute-forcing passwords, but maybe this is different. If your blocks consistently take double the amount of time that the formula predicts, use 1 instead.
",
"nested_level": 0
},
{
"id": 219,
"thread_id": 22,
"source_id": "36",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1371#msg1371",
"date": "2010-06-05T15:28:29Z",
"text": "The main part of the formula that I'm uneasy about is the \"target probability\" of 0.5. 0.5 is used for calculations involving brute-forcing passwords, but maybe this is different. If your blocks consistently take double the amount of time that the formula predicts, use 1 instead.
I thought about that. I don't know if 0.5 is valid or not. I'll continue to take observations. I wonder if it writes to the debug log when it has success.
Actually, that formula assumes that you're working on one block until you figure it out. In Bitcoin, aren't multiple nodes working on the same block? When one finishes, the others abandon work on it and choose another block? That was the impression that I had, but it might be wrong.
I wonder if it writes to the debug log when it has success.
BitCoin does say when it has solved a block. Search for \"proof-of-work found\".
In Bitcoin, aren't multiple nodes working on the same block?
No. Each node's block is unique because it contains their unique public key. Functionally, every hash gives you a totally random number between 0 and the maximum value of a 256-bit number. If the random number is equal to or below the target, you win. So the probability of winning with one hash is
target in
max.
Starting on another block because somebody else won requires almost no work.
See the BitCoin Wiki
\"block\" article and the
BitCoin paper for more info.
I thought about that. I don't know if 0.5 is valid or not. I'll continue to take observations. I wonder if it writes to the debug log when it has success.
Use a value of 1, not 0.5. Suppose max=100 and target=10, then 10 out of every 100 hashes will be at or below the target, so your success rate will be 10% NOT 5%.
At the moment target/max ~= 1.5x10^-11 (target~=0x000000000f, which is 36 zeros, so you basically need to throw a dice with 2^36=69 billion sides, and wait until you get a 1), and you're doing 1 million x 86400 = 86.4 billion hashes per day, so you can expect slightly more than one success per day.
It's VERY important to realise that this is the AVERAGE bitcoin creation time, and will only be valid over periods longer than about a week or so. Because a success event is completely random (I hope, otherwise the hash function is probably not secure and someone will eventually crack it, and therefore bitcoin!), the interval between one success and the next will follow a Poisson distribution with n=0, i.e. an exponential (see wikipedia). Therefore, with an average rate of, say, 1 success per day, you can expect that roughly 10% of the time, you'll have to wait 2\u00bc days or more, 1% of the time 4\u00bd days, 0.1% 7 days and so on.
Thanks for clearing that up, fergalish!
",
"nested_level": 0
},
{
"id": 223,
"satoshi_id": 132,
"thread_id": 22,
"source_id": "40",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1648#msg1648",
"date": "2010-06-21T18:09:17Z",
"text": "I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar.
Two new log messages:
21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s
21/06/2010 01:23 generated 50.00
grep your debug.log for \"generated\" to see what you've generated, and grep for \"hashmeter\" to see the performance. On windows, use:
findstr \"hashmeter generated\" \"%appdata%\\bitcoin\\debug.log\"
I have the hashmeter messages once an hour. How often do you think it should be?
",
"nested_level": 0
},
{
"id": 224,
"thread_id": 22,
"source_id": "41",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg1667#msg1667",
"date": "2010-06-22T16:04:46Z",
"text": "How about in the options menu you can turn it off or on, and specify an interval in minutes for how often it should display?
I say keep it simple; more choices isn't always better, it just makes it overwhelming and confusing for most users.
Agree. Certainly too trivial to clutter the user's attention with.
I changed it to every 30 minutes.
If I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep.
",
"nested_level": 0
},
{
"id": 226,
"thread_id": 22,
"source_id": "43",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg2543#msg2543",
"date": "2010-07-13T12:52:22Z",
"text": "\"difficulty\" : 45.38582234101263
It jumped from 23 in a couple days. I think this pretty much puts an end to generating a block a day with a personal computer.. but you can still get lucky. Now you'll need to build a cluster or hijack a college computer lab for it to be worth doing
I expect the trading value will increase significantly over the next few weeks as the supply slows down; should be interesting.
The probability of winning per hash went from 9.90701E-12 to 5.12995E-12. So about double the difficulty.
",
"nested_level": 0
},
{
"id": 228,
"thread_id": 22,
"source_id": "45",
"poster_name": "gould",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=348",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg2654#msg2654",
"date": "2010-07-13T21:30:59Z",
"text": "I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.
",
"nested_level": 0
},
{
"id": 229,
"thread_id": 22,
"source_id": "46",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg2660#msg2660",
"date": "2010-07-13T21:49:33Z",
"text": "I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.
You can use the calculator at:
http://www.alloscomp.com/bitcoin/calculator.phpIf this is a feature request post in the Development & Technical Discussion Forum:
http://bitcointalk.org/index.php?board=6.013/07/2010 0000000005a3f437d4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a
",
"nested_level": 0
},
{
"id": 231,
"satoshi_id": 210,
"thread_id": 22,
"source_id": "48",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3488#msg3488",
"date": "2010-07-16T14:46:12Z",
"text": "The proof-of-work difficulty is currently 45.38. (see
http://www.alloscomp.com/bitcoin/calculator.php)
It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
The proof-of-work difficulty is currently 45.38. (see
http://www.alloscomp.com/bitcoin/calculator.php)
It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
Holy....
Satoshi, what happens if the rush dries up for a bit; some of the slashdotters or whoever get tired? Does the difficulty ever go back down?
The proof-of-work difficulty is currently 45.38. (see
http://www.alloscomp.com/bitcoin/calculator.php)
It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.
Holy....
Satoshi, what happens if the rush dries up for a bit; some of the slashdotters or whoever get tired? Does the difficulty ever go back down?
If I'm reading the source code correctly, it should go up and down based on how much CPU is being thrown at it. So if someone rented a super computer to drive up the difficulty for a week, then it vanished, the difficulty should float back down.
It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.
The difficulty can adjust down as well as up.
The network should be generating close to 6 blocks per hour now.
",
"nested_level": 0
},
{
"id": 235,
"thread_id": 22,
"source_id": "52",
"poster_name": "RudeDude",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=481",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3527#msg3527",
"date": "2010-07-16T16:59:04Z",
"text": "I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.
I think the web c alc does a good job by showing likelyhoods based on khash speed:
http://www.alloscomp.com/bitcoin/calculator.phpThat way you can see there is no guaranteed time horizon.
It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.
The difficulty can adjust down as well as up.
The network should be generating close to 6 blocks per hour now.
Yeah, I've noticed the \"10 second blocks\" are gone, replaced with 419 and 741 second block generation with no more in the last 20 minutes. That should keep those server farms on hold for a while
Now, correct me if I'm wrong, but now that block generation is taking a lot longer, doesn't that mean that the lucky person who got the block is going to take a lot longer to be verified by the network that he/she was the winner before they could ever spend it?
Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You know long before that that you won one.
",
"nested_level": 0
},
{
"id": 238,
"thread_id": 22,
"source_id": "55",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3538#msg3538",
"date": "2010-07-16T17:33:57Z",
"text": "Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You'll know long before that that you won one.
So if the difficulty was increased so high that it took a day to find a winning block, that means the lucky winner would have to wait 120 day before they could spend it or about 4 months if everyone else was averaging about the same speed? Seems like at the high end of the difficulty, there is an issue with coin generation vs. being able to put it into circulation by spending. Wouldn't the long delay cause a lot of generated coin to be lost because anything could happen to the PC that won in a long amount of time if the winner had to really wait that long? They might un-install the program or the computer get eaten by a virus or power surge well before then.
Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You'll know long before that that you won one.
So if the difficulty was increased so high that it took a day to find a winning block, that means the lucky winner would have to wait 120 day before they could spend it or about 4 months if everyone else was averaging about the same speed? Seems like at the high end of the difficulty, there is an issue with coin generation vs. being able to put it into circulation by spending. Wouldn't the long delay cause a lot of generated coin to be lost because anything could happen to the PC that won in a long amount of time if the winner had to really wait that long? They might un-install the program or the computer get eaten by a virus or power surge well before then.
I think that the overall network is generating the same amount of blocks regardless of the difficulty; the difficulty is intended so that the network generates a block in a relatively constant amount of time. Therefore, this confirmation time should always be around the same.
Satoshi or anyone else can correct me if I'm wrong
Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.
The recent adjustment put us back to close to 6 blocks per hour again.
There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
http://nullvoid.org/bitcoin/statistix.phpAh ok, cool. I continue to be astounded by how much thought was put into this system to keep it balanced, nice job!
",
"nested_level": 0
},
{
"id": 242,
"thread_id": 22,
"source_id": "59",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3631#msg3631",
"date": "2010-07-17T01:31:32Z",
"text": "Now, correct me if I'm wrong, but now that block generation is taking a lot longer, doesn't that mean that the lucky person who got the block is going to take a lot longer to be verified by the network that he/she was the winner before they could ever spend it?
No, this isn't correct. Finding the hash requires a whole bunch of effort, but the process of verification that the \"winner\" has found a matching block is by comparison a trivial exercise and doesn't take all that long. Once they have found the block, they can spend those coins right away.
What this does mean is that the coin allocation system has now become a lottery, where new winners are receiving a block of coins worth a whole lot more (due to exchange rates and scarcity) than earlier blocks which were in comparison relatively trivial in value. My question is, how valuable will this \"lottery\" become in the long run (in terms of Euros or Dollars per block generated)?
Essentially what is happening is that the computer is picking a random sequence of numbers (like a lottery) and if that computer happens to pick the correct sequence of bits, you \"win\". The change in difficulty is something akin to playing a lottery that has you only picking six numbers vs. one with fourteen or a hundred numbers to win. The odds are actually worse for a bitcoin block than even the worst of any normal lottery that has ever been conceived at the moment.
In the Economy subforum, I have just written a post titled \"Get rid of 'difficulty' and maintain a constant rate\" which outlines a scheme which a new version of the BitCoin software could use to keep the rate of block generation absolutely constant at the cost of a slight increase in network traffic.
I would be very grateful for your comments.
ByteCoin
",
"nested_level": 0
},
{
"id": 244,
"thread_id": 22,
"source_id": "61",
"poster_name": "ichi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=316",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3740#msg3740",
"date": "2010-07-17T13:41:26Z",
"text": "I value Bitcoin as an anonymous digital currency. Although I'm not expecting to get rich, I'd like the ability to continuously generate enough Bitcoin to purchase desired services.
Is there any expectation that economic value per khash/sec (or client) per day will be at least somewhat stable? Difficulty just increased 300%, and USD/Bitcoin just increased about 500% (although that may turn out to be a spike). I do get that there's no necessary relationship. However, perhaps there's an economic basis for one (however approximate it might be).
",
"nested_level": 0
},
{
"id": 245,
"thread_id": 22,
"source_id": "62",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Proof-of-work difficulty increasing",
"url": "https://bitcointalk.org/index.php?topic=43.msg3743#msg3743",
"date": "2010-07-17T13:45:19Z",
"text": "I value Bitcoin as an anonymous digital currency. Although I'm not expecting to get rich, I'd like the ability to continuously generate enough Bitcoin to purchase desired services.
Is there any expectation that economic value per khash/sec (or client) per day will be at least somewhat stable? Difficulty just increased 300%, and USD/Bitcoin just increased about 500% (although that may turn out to be a spike). I do get that there's no necessary relationship. However, perhaps there's an economic basis for one (however approximate it might be).
Try the
Bitcoin Economics ForumYou should be able to find many discussions about this topic there.
This thread is about the proof of work difficulty number.
New difficulty factor 244.213223092
+35%
I updated the first post.
date, difficulty factor, % change
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%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
",
"nested_level": 0
},
{
"id": 247,
"thread_id": 23,
"source_id": "1",
"poster_name": "BlueSky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=34",
"subject": "How divisible are bitcoins and other market/economic questions",
"url": "https://bitcointalk.org/index.php?topic=44.msg252#msg252",
"date": "2010-02-06T09:36:45Z",
"text": "How divisible are bitcoins? Can I divide a bitcoin? as in could I spend 0.5 or 0.01 of a bitcoin?
I ask this question as practically the production of new bitcoins is finite & will become too expensive in terms of time & power in the future and if the system becomes more popular there will be more goods than BC's.
What about dwindling supply?
The current supply will eventually begin to dwindle as people lose their wallet's(removing coins from the system) & governments attempt to drain coins out (either by scamming or creating coins themselves and simply hoarding them)of the system. This is inevitable (government action against BC) as no government worldwide will allow the existence of such an anonymous currency system out of their control or supervision.
What about the need for banks?
Actually I don't think there would be a need for banks to get interest on savings, simply holding onto BC's they will increase in value as more users come into the system. So technically you'll get interest just for keeping them under your bed.
How are BC's valued(this is more of a question for NewLibertyStandard)?
As I see it(thusfar) the value of bitcoins(as in their exchange rate or the goods they can buy) is not in how much energy/time it takes to create them (this simply ensures a limited supply) but that they are accepted for goods & services.
The more goods & services that can be bought with BC the less coins it will require per good.
For example there are 2 Million BC in existence, and only one person accepts BC, & is willing to sell a single t-shirt. Then the BC value of that shirt is 2Million BC, if it we're 2 t-shirts then each shirt would cost 1Million and so forth.
Of coarse this may never happen exactly like this, a person would look at the electricity cost of making 2Million BC's(in lets say US$) and the cost of buying the t-shirt(again in US$). If it costs $100 of electricity to make 2Million BC's then of coarse the customer will just use US$ and pay $10 for the t-shirt.
",
"nested_level": 0
},
{
"id": 248,
"thread_id": 23,
"source_id": "2",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: How divisible are bitcoins and other market/economic questions",
"url": "https://bitcointalk.org/index.php?topic=44.msg254#msg254",
"date": "2010-02-06T12:21:07Z",
"text": "Bitcoins are divisible by 100. So when you generate \u0e3f50.00, you are getting 5000 bitcoin cents.
The
New Liberty Standard Exchange Rate includes an explanation of how it is calculated. BlueSky, how much are you willing to sell your bitcoins for and how much are you willing to pay for someone else's bitcoins?
Bitcoins can be lost, but for the foreseeable future there will continue to be more than enough bitcoins available to keep playing the game.
Each person is their own bank. Although I suppose that if a friend of mine wanted to buy some bitcoins and didn't have a computer or Internet, I wouldn't mind keeping track of their balance.
That is pretty divisible(enough for the moment), which means that \u0e3f serves all the functions of money- \"Money is a matter of functions four, a medium, a measure, a standard, a store.\" That is, money functions as a medium of exchange, a unit of account, a standard of deferred payment, and a store of value.\"-wikipedia
I must thank Satoshi for his work (although the groundwork was done during the 80's, algorythms etc. this is the first useful implementation and it's effects are profound).
I live in PRChina, combining Freenet, Tor, I2P there is the framework for free,anonymous discussion and transfer of information(something that is prevented here, sometimes with serious penalties). Add to this BitCoin and we now have an underground market free from the tyrany and scrutinising eye of the state. This will allow an alternative, free China to develope under the nose of the state machinery.
My understanding is that Bitcoin cannot be suppressed without suppressing the internet as a whole, is this correct?
I would like to give Satoshi a donation, but sadly R&B(ReminBi, literally \"The Peoples Money\") is not a world traded currency and sending a payment in a foreign currency is expensive & complicated. If I could give a gift, to a value of R&B500(about $70US)? Or if wished open a currency exchange for \u0e3f/R&B?
One thing I will do is have some computer science students translate the application to Chinese, after Spring Festival.
NewLiberty-
The lazy way would be for me to peg my exchange rate to yours and let you do the calculations. Otherwise I would need to know the total amount of \u0e3f in circulation and the amount of goods that can be purchased with it(this is a Austrian economist view of measuring the value I think?), just what is the amount in circulation?
What do you mean \"keep playing the game\"?
Also, what do you sell more, \u0e3f or $US?
",
"nested_level": 0
},
{
"id": 250,
"thread_id": 23,
"source_id": "4",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: How divisible are bitcoins and other market/economic questions",
"url": "https://bitcointalk.org/index.php?topic=44.msg257#msg257",
"date": "2010-02-06T15:12:15Z",
"text": "...Otherwise I would need to know the total amount of \u0e3f in circulation and the amount of goods that can be purchased with it(this is a Austrian economist view of measuring the value I think?), just what is the amount in circulation? ...
From the FAQ:
How are new Bitcoins created?
New coins are generated by a network node each time it finds the solution to a certain calculational problem (i.e. creates a new block), for which an average solution time can be calculated. The difficulty of the problem is adjusted so that in the first 4 years of the Bitcoin network, 10,500,000 coins will be created. The amount is halved each 4 years, so it will be 5,250,000 in years 4-8, 2,625,000 in years 8-12 and so on. Thus the total number of coins will approach 21,000,000 over time.
What's the current total amount of Bitcoins in existence?
The number of blocks times the coin value of a block. The coin value is 50 bc per block for the first 210,000 blocks, 25 bc for the next 210,000 blocks, then 12.5 bc, 7.25 bc and so on.
As of October 30th 2009, there are about 26,000 blocks in the block chain, which means 26,000 * 50 bc = 1,300,000 bitcoins in existence. You can see the up-to-date number of blocks in the status bar of the Bitcoin main window.
Current Block count as of 06th Feb. 2010 - 3.15 PM - GMT is 38,660 blocks. You can do the math
What about dwindling supply?
The current supply will eventually begin to dwindle as people lose their wallet's(removing coins from the system) & governments attempt to drain coins out (either by scamming or creating coins themselves and simply hoarding them)of the system. This is inevitable (government action against BC) as no government worldwide will allow the existence of such an anonymous currency system out of their control or supervision.
That's an excellent point. If this occurs, it might be a good idea to remove or extend the 21M million limit in later versions and freeze the difficulty of generating new coins (by not making it exceedingly difficult to make new ones). Granted, BTC will not be an excellent investment as it is now (because currently we expect its price to multiply in the future), but then again if it turned out to be that popular, the \"investment\" incentive will not be the main reason people are rushing to use it.
Removing or extending the 21M limit would be a disaster, it's the finite supply of this digital cash that makes it useful as money.
Allowing for the currency to be further divided would solve that issue. No one loses the value of any of their currency held(devaluation or debasing), while at the same time being able to break off smaller pieces of a \u0e3f to trade.
Besides, the whole point is that there is no (central)control over the supply, this would allow it to be extinguished by governments or abused by a central authority (like today's central banks & governments)
I am wondering Satoshi, what would be the technical difficulty of implementing \u0e3f as 0.000(or more zeroes) instead of 0.00?
This is not a request since there is no need for it yet, but may wish to acommadate a larger user base in the future.
",
"nested_level": 0
},
{
"id": 253,
"satoshi_id": 46,
"thread_id": 23,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: How divisible are bitcoins and other market/economic questions",
"url": "https://bitcointalk.org/index.php?topic=44.msg267#msg267",
"date": "2010-02-06T23:25:53Z",
"text": "Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.
But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places.
If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the \",\"'s and \".\"'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.
",
"nested_level": 0
},
{
"id": 254,
"thread_id": 24,
"source_id": "1",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg272#msg272",
"date": "2010-02-07T09:27:56Z",
"text": "Everyone open your graphics editor and make a \"we accept Bitcoin\" logo. A good looking logo (preferably better than mine
) would be really useful.
My first version attached.
I took a shot. Small, clean \"btc accepted\" sign. See attached file.
",
"nested_level": 0
},
{
"id": 256,
"thread_id": 24,
"source_id": "3",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg276#msg276",
"date": "2010-02-07T19:14:19Z",
"text": "Everyone open your graphics editor and make a \"we accept Bitcoin\" logo. A good looking logo (preferably better than mine
) would be really useful.
Is there a high-res bitcoin logo? Or a vector-image?
No, sorry. I've been meaning to redo it. The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME. Any larger than that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right. If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in \"BC\" don't land square on a pixel.
The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't like the 32x32 version.
I'm attaching bitcoin20x20.png, the 20x20 version with full transparency.
",
"nested_level": 0
},
{
"id": 258,
"thread_id": 24,
"source_id": "5",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg286#msg286",
"date": "2010-02-08T20:22:59Z",
"text": "This one is inspired on the PayPal, secure payments logo.
",
"nested_level": 0
},
{
"id": 259,
"thread_id": 24,
"source_id": "6",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg287#msg287",
"date": "2010-02-08T20:24:43Z",
"text": "A simple \"we accept Bitcoin\" image.
",
"nested_level": 0
},
{
"id": 260,
"thread_id": 24,
"source_id": "7",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg293#msg293",
"date": "2010-02-09T15:04:26Z",
"text": "Thank you for these sirius-m, giik and all future contributors. I might have ago at producing a logo myself.
Is this a logo contest ? How many Bitcoins for the Winner ?
Perhaps anyone who adopts a contributors logo for their website might consider a Bitcoin donation to it's creator(s) !
A bitcoin image in the shape of a credit card. Inspired by the Me.com account payment page.
",
"nested_level": 0
},
{
"id": 262,
"thread_id": 24,
"source_id": "9",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg473#msg473",
"date": "2010-02-24T04:15:05Z",
"text": "I attempt a contribution:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc1_400x200_old.png&t=589&c=6yxqMX8A3G_w1w\"/)
EDIT) This is old version. Design has been
updated.
Image original is saved as proprietary vector format, can be resized without loss of quality. Bitcoin graphic had to be remade by myself as vector. I will accept and may implement suggestions.
Quality and fantastic Sabunir ! I really like them.
Suggestions:
(1) The background 'fade' effect somewhat detracts from the text in the smaller versions of the logo. Almost making it unreadable (tricky one as I realize it's taken from the website header)
(2) Maybe a mention of 'P2P'. Maybe not...
(3) Embossed blue / dark blue outline ?
I'd be happy to pay to use the logo's (I have already sent giik a token 100BTC donation)
Am I to understand that these graphics are public domain?
",
"nested_level": 0
},
{
"id": 267,
"thread_id": 24,
"source_id": "14",
"poster_name": "Ensayia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=46",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg487#msg487",
"date": "2010-02-24T06:41:59Z",
"text": "In what way, madhatter2?
As in you can take them and use them wherever? For mine I don't care, use it how you like, just try to give credit if possible.
",
"nested_level": 0
},
{
"id": 268,
"thread_id": 24,
"source_id": "15",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg489#msg489",
"date": "2010-02-24T07:02:05Z",
"text": "Public domain? No. My images are
Copyleft, to myself (satoshi or any other Bitcoin developers can have the rights to these images, upon request). In practice, Copyleft works almost the same as public domain. You are completely free to use, share, or modify my images. If you do, please consider listing me in your credits or donating an amount of coins to me, but this isn't required.
Thanks, these are getting to look good.
",
"nested_level": 0
},
{
"id": 270,
"thread_id": 24,
"source_id": "17",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg499#msg499",
"date": "2010-02-24T16:07:20Z",
"text": "wow ! Yeah looking really good
As well as GNU GPL why not attach a Creative Commons License
http://creativecommons.org/ to them. You can reference the project address and request a Bitcoin donation for their reproduction.
I am not that picky. Growth of the Bitcoin network and promoting more widespread usage is sufficient reward to me.
",
"nested_level": 0
},
{
"id": 272,
"satoshi_id": 76,
"thread_id": 24,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Make your \"we accept Bitcoin\" logo",
"url": "https://bitcointalk.org/index.php?topic=45.msg507#msg507",
"date": "2010-02-24T21:53:52Z",
"text": "If you GPL stuff, I have to avoid using it. Nothing against GPL per-se, but Bitcoin is an MIT license project. Anything GPL please clearly mark it as such.
",
"nested_level": 0
},
{
"id": 273,
"thread_id": 25,
"source_id": "1",
"poster_name": "BlueSky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=34",
"subject": "Simple to implement feature requests",
"url": "https://bitcointalk.org/index.php?topic=46.msg281#msg281",
"date": "2010-02-08T09:00:02Z",
"text": "First request:
Optional connect to IP dialog.
Explanation:
BitCoin connects to the network(of peers) by getting one of a number of IP's from IRC at present, once connected to a single peer other connections can be made, so if only 1 IP on the list are available then you can connect to the network & make connections to other IP's(this is my assumption, please correct me if I am wrong).
This is somewhat similar to how Tor works, when you first start it up it attempts to connect to a public list of IP's(public bridge nodes). This list being public is accessible to organisations that want to prevent the use of Tor(for example the Chinese or Iranian government). And so as a consequence these IP's are blocked, and you cannot connect from these countries.
However there is the option to connect to the ip of a bridge (if you know one, a friend in a free country running Tor in bridge mode perhaps) and so this circumvents regime blocking attempts and is very robust.
Adding this feature will allow Bitcoin to function despite regime efforts to prevent it.
",
"nested_level": 0
},
{
"id": 274,
"satoshi_id": 50,
"thread_id": 25,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Simple to implement feature requests",
"url": "https://bitcointalk.org/index.php?topic=46.msg284#msg284",
"date": "2010-02-08T16:37:24Z",
"text": "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 try) -connect=(next to try) ...
You can specify non-routable IPs with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that.
In particular, -addnode is needed if you're always going to connect through TOR, since the IRC server blocks all the TOR exit nodes. To connect through TOR, you could use:
bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216
",
"nested_level": 0
},
{
"id": 275,
"satoshi_id": 48,
"thread_id": 26,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg279#msg279",
"date": "2010-02-08T01:27:02Z",
"text": "Thank you for the offer to help translate. That is probably the best way you could help.
I will need to prepare the code for translation first. wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard. We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support. I've done test builds with 2.9.0 and there is one bug left to fix.
What operating system are you using? Windows, Linux 32-bit or 64 bit?
Split from another thread.
sirius-mI am running Windows 32 (But have AMD64 dual core machine), but could, if required have a version of Linux using virtualisation(I must install this).
The most simple way at present is to have different language binaries(e.g. bitcoin_en.exe, bitcoin_zh.exe etc.). Please post when you want this translated, this would mean there could be a dual language release for the next version (Why not a tri-language release, you do speak Japanese no?).
",
"nested_level": 0
},
{
"id": 277,
"satoshi_id": 49,
"thread_id": 26,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg283#msg283",
"date": "2010-02-08T16:10:37Z",
"text": "It's much easier to have a single binary and multiple .mo files. It's too much maintenance work to have lots of build variations. Once the software support is implemented, anyone could contribute translations.
wxWidgets uses the gettext standard. You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file. The program loads the .mo file at runtime and reskins all the strings. Additional languages can be added to an existing program by adding .mo files without recompiling the program.
On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.
Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next.
",
"nested_level": 0
},
{
"id": 278,
"thread_id": 26,
"source_id": "4",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg285#msg285",
"date": "2010-02-08T19:28:28Z",
"text": "Thank you for the offer to help translate. That is probably the best way you could help.
I'm willing to help you translate to Dutch. Just let us know, when it's possible!
I can translate it into German, if you wish.
",
"nested_level": 0
},
{
"id": 280,
"thread_id": 26,
"source_id": "6",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg298#msg298",
"date": "2010-02-09T16:08:39Z",
"text": "You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too.
",
"nested_level": 0
},
{
"id": 281,
"thread_id": 26,
"source_id": "7",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg302#msg302",
"date": "2010-02-09T20:47:58Z",
"text": "[...]JSON-RPC and command line support[...]
Sweet! I've been looking for something to make some kind of semi-cloud setup, and JSON-RPC looks promising. Keep up the good work!
You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too.
Do you want it as plain-text or a .html or .php file ?
You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too.
Do you want it as plain-text or a .html or .php file ?
Plain text is good, but add the heading and list html tags if possible.
It looks like the
Bitcoin Wikipedia article is only available in English. How about some of you either translate or write a new article in your language.
My Dutch translation is almost finished. I will send it to sirius-m this week.
",
"nested_level": 0
},
{
"id": 286,
"satoshi_id": 62,
"thread_id": 26,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin client and website translation",
"url": "https://bitcointalk.org/index.php?topic=47.msg389#msg389",
"date": "2010-02-17T19:19:43Z",
"text": "I updated the SVN with changes to support translation. Translatable strings are all enclosed in _(\"\"), and we're using UTF-8 on all platforms.
When the program runs, it looks in the directory of the EXE for the file: locale\\<langcode>\\LC_MESSAGES\\bitcoin.mo
<langcode> is the two letter code of the language your OS is set to, like \"de\" or \"nl\".
On Linux, it also looks for:
/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
/usr/local/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
(are there other standard places it should look on linux?)
Here's a quick walkthrough using poedit to make a .po and .mo file:
- Download the bitcoin sourcecode from SVN
- In the trunk directory, mkdir locale\\<lang>\\LC_MESSAGES
- In poedit, File->New catalog->Paths tab
- Click the \"New item\" dotted rectangle button
- Put \"../../..\" and MAKE SURE TO PRESS ENTER to add the path
- Click OK
- Save the file as \"bitcoin.po\" in the LC_MESSAGES directory you made
- It should then scan the sourcecode and find about 170 strings
- If it didn't find anything, check Catalog->Settings->Path tab, make sure the \"../../..\" was added
When you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program).
",
"nested_level": 0
},
{
"id": 287,
"thread_id": 27,
"source_id": "1",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "What's with this odd generation?",
"url": "https://bitcointalk.org/index.php?topic=48.msg310#msg310",
"date": "2010-02-10T18:31:40Z",
"text": "I thought BitCoin only generated in 50 coin increments, but I got 50.44 here.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg695.imageshack.us%2Fimg695%2F3865%2Fgenerate1.png&t=589&c=t9EDL8yGu4p8Zw\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg63.imageshack.us%2Fimg63%2F9348%2Fbitcoin50.png&t=589&c=eSykXYD1JsY_mQ\"/)
had the same a while ago with 50.26
That is odd !?! I've currently only had 50.00 generations myself.
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 in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together. After that it's just one line to send the combined unit.
",
"nested_level": 0
},
{
"id": 291,
"thread_id": 27,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: What's with this odd generation?",
"url": "https://bitcointalk.org/index.php?topic=48.msg318#msg318",
"date": "2010-02-12T08:31:52Z",
"text": "There's a small transaction fee for very large transactions. (usually over 10,000 bc) The node that generates the block that contains the transaction gets the fee.
The fee is based on the KB size of the transaction and intended to compensate the network for the resources used to process it.
If the same money gets sent again, it won't incur the fee again because it'll be small. The first time they're bundling hundreds of 50 bc coins together. After that it's just one line to send the combined unit.
Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)? Why couldn't someone just send 1000 small transactions to bypass fees?
why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!
",
"nested_level": 0
},
{
"id": 293,
"thread_id": 27,
"source_id": "7",
"poster_name": "riX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=27",
"subject": "Re: What's with this odd generation?",
"url": "https://bitcointalk.org/index.php?topic=48.msg320#msg320",
"date": "2010-02-12T14:31:15Z",
"text": "Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)? Why couldn't someone just send 1000 small transactions to bypass fees?
You could, but you'd have to wait for one block to be generated between each one of them.
Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)?
Yes.
why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!
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 small fee is added.
The average transaction, and anything up to 500 times bigger than average, is free.
It's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount. It's not money sucked out of the system, it just goes to other nodes. If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.
Is the fee enough to always ensure the profitability of running a node, even when BitCoin generation stops being profitable?
",
"nested_level": 0
},
{
"id": 296,
"satoshi_id": 57,
"thread_id": 27,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: What's with this odd generation?",
"url": "https://bitcointalk.org/index.php?topic=48.msg329#msg329",
"date": "2010-02-14T15:52:23Z",
"text": "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 compensation for nodes. I'm sure that in 20 years there will either be very large transaction volume or no volume.
",
"nested_level": 0
},
{
"id": 297,
"thread_id": 28,
"source_id": "1",
"poster_name": "nphyx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=36",
"subject": "DEB Package?",
"url": "https://bitcointalk.org/index.php?topic=49.msg314#msg314",
"date": "2010-02-12T00:31:35Z",
"text": "I am having 0 luck attempting to compile w/wxWidgets. Trying to compile wx from source was a no-go (various syntax errors I didn't really delve into), downloaded latest precompiled wx packages for ubuntu karmic, but they do not match up to your static links far as I can tell. I guess what I'm getting at is, rather than try to sort out these issues, I'd really love a .deb <.< I'd like to participate - as an agorist and a fan of cryptoanarchic theory this is sort of a fantasy of mine, but there is frankly no way I will dual boot windows or run this in as insecure an environment as a VM.
DEB isn't a bad route, you'll hit the vast majority of desktop linux users, most of whom won't be buggered to try compiling in the first place, so I don't think it's entirely unreasonable. Alternatively if you are interested in helping me work out compilation issues I would be happy to provide x86_64 binaries for ubuntu as long as I am compiling them. I haven't done .debs before but I am sure I can figure that out. Let me know
Are you just trying to run the program or do you really need to compile it? There's a 32-bit linux binary that can be run on 64-bit ubuntu if you \"sudo apt-get ia32-libs\".
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/downloadI recently updated the SVN for building on 64-bit Karmic with wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did not build on 64-bit yet.
Unfortunately there currently isn't a -dev deb package of either of the versions of wxWidgets that we can use. On Karmic they only have the UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version or the UTF-8 (wxWidgets 2.9.0) version. We're moving towards 2.9.0.
I know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine.
If you want, I can provide you with a precompiled binary.
Am I missing something? Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?
The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.
Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it.
Sorry, I should have mentioned more clearly that I am running AMD64. I was trying to compile with 0.2.0, so that would explain a lot of my issues. I *would* like to have a native 64 bit binary, but it sounds like that isn't going to happen right now. I have ia32-lib already, I'll try running what you've supplied, and failing that Wine might be an option. Thanks for the help. I don't remember coming across SVN links on the download page, but once you get up to wxWidgets2.9 I may try again. I could *not* get 2.8.10 to compile for me, I'm sure I probably was overlooking something, but it sounds like 2.9 at least resolves the utf-8/ansi issue
I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.
I have been compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine on 64-bit. Read build-unix.txt and use the given ../configure parameters on wxWidgets so you can use the makefile.unix.wx2.9 as supplied. (--enable-debug --disable-shared --enable-monolithic)
There's one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason. -- fixed
The download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time.
The SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010.
Hopefully they'll have a wxWidgets 2.9.0 debian package someday.
",
"nested_level": 0
},
{
"id": 302,
"thread_id": 29,
"source_id": "1",
"poster_name": "foobar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=43",
"subject": "Setting up multiple bitcoin machines behind NAT",
"url": "https://bitcointalk.org/index.php?topic=54.msg359#msg359",
"date": "2010-02-16T00:35:25Z",
"text": "Hello,
well the title says it all. I want to set up multiple bitcoin machines behind NAT.
For this it reason would be nice, if one could choose an other port than 8333, which I guess would have other nice side effects. Maybe someone uses this port for something else or maybe it isn't possible to set up port forwarding to this port for one reason or another.
Or is there an other way one should go?
Greetings,
foobar
",
"nested_level": 0
},
{
"id": 303,
"satoshi_id": 59,
"thread_id": 29,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Setting up multiple bitcoin machines behind NAT",
"url": "https://bitcointalk.org/index.php?topic=54.msg360#msg360",
"date": "2010-02-16T01:34:56Z",
"text": "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 work, other nodes wouldn't know to connect to that port)
If you want, as a small optimization, you could run the rest of your computers as:
bitcoin -connect=<the IP of the first computer>
so they get all their network communication from the first computer and don't all connect over the net individually for the same information. This saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.
For redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them. The first two are run normally, the rest are run like:
bitcoin -connect=<IP1> -connect=<IP2>
",
"nested_level": 0
},
{
"id": 304,
"thread_id": 29,
"source_id": "3",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Setting up multiple bitcoin machines behind NAT",
"url": "https://bitcointalk.org/index.php?topic=54.msg877#msg877",
"date": "2010-04-08T20:06:37Z",
"text": "Right now there isn't a port number setting to do that. It's a feature yet to be implemented.
So, if I somehow I forwarded port router:8333 to bitcoinhost1:8333 and router:8334 to bitcoinhost2:8333, we get undefined behavior?
Because that seems like trivial to me, to keep track of port numbers in any p2p app.
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.
",
"nested_level": 0
},
{
"id": 306,
"thread_id": 30,
"source_id": "1",
"poster_name": "ec",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=42",
"subject": "URI-scheme for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=55.msg377#msg377",
"date": "2010-02-16T20:51:42Z",
"text": "Hi, intrigued by the bitcoin-system, I have an idea:
The bitcoin addresses could be improved by implementing an
URI-scheme like e.g. torrent
magnet links.
So instead of
1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could more unambiguous say
bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, and even configure browsers to redirect clicks on such links to a bitcoin client. This would allow one to implement \"donate buttons\" on homepages, \"pay buttons\" on webshops etc.
If an IP should be included, URIs allow this as
bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ. If wanted an amount could be specified as
bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of course for the user to verify in the secure bitcoin-client).
Just my 0.02 \u0e3f (return them to
bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you don't like them
)
An URI-scheme could also be of use for implementing a mobile wallet with
QR-codes, so that your buddy who wants to pay you X bitcoins don't have to enter your bitcoin-address manually, but only need to photograph the screen of your mobile phone.
Yeah, I had totally thought of that too. A magnet link scheme would be awesome.
That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.
",
"nested_level": 0
},
{
"id": 310,
"thread_id": 30,
"source_id": "5",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: URI-scheme for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=55.msg484#msg484",
"date": "2010-02-24T06:39:16Z",
"text": "That would be so awesome...
I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per
this thread and the wonderful developments
described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.
Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?
Maybe it is good, not to try implementing a new top level URI scheme, as it is regarded as an ad lib maneuverer, if it is not recognized universally. Adopting the magnet system would avoid this, but in itself magnet is an informal, unregistered scheme. The beauty of magnet is that it can be shared and is open in that sense.
Now, that might all seem very good, because bitcoin is after all a P2P application and it's network does operate on similar principals, but what if the person clicking on the link is not a bitcoin user? What if you want to incorporate some information that is not carried in the existing network, such as the article being sold, shipping information and various other issues. My understanding is that bitcoin only handles the transaction itself, so the user is left to make all other arrangements, contracts and communications independent of bitcoin. Here's where the anonymity is compromised, because here, we are inclined to resort to conventional 'hierarchical hardwired, or non-anonymous technologies. That's not a criticism of bitcoin by any stretch, because bitcoin is a fantastic way to transact, no question about it. But the transaction is only one side of the coin, if you'll pardon that cheesy pun.
In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. Given that freenet is a user/identity-space intended for information storage, couldn't it also be used as a repository of human readable data files, particular and unique to each user, and incorporating any format of data you wish to use, for embellishing your transaction? Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.
This should keep everything under the same kind of cryptographic P2P infrastructure, and allow infinite diversity of application specific context. I suppose a unique URI hash key, could be borne out of the combination of your freenet+bitcoin hashes and the file encrypted with your freenet key found by decrypting with your bitcoin key, while your bitcoin node can be addressed the other way around. Does that sound right? Of course, if you use your real identity on one, then I guess then, you real identity would be divulged on the other.
Anyhow, I'm sure there's some way to do it. Again, freenet also uses an unregistered URI scheme, but if a variant of magnet is adopted, that will not be a problem. The question remains, if people have hopes of bitcoin becoming a formal recognized currency and a very legitimate deal, then the strict adherence to all other internet protocols might be advisable. I have noted so far nothing in particular that would prevent the registration of a magnet/freenet like URI scheme. I haven't searched them all but one may even exist. Otherwise why not register one?
So the URI scheme needs to be agreed upon as to the classification (i.e. what kind magnet etc, as well do we go legit/formal or not) and format, such as how it is to be laid out:
Components Of A URI![\"\"](\"https://ip.bitcointalk.org/?u=https%3A%2F%2Fdeveloper.mozilla.org%2F%40api%2Fdeki%2Ffiles%2F3267%2F%3Duri-diagram.png&t=589&c=IB2e7gz117wstg\"/)
This speaks to the conventions that Mozilla will account for in parsing a URI.
A typical magnet URI, looks like this
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
A freenet URI is like this:
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdfTo be recognized at all, the freenet program needs to be installed and this includes a Java powered web server that recognizes the resource as an item in identity space of the localhost. i.e. my browser sees the whole of freenet as being on my machine. I don't know if this identity space could be addressable without the user having to run a web-server, but I suspect the server is only for the ability to serve web pages as well as recognition of the localhost as the requisite top level domain. The 'http:' indicates that the freenet URI, is nothing special in itself, but the IP address (localhost) certainly is. I suspect a program can address the freenet user space, without incorporating a web server, and the universal links can be made as magnet URIs. As for those who don't have bitcoin installed, I don't know how the URI could be made to have a default fall back, to redirect visitors of that link. to the Sourceforge download for bitcoin. That may need to implemented in code and cookie or environ variable set to record the presence of bitcoin.
Other relevant sites I have visited in the course of this research include:
Any ideas/comments/feedback is/are welcome.
Steve
Before this can happen there needs to be a consensus about what form the URI would take. [snip] ...the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address.
[snip]The beauty of magnet is that it can be shared and is open in that sense.
I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either.
In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. [snip] Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.
Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.
However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):
- address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
- amount (optional): The amount to send.
- message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
- details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.
This just in:... It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet
<YAY!>
Sorry, I'm not assuming that we must agree on the freenet URI functionality I suggested, just that It is exciting that it can be so readily incorporated, even for experimental purposes. Simply addressing a preconfigured freenet server should do the trick, but perhaps even the existing code can be slightly modified to directly address freenet (without the implicit web server included in the proper freenet install), but by including this FCP code, in the browser add-on, just the addressing and communicating functionality may be incorporated without the overhead of a full blown freenet http server. I assume at this point, the freenet web server, is only needed by the client for browsing freenet, not to service a node. As Bitcoin already addresses a similar P2P network, how hard would it be to make the bitcoin server do freenet inquiries? Could such trickery be included in the JSON intreface?
From:
http://new-wiki.freenetproject.org/FCPv2Purpose
The Freenet Client Protocol is a simple, text-based protocol designed to allow third-party applications to interact with Freenet. Supported functionality includes:
* Inserting of data into Freenet
* Retrieval of data from Freenet
* Querying the status of Freenet
* Managing the other Freenet nodes that are connected to your own node.
So, it seems you can pull data out of and post data into freenet at will.
Veeeeery interesting indeed.
Aside from that, in the course of looking for proxies or workarounds for freenet URI integration, I believe I solved an unrelated problem to do with my ISP blocking VoIP/SIP (as it's the local telco as well - and yes, I am changing providers very soon). I want VoIP, but my bastard anti-competitive ISP has crippled my modems firmware (which has an inbuilt 2 port analogue telephone adapter), and I hope this work around (Tor) gets past it (I'm not holding my breath) but Link2VoIP, if you are reading this, I'm looking in your direction.
",
"nested_level": 0
},
{
"id": 314,
"thread_id": 30,
"source_id": "9",
"poster_name": "Karmicads",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=163",
"subject": "Re: URI-scheme for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=55.msg1043#msg1043",
"date": "2010-05-02T07:07:54Z",
"text": "Hi DataWraith
I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages.
I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity. I'm honestly not into superficial popularity if I can help it. The reason to consider a magnet URI IMHO is owing to the
Actual stated purpose and draft specificationsMAGNET is a work-in-progress URI specification, and collection
of standard practices/implementing code to allow a website to
seamlessly integrate with features made available by local
utility programs. In one way, it could be thought of as a
vendor- and project-neutral generalization of the \"freenet:\"
and \"ed2k:\" URI-schemes used by the Freenet and EDonkey2000
peer-to-peer networks, respectively.
It's stated purpose is specifically to allow websites to seamlessly integrate with features of local utility programs. It is intended to be vendor neutral and avoid having to reinvent the wheel and avoid further conflicts with other URI schemes. It also follows strong compliance with W3C standards and any scheme using the magnet convention would inherit that rigor.
NOTES ABOUT THE URI FORMAT:
- Yes, it looks a little strange to have the \"?\" right after
the \":\", but by my reading of the relevant URL/URI RFCs,
that fits the recommended common URI syntax well. (It also
meshes nicely with the way the parameters are passed on to
individual local apps.)
- FYI, EDonkey URIs violate many provisos of RFCs 1738 and
2396, including the use of \"//\" at the front of a non-
hierarchical namespace and the use of illegal/disfavored
(when not escaped) characters
- Parameter names and values should officially be www-
formencoded, just like HTTP web form GET submissions in the
query-string, though in practice some characters that a
strict reading of HTML-specs/RFC1738 would suggest should be
encoded (like '.' and ':') seem not to be encoded.
- The prefix 'x.' is reserved for application-specific new
parameter experimentation. Any parameters not beginning 'x.'
are only to be defined by official MAGNET specifications.
- Other potential parameters might include a \"fallback-
location\" for content that can't be found via P2P, P2P-
system-specific identifiers (ed2k, sig2dat, freenet), other
topic qualifiers (\"length\"), etc. These remain to be
designed; comments wanted.
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).
Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.
MAGNET URIS, ILLUSTRATED BY EXAMPLE:
(1)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
meaning: show me options pertaining to the \"exact topic\" (xt)
given by the supplied URI (specifically, an URN)
(2)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3
meaning: show me options about this exact topic, but use
the included (unverified) \"display name\" for user convenience
(3)
magnet:?kt=martin+luther+king+mp3
meaning: show me options about the \"keyword topic\" (kt)
given by the string
(4)
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7
meaning: show me options about the two exact topics given
(5)
magnet:?mt=http://weblog.foo/all-my-favorites.rss
meaning: show me the options for the \"manifest topic\" (mt)
fetchable via the given URI. This could also be an URN.
Manifest topics include lists of other items.
Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.
Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it. I would be more concerned with robustness and not being painted into a corner myself. The effort to implement backward compatibility and forward extensibility, having been considered from the outset, is a small price IMHO. In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed. Also the URI should of course include this freenet functionality, as an optional parameter. So if not specified, the information to do the basic transaction would still be legitimate. It would not then be compulsory to use in publishing the URI, but the handler should still be able to take the parameter if it is used, otherwise the optional choice you are proposing is between two different incompatible URI schemes. Measure twice, cut once.
However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):
* address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
* amount (optional): The amount to send.
* message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
* details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.
Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.
The amount: Yup goes without saying.
Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. The need to reference a supplementary document begins here. The payer can send their message in the software interface (either the standalone program or the Firefox add-on), The link, at a minimum, identifies the recipient and the amount, that must be passed to the software. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? What message needs to be passed by the payer, that is not possible in the interface, but is possible by clicking on the link? That would imply that the link invokes methods like post or get, that are exclusively http/s functionality, that is defeating the purpose of having a purpose made URI scheme. Post and Get functions need to be addressed within the hierarchical namespace of TCP/IP and/or physical file path names.
Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.
As far as this
\"you could also link to freenet, i2p and tor to keep things anonymous.\" is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with. That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless. If I can make the URI handler address the freenet namespace, then I suggest it would much better to store the files there in the first place. Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.
If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.
EDIT: Re my comment
\"The amount: Yup goes without saying.\" I take that back. I was thinking in terms of links only as instigators of payment events, but of course, if the amount and other parameters are left blank, it should then default to acting as an identifier link to instigate a payment at the behest of the payer. A simple donate button would only need one parameter and zero redirections/login/confirmation/calculate and change currency before you can finally send, to not see your transaction eating the dust of snailmail on horseback, in the event that you don't have a credit card. (Suck on that that PlayPal). That, along with the naming alias idea suggested by DataWraith AKA (having an address), if that;s what you meant DataWraith, is certainly worth implementing for my bitcoin.
Karmicaids, thanks for taking the time for such a detailed reply.
It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet
<YAY!>
Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional.
I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity.
I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part -- that the existing acceptance of magnet links in other software was a plus.
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).
Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.
Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.
Perhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a
thing so much as a
process. In my mind, magnet links refer to things (usually a file -- whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say \"Yes, send the coins.\" once you click the link).
To me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.
A bitcoin-link should be more like mailto: than magnet: IMHO.
Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it.
Yeah, my mistake, sorry.
In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed.
IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service -- that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific.
* address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
* amount (optional): The amount to send.
* message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
* details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.
Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.
Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. \"Change your address\"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.
A system to translate aliases would of course be nice, but I think that's better handled with an address book or
mybitcoin.com or something.
Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link?
Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?
This has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message \"Payment for Ebay auction #12345\", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345.
Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.
Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.
What I wanted here was to make this additional information general. Some examples might clarify this:
The creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction.
As far as this \"you could also link to freenet, i2p and tor to keep things anonymous.\" is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with.
But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.
Also, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable.
That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless.
Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with.
Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.
Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? -- this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever.
If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.
Well, we're all together in this. I just hope to arrive at the best possible system. :-)
Thank you for your thorough explanation, and patience with my suggestions.
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.
That's a very pragmatic answer. I like it.
However, how would that work with the combined IP / Bitcoin Address URI (URN? URL?) scheme described here?
[link]http://bitcointalk.org/index.php?topic=158.msg1322#msg1322[/link]
I know it's been nearly a month, sorry.
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345or
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 in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.
What would be nice about sending by domain is you could visually verify who it's going to.
A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
",
"nested_level": 0
},
{
"id": 319,
"thread_id": 30,
"source_id": "14",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: URI-scheme for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=55.msg1597#msg1597",
"date": "2010-06-16T06:14:05Z",
"text": "But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.
What would be nice about sending by domain is you could visually verify who it's going to.
I think that hiding the complexity of Bitcoin addresses from the casual user is a good thing. Barring that, it should be possible to embed an observable but unalterable message with address transactions. Is there some reason this is technically infeasible?
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
Try clicking this link:
http://127.0.0.1/You probably don't see anything (unless you're running a web server on your system), but the browser happily tries to take you there.
XMLHTTPRequest is what we were discussing in that other thread.
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
",
"nested_level": 0
},
{
"id": 321,
"thread_id": 30,
"source_id": "16",
"poster_name": "bencoder",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=243",
"subject": "Re: URI-scheme for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=55.msg1599#msg1599",
"date": "2010-06-16T12:59:40Z",
"text": "Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
You could do an iframe that pointed to something like
http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> and then that iframe would contain a little bitcoin interface stating how much & who you're paying and a button to confirm or cancel the payment. If you confirm the payment then it sends the coins to the domain and then redirects to the return value in the query string. bitcoin could add a ?paid=true or ?paid=false to the return location as well so the return script on the domain could then check if it received the payment correctly, or cancel the order.
Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
That's not exactly true. At the moment, Bitcoin only binds RPC to the loopback interface, 127.0.0.1. I would assume that this web interface would be the same. However, there SHOULD be a password to prevent trojans from trivially sending your wallet away. Wallet encryption needs to happen, too.
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
That's what I thought too.
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...
If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.
I'll get started on adding the password field.
Edit 24 May 2011:
This post has just been majorly updated after more than a year to address the technical issues raised against the original suggestions. The ones presented now are practical. They're also credible as the early warning turned out to be true: Bitcoin has transformed into a ridiculously volatile speculation and hoarding tool rather than a stable medium of exchange.![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fs3.postimage.org%2F2zivvoft0%2Fchart.jpg&t=589&c=9dNTJ61BQzoxTw\"/)
I dare not spend a coin today lest its price doubles tomorrow, nor dare I receive a payment in coins today lest their price crashes before I rush to sell them, nor dare I, naturally, store my wealth in the form coins so I'm relying on vulnerable exchangers to store it in the form of fiat currency. Something must be very wrong...
Yet that was all but unexpected; it was inevitable given how the limited supply system was designed. Let's stop and think about this for a minute:
Satoshi stated in his FAQ that
When Bitcoins start having real exchange value, the competition for coin creation will drive the price of electricity needed for generating a coin close to the value of the coin. Now the only problem is that this \"real exchange value\" itself would be determined in part by electricity, computer deterioration, and time expenditures needed to generate new BTCs. And those expenditures increase with time. We have a loop.
Every four years a miner needs to exert double the virtual effort to create the same amount of coins, which means he'll be constantly demanding higher prices to compensate for his costs. Which also means that bitcoins won't generally be spendable. Why? Because only an idiot spends a currency which he is certain its price will double within 4 years, effectively granting him about
19% real annual interest--significantly better than any bank or mutual fund.
Great! I hear you say,
free money for everyone, right?Wrong.
Just as it's futile to create and distribute free extra coins to anyone already owning them \"to make everyone richer\", built-in deflation won't be helping anyone on the long term. That free money will encourage people to
hoard BTCs forever or until another wishful investor buys them, fueling
speculation and price bubbles. Bitcoin will ultimately be regarded as a phony
investment with no real value, just like the good ol'
Pyramid (Ponzi) Scheme where everyone purchases a ticket just to sell it to someone else later for a high profit until
the whole system collapses when it runs out of new victims.
This scenario can only be avoided if the cost of generating new BTCs got constant. Which can only happen if participating nodes needed to exert a more or less constant amount of work (cost) to generate a given amount of BTCs. Only then will people be inclined to actually spend their coins, and they can finally serve their purpose as a stable medium of exchange.
But that's not it. The very fact that the
newly-generated coin supply dwindles as its user base (hopefully) continues to grow will raise that 19% deflation rate even higher. Let alone that many coins are forever destroyed via HDD failures and lost thumb drives, pushing the deflation even higher and higher.
High deflation is bad because nobody spends their money, they only save it because it gains value over time. Can you imagine what would've happened if, say, the Japanese government hasn't printed any (or very few) Yens during the last century while the population exploded? One 1911 Yen would have been more than enough to buy a house today. Who then would've spent their Yens in 1911? Why, almost noone of course!
This scenario is only avoidable if the number of available BTCs continues to grow with its user base at least proportionally. If both figures match,
we won't have deflation nor inflation.
But under the current model the price wouldn't necessarily be tied to the increasing generating electricity costs forever, which means there's a different scenario other than a perpetually deflating currency, and it's much worse: After about 14 years almost no new coins will be produced. Generating costs could then be largely irrelevant, resulting in a
lack of a price anchor. This would leave the price solely to the market's supply and demand forces.
Just like Picasso paintings, a coin could then be worth $1 on a given day then literally be worth $100 on the next and vice versa.
So what's the solution? Well, as you might have already guessed,
we should remove both the 4-years doubling interval rule and the 21M limit. Just allow BTCs to be generated indefinitely.
Don't sigh in relief just yet. After removing the limit we're better off but
still have another issue: The number of users and generating nodes grows exponentially while the existing coins grow arithmetically. We therefore need a mechanism to reflect the number of generating nodes (i.e the total exerted effort) into the resulting bitcoins. But blocks aren't the answer: Technical difficulties have been addressed against my original suggestion which advised rendering the amount of generatable blocks unlimited and totally dependent on the number of nodes. The problem was that a minimum \"cooling down\" period is needed to propagate who owns the new block across the entire network to avoid conflicts.
My modified suggestion therefore is to reflect the total exerted effort in the number of coins, not blocks. So we'd still have only 144 new daily blocks, but the amount of coins in these new blocks will depend on the proof-of-work difficulty (which automatically adjusts to the number of generating nodes). That makes sense.
A late adopter who needs to spend weeks, months, or even years to generate a block should end up with more coins in that block than an early adopter who had to spend only a couple of hours.And no, sorry, early adopters didn't take any risk to deserve a reward. Running a computer program which pops deflationary money isn't a risky activity, not one that warrants a 1,000,000% profit anyway.
No wonder Satoshi (not his real name, which is unknown) was fiercely defending the original design and wanted to keep it going for as long as possible. It allowed him to initially produce all 144 daily blocks (7200 coins/day) for quite a while before having competing miners drive his coins' price way up. He's probably following up on this forum from his Caribbean beach seat now, with other \"early adopters\" eager to join him. The proposed system is the way to halt this pyramid scheme.
The coins' price will then depend on the total cost of electricity sacrificed to generate the newest block. Think of it as if everyone in the network bought some electricity from their utilities company before loading it all onto the network where the roulette runs every ten minutes on average with one lucky winner hitting the jackpot.
Bitcoins would have a real value equal to the amount of electricity sacrificed to create them, and their price would essentially be a function of the (pretty stable) average worldwide home electricity costs, not a function of the number of generating nodes nor total demand, which will never stabilize in the foreseeable future.
Under the proposed system, if the number of generating users doubles tomorrow, the number of coins generated tomorrow will double as well, offsetting the demand surge with a supply surge without the need for a price jump followed by price crash as is the case now.
This flexible supply system will be telling everyone
there's no advantage to being an early adopter. A user doesn't need another victim to reap rewards later because there are no rewards to begin with.
Bitcoin is a medium of exchange, not a profit-making tool. Speculators and investors can go ruin another currency for there's nothing for them to gain here until they can manipulate global electricity prices. By
eliminating risk and uncertainty we're showing them the door, thus accomplishing the most important task towards achieving a stable medium of exchange the general population can trust.
Finally, a simple numerical example: If we assume the average worldwide cost of running a modern CPU for 24 hours is 20 cents, and if our initial goal is to have one BTC roughly equaling one US dollar, then the amount of coins each new block contains should equal: (fifth of a BTC/144 * the estimated equivalent of the modern CPUs number in the network). Thus, if the exerted power was then estimated to equal 10,000 CPUs, the new block created at that point would contain 14 BTC because the whole network spent $14 during the last 10 minutes to create it. If it was 20,000 CPUs, the new block would have 28 BTC and so on.
Once enough coins are produced for \u0e3f1 equaling $1, miners would generate just enough to cover the economy's expansion because any excess will come to them at a loss. The price would then fluctuate approximately along the lines of 99\u00a2-$1.03.
Practically speaking, if the price of 1 BTC after implementing the new system was, say $10, we could simply add a zero to increase the amount of existing coins ten-fold, making 1 BTC equaling 1 dollar, after which
the price will essentially stabilize itself automatically forever. Note that the estimated CPUs figure is arbitrarily set using current computer power and running costs. Errors won't be detrimental because the market will correct itself resulting in 1 BTC equaling slightly more or less than $1. For example, if computers became more energy-efficient while electricity costs stayed constant, then \u0e3f1 will equal a bit less than $1 because it now costs less to produce and vice versa. Whatever the case may be, the price would be stable on the short term and move slowly along with electricity costs and CPU/GPU efficiency on the long term, rendering coins as stable as major fiat currencies.
Note that some replies before page 7 might seem irrelevant because of the suggestion improvements addressing them. The removed obsolete paragraphs from the original entry have been copied below in the third post of this thread just in case anyone wants to have a look to understand the full context of the discussion.Note2: I've revived the thread at the bottom of page 20 due to the increased hacking and abuse of intermediary services such as the MtGox and Bitcoin7 exchangers. The underlying logic is that, had the coin's price been stable, we wouldn't have needed to trust them as often because we wouldn't have been forced to keep our wealth with them in the form of stable fiat instead of in our computers in the form of unstable coins. ",
"nested_level": 0
},
{
"id": 325,
"thread_id": 31,
"source_id": "2",
"poster_name": "I-am-not-anonymous",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=41",
"subject": "Re: Current Bitcoin economic model is unsustainable",
"url": "https://bitcointalk.org/index.php?topic=57.msg391#msg391",
"date": "2010-02-18T07:36:51Z",
"text": "Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.
As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.
In other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.
After 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.
I could be wrong though. Somebody who know what they're talking about please comment instead of me!
Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.
As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.
In other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.
After 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.
I could be wrong though. Somebody who know what they're talking about please comment instead of me!
The plan is to halve the value of the block every four years. So if your PC is making 6 blocks/day now (i.e 300 BTC/day), in 4 years it could be also be making 6 blocks/day, but your balance will only increase by 150 because the block would equal 25 instead of 50 BTCs
Edit 24 May 2011: These are the removed paragraphs from the original 2010 first post. They are obsolete and no longer relevant as the post is now heavily edited. Nevertheless I thought I'd include them for anyone who wishes to understand the full context of the 2010 discussion (up to page 7).
So what's the solution? Well, as you might have already guessed, we should remove both the 4-years interval thing and the 21M limit. Just let BTCs continue to be created forever at a constant rate*. The rate should be divisible enough to give up to, say, 100,000 people an incentive to run the network simultaneously. In other words, the current 144 daily blocks (or units) aren't enough because this means that @ 100,000 users, one has to wait an average of 757.6 days (that's 2+ years) to see something pop up on his screen. 100k is an arbitrary figure, but remember that we need to mobilize as many nodes as possible to resist the tampering attempts of supercomputer-owning governments who can and will try to generate their own proof of work to ruin the project if it ever reaches mainstream. Also note that this will not lead to inflation in the foreseeable future, because the user base of bitcoin will continue to grow for years to come, let alone natural economic and population growth (unless the Mayans turn out to be right, of course).
This way, when the number of bitcoin-generating nodes approaches stability, we will end up with a slowly-growing number of bitcoins matching a slowly-growing number of nodes, resulting in the currency's relative price stability, leading in turn to the ultimate goal of it being used for exchange purposes.
Now for the fun part, a numerical example: If the system is producing 10k bitcoins/day at a constant rate (with difficulty adjusted by collective CPU power just like it is now), and the number of users attempting to generate BTCs was 10k after 1,000 days from now, and increasing at a constant rate of 10 new users/day, we will have and continue to have an average of 1,000 BTCs/user. No inflation, no deflation, no incentive to hoard BTCs, and no incentive to spend BTCs quickly (though that wouldn't necessarily be a bad thing!). Remember that we can always add or remove zero's if the numbers turned out to be awkward at some point, like Germany did in the 1920's hyper-inflation. Note that under this model, an initial price surge is inevitable because the number of nodes increases at abnormal rates at the project's beginning. As the project matures, there would be only reasonable user-base increases, so the price won't fluctuate much any longer (think the percentage increase in newly opened email accounts from 2000 to 2001 vs from 2020 to 2021, for example).
*Another idea would be to set the BTCs creation's difficulty irrelevant of total CPU power in the network so that, say, the average computer would create 1 BTC/day. The global price would then automatically adjust to the participants' average electricity and machine consumption cost. It would be sort of like buying some electricity from the utilities company and loading it on your machine as transferable BTCs. If electricity happens to be cheapest in India, Indians will initially profit from creating BTCs, but as their proportion among the nodes increases, the BTCs price will decrease as it approaches India's average electricity cost. Exchangers will quickly balance supply and demand just as in ForEx fluctuations, Econ 101, remember? Non-Indians would purchase BTCs from Indian exchangers at a very small profit margin because of competition. I personally prefer this model to the constant rate one because the amount of BTCs in circulation would generally be proportionate to the amount of users (sort of like farming gold in MMORPGs), instead of picking an arbitrary constant figure and letting users adjust to it. Thus this model avoids the initial price surge because there will be a balance from day one.
Admittedly, BTCs' price would be tied to energy's under this model. But then again, this is also the case in both my other and the current model. Besides, using Bitcoin for casual quick transfers (rather than as savings) would virtually eliminate this risk. Also granted that creating zillions of BTCs (eg. via governmental sabotage) would lead to inflation in this case if they flood the market with cheap coins, but then again this problem exists in the other two models as well, and can also be avoided by those using the coin for transfers only. But whereas in the other two models a supercomputer-or-two can ruin the whole project by barring most of the honest nodes from creating coins (via controlling most of the CPU power and skyrocketing coin-generating needed effort), under this uber-flexible model everybody will be able to create some coins and use them for transfers regardless of sabotage attempts.Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.
As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.
In other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.
After 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.
I could be wrong though. Somebody who know what they're talking about please comment instead of me!
The plan is to halve the value of the block every four years. So if your PC is making 6 blocks/day now (i.e 300 BTC/day), in 4 years it could be also be making 6 blocks/day, but your balance will only increase by 150 because the block would equal 25 instead of 50 BTCs
I think I understand, thank you for correcting me.
Right now, Your average coin creation rate will be (6 * 50 coins / hour) * (your CPU speed / the total CPU speed in the system)
4 Years from now, Your average coin creation rate will be (6 * 25 coins / hour) * (your CPU speed / the total CPU speed in the system)
Because the amount of bitcoins per block
halves every 4 years.
My question is, what happens if (your CPU Speed) and (The total CPU Speed in the System)
double in 4 years?
I think I understand, thank you for correcting me.
NP, I just sent you a PM
My question is, what happens if (your CPU Speed) and (The total CPU Speed in the System) double in 4 years?
If both doubles then the ratio will stay the same, so the generation will stay the same. You see, it's all relative. Practically, of course, what will probably happen is that your ratio will be much less since more people will hear about Bitcoin (also given the recent surge in capitalist-anarchists and communists).
I'm really tired and I have work tomorrow so this will be my final post for possibly 18 hours but I see what you're saying--your ability to generate bitcoins will inevitably be reduced because people with high-power server farms will take over production.
But when the first system-wide \"halving\" of bitcoins occurs there will be 10,500,000 while the server farms get started on the 5,200,000.
This means twice as many bitcoins will be available via exchange than via creation. If some CPU farmer determines that in now takes double his resources to make bitcoins and thus doubles his exchange rate for his fresh product, he is very likely to be underbid by the people controlling the 10,500,000 because of the time value of money.
You said \"only and idiot would sell at 19% interest rates\" (paraphrase) but in a free market, somebody HAS to be willing to sell for there to even BE an interest rate, people willing to exchange value today for value tomorrow.
",
"nested_level": 0
},
{
"id": 330,
"thread_id": 31,
"source_id": "7",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Current Bitcoin economic model is unsustainable",
"url": "https://bitcointalk.org/index.php?topic=57.msg397#msg397",
"date": "2010-02-18T09:10:12Z",
"text": "I see what you're saying--your ability to generate bitcoins will inevitably be reduced because people with high-power server farms will take over production.
That's only a tiny part of the problem!
This means twice as many bitcoins will be available via exchange than via creation. If some CPU farmer determines that in now takes double his resources to make bitcoins and thus doubles his exchange rate for his fresh product, he is very likely to be underbid by the people controlling the 10,500,000 because of the time value of money.
What will probably happen is the other way around: Those who create BTCs in the first 4 years will make unreasonable profit as they enter the 5th year, and those who create BTCs in the second 4 years will make unreasonable profit as they enter the 9th year, etc
You said \"only and idiot would sell at 19% interest rates\" (paraphrase) but in a free market, somebody HAS to be willing to sell for there to even BE an interest rate, people willing to exchange value today for value tomorrow.
The \"interest rate\" would be the expected future value at best, or Bitcoin will be regarded as a currency without a future at worst. Just like Pyramid Schemes: Many people bought them but nobody took them seriously. It is well established that under perfectly free markets, commodities are sold at a very small or even no margin above their cost on the long run. Since BTCs cost will double every 4 years, so will their price. So nobody under normal circumstances would be willing to sell his ever-inflating BTCs unless he wants to escape the system with some profit before it collapses.
Bitcoin is similar to gold in terms of finite supply and increasing mining costs. Every argument you can make against Bitcoin economy you can make against gold economy, but gold economy still works. Actually, gold currency has been throughout the history unmatched by any paper money in stability.
It's an old keynesian argument that deflation is bad because it leads to a \"deflationary spiral\" where nobody eventually buys anything, because they can get more the next day. That didn't happen where gold standard was applied. Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime. A good example is the computers market - you can get twice as good a computer with the same price if you wait a few years, but people still do buy computers today.
Also, it's good to note that production cost doesn't equal value. You could start printing a currency of your own, but it's value wouldn't be equal to your printing costs. The value is zero if nobody accepts them as payment, or it can be more than the printing costs if many people accept it for payment and there's not too many notes in circulation. That's why I've found NewLibertyStandard's pricing by the production costs a bit misleading, giving the wrong picture to some people that bitcoin value is somehow bound to the electricity cost. He may of course sell and buy at whatever price he wants, but he'll be short on either bitcoins or dollars if it's not the market price (supply/demand).
",
"nested_level": 0
},
{
"id": 332,
"thread_id": 31,
"source_id": "9",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Current Bitcoin economic model is unsustainable",
"url": "https://bitcointalk.org/index.php?topic=57.msg399#msg399",
"date": "2010-02-18T19:58:55Z",
"text": "There isn't a right and wrong economic model. Every model adjusts to supply and demand, they just adjust in different ways.
The current model is beneficial to early adopters in three different ways. First, early adopters generate more bitcoins while there is less competition at the beginning. Second, the availability of bitcoins decreases, which cements their position of wealth. Last, the early adopters have the potential to get rich off the latecomers once generating blocks becomes extremely difficult. Latecomers will have to inject dollars or something else of worth in order to get access to bitcoins and the wealth will go disproportionately to the early adopters.
The idea of the swarm increasing the amount of bitcoins awarded as processing power increases is interesting, but I think it would give too much advantage to botnets. With a constant amount of bitcoins being generated, they can only collect a days worth of bitcoins per day, but if the number of bitcoins was variable, they could swoop in and generate a thousand years worth of bitcoins in a few weeks.
In my ideal model, the same amount of blocks would be generated per day, but 100 bitcoins with no decimal would be awarded for generating a block instead of 50.00 and the amount of bitcoins awarded per block would stay the same forever instead of halving every four years. This would give one advantage to the early adopters who would be able to generate bitcoins more easily while there is less competition at the beginning and it would allow deflation as more people adopt bitcoins, but it would also allow for inflation as more bitcoins are generated, thus encouraging people to spend their bitcoins. Eventually creating bitcoins will still become very difficult and dollars or something else of worth will have to be injected in order for latecomers to get access to bitcoins, but as time passes, that wealth will be distributed more and more evenly between early adopters and latecomers. I prefer 100 to 50.00 because bitcoins are going to take a while before they are worth enough to need to be more divisible and because it's not clear whether a single bitcoin is \u0e3f1.00 or \u0e3f0.01.
",
"nested_level": 0
},
{
"id": 333,
"thread_id": 31,
"source_id": "10",
"poster_name": "Suggester",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=31",
"subject": "Re: Current Bitcoin economic model is unsustainable",
"url": "https://bitcointalk.org/index.php?topic=57.msg400#msg400",
"date": "2010-02-18T21:19:23Z",
"text": "Bitcoin is similar to gold in terms of finite supply and increasing mining costs. Every argument you can make against Bitcoin economy you can make against gold economy, but gold economy still works. Actually, gold currency has been throughout the history unmatched by any paper money in stability.
No. Gold was synonymous to \"money\". Things were valued for how much gold they were worth, not vice versa. We should think of bitcoin today as a new unestablished currency in a world of established alternatives (eg. the Euro 10 years ago). Additionally, if we assume that it became impossible to mine virtually anymore gold today, and we further assume that the demand for gold was perpetually on the rise (for example because women were increasingly using it for jewelery), then yes, it will result in a perpetual deflation for its value and nobody would be willing to sell their gold except for emergencies. Under these conditions, using gold as a means of payment is a sure way for starting a depression!
It's an old keynesian argument that deflation is bad because it leads to a \"deflationary spiral\" where nobody eventually buys anything, because they can get more the next day.
Old and true
That didn't happen where gold standard was applied.
What has gold standard got with increasing the value of BTCs over time? Gold was ALREADY a medium of exchange when the gold standard was applied. I can imagine that the very first time some human discovered the first gold mine, everybody in their area thought it looked cool and started using it as a medium of exchange. People have been mining gold for thousands of years and we haven't still run out of it. BTCs will essentially stop its generation within 15 years.
Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime.
They won't buy tomorrow when the price is lower because it will never be lower as we approach the \"next four years limit\".
A good example is the computers market - you can get twice as good a computer with the same price if you wait a few years, but people still do buy computers today.
Computers are totally different because you can't sell them 4 years from now for double what they're worth today. Had this been the case, nobody would ever sell a computer unless he's starving. Heck, just look at NewLibertyStandard's graph. It will keep shooting up as long as this 4-year model continues.
Also, it's good to note that production cost doesn't equal value. You could start printing a currency of your own, but it's value wouldn't be equal to your printing costs. The value is zero if nobody accepts them as payment, or it can be more than the printing costs if many people accept it for payment and there's not too many notes in circulation. That's why I've found NewLibertyStandard's pricing by the production costs a bit misleading, giving the wrong picture to some people that bitcoin value is somehow bound to the electricity cost.
If the value is more than my printing costs, I'll be busy printing like there's no tomorrow until the price equals my cost (remember that I'm acting like a selfish unorganized person, not an entity or a country, just like most of Bitcoin users will be). If the value is less than my printing costs, me or anyone who wishes to acquire that currency will buy it from others instead of creating it, raising the price of coins already in circulation and dropping the competition and cost of creating new ones (and in bitcoin's case that means network and proof-of-work failure). So you see, in our coin's case, its market value must equal electricity & computer cost. Not more or less. And in any perfectly free market you'll find a similar situation: price = cost.
He may of course sell and buy at whatever price he wants, but he'll be short on either bitcoins or dollars if it's not the market price (supply/demand).
You said it: Supply & demand. What will happen if BTC got successful is that demand will increase while supply dwindles. At some point (after about 15 years) there will be more and more people demanding coins while almost none is generated. This will result in the price increasing until every human on the planet who will potentially use bitcoin has already joined its market (assuming the 4-year doubling thing was removed). And you know what? Maybe that happened to gold in the beginning of its discovery, until almost all people on the planet had gold available to them if they had a reasonable equivalent (e.g. In Arabia, more than a thousand years ago, you could have sold a camel at a time for about 70 gold dinars, and a rabbit for tenth of a gold dinar. Not too difficult to make).
There isn't a right and wrong economic model. Every model adjusts to supply and demand, they just adjust in different ways.
Pyramid Schemes is an absolutely \"wrong\" economic model!
The current model is beneficial to early adopters in three different ways.
Who said it should be beneficial to early adopters? I mean, that's cool because I happen to be one, but if it undermines the model's sustainability then it shouldn't stay.
The idea of the swarm increasing the amount of bitcoins awarded as processing power increases is interesting, but I think it would give too much advantage to botnets. With a constant amount of bitcoins being generated, they can only collect a days worth of bitcoins per day, but if the number of bitcoins was variable, they could swoop in and generate a thousand years worth of bitcoins in a few weeks.
Uh huh, but botnets can't start generating now and collecting 90%+ of newly created blocks? Botnets/supercomputers will always be a problem in any model. But with a limited supply such as 6 blocks/hour, almost nobody can compete with them (can you wait 2 months for a coin to appear?). While if the supply is unlimited, at least we'll end up getting something, and hopefully trading it for a price close to what you've paid for it.
In my ideal model, the same amount of blocks would be generated per day, but 100 bitcoins with no decimal would be awarded for generating a block instead of 50.00 and the amount of bitcoins awarded per block would stay the same forever instead of halving every four years.
That's what I've been advocating as the second-best solution. But we'll need to increase the # of daily blocks to give enough incentives though as I explained in the initial post.
I stand by my statement that the current economic model is not wrong. You might dislike it and I might not prefer it, but other people do prefer it. Our perspective is no more valid than theirs. But that's not to say that I wouldn't use a bitcoin variant if it more closely resembled the description I offered.
Who said it should be beneficial to early adopters?
I'm just stating the facts, sir.
Currently a botnet could generate 99.9% of bitcoins per day, but if bitcoin generation payout was variable, they could generate over 9000% of how many bitcoins are generated per day without them. Botnet operators value their CPU cycles, so being able to generate over 9000% until they have as many as they currently want and then being able to stop and use their CPU cycles for other purposes is much more advantageous than having to use their spare CPU cycles to only generate a capped amount per day.
The number of blocks generated per day can not be easily increased or decreased because there has to be enough time to propagate the blocks to all other nodes while still being frequent enough to allow timely transactions. What can vary is the amount of bitcoins per block. The amount of bitcoins awarded per block can either increase, decrease or stay constant over time. If every person had an equal amount of CPU cycles at his disposal, I would prefer for the amount of bitcoins awarded per generated block to increase proportionally to the amount of CPU used to generate bitcoins. As it is, I'm in favor of the amount staying constant over time.
Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime.
They won't buy tomorrow when the price is lower because it will never be lower as we approach the \"next four years limit\".
He was referring to the price of goods decreasing as value of a bitcoin increases. Eventually the value of bitcoins will go high enough and the price of the goods will go low enough that the person will feel rich enough to spend his bitcoins. To take it to an extreme, if a person has ten thousand bitcoins and can buy the TV of his dreams for one bitcoin, the value of having the TV now is greater than the future potential increased value of the one 10,000th of his total bitcoins.
Currently a botnet could generate 99.9% of bitcoins per day, but if bitcoin generation payout was variable, they could generate over 9000% of how many bitcoins are generated per day without them.
9000% of the now-cheaper-coin because so much of it is available after they joined. It all balances out in the end, and in both cases they have an incentive to join the network. Actually, under the current model they have even more incentive because the coin can never get cheaper!
Botnet operators value their CPU cycles, so being able to generate over 9000% until they have as many as they currently want and then being able to stop and use their CPU cycles for other purposes is much more advantageous than having to use their spare CPU cycles to only generate a capped amount per day.
To be honest, I don't see what more harm a botnet can make if we changed to the suggested model. Economically, it would be just like 1,000 honest members joined the network. This can even help the project with some free advertising on security blogs
The number of blocks generated per day can not be easily increased or decreased because there has to be enough time to propagate the blocks to all other nodes while still being frequent enough to allow timely transactions. What can vary is the amount of bitcoins per block. The amount of bitcoins awarded per block can either increase, decrease or stay constant over time. If every person had an equal amount of CPU cycles at his disposal, I would prefer for the amount of bitcoins awarded per generated block to increase proportionally to the amount of CPU used to generate bitcoins. As it is, I'm in favor of the amount staying constant over time.
How about a middle solution then? For example, the default difficulty be adjusted to about 1 block/CPU/day (assuming an average 2.4 GHz processor), but in case more than X blocks/day was being created (X = the maximum # of daily blocks afterwhich there is no enough time for propagation across the network), then difficulty gets automatically adjusted. Practically, it would end up being like my second-best and your best model. In other words, very close to the current situation except that we assume the current 4-years-period is extended to forever. So let's at least agree that the removal of the 4-year thing and the 21M limit is essential to avoid an ever-deflating currency.
He was referring to the price of goods decreasing as value of a bitcoin increases. Eventually the value of bitcoins will go high enough and the price of the goods will go low enough that the person will feel rich enough to spend his bitcoins. To take it to an extreme, if a person has ten thousand bitcoins and can buy the TV of his dreams for one bitcoin, the value of having the TV now is greater than the future potential increased value of the one 10,000th of his total bitcoins.
You only switched the problem to another user then: The TV seller! He would also keep this coin until he has 10,000 coins. The point is that it's very hard (albeit not impossible) to convince people to spend or transfer a coin they are pretty sure will be 19% more valuable within a year. Moreover, economic-savvy folks might as well choose not to join the network if they predict this will happen, or join it with the intent of \"hitting-and-running\" a quick profit before the system's failure becomes imminent, and they will be right.
The problem with botnets is that their operators are stealing electricity, bandwidth and access to RAM, hard drive space and CPU time. Everyone else is paying for those resources out of their own pockets.
The order of my preferences for how I would like bitcoin to work is first, for the amount of bitcoins awarded to stay constant as I
previously described, second, for the amount of bitcoins awarded to increase at a constant rate, third, for the amount of bitcoins awarded to decrease at a constant rate, last and least, for the amount of bitcoins awarded to increase at a variable rate. If botnets did not exist than the variable option would be at the top of my list instead of the bottom.
EDIT: My new highest preference for how I would like bitcoin to work is for the amount of bitcoins awarded to increase at the same rate as worldwide human population growth.
If the TV buyer is an early adopter and the TV seller is a latecomer, then the TV buyer already has many bitcoins and it would cost the TV seller more dollars worth of electricity than the price of the TV to generate 1 bitcoin. I do not agree that it will be hard to get people to spend their bitcoins. People do value potential future increases, but they also value having an item now. Why would someone borrow money on a credit card with a 19% interest rate instead of keeping their money in their savings account? They do it because they value having the TV now more than the potential losses over time. Life is short. You're welcome to save all your high returning money until the day you die, but the rest of us are going to make use of it before it's no use to us.
Heck, just look at NewLibertyStandard's graph. It will keep shooting up as long as this 4-year model continues.
My exchange rate will only increase as Bitcoin becomes more popular. There are practical limits to the popularity of Bitcoin. Sure, potentially it could be run on every functional computer around the world, but from practical perspective, that will never happen. The swarm is currently pretty small, so when a few new users join, there is a large effect on my exchange rate and it increases fairly quickly. As the rate of growth slows or reverses and as my exchange rate average increases over the next two years, the exchange rate will steady out with only very small increases AND decreases every day. As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy. In any case, hopefully by then there will be other ways of calculating the value of a bitcoin other than my single solitary exchange service.
No. Gold was synonymous to \"money\". Things were valued for how much gold they were worth, not vice versa.
In school, they taught us (i.e. me) that a good's
value price is based solely on what people can exchange it for. They also taught us that a good's value was
not determined by how much labor went into the good.
We were essentially told that if one camel is worth 50 gold dinars, then 50 gold dinars is also worth one camel. Or something to that effect.
If this is the case, then the cost of producing bitcoins would only a be a factor in, not a determinant of, their value.
Did I understand the lesson correctly?
_______________________________________________________________________________
______________________________
On the general topic of whether bit-coin will/will not be successful--I don't really know. I act as though I am a \"bitcoin defender\" but this is mostly because I am excited about the new currency and want to support it, not because I know enough about economics to predict it's eventual usefulness.
I would very much like to see people who dislike bitcoin's design organize and code alternative currencies that inflate according to a monetary rule, or have the built in safeguards you described. That way, the market will eventually choose the best currency as people move towards the good ones and away from the bad.
I am not sure if bitcoin's creators will be convinced to implement the changes you recommend--but i think you are very likely to find people who agree with your plan for a better encrypted digital currency and will help you modify or re-write bitcoin's source to make it happen.
The problem with botnets is that their operators are stealing electricity, bandwidth and access to RAM, hard drive space and CPU time. Everyone else is paying for those resources out of their own pockets.
That's not a problem for Bitcoin or its users. If those CPU cycles aren't used to steal electricity for bitcoin, they'd be used to steal electricity to DDoS some site or brute-force some account. We shouldn't worry about them. As I said, they're just as if those users voluntarily joined the network for all practical purposes.
EDIT: My new highest preference for how I would like bitcoin to work is for the amount of bitcoins awarded to increase at the same rate as worldwide human population growth.
\"Human population\" is totally irrelevant. Even if human population was shrinking by, say 1% annually now, I assure you that Internet users population will be increasing and bitcoin users will be increasing at an even higher rate. \"Bitcoin users\" is the magic word here. With the suggested variable model, we're always sure that new coin generation matches the expanding (or shrinking) user base. But anyway, I see that you're beginning to side with me that the 4-year-doubling isn't a good idea.
If the TV buyer is an early adopter and the TV seller is a latecomer, then the TV buyer already has many bitcoins and it would cost the TV seller more dollars worth of electricity than the price of the TV to generate 1 bitcoin.
Man, if you paid $1,000 for an ounce of gold, then a few months later it was worth $2,000, are you going to sell it for $1,000?! No? Good. Because the early adopter will not treat his coins as if they're worth the pennies he paid for them anymore now that they're worth a ton of electricity. He'd treat them for what they're worth today.
I do not agree that it will be hard to get people to spend their bitcoins. People do value potential future increases, but they also value having an item now. Why would someone borrow money on a credit card with a 19% interest rate instead of keeping their money in their savings account? They do it because they value having the TV now more than the potential losses over time. Life is short. You're welcome to save all your high returning money until the day you die, but the rest of us are going to make use of it before it's no use to us.
My answer is simple: Assuming people approve the current Bitcoin's model, it will turn out to be the #1 worldwide investment: Just buy (or hack) a bunch of PCs, let them run, and you'll be earning at least 19% annually with no risk involved! Investors (and indeed, botnets) won't leave a chance for normal folks like you and me to earn any BTCs much less spend them. Any bitcoin will be spent 2-3 times at most before falling into the hands (well, \"the computers\" is the better term here) of an investor who'll keep it for a very long time or forever. This model has to change or it will destroy the otherwise excellent idea. Making bitcoin a way to INVEST rather than to SPEND is its one-way ticket to failure. You also forgot that bitcoins will leave the stream all the time (eg. computer failures or accidental deletion), which will add to their deflating. Might as well turn this 19% into 20% or something.
My exchange rate will only increase as Bitcoin becomes more popular. There are practical limits to the popularity of Bitcoin. Sure, potentially it could be run on every functional computer around the world, but from practical perspective, that will never happen. The swarm is currently pretty small, so when a few new users join, there is a large effect on my exchange rate and it increases fairly quickly. As the rate of growth slows or reverses and as my exchange rate average increases over the next two years, the exchange rate will steady out with only very small increases AND decreases every day.
Even if we assume that Bitcoin's current users will never increase (thus not making it more difficult to generate coins), we're sure that its value will increase by at least 19% annually because of the expected 4-year-old D-day when which all BTCs price magically doubles because it will cost double to generate them.
As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy.
Can you explain that part? I didn't understand how multiplying by two will achieve stability.
PS. It might be a good idea to merge your previous double-posts in one via Edit to make reading easier for us and those following us. The world is watching (or some three-letter-agencies anyway
)
We were essentially told that if one camel is worth 50 gold dinars, then 50 gold dinars is also worth one camel. Or something to that effect.
If we assume that dinars can't be used for any other non-monetary purposes (such as jewelry, paperweights, etc), then it's practically very difficult for them to have a demand curve by themselves. Camels can be used to ride, so their gold price fluctuated (i.e. They become more or less popular with time). Bitcoin can only be used as money, so it's used solely to value things not vice versa.
Did I understand the lesson correctly?
If raising a camel costed more than 50 dinars, you can count on people stopping raising camels until the price goes back up due to supply shortage. With the absolutely arbitray 4-year model, this can never happen. Supply will ALWAYS decrease no matter what. I'm asking for a more flexible method which depends on the actual number of users.
On the general topic of whether bit-coin will/will not be successful--I don't really know. I act as though I am a \"bitcoin defender\" but this is mostly because I am excited about the new currency and want to support it, not because I know enough about economics to predict it's eventual usefulness.
If I wasn't, I wouldn't be here crying my lungs out to correct the model for a one which will work!
but i think you are very likely to find people who agree with your plan for a better encrypted digital currency and will help you modify or re-write bitcoin's source to make it happen.
I know practically nothing about programming or coding. I'm interested in economics (as you might have guessed
) and was trying to offer a bit of advice to the geeks who do the coding.
As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy.
Can you explain that part? I didn't understand how multiplying by two will achieve stability.
I use a formula to calculate my exchange rate which is described on my
exchange rate page. When I generate my first block of \u0e3f25 rather than \u0e3f50, I can simply change my formula to multiply bitcoins generated by two which will turn that \u0e3f25 into \u0e3f50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.
I absolutely disagree that the current model is unsustainable and I absolutely disagree that people will not spend their bitcoins. If I had my druthers, the amount of bitcoins awarded would grow at the same rate as worldwide human population growth, but it doesn't matter because druthers are just druthers and they ain't important at all.
I use a formula to calculate my exchange rate which is described on my
exchange rate page. When I generate my first block of \u0e3f25 rather than \u0e3f50, I can simply change my formula to multiply bitcoins generated by two which will turn that \u0e3f25 into \u0e3f50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.
OMG. The moment you do that you'll run out of coins immediately because buying them from you would cost only half as much as generating them!
I absolutely disagree that the current model is unsustainable and I absolutely disagree that people will not spend their bitcoins.
Fine. But until someone answers the numerous doubts I've raised in here, I (and anyone with basic economics background) won't believe Bitcoin's current model has a promising future.
If I had my druthers, the amount of bitcoins awarded would grow at the same rate as worldwide human population growth
But I already explained why that was irrelevant. Oh well... nevermind.
I use a formula to calculate my exchange rate which is described on my
exchange rate page. When I generate my first block of \u0e3f25 rather than \u0e3f50, I can simply change my formula to multiply bitcoins generated by two which will turn that \u0e3f25 into \u0e3f50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.
OMG. The moment you do that you'll run out of coins immediately because buying them from you would cost only half as much as generating them!
I will always have dollars and bitcoins available to inject into my exchange service. I may run out today, but there will always be more available tomorrow. It's all detailed on
my exchange rate page.
Fine. But until someone answers the numerous doubts I've raised in here, I (and anyone with basic economics background) won't believe Bitcoin's current model has a promising future.
Fine. But regardless of whether someone answers the numerous doubts you've raised in here, I (and anyone with advanced economics background) will believe Bitcoin's current model has a promising future.
Nothing to sweat people. Nobody ever died of a 'deflationary spiral.'
I agree with \"I-am-not-anonymous.\" The market will choose the best bitcoin-like currency. I happen to believe, however, that the rules that Satoshi has founded bitcoin on will be more than adequate for the future of a thriving bitcoin economy.
Everybody knows exactly how fast the supply of bitcoins will grow: it's set in stone in the rules of the programming and the bitcoin network. While it's true that there is not a currently existing fully-fleshed out market to truly price bitcoins, such markets and exchanges are being developed. As far as future would-be bitcoin generators are concerned, the question is not how much will he \"demand....to compensate for his costs.\" The question he'll be asking himself is \"given current market values and my ability to utilize electricity and CPU resources, is it worth it for me to generate bitcoins?\" If the answer is yes, he participates. If it's no, he stops trying to mine for bitcoins and focuses on trading tangible assets with bitcoins serving as an appropriate intermediary. If he's not sure, he tries his hand at it for a while and then makes a final decision.
The number of nodes and associated computational cpu power will be in flux, and that competitive flux will allow for costs to approximate value (not the other way around.) Value being set by the markets and the demand for use of bitcoin as a trade intermediary (a money). In the far future, the competition of transaction costs will play a more important role for the would-be node operator.
Contrary to the paradox of thrift argument you present, collecting bitcoins and saving them with hopes of earning purchasing power through deflation is not a bad thing. It will allow for the pooling of bitcoin capital and make purchases of larger capital investments possible. In the future, there might even be bitcoin banks that lend out saved bitcoins with market-set interest rates, thereby diminishing the effects of hoarding. All this wonderful saving, however, comes at a price: delayed gratification of present desires. From the perspective of the would-be saver, the question will always be denying present desires to purchase real tangible assets now versus the future possibilities of purchasing more later. This time preference naturally varies with people and in different circumstances.
Given the fact that bitcoins are by their electronic nature easily divisible, prices will be able to easily adjust to deflationary pressures. If too many are saving, prices will fall and the rate of interest will go down. This encourages demand (lower prices) and decreases the desire to save (less interest).
XC
Excellent analysis, xc.
A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing.
In the absence of a market to establish the price, NewLibertyStandard's estimate based on production cost is a good guess and a helpful service (thanks). The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.
In later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around.
At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.
",
"nested_level": 0
},
{
"id": 346,
"thread_id": 32,
"source_id": "1",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Number of connections",
"url": "https://bitcointalk.org/index.php?topic=58.msg403#msg403",
"date": "2010-02-19T00:12:56Z",
"text": "Is there some hard-coded maximum limit for the amount of connections? I see 45 connections atm. It's been growing nicely in the last months. Just can't get that many coins anymore...
",
"nested_level": 0
},
{
"id": 347,
"satoshi_id": 63,
"thread_id": 32,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Number of connections",
"url": "https://bitcointalk.org/index.php?topic=58.msg413#msg413",
"date": "2010-02-21T03:43:48Z",
"text": "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 connections. Maybe it should be 10.
Since nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium. 45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node.
The number of connections won't be a good gauge of the size of the network any more. Someone should periodically IRC to the bitcoin channel on chat.freenode.net and count the number of users. That gives you the total count of network nodes (except TOR nodes).
Block generation is again running ahead of pace. We're in for another big step up in difficulty at the next adjustment in about 5 days.
",
"nested_level": 0
},
{
"id": 348,
"satoshi_id": 64,
"thread_id": 33,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Post your static IP",
"url": "https://bitcointalk.org/index.php?topic=59.msg414#msg414",
"date": "2010-02-21T04:19:53Z",
"text": "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 IPs should be considered a donation.
If you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it'll be one-way. They won't necessarily be watching for incoming transactions to send back.
",
"nested_level": 0
},
{
"id": 349,
"satoshi_id": 66,
"thread_id": 34,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg426#msg426",
"date": "2010-02-21T21:48:01Z",
"text": "Uploaded some UI changes to SVN as version 0.2.5.
Instead of View->Show Generated, we now have tabs:
- All Transactions
- Sent/Received
- Sent
- Received
Makes it a lot easier to flip to received and check for payments.
Moved the \"Your Addresses\" book inside the main address book. It was confusing having two address books.
I found the \"To:\" in \"From: unknown, To: (one of your bitcoin addresses)\" still confusing, so I changed it to \"From: unknown, Received with:\". The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book.
Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.
I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing.
",
"nested_level": 0
},
{
"id": 350,
"thread_id": 34,
"source_id": "2",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg427#msg427",
"date": "2010-02-21T22:00:09Z",
"text": "These improvements sound good. Thank you for your continued development of the application. As a suggestion, you could consider shortening \"From: unknown, Received with:\" to \"From: unknown, Paid to:\"
",
"nested_level": 0
},
{
"id": 351,
"thread_id": 34,
"source_id": "3",
"poster_name": "giik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=29",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg432#msg432",
"date": "2010-02-22T20:04:42Z",
"text": "When you merged the \"your addresses\" and \"the other addresses\", how can you see the difference between them? Perhaps it is better to build version 0.2.5 myself, but does anyone have a guide to build it on Mac OS X 10.6?
",
"nested_level": 0
},
{
"id": 352,
"satoshi_id": 68,
"thread_id": 34,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg434#msg434",
"date": "2010-02-23T01:16:28Z",
"text": "There are now \"Sending\" and \"Receiving\" tabs in the Address Book. Your addresses are referred to as \"receiving addresses\".
madhatter was working on building it on Mac. He had errors probably caused by UTF-16 wxWidgets 2.8. Should have better luck now with 2.9.0. wxWidgets 2.9.0 is UTF-8 and wouldn't have that problem.
I think he had it working on FreeBSD, but he wanted a non-UI version.
I have the command line and JSON-RPC daemon version working now. Will SVN it in a day or two.
I disabled gdm on my Ubuntu system so it boots into command line. I hope I will be able to get it enabled again with rcconf.
",
"nested_level": 0
},
{
"id": 353,
"thread_id": 34,
"source_id": "5",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg438#msg438",
"date": "2010-02-23T12:09:58Z",
"text": "In Ubuntu you can also switch to a non-graphical login screen by pressing ctrl + alt + F[1-8].
",
"nested_level": 0
},
{
"id": 354,
"thread_id": 34,
"source_id": "6",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg439#msg439",
"date": "2010-02-23T12:28:27Z",
"text": "And you can login to one of the TTY1-8 (what sirius-m was talking about) and execute /etc/init.d/gdm start and it will start gdm!
",
"nested_level": 0
},
{
"id": 355,
"satoshi_id": 70,
"thread_id": 34,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: UI improvements",
"url": "https://bitcointalk.org/index.php?topic=60.msg446#msg446",
"date": "2010-02-23T16:53:27Z",
"text": "/etc/init.d/gdm start and it will start gdm!
Ah yes, there we go, back to normal again.
The ctrl+alt+F[1-8] thing never worked on this computer. The screen just goes haywire.
Am I the only one seeing minuscule generation lately? It was decent until around 20:00 GMT February 21st, but after that my machine (4 core I7) produced only one block for entire >12 hours. And there isn't even a clue for new difficulty hike in the debug log.
Here are my possible scenarios:
1. Some big BC bot came along.
2. Someone is trying some kind of DoSing the system.
3. Someone built a bitcoin mod with GPGPU (CUDA or sorts) support.
4. Some kind of growth problem (i.g. we reached first of a kind network size and there is problem with that).
Ideas?
",
"nested_level": 0
},
{
"id": 357,
"thread_id": 35,
"source_id": "2",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: generation slowed down dramatically",
"url": "https://bitcointalk.org/index.php?topic=61.msg429#msg429",
"date": "2010-02-22T14:39:40Z",
"text": "Ideas? I would want a copy of this hypothetical CUDA-enabled client. However, I doubt that GPGPU acceleration would affect generation speeds very much. Only the most expensive of modern graphics cards have a clock speed of over 1 Ghz, after all.
",
"nested_level": 0
},
{
"id": 358,
"thread_id": 35,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: generation slowed down dramatically",
"url": "https://bitcointalk.org/index.php?topic=61.msg431#msg431",
"date": "2010-02-22T19:33:53Z",
"text": "No problem here. Other clients just happened to generate those blocks before you.
",
"nested_level": 0
},
{
"id": 359,
"satoshi_id": 67,
"thread_id": 35,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: generation slowed down dramatically",
"url": "https://bitcointalk.org/index.php?topic=61.msg433#msg433",
"date": "2010-02-23T00:49:56Z",
"text": "Just a random streak of bad luck. It looks steady to me.
Competition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.
The adjustments are every 2016 blocks. To calculate our progress towards the next one, divide the block total by 2016. The fractional part is how far we are to the next one.
My back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way. About 1.5 days to go until the next one. That'll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase.
",
"nested_level": 0
},
{
"id": 360,
"thread_id": 36,
"source_id": "1",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Bitcoin Address Collisions",
"url": "https://bitcointalk.org/index.php?topic=62.msg435#msg435",
"date": "2010-02-23T03:46:44Z",
"text": "Although extremely unlikely, what would happen if two Bitcoin clients generated the same Bitcoin address? Would payments be delivered to whichever client encountered the payment first? If there is a mechanism in place to prevent such collisions, please explain it.
",
"nested_level": 0
},
{
"id": 361,
"thread_id": 36,
"source_id": "2",
"poster_name": "ec",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=42",
"subject": "Re: Bitcoin Address Collisions",
"url": "https://bitcointalk.org/index.php?topic=62.msg436#msg436",
"date": "2010-02-23T08:25:17Z",
"text": "For two addresses to be equal, two identical private/public elliptical curve (ec
) keys have to be generated. Without looking at the source code, let's assume the probability for this is 2^(-128) for a keyspace of 128 bits. See
here for a perspective on how probable it is with a 122 bit collision.
However, if something similar to the
Debian ssl-scandal happens, similar keys could indeed be generated. The effect of an individual generating an existing key, is (if I understand it correctly) in effect to make a copy of wallet.dat. Not good at all, but not devastating for all the members of the p2p network.
Are you referring to the private key which is generated the first time a person runs Bitcoin? If someone were to successfully duplicate someone else's key then after they downloaded all the blocks, they would have the same balance as the person with the original key. That's what you're saying, right?
I was referring to the custom Bitcoin addresses which you can label with the name of the person who is going to send you bitcoins so that you know from whom the payment came. I think these addresses are generated from the private key mentioned previously. I'm wondering about collisions because although they are very unique, they are easily generated over and over again by all by all bitcoin clients.
",
"nested_level": 0
},
{
"id": 363,
"thread_id": 36,
"source_id": "4",
"poster_name": "ec",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=42",
"subject": "Re: Bitcoin Address Collisions",
"url": "https://bitcointalk.org/index.php?topic=62.msg442#msg442",
"date": "2010-02-23T16:17:56Z",
"text": "Are you referring to the private key which is generated the first time a person runs Bitcoin? If someone were to successfully duplicate someone else's key then after they downloaded all the blocks, they would have the same balance as the person with the original key. That's what you're saying, right?
Yes, that is correct. They would share the wallet, and it becomes a race on spending the money first.
I was referring to the custom Bitcoin addresses which you can label with the name of the person who is going to send you bitcoins so that you know from whom the payment came. I think these addresses are generated from the private key mentioned previously. I'm wondering about collisions because although they are very unique, they are easily generated over and over again by all by all bitcoin clients.
If I read the source code correctly, keys are always made in pairs. That means, every address has an associated private key. When you click \"New Address\", you call GenerateKey in main.cpp, which generates a new key pair. So the duplicate address is ultimately a duplicate public key. Which is
very unlikely.
While keys still are \"easily generated\", you should have to generate a whole lot of keys before a collision. While I am not certain, it seems that the keys generated have a space of 256 bits, which is a lot more than the 122 bits put in perspective in the wikipedia article on uuids. Remember, 123 bits have half the probability of collision as 122 bit, 124 half of that again etc.
There's a separate public/private keypair for every bitcoin address. You don't have a single private key that unlocks everything. Bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit.
If there was a collision, the collider could spend any money sent to that address. Just money sent to that address, not the whole wallet.
If you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block. You could have got a lot more money by generating blocks.
The random seed is very thorough. On Windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc. since your computer started. Linux has a built-in entropy collector. Adding to that, every time you move your mouse inside the Bitcoin window you're generating entropy, and entropy is captured from the timing of disk ops.
",
"nested_level": 0
},
{
"id": 365,
"thread_id": 36,
"source_id": "6",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Bitcoin Address Collisions",
"url": "https://bitcointalk.org/index.php?topic=62.msg450#msg450",
"date": "2010-02-23T19:04:47Z",
"text": "Thanks for the explanation. I think it all makes sense.
Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window? I may have mentioned this in an email message quite a while ago, but it would be cool for some very future version to allow people to see which of their bitcoins are encrypted with which of their addresses.
",
"nested_level": 0
},
{
"id": 366,
"satoshi_id": 72,
"thread_id": 36,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin Address Collisions",
"url": "https://bitcointalk.org/index.php?topic=62.msg453#msg453",
"date": "2010-02-23T22:24:00Z",
"text": "Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?
No, each generated transaction uses a new, single-use address.
Nothing uses the address in the main window, it's just there for convenience for you to copy. 0.2.5 has a \"New...\" button next to it to make it easy to change each time you use it.
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 installed.
The command to start as a daemon is:
bitcoin -daemon [switches...]
Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the \"-server\" switch.
bitcoin -server [switches...]
With either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332. The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it's running under.
To control it from the command line, the interface is a command name without any switches, followed by parameters if any.
bitcoin <command> [params...]
For example:
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop
It's a simple JSON-RPC client and prints the JSON result. Look at rpc.cpp for the list of commands.
Web apps or anything automated will normally use JSON-RPC directly, not command line. There are JSON-RPC libraries for all the major languages. In script languages like PHP and Python the syntax is as natural as calling a local function.
",
"nested_level": 0
},
{
"id": 368,
"thread_id": 37,
"source_id": "2",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg459#msg459",
"date": "2010-02-24T02:29:17Z",
"text": "Oh thank you!
You have no idea how badly I needed something like this.
I will have a payment library built in no time.
On Linux it needs libgtk2.0-0 installed
Will this requirement be removed sometime? I'd rather not have to deal with GTK.
Gtk is required by the GUI, so it must be linked if you want to use the same binary. Making a separate binary is another option, dunno how much code tweaking and ifdeffing that would take.
",
"nested_level": 0
},
{
"id": 371,
"thread_id": 37,
"source_id": "5",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg478#msg478",
"date": "2010-02-24T05:00:45Z",
"text": "* madhatter2 pulls out razor sharp hex editor
On Linux it needs libgtk2.0-0 installed
Will this requirement be removed sometime? I'd rather not have to deal with GTK.
How much \"dealing with\" does GTK actually require? Is it just a matter of \"sudo apt-get install libgtk2.0-0\" and having some extra libraries sitting around? GTK doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it's done.
It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK.
*NIX peoples are \"purists\" of sorts. They don't like to pollute their OS installs with libraries that shouldn't be necessary.
A million ifdefs are not the answer either. Hmm.. more thought to this may be required.
On Linux it needs libgtk2.0-0 installed
Will this requirement be removed sometime? I'd rather not have to deal with GTK.
How much \"dealing with\" does GTK actually require? Is it just a matter of \"sudo apt-get install libgtk2.0-0\" and having some extra libraries sitting around? GTK doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it's done.
It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK.
I'm using Linux From Scratch, so installing a dependency-ridden package like GTK would be a bit of a pain. Why should I add a dozen additional packages and hundreds of megabytes to my system when BitCoin doesn't even use them?
",
"nested_level": 0
},
{
"id": 375,
"thread_id": 37,
"source_id": "9",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg493#msg493",
"date": "2010-02-24T07:56:18Z",
"text": "Why would you install them? Because you currently have to. I know the feeling. I run minimalist FreeBSD servers and to clutter them with X libraries is a pain.
However, installing them onto a X workstation is totally fine -- you usually have all of the correct dependancies already.
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.
",
"nested_level": 0
},
{
"id": 377,
"satoshi_id": 77,
"thread_id": 37,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg509#msg509",
"date": "2010-02-24T22:08:55Z",
"text": "When and how fast did memory usage increase? Right away, slowly over a long time, or starting at some later event?
I have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.
It has to be something about the difference on the server besides 64-bit. Maybe some malfunction from the lack of GUI. A memory leak debug tool could give a clue.
",
"nested_level": 0
},
{
"id": 378,
"thread_id": 37,
"source_id": "12",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg538#msg538",
"date": "2010-02-25T16:32:17Z",
"text": "It started increasing right away. I'll see if valgrind can help me.
",
"nested_level": 0
},
{
"id": 379,
"satoshi_id": 80,
"thread_id": 37,
"source_id": "13",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg539#msg539",
"date": "2010-02-25T22:54:17Z",
"text": "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. We only have four functions that interface from the node to the UI. In the bitcoind build, we don't link ui.o or uibase.o.
It started increasing right away. I'll see if valgrind can help me.
Sure feels like it could be something in wxWidgets retrying endlessly because some UI thing failed or something wasn't inited correctly. Our hack to ignore the initialize failure and run anyway means we're in uncharted territory. We're relying on the fact that we hardly use wx in this mode. We do still use a few things like wxGetTranslation and wxMutex.
Another way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it's doing.
I suspect bitcoind will probably work fine, but I hope you can still debug the problem.
I'm getting errors when trying to compile with just wxBase.
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/opt/tdep/include\" -I\"/usr/include\" -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp
In file included from util.cpp:5:
headers.h:22:24: error: wx/clipbrd.h: No such file or directory
In file included from headers.h:100,
from util.cpp:5:
db.h: In member function 'bool CDB::Exists(const K&)':
db.h:140: error: 'class Db' has no member named 'exists'
make: *** [obj/nogui/util.o] Error 1
Clipbrd.h isn't installed with wxBase. Moving wxWidgets-2.9.0/include/wx/clipbrd.h to my include directory just eliminates those two \"no such file\" lines.
wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.
Updated headers.h on SVN.
Sorry, I linked to wxbase but I had full wxWidgets on my computer.
The db.h:140 class Db no member named \"exisits\" is stranger. pdb->get, pdb->put, pdb->del compiled before that. Do you have version 4.7.25 of Berkeley DB?
Db::exists()
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.htmlhttp://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.htmlI suppose they might have added exists recently, using get before that.
I'm using Berkeley DB 4.5.20.
",
"nested_level": 0
},
{
"id": 383,
"thread_id": 37,
"source_id": "17",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg558#msg558",
"date": "2010-02-26T19:37:50Z",
"text": "Using DB-4.7.25 fixed that problem.
I'm now getting this error, though:
g++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/opt/tdep/include\" -o bitcoind -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/opt/tdep/lib\" obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -l wx_baseu-2.9 -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l crypto -l gthread-2.0
obj/nogui/init.o: In function `wxArrayString::Item(unsigned int) const':
init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x7): undefined reference to `wxTheAssertHandler'
init.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x42): undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
collect2: ld returned 1 exit status
make: *** [bitcoind] Error 1
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.
",
"nested_level": 0
},
{
"id": 385,
"thread_id": 37,
"source_id": "19",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: Command Line and JSON-RPC",
"url": "https://bitcointalk.org/index.php?topic=63.msg564#msg564",
"date": "2010-02-27T03:21:23Z",
"text": "The headless mode is incredibly usefull. Finally I can start generating on my servers in the night
Cool; it works!
Thanks for your help!
I am using 2.9.0.
(No memory issues for me.)
That wchar thing was what I was stuck on for the OSX build.
Glad to see it is ironed out. I'll keep hacking away now.
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.
New icons, what do you think? Better than the old one?
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin16.4.png&t=589&c=nbQh6wpencehMQ\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin20.4.png&t=589&c=fFlL6ruPQ7IGHA\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin32.5.png&t=589&c=U22oaajL6w5RyA\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin48.5.png&t=589&c=EvOpR1UIrHi0BA\"/)
Full size 530x529 image for scaling down to custom sizes:
http://www.bitcoin.org/download/bitcoin530.pngThe perspective shadow was too thick on the larger sizes. I updated 32, 48 and the full size.
I release these images into the public domain (copyright-free). I request that derivative works be made public domain.
Pretty...
",
"nested_level": 0
},
{
"id": 391,
"thread_id": 38,
"source_id": "3",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg519#msg519",
"date": "2010-02-25T01:47:56Z",
"text": "I like them. Do they come in higher resolutions?
",
"nested_level": 0
},
{
"id": 392,
"satoshi_id": 79,
"thread_id": 38,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg521#msg521",
"date": "2010-02-25T01:56:24Z",
"text": "I like them. Do they come in higher resolutions?
Yes, the original is 546x531 pixels.
It looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first. I'll post larger sizes and full size a little later.
I still dislike the currency symbol ... But at least the logos look good and clean.
",
"nested_level": 0
},
{
"id": 394,
"thread_id": 38,
"source_id": "6",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg525#msg525",
"date": "2010-02-25T02:28:49Z",
"text": "I like them. Do they come in higher resolutions?
Yes, the original is 546x531 pixels.
Excellent. This would be a good resource for those participating in the banner contest. Why unequal dimensions?
My only suggestion would be to make the coin's text stand out more. At tiny resolutions outlines tend to be come unworkable, so a better option may be to experiment with contrast. Making the text significantly darker than the rest of the coin would likely increase readability. Alternately, you could make the inner circle color darker, and the text lighter.
Good suggestion. I made the B slightly lighter and the background slightly darker. Very slightly. The foreground is now exactly the same colour as the BC in the old one.
It's kind of OK if you can't easily read the B in the 16x16. At that size, you just need to see that it's a coin. It doesn't matter so much what's embossed on it, just that there be some detail there because it wouldn't look like a coin if it was a blank smooth circle.
It's slightly wider than tall because the dark perspective under it goes more to the right than down.
I finished and posted the 32x31 and 48x47 versions in the first message. I like the 48 a lot.
How does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo?
",
"nested_level": 0
},
{
"id": 396,
"thread_id": 38,
"source_id": "8",
"poster_name": "ihrhase",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=45",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg563#msg563",
"date": "2010-02-27T03:12:42Z",
"text": "Works for me...
",
"nested_level": 0
},
{
"id": 397,
"thread_id": 38,
"source_id": "9",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg565#msg565",
"date": "2010-02-27T03:24:07Z",
"text": "How about an SVG version? That way we could automatically generate smaller and larger versions as needed, and storage in the Source Control Management is an option too.
",
"nested_level": 0
},
{
"id": 398,
"satoshi_id": 85,
"thread_id": 38,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg566#msg566",
"date": "2010-02-27T04:28:29Z",
"text": "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.
When you use SVG or another vector-format, you don't have the problems you discribed when scaling the logo. Perhaps I'll give it a go in Illustrator.
",
"nested_level": 0
},
{
"id": 400,
"satoshi_id": 87,
"thread_id": 38,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg588#msg588",
"date": "2010-03-02T02:33:05Z",
"text": "We have the standard icon sizes, and the full size scales nicely to anything else.
I added the full size to the first post.
",
"nested_level": 0
},
{
"id": 401,
"thread_id": 38,
"source_id": "13",
"poster_name": "Sabunir",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=28",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg590#msg590",
"date": "2010-03-02T04:16:41Z",
"text": "Thank you. I have updated my \"Accept Bitcoin\"
buttons and
banner (version twos) to use your new coin.
Here's a vector graphic (SVG). I'm no expert, so it may not be optimal, but it should work for the most part.
http://www.shalhoon.com/bitcoin.svg(You may need to right-click and \"Save As...\" if your browser thinks it knows how to display it).
After some toying, this one seems a bit more crisp.
http://www.shalhoon.com/bitcoin2.svgI also made an SVG version. It's not as shiny as the original logo, though.
",
"nested_level": 0
},
{
"id": 405,
"thread_id": 38,
"source_id": "17",
"poster_name": "ArrowJ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=605",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg19658#msg19658",
"date": "2010-11-02T06:21:14Z",
"text": "Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.
There is at least one other thread with a set of logos and badges that are really, really promising here:
http://bitcointalk.org/index.php?topic=1631.0 I promise I don't know this guy/gal (I didn't even check the username). Heck if someone else came up with another alternative that would be cool too. It seems important that we have a really nice logo with all the sizes, resolutions, and formats that might be needed.
Is there a reason we couldn't adopt something else before bitcoin gets too big and it's too late to change without hurting \"brand\" recognition? It seems silly to stick with something that is \"ok\" when we could have something great.
I hope I didn't step on anyone's toes to badly.
Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.
There is at least one other thread with a set of logos and badges that are really, really promising here:
http://bitcointalk.org/index.php?topic=1631.0 I promise I don't know this guy/gal (I didn't even check the username). Heck if someone else came up with another alternative that would be cool too. It seems important that we have a really nice logo with all the sizes, resolutions, and formats that might be needed.
Is there a reason we couldn't adopt something else before bitcoin gets too big and it's too late to change without hurting \"brand\" recognition? It seems silly to stick with something that is \"ok\" when we could have something great.
I hope I didn't step on anyone's toes to badly.
Satoshi created bitcoin so that is his preferred one hence it is the \"official\" one. The project is open source so if you can come up with something better people will adopt it. Thats the nature of things and of bitcoin itself.
What exactly is your issue with the \"official\" logo?
ArrowJ is right, image is everything, and its best left to the Pro's. (i.e. Not me.)
That said, the name \"Bitcoin\" is pretty uninspiring start for a Graphic Designer, IMO. (But that is a whole other discussion.)
Kudos to Bitboy on his contribution, this kind of simple smooth and sharp image instantly tells the viewer that we are in 2010.
",
"nested_level": 0
},
{
"id": 408,
"thread_id": 38,
"source_id": "20",
"poster_name": "ShadowOfHarbringer",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1775",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg19670#msg19670",
"date": "2010-11-02T10:46:19Z",
"text": "Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.
Stop complaining. The current logo is just good enough.
It has all the properties a good logo should have.
PS.
After bitcoin goes mainstream, satoshi will be incredibly rich and he can afford some professional artist to polish it more
PS2.
After some consideration, i think that the logo could be easily polished a little by adding some more 3D-effect to the coin borders, so it would actually look like a real coin. But the rest is 100% OK.
...The project is open source so if you can come up with something better people will adopt it...
I don't personally have the skills, but again, I think
http://bitcointalk.org/index.php?topic=1631.0 is a great choice.
\"What exactly is your issue with the \"official\" logo?\"
The most recent version isn't as bad as the original, but it is still not a crisp as could be desired, it doesn't scale well, has too many color shades, just has an overall \"generic\" look to it.
Stop complaining. The current logo is just good enough.
It has all the properties a good logo should have.
I'm not actually complaining...just voicing an alternative opinion related to the quality of the current logo that represents the bitcoin project to most of the outside world. I feel it has few of the aesthetic properties a good logo should have.
I don't see why this can't be discussed without being offensive (I'm trying not to attack anyone personally). I'm not saying anything about the qualities of the designer as a human being...he did after all come up with the cool idea of Bitcoin in the first place, but this does not mean his artwork should be the de facto face of the project IF the goal is to increase it's popularity. It seems to me that the better face we can put on the project the better. Is it bad to strive for fantastic?
After some consideration, i think that the logo could be easily polished a little by adding some more 3D-effect to the coin borders, so it would actually look like a real coin. But the rest is 100% OK.
I personally think less 3D is in order. It's ok for it to be \"abstract\" in that it doesn't look exactly like a coin...I would posit that it would be better if it doesn't try to look like a real coin...after all, we aren't dealing in real coins...we are dealing in BITcoins
I don't see why this can't be discussed without being offensive (I'm trying not to attack anyone personally). I'm not saying anything about the qualities of the designer as a human being...
Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.
You're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.
However i don't know if Satoshi will like the license (cc by-sa).
IMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain.
Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.
You're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.
However i don't know if Satoshi will like the license (cc by-sa).
IMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain.
I'll be honest with you, I thought I had offended with the suggestion.
I hadn't thought of the license issue, but of course your right, whatever logo is used it should probably be public domain. IF the community decided to adopt Bitboy's logo I'd contribute 5 btc to \"buy out\" his license and turn it over to the public domain.
Can this sort of thing be settled with a vote or does it not work that way? I mean we can say it's open source and whatever people use will win, but you have to admit Satoshi's logo has a little bit of an advantage...nobody wants to offend the originator of the awesome idea...I don't want to anyhow...hope I haven't!
Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.
You're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.
However i don't know if Satoshi will like the license (cc by-sa).
IMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain.
I'll be honest with you, I thought I had offended with the suggestion.
I hadn't thought of the license issue, but of course your right, whatever logo is used it should probably be public domain. IF the community decided to adopt Bitboy's logo I'd contribute 5 btc to \"buy out\" his license and turn it over to the public domain.
Can this sort of thing be settled with a vote or does it not work that way? I mean we can say it's open source and whatever people use will win, but you have to admit Satoshi's logo has a little bit of an advantage...nobody wants to offend the originator of the awesome idea...I don't want to anyhow...hope I haven't!
The licence should be the same as the original logo imo because we know for sure that is the one satoshi supports.
Is that a requirement for an open source project though?
",
"nested_level": 0
},
{
"id": 414,
"thread_id": 38,
"source_id": "26",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg19810#msg19810",
"date": "2010-11-03T11:27:01Z",
"text": "Is that a requirement for an open source project though?
No, just for
this open source project, i.e. Satoshi's Bitcoin client.
Is that a requirement for an open source project though?
No its not...but you'd be more likely to get satoshi to support something we know he approves of!
Understood. I had a friend explain some of the ideology a little more clearly to me. Bottom line, I hope we can end up with a top notch professional logo for this project.
",
"nested_level": 0
},
{
"id": 417,
"thread_id": 38,
"source_id": "29",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg19865#msg19865",
"date": "2010-11-03T16:31:22Z",
"text": " I personally think less 3D is in order. It's ok for it to be \"abstract\" in that it doesn't look exactly like a coin...I would posit that it would be better if it doesn't try to look like a real coin...after all, we aren't dealing in real coins...we are dealing in BITcoins
Haha, I agree. Maybe it should be a holo-coin.
I like icons that Satoshi published in the first post.
",
"nested_level": 0
},
{
"id": 419,
"satoshi_id": 500,
"thread_id": 38,
"source_id": "31",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New icon/logo",
"url": "https://bitcointalk.org/index.php?topic=64.msg21766#msg21766",
"date": "2010-11-13T00:55:51Z",
"text": "I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.
It'll be a lot simpler if authors could make their graphics public domain.
",
"nested_level": 0
},
{
"id": 420,
"thread_id": 39,
"source_id": "1",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "wxWidgets 2.9.0",
"url": "https://bitcointalk.org/index.php?topic=65.msg569#msg569",
"date": "2010-02-27T17:09:59Z",
"text": "I'm currently trying to get BitCoin to compile on the openSuse Build Service, which would allow us to create a wide range of precompiled packages for a variety of distros but I'm continually running into problems. The most important of them is the wxWidgets 2.9.0 requirement which is incredibly hard to provide, and the source of many of the problems described on the Forum. Why is it so important to have a 2.9.0? Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
Regards,
cdecker
",
"nested_level": 0
},
{
"id": 421,
"satoshi_id": 86,
"thread_id": 39,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: wxWidgets 2.9.0",
"url": "https://bitcointalk.org/index.php?topic=65.msg571#msg571",
"date": "2010-02-27T21:22:53Z",
"text": "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.
Does anyone happen to know what kinds of regulations are in place for people who buy and sell unofficial digital currencies such as Bitcoin? I'm particularly interested in United States regulations, but please mention any regulations of which you are aware.
Registering a business or non-profit organization gives
the advantage of being able to do transactions in the name of the business and
forming a corporation limits liability. But it seems like it would be more trouble than it's worth to incorporate or register a business until the profits are large enough to hire employees.
I noticed that in the United States, financial institutions are required to submit a
currency transaction report for all transactions over $10,000 and a
suspicious activity report for suspicious transactions. I don't think a private citizen would be required to submit either type of report. In any case, so long as the official currency part of the transaction is passing through a registered financial institution, the institution would already be submitting those reports for such transactions.
I have read about
money laundering and it seems that so long as a person is not knowingly laundering money, then the person is not committing the crime.
Profits would need to be tracked for tax purposes but that can be accomplished easily enough using accounting software such as
GnuCash.
Am I missing anything? Are there any regulations prohibiting me from sending money to and receiving money from random strangers who may be criminals unbeknownst to me?
http://en.wikipedia.org/wiki/E-goldIn 2007 the proprietors of the e-gold service were indicted by the United States Department of Justice on four counts of violating money laundering regulations. In July 2008 the company and its three directors pled guilty to charges of \"conspiracy to engage in money laundering\" and the \"operation of an unlicensed money transmitting business\" in the U.S. District Court for D.C. The company faces fines of $3.7 million.
Running an exchange seems very dangerous. I would never do it without talking to a lawyer and setting up a LLC.
",
"nested_level": 0
},
{
"id": 424,
"thread_id": 40,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Money Transfer Regulations",
"url": "https://bitcointalk.org/index.php?topic=69.msg597#msg597",
"date": "2010-03-02T09:01:53Z",
"text": "Thanks for the reply. I agree that running an exchange does seem dangerous. I have started extremely small and limited my service so that if I am doing something wrong it will hopefully be so minor that I won't be prosecuted and so that if I am convicted of something the fines will be small enough to hopefully not bankrupt me.
I've looked at that E-gold article before but this time I read it, I thought to look up some terms mentioned in it which turned up some interesting regulations concerning
registration of money transmitting businesses and
prohibition of unlicensed money transmitting businesses. I don't know whether my tiny service qualifies as an unlicensed money transmitting business, but if it does, I'll stop until I can get it registered. Although if there's a large non-refundable application fee, I'll have to re-evaluate whether it's worth the cost since I'm currently not trying to earn a profit.
NLS, there is no \"legal\" way to do what you are looking to do on a large scale, knowledge is not necessary for indictment...
You are providing a tax shelter, you should automatically factor in illicit to your \"hobby\"
",
"nested_level": 0
},
{
"id": 426,
"thread_id": 40,
"source_id": "5",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Money Transfer Regulations",
"url": "https://bitcointalk.org/index.php?topic=69.msg601#msg601",
"date": "2010-03-02T15:39:01Z",
"text": "Nah.. you guys have it wrong.
It isn't the written law that you should be concerned with.
You need to rely on your courts to make the 'fair and just' decisions. That is the real problem. I wouldn't dream of running any sort of \"money transmitting business\" (their term) or currency exchange in the USA. (See e-gold and liberty dollar.)
It is probably best to run your exchanger from a different country than the one in which you reside. That would involve a corporation or trustee.
($10,000 OR any \"suspicious\" transaction. That is subject to OPINION.. very open-ended if you ask me. So a court proceeding on failure to report based on suspicion would boil down to \"he who can afford to put forth the most motions in court\"... lol)
Another option is an estoppel. (Again, you need to really know what you are doing.)
Cheers!
Here's the legal definition of currency,
31 C.F.R. \u00a7 103.11(h) and the legal definition of a currency dealer or exchanger,
31 C.F.R. \u00a7 103.11(uu)(1) (both links take you slightly above the definitions). My lawyer friend indicated that that my service seems legal, but that's absolutely not legal advice for you folks. I'm running my little service as honestly and as legally as I know how, so until I find out that I'm doing something wrong, I'm not going to stop.
Don't forget to look at state money transmitting licenses. That's what killed Goldage. (They were one of the largest e-gold exchangers). They were unlicensed because that thought that digital gold was outside the jurisdiction (not legal tender) of the state/federal governments. The state laws were vague enough, and law enforcement was ignorant enough, that they were prosecuted by the state of New York.
(See:
http://en.wikipedia.org/wiki/Goldage)
Lots of people speculate that they were prosecuted for political reasons and not for \"legal\" ones. The central banks (and therefore the governments under their economic debt rule) do not want competing currencies. This isn't because it is competition (e-gold was soooo small compared to the FRN paper game). They didn't want e-gold to open up people's mind to the idea of alternate currencies. That is a far bigger threat.
Remember that a license is an act of privilege that can be revoked/regulated. I firmly believe that any action that you can purchase a license for is fundamentally lawful. (Ex: you can't buy a license to commit a crime. No \"license to kill\", Bond.
).
It is possible to claim lawful excuse to operate unlicensed. (By pronouncement or claim by right of notary.. again, you need to know what you are doing.)
Peace!
Remember NLS
There are two types of law...
The Law you can read, and the one the government chooses to apply to you...
Your Lawyer friends may be right, but so were joe stack's and he got prosecuted...
",
"nested_level": 0
},
{
"id": 430,
"thread_id": 40,
"source_id": "9",
"poster_name": "I-am-not-anonymous",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=41",
"subject": "Re: Money Transfer Regulations",
"url": "https://bitcointalk.org/index.php?topic=69.msg612#msg612",
"date": "2010-03-03T03:48:33Z",
"text": "Remember NLS
There are two types of law...
The Law you can read, and the one the government chooses to apply to you...
Your Lawyer friends may be right, but so were joe stack's and he got prosecuted...
How encouraging...you've just told the poor fellow that even if he does everything right he could still go to jail--you're making him feel like an ethnic minority!
In most cases though, if a lawyer tells you you won't go to jail, you probably will not go to jail. Newlibertstandard uses paypal, which already practices know-your-customer and he is operating in amounts less than $10,000 which is what the money laundering and tax cheat police sniff out for. This means he is unlikely to be doing anything that is wrong OR anything that will attract the attention of Law Enforcement.
However---
Thinking ahead to bitcoin's future--money changing services that operate on a large scale and don't practice know-your customer would indeed be illegal and would thus have to operate within the onionverse, changing bitcoin to money services other than paypal (perhaps offshore based like pecunix).
Another idea would be for some future crypto-preneur to set up a Mom and Pop shop called \"Grandpa Joe's envelopes stuffed with cash\" and only accept bitcoin as payment. lol.
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.
",
"nested_level": 0
},
{
"id": 432,
"thread_id": 41,
"source_id": "1",
"poster_name": "fergalish",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=39",
"subject": "bitcoin auto-renice-ing",
"url": "https://bitcointalk.org/index.php?topic=72.msg673#msg673",
"date": "2010-03-08T09:29:56Z",
"text": "Hi, I run bitcoin at a nice level of 20 so as not to interfere with other tasks. Every now and then, however, it seems to auto-adjust itself to nice level 2, or even 0. It this by design? Frankly, such a thing should be illegal for a linux application... it's a bit odd to say the least.
",
"nested_level": 0
},
{
"id": 433,
"satoshi_id": 90,
"thread_id": 41,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin auto-renice-ing",
"url": "https://bitcointalk.org/index.php?topic=72.msg717#msg717",
"date": "2010-03-15T18:44:12Z",
"text": "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);
",
"nested_level": 0
},
{
"id": 434,
"thread_id": 41,
"source_id": "3",
"poster_name": "asdfman",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=327",
"subject": "Re: bitcoin auto-renice-ing",
"url": "https://bitcointalk.org/index.php?topic=72.msg2268#msg2268",
"date": "2010-07-12T08:05:57Z",
"text": "Hello,
This same behavior was bugging me too.. I would renice all the threads to 19, as it was interrupting system responsiveness since bitcoind was taking priority, but every so often the program would automatically reset the priority to something that would disrupt system responsiveness ..
so what I did was just edit util.h
and change the function that manipulates the priority:
inline void SetThreadPriority(int nPriority)
{
printf(\"No, were not changing any damn priority\n\");
}
and then recompiled bitcoind
now I just renice all the threads once, and they are stuck at what I set them to until program exit (NI column staying at 19):
1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%] Time: 03:59:40
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%] Uptime: 253 days(!), 01:12:27
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||501/1255MB] Load: 4.01
Swp[|||||||||||||||||||||||||||||||||||||||||||||||||||||| 501/1004MB] Load average: 4.01 4.15 3.49
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
| | |__ __| |__ |__||__ |__| | | | | | | | | | | | | __| __| | |
Avg: |__|.|__|% sy: |__ . __|% ni: __||__|.|__|% hi: |__|.|__|% si: |__|.|__|% wa: |__|.|__|% Tasks: __| __| | total, | running
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
4523 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.66 `- bitcoind -gen -daemon
4534 root 39 19 126M 46280 3424 R 90.0 3.6 12:43.73 | `- bitcoind -gen -daemon
4533 root 39 19 126M 46280 3424 R 45.0 3.6 10:49.02 | `- bitcoind -gen -daemon
4532 root 39 19 126M 46280 3424 R 46.0 3.6 10:05.83 | `- bitcoind -gen -daemon
4531 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.03 | `- bitcoind -gen -daemon
4530 root 39 19 126M 46280 3424 S 1.0 3.6 0:15.53 | `- bitcoind -gen -daemon
4529 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.72 | `- bitcoind -gen -daemon
4527 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.02 | `- bitcoind -gen -daemon
4526 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.03 | `- bitcoind -gen -daemon
4525 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.06 | `- bitcoind -gen -daemon
in my debug.log:
[root@raidserv] (~/.bitcoin)# grep \"No,\" debug.log
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
...
So now I can leave bitcoind running all day long without me noticing much...
Asdfman, what program is generating that output? I like it
lachesis - htop
its awesome.. has ANSI colors, you can fully configure it to display all threads, tree view, etc ,etc
",
"nested_level": 0
},
{
"id": 438,
"satoshi_id": 182,
"thread_id": 41,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin auto-renice-ing",
"url": "https://bitcointalk.org/index.php?topic=72.msg2886#msg2886",
"date": "2010-07-14T17:38:31Z",
"text": "Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.
",
"nested_level": 0
},
{
"id": 439,
"satoshi_id": 91,
"thread_id": 42,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Idea for file hosting and proxy services",
"url": "https://bitcointalk.org/index.php?topic=83.msg719#msg719",
"date": "2010-03-15T19:16:56Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 440,
"thread_id": 42,
"source_id": "2",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Idea for file hosting service",
"url": "https://bitcointalk.org/index.php?topic=83.msg728#msg728",
"date": "2010-03-16T10:17:55Z",
"text": "Good idea.
I'll eventually be setting up a 'one hop', SSL, http, login protected proxy service (similar to the 1st Psiphon project) and accepting bitcoins as payment.
I'm UK based so it will be good for using BBC iplayer etc.
I will be giving bitcoin users priority service, as well as users from 'restricted' countries.
I doubt I'll have the spare bandwidth for a file hosting service though, maybe.
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?
",
"nested_level": 0
},
{
"id": 442,
"thread_id": 42,
"source_id": "4",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Idea for file hosting service",
"url": "https://bitcointalk.org/index.php?topic=83.msg751#msg751",
"date": "2010-03-18T12:22:04Z",
"text": "There are a ton of Python options for web frameworks. I'm in the process of learning CherryPy, and I'm new to web development, so it's slow going. Looks like they have an example for basic uploading. Something in PHP would probably be best for the community though. Are there any Python people here?
",
"nested_level": 0
},
{
"id": 443,
"thread_id": 42,
"source_id": "5",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Idea for file hosting service",
"url": "https://bitcointalk.org/index.php?topic=83.msg752#msg752",
"date": "2010-03-18T14:36:50Z",
"text": "Yes. Any built proxy implementation would be open source and automated bitcoin payments would be great.
I will post the psiphon info. and links because the project has just moved from v1 to v2 and the implementations are very different.
Psiphon is a free 'circumvention' tool and should remain so. However, I've run a private and personally updated / secured 1.6 version and do accept 'token' donations from some of my users.
\"Psiphon is a web proxy designed to help Internet users securely bypass the content-filtering systems used to censor the internet. Psiphon was developed by the Citizen Lab at the University of Toronto.
License: GNU General Public License
Source code:
http://psiphon.ca/download/psiphon-src-1.6.tar.gzhttp://wikipedia.org/wiki/Psiphonhttp://psiphon.ca/https://launchpad.net/psiphonPsiphon is a user-friendly, simple to administer, web-based proxy application. It allows users in regions with unrestricted Internet access to provide access to denied content to their friends, family, and associates in regions with restricted access.
Please contact the project leader if you're interested in helping us take Psiphon forward.
NOTE: The Psiphon 1.x and 2.x series are essentially different products with different architectures. Psiphon 1.x is a light-weight web proxy designed to run on a home PC (MS Windows-based) with no central management component. With Psiphon 1.x, a user asks a friend to run a proxy and can then access blocked sites via his or her friend's Internet connection. The Psiphon 1.x source code is available here:
https://code.launchpad.net/~psiphon-inc/psiphon/psiphon-1.6.
The new project is Psiphon 2.x, a centrally managed web proxy system deployed by Psiphon Inc. to provide censorship circumvention services.\"
Great source code here in reference to designing and building our own separate bitcoin style implementation. I'd grab the 1.6.tar.gz for your reference satoshi, before it becomes to 'historical'. It's also not that easy to compile the 1.6 version on Linux anymore.
The 1.6 Win32 version has now been removed from the original project website. I actually run my existing proxy service on a windows box, with additional security. I have the msi and documentation if anyone can't find it elsewhere or would like it for reference etc. I keep it up-to-date and secure from the following sources;
SSL -
http://www.slproweb.com/products/Win32OpenSSL.htmlVisual C++ 2008 Redistributables for msvcpXX.dll and msvcrXX.dll
http://www.sqlite.org/download.htmlPrecompiled Binaries For Windows for sqlite3.dll
Java and some flash support is always an issue though !
I would be happy to work on and share contributions for a 'bitcoin' proxy software, but have limited time and developer experience myself. Maybe you should contact the psiphon developers for a separate v1.6 style implementation yourself satoshi ?
I understand that the Tor project is also looking for a payment / incentive system for it's server operators.
Could you change the thread title to \"Re: Idea for file hosting and proxy services\". Thanks.
Regards,
BitcoinFX
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)
",
"nested_level": 0
},
{
"id": 445,
"satoshi_id": 97,
"thread_id": 42,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Idea for file hosting and proxy services",
"url": "https://bitcointalk.org/index.php?topic=83.msg810#msg810",
"date": "2010-03-24T18:02:55Z",
"text": "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.
A week or so ago I met a very nice Freenoder staffer in the #bitcoin and #bitcoin-dev channels. He told me that the #bitcoin channel turned up on Freenode's radar as it looks like a Botnet Command and Control channel, but after I explained to him how Bitcoin works and why they need IRC, he said that the channel at it's current size is not a problem.
However, this got me thinking and later this week I also discussed the topic on IRC, and I came to the conclusion, that IRC is the wrong method for bootstrapping, especially in it's current form. At the moment, each client will connect to IRC and stay connected. Using /who and join messages, the client will connect to the found IPs on port 8333 as a bootstrapping method. However, the clients internally also talk to each other and broadcast new nodes via the Bitcoin protocol. Still, they are always online in IRC. This has various disadvantages:
- IRC connectivity is necessary for bootstrapping (firewalls often block it and Freenode blocks TOR)
- There is a single point of failure (Freenode)
- We are leeching Freenode's services instead of using our own infrastructure. Many servers actually disallow bot connections in their MOTDs.
- Minor point: The additional protocol inside Bitcoin brings extra complexity
There is already a list of permanently-on Bitcoin IPs around in this forum, which is a nice idea, but not very scalable, thus I propose the following solution: Gnutella and MUTE face very similar bootstrapping problems. To solve them, they rely on a list of \"Gnutella Webcaches\". Those webcaches are run by volunteers on simple PHP servers and a master list of them is distributed with each Gnutella/MUTE release. When a client wants to join the network, it asks one or two of the Webcaches via HTTP for a list of other nodes and also gets added to that list (which is usually a list of the last X clients seen). Every few hours (or days) a running client reconnects to the webcache to tell it, that it is still alive and does not have to be deleted from the list. I suggest, that the same thing is implemented for Bitcoin. Volunteers could run those webcaches on cheap PHP webspace and tell their URL to Satoshi or Sirius, who in turn could add the list to each release. This would allow users running behind a restrictive firewall or TOR to use Bitcoin without manually finding other nodes, and it is a much more scalable approach. (As a bonus we could remove those HTTP calls to whatismyip.com or similar sites).
Of course, there might be a better idea for bootstrapping Bitcoin and I would love to hear it. Or maybe suggestions for the Webcache idea. Please post them here!
Cheers,
soultcer
To eliminate segmentation, every peer should have a list of every other peer. Tor also has this requirement, so we should copy them: have several trusted directory servers periodically create a signed list of all peers and publish it via HTTP. All BitCoin clients have the option to act as a directory mirror, which will be indicated in the dirServers' list. Generators need to ask to be added to the list (which could also include info like the maximum number of connections that peer will accept), but people just wishing to make transactions can just get the list from a dirMirror and connect to a few random peers.
If this is too centralized, we can do what I2P did and allow anyone to become a directory server. You need to be able to detect when a dirServer goes rogue in this case, though.
",
"nested_level": 0
},
{
"id": 448,
"thread_id": 43,
"source_id": "3",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg725#msg725",
"date": "2010-03-16T01:57:24Z",
"text": "I vote for the I2P method, myself. It works great.
",
"nested_level": 0
},
{
"id": 449,
"satoshi_id": 92,
"thread_id": 43,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg729#msg729",
"date": "2010-03-16T19:48:47Z",
"text": "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.
Bitcoin's IRC client implementation is already thoroughly tested.
We all talk about bootstrapping systems, how ever, my idea might be a bit better.
A user starts bitcoin on a host for the first time, and it will initially download a list of nodes that it will connect to.
(until, of course, we have a lot of static nodes we can hard code into bitcoin...)
Then, the client tries to connects to those IPs on that list it downloaded, or when it already has a list downloaded from the last time it started bitcoin, connect to those.
When we're connected, the client asks every node for a list of nodes they know and updates its node list.
Once a complete list is obtained, it is saved on the hard drive and a copy is kept in memory. (This is because we want to have a list of nodes without actually connect to that indexing server.)
And finally, the node is completely connected to the network.
When a new node connects (when it receives a \"new node packet\"), the list is both updated in memory and saved to the hard drive again.
To make updating the list with new nodes so bandwidth friendly as possible, I suggest that every node \"echoes\" the IP of a new node connecting to the network to all the nodes it knows...
Pros:
* Has bootstrapping in mind.
* Is distributed for clients that have a node list
Cons:
* Every new client needs to connect to a server to get a new node list until we're done with bootstrapping.
This, in my eyes, seems like the best solution to our bootstrapping problem...
PS: If we implement this, we might just wanna check if the \"new node packet\" we received contains bogus IPs, or IPs that resolve to .gov domains!
Hi all.
This may be a stupid idea, and if it's not stupid, may not be viable for the next few years, but I thought I'd toss it out there anywhere:
What about Multicasting?
IPv6 is supposed to have better multicasting support than IPv4, and if I did not misunderstand the Bitcoin protocol, most messages need to be broadcasted to the entire network. Theoretically a node could send such messages to a global multicast address, and everyone will receive it in a bandwith-efficient way.
That would make bootstrapping in the traditional sense obsolete, since the client would just have to subscribe to the multicast channel. The remaining \"Give me block xyz\" requests could be handled by optionally including a field in messages to the multicast channel that basically says \"My address is 2001:db8::42, and I'm willing to answer direct queries for specific blocks\". After listening to the channel for a while, such a packet should come around, because, at the very least, new blocks will be announced there every so often.
",
"nested_level": 0
},
{
"id": 452,
"thread_id": 43,
"source_id": "7",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1058#msg1058",
"date": "2010-05-03T20:36:34Z",
"text": "I don't know that much about IPv6, but it sounds good, if it's possible.
How ever, keep in mind that as of now, 9/10th of the world still uses IPv4!
So it is a great idea, and developer(s) (how much does bitcoin have anyways?) should implement it in bitcoin (in my humbly opinion).
How ever, making it default to use IPv6 isn't a good idea.
It's totally viable when everyone will be using IPv6, it's just everyone still uses IPv4!
(And I see now that in my previous post I basically explained what other people adviced... Oops!)
",
"nested_level": 0
},
{
"id": 453,
"thread_id": 43,
"source_id": "8",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1059#msg1059",
"date": "2010-05-03T22:22:23Z",
"text": "TCP doesn't work with multicasting. And I doubt it will ever be easy for a home user to join a multicast group.
",
"nested_level": 0
},
{
"id": 454,
"thread_id": 43,
"source_id": "9",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1062#msg1062",
"date": "2010-05-04T03:19:03Z",
"text": "If you guys are interested in ipv6, there are a lot of transition mechanisms available. Windows comes with teredo which is kind of complicated for what it does.. I like 6to4, basically every ipv4 node has an ipv6 prefix which is 2002:<ipv4 addr> /48. It is very easy to set up 6to4 on a linux box. Here is my setup as an example:
echo 0 > /proc/sys/net/ipv6/conf/all/autoconf
echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv6/conf/all/router_solicitations
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
ip tunnel add 6to4tunnel mode sit ttl 200 remote any local 76.122.46.187
ip link set dev 6to4tunnel up
# listen for 6to4 traffic to me
ip -6 addr add 2002:4c7a:2ebb::1/16 dev 6to4tunnel
# route to non 6to4 ipv6 hosts
ip -6 route add 2000::/3 via ::192.88.99.1 dev 6to4tunnel metric 1
# add address to lan0
ip addr add 2002:4c7a:2ebb:0001::1/64 dev lan0
# add address to lan1
ip addr add 2002:4c7a:2ebb:0002::1/64 dev lan1
echo \"Starting radvd...\"
/opt/radvd/sbin/radvd
That is literally all it takes. This is for my linux box which is acting as a router. You just convert your ipv4 address to hex. For instance mine, 76.122.46.187 == 4c 7a 2e bb
The v4 address 192.88.99.1 is an anycast address.. There are routers that pick up the 6to4 traffic and bridge it over into the native v6 land. Because of how routing works you will just get to the closest (network wise) bridge router when you transmit to v6 addresses.
Setting up radvd allows the client machines on your lans (I have lan0 and lan1) to receive an automatic ipv6 address. With this set up you can hit ipv6.google.com and see the letters bouncing to know it works.
If you're planning to try this, google up some info on 6to4 first so you understand how it works. Also be aware that your machines which are NAT'd with ipv4 are globally accessible with this set up and are not filtered unless you set that up separately (windows firewall, ip6tables, etc)
I throughly agree with this. In the long run, IRC should be completely phased out and replaced with something like Gnutella's host caches or Tor's dictionary servers (as others have suggested).
At the very least, Bitcoin should disconnected from IRC as soon as it has a list of peers to connect to. It should also cache that list so it wouldn't need to reconnect upon the next startup.
Just my 0.02\u0e3f.
",
"nested_level": 0
},
{
"id": 456,
"thread_id": 43,
"source_id": "11",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1407#msg1407",
"date": "2010-06-08T12:11:05Z",
"text": "Anyone into a set of multi entity owned DNS servers that cooperate for a Fast Flux [1] network to ensure bootstrap availability?
[1]
http://en.wikipedia.org/wiki/Fast_fluxWhat's wrong with IRC? It's just another method that's used to exchange the peer list. You can just prevent it from connecting and use -addnode=1.2.3.4 to connect to a known node for bootstrapping if you want..
If nodes disconnect from IRC after they get their list then it makes it less useful for bootstrapping since it will be empty except for the node that's trying to bootstrap at the time.
IRC has been around forever and it's well documented (and easy to understand for newcomers) - why create something more complicated?
",
"nested_level": 0
},
{
"id": 458,
"thread_id": 43,
"source_id": "13",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1409#msg1409",
"date": "2010-06-08T13:57:09Z",
"text": "I like the idea of distributed host caches like Gnutella uses. At the moment, for the majority of people, IRC is a single point of failure. Let's assume that for some reason our Freenode channel was gone. Maybe Freenode got fed up and shut us down. Maybe MenInBlack saw our system, laughed maniacally, and then pressured Freenode to shut us down.
When you start your client, it will do nothing. You could drop to a command line and type \"-addnode\" (or is it -peer? whatever) to connect to a known node, but at that point you'd somehow need to know a node. It probably wouldn't be that hard for one of us, but what about a new user? We could keep a list of peers on the website for them to use, but at that point, they've gone from \"just double click the shiny gold coin and get trading\" to \"check our website for updated peer lists, open command prompt, navigated to the bitcoin directory, and type the proper peer.....\" And if MIB were after us, the website would probably be long since gone.
Of course, we could implement addpeer in a more user-friendly manner. Perhaps a popup that says \"I can't connect to the network. Enter a peer: \" with instructions on some ways to find one, but at that point we're creating a social solution to a technical problem.
Also, if we get bigger we will need to move away from IRC anyway (as implied by the OP's conversation with a Freenode staffer). And what about Tor users? Why should people who want to use Tor to be anonymous have to manually add a peer?
Finally, anyone on Freenode can easily get a list of all running Bitcoin clients, when they came online, when they went offline, etc. That goes against the project's stated goal of anonymity. Of course, with a host cache system, anybody who connected to that cache could be logged by the server operator, but no one operator would have a full picture of the network.
I think the IRC solution is a wonderful beginning, and I applaud how stable it has proven to be. It was a great decision to get the network up easily and concentrate on the more interesting and important considerations in the program. I just think that Bitcoin will outgrow it someday, if it hasn't already.
",
"nested_level": 0
},
{
"id": 459,
"satoshi_id": 117,
"thread_id": 43,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1579#msg1579",
"date": "2010-06-14T18:13:21Z",
"text": "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 seed nodes, just connect and get the list, so it won't be a burden on them.
What do you think, should I go ahead with adding the seeds?
It'll still try IRC first. The IRC has the advantage that it lists nodes that are currently online, since they have to stay connected to stay on the list, but the disadvantage that it's a single point of failure. The \"addr\" system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline. The combination of the two gets us the best of both worlds and more total robustness.
Is there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us?
",
"nested_level": 0
},
{
"id": 460,
"thread_id": 43,
"source_id": "15",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1580#msg1580",
"date": "2010-06-14T18:30:58Z",
"text": "I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs.
My box is a dedicated irc server:
2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08
You can use irc.lfnet.org to connect.
I hang out on #linuxos if anyone wants to drop in.
",
"nested_level": 0
},
{
"id": 461,
"thread_id": 43,
"source_id": "16",
"poster_name": "blanu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=259",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1614#msg1614",
"date": "2010-06-18T05:12:48Z",
"text": "This is a common problem in P2P, known as Original Introduction, although bootstrapping is also a good word for it. The problem with bootstrapping is that you can't decentralize it. Whether it's IRC or HTTP or DNS, the client needs to be hardcoded with an address or list of addresses which is sufficiently fresh that at least one of the listed addresses is still active. After the first node is reached, you are no longer in Original Introduction mode and can use the full range of techniques for decentralization, such as gossip. Unless, of course, you get disconnected from the network and all of your known peers go away, in which case you're back to bootstrapping.
There are two properties that are at odds when you chose a bootstrapping method: robustness (scalability/reliability) and freshness. Robustness is increased at the expense of freshness by caching on multiple servers, as is usually done with HTTP peer lists. Freshness is maximized (at least up to the TCP timeout) at the expense of robustness by having everyone connected, as with IRC. Of course, the key is finding the right mix of robustness and freshness because you need both for the bootstrap to be successful.
Here are some of my current favorite methods for bootstrapping:
Append list of fresh peers to executable or installer dynamically on download. People usually get the application from its official website, so the website is already a point of failure for new users. You're already hardcoding an address in the application, the address that the application will use to bootstrap. So instead just add fresh peers at the moment of download. You need some fancy code in the executable to read the list off the end, but I've implemented this in an NSIS installer and it's not that hard. Most software developers are upset by the idea of this method.
Connect via XMPP to Google App Engine application. This gives the freshness of IRC, but with more robust scaling. App Engine is mostly for writing web apps, but it provides email and XMPP handling as well. It would be simple to write one application that could handle peer lists via either XMPP or HTTP with the same handler code. I'm currently using this in an application and it works well and is very reliable. I only wish there was a second App Engine to use as a fallback because it does have occasional downtime.
An alternative to requiring all nodes to include the complexity of a protocol like IRC or XMPP is to have a few special sentinel nodes which sit on the network and collect addresses of connected nodes via the usual decentralized methods available to an active node. These sentinel nodes periodically upload fresh addresses, say via HTTP POST to a number of websites. A new node can then download a fresh address list from any of the websites which is currently functioning and reachable. If you have 5 sentinels each uploading every 5 minutes (staggered), then you'll have updates roughly once a minute. This is on par with IRC in terms of freshness and is robust as you care to make it by varying the number of HTTP mirrors and the number of sentinels.
",
"nested_level": 0
},
{
"id": 462,
"thread_id": 43,
"source_id": "17",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1616#msg1616",
"date": "2010-06-18T14:08:23Z",
"text": "I think the way eMule handles bootstrapping for its KAD-network is pretty close to optimal:
The list of known peers is stored in a file (nodes.dat), and every client maintains a list of known nodes in that file (sorted by longest uptime, I think -- that's an intrinsic property of Kademlia, but still a good idea). The released client should be accompanied by such a file that contains the addresses of a few reliable peers on static IP addresses, from which a new client can then get more addresses to connect to (and hence store in its own file).
If the \"seed list\" gets out of date, or the server is shut down or something, you can just ask *anyone* in the network to publish his nodes-file (on rapidshare, say), and voila, you've got a fresh list of IPs you can connect to.
",
"nested_level": 0
},
{
"id": 463,
"satoshi_id": 128,
"thread_id": 43,
"source_id": "18",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1619#msg1619",
"date": "2010-06-18T17:28:18Z",
"text": "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 node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It's only slow to get connected the first time.
This means TOR users won't need to -addnode anymore, it'll get connected automatically.
",
"nested_level": 0
},
{
"id": 464,
"satoshi_id": 148,
"thread_id": 43,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg1781#msg1781",
"date": "2010-06-25T22:40:47Z",
"text": "I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs.
My box is a dedicated irc server:
2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08
You can use irc.lfnet.org to connect.
This seems like a good idea.
What does everyone think, should we make the switch for 0.3?
You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.
",
"nested_level": 0
},
{
"id": 466,
"thread_id": 43,
"source_id": "21",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg2009#msg2009",
"date": "2010-07-07T01:05:47Z",
"text": "Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?
",
"nested_level": 0
},
{
"id": 467,
"satoshi_id": 170,
"thread_id": 43,
"source_id": "22",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: On IRC bootstrapping",
"url": "https://bitcointalk.org/index.php?topic=84.msg2010#msg2010",
"date": "2010-07-07T01:31:07Z",
"text": "Everybody needs to connect to the same IRC server and channel so they can find each other.
You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.
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 old and has impressive uptime. I think it's going to be fine.
We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.
Hi everyone. I'd like to see a good discussion on different methods for transferring into and out of cash. It has been touched on elsewhere, but I'd like to create a definitive thread for it. This discussion should include, but shouldn't be limited to the following...
1.) Methods mentioned previously on the forum, along with their pros and cons.
2.) New ideas including ones that are \"outside of the box\"
3.) As a customer, which method do you prefer? What is more important to you? Anonymity, security, convenience or other?
NewLibertyStandard is using direct transactions with Paypal.
I think Sirius-m is working on several different direct transactions that the customer may select from.
I am using a deposit and withdraw system using Paypal (for the time being).
Let's dicuss everything from satoshi's sophisticated \"e-bay-like\" idea, to madhatter2's \"money in the mail\" idea, and everything in between.
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.
Nice!
I might do 'well hidden cash in the mail' here for small amounts.
One last thing. Legality can be listed as a pro/con but let's not get wrapped up in it here. NewLibertyStandard already has a good
thread started on that topic.
Cash in the mail is the best option, in my opinion.
1. It is fairly anonymous (there would be a postmark from your side and you'd know my address).
2. I know the laws inside and out here. I wouldn't violate them.
3. I am not in the USA.
Oh and PayPal is a horrible choice.
All it would take is for a competitor to rat you out to PayPal and you'd be out of business.
Exchanging in and out of physical gold/silver is another option. I have experience with shipping goods, and a friend of mine is a bullion dealer.
edit by Xunie: merged two posts.PayPal
Free and easy to open an account.
Very inexpensive to deposit, transfer and withdraw money.
Easily accessible by people all around the world.
PayPal is known to frequently freeze funds for long periods of time.
Reveals first and last name.
Transactions can be contested fairly easily.
Bank Wire
Most well established electronic money transfer method.
Fees are prohibitively expensive for small transactions.
Bank can request to reverse transaction, but it's very rare.
I presume first and last name don't need to be revealed.
Some personal account information must be revealed.
Bank Wire through MutoNovo
Fee in addition to wire fee.
Do not need to reveal personal account information to send or receive wire.
Western Union
Many locations worldwide.
Neither party needs a bank account.
Fees are fairly expensive.
Weak identity verification.
Pecunix Digital Gold Currency
Transaction fee is small.
Transactions are fairly anonymous.
Currency must be purchased and sold through a third party, presumably with expensive fees.
Postal Mail
Lots of domestic mailing options available within USA.
Mailing of currency generally discouraged.
Various types of checks can only be cashed in certain countries.
Cash can be lost or stolen.
Value of some kinds of checks can be lost or stolen.
Value of other kinds of checks do not get withdrawn until named recipient cashes check.
Although extremely unlikely and highly punishable, postal mail can be used as a delivery method for harmful biological agents.
PayPal works best for me because it's inexpensive and easy. If I was planning on expanding and making a profit from my exchange service, I would probably get an account at a big bank and offer as many payment options as possible.
",
"nested_level": 0
},
{
"id": 471,
"thread_id": 44,
"source_id": "4",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Exchange Methods",
"url": "https://bitcointalk.org/index.php?topic=87.msg772#msg772",
"date": "2010-03-20T03:58:23Z",
"text": "Not anymore. They were just recently slapped with fines. They are tightening up ID requirements now.
Western Union
Weak identity verification.
I like Liberty Reserve
https://www.libertyreserve.com/Its easy to use, fast, secure and has a good API. It's been around since 2002. USD, EUR and Gold holdings. No formal ID verification process is required. You are allowed to create multiple accounts as long as you register your details fully (i.e. no fake accounts) Its based in Costa Rica, which makes the list of the 'Worlds 22 Oldest Democracies'
http://wikipedia.org/wiki/Costa_Rica - Intel has a main micro processor facility in Costa Rica and I like coffee.
I trust and use Liberty Reserve more than any another eCurrency or online payment system.
https://www.libertyreserve.com/en/exchangers/index.aspx has loads of useful exchange links.
Here are some other suggestions for discussion:
Exchange Zone -
http://exchangezone.com/ - easy and secure, member to member, eCurrency auction service.
AlertPay -
https://www.alertpay.com/c-gold -
https://c-gold.com/Strict Pay -
https://www.strictpay.com/SolidTrust Pay -
https://solidtrustpay.com/Perfect Money -
https://perfectmoney.com/Global Digital Pay -
https://www.globaldigitalpay.com/ePassport -
https://www.epassporte.com/EuroGoldCash -
https://www.eurogoldcash.com/Hyper Wallet -
http://www.hyperwallet.com/Web Money -
http://www.wmtransfer.com/Pro Currex -
https://www.procurrex.com/ECU Money -
http://www.ecumoney.com/With many of these e-currencies and providers / exchangers now implementing mobile phone payments it would seem logical to pursue that route. Most countries have 'pay-as-you-go' providers. This is as good as 'anonymous' if bought for cash. Apparently, mobile phone payments have a much higher conversion rate than credit cards etc. for online payments.
Here are some services I found for discussion and which I might be implementing myself in the future:
Zong -
http://www.zong.com/zong/Obo Pay -
https://www.obopay.com/Bango -
http://bango.com/MobileTransactions -
http://www.mobiletransaction.org/Self Bank Mobile -
https://www.selfbankmobile.com/Implementation:
Fortumo -
http://fortumo.co.uk/Asterisk -
http://www.asterisk.org/Consider the above with a Bitcoin mobile App. and we are really getting somewhere.
I don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...
This reminds me of a few Google Hoaxes.
Gmail Paper -
http://mail.google.com/mail/help/paper/index.htmlGoogle Gulp -
http://www.google.com/googlegulp/ lol
As a business, why would I accept Bitcoin and not LR/Pecunix? It doesn't make any sense to do exchanges between LR/Pecunix and Bitcoin.
Oh, and asterisk sucks. You'll want freeswitch instead. (freeswitch.org)
So you are saying that people are lazy? lol Big surprise there.
I don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...
Oh and LR is a fractional reserve currency on top of a fractional reserve currency. Do not keep money in your LR accounts. Use it as a pass-thru only. Also, PerfectMoney is ran by a sociopath who is currently in prison.
edit by Xunie: merged 4 posts.As a business, why would I accept Bitcoin and not LR/Pecunix? It doesn't make any sense to do exchanges between LR/Pecunix and Bitcoin.
You can decide to accept Bitcoins and / or LR/Pecunix, both or neither !
It does make sense to exchange LR/Pecunix with Bitcoins and vice versa;
(1) You (customers) can generate Bitcoins.
(2) You (customers) can buy, sell, or exchange items, goods and services which you can't with just Bitcoins and vice versa.
You know you can obtain a bank card to withdraw LR USD from an ATM ! You can't do that with Bitcoins, yet !
Oh, and asterisk sucks. You'll want freeswitch instead. (freeswitch.org)
Thanks for the opinion, link and info. I will look into and try that one.
We are all here to learn, discuss and share information.
So you are saying that people are lazy? lol Big surprise there.
I don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...
Yes. I was also highlighting the fact that 'snail mail' is slow. Also, on a 'paranoid' note it's not 'anonymous' to send a 'franked' envelope, revealing your location and which also contains your DNA.
![\"Shocked\"](\"/static/img/emoticons/shocked.gif\"/)
Not that this is a realistic consideration for micro payments anyway. Much better to buy a 'mobile' credit card and toss it in a ditch. If you are that way inclined.
I'm not saying 'snail mail' is a bad idea. Just discussing the pros and cons...
Oh and LR is a fractional reserve currency on top of a fractional reserve currency. Do not keep money in your LR accounts. Use it as a pass-thru only. Also, PerfectMoney is ran by a sociopath who is currently in prison.
Yep. Never keep money in a bank, always keep it under the bed, much safer... lol
Yes. I have also heard of 'problems' with Perfect Money.
Most of what I listed was for discussion and was not a recommendation. Again, we are here to share ideas and information, good, bad or indifferent.
Also found liqpay (mobile payments) -
https://www.liqpay.comI think as Bitcoin's adoption rates go up more and more LR+Pecunix only sites will pick up Bitcoin as an alternate payment option. After all, the people already accepting LR/Pecunix are very like-minded.
Yes, we are all here to learn and discuss. My apologies if I came across as a \"know-it-all\". I have just been in the payment processing industry and law studies for over 10 years, and I know a lot about it.
Sure, you can be worried about me taking your DNA from an envelope that you send.
Just use gloves when preparing the envelope and use water or tape instead of saliva. (Wear a hair net too if you are that paranoid! ha!)
A franked envelope has information about the general area from where the letter was mailed. It is rather useless to an investigator, assuming that you don't use a real return address. Or you use a return address that I provide you (lets just say). You can also go for a little drive to a different part of town and mail from there. Or another city. Or get a friend to re-mail it from his city. There are plenty of options.
'Snail mail' when properly prepared (making the envelopes as machine-readable as possible and using the proper Zip code 5+4 digit extension, etc) is actually quite speedy. (I have experience with shipping as well.)
Epassporte is kinda scammy. It is ran by the same folks who run Paycom/Epoch Billing (adult billing). I personally know a handful of people who were ripped off, had their accounts frozen for various non-issues (see: PayPal).
When I had signed up for a physical card when they first opened I never received anything in the mail, they charged my CC, my bank called me asking me if it was fraudulent. They told me that those epassporte charges had caused a lot of disputes at my bank. I explained to the guy on the phone what I had ordered online and that I hadn't received anything. (It wasn't my intention to chargeback or cause any \"friendly fraud\", people do that to me all the time so I know how it feels. It is aggravating.) My money was refunded by epassporte after I called them in California (they claim to be in Antigua).
When people ask me to pay them with Epassporte, I usually just laugh.
Anyone want to hear my stories about PayPal? lol I have a few.
How about with Visa International? Or MasterCard's broken securecode system?
Great minds think alike. (There are better places than under your bed.)
Yep. Never keep money in a bank, always keep it under the bed, much safer... lol
I think as Bitcoin's adoption rates go up more and more LR+Pecunix only sites will pick up Bitcoin as an alternate payment option. After all, the people already accepting LR/Pecunix are very like-minded.
Yes, we are all here to learn and discuss. My apologies if I came across as a \"know-it-all\". I have just been in the payment processing industry and law studies for over 10 years, and I know a lot about it.
Sure, you can be worried about me taking your DNA from an envelope that you send.
Just use gloves when preparing the envelope and use water or tape instead of saliva. (Wear a hair net too if you are that paranoid! ha!)
A franked envelope has information about the general area from where the letter was mailed. It is rather useless to an investigator, assuming that you don't use a real return address. Or you use a return address that I provide you (lets just say). You can also go for a little drive to a different part of town and mail from there. Or another city. Or get a friend to re-mail it from his city. There are plenty of options.
'Snail mail' when properly prepared (making the envelopes as machine-readable as possible and using the proper Zip code 5+4 digit extension, etc) is actually quite speedy. (I have experience with shipping as well.)
No. You don't come across as a 'know-it-all'. I enjoy reading your post and contributions.
However, I would much rather just sit at my desk and transfer 'payments' around by text msg etc. than have to drive across town to post a letter. Only to return home and remember that I'd forgotten to buy the darn hair nets (again) rofl.
Google Paper has experience of shipping to
http://mail.google.com/mail/help/paper/more.htmlMaybe one should have a lackey that does the driving and mailing.
Pay him in Bitcoins!
However, I would much rather just sit at my desk and transfer 'payments' around by text msg etc. than have to drive across town to post a letter. Only to return home and remember that I'd forgotten to buy the darn hair nets (again) rofl.
Here is an idea I have been pondering. I think it's similar to Satoshi's, only transfers are made directly... Feel free to rip apart or amend. I created a
goofy .pdf to explain what is happening.
In theory this could be used for any third party such as Paypal, etc. I think it would be very difficult for them to prove that individuals are participating in a currency exchange. And, I think it becomes more difficult to prove as the number of traders increase.
One big problem. Person A and Person B must follow through with their transfers and be honest about their actions. A solution might be to require an initial deposit from each individual to be held as collateral before any orders are made. These deposits could be in Bitcoins and offered as compensation when a trade \"goes bad\" for whatever reason.
Pros:
1.) No centralized account that can be seized or frozen.
2.) No tax reporting burden on accounts.
Cons:
1.) Transfers are less anonymous since individuals can \"see\" one another.
2.) Parties must be trustworthy.
During an audit (taxman, or otherwise) how will \"Person B\" explain a donation? Person B would need to have some sort of cover. A fake charity or something?
",
"nested_level": 0
},
{
"id": 486,
"thread_id": 44,
"source_id": "19",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Exchange Methods",
"url": "https://bitcointalk.org/index.php?topic=87.msg803#msg803",
"date": "2010-03-23T00:59:09Z",
"text": "During an audit (taxman, or otherwise) how will \"Person B\" explain a donation? Person B would need to have some sort of cover. A fake charity or something?
I'm not sure what Paypal is required to report on individuals and/or merchants.
This explains some of it for US domestic. It's a little dated though. Maybe someone could elaborate.
None of that matters. PayPal's corporate policies are not law. Under the slightest inquiry they will give you up. I guarantee that fact.
See 'jurisdiction' again. Is PayPal a registered corporation? I'd imagine so. Obtaining a corporate charter is a PRIVILEGE (means \"private law\"), not a right. (Rights are inherent, you don't apply for them.) It makes PayPal subject to the jurisdiction of the REGISTRAR. (The state or federal government.) So when they are asked for your information and are stuffed with a pile of statutes, they have to comply or face civil (See: Roman Civil Law) penalties or the revocation of the charter. (Revocation of charters is rare, but it does happen.)
After PayPal gives up your information; they (IRS/boogieman/whoever) will look at the real world items you have in your 'keep' and determine that they were paid for with these so-called donations online.
You'll enter your plea with the courts (a plea is a verbal contract that also establishes civil jurisdiction with your consent), they'll find you guilty, and you'll get a nice piece of paper called a court order to pay fines (or possibly jail time).
Call me jaded if you wish. They are very 'tricky monkeys'.
Add this to the 'cons list' for cash:
- Possibility of RFID imbedded into the bills. They could be read by the machines at your local post office and throw a red flag on the destination address.
",
"nested_level": 0
},
{
"id": 489,
"satoshi_id": 95,
"thread_id": 44,
"source_id": "22",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Exchange Methods",
"url": "https://bitcointalk.org/index.php?topic=87.msg807#msg807",
"date": "2010-03-23T17:35:34Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 490,
"thread_id": 45,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "who is bitcoin.com",
"url": "https://bitcointalk.org/index.php?topic=88.msg799#msg799",
"date": "2010-03-22T17:16:17Z",
"text": "Is
http://www.bitcoin.com a valid implementation of the bitcoin protocol? How are they able to use the name? Does anyone know who is behind it?
It's not related to our project. Apparently it's some company called Bitcoin Ltd. The page has been saying \"alpha test coming soon\" since the last summer at least.
",
"nested_level": 0
},
{
"id": 492,
"satoshi_id": 94,
"thread_id": 45,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: who is bitcoin.com",
"url": "https://bitcointalk.org/index.php?topic=88.msg806#msg806",
"date": "2010-03-23T15:22:41Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 493,
"thread_id": 46,
"source_id": "1",
"poster_name": "SheriffWoody",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=55",
"subject": "removing bitcoin addresses",
"url": "https://bitcointalk.org/index.php?topic=101.msg873#msg873",
"date": "2010-04-08T14:56:25Z",
"text": "Is there any way to remove bitcoin addresses that you have generated for yourself? What about if you have received payments to those addresses? Are they needed to show ownership for the coins after they have been transferred?
",
"nested_level": 0
},
{
"id": 494,
"thread_id": 46,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: removing bitcoin addresses",
"url": "https://bitcointalk.org/index.php?topic=101.msg888#msg888",
"date": "2010-04-10T06:12:31Z",
"text": "A question to Satoshi: have you tested the program with thousands of own addresses in the wallet? If I make a new address for each automated transaction, it's going to be a big amount. Or maybe I could reuse the addresses, given a big enough pool.
",
"nested_level": 0
},
{
"id": 495,
"satoshi_id": 102,
"thread_id": 46,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: removing bitcoin addresses",
"url": "https://bitcointalk.org/index.php?topic=101.msg1134#msg1134",
"date": "2010-05-16T23:34:40Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 496,
"thread_id": 47,
"source_id": "1",
"poster_name": "Minsc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=147",
"subject": "Is there a way to automate bitcoin payments for a website?",
"url": "https://bitcointalk.org/index.php?topic=112.msg928#msg928",
"date": "2010-04-15T00:12:40Z",
"text": "I run a website hosted on freebsd and well right now nobody visits it ever and so I can totally change it. I am wanting to change it to allow people to pay for services from the website exclusively through bitcoins. Now I see bitcoin has some linux program but I'm not sure that's compatible with FreeBSD or not. I also don't know how I can integrate bitcoin into a website to automatically take the bitcoin payments so they show up immediately. I'd really like them to work so my website immediately recognizes the payment coming in.
",
"nested_level": 0
},
{
"id": 497,
"thread_id": 47,
"source_id": "2",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Is there a way to automate bitcoin payments for a website?",
"url": "https://bitcointalk.org/index.php?topic=112.msg929#msg929",
"date": "2010-04-15T00:16:22Z",
"text": "Not sure about FreeBSD, but payments can be automated with the new version.
http://bitcointalk.org/index.php?topic=63.0I have the latest SVN snapshot running on FreeBSD (bitcoind) with automation running on a few servers.
You just install databases/db48, x11-toolkits/gtk20, devel/gmake, and devel/boost-all from the ports tree, download wxwidgets 2.9 and install it manually (the port version is 2.8.. that's no good), change a few paths in the makefile.unix file, and run \"gmake -f makefile.unix bitcoind\". You will end up with a binary called \"bitcoind\" (it is headless). Run \"strip ./bitcoind\" to make it smaller (it is really big with the debugging symbols). You can, of course, leave the debugging symbols in. I had to use gdb on bitcoind a few times in the past to figure out a strange crash.
I have tested bitcoind on 32 and 64 bit systems running FreeBSD. I didn't detect any memory leaks or see any crashes.
",
"nested_level": 0
},
{
"id": 499,
"thread_id": 47,
"source_id": "4",
"poster_name": "generica",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=154",
"subject": "Re: Is there a way to automate bitcoin payments for a website?",
"url": "https://bitcointalk.org/index.php?topic=112.msg984#msg984",
"date": "2010-04-21T16:53:40Z",
"text": "madhatter, thanks for these instructions. I edited the makefile and installed the dependencies. Here are the changes I had to make if anyone is interested:
- Added these three INCLUDEPATH entries:
-I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" \\
-I\"/usr/local/include/db48\" \\
-I\"/usr/local/include\"
- Added this LIBPATH entry:
-L\"/usr/local/lib/db48\"
- Changed \"wx_gtk2ud-2.9\" to \"wx_gtk2u-2.9\" because I didn't build wxwidgets with debugging
This is with SVN Rev 75. However, the end result won't compile:
[root@colo /usr/src/bitcoin/trunk]# gmake -f makefile.unix bitcoind
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/script.o script.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/db.o db.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/net.o net.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/irc.o irc.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/main.o main.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/rpc.o rpc.cpp
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp: In instantiation of 'boost::mpl::less_impl<mpl_::integral_c_tag, mpl_::integral_c_tag>::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul> >':
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:73: instantiated from 'boost::mpl::less<mpl_::size_t<8ul>, mpl_::size_t<1ul> >'
/usr/local/include/boost/mpl/aux_/has_type.hpp:20: instantiated from 'boost::mpl::aux::has_type<boost::mpl::less<mpl_::size_t<8ul>, mpl_::size_t<1ul> >, mpl_::bool_<true> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/quote.hpp:56: instantiated from 'boost::mpl::quote2<boost::mpl::less, mpl_::void_>::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/bind.hpp:207: instantiated from 'boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul>, mpl_::na, mpl_::na, mpl_::na>'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, 0>, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73: instantiated from 'boost::mpl::apply2<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'
/usr/local/include/boost/mpl/max_element.hpp:42: instantiated from 'boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::apply<boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73: instantiated from 'boost::mpl::apply2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:115: instantiated from 'boost::mpl::aux::iter_fold_impl<4, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:146: instantiated from 'boost::mpl::aux::iter_fold_impl<6, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/iter_fold.hpp:40: instantiated from 'boost::mpl::iter_fold<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/max_element.hpp:65: instantiated from 'boost::mpl::max_element<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > >, boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >'
/usr/local/include/boost/variant/variant.hpp:123: instantiated from 'boost::detail::variant::max_value<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::mpl::sizeof_<mpl_::arg<1> > >'
/usr/local/include/boost/variant/variant.hpp:232: instantiated from 'boost::detail::variant::make_storage<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>'
/usr/local/include/boost/variant/variant.hpp:1098: instantiated from 'boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>'
json/json_spirit_value.h:89: instantiated from 'json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >'
rpc.cpp:34: instantiated from here
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:90: warning: comparison between 'enum mpl_::size_t<1ul>::<anonymous>' and 'enum mpl_::size_t<8ul>::<anonymous>'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp: In instantiation of 'boost::mpl::less_impl<mpl_::integral_c_tag, mpl_::integral_c_tag>::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >':
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:73: instantiated from 'boost::mpl::less<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'
/usr/local/include/boost/mpl/aux_/has_type.hpp:20: instantiated from 'boost::mpl::aux::has_type<boost::mpl::less<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >, mpl_::bool_<true> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/quote.hpp:56: instantiated from 'boost::mpl::quote2<boost::mpl::less, mpl_::void_>::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/bind.hpp:207: instantiated from 'boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul>, mpl_::na, mpl_::na, mpl_::na>'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, 0>, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73: instantiated from 'boost::mpl::apply2<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'
/usr/local/include/boost/mpl/max_element.hpp:42: instantiated from 'boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::apply<boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49: instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73: instantiated from 'boost::mpl::apply2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:115: instantiated from 'boost::mpl::aux::iter_fold_impl<4, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:146: instantiated from 'boost::mpl::aux::iter_fold_impl<6, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/iter_fold.hpp:40: instantiated from 'boost::mpl::iter_fold<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'
/usr/local/include/boost/mpl/max_element.hpp:65: instantiated from 'boost::mpl::max_element<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > >, boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >'
/usr/local/include/boost/variant/variant.hpp:123: instantiated from 'boost::detail::variant::max_value<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::alignment_of<mpl_::arg<1> > >'
/usr/local/include/boost/variant/variant.hpp:238: instantiated from 'boost::detail::variant::make_storage<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>'
/usr/local/include/boost/variant/variant.hpp:1098: instantiated from 'boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>'
json/json_spirit_value.h:89: instantiated from 'json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >'
rpc.cpp:34: instantiated from here
/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:90: warning: comparison between 'enum mpl_::integral_c<long unsigned int, 1ul>::<anonymous>' and 'enum mpl_::integral_c<long unsigned int, 8ul>::<anonymous>'
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -DwxUSE_GUI=0 -o obj/nogui/init.o init.cpp
g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -O3 -o obj/sha.o sha.cpp
g++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\" -o bitcoind -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/usr/local/lib/db48\" obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -l wx_baseu-2.9 -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l crypto -l gthread-2.0
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':
/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':
/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
gmake: *** [bitcoind] Error 1
This is on FreeBSD 7.2. Any ideas?
I don't even understand what madhatter2 said.
It'd be nice to have just one single port to install and then I could just leave it as a terminate and stay resident program. Then it would log payments received in a file and could be communicated with via shell commands.
",
"nested_level": 0
},
{
"id": 501,
"thread_id": 47,
"source_id": "6",
"poster_name": "Link2VoIP",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=132",
"subject": "Re: Is there a way to automate bitcoin payments for a website?",
"url": "https://bitcointalk.org/index.php?topic=112.msg994#msg994",
"date": "2010-04-22T00:31:46Z",
"text": "You are partly correct. bitcoind is a \"terminate and stay resident program\". You communicate with it over a JSON-RPC socket to send payments/poll for received payments.
A little late, but in case anyone else has the same issue. The compile dump had 2 warnings (that were 20 lines long) and 2 link errors. The errors were:
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':
/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':
/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
Those are probably due to switching to the release build of wxWidgets instead of debug. They're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff. There's nothing to fear about the debug build. It's fully suitable for releases.
bitcoind runs as a daemon and can either be controlled by command line or JSON-RPC.
Thanks madhatter and generica for detailing the instructions for building on freebsd.
adgadg
",
"nested_level": 0
},
{
"id": 504,
"thread_id": 48,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Ummmm... where did my bitcoins go?",
"url": "https://bitcointalk.org/index.php?topic=125.msg1050#msg1050",
"date": "2010-05-03T01:18:23Z",
"text": "Did your new installation finish downloading all of the blocks (currently about 54,200)? The transaction probably won't appear until it does.
",
"nested_level": 0
},
{
"id": 505,
"thread_id": 48,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Ummmm... where did my bitcoins go?",
"url": "https://bitcointalk.org/index.php?topic=125.msg1054#msg1054",
"date": "2010-05-03T10:17:55Z",
"text": "The blocks are currently about 34 MB. I'm sure future versions will improve the download process. Including them with the installation would not be correct way of speeding up the initial download. But a trusted source could certainly host the majority of the blocks as a separate download. That would definitely speed up the process, although I think that Bitcoin double checks each block that it downloads and it probably wouldn't double check each block if you just added the file to the bitcoin user folder.
",
"nested_level": 0
},
{
"id": 506,
"thread_id": 48,
"source_id": "4",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Ummmm... where did my bitcoins go?",
"url": "https://bitcointalk.org/index.php?topic=125.msg1056#msg1056",
"date": "2010-05-03T15:27:01Z",
"text": "34 MB... on a fast DSL plan, that should take a couple of minutes. Not 3 hours....
Downloading the blocks as a single file would only take a few minutes but Bitcoin doesn't download the blocks as a single file. Try comparing the time it takes to copy a 50 GB file from one hard drive to another versus copying 50 GB of 1 KB files from one hard drive to another. The 50 GB of 1 KB files will take an eternity to copy. Try to do the same test over the Internet and the 50 GB of 1 KB files will take infinite eternities to finish. I believe Bitcoin already has a few small optimizations for how it downloads blocks but there is still a lot of room for improvement. On the bright side, Bitcoin only has to download old blocks once, after which it stays continuously up to date.
The BitCoin paper mentions \"simplified payment verification\" that could be used to accept payments without downloading all of the blocks. I don't know if this is implemented yet. It might only be enabled for clients that have \"generate BitCoins\" turned off.
",
"nested_level": 0
},
{
"id": 508,
"thread_id": 48,
"source_id": "6",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Ummmm... where did my bitcoins go?",
"url": "https://bitcointalk.org/index.php?topic=125.msg1060#msg1060",
"date": "2010-05-04T01:51:12Z",
"text": "The BitCoin paper mentions \"simplified payment verification\" that could be used to accept payments without downloading all of the blocks. I don't know if this is implemented yet. It might only be enabled for clients that have \"generate BitCoins\" turned off.
Is that referring to sending bitcoins by IP address rather than by bitcoin address?
-----
Full Member! Woot Woot!
No.
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
So you would only download the most recent 200 or so blocks and then new blocks as they come in, relying on the network to verify the blocks for you. It would be a really lightweight way to use BitCoin. It would even be useful for \"full network nodes\" as they are downloading the whole block chain.
Congrats on 100 posts!
We should bundle a snapshot of the block chain with each release of the Bitcoin software to save the user from having to download the entire chain upon a new install.
In terms of trust: The user is already trusting bitcoin.org's download to be valid. Combining the zip/exe installer with a snapshot of the block chain is not a big deal in my opinion. They can publish hashes and signatures to ensure file integrity, etc.
Even in a worst case scenario where the block chain snapshot was compromised nothing bad will happen. The longest block chain always wins. The client would download a new copy from the P2P network. (Besides, if the block chain was compromised we have bigger problems such as the software itself being trojaned, but this is another topic).
It's ++good!
34 MB... on a fast DSL plan, that should take a couple of minutes. Not 3 hours....
Really from a purist stance, people should audit the code and build it themselves.
However this would exclude most people except dorks like us.. so you just have to trust that you got it from a reputable source. I distribute a Mac OS X binary version but if you don't trust me you shouldn't be using it. Similarly, I can make a password manager tool or a PayPal assistant tool and I can make it send your passwords and money to me. You have to trust someone I guess unless you are willing to audit the code yourself. The network itself has some protections from non-cooperative nodes but the users are obviously targets for scamming. Kind of reminds me of the card skimmers people install on ATMs too.. they think they're using a trustworthy machine but it's been modified to capture their information.
",
"nested_level": 0
},
{
"id": 512,
"satoshi_id": 105,
"thread_id": 48,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Ummmm... where did my bitcoins go?",
"url": "https://bitcointalk.org/index.php?topic=125.msg1149#msg1149",
"date": "2010-05-18T20:06:46Z",
"text": "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 the whole way?
I've thought about ways to do a more cursory check of most of the chain up to the last few thousand blocks. It is possible, but it's a lot of work, and there are a lot of other higher priority things to work on.
Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network. They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.
SPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.
In the meantime, sites like
vekja.net and
www.mybitcoin.com have been experimenting with account-based sites. You create an account on a website and hold your bitcoins on account there and transfer in and out. Creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people. The only disadvantage is that you have to trust the site, but that's fine for pocket change amounts for micropayments and misc expenses. It's an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software.
Hello there,
Today I wrote an article encapsulating my idea for a new currency system of the world. One that is based on real value, open banking and technology.
After publishing it, someone pointed out to me that there is in fact already a \"prototype\" of my idea in existence. And they shared the link to Bitcoin.
To my pleasant surprise, the Bitcoin project is indeed a viable new world currency system based on the same principals I proposed in the article.
So I guess I just wanted to congratulate the developers on bringing your vision of Bitcoin to life - and that I'm excited to get involved in the project however I can.
",
"nested_level": 0
},
{
"id": 514,
"thread_id": 49,
"source_id": "2",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: A New Currency System for the World",
"url": "https://bitcointalk.org/index.php?topic=128.msg1079#msg1079",
"date": "2010-05-08T03:22:23Z",
"text": "Welcome Derrick! Watch out everyone... He's another one of those crazy Paulites! : P
",
"nested_level": 0
},
{
"id": 515,
"thread_id": 49,
"source_id": "3",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: A New Currency System for the World",
"url": "https://bitcointalk.org/index.php?topic=128.msg1080#msg1080",
"date": "2010-05-08T04:04:57Z",
"text": "Maybe when you get up to speed, you can be a spokesmen or something. Trying to explain this to the people on Ron Paul Forums gives me a terrible headache.
",
"nested_level": 0
},
{
"id": 516,
"thread_id": 49,
"source_id": "4",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: A New Currency System for the World",
"url": "https://bitcointalk.org/index.php?topic=128.msg1081#msg1081",
"date": "2010-05-08T08:52:17Z",
"text": "Nice article.
Welcome to Bitcoin, Derrick.
Another crazy paulite here...
I am using this thread to introduce myself, since I have started using bitcoin because of this article link in RonPaulForums.org . I knew bitcoin from before and I though it was a interesting project it seemed too young at the moment. But after speaking with dwdollar over there, I decided to give it a try.
Bitcoin is running now in the linux server of my home (and it should be generating coins, I just dont know how long does it take to generate one). Its running on a atom 330 with 1gig RAM and not the processor nor the memory is going out of hand, but I have a problem. I connect to my server using a VNC connection. When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.
Hello and welcome!
Bitcoin is maturing nicely. More and more shops are accepting it as payment as time goes on.
The Atom processor is quite slow. Expect to wait a few days to gain some coins. The generation difficulty has been slowly climbing lately as well so that is also working against you.
Try selling something for coins; that's the easiest way to get them and provide something useful to the Bitcoin economy.
It's ++good!
Welcome hugolp!
Regarding your sluggishness, you can fix that by giving bitcoin a lower priority (it won't slow down generation normally, just means if you want to use the computer for something else that'll get priority) by a command like:
renice -n 15 $(pidof bitcoin)
I'm sure there's a GUI option for it as well somewhere.
Also make sure your cpu fans are working, your heatsink is actually on, machine is clear of dust, etc or you might overheat.
",
"nested_level": 0
},
{
"id": 521,
"thread_id": 49,
"source_id": "9",
"poster_name": "hugolp",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=183",
"subject": "Re: A New Currency System for the World",
"url": "https://bitcointalk.org/index.php?topic=128.msg1089#msg1089",
"date": "2010-05-08T13:32:59Z",
"text": "Welcome hugolp!
Regarding your sluggishness, you can fix that by giving bitcoin a lower priority (it won't slow down generation normally, just means if you want to use the computer for something else that'll get priority) by a command like:
renice -n 15 $(pidof bitcoin)
I'm sure there's a GUI option for it as well somewhere.
Thanks. At the end I minimized bitcoin in the tray icon bar and the sluginesh disapeared. Now bitcoin its taking over the cpu (all the cores running at near 100%) but the machine works fine.
Also make sure your cpu fans are working, your heatsink is actually on, machine is clear of dust, etc or you might overheat.
Thanks. The computer is running my Mythtv server and my torrents 24h so it would have broke alredy if it was in bad state. Also, the Atom 330 does not have a fan. Thre is a fan in the system but it is for the chipset. Curiously enough, Intel did not have time to optimize the chipset as much as the cpu, so the cpu is fanless but the chipset is not, unlike any normal computer system. The next Atom generation is coming or was released shortly and I believe they have integrated the cpu+gpu+memory management (and maybe other stuff) in one chip and the chipset part is small, so it will probably wont require fan. I am not sure if the cpu now requires fan, but if it does not its perfect for a home server. I was previously running a VIA chipset and I dont like Intel too much, but the Atom's are the best at their thing: Low power, low cost and best performance for those characteristics. The atom 330 even runs 720p video without problems (it can not handle 1080p).
You'll want to renice +20 bitcoin then. I wouldn't dream of sharing a bitcoin in generation mode on a box that was playing videos. Choppy videos annoy the hell outta me.
So you think there are really new currency systems for the world? Most governments attempt to control of their currencies. When the government fixes exchange rates, there usually exists a black market. That is what I have learned in my Economics subject.
",
"nested_level": 0
},
{
"id": 524,
"thread_id": 49,
"source_id": "12",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: A New Currency System for the World",
"url": "https://bitcointalk.org/index.php?topic=128.msg3382#msg3382",
"date": "2010-07-16T04:05:25Z",
"text": "So you think there are really a new currency system for the world? Most governments attempt to control of their currencies. When the government fixes exchange rates, there usually exists a black market. That is what I have learned in my Economics subject.
They can only resist market forces for so long because Governments are restricted to a defined geographical area. Bitcoin has no boundaries or motives.
When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.
0.3.1 fixes that, sets the generate threads to the lowest priority. Download links are on the homepage now.
For a website taking payments with bitcoins, which is better: taking payments through IP solely or using tons of bitcoin addresses that you have to reuse and reuse?
And why?
",
"nested_level": 0
},
{
"id": 527,
"thread_id": 50,
"source_id": "2",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?",
"url": "https://bitcointalk.org/index.php?topic=129.msg1096#msg1096",
"date": "2010-05-09T17:03:10Z",
"text": "Right now, Bitcoin Addresses are the only option if you want automation. If you're only taking donations, or only handling manual transactions, IP Addresses might be better suited. That way they can send you comments or messages about their account info.
",
"nested_level": 0
},
{
"id": 528,
"thread_id": 50,
"source_id": "3",
"poster_name": "dsg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=97",
"subject": "Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?",
"url": "https://bitcointalk.org/index.php?topic=129.msg1098#msg1098",
"date": "2010-05-09T17:09:38Z",
"text": "Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.
",
"nested_level": 0
},
{
"id": 529,
"thread_id": 50,
"source_id": "4",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?",
"url": "https://bitcointalk.org/index.php?topic=129.msg1120#msg1120",
"date": "2010-05-14T01:16:57Z",
"text": "Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.
Isn't that \"unsafe\"?
Say I am an exit node listening for bitcoin transactions and grab them?
Or is everything public/private key encrypted?
[1][1]Which is my guess.Actually no, transfering coins via IP address isn't encrypted. When you transfer coins to an IP, the recipient creates a new address just for that transaction and tells you to transfer coins to that address. A malicious exit node could sniff all Bitcoin traffic and intercept those transactions easily.
So for everyone: DO NOT USE IP ADDRESSES AS DESTINATIONS, ALWAYS USE BITCOIN ADDRESSES.
I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.
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.
Could the bitcoin network be destroyed by someone generating endless bitcoin addresses nonstop? I mean it sounds like it would do something really bad to it.
I'm pretty sure at some point a website will take payments in bitcoins and will decide to generate a new bitcoin address for each payment and end up endlessly generating new addresses like mad and do something bad to the network. Then more will start in.
",
"nested_level": 0
},
{
"id": 533,
"thread_id": 51,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add",
"url": "https://bitcointalk.org/index.php?topic=130.msg1093#msg1093",
"date": "2010-05-09T05:34:57Z",
"text": "Generating addresses is CPU-intensive, and you don't touch the network when you generate a new address. It could only cause damage if a non-unique address was created, but this is so unlikely that it's not even worth considering.
",
"nested_level": 0
},
{
"id": 534,
"thread_id": 51,
"source_id": "3",
"poster_name": "dsg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=97",
"subject": "Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add",
"url": "https://bitcointalk.org/index.php?topic=130.msg1095#msg1095",
"date": "2010-05-09T16:12:02Z",
"text": "Yes.
Also, generating a new address for each payment is the best way to do it. Maximum anonymity because of least re-use of addresses. The keyspace is large enough that we don't need to worry about exhausting it.
",
"nested_level": 0
},
{
"id": 535,
"thread_id": 51,
"source_id": "4",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add",
"url": "https://bitcointalk.org/index.php?topic=130.msg1099#msg1099",
"date": "2010-05-09T18:47:08Z",
"text": "If you're generating a new Bitcoin Address for each transaction, people may accidentally send to old ones. They will have that BA in their Transaction history and may think it's good for multiple uses. Just something to think about.
The possibility of accidentally sending to a random BA is insanely small though.
",
"nested_level": 0
},
{
"id": 536,
"satoshi_id": 98,
"thread_id": 51,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add",
"url": "https://bitcointalk.org/index.php?topic=130.msg1130#msg1130",
"date": "2010-05-16T21:01:44Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 537,
"thread_id": 52,
"source_id": "1",
"poster_name": "bitcoin2paysafe",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=88",
"subject": "Exception: 9key_error error",
"url": "https://bitcointalk.org/index.php?topic=135.msg1122#msg1122",
"date": "2010-05-14T18:07:50Z",
"text": "Today, I've got an error message:
Exception: 9key_error
CKey::CKey(); EC:KEY_new_by_curve_name failed
bitcoin in ThreadBitcoinMiner()
Console:
terminate called after throwing an instance of 'key_error'
what(): CKey::CKey() : EC_KEY_new_by_curve_name failed
Aborted
I hope that isn't a buffer overflow. Have anybody this error message too?
OS: linux
",
"nested_level": 0
},
{
"id": 538,
"satoshi_id": 101,
"thread_id": 52,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Exception: 9key_error error",
"url": "https://bitcointalk.org/index.php?topic=135.msg1133#msg1133",
"date": "2010-05-16T22:53:59Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 539,
"thread_id": 53,
"source_id": "1",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Odd amount of generated coins",
"url": "https://bitcointalk.org/index.php?topic=141.msg1165#msg1165",
"date": "2010-05-20T09:38:53Z",
"text": "Greetings,
How is the amount of bitcoins generated per block determined? It was my understanding that is is currently fixed to 50, however a few days ago I happened to generate amount of 52.64:
Status: 729 blocks
Date: 05/15/10 08:38
Source: Generated
Credit: 52.64
Net amount: +52.64
How comes?
Regards,
Dimitri
",
"nested_level": 0
},
{
"id": 540,
"thread_id": 53,
"source_id": "2",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Odd amount of generated coins",
"url": "https://bitcointalk.org/index.php?topic=141.msg1168#msg1168",
"date": "2010-05-20T21:03:55Z",
"text": "Internally, bitcoins are bundled into packs of 50.00 or however many get sent over the network. Bitcoins usually have to be re-bundled each time they get sent. If a certain very large number of bitcoin bundles have to be re-bundled, there is a very small fee which the sender has to pay. The fee goes to the bitcoin client (yours in this case) which verifies the large re-bundling. It's not a well known behavior and I hope that future versions will display a warning or confirmation before such a fee is charged.
There is a post somewhere with more specific details. I'll look for it for a few minutes and I'll edit this post if I happen to find it. As always, the source code, which is open source, will reveal the exact behavior. I haven't examined the code and my description of the behavior is based on my poor memory, so it might not be exactly correct.
Edit:
Here's the explanation I mentioned. It seems that if more than 500 bundles of bitcoins are re-bundled, there's roughly a 0.002% fee. So during that ten minute period, one or more people each re-bundled 500 bundles of bitcoins, totaling roughly 132,000 bitcoins.
Since the sender pays the fee, I'd like to know what happens when a person sends all their bitcoins. I would expect that if there weren't enough bitcoins to cover the fee, then the amount of the fee which can not be paid would be subtracted from the payment. If this is not the case, then the fee could be avoided by sending all your coins to yourself before sending a large payment.
A transaction over the size limit can still be sent if a small fee is added.
This makes it sound like a payment wouldn't send successfully if there were insufficient funds for the fee.
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 network.
Do you want to pay the fee?\"
If you don't have enough money with the fee added, it says
\"Total exceeds your balance when the # transaction fee is included \"
",
"nested_level": 0
},
{
"id": 542,
"thread_id": 54,
"source_id": "1",
"poster_name": "molybdenum",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=208",
"subject": "CLI bitcoin generation",
"url": "https://bitcointalk.org/index.php?topic=145.msg1194#msg1194",
"date": "2010-05-22T18:44:20Z",
"text": "So I'm poking around creating a simple web interface for simple bitcoin usage (something a little lighter and less stateful than a full-on wx/GTK GUI) and I haven't seen any way to see the status of generated blocks in progress of verification... I have seen my balance jump up by 50, but of course that doesn't show up in getallreceived.
For a headless coin generation box, being able to see my status right away would be nice, or at least, being able to know if I have 30 blocks awaiting confirmation, or am still trying to get the first... if it's purely automated and just checking-and-forwarding the balance, that's not a problem though.
Additionally, in the GUI client a transaction will appear as soon as it's seen, while getallreceived only shows a transaction after a block has gone by... yet the balance jumps up by the appropriate amount right away.
I can imagine some poor nervous customer pacing back and forth worrying about his payment going through, when that wouldn't really be needed. While this *could* be used to cheat the system if a malicious machine managed to generate the winning block and exclude its own payment, but some instant indication that something was happening would be nice none the less even if it needed a \"don't accept transactions while the confirmations are still at 0\" warning tag... perhaps a separate function that included 0-confirmation transactions? An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
",
"nested_level": 0
},
{
"id": 543,
"satoshi_id": 109,
"thread_id": 54,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: CLI bitcoin generation",
"url": "https://bitcointalk.org/index.php?topic=145.msg1256#msg1256",
"date": "2010-05-26T20:09:34Z",
"text": "An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
Yeah, that actually is what it is. getallreceived 0 should do what you want. (now it's renamed to listreceivedbyaddress 0) The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations. Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.
listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] is the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven't received any payments.
Returns an array of objects containing:
\"address\" : receiving address
\"label\" : the label of the receiving address
\"amount\" : total amount received by the address
\"confirmations\" : number of confirmations of the most recent transaction included
or listreceivedbylabel if you're labelling addresses with their username.
So far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet.
Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.
",
"nested_level": 0
},
{
"id": 545,
"thread_id": 55,
"source_id": "2",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1205#msg1205",
"date": "2010-05-23T21:18:46Z",
"text": "Can you upload a screenshot? It'd help out great.
",
"nested_level": 0
},
{
"id": 546,
"thread_id": 55,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1428#msg1428",
"date": "2010-06-09T12:35:13Z",
"text": "I didn't feel like editing images, so I just took a few partial screenshots.
Edit: I just added a screenshot of the file menu in gcalctool as an example of how the menu should be displayed.
",
"nested_level": 0
},
{
"id": 547,
"thread_id": 55,
"source_id": "4",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1563#msg1563",
"date": "2010-06-14T03:49:46Z",
"text": "I don't see any problems here, running 10.04 myself now!
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fi45.tinypic.com%2Fiyhlwk.png&t=589&c=H4jWgYpiGo26dA\"/)
The problem is with the default theme. You're screen shot is not the default theme.
",
"nested_level": 0
},
{
"id": 549,
"thread_id": 55,
"source_id": "6",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1633#msg1633",
"date": "2010-06-21T09:08:36Z",
"text": "I'm new, but it works fine here. It's version 0.2 though.
http://i45.tinypic.com/1z5knb8.jpgI think the default theme in 10.04 makes everything look ugly. And why are mini/maxi/close on the left side and not the right? That's really annoying.
",
"nested_level": 0
},
{
"id": 551,
"thread_id": 55,
"source_id": "8",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1639#msg1639",
"date": "2010-06-21T13:28:02Z",
"text": "I don't thinks it looks ugly.
You can change the buttons back to the right side if you wish, just google for it.
Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.
This is now fixed in the SVN version.
1) Menu bar default color.
2) Balance bar not a different color.
3) Background behind bitcoin address and balance now the same color as toolbar.
I checked all the standard themes and it seems reasonable with all of them.
Ubuntu minimize,maximize,close buttons to the right:
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close
They've got it awfully buried considering 9 out of 10 users are used to having it on the right.
Satoshi, that definitely made it look better for me, but now Bitcoin won't minimize to tray in Ubuntu 10.04. The proper check box is checked, but it just minimizes to my taskbar like always.
",
"nested_level": 0
},
{
"id": 554,
"satoshi_id": 133,
"thread_id": 55,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1653#msg1653",
"date": "2010-06-22T03:45:56Z",
"text": "On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.
But now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.
Updated SVN.
Thanks for testing.
",
"nested_level": 0
},
{
"id": 555,
"thread_id": 55,
"source_id": "12",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1657#msg1657",
"date": "2010-06-22T06:17:52Z",
"text": "Yeah, r89 works as expected for me. It doesn't seem to have any problems creating or removing icons, but I'm using XFCE, so that might be the difference.
In addition, there's a difference between standard behaviour for tray icons in Windows and Linux. In most Linux apps, clicking the tray button while the app's window is open will cause it to close again. I personally like that better than the Windows default, where a single click does nothing once the main window is displayed. Is there any chance that feature might get added to the Linux version?
",
"nested_level": 0
},
{
"id": 556,
"satoshi_id": 136,
"thread_id": 55,
"source_id": "13",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin in Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=149.msg1668#msg1668",
"date": "2010-06-22T16:39:43Z",
"text": "It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list. I never would have noticed that if you hadn't pointed it out.
",
"nested_level": 0
},
{
"id": 557,
"thread_id": 56,
"source_id": "1",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1212#msg1212",
"date": "2010-05-24T11:56:41Z",
"text": "Can I help to translate the official homepage ( and main others ) into italian language?
Is there a way to make it easy for many other random people that want to do the same?
sirius-m: changed topic
",
"nested_level": 0
},
{
"id": 558,
"thread_id": 56,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Homepage language",
"url": "https://bitcointalk.org/index.php?topic=151.msg1215#msg1215",
"date": "2010-05-24T13:33:54Z",
"text": "Can I help to translate the official homepage ( and main others ) into italian language?
Is there a way to make it easy for many other random people that want to do the same?
Translations are very welcome! Translations show that there's a big community behind a project, and are of course helpful to those who don't speak English.
You can post your translation in this thread as an attached txt-file. Please use the same html tags (h1, h2, h3, ul, li, strong, em, img, a) as in the English page. You can translate the front page and the FAQ, or just the front page if the FAQ feels too long. Trade page changes too often to be translated, and contact info is unnecessary for people who don't speak English.
German, Spanish, Chinese and Russian translations would be especially helpful, as they're big language areas that have a lot of people who don't speak English. Of course other languages are good to have too.
Attached: the English pages with html tags, to be used as a template for translation. Download notepad++ if you want syntax highlighting
Edit 6.1.2011: You can add and update translations at https://en.bitcoin.it/wiki/Bitcoin.org_translations.Update 9.8.2013: Bitcoin.org translations:
https://www.transifex.com/projects/p/bitcoinorg/that reminds me of my intention to do a german translation ^^
",
"nested_level": 0
},
{
"id": 560,
"thread_id": 56,
"source_id": "4",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Homepage language",
"url": "https://bitcointalk.org/index.php?topic=151.msg1217#msg1217",
"date": "2010-05-24T14:20:43Z",
"text": "that reminds me of my intention to do a german translation ^^
Eh, me too... this post finally got me started, actually. I'm using Google's Translation Toolkit, so if you want in on the fun, PM me with your Google account name, and I'll invite you to contribute to or comment on the translation.
Italian homepage
removed by sirius-m, sorry :P
Italian homepage
Sorry, I ninja-edited my post while you were translating. Realized that an attachment is better than a long code block that makes the thread difficult to read (I'll remove it from your post).
Thanks for your translation, I'll add it!
Ok, I'll translate FAQ also for sure
Even though I've started using Google's Tools now, it would probably be a good idea to put all of this under version control. That'd also make it easier to see when the original page changes and you need to update the translation. I especially like how
http://whygitisbetterthanx.com/ does it -- with one branch per language in a git repository (see bottom of page).
Edit: Bitcoin front page is done. Would be good if someone else could proof-read it though. SmokeTooMuch?
In my opinion your translation is fine, DataWraith.
Just two things:
1. I think the \"f\" in Sourceforge should be uppercase. At least that`s what wikipedia tells me.
2.
Abh\u00e4ngig davon, wieviel CPU-Zeit im Leerlauf Sie beitragen k\u00f6nnen, kann es einige Tage dauern bis die ersten M\u00fcnzen erzeugt werden &endash; haben Sie also bitte etwas Geduld.
It sounds better when you write it like this:
Abh\u00e4ngig davon, wieviel CPU-Zeit
Sie im Leerlauf beitragen k\u00f6nnen, kann es einige Tage dauern bis die ersten M\u00fcnzen erzeugt werden - haben Sie also bitte etwas Geduld.
(the &endash; doesn`t get resolved correctly, you better check that again or replace it with a normal comma)
Thanks for the German translation.
",
"nested_level": 0
},
{
"id": 567,
"thread_id": 56,
"source_id": "11",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1239#msg1239",
"date": "2010-05-25T21:15:52Z",
"text": "My pleasure.
I've fixed the problems SmokeTooMuch mentioned (thanks!) in the attached version. I also should have the FAQ translated soonish (first draft is done).
We also might want to update the numbers. Even though the FAQ explicitly states that it dates back to October 2009, claiming 500 generated Bitcoins per day as achievable amount might give rise to disappointment.
Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release.
All you have to do is get poedit and translate the po file I'm attaching to this post. It's less than 750 words.
Updated bitcoin.po attachment for 0.3.1
",
"nested_level": 0
},
{
"id": 569,
"thread_id": 56,
"source_id": "13",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1265#msg1265",
"date": "2010-05-27T05:17:34Z",
"text": "I'm translating this into Dutch myself.
Don't blame my grammar or anything if I screw up!
I'm done with the FAQ, it's attached to this post. I've also attached the front_page again, because the \"Advantages:\" before the list of bullet points needed to be in its own paragraph (I assume from the structure of the files that three blank lines serve as paragraph-break in whatever CMS is used for the homepage).
I'll also take a look at the .po-file, but it'll probably take a few days.
",
"nested_level": 0
},
{
"id": 571,
"thread_id": 56,
"source_id": "15",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1267#msg1267",
"date": "2010-05-27T11:03:36Z",
"text": "Here there is the italian translation of the software.
There can be some mistakes, but it's just ok for the first version
I hope that someone will come to do something better.
Hurray! We have our first language. I uploaded it to SVN to go in with the 0.3 release.
",
"nested_level": 0
},
{
"id": 573,
"thread_id": 56,
"source_id": "17",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1271#msg1271",
"date": "2010-05-27T18:30:03Z",
"text": "Here is the almost complete (93%) translation into Dutch.
It might contain some errors though.
I can has credit now?
I uploaded the 93% complete Dutch translation to SVN. Thanks!
",
"nested_level": 0
},
{
"id": 575,
"thread_id": 56,
"source_id": "19",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1331#msg1331",
"date": "2010-06-03T11:24:49Z",
"text": "Here's the German translation for the client.
It may require some modification, because, on average, German sentences are a third longer than English ones and thus may not fit the available space. Also, I couldn't test the access keys (e.g. E&xit) properly, so I may have introduced collisions there...
",
"nested_level": 0
},
{
"id": 576,
"thread_id": 56,
"source_id": "20",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1377#msg1377",
"date": "2010-06-05T19:02:45Z",
"text": "Hey Satoshi, if I translate to tlhIngan Hol (Klingon), will you add it to the SVN?
lol!
",
"nested_level": 0
},
{
"id": 578,
"satoshi_id": 124,
"thread_id": 56,
"source_id": "22",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1600#msg1600",
"date": "2010-06-16T16:53:34Z",
"text": "Thanks DataWraith! The German translation is uploaded to SVN.
This is great, we've already got 3 major languages.
",
"nested_level": 0
},
{
"id": 579,
"thread_id": 56,
"source_id": "23",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1661#msg1661",
"date": "2010-06-22T13:57:44Z",
"text": "I got the simplified and traditional Chinese translations of bitcoin.org front page from my friend Michael Chen. Thanks Michael!
The simplified page still says \"page not found\" for some reason, I'm trying to make it work.
For the record: the Dutch translation is by giik.
",
"nested_level": 0
},
{
"id": 580,
"thread_id": 56,
"source_id": "24",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1682#msg1682",
"date": "2010-06-22T20:45:59Z",
"text": "Sirius, Can you update the German translation of the frontpage to the last version I posted? It contains the fixes proposed by SmokeTooMuch, foremost for the screwup with the – HTML entity. I'll attach it to this post again, for your convenience.
",
"nested_level": 0
},
{
"id": 581,
"thread_id": 56,
"source_id": "25",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg1839#msg1839",
"date": "2010-06-27T20:18:45Z",
"text": "Sirius, Can you update the German translation of the frontpage to the last version I posted? It contains the fixes proposed by SmokeTooMuch, foremost for the screwup with the – HTML entity. I'll attach it to this post again, for your convenience.
Done. You don't need those extra line breaks in the cms.
Thanks to Jonatan Lehtonen for the Swedish front page translation.
Anyone willing to help us with a Spanish, Russian or French translation here?
I have a friend who might be willing to translate it into Romanian, already dropped him a message.
",
"nested_level": 0
},
{
"id": 584,
"thread_id": 56,
"source_id": "28",
"poster_name": "aidos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=343",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg2575#msg2575",
"date": "2010-07-13T16:46:56Z",
"text": "I'm working on the french translation
I recommend to remove the download links at the bottom of the main page.
As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.
",
"nested_level": 0
},
{
"id": 586,
"thread_id": 56,
"source_id": "30",
"poster_name": "milkiway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=434",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg2906#msg2906",
"date": "2010-07-14T18:37:14Z",
"text": "I'm working on spanish translation for the faq and the main web
Also the soft, i just downloaded the po file
Here is the spanish po file. When I can see it into the program, I'll check the translation errors and I'll try to fix it
Tomorrow I'll start to traslate the main web and the last will be the faq
PD: Can anyone post the last versi\u00f3n of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!
Edit: I'll check and update the spanish po file
PD: Can anyone post the last versi\u00f3n of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!
I updated the .txt files in my post on the first page.
Ok here is the .po file for French. While I'm at it, I noted a couple of issues:
1. The \"About\" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the \"About\" box message. Same problem with the \"Apply\" button in the Settings window.
2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as \"\u00e9\u00e0\u00e8\u00e7\"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.
3. Some translated strings don't fit in the dialog box anymore (French is a bit more verbose than English). Some cases can be solved by inserting a \"\n\", but that's not always possible (window titles for example).
4. About the .po file :
- There are a few strings in the .po file that don't needs translation (ie: \"Bitcoin\"). Maybe those shouldn't be inside _(\"...\") ?
- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit.
- Many strings have all their words capitalized, which just looks strange in French. I checked, none of my other software do it, so I've used normal capitalization everywhere.
- There are a couple message strings that are almost identical, maybe using the same string for each of those messages would be better ? Example : \"This is an oversized transaction that requires a transaction fee of %s\" and \"Error: This is an oversized transaction that requires a transaction fee of %s \". It's the exact same text except for \"Error:\" at the beginning and an extra space at the end (which is probably useless ?).
Finally, The provided .po file is not up-to-date, as one of the settings string has changed, and is not getting translated (the one about starting Bitcoin at login).
Otherwise Bitcoin seems like a great concept, good work !
",
"nested_level": 0
},
{
"id": 590,
"thread_id": 56,
"source_id": "34",
"poster_name": "milkiway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=434",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3114#msg3114",
"date": "2010-07-15T08:34:52Z",
"text": "PD: Can anyone post the last versi\u00f3n of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!
I updated the .txt files in my post on the first page.
Thanks!
2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as \"\u00e9\u00e0\u00e8\u00e7\"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.
I noticed it right now. I must review the spanish po-file
Here, the po file updated and the front page translated into Spanish
This afternoon I'll start to translate the faq
Ok here is the .po file for French. While I'm at it, I noted a couple of issues:
1. The \"About\" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the \"About\" box message. Same problem with the \"Apply\" button in the Settings window.
I need to give an updated .po file.
2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as \"\u00e9\u00e0\u00e8\u00e7\"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.
OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can.
4. About the .po file :
- There are a few strings in the .po file that don't needs translation (ie: \"Bitcoin\"). Maybe those shouldn't be inside _(\"...\") ?
- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit.
Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN.
I uploaded an updated bitcoin.po for 0.3.1 attached to this message:
http://bitcointalk.org/index.php?topic=151.msg1259#msg1259please use it if you're starting a new translation.
If you already have a po file, poedit can update it.
- Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:
http://bitcointalk.org/index.php?topic=383.0- Make a subdirectory under src: locale/??/LC_MESSAGES
(?? could be anything really, \"en\" or your language 2-letter code)
- Put your .po file there
- Open it with poedit
- In poedit, Catalog->Update from sources
The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.
I recommend to remove the download links at the bottom of the main page.
As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.
I updated them to 0.3.0.
I am tempted to remove the download links from the other languages and only keep it on English.
They will need to be updated for 0.3.1 soon. Perhaps there's a way for someone to manage the updating of the translated drupal pages.
Thanks for the Spanish and French translations! The edited and updated .po files are attached.
I uploaded these to the SVN.
",
"nested_level": 0
},
{
"id": 597,
"thread_id": 56,
"source_id": "41",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3425#msg3425",
"date": "2010-07-16T10:02:33Z",
"text": "Working on Russian translation, will be available in a day or two.
",
"nested_level": 0
},
{
"id": 598,
"thread_id": 56,
"source_id": "42",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3440#msg3440",
"date": "2010-07-16T11:42:15Z",
"text": "BTW, there is a bug with translating this string:
#: ../../../ui.cpp:634
msgid \"From: unknown, Received with: \"
Russian translation doesn't show in the main window, only colons and comma appear. So it looks like: \u00ab : , : 18RRVv...\u00bb (cut the address) Looks like unicode problem, although there is correctly translated string in the first column (confirmations \u21d2 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u0439). Despite this the translation is almost complete but I have to be sure that everything looks like it should.
",
"nested_level": 0
},
{
"id": 599,
"thread_id": 56,
"source_id": "43",
"poster_name": "d1337r",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=449",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3487#msg3487",
"date": "2010-07-16T14:43:08Z",
"text": "BTW, translated the wiki page \"getting started\" to Russian. There should be a DokuWiki add-on or setting which displays the 'translations of this page' combobox like the home page of dokuwiki.org. For now, it's just a link in the getting started page.
",
"nested_level": 0
},
{
"id": 600,
"thread_id": 56,
"source_id": "44",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3501#msg3501",
"date": "2010-07-16T15:02:01Z",
"text": "Looks like the translation is nice, except the already mentioned bug. File attached.
Fix: I reuploaded the file with some corrects. I don't really get what does \"Net amount:\" mean so translated it literally.
",
"nested_level": 0
},
{
"id": 601,
"thread_id": 56,
"source_id": "45",
"poster_name": "milkiway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=434",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg3738#msg3738",
"date": "2010-07-17T13:38:07Z",
"text": "Spanish FAQ translated.
Later, I'll check if there are errors
Spanish frontpage and FAQ cleaned for errors and updated.
Please, update from this two files. Thanks!
",
"nested_level": 0
},
{
"id": 603,
"thread_id": 56,
"source_id": "47",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg4020#msg4020",
"date": "2010-07-18T16:46:48Z",
"text": "Spanish frontpage and FAQ cleaned for errors and updated.
Please, update from this two files. Thanks!
Updated. Thanks.
Spanish frontpage and FAQ cleaned for errors and updated.
Please, update from this two files. Thanks!
Updated. Thanks.
Thanks to Tao Wan for the Chinese FAQ. We'd appreciate if somebody could check the translation or fill in the missing questions.
",
"nested_level": 0
},
{
"id": 606,
"thread_id": 56,
"source_id": "50",
"poster_name": "d1337r",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=449",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg5065#msg5065",
"date": "2010-07-22T16:16:20Z",
"text": "Hmm.. Here are some \"beta\" versions of Russian translations for the site itself. (They are complete, but not perfect)
",
"nested_level": 0
},
{
"id": 607,
"thread_id": 56,
"source_id": "51",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg5446#msg5446",
"date": "2010-07-24T03:50:06Z",
"text": "Hmm.. Here are some \"beta\" versions of Russian translations for the site itself. (They are complete, but not perfect)
Thanks. You can send updates when they're ready.
It looks like a Russian branch of the wiki now exists. I imagine it would be a good idea to have the Russian Documentation link on the front page link to it.
",
"nested_level": 0
},
{
"id": 609,
"thread_id": 56,
"source_id": "53",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg5747#msg5747",
"date": "2010-07-25T20:34:48Z",
"text": "Translation of bitcoin-0.3.2 into Russian
",
"nested_level": 0
},
{
"id": 610,
"thread_id": 56,
"source_id": "54",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg5750#msg5750",
"date": "2010-07-25T20:37:54Z",
"text": "Despite this the translation is almost complete
Damn! I also made this work. I so wanted to be helpful!
(But I insist that an \"unknown\" != \"anonymous\")
Damn! I also made this work. I so wanted to be helpful!
(But I insist that an \"unknown\" != \"anonymous\")
Do you have the same problem with russian text in the main window?
Damn! I also made this work. I so wanted to be helpful!
(But I insist that an \"unknown\" != \"anonymous\")
Do you have the same problem with russian text in the main window?
I don't tried to build the program.
If you tell me what command builds this project under linux I can do it.
I propose to make national sections of the forum. As a minimum, the Russian section is ripe.
http://bitcointalk.org/index.php?topic=593.msg6125Russian board created. Let me know if there's demand for a board in some other major language.
",
"nested_level": 0
},
{
"id": 615,
"thread_id": 56,
"source_id": "59",
"poster_name": "milkiway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=434",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg6809#msg6809",
"date": "2010-07-31T13:42:43Z",
"text": "Please, update the links for 0.3.6 version in the spanish translation!
",
"nested_level": 0
},
{
"id": 616,
"thread_id": 56,
"source_id": "60",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg8777#msg8777",
"date": "2010-08-11T18:20:36Z",
"text": "I'm translating the po file to Brazilian Portuguese.
",
"nested_level": 0
},
{
"id": 617,
"thread_id": 56,
"source_id": "61",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg8785#msg8785",
"date": "2010-08-11T19:15:27Z",
"text": "My first draft is attached, but it surely has issues (masculine/feminine, plural/singular, the placing of the & etc). Is there a way I could test the program with this translation in order to correct stuff?
",
"nested_level": 0
},
{
"id": 618,
"thread_id": 56,
"source_id": "62",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg10034#msg10034",
"date": "2010-08-18T08:08:59Z",
"text": "Anyone interested in making a French translation? Twitter shows there might be interest towards the project from that direction.
smf supports too much languages. If only u install them
Or maybe i did'nt found where can i change it in profile settings?
Updated russian translation. Now works fine without issues. Hope it will be included in the next version.
",
"nested_level": 0
},
{
"id": 621,
"thread_id": 56,
"source_id": "65",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14164#msg14164",
"date": "2010-09-26T21:45:51Z",
"text": "Anyone interested in making a French translation? Twitter shows there might be interest towards the project from that direction.
I see on this thread that some people made a french translation. Still, I don't see it on the main page.
I made one myself, in html format. It's just a basic translation of the main page.
A little update on translation. Haven't understood \"matures in %d blocks\" phrase right but generated a block today and fixed this.
",
"nested_level": 0
},
{
"id": 623,
"thread_id": 56,
"source_id": "67",
"poster_name": "kaja",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1701",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14393#msg14393",
"date": "2010-09-28T13:33:11Z",
"text": "http://ompldr.org/vNW56aw/index.html \u2190 The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).
Please do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop.
",
"nested_level": 0
},
{
"id": 624,
"thread_id": 56,
"source_id": "68",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14413#msg14413",
"date": "2010-09-28T19:10:59Z",
"text": "http://ompldr.org/vNW56aw/index.html The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).
Please do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop.
Saluton, kaja !
Ni babilis en freenode #esperanto, cxu ne ?
http://ompldr.org/vNW56aw/index.html The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).
Please do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop.
Saluton, kaja !
Your traduction doesn't seems very good. For instance, we can't use 'kriptmonunuo' since the word 'kripto' doesn't mean 'to cypher' at all. The correct esperantist world is 'Cxifri', I think.
:O Grondilu, you are correct. I didn't know that kripto meant that. I thought it was a synonym for \u0109ifro!
Anyway, that's fixed now. Are there any other errors?
http://ompldr.org/vNW83OQ/index.htmlBy the way, the English word for 'traduction' is 'translation'.
:O Grondilu, you are correct. I didn't know that kripto meant that. I thought it was a synonym for ifro!
Anyway, that's fixed now. Are there any other errors?
http://ompldr.org/vNW83OQ/index.htmlBy the way, the English word for 'traduction' is 'translation'.
Cxifromono seems much better, I think. I'm not a very experienced esperantist, so I'm not much confident about my skills to judge your translation. I suggest you post your work on soc.culture.esperanto or something.
Thanks for the French and Esperanto translations!
I see on this thread that some people made a french translation. Still, I don't see it on the main page.
I don't see a previous French translation of the main page.
Thanks for the French and Esperanto translations!
I see on this thread that some people made a french translation. Still, I don't see it on the main page.
I don't see a previous French translation of the main page.
It is now.
However, I made a few mistake.
Here is a slighlty modified version.
Also, the esperanto version is incorrect. Please use this one instead.
How can I find the English .po file so that I may translate the software to Esperanto?
",
"nested_level": 0
},
{
"id": 631,
"thread_id": 56,
"source_id": "75",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14657#msg14657",
"date": "2010-09-30T05:30:14Z",
"text": "Edit any po-file, they all contain English strings. Esperanto? WOW! LOL!
Esperanto? WOW! LOL!
Pretty cool, hum ? :-)
But I'll feel much better when someone edit the current page and change the horrible word 'Kriptomonunuo' to 'Cxifromono'.
Yeah, it would be very funny.
I also have a claim to the translation but to the Bitcoin's Russian localization.
We have historically two variants of the word 'transaction'. One word is used
in banks and business when it comes to money transfer, and another word is
used in computer science: words '\u0442\u0440\u0430\u043d\u0441\u0430\u043a\u0446\u0438\u044f' and '\u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f' accordingly.
I updated the translation and replaced \u00ab\u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f\u00bb with more neutral and casual word \u00ab\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u00bb. Also made some corrections on other phrases.
",
"nested_level": 0
},
{
"id": 635,
"thread_id": 56,
"source_id": "79",
"poster_name": "Golobulus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1751",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14707#msg14707",
"date": "2010-09-30T15:57:26Z",
"text": "Hi guys,
I only heard about the bitcoin project a few days ago from my friend and really liked the idea. Since then my PC has been trying to generate some bitcoins.
I am going to translate the page to Polish. I assume all I do is just view the HTML source of the original page and replace English with Polish?
Thanks and regards.
In addition to the kriptomonunuo problem, there's another problem that the righthand side menu for all languages is English no matter which language is selected!
",
"nested_level": 0
},
{
"id": 637,
"thread_id": 56,
"source_id": "81",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg14799#msg14799",
"date": "2010-10-01T02:16:30Z",
"text": "In addition to the kriptomonunuo problem, there's another problem that the righthand side menu for all languages is English no matter which language is selected!
Maybe you should pm sirius-m directly.
But please first make sure that the translation is correct now, because I guess he won't be happy if we disturb him twice for a translation, especially with this language !
Thanks eurekafag, Russian translation added to SVN rev 160.
",
"nested_level": 0
},
{
"id": 639,
"thread_id": 56,
"source_id": "83",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg15248#msg15248",
"date": "2010-10-04T10:55:56Z",
"text": "Glad to hear that. Where can I find the latest English .po file to keep the translation up-to-date?
",
"nested_level": 0
},
{
"id": 640,
"thread_id": 56,
"source_id": "84",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg15316#msg15316",
"date": "2010-10-04T16:34:07Z",
"text": "It does not exist.
",
"nested_level": 0
},
{
"id": 641,
"thread_id": 56,
"source_id": "85",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg15324#msg15324",
"date": "2010-10-04T17:16:06Z",
"text": "Seriously : could anyone replace \"Kriptomonunuo\" by \"Cxifromono\" in the esperanto page ? \"Kriptomonunuo\" is very ugly for it means \"the money unit from the crypt\". In esperanto, \"kripto\" is the underground cell where we burry dead people.
Please !
",
"nested_level": 0
},
{
"id": 642,
"thread_id": 56,
"source_id": "86",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg15344#msg15344",
"date": "2010-10-04T18:40:49Z",
"text": "I am going to translate the page to Polish. I assume all I do is just view the HTML source of the original page and replace English with Polish?
Yes, but only the content part and no downloads.
Seriously : could anyone replace \"Kriptomonunuo\" by \"Cxifromono\" in the esperanto page ?
Done
Where can I find the latest English .po file to keep the translation up-to-date?
poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources.
So for example, you have:
src
src\\base58.h
src\\bignum.h
...
src\\util.cpp
src\\util.h
src\\xpm
src\\locale\ru\\LC_MESSAGES\\bitcoin.po
Open bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\\..\\..) from where bitcoin.po is.
This updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn't make any bad guesses.
Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I'm attaching your Russian one to this message.
Shame on me, I haven't know about this useful tool before. Thanks for the clear explanation I've updated the translation according to rev160. How often should I review and update the translation? That's not a problem to do this for every revision but I don't want to spam this topic with translations every 2-3 days. Maybe it's good to make an announce that new release is coming in a few days so translators could update their files in time?
",
"nested_level": 0
},
{
"id": 645,
"satoshi_id": 486,
"thread_id": 56,
"source_id": "89",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg15660#msg15660",
"date": "2010-10-06T15:42:39Z",
"text": "poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?
Strings aren't added or changed very often. It's months before enough changes build up.
I uploaded the changes.
This Windows build has the Russian translation in it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exeStrange enough. I ran it on my usual XFS and new untranslated strings appeared on top. Is the order so important? I guess it's not for the program and for translators because when one use poedit he can always check what the particular string belongs to. By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.
",
"nested_level": 0
},
{
"id": 647,
"satoshi_id": 492,
"thread_id": 56,
"source_id": "91",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Website and software translations",
"url": "https://bitcointalk.org/index.php?topic=151.msg17965#msg17965",
"date": "2010-10-21T22:50:47Z",
"text": "The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can't diff for changes. I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.
I can still put it back into normal order by making poedit rescan it.
It is normal that untranslated strings are shown on top.
By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.
I know, but not easily without complicating the sourcecode.
I have a question.
I saw that everyone need to get blocks before starting to get coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks somewhere on the official website?
",
"nested_level": 0
},
{
"id": 649,
"thread_id": 57,
"source_id": "2",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1224#msg1224",
"date": "2010-05-24T19:49:00Z",
"text": "Well, what if the main website gets hacked and the blocks you are downloading are not the original blocks?
I mean, this makes the network a hell of a lot of insecure.
",
"nested_level": 0
},
{
"id": 650,
"thread_id": 57,
"source_id": "3",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1225#msg1225",
"date": "2010-05-24T19:55:54Z",
"text": "I think that probably they won't be accepted by the majority of the network, that they have a different database/hash ... is it right?
",
"nested_level": 0
},
{
"id": 651,
"thread_id": 57,
"source_id": "4",
"poster_name": "Dynotor",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=197",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1228#msg1228",
"date": "2010-05-24T21:30:39Z",
"text": "I have a question.
I saw that everyone need to get blocks before starting to get coins.
Does it mean that these blocks are the same for everyone?
Is there a database with all of them?
So ... can I share this database with someone else to make him able to generate coins after few seconds?
I'm not sure if I have understood correctly how everything works
If I'm right ... can we share an always updated database of blocks somewhere on the official website?
I'll defer to others on whether having a central database is a good idea, but if you're creating multiple directories with the -datadir command line option, you can safely bootstrap that directory by copying \"blkindex.dat\" and \"blk0001.dat\" from an already established data directory into your new one.
While a central database, or at least a partially-completed centralized copy of a certain number of blocks would speed things up, but then, so would mass-transfer between clients (requests for 500 blocks or so instead of one blocks at a time) and the latter would implement it within the confines of the network, without needing web hosting for a copy of the block database.
Currently, I believe one could grab a copy of someone else's blk*.dat files and speed the process up that way, but it really shouldn't be needed when the same thing can be done with a few snippets of code.
A draft standard for the bitcoin wire protocol would possibly be a help here, in that it would be possible for someone C++-illiterate to see what actually is possible in the current system ;-)
EDIT: if I understand correctly, a complete false start that wouldn't disappear as soon as a client connected to the network at large would require generating as many blocks as were currently in the network, so, one individual would have to generate 57525 blocks to do major harm to the network.
It could give someone a head start in forging a block, but not really. Having a rouge starter set of blocks would be just like having each new node started from that set of blocks be a rouge node, so it should be similarly impractical to forge anything.
",
"nested_level": 0
},
{
"id": 653,
"thread_id": 57,
"source_id": "6",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1230#msg1230",
"date": "2010-05-25T04:44:05Z",
"text": "Most of the slowness results from the blocks needing to be verified one at a time in order, not from network delays. At least according to, if I'm not mistaken, satoshi, the Bitcoin author, in another thread. There has been some talk about a lightweight client, which doesn't verify all the blocks, but instead only broadcasts transactions. I'm not familiar with the algorithm, but if it's possible, I think it would be best to just alter the regular client so that when it starts up the first time, it grabs the most current block and verifies blocks in reverse order while also continuing to verify new blocks. That way Bitcoin could start generating blocks immediately.
",
"nested_level": 0
},
{
"id": 654,
"thread_id": 57,
"source_id": "7",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1231#msg1231",
"date": "2010-05-25T07:18:25Z",
"text": "I'm not familiar with the algorithm, but if it's possible, I think it would be best to just alter the regular client so that when it starts up the first time, it grabs the most current block and verifies blocks in reverse order while also continuing to verify new blocks. That way Bitcoin could start generating blocks immediately.
Good idea, but we would need some form of indicator it did that to the user, and warn the user about the potential hazards.
(Atleast, that's my idea.)
It only verifies the last few as it is, to speed things up, but it doesn't work backwards.
Satoshi has mentioned a simplified payment verification system that he is planning to implement, which would allow payment only clients which do not have to verify all the blocks - he just hasn't written it yet.
I think even if you could just have someone 'click here to install instantly' it wouldn't do any good because they wouldn't have any bitcoins and they wouldn't know what a bitcoin is
Although I'm not familiar with the specifics of the algorithm implementation in C++, I am familiar with how the verification works in general. Although the algorithm would have to be re-written, it really should be possible to verify blocks in both directions at the same time. Each block contains the hash of the previous block, but the first block contains a genesis hash, which isn't the hash of a previous block. The first time bitcoins starts, it would treat a recent hash, perhaps a one day old hash as a temporary genesis hash and quickly verify the roughly 144 blocks up to the most recent block and it would continue to verify and optionally generate new hashes. Another thread would grab a previous hash, perhaps a two day old hash and treat it as the new temporary genesis hash. It would quickly verify the roughly 144 blocks, and verify that the last hash matches the previous genesis hash. The second thread would continue verifying previous blocks until it reached the real genesis block, which I believe is defined within Bitcoin itself. As you can see, blocks are always being verified in forward direction, but the beginning point is just pushed back until it reaches the real beginning. There could even be a third thread which would start at the real genesis hash and verify blocks from there so that they meet in the middle. All three of those threads could be grouped into another thread which would be run for each different chain of blocks which it is told about from other Bitcoin peers. If more than one chain is verified as authentic, Bitcoin would calculate and compare the total amount of computing power required to create the chain and keep only the strongest chain. Off the top of my head, an easy way to calculate the strongest chain, would be to find the largest sum of the inverses of the numeric value of each hash.
",
"nested_level": 0
},
{
"id": 657,
"satoshi_id": 110,
"thread_id": 57,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Share database blocks ?",
"url": "https://bitcointalk.org/index.php?topic=153.msg1258#msg1258",
"date": "2010-05-26T20:34:34Z",
"text": "It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.
The advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you're downloading them from. If you downloaded the blk*.dat files from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself. If you're copying blk*.dat from another computer of yours, that should be fine.
How long is the initial block download taking for you?
",
"nested_level": 0
},
{
"id": 658,
"thread_id": 58,
"source_id": "1",
"poster_name": "Dynotor",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=197",
"subject": "Tracing a coin's lineage",
"url": "https://bitcointalk.org/index.php?topic=154.msg1234#msg1234",
"date": "2010-05-25T18:27:19Z",
"text": "Assuming a goal of bitcoin is to introduce anonymity to online transactions, one of the things that concerns me most is the traceability of coins to previous transactions. I've read a lot of discussion about this in the forums, but there's still some open questions for me.
So first, let me state what I do understand:
1) All transactions are public in their amounts and public key identities as follows:
a) In a transaction, you can see the public key of the person who spent the money
b) In a transaction, I *think* but am not completely sure you can see the public key of the person who gets the money. (If you can't, you'll see it when they spend the money later, so this isn't that important.
2) Keeping your public keys from being associated with your identity is required if you don't want your transactions to be attributable to you.
We need to better educate users on how to do #2. I have an information security background, and it's not even immediately obvious to me what the best ways of handling bitcoins are to maximize your privacy.
I have these specific questions or comments regarding this topic:
1) Are one-time public keys disposed of when they are no longer required?
For example, I've read that a one-time-use private key is created when I generate a bitcoin block. When I spend these coins and I've signed them to someone else, I shouldn't need that private key anymore. The same thing goes for a key created for taking a payment-by-IP. Keeping keys around after they are no longer necessary may make a user vulnerable to later having their wallet seized and used to prove that they originated a transaction.
2) Reusable keys (those created inside the GUI) should be able to be similarly deleted when they are no longer required. This is a bit more dangerous, because once you delete the key you won't be able to get payments sent to that key, so the user really needs to understand what's going on in this case. Keys with coins stored under them obviously shouldn't be deleted.
3) We really need to make it possible to track coin bundle's lineage to enable the user to know their risk regarding spending specific coins. I think it should be possible, within the GUI, to see all the public keys associated with each coin bundle. It would also be nice to be able to tag keys that are associated with you with comments to aid you in determining which coins to send to someone. That way you could realize that another bitcoin user has seen you use a specific key, and to restrict other coins that are also associated with that key to a similar purpose and not something else that would link the two identities.
4) In addition to making it possible to track a coin bundle's lineage, we also need to be able to choose which coin bundles to include in a payment.
The important thing here is that we need to make the information that is possible to acquire through digital forensics to be easily accessible by the end user. Only by making this information accessible to the end user will people be able to make good security decisions regarding the spending of bitcoins in sensitive environments.
One more thing that is important: Once these features are available, exchangers need to have clear data retention policies. For example, if I was an exchanger, I might keep track of the public keys of the people that I am doing active trades with. I'd probably retain this information until I had traded out the coins I had acquired through a trade, but would dispose of this information once the coins had left my possession. I would also have a policy to not share that information with third parties unless required to by a court order. If I was trading with an exchanger, I would want to know what their policies were and how they differed from my expectations.
",
"nested_level": 0
},
{
"id": 659,
"thread_id": 58,
"source_id": "2",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Tracing a coin's lineage",
"url": "https://bitcointalk.org/index.php?topic=154.msg1238#msg1238",
"date": "2010-05-25T21:12:51Z",
"text": "The points you mentioned are of high concern to me (and should be to the rest of the community.)
Your suggestion of making the information that can found with/through digital forensics available to the user seems very good in securing Bitcoin.
Maybe build a \"paranoid mode\" switch in Bitcoin that will immediately show all that info to the user!
Also what seems like a good idea is to show that switch in a \"first run dialog\", but some people find that annoying. (I would too a business environment!)
Maybe distribute a \"Home\" and \"Business\" binary that has the \"first run dialog\" and one without it, ofcourse in that order.
But, as this data is available, and people will trust Bitcoin (sometimes blindly), we'll have to warn users about pitfalls.
Have proper documentation documenting everything, even for the \"paranoid users\".
Users will have to learn how to make safe transactions, etc...
If someone screws up and gets screwed over by the justice system because he trusted Bitcoin blindly, he'll speak about it and Bitcoin will get a bad name.
My conclusion: the Bitcoin community needs to watch out for the losers dumb users lusers!
",
"nested_level": 0
},
{
"id": 660,
"thread_id": 58,
"source_id": "3",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Tracing a coin's lineage",
"url": "https://bitcointalk.org/index.php?topic=154.msg1240#msg1240",
"date": "2010-05-25T21:29:05Z",
"text": "It's good that someone is thinking along the lines of how security/anonymity could be compromised.
Yes, you know both sender and recipient of a payment. The recipient's key is always included, and from there you can trace the coin back to the previous recipient, i.e. the current sender.
My 2\u0e3f worth of thoughts:
Ideally the Bitcoin wallet should be encrypted, and future versions will implement that. Now, leaving malware out of the picture (which would probably just send all bitcoins to the hacker in question instead of tracing transactions back), when both your computer is confiscated and you are forced to reveal the password, you're probably already in big trouble... you'd have to already have screwed up other than by using bitcoin in an unsafe manner. Personally I don't worry about this, but it is good that somebody does.
As an aside: Bitcoin can be used over the TOR network, so one can hide one's IP address. There are also the web-based wallet services, which might make it harder to trace a transaction that went through them. On the other hand, they could do some tracing of their own... The deciding factor here is which coins are chosen for which transactions.
As for coin lineage, yeah, that might be a problem. Currently it is a best practice to give out a different address to every sender, and only give it to them. An outside observer you can't know if the next recipient (or rather crypographic key) the coin is sent to is one of your aliases or someone else entirely. Bitcoin Currency Exchanges (or any high-volume user) might be a problem here, but otherwise one probably doesn't have enough data to infer much about the transfers, it just becomes untractable if every person has a lot of different addresses. One additional point here is that old transactions expire after a while, and the space is reclaimed -- that wouldn't stop a serious attacker, but it's helping a little.
",
"nested_level": 0
},
{
"id": 661,
"thread_id": 58,
"source_id": "4",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Tracing a coin's lineage",
"url": "https://bitcointalk.org/index.php?topic=154.msg1242#msg1242",
"date": "2010-05-26T00:50:04Z",
"text": "Can't we force a user to use a new address for receiving payments?
Every time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that'd be useless, right?)
The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address. (We wanna minimize \"lost\" Bitcoins, right?)
This yields a couple of questions:
- Is this technologically possible? (Probably.)
- Is this bad to force it upon users? (Probably.)
- Should we implement such a feature? (I don't know, I wouldn't unless we don't have a choice, better half a defense than none!)
So, are there any alternatives to combat \"coin lineage\"?
BitCoin could automatically send random coins to a new address at random times. This would make knowing a coin's lineage useless to an attacker, since any of these new addresses could be actual people.
",
"nested_level": 0
},
{
"id": 663,
"satoshi_id": 108,
"thread_id": 58,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Tracing a coin's lineage",
"url": "https://bitcointalk.org/index.php?topic=154.msg1254#msg1254",
"date": "2010-05-26T18:51:04Z",
"text": "Can't we force a user to use a new address for receiving payments?
Every time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that'd be useless, right?)
The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address.
This is on my list. I will soon make the \"Your Bitcoin Address:\" window automatically change whenever you receive anything to the address displayed.
I'm also recommending this approach for the implementation of web apps. I just posted some sample code showing a suggested way of implementing this.
Versions on SVN since 0.2.4 already have a \"New...\" button next to the address bar to encourage changing it manually too.
@theymos: If nothing else, we can fall back on that solution in the future.
I added label related functions to help with managing multiple addresses per user. New or renamed functions are:
getreceivedbyaddress -- amount received on a single address
getreceivedbylabel -- amount received by all addresses with this label
listreceivedbyaddress -- list addresses and amounts they've received
listreceivedbylabel -- list labels and amounts they've received
setlabel -- misc label functions for completeness
getlabel
getaddressesbylabel
For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress. The old names are still there so as not to break existing code, but they're deprecated.
The idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the \"bylabel\" functions. You can freely change their address without worrying about tracking all their old addresses.
A good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:
// Get a new address whenever the current one has received anything
if (strAddr == \"\" || getreceivedbyaddress(strAddr) > 0)
strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address
// Get total received by all the user's addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance
If you're just getting one particular user's balance, such as in response to a page request by that user, use getreceivedbylabel, but if you're scanning over all users, it's better to use listreceivedbylabel to get the complete list and scan against the result. Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).
You should only really need to scan all users if you're polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it. It's not necessary to poll very frequently. If you require 1 confirmation, that'll take an average of 10 minutes anyway, so there's no point in polling more often than every few minutes.
If you're selling digital goods and services, where you don't lose much if someone gets a free access, and it can't be resold for profit, I think you're fine to accept 0 confirmations.
It's mostly only if you were selling gold or currency that you'd need multiple confirmations.
",
"nested_level": 0
},
{
"id": 665,
"thread_id": 60,
"source_id": "1",
"poster_name": "SirArthur",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=217",
"subject": "Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1284#msg1284",
"date": "2010-05-29T04:38:52Z",
"text": "At least the Windows client seams unable to resolve hostnames - or doesn't even try, pops up an \"Invalid Address\" right away.
This is a huge setback taken most people have dynamic IP Addresses. Therefore, instead of \"123.123.123.123\" only it should be added the hability to send also to \"someone-accepting-bitcoins.somedomain.sometld\".
",
"nested_level": 0
},
{
"id": 666,
"thread_id": 60,
"source_id": "2",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1292#msg1292",
"date": "2010-05-29T16:41:24Z",
"text": "Or it should just look the hostname up before it dismisses it as an invalid address.
This has probably just slipped the mind of the developer.
",
"nested_level": 0
},
{
"id": 667,
"thread_id": 60,
"source_id": "3",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1317#msg1317",
"date": "2010-06-01T11:01:02Z",
"text": "There are security implications with sending payments to a 'hostname' instead of an internet address. TCP is difficult to forge, however DNS is trivial. It is not a good idea to send payments to a hostname. Whether it is an oversight or intentional, it probably should not be used for anything where fraud is a concern.
Here's something I quickly googled up for anyone interested:
http://adventuresinsecurity.com/Papers/DNS_Cache_Poisoning.pdfIt is not even really an attack, it's just how it works.. This is why once people figured out that DNS was unreliable, things like .rhosts for rsh went out of style and ssh uses public keys instead. It still does some DNS checking to see if the key changed, which could indicate that the DNS has been used to divert your connection to another host.
It is very easy for me to make your computer think that someone-accepting-bitcoins.somedomain.sometld is MY computer, especially if I know you will be sending payment to it.. however if somedomain.sometld is some popular well known service like an exchange, I can just go trying to poison every bitcoin user's cache randomly and see how many I get. I know every node's network address so I can figure out who their provider is, thus I can easily narrow down which recursors they're likely to be using, so it makes attacking it a lot nicer rather than blindly messing with a bunch of random resolvers that may or may not have any effect.
Many internet DNS servers will just accept any random data you send them, though there have been attempts to patch these things and work around some of the really trivial attacks. In the end though, it is the DNS protocol that's at fault and it is not easily patchable without replacing it. There are things in the works to make the protocol more secure and such, but until it's adopted by the entire internet, there will always be places to mess with it.
It is not even a good idea to send payment to an internet address in my opinion, because the way it is implemented in bitcoin right now, you don't know if you connected to the right node. There is no pre-shared password or public key to verify manually. While it is not feasible to take over an existing TCP connection, it is possible to use NAT to divert it. In this case the attacker would have to have control of a router along the way to your destination, but in the case of Tor anyone can run an exit node and just accept all the bitcoin payments.. it's really easy to do that because they're all on port 8333 so I can just DNAT every connection to 8333 to my own bitcoin host.
Just don't use hostnames or internet addresses - use bitcoin addresses.
Here we go again...
YES, you can be phished, hijacked, whatever... but, again, it has to rely on informed options rather than behaviors of \"I decided this is more secure to you\".
",
"nested_level": 0
},
{
"id": 669,
"thread_id": 60,
"source_id": "5",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1320#msg1320",
"date": "2010-06-01T12:17:23Z",
"text": "I'm not sure what you mean by again (I'm not the developer).. anyway I'm just trying to explain why I don't think you should use it to accept payments. Sending payments to a hostname is not reliable for the reasons I said above, and the biggest problem is that there is no way to even know that the payment went to the wrong place, for the sender. There is a better (reliable) alternative using one time bitcoin addresses.
What I was getting at is that there is no authentication and no way to know if the payment got there with internet address based transactions. I think the internet address based payments are only for testing locally. The option is there but I don't think it's suitable for using on the internet or any multi-user network.
If there was any real amount of internet address based transactions and tor users I would set up an exit node just to intercept any tor based payments.. I still may do it just to see if I can get any because it's just another way to make a few more bitcoins per day.
I guess what I'm trying to say that it is the equivalent of leaving a pile of cash in your driveway with a rock on top of it to keep it from blowing away in the wind. Anyone can just go pick it up and so if you're a service provider you would not want to encourage your customers to pay you in that way, because it would just cause problems when the customer says they paid and the service provider says they didn't receive it. The only reason it's even possible to use on the internet right now is because unlike cash which has perceived value to a lot of people, bitcoins are like a pile of rocks to random internet users, they just walk by. If there are all these piles of bitcoins in everybody's driveway and people start figuring out that they're valuable, you can bet they'll start disappearing, so it's best not to put them there in the first place.
Laszlo
",
"nested_level": 0
},
{
"id": 670,
"satoshi_id": 114,
"thread_id": 60,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1322#msg1322",
"date": "2010-06-02T18:18:15Z",
"text": "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 address plus IP, like:
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com
I need suggestions for the separator character. \":\" is a candidate, but IPv6 has : in it and that might get confusing. Something that's allowed in url parameters would be nice.
I want to use SSL for the connection, using the bitcoin address' public key as the cert. You would be certain you're connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection.
Since it's authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.
",
"nested_level": 0
},
{
"id": 671,
"thread_id": 60,
"source_id": "7",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1330#msg1330",
"date": "2010-06-03T02:56:19Z",
"text": "How about $ ? It's distinctive, allowed in URLs, and related to money. You could also surround the authentication address in parentheses to emphasize that coins should not be sent to that address directly.
I really like that authentication method.
",
"nested_level": 0
},
{
"id": 672,
"thread_id": 60,
"source_id": "8",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1332#msg1332",
"date": "2010-06-03T14:29:56Z",
"text": "Seems like $ would be inviting confusion, since it's followed by numbers that can look kind-of like a dollar amount:
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3$64.20.45.38
means send $64.20 to my bitcoin address ?
Hyphen or underscore would be less confusing, but I think period would work really nicely:
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.64.20.45.38
19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com
The advantage of that last one is it is a valid URL; if a user pasted that into Firefox's URL bar or searched for it in Google the website owner could display a helpful web page explaining how to pay.
",
"nested_level": 0
},
{
"id": 673,
"thread_id": 60,
"source_id": "9",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1333#msg1333",
"date": "2010-06-03T17:19:23Z",
"text": "Maybe you just use a regular old URL or URN.. Kind of like namespaces in XML.
URN:
urn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78
URL (not for using with a web browser, but it's unique):
http://bitcoin.org/12.34.56.78/19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU319vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com
That's ambiguous. How do we know whether to send coins securely to skypaint.com or insecurely to the IP address that the entire thing resolves to?
Having an informational page at the subdomain would be pretty awesome, though. Maybe it's worth implementing around the ambiguity.
The idea of send by DCC is to simplify.
It's not like put 1000 USD over a rock, the attacks are \"theoretically easy\" but on practical not, unless your ISP attacks you... but if it does so, why not attack your bank account instead? Except maybe for cable access where your neighbor can sniff you.
This bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78 is about as practical as nothing. What would be the simplification-add of such? Try to say to someone over the phone your BC address on such manner.
Let's do one thing, right: PUT TOR ASIDE. One thing is using BC for anonymous payments / OTHER is to make non-anonymous payments.
If you're up to do anonymous payments, that's already sorted: Use BC address and that's it.
It's then a matter of choices, if for security reasons you feel more confortable with it disabled, do it like: Disabled by default / Enable if you want and know what you're doing.
Someone could hijack my site and show another BC address
-Someone could hijack your site and show another PayPal email also. Defacings aren't however easy to do, you don't see sites defaced everyday.
Someone could hijack DNS to resolve to something else
-Someone could hijack your bank's login and make you pass over your password to it... again DNS hijack/spoof isn't also that easy to do. Theoretically (again) it is, but that would be if you were using some bogus Nameserver. If you use your ISP defaults it would be rather complicated. And if someone invaded your PC to make it change DNS's, then that same one would open your BC Client and send all your BC's to his address.
So, in the end, my proposal is:
Split the \"project idea\" in two different (way different) branches:
1 - Anonymous payments - Using BC Address exclusivelly
2 - Non-anonymous (regular) payments - Using BC Addresses OR DCC.
It makes no sense at all to use Tor arguments over branch 2.
",
"nested_level": 0
},
{
"id": 676,
"thread_id": 60,
"source_id": "12",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1343#msg1343",
"date": "2010-06-04T02:45:21Z",
"text": "Bank sites and such use end to end encryption which makes intercepting more difficult and there is usually two way authentication. The website authenticates itself to you by showing you your personally selected image/phrase, thus you recognize that this is the site you wanted to visit, and then you authenticate to the website so they recognize you as the customer you claim to be. It's not perfect but it's like putting a pad lock on a box full of money to keep honest people honest. Sometimes they use a bigger/thicker pad lock so the effort/gain ratio makes it not really worth trying to break it.
I agree with you in a way about security, if it's too inconvenient then it's not very useful... though encryption and authentication are generally good enough to deter trivial things and they provide some reassurance.
It is certainly convenient to be able to send to a paypal email address, but even there you get two way authentication. PayPal will display the name of the person you're sending to, before you commit to how much you're sending. PayPal is very popular and is riddled with fraud.. if Bitcoin was accepted on Ebay and the IP address based sending was used as it is today, it would never get there because people would just intercept it along the way, TOR or not.
If you've used ssh you know that uses two way authentication as well - you verify the server's key visually before you present your own authentication credentials. This technique is problematic in a way because if it's the first time you're connecting you don't know what it should be.. you have to call up the person operating the server and ask them to read you the key. I think the idea of putting it into the URL or other address notation is that you declare what you expect it to be and the local client will tell you if the peer presents something different. I suppose you could go the ssh route, just let someone accept whatever is presented.. though right now the key is dynamically generated, it could be changed so that it would present some key that changes once a day or something.. then you could show it on the web site that's expecting the payment, but then why wouldn't you just show the bitcoin address itself and send that way.
I guess I don't really understand your point with simplification.. if you have to copy/paste an address already, what does it matter if it's an internet address, a DNS address or a bitcoin address?
",
"nested_level": 0
},
{
"id": 677,
"thread_id": 60,
"source_id": "13",
"poster_name": "SirArthur",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=217",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1345#msg1345",
"date": "2010-06-04T03:26:58Z",
"text": "Put things this way; if you manage (on a more or less distant future, don't know) to run sort of a shop on surface web* with BC, you may want:
\u00bb Your customers to be identifiable - to know who is paying what and handle refunds
\u00bb Your customers to leave notes along with the payment.
\u00bb Your customers to have a friendly address to pay to (not an IP, not an unreadable hash) - unless you run thenerdsshop.com there is.
\u00bb Your customers to not be nagged.
For this would be obviously interesting a TLS/SSL feature. Imagine this operation:
Client -> send BC 50 to bcpay.mysite.com
bcpay.mysite.com -> send a certificate with the store's data, client's get a popup with this server's information to confirm
eg:
You're about to make a payment to the following Bitcoin client:
SITE NAME: mystore.com
COMMON NAME: Payments Gateway
CA VERIFIED BY: BitcoinSSL
Client -> Confirm ? payment is sent: payment is cancelled.
* Tor users: Let's call it a surface web shop shipping goods to your house, so you wouldn't go there anyway. What would be the point of hide your IP while give your home address?
",
"nested_level": 0
},
{
"id": 678,
"thread_id": 60,
"source_id": "14",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Hostnames instead of IP Addresses",
"url": "https://bitcointalk.org/index.php?topic=158.msg1482#msg1482",
"date": "2010-06-11T14:33:55Z",
"text": "I don't see why these two ideas are mutually exclusive, although I'd assume implementing SSL/TLS is not trivial. We do already link to the OpenSSL library, so I don't know.
I personally would prefer a urn scheme to handle a bitcoin address.
urn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78
That would be perfect, although I would prefer to use the hostname on the right side.
Of course, I'm the kind of guy who might shop at thenerdsshop.com
For grandma, the entire bitcoin concept is pretty confusing at the moment. Even neglecting all the technical details, the UI still shows a huge string of numbers and letters (your receiving address) and best practices currently require you to deal with that every time you give someone your address.
Another option is to use something like what OpenID uses: hidden tags on the store's (hopefully SSL) site. Then you could just enter a site's URL as the receiving address. It would hit that site, search for something like
<link rel=\"bitcoin.address\" href=\"19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3\">
<link rel=\"bitcoin.server\" href=\"12.34.56.78\">
Or some other form and try to send securely to that.
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 of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.
The user would send to domain.com (or
www.domain.com is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay.
The SSL also makes it safe for TOR users.
Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.
Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren't used to the idea of having to identify the payment. Merchants would get too many blank payments followed by \"I paid you, where's my stuff?!\" a week later.
The payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn't contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though.
I can't build r80 from the SVN with -O2 in the makefile. I'm running Ubuntu 10.04 LTS 64-bit on an Intel Core 2. If I remove -O2 (switch back to -O0), it builds fine.
The problem seems to be line 15 of net.h. My googling suggests that statement-expressions, some non-standard, GCC-only extension to C++, are not allowed outside of functions at that level of optimization. htons is implemented as a statement-expression for linux. I managed to get it to build by replacing the htos(8333) with 0x8D20, which is 8333 in network byte order. This compiles and runs fine on my Intel processor, but probably wouldn't work on a big endian processor like a PowerPC.
Is anybody else experiencing this bug?
Also, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3.
",
"nested_level": 0
},
{
"id": 681,
"thread_id": 61,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Can't Build r80 from SVN",
"url": "https://bitcointalk.org/index.php?topic=163.msg1360#msg1360",
"date": "2010-06-05T03:12:48Z",
"text": "You did the right thing.. none of it works on big endian anyway.
",
"nested_level": 0
},
{
"id": 682,
"thread_id": 61,
"source_id": "3",
"poster_name": "D\u0489ataWraith",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=155",
"subject": "Re: Can't Build r80 from SVN",
"url": "https://bitcointalk.org/index.php?topic=163.msg1374#msg1374",
"date": "2010-06-05T16:36:11Z",
"text": "Is anybody else experiencing this bug?
Also, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3.
Yeah, I had the same problem.
BtW: If you look at the makefile, sha.{h,cpp} are already compiled -O3; using a higher optimization level for the remainder of the program is probably not going to help much.
-O2 is generally the preferred optimization for gcc, -O3 can produce larger code which is slower, but you should experiment around with it.. it also seems to depend on the time of day or the phases of the moon for me at least, some days I'm getting a lot more hashes per second.
",
"nested_level": 0
},
{
"id": 684,
"thread_id": 61,
"source_id": "5",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Can't Build r80 from SVN",
"url": "https://bitcointalk.org/index.php?topic=163.msg1378#msg1378",
"date": "2010-06-05T19:05:24Z",
"text": "Please note that revision 77 is buildable (by default) and 78 isn't I believe.
And can you next time wait for your answer in IRC?
I mean, you asked your question twice, we're just not in the room 24/7!
I'm not in the room 24/7 either. I decided to go off IRC and to the forums so I wouldn't need to wait around all day.
I need to learn some more C++. There are a lot of things that would improve bitcoin like encrypted wallet files, built-in performance monitoring, RPC extension, etc. Is there any system for submitting patches for inclusion in the SVN and/or default builds?
I don't mean to come accross as confrontational. I love Bitcoin and just want to help improve it.
",
"nested_level": 0
},
{
"id": 686,
"thread_id": 61,
"source_id": "7",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Can't Build r80 from SVN",
"url": "https://bitcointalk.org/index.php?topic=163.msg1387#msg1387",
"date": "2010-06-06T18:55:31Z",
"text": "Some notes on how to build the linux client. I used a 64 bit system but the process is almost identical for i386 linux.
http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdfSome notes on how to build the linux client. I used a 64 bit system but the process is almost identical for i386 linux.
That's my process as well, although I apply a variety of patches to things before hand. And I have boost and I think libdb from Ubuntu's repos.
Sorry, I didn't test compile on linux the last few revisions.
Reverted makefile.unix.
",
"nested_level": 0
},
{
"id": 689,
"thread_id": 62,
"source_id": "1",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1373#msg1373",
"date": "2010-06-05T16:26:09Z",
"text": "Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?
",
"nested_level": 0
},
{
"id": 690,
"thread_id": 62,
"source_id": "2",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1376#msg1376",
"date": "2010-06-05T18:59:19Z",
"text": "I don't know if there are any technological safeguards to prevent this, but there is a social one: if you drop transactions, others might drop yours.
",
"nested_level": 0
},
{
"id": 691,
"thread_id": 62,
"source_id": "3",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1379#msg1379",
"date": "2010-06-05T19:22:38Z",
"text": "Bitcoin supports transaction fees paid to the node that records a transaction into the block chain. If too many nodes start dropping transactions, you can pay a fee when you want to increase the likeliness of your transaction being recorded in the next block.
",
"nested_level": 0
},
{
"id": 692,
"thread_id": 62,
"source_id": "4",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1381#msg1381",
"date": "2010-06-05T19:42:17Z",
"text": "So would it be smarter to only process transactions which profit you? That way if you want to send money you need to include a courier fee or nobody will confirm it. That seems reasonable to me, where you can add a fee yourself to each transaction, and people can configure a threshold of how much of a fee they expect before accepting a transaction.
",
"nested_level": 0
},
{
"id": 693,
"thread_id": 62,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1382#msg1382",
"date": "2010-06-05T19:55:40Z",
"text": "That's a clever (and very free-market) solution. How does BitCoin currently deal with transactions that aren't published in a block for a long time? Is there any risk of them being lost?
",
"nested_level": 0
},
{
"id": 694,
"thread_id": 62,
"source_id": "6",
"poster_name": "QuantumMechanic",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=241",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1383#msg1383",
"date": "2010-06-05T20:02:09Z",
"text": "Are there any estimates on the average transaction fee once users' incentive to support the network via bitcoin generation is mostly dried up? How does this scale with the number of users, the size of network, and the total transaction rate?
",
"nested_level": 0
},
{
"id": 695,
"satoshi_id": 122,
"thread_id": 62,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: What is the incentive to collect transactions?",
"url": "https://bitcointalk.org/index.php?topic=165.msg1595#msg1595",
"date": "2010-06-15T23:41:29Z",
"text": "Adding transactions to the block you're working on will slow down your generation rate
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 hash of the transactions (the Merkle root) and is only updated occasionally.
If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.
Hi all,
I'm currently trying to get the openSuse Build Service to build bitcoin binaries for all the major distros, but wxWidgets is giving me a headache, as the development branch 2.9.0 is in not a single repository, and I'm having huge problems building it myself.
So I was wondering whether it is possible at all to compile everything without any depencies on wxWidgets?
Once wxWidgets 2.9.0 starts appearing in the default repos I'll create packages for the GUI version too, but a CLI version is better than nothing for the moment.
Regards,
Chris
P.S.: If you're interested at peeking, please take a look here:
https://build.opensuse.org/project/show?project=home%3Acdecker%3Abitcoinhttp://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdfIf you follow these instructions and build 'bitcoind' it's all linked statically to wxWidgets, boost, openssl and libdb.. for me it looks like this:
$ ldd bitcoind
linux-vdso.so.1 => (0x00007fff31dff000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ff1a0a78000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1a0768000)
libm.so.6 => /lib/libm.so.6 (0x00007ff1a04e4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ff1a02cd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff1a00b1000)
libc.so.6 => /lib/libc.so.6 (0x00007ff19fd41000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1a0c7c000)
",
"nested_level": 0
},
{
"id": 698,
"thread_id": 63,
"source_id": "3",
"poster_name": "jago25_98",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=277",
"subject": "Re: Building BitCoin Client completely Headless",
"url": "https://bitcointalk.org/index.php?topic=171.msg1810#msg1810",
"date": "2010-06-26T20:11:15Z",
"text": "I need headless cli to run on my server (don't own my own computer, just a root shell & a borrowed laptop from work).
How to compile? I recommend including a cli binary. FAQ?
Good work by the way, thanks
update: checked out thr trunk by svn, tried a make after installing g++, no joy:
usr/include/c++/4.3/bits/stl_vector.h:150: instantiated from \u00e2void std::_Vector_base<_Tp, _Alloc>::_M_deallocate(_Tp*, size_t) [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]\u00e2
/usr/include/c++/4.3/bits/stl_vector.h:136: instantiated from \u00e2std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]\u00e2
/usr/include/c++/4.3/bits/stl_vector.h:235: instantiated from \u00e2std::vector<_Tp, _Alloc>::vector(size_t, const _Tp&, const _Alloc&) [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]\u00e2
key.h:105: instantiated from here
serialize.h:684: error: \u00e2memset\u00e2 was not declared in this scope
make: *** [headers.h.gch] Error 1
...amongst other errors (don't know what I'm doing with multiplatform...
Jago, do you have all the proper dependencies installed?
",
"nested_level": 0
},
{
"id": 700,
"satoshi_id": 155,
"thread_id": 63,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Building BitCoin Client completely Headless",
"url": "https://bitcointalk.org/index.php?topic=171.msg1815#msg1815",
"date": "2010-06-26T21:06:06Z",
"text": "The linux release candidate in the \"1.3 almost ready\" thread contains prebuilt bitcoind.
",
"nested_level": 0
},
{
"id": 701,
"thread_id": 64,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1441#msg1441",
"date": "2010-06-10T02:12:24Z",
"text": "Will it be possible to get bitcoin working on a mobile phone?As the computing power of mobiles increases at what point will it be practicable?It would be nice to carry a portable version of my bitcoin wallet around with me.Is there an app for that?
I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing.
",
"nested_level": 0
},
{
"id": 703,
"thread_id": 64,
"source_id": "3",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1450#msg1450",
"date": "2010-06-10T12:06:20Z",
"text": "I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing.
QR codes have been proposed as a solution
here.
I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing.
QR codes have been proposed as a solution
here.
nice!
You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them. But maybe a mobile wallet would be better in a sense.
",
"nested_level": 0
},
{
"id": 706,
"thread_id": 64,
"source_id": "6",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1453#msg1453",
"date": "2010-06-10T14:21:17Z",
"text": "Another option is an mobile-optimized, https-secured web interface on your local computer. That's already possible with something like LigHTTPd and PHP or Python and JSON-RPC. Not quite as good as running Bitcoin on your phone, but better than vekja.net for trustworthiness.
",
"nested_level": 0
},
{
"id": 707,
"thread_id": 64,
"source_id": "7",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1507#msg1507",
"date": "2010-06-12T00:19:26Z",
"text": "Could you build an iphone app that uses bitcoin?
",
"nested_level": 0
},
{
"id": 708,
"thread_id": 64,
"source_id": "8",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1508#msg1508",
"date": "2010-06-12T00:19:48Z",
"text": "Sure, but Apple would likely not accept it.
",
"nested_level": 0
},
{
"id": 709,
"thread_id": 64,
"source_id": "9",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1509#msg1509",
"date": "2010-06-12T01:01:42Z",
"text": "What do you imagine the iPhone app doing? Just looking for some ideas on how it should look and what it should do..
",
"nested_level": 0
},
{
"id": 710,
"thread_id": 64,
"source_id": "10",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1510#msg1510",
"date": "2010-06-12T01:22:15Z",
"text": "What do you imagine the iPhone app doing? Just looking for some ideas on how it should look and what it should do..
It could be useful for many things because your phone is usually carried everywhere unlike a desktop/laptop.
I imagine it would be able to carry your wallet db
Phone banking of some description.
A list of bitcoin sites you could browse.
A push notification for bitcoins received/sent.
Exchange on the go.
If you had an untraceable el cheapo burner phone you might need to purchase
prepaid phone cards using bitcoin- for the paranoid lol
I guess the list would grow as the marketplace expanded and more merchants came on board.
I think this idea deserves more recognition.
A phone is much more accessible and widely available than a computer. There are many, many people for whom they only got a phone.
Even some kind of SMS / gateway / key exchange would be something... being able to send a payment by sms to a gateway server with an unsupported phone to a supported phone, for example, or to a trusted third party who can handle the transaction for us.
By rolling passcode perhaps.
That would fantastic, and possibly not too much of a major overhaul needed?
Inspired?
",
"nested_level": 0
},
{
"id": 712,
"satoshi_id": 154,
"thread_id": 64,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin mobile.",
"url": "https://bitcointalk.org/index.php?topic=177.msg1814#msg1814",
"date": "2010-06-26T20:58:26Z",
"text": "You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them.
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 an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.
If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website.
A web interface to your own Bitcoin server at home wouldn't be a solution for everyone. Most users don't have a static IP, and it's too much trouble to set up port forwarding.
Hi people. I'm interested in decentralized currency and going to either participate in development of this one or develop my own version. Before making a decision i want to clarify few technical aspects, which is not clear from documentation. Partially this is just because english is not my native language, but anyway
.
0) Is it necessary to run a node if i want to have a wallet? Is it necessarily attached to some exact node or i can keep my wallet on flash drive for example and use it with any node? Where and in which form my account balance is stored?
1) Do i need to download whole network transactions log to be able to validate received coins?
2) How user protected from potential situation when some node is hacked(or modified) and using his id (public key) to send money from his account? It looks possible when everything is sychronyzed between everybody.
3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)
4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.
5) Is there any any plans on decentralizing node list (i have figured out from irc that bitcoin is currently not really decentralized, because nodes getting in touch by joining irc channel on freenode).
6) Do i correctly understand that after some point in time nobody will have ability to generate new coins? we'll just use fixed amount of existing ones.
Thanks for you answers.
Hello Nixoid. I'll answer what I can. Everyone else, feel free to jump in and help, or to correct me if I have something wrong!
0) Yes and no. When people speak of a node here, they usually mean a generating node. You can have a wallet without generating coins, but you must have the software installed and running to make and receive transactions. You can, however, move your wallet between computers / accounts as long as you only keep one version of it. Otherwise, Bitcoin might try to spend the same coins twice. Your use case (on a flash drive) would be fine.
1) You do need the whole transaction log to validate transactions. At the moment it comes to something like 25MB.
2) I'm not sure about this one.
3) This one either, sorry.
4) At the moment, there is no transaction fee (I think). There is just support for one in the source code. At some point in the future, the transaction fee will be used to replace \"mining\" bitcoins as an incentive to run a node. Also, a transaction fee might be used to insure that other nodes accept your blocks.
5) I'm not sure what sirius's plans are, but I would like to decentralize this very much. I think IRC is one of Bitcoin's Achilles heels at the moment.
6) The rate of generation asymptotically approaches zero. About every 4 years, the number of coins created by each new block is halved. In roughly 10-11 years, each new block will generate 6.25 coins for the miner (instead of 50 today). At some point, transaction fees will be implemented to replace generation as the incentive to supply your bandwidth acting as a node. The idea is that the fee will be < 0.5%.
",
"nested_level": 0
},
{
"id": 715,
"thread_id": 65,
"source_id": "3",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Technical clarifications",
"url": "https://bitcointalk.org/index.php?topic=179.msg1472#msg1472",
"date": "2010-06-11T01:34:11Z",
"text": "I'll try to answer what I can:
0) Is it necessary to run a node if i want to have a wallet? Is it necessarily attached to some exact node or i can keep my wallet on flash drive for example and use it with any node? Where and in which form my account balance is stored?
You either have to run a node or trust somebody else (like MyBitcoin.com) to keep a wallet for you.
Your account balance is stored in a Berkeley DB file called 'wallet.dat' (what directory depends on your operating system; on my Mac it is ~/Library/Application Support/Bitcoin/wallet.dat, on linux it is ~/.bitcoin/wallet.dat, not sure about PCs).
The only application that can read wallet.dat is the bitcoin code, and the database structure isn't documented anywhere besides the bitcoin C++ source code.
1) Do i need to download whole network transactions log to be able to validate received coins?
Theoretically, no, but the code to do lightweight validation hasn't been written.
2) How user protected from potential situation when some node is hacked(or modified) and using his id (public key) to send money from his account? It looks possible when everything is sychronyzed between everybody.
Satoshi is planning on encrypting the wallet database, so you'd need to enter a password to read it. (and they need to get your private keys to generate transactions-- those are what are stored in the wallet.dat)
3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)
4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.
Dunno.
5) Is there any any plans on decentralizing node list (i have figured out from irc that bitcoin is currently not really decentralized, because nodes getting in touch by joining irc channel on freenode).
There's another thread about this in these forums; maybe we should start a \"Satoshi's TODO list\" thread and get folks to volunteer to help out.
6) Do i correctly understand that after some point in time nobody will have ability to generate new coins? we'll just use fixed amount of existing ones.
Fewer and fewer coins will be created over the next N years (where N is-- what, 20?). That's a feature, not a bug...
RE: developing your own version: are you thinking of creating a second bitcoin implementation that is compatible with the existing C++ one (good idea, in my opinion)? Or creating a similar-but-not-the-same system (bad idea, in my opinion)?
4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.
I second that one. My fear is that the transaction fee won't scale nicely. Hopefully this is unfounded.
4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.
Transaction fee is needed to give an incentive to generate blocks after many years from now, when the block value has grown low. Also, if many nodes stop recording transactions into the blocks they generate (because of the small generation speed benefit gained), you can apply transaction fee as an incentive.
There will probably always be nodes that include your transactions into their blocks for free, but you might have to wait for a few blocks if many nodes don't.
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.
",
"nested_level": 0
},
{
"id": 719,
"thread_id": 66,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1488#msg1488",
"date": "2010-06-11T17:38:45Z",
"text": "For my first Bitcoin coding project, I decided to do something that sounds really dumb: I created a web site that gives away Bitcoins. It is at:
https://freebitcoins.appspot.com/ Five \u0e3f per customer, first come first served, I've stocked it with \u0e3f1,100 to start. I'll add more once I'm sure it is working properly.
Why? Because I want the Bitcoin project to succeed, and I think it is more likely to be a success if people can get a handful of coins to try it out. It can be frustrating to wait until your node generates some coins (and that will get more frustrating in the future), and buying Bitcoins is still a little bit clunky.
Please try it out and get some free coins, even if you already have more Bitcoins than you know what to do with. You can get some and then donate them right back; the address is:
15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsCAwesome!
",
"nested_level": 0
},
{
"id": 721,
"thread_id": 66,
"source_id": "3",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1490#msg1490",
"date": "2010-06-11T18:11:37Z",
"text": "I really like that. Do you think it would be good to post when the number of bitcoins left is below 200-300? That way people like me could donate to it to help keep this going.
",
"nested_level": 0
},
{
"id": 722,
"thread_id": 66,
"source_id": "4",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1495#msg1495",
"date": "2010-06-11T18:29:39Z",
"text": "Couldn't someone just keep making new bitcoin addresses and drain your system?
You should at least toss recaptcha on there.
It only gives 5 coins / IP / day. I dunno if it also checks addresses.
But it's true, a good captcha wouldn't be a bad idea.
Yeah, using only the IP is somewhat unsecure, but it's better than nothing.
I wonder if it's possible to generate coins on app engine...
",
"nested_level": 0
},
{
"id": 724,
"thread_id": 66,
"source_id": "6",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1500#msg1500",
"date": "2010-06-11T19:27:15Z",
"text": "Showing the number of Bitcoins available is on my TODO list. I just checked and the balance is up to 1,135 (thanks to whoever donated!).
And right now it is 5 bitcoins per IP address (not bitcoin address). Not per-day-- just 5. I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.
RE: captchas: yeah, I was gonna start out with a captcha, but I wanted it to be as simple and non-threatening as possible. I don't think anybody who has access to hundreds or thousands of working public IP addresses would go to the effort of writing a bitcoin-harvesting robot, though I suppose somebody with a botnet might take a crack at it. To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address).
",
"nested_level": 0
},
{
"id": 725,
"thread_id": 66,
"source_id": "7",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1501#msg1501",
"date": "2010-06-11T19:32:43Z",
"text": "Showing the number of Bitcoins available is on my TODO list. I just checked and the balance is up to 1,135 (thanks to whoever donated!).
I got 5 then felt bad so sent you 50 back
And right now it is 5 bitcoins per IP address (not bitcoin address). Not per-day-- just 5. I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.
My mistake. I don't see that being a big problem. Perhaps have it reset every week? I doubt you'll be hard-pressed for coins, at least for now.
To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address).
That actually wouldn't help much. It's completely trivial to generate a new address per transaction (with JSON-RPC). If I were coding a botnet, that's how I'd do it. Adding a CAPTCHA might be wise if you notice problems, but for now I doubt you have much to lose by skipping it.
Just out of curiosity, how did you build that on the App Engine? Could I possibly see your source? I might set something similar up on my local server. As I understood it, you can't make any sort of outbound request from app engine, though. So how do you send the coins?
Will you share the source code of your service?
Will you share the source code of your service?
I'd be happy to share the interesting bits, but the architecture is... um, unique. I'll start a thread on the Development forum describing how I built it.
gavinandersen
I've been able to drawn 50 BTC in minutes using Tor. Please add some address filter too, so the same address can't be used twice. I'll also provide a Tor blacklist if you'd like.
PS: I've paid back those BTCs.
It's out job to disarm thieves so this currency won't be subjected to the same atrocities as in real world.
This currency shall not be used for one to be rich and in control and others poor and under control.
",
"nested_level": 0
},
{
"id": 729,
"thread_id": 66,
"source_id": "11",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1535#msg1535",
"date": "2010-06-13T09:07:47Z",
"text": "He's giving it away, it's an honor system, so don't take more than you need
Of course. I didn't. But that doesn't mean others won't too.
",
"nested_level": 0
},
{
"id": 731,
"thread_id": 66,
"source_id": "13",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1541#msg1541",
"date": "2010-06-13T15:05:50Z",
"text": "I've been able to drawn 50 BTC in minutes using Tor. Please add some address filter too, so the same address can't be used twice. I'll also provide a Tor blacklist if you'd like.
PS: I've paid back those BTCs.
How many public Tor exit nodes are there these days? You've essentially blacklisted 10 of them already
I am going to add a one-donation-per-bitcoin address rule to make it a teeny-tiny bit harder to cheat. I don't want to blacklist anybody coming from Tor, though-- I think a lot of people using Tor will also be interested in Bitcoin.
I'll implement a CAPTCHA when (if?) the current service starts running low on coins (there are 1,570 bitcoins in the faucet right now!).
Gavinandersen
About 1500-1700 exit nodes on Tor. Yea, people using Bitcoin might use Tor, but not for your service. My suggestion is to ban open proxies.
",
"nested_level": 0
},
{
"id": 733,
"thread_id": 66,
"source_id": "15",
"poster_name": "wobber",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=251",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1547#msg1547",
"date": "2010-06-13T16:25:54Z",
"text": "Gavinandersen, you gave me 13.37 (leet) BTC?
",
"nested_level": 0
},
{
"id": 734,
"thread_id": 66,
"source_id": "16",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1554#msg1554",
"date": "2010-06-13T21:45:07Z",
"text": "Gavin, you should set DEBUG = False in your Django settings next time. I hit some kind of exception page and it gave me your secret and the URI of your JSON gateway.
I'll send your bitcoins back to you if you'd like.
I'm emailing you.
Thanks, lachesis-- \u0e3f50 to you for finding that bug!
I've changed the key and turned off debugging; I'll tighten up its security a little more tomorrow when I'm more awake.
And wobber: no, I didn't send you leet \u0e3f
",
"nested_level": 0
},
{
"id": 736,
"thread_id": 66,
"source_id": "18",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1558#msg1558",
"date": "2010-06-14T01:45:38Z",
"text": "Thanks Gavin. Glad to help.
",
"nested_level": 0
},
{
"id": 737,
"thread_id": 66,
"source_id": "19",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1577#msg1577",
"date": "2010-06-14T17:48:44Z",
"text": "The Bitcoin Faucet now shows how many coins it has available to give out (on the left-hand side of the page). The number is only moderately accurate-- donations will take 5 or 10 minutes to show up in the balance.
I also implemented another anti-cheating measure that should make casual cheating a little harder (which I don't want to say too much about because that would make it easy for cheaters to know what to do).
I'm very pleasantly surprised at how well freebitcoins is working so far; thanks again to everybody who tried it out and who donated bitcoins to it!
",
"nested_level": 0
},
{
"id": 738,
"satoshi_id": 129,
"thread_id": 66,
"source_id": "20",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Get 5 free bitcoins from freebitcoins.appspot.com",
"url": "https://bitcointalk.org/index.php?topic=183.msg1620#msg1620",
"date": "2010-06-18T23:08:34Z",
"text": "Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.
You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.
",
"nested_level": 0
},
{
"id": 739,
"thread_id": 67,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "sfg",
"url": "https://bitcointalk.org/index.php?topic=184.msg1492#msg1492",
"date": "2010-06-11T18:19:41Z",
"text": "dsag
",
"nested_level": 0
},
{
"id": 740,
"thread_id": 67,
"source_id": "2",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1493#msg1493",
"date": "2010-06-11T18:24:26Z",
"text": "That's true. It is getting to be time for a new release. Maybe Laszlo's performance patch will make it into the svn too?
",
"nested_level": 0
},
{
"id": 741,
"thread_id": 67,
"source_id": "3",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1515#msg1515",
"date": "2010-06-12T07:10:08Z",
"text": "Please note that I'm not the Bitcoin author - if you don't trust me then don't use these. I have written instructions that should get you started if you want to build your own (look around at my other posts).
Some unofficial builds that I created:
Mac OS X, Linux (64 bit) and Win32 builds available
http://heliacal.net/~solar/bitcoin/builds/This includes a tiny patch I added to show how many hashes per second are being processed. A picture of the hash counter is attached.
If you want the patch so you can build it yourself it is available here:
http://heliacal.net/~solar/bitcoin/bitcoin-svn-81-perfcounter-2010-06-12.patch![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fheliacal.net%2F%7Esolar%2Fbitcoin%2Fbc-svn-81-win32.png&t=589&c=Y2yljwtImM_AAg\"/)
Thank you very much!
I'm trying to generate coin with your windows build, and it seems that it doesn't work at all.
It was working with the official exe.
Is there a bug somewhere on official code?
",
"nested_level": 0
},
{
"id": 744,
"thread_id": 67,
"source_id": "6",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1603#msg1603",
"date": "2010-06-16T23:52:34Z",
"text": "Joozero, what is the problem with it? I use that binary myself and it works for me.
",
"nested_level": 0
},
{
"id": 745,
"thread_id": 67,
"source_id": "7",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1604#msg1604",
"date": "2010-06-17T00:59:47Z",
"text": "I doesn't generate coins anymore.
Anyway it could be a problem with windows 7 x64, even if the latest one was working.
I know that there is a lot of math and we have to be luck, it is just strange
I'll wait some more ...
Joozero I'm sorry if it doesn't work for you.. I noticed that the performance with the windows client seems slower than the other two I built.. I'm not sure if this is because of a mistake I made or something I overlooked in the code but I will take another look and let you know if I find anything. Maybe there is something else wrong with it besides just the performance..
",
"nested_level": 0
},
{
"id": 747,
"thread_id": 67,
"source_id": "9",
"poster_name": "ender_x",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=139",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1607#msg1607",
"date": "2010-06-17T14:47:47Z",
"text": "Thanks laszlo..
Also any chance of a 32-bit build?
",
"nested_level": 0
},
{
"id": 748,
"thread_id": 67,
"source_id": "10",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1608#msg1608",
"date": "2010-06-17T16:03:16Z",
"text": "32 bit linux? Yea I can do that.
",
"nested_level": 0
},
{
"id": 749,
"satoshi_id": 125,
"thread_id": 67,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: new binary release?",
"url": "https://bitcointalk.org/index.php?topic=184.msg1609#msg1609",
"date": "2010-06-17T17:07:56Z",
"text": "I'm working on getting version 0.3 released as soon as I can. Just a last few things left to do. It's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available. This time we'll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release. Plus, we'll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!).
",
"nested_level": 0
},
{
"id": 750,
"thread_id": 68,
"source_id": "1",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Dealing with SHA-256 Collisions",
"url": "https://bitcointalk.org/index.php?topic=191.msg1555#msg1555",
"date": "2010-06-14T01:01:11Z",
"text": "A mathematician friend of mine pointed out that there are very few if any hash protocols that have survived for 10 years or more. What would Bitcoin's solution be if SHA256 were to be cracked tomorrow?
",
"nested_level": 0
},
{
"id": 751,
"thread_id": 68,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Dealing with SHA-256 Collisions",
"url": "https://bitcointalk.org/index.php?topic=191.msg1559#msg1559",
"date": "2010-06-14T02:34:57Z",
"text": "I don't think that broken cryptography could ever be the end of BitCoin if it becomes popular. Since the block chain can be forked without losing too much data, modifications to all aspects of BitCoin are possible. If SHA-256 was broken, a new version of BitCoin would be released that would switch to a stronger hash function for addresses. Changing the hash function used for blocks might not be necessary if the weakness still required some non-trivial amount of computation. The new version would ignore SHA-256 blocks after a certain point in time, but most old transactions would survive.
In case the weakening of SHA-256 is gradual instead of sudden (much more likely, IMO), BitCoin could stretch the process of switching to a different hash algorithm over a long time. First accept SHA-512 (or whatever) in addition to SHA-256, then use SHA-512 by default, and finally stop accepting SHA-256 for new blocks.
",
"nested_level": 0
},
{
"id": 752,
"thread_id": 68,
"source_id": "3",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Dealing with SHA-256 Collisions",
"url": "https://bitcointalk.org/index.php?topic=191.msg1566#msg1566",
"date": "2010-06-14T04:30:41Z",
"text": "In case the weakening of SHA-256 is gradual instead of sudden (much more likely, IMO), BitCoin could stretch the process of switching to a different hash algorithm over a long time. First accept SHA-512 (or whatever) in addition to SHA-256, then use SHA-512 by default, and finally stop accepting SHA-256 for new blocks.
Wouldn't the users lose their coins?
So it's possible to switch \"on the fly\" to a new hash function? Wouldn't all the old transactions then be compromised (because they could be trivially recomputed)?
SHA-256 has already been weakened by a factor of 16 (according to my friend. I can't find documentation on that, but I trust him). That's 16 out of 2^256, so not a huge deal, but still.
",
"nested_level": 0
},
{
"id": 754,
"thread_id": 68,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Dealing with SHA-256 Collisions",
"url": "https://bitcointalk.org/index.php?topic=191.msg1568#msg1568",
"date": "2010-06-14T06:09:58Z",
"text": "Wouldn't all the old transactions then be compromised (because they could be trivially recomputed)?
After thinking about this some more, I've realized that breaking the hash function used in blocks would be more disastrous than I had originally thought. But it should still be possible to change the hash function \"on-the-fly\" by including secure hashes of each real block in the old chain with the new BitCoin release. Some mechanism of doing this (hopefully more elegant) would also have to be used for a gradual hash change.
Wouldn't the users lose their coins?
Everyone's balance is publicly available, so it should always be possible to preserve this data, no matter what changes are made to BitCoin.
SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.
If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
",
"nested_level": 0
},
{
"id": 756,
"thread_id": 69,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG",
"url": "https://bitcointalk.org/index.php?topic=195.msg1606#msg1606",
"date": "2010-06-17T11:38:31Z",
"text": "So I'm writing a little tool that dissects the Bitcoin wallet.dat, mainly because I want to understand better exactly how Bitcoin works.
And I see that the outputs of transactions have a value (number of bitcoins) and a bunch of bytes that are run through the little Forth-like scripting language built in to bitcoin. E.g.:
['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90 EQUALVERIFY CHECKSIG']
First: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto). It makes me nervous because it is more complicated, and complication is the enemy of security. It also makes it harder to create a second, compatible implementation. But I think I can get over that.
Looking at the code, new transactions are verified by pushing the signature an then public key on the interpreter's stack and then running the TxOut script (did I get that right?).
Could I write code to create transactions with any valid script in the TxOut?
E.g. could I create a TxOut with a script of: OP_2DROP OP_TRUE
... to create a coin that could be spent by anybody?
And is flexibility in the types of coins created the reason it is coded this way?
",
"nested_level": 0
},
{
"id": 757,
"satoshi_id": 126,
"thread_id": 69,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG",
"url": "https://bitcointalk.org/index.php?topic=195.msg1611#msg1611",
"date": "2010-06-17T18:46:08Z",
"text": "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 problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
",
"nested_level": 0
},
{
"id": 758,
"thread_id": 69,
"source_id": "3",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG",
"url": "https://bitcointalk.org/index.php?topic=195.msg1612#msg1612",
"date": "2010-06-17T18:50:31Z",
"text": "How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network.
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.
I know, most developers don't like their software forked, but I have real technical reasons in this case.
I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
That's one of the reasons for transaction fees. There are other things we can do if necessary.
How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well
Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.
Fortunately, so far all the issues raised have been things I previously considered and planned for.
I only have a 1Ghz netbook running bitcoin at the moment, so I'm curious what kind of bitcoin generation rates the faster computers get. 100/week, 1000/week, 10000/week? How big of an advantage is there to having a faster computer?
",
"nested_level": 0
},
{
"id": 762,
"thread_id": 70,
"source_id": "2",
"poster_name": "molybdenum",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=208",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1626#msg1626",
"date": "2010-06-20T11:02:33Z",
"text": "I get, on average, 100 a day with my P4@3200, I'd expect there to be only a small MIPS/MHz drop between P4 and celeron, so I'd guess vaugely at 50 somewhere between every day, and every day and a half. That's just a wild guess though, and difficulty only seems to be going up...
",
"nested_level": 0
},
{
"id": 763,
"thread_id": 70,
"source_id": "3",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1628#msg1628",
"date": "2010-06-20T16:11:20Z",
"text": "It will always benefit you to have the fastest computer, or have more computers than anyone else. The hits per day you get will go down statistically over time as the difficulty rises, but you will still get a larger share than everyone else if you control the biggest pool of resources.
This is all based on the theory that statistics mean something though.. The guy with the 1Ghz computer could 'get lucky' and generate a thousand a day while the guy with the compute cluster gets none. I think this 'get lucky' theory is what gambling is based on.
",
"nested_level": 0
},
{
"id": 764,
"thread_id": 70,
"source_id": "4",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1630#msg1630",
"date": "2010-06-20T17:39:28Z",
"text": "You should try one of Laszlo's builds of Bitcoin. They show the number of hashes / second that you're computing. Post that number, and you/we can calculate how often you will find a block (on average, statistical caveats apply as Laszlo suggested).
",
"nested_level": 0
},
{
"id": 765,
"thread_id": 70,
"source_id": "5",
"poster_name": "spndr7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=205",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1632#msg1632",
"date": "2010-06-21T04:28:43Z",
"text": "my CPU amd turion 2 cores rated at 1.6 Ghz generates 50 BC in 2 days.........
",
"nested_level": 0
},
{
"id": 766,
"thread_id": 70,
"source_id": "6",
"poster_name": "paperfree",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=264",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1651#msg1651",
"date": "2010-06-22T02:19:43Z",
"text": "100/day seems pretty good... Does internet connection speed matter? Also, does it matter how long your computer has been continuously connected?
",
"nested_level": 0
},
{
"id": 767,
"thread_id": 70,
"source_id": "7",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: How fast do the fastest computers generate bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=197.msg1652#msg1652",
"date": "2010-06-22T02:43:00Z",
"text": "100/day seems pretty good... Does internet connection speed matter? Also, does it matter how long your computer has been continuously connected?
Nope
and you can only generate when you have all blocks, so you won't generate for the first minutes of starting Bitcoin. Doesn't matter past that.
I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect. Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks.
I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.
The latest SVN version has a khash/s display. Around 400 khash/s per processor is typical.
",
"nested_level": 0
},
{
"id": 769,
"thread_id": 71,
"source_id": "1",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Dying bitcoins",
"url": "https://bitcointalk.org/index.php?topic=198.msg1638#msg1638",
"date": "2010-06-21T13:22:35Z",
"text": "Hello,
if somebody's loosing his wallet (e.g. due to disk crash) he's not able to get back his coins, is he?
So every time a person looses coins, they're lost forever? So the bitcoin network will slowly shrink over time? (Because there will always be people who loose wallets!)
TIA
virtualcoin
edit: Forgot to mention the coins of users that are try out bitcoin and then never use it again.
",
"nested_level": 0
},
{
"id": 770,
"thread_id": 71,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Dying bitcoins",
"url": "https://bitcointalk.org/index.php?topic=198.msg1640#msg1640",
"date": "2010-06-21T13:54:29Z",
"text": "They are lost for good. Think of it like someone losing their wallet in the ocean. It seems like it would be a problem but it's really not that significant. People lose their gold jewelry all the time but it doesn't make much of a difference to the value of gold.
I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this..
",
"nested_level": 0
},
{
"id": 771,
"thread_id": 71,
"source_id": "3",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: Dying bitcoins",
"url": "https://bitcointalk.org/index.php?topic=198.msg1641#msg1641",
"date": "2010-06-21T14:33:31Z",
"text": "They are lost for good. Think of it like someone losing their wallet in the ocean. It seems like it would be a problem but it's really not that significant. People lose their gold jewelry all the time but it doesn't make much of a difference to the value of gold.
But loosing 1 bitcoin in the ocean of a maximum of 21.000.000 coins seems significant to me, so not comparable to gold and jewelry.
So only 21000 losses of 1000 coins can happen. That's not much!
But loosing 1 bitcoin in the ocean of a maximum of 21.000.000 coins seems significant to me, so not comparable to gold and jewelry.
So only 21000 losses of 1000 coins can happen. That's not much!
But remember that each bitcoins can be divided into 100 million pieces, as needed.
And the more valuable they become, the more careful people will be not to lose them.
So how am I able to transfer less than BC0.01 without getting the message \"error in amount\" from the bitcoin program?
",
"nested_level": 0
},
{
"id": 774,
"thread_id": 71,
"source_id": "6",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Dying bitcoins",
"url": "https://bitcointalk.org/index.php?topic=198.msg1645#msg1645",
"date": "2010-06-21T16:33:00Z",
"text": "The current user interface doesn't support smaller than 0.01 increments but it is possible to support it in a future revision.
",
"nested_level": 0
},
{
"id": 775,
"satoshi_id": 131,
"thread_id": 71,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Dying bitcoins",
"url": "https://bitcointalk.org/index.php?topic=198.msg1647#msg1647",
"date": "2010-06-21T17:48:26Z",
"text": "Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone.
I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this..
Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal.
I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.
Testing at this point is much appreciated.
",
"nested_level": 0
},
{
"id": 777,
"thread_id": 72,
"source_id": "2",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1655#msg1655",
"date": "2010-06-22T04:06:45Z",
"text": "I'm just here
Windows 7 x64
4 GB RAM
Intel i7 860
Very nice! There have definitely been some major improvements, including the hashmeter, RPC support, and a command-line daemon. It would be nice if the listtransactions RPC method were finished before the next release, though. Also, some code should be added to the JSON-RPC methods to list out dHashesPerSec.
Great work Satoshi!
",
"nested_level": 0
},
{
"id": 779,
"thread_id": 72,
"source_id": "4",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1659#msg1659",
"date": "2010-06-22T07:28:56Z",
"text": "Whoohoo! Can't wait!
Note, is there somewhere I can get a devel build?
Maybe we can setup nightly builds or something...
",
"nested_level": 0
},
{
"id": 780,
"thread_id": 72,
"source_id": "5",
"poster_name": "teppy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=206",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1662#msg1662",
"date": "2010-06-22T14:15:24Z",
"text": "Should we try for some publicity? Slashdot is good if we can get it.
I've had a number of submissions accepted, though always by one editor that no longer works there. Anyone else with a Slashdot connection?
",
"nested_level": 0
},
{
"id": 781,
"thread_id": 72,
"source_id": "6",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1664#msg1664",
"date": "2010-06-22T14:20:31Z",
"text": "Should we try for some publicity? Slashdot is good if we can get it.
I've had a number of submissions accepted, though always by one editor that no longer works there. Anyone else with a Slashdot connection?
We should try to get publicity, and focus the campaign on the time right after the release to get the maximum impact: simultaneously advertising on forums, irc, Youtube, Facebook, Google Ads and other places. Slashdot with its millions of tech-savvy readers would be awesome, perhaps the best imaginable! I just hope the server can stand getting \"slashdotted\"
Maybe it should be upscaled beforehand just in case.
It would be nice if the listtransactions RPC method were finished before the next release, though.
My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.
We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.
Here's RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in \"c:\\program files\\bitcoin\"
",
"nested_level": 0
},
{
"id": 784,
"thread_id": 72,
"source_id": "9",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1672#msg1672",
"date": "2010-06-22T17:58:56Z",
"text": "I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.
Testing at this point is much appreciated.
I just finished creating a clean Amazon EC2 debian 5.0 machine image with everything I needed to compile bitcoind, and it compiled (using a variation of Laszlo's makefile.unix) and is running fine (just finished downloading the block chain). I'll let you know if it misbehaves.
I had trouble compiling the gtk version, but I think that's because I did something wrong compiling wxWidgets. I don't need no stinkin' graphics (and am not a wxWidgets expert), so I'm not going to bother trying to fix that.
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\\Program Files\\Bitcoin\\bitcoin.exe in OnInit()
I have the same problem :|
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\\Program Files\\Bitcoin\\bitcoin.exe in OnInit()
What operating system?
Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the \"%appdata%\" directory exists.
Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.
Windows 7 x64 ENG
4 GB RAM
Intel i7 860
I was using the v0.2.10 build by laszlo before yours.
",
"nested_level": 0
},
{
"id": 788,
"satoshi_id": 141,
"thread_id": 72,
"source_id": "13",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1677#msg1677",
"date": "2010-06-22T19:25:13Z",
"text": "davidonpda, were you also running laszlo's build previously?
Check if the \"%appdata%\" directory exists, and \"%appdata%\\bitcoin\"
Try:
rename \"%appdata%\\bitcoin\" bitcoin2
does it work then?
",
"nested_level": 0
},
{
"id": 789,
"thread_id": 72,
"source_id": "14",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1678#msg1678",
"date": "2010-06-22T19:33:24Z",
"text": "Check if the \"%appdata%\" directory exists, and \"%appdata%\\bitcoin\"
Both are existing
Try:
rename \"%appdata%\\bitcoin\" bitcoin2
does it work then?
Yes it works.
so I closed it, copied the walled.dat from the old folder to the new one, and now it's downloading blocks
Address book and old transfers seem ok, but there aren't anyone of old \"generated coins\" ... I just need to wait?
Anyway, I can just go back with the old v0.2.10
EDIT:
I did another thing.
Closed it, copied addr.dat / blk0001.dat / blkindex.dat from old folder to the new one.
Restarted bitcoin ( v0.30 ), and now it seems that everything is working. ( I can see also old generated coins now )
I just did NOT copied \"log.0000000002\" from the database folder ...
You figured it out faster than I could post a reply.
It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
When you copied the directory except log.0000000002, that's the best solution. You should be good now.
The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to v0.2.10.
Anyone else who hits this problem, move the database\\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)
I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
yes, I'm just using 0.30 by now.
Thank you!
Runs fine under WINE. *rhymes*
It automatically switched the language to German, too. Now that I can see the translation in the client itself, I noticed a few things to improve, and will post a new .po file within the next two or so days.
",
"nested_level": 0
},
{
"id": 793,
"thread_id": 72,
"source_id": "18",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1685#msg1685",
"date": "2010-06-22T22:00:47Z",
"text": "Yeah, 0.3.0 seems to have a performance increase over svn r84 with Laszlo's performance patch.
",
"nested_level": 0
},
{
"id": 794,
"satoshi_id": 143,
"thread_id": 72,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1686#msg1686",
"date": "2010-06-22T22:23:39Z",
"text": "Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
",
"nested_level": 0
},
{
"id": 795,
"thread_id": 72,
"source_id": "20",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1687#msg1687",
"date": "2010-06-22T23:07:30Z",
"text": "Much faster than Laszlo's build for me. Went from 600-700khash/s to 1000-1100khash/s on my Intel Core 2 Duo E8500. From 700-800khash/s on a laptop i7 to ~1100khash/s.
edit: Keeping the \"Run Bitcoin\" option checked in the installer seems to run it with admin privileges on the first launch. (in Win7)
",
"nested_level": 0
},
{
"id": 796,
"satoshi_id": 144,
"thread_id": 72,
"source_id": "21",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1748#msg1748",
"date": "2010-06-24T17:40:05Z",
"text": "Here's RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the \"-mt\" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
",
"nested_level": 0
},
{
"id": 797,
"thread_id": 72,
"source_id": "22",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1750#msg1750",
"date": "2010-06-24T20:49:24Z",
"text": "Nice. :-)
64-bit version works fine on Ubuntu 10.04, of course it's (much) faster than through WINE emulation (and because it's 64-bit!?)
4 cores: 2850 khash/s
3 cores: 2130 khash/s
2 cores: 1420 khash/s
1 core: 700 khash/s
WINE (32-bit):
4 cores - 2300 khash/s
3 cores - 1740 khash/s
2 cores - 1150 khash/s
1 core - 580 khash/s
Thank you - looks pretty nice, too.
http://i50.tinypic.com/2ih1h0p.jpgedit: What's the difference between \"Sent/Received\" and \"All transactions\"?
will it change something if you release a x64 bit version for Windows?
",
"nested_level": 0
},
{
"id": 799,
"thread_id": 72,
"source_id": "24",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1758#msg1758",
"date": "2010-06-24T23:26:03Z",
"text": "Ubuntu 9.04 x86:
vlad@vlad:~/bitcoin/bin/32$ ./bitcoind
./bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)
Anybody know what Bitcoin needs?
",
"nested_level": 0
},
{
"id": 800,
"satoshi_id": 145,
"thread_id": 72,
"source_id": "25",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1760#msg1760",
"date": "2010-06-25T02:17:41Z",
"text": "I don't know. Maybe someone with more Linux experience knows how to install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?
The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/
",
"nested_level": 0
},
{
"id": 801,
"thread_id": 72,
"source_id": "26",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1763#msg1763",
"date": "2010-06-25T04:47:28Z",
"text": "Windows 7 x64
4 GB RAM
Intel i7 860
4 cores ( 8 virtuals ): 2200 khash/s
It's lower than Ubuntu :|
",
"nested_level": 0
},
{
"id": 802,
"thread_id": 72,
"source_id": "27",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1765#msg1765",
"date": "2010-06-25T07:18:54Z",
"text": "Linux on an overclocked Pentium D:
- 1 core: 565 khash/s, 1.01 kW h/day
- 2 cores: 1100 khash/s, 1.78 kW h/day
The new version seems to give me an improvement of 20-30 khash/s (with two cores) over SVN 80 with laszlo's patch.
Does anyone know what I have to change in the makefile so that I don't have to add LD_LIBRARY_PATH pointing to the dependency libraries when executing BitCoin? I already have -I and -L pointing to the single, correct location. (This isn't caused by the new version; I've always had this problem.)
",
"nested_level": 0
},
{
"id": 803,
"thread_id": 72,
"source_id": "28",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1766#msg1766",
"date": "2010-06-25T10:29:54Z",
"text": "The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
But look here:
32-bit Linux version on Ubuntu 10.044 cores: 2500 khash/s
3 cores: 1900 khash/s
2 cores: 1260 khash/s
1 core: 630 khash/s
64-bit Linux version on Ubuntu 10.04 (new measure)4 cores: 2880 khash/s
3 cores: 2150 khash/s
2 cores: 1450 khash/s
1 core: 720 khash/s
(Though I never created one coin, yet - but I don't let bitcoin run on 4 cores the whole day, not even on 1 core...)
@Joozero - The Intel i7 860 is @ 2.8 Ghz, isn't it? My Phenom II is @ 3 Ghz, that's another important fact I think. I will try bitcoin on Windows 7 at the same machine later.
/edit
32-bit Win version on Windows 7 64-bit4 cores: 2310 khash/s
3 cores: 1740 khash/s
2 cores: 1160 khash/s
1 core: 580 khash/s
Thanks virtualcoin, that's a perfect comparison.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
",
"nested_level": 0
},
{
"id": 805,
"satoshi_id": 149,
"thread_id": 72,
"source_id": "30",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1787#msg1787",
"date": "2010-06-26T00:32:09Z",
"text": "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)
",
"nested_level": 0
},
{
"id": 806,
"thread_id": 72,
"source_id": "31",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1788#msg1788",
"date": "2010-06-26T01:19:35Z",
"text": "It looks good! The number of hashes per second intermittently disappears for a few seconds at a time. I think it might be triggered by clicking on the file menu multiple times. I'm using the Linux 64-bit build.
",
"nested_level": 0
},
{
"id": 807,
"satoshi_id": 151,
"thread_id": 72,
"source_id": "32",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1800#msg1800",
"date": "2010-06-26T15:10:10Z",
"text": "The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
",
"nested_level": 0
},
{
"id": 808,
"satoshi_id": 153,
"thread_id": 72,
"source_id": "33",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 1.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1806#msg1806",
"date": "2010-06-26T19:21:05Z",
"text": "Changed the version number to 1.3 and removed \"Beta\".
(links removed, see below)
Uses irc.lfnet.org.
",
"nested_level": 0
},
{
"id": 809,
"thread_id": 72,
"source_id": "34",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: 1.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1832#msg1832",
"date": "2010-06-27T14:45:28Z",
"text": "I'm not sure why but I noticed that as well - my Win32 build was a lot slower than the linux/mac builds I did. I used MinGW and all that but maybe I made a mistake somewhere.. I probably used a different version of Berkeley DB than Satoshi too so that's why the logs weren't binary compatible.
",
"nested_level": 0
},
{
"id": 810,
"satoshi_id": 159,
"thread_id": 72,
"source_id": "35",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 1.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1834#msg1834",
"date": "2010-06-27T15:30:13Z",
"text": "MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
",
"nested_level": 0
},
{
"id": 811,
"thread_id": 72,
"source_id": "36",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: 1.3 almost ready",
"url": "https://bitcointalk.org/index.php?topic=199.msg1842#msg1842",
"date": "2010-06-27T22:02:25Z",
"text": "MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
Maybe best to look at the 4.4.3 compiled disassembly as well and see if there are any differences.
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
Dimitri
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow.
(reverted to rc2)
Links removed, 0.3 is now released, so go to
http://www.bitcoin.org to download it.
Laszlo's build is going to be our first Mac release so please test it!
",
"nested_level": 0
},
{
"id": 816,
"thread_id": 72,
"source_id": "41",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: 0.3 almost ready -- please test the Mac version!",
"url": "https://bitcointalk.org/index.php?topic=199.msg2002#msg2002",
"date": "2010-07-06T17:52:58Z",
"text": "I'm running rc4 on xp32/64 and everything seems ok so far,
installed without problems, ~50connections on a forwarded node, 8 on others,
limited to 1(of2) and 1-2(of3) cores, which scales up nicely, but hasnt generated any coins yet.
Hopefully i'll get some tonight.
What if a major flaw is discovered in BC's cryptographic soundness? Is there any way to prevent the complete dissolution of the system and of everybody's wealth?
Perhaps one way to do it would be to create a voluntary registry of non-anonymous addresses, to be shared and verified publicly. Then, if a major flaw arose (maybe someone solved the factoring problem
), then there would still be a record of everybody's wealth that could be used in a new system (supposing everybody could agree on the latest time that no fraudulent transactions could have taken place). Of course, people who chose to stay anonymous (and therefore did not include their address in the registry) would see their wealth disappear, but alas that risk would prove the price of anonymity.
What if a major flaw is discovered in BC's cryptographic soundness? Is there any way to prevent the complete dissolution of the system and of everybody's wealth?
Perhaps one way to do it would be to create a voluntary registry of non-anonymous addresses, to be shared and verified publicly. Then, if a major flaw arose (maybe someone solved the factoring problem
), then there would still be a record of everybody's wealth that could be used in a new system (supposing everybody could agree on the latest time that no fraudulent transactions could have taken place). Of course, people who chose to stay anonymous (and therefore did not include their address in the registry) would see their wealth disappear, but alas that risk would prove the price of anonymity.
That is an interesting idea. But, how would the wealth be transfered to a new system and what would be the exchange rate? Perhaps this could be combined with an insurance plan that had a predetermined and guaranteed payout written in the policy?
But, how would the wealth be transfered to a new system and what would be the exchange rate?
Wealth would not have to be transferred per say. Rather, a new, cryptographically sound system would be adopted, and previous owners would be given new currency in proportion to their old balance of BC. The exchange rate would be determined solely by the market's usage of the new currency.
Imagine a verified public registry that voluntarily ties BC addresses to email addresses (by signing your email address with your private key for the BC address). If BC failed, the new system would take a certain historical block from BC at a fraudless time. Then, supposing again that 21 million units of new currency were being generated, and that 80% of the old BC currency had been registered, then each time a node generates a block for the new currency they would get to keep 20% of some number of new currency while every registered address would receive some tiny share of the other 80% in proportion to their registered BC at their registered email address. When all new currency generation is done, the owners of the 80% of registered BC money will have 80% of the new money, while the lost 20% is reissued.
I would bet that if BC had seen widespread adoption, and if many people had registered their addresses, then the new currency would be readily accepted because so many people would be getting it for free and in their \"fair\" amount.
Perhaps this could be combined with an insurance plan that had a predetermined and guaranteed payout written in the policy?
That's another interesting idea. Basically, some individual could choose to setup their own insurance company for BC where people pay a certain percentage of their protected BC amount. This company would then keep a registry similar to that above, but only for its clients (It's necessary to verify that clients have the BC amount they claim). Instead of issuing new currency in case of catastrophic failure, they could simply issue USD's. Again, the biggest challenge would be setting clear terms for when payout would occur and which block would be treated as the truth. Perhaps they could pay out from the last block issued before a mathematical proof of the system's unsoundness was offered?
It is strange that is has taken such a long time to create a digital fiat currency. And who
says that Bitcoin is the one and only digital currency that will exist in the future?
Right now, if there is a flaw in the bitcoin algorithm the people dealing with it will lose their trust
in the currency and the bitcoins will lose their value. If there are several digital currencies in the future
you will just sell your bitcoins and buy more secure (or more useful) digital coins instead. I think that there will be a tendency to swap from one digital money system to another, once people see an advantage of a new system. Like an evolutionary process.
I find it funny that some people still cling to the idea that there has to be some kind of \"agency\" that regulates the economy. I mean when you don't want your old money anymore you just .. eh .. sell it?
You are not forced by anyone to use bitcoins, right? And nobody can stop you from using another digital
currency. So the best way to keep your wealth is to invest in different assets - as always in life.
",
"nested_level": 0
},
{
"id": 822,
"thread_id": 73,
"source_id": "5",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg1759#msg1759",
"date": "2010-06-25T00:56:40Z",
"text": "Max,
Your comments make total sense, as long as there is time to switch over to the new currency when a threat looms. This is pretty reasonable. For example, people might start to find some small flaws with SHA-256, and so people would have time to buy into the new currency before the whole system unravels.
However, supposing somebody found a major flaw while BC was in widespread usage, that person could commit a lot of fraud without people even realizing immediately. In this case, it might be valuable to have some kind of registry, because people might want to buy into a new currency that does include some distribution in proportion to formerly registered wealth (game theoretically, only the wealthier registered 50% would prefer this currency, but that's the topic of another discussion).
Now, it seems like a pretty good solution would be for everyone to hold a diversity of digital currencies, which are backed by a diversity of cryptographic methods. However, this solution has many costs of its own, since the marketplace would need to support many currencies. Among other things, it would be absolutely necessary to have many competing, cheap exchanges.
",
"nested_level": 0
},
{
"id": 823,
"thread_id": 73,
"source_id": "6",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg1764#msg1764",
"date": "2010-06-25T05:30:44Z",
"text": "Max,
Your comments make total sense, as long as there is time to switch over to the new currency when a threat looms. This is pretty reasonable. For example, people might start to find some small flaws with SHA-256, and so people would have time to buy into the new currency before the whole system unravels.
However, supposing somebody found a major flaw while BC was in widespread usage, that person could commit a lot of fraud without people even realizing immediately. In this case, it might be valuable to have some kind of registry, because people might want to buy into a new currency that does include some distribution in proportion to formerly registered wealth (game theoretically, only the wealthier registered 50% would prefer this currency, but that's the topic of another discussion).
Now, it seems like a pretty good solution would be for everyone to hold a diversity of digital currencies, which are backed by a diversity of cryptographic methods. However, this solution has many costs of its own, since the marketplace would need to support many currencies. Among other things, it would be absolutely necessary to have many competing, cheap exchanges.
Any monetary system with a central registering authority is headed for failure imo.
No not a centralized registry. There's no \"agency\" controlling it. It's just something that users would agree to, just like every other rule of BC. Deentralized and public, just like BC does transactions.
",
"nested_level": 0
},
{
"id": 825,
"thread_id": 73,
"source_id": "8",
"poster_name": "Max Stirner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=247",
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg1837#msg1837",
"date": "2010-06-27T18:22:51Z",
"text": "Amal, I admit: I got you wrong!
I am just afraid that digital currencies will not stay legal for long because the government has not control over it. (The day they make it illegal, you should open a bottle of champagne, because that's the sign that bitcoin is a success.)
So at that point, they will also shut down your registry. And all the people who gave their address to that agency will get into trouble.
If there is a major flaw discovered in Bitcoin and there is no sufficient time to swap to a different system, I assume there is nothing you can do about a loss of your wealth.
Still, let's suppose YOU have discovered a way to produce an unlimited amount of coins. Your goal would be to profit from that secret AS LONG AS POSSIBLE. So even people that have the power to cheat wouldn't want a collapse of the digital fiat currency. And before the collapse of the old currency they would change their fake money for a better currency. But I am afraid that also goes for the so called \"real\" money. But.. somebody who has the brains to fool the algorithm of the digital currency at least gets a reward for his genius. In our paper fiat money system in the contrary, people who have access to the \"printing press\" of the government / central bank get rewarded for being just plain assholes.
",
"nested_level": 0
},
{
"id": 826,
"satoshi_id": 160,
"thread_id": 73,
"source_id": "9",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg1838#msg1838",
"date": "2010-06-27T19:06:09Z",
"text": "Here's an answer to a similar question about how to recover from a major meltdown.
https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
Satoshi,
That would indeed be a solution if SHA was broken (certainly the more likely meltdown), because we could still recognize valid money owners by their signature (their private key would still be secure).
However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.
",
"nested_level": 0
},
{
"id": 828,
"thread_id": 73,
"source_id": "11",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg1922#msg1922",
"date": "2010-07-02T00:21:53Z",
"text": "If you're worried about elliptic curve cryptography being broken, then don't store any significant wealth in Bitcoin. Just like if you're worried about your (real, physical) wallet being stolen don't hold more cash than you need to get through a couple of days of purchases.
By the way: I think an economical method for separating gold atoms from seawater will be found before elliptic curve cryptography is broken (and I think both are unlikely in the next 25 years).
",
"nested_level": 0
},
{
"id": 829,
"satoshi_id": 177,
"thread_id": 73,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Major Meltdown",
"url": "https://bitcointalk.org/index.php?topic=202.msg2133#msg2133",
"date": "2010-07-10T13:36:17Z",
"text": "However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.
True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)
So I've been watching the IP addresses of people getting 5 free bitcoins from the Bitcoin Faucet (
https://freebitcoins.appspot.com/ ).
And I see some... uh,
interesting patterns. Like these successful requests for coins:
79.117.152.158 - - [21/Jun/2010:12:17:02 -0700] \"POST / HTTP/1.1\" 200 1234
79.117.159.197 - - [21/Jun/2010:12:16:24 -0700] \"POST / HTTP/1.1\" 200 1234
79.117.135.236 - - [21/Jun/2010:12:10:23 -0700] \"POST / HTTP/1.1\" 200 1234
79.117.163.238 - - [21/Jun/2010:12:08:50 -0700] \"POST / HTTP/1.1\" 200 1234
79.117.155.23 - - [21/Jun/2010:12:08:07 -0700] \"POST / HTTP/1.1\" 200 1234
My apologies if there actually are a bunch of new bitcoin users using IP addresses in the 79.117 range... but I'm guessing somebody there is getting more than their fair share of free bitcoins.
There are several suspicious requests from the 192.38.95.* address block, too.
So I've made some changes to the Faucet. You won't notice them unless you try to cheat; if you do try to cheat, you'll have to solve a CAPTCHA to get coins.
If that doesn't discourage cheating, I'll modify the code so that if it think you're trying to cheat it requires a CAPTCHA and only gives out a bitcoin nickel (0.05 bitcoins)...
Lol, bitnickel!
Anyhow, I was expecting this.
And what about those using proxies?
I don't wanna be an #@!%!#% here, but ehh... I think the \"5 BTC for FREE!\" thing, is kinda... flawed...
",
"nested_level": 0
},
{
"id": 832,
"thread_id": 74,
"source_id": "3",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Bitcoin Faucet changes",
"url": "https://bitcointalk.org/index.php?topic=206.msg1749#msg1749",
"date": "2010-06-24T18:17:36Z",
"text": "I don't wanna be an #@!%!#% here, but ehh... I think the \"5 BTC for FREE!\" thing, is kinda... flawed...
\"flawed\" ??
I've been telling people it is a half-baked, I've-lost-my-friggin-mind idea!
So far, I count it as a big success-- I've learned a lot that will help me with my next Bitcoin-related project, I've made a bunch of people a teeny-tiny bit happier, and I've personally invested just under $1.00 worth of bitcoins over the last two weeks.
I did throw in the towel today and turned on reCAPTCHA for everybody getting bitcoins (it looks like somebody DID bother to write a robot to harvest coins through proxies). It was fun trying to come up with new, creative ways of detecting cheating, but I have more important things to work on.
http://www.decaptcher.com/It costs someone $2 per 1000 captchas. So, they could suck out 5000 bitcoins for $2. lol.
But, that should help stop most people
I guess that's why the forum still gets those annoying spam user registrations despite the captcha.
Gavin, why don't you just block all served Bitcoin addresses?
Would it be easy to generate them automatically?
",
"nested_level": 0
},
{
"id": 835,
"thread_id": 74,
"source_id": "6",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Bitcoin Faucet changes",
"url": "https://bitcointalk.org/index.php?topic=206.msg1757#msg1757",
"date": "2010-06-24T23:13:45Z",
"text": "Gavin, why don't you just block all served Bitcoin addresses?
Would it be easy to generate them automatically?
It is easy to generate them automatically (it is easy to write code that asks the Bitcoin program to generate and return a new address).
Funny how on this forum the same people play both sides of the table--on the one hand, trying to come up with ways to preserve absolute anonymity (e.g. the heroin store thread), and then coming here and trying to do sort of the opposite to protect BTC Faucet.
I love it
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 bitcoins given until it's manageable, and always require captcha.
",
"nested_level": 0
},
{
"id": 838,
"thread_id": 75,
"source_id": "1",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1774#msg1774",
"date": "2010-06-25T20:20:16Z",
"text": "At 21:11 dutch time (CEST), around 10 minutes ago from when I made this post, the Bitcoin clients are getting k-lined.
(note, times are CEST.)
--- SNIP ---
[21:11:36] * u4euc453wZ599zQ has quit (K-Lined)
[21:11:37] * u4mZRTtQwC6NskZ has quit (K-Lined)
[21:11:37] * x398030675 has quit (K-Lined)
[21:11:37] * u4m5AmvGVaM8MNU has quit (K-Lined)
[21:11:37] * x92119461 has quit (K-Lined)
[21:11:38] * u4iQ9mpGopGTd6D has quit (K-Lined)
[21:11:39] * u4iqow5D1WqBmPH has quit (K-Lined)
[21:11:39] * u4qsjyU6VRAtfRD has quit (K-Lined)
--- SNIP ---
Anyhow, this leaves the bitcoin network unable to operate.
I see some clients getting back slowly.
But this worries me.
I suggest we apply what ever other bootstrapping mechanism we have right now, and release 0.3 ASAP.
Someone in #freenode suggested this:
<gwillen> Xunie: as a potential user of bitcoin, I would suggest that if your project is going to connect to IRC in the background, you should document that fact somewhere. I'm suddenly much more wary of using it now that I know that it does this.
This does make Bitcoin seem a bit... malicious to say the least...
Whoops! My bad. I was testing something and it went haywire.
Should see the k-lines lift shortly. Heh.
It's a relief to hear this.
And what were you exactly testing?
Like, how can it affect the whole network?
If this is a bug that can bring down the whole network, it's pretty serious, heh.
",
"nested_level": 0
},
{
"id": 841,
"thread_id": 75,
"source_id": "4",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1777#msg1777",
"date": "2010-06-25T20:41:44Z",
"text": "I'm banned.
",
"nested_level": 0
},
{
"id": 842,
"thread_id": 75,
"source_id": "5",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1778#msg1778",
"date": "2010-06-25T20:48:08Z",
"text": "I'm connected now.
",
"nested_level": 0
},
{
"id": 843,
"satoshi_id": 147,
"thread_id": 75,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1779#msg1779",
"date": "2010-06-25T21:15:15Z",
"text": "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 install can't discover the network for the first time without IRC.
0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy.
",
"nested_level": 0
},
{
"id": 844,
"thread_id": 75,
"source_id": "7",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1783#msg1783",
"date": "2010-06-25T23:33:17Z",
"text": "I was mucking around with the source code on a large research cluster that I have access to. For some reason the nodes were connecting and disconnecting from Freenode quite rapidly witch resulted in most of my nodes getting k-lined. Freenode started going nuts and blocking my nodes as fast as I was creating connections.
Not too sure if other people were k-line'd as well because of this?? However, the timing was \"bang on\".
I had discovered the bug around the same time this k-line problem was reported. I ended up forcing the source to seed IPs from some Bitcoin clients that I run on a different network.
",
"nested_level": 0
},
{
"id": 845,
"thread_id": 75,
"source_id": "8",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1784#msg1784",
"date": "2010-06-25T23:48:45Z",
"text": "This does make Bitcoin seem a bit... malicious to say the least...
Bootstrapping to the network is malicious?
Whether it's right or wrong, when people who know what IRC is hear that IRC is involved in something, they immediately think malice.. This is not without foundation as a lot of antisocial behavior takes places on IRC channels. The other thought is botnets which use IRC to bootstrap, control or communicate. A program which connects to IRC is by definition called a 'bot' and to IRC people that means something bad, especially if it's not an IRC bot program specifically.
What Satoshi did here is use IRC simply as a matchmaking service but I could see how someone could draw the wrong conclusion when they see a channel with hundreds of randomly named bots idling in it. Perhaps you could put these people's minds at ease if there was some pop up asking them if it's ok to bootstrap from IRC.. because if they just write it off as a trojan or botnet they may never bother to find out how it really works.
",
"nested_level": 0
},
{
"id": 847,
"thread_id": 75,
"source_id": "10",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1790#msg1790",
"date": "2010-06-26T04:13:50Z",
"text": "Oh so with all that being said, you guys are all welcome to IRC on irc.lfnet.org. It is a small network that me and a couple of guys run.. we don't have services or k-lines or anything like that.
",
"nested_level": 0
},
{
"id": 848,
"satoshi_id": 150,
"thread_id": 75,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel",
"url": "https://bitcointalk.org/index.php?topic=215.msg1797#msg1797",
"date": "2010-06-26T14:28:06Z",
"text": "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 switching over:
http://bitcointalk.org/index.php?topic=199.msg1787#msg1787Is it about time we lose the Beta? I would make this release version 1.3.
",
"nested_level": 0
},
{
"id": 850,
"thread_id": 76,
"source_id": "2",
"poster_name": "virtualcoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=267",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1818#msg1818",
"date": "2010-06-26T23:04:01Z",
"text": "I'm not sure, but I think it's unusual to jump from version 0.3 to 1.3. ^^ Maybe 1.0?
But on the other hand: who cares?
",
"nested_level": 0
},
{
"id": 851,
"thread_id": 76,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1823#msg1823",
"date": "2010-06-27T01:10:42Z",
"text": "My vote is for 1.0. It'll probably help us get slashdotted.
",
"nested_level": 0
},
{
"id": 852,
"thread_id": 76,
"source_id": "4",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1824#msg1824",
"date": "2010-06-27T01:33:31Z",
"text": "+1 NLS. Version 1.0 sounds better than 1.3.
",
"nested_level": 0
},
{
"id": 853,
"satoshi_id": 157,
"thread_id": 76,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1827#msg1827",
"date": "2010-06-27T12:43:50Z",
"text": "But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don't want to put my money in something that's 1.0. 1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3)
",
"nested_level": 0
},
{
"id": 854,
"thread_id": 76,
"source_id": "6",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1829#msg1829",
"date": "2010-06-27T13:47:18Z",
"text": "True, and it is your project. 1.3 it is!
",
"nested_level": 0
},
{
"id": 855,
"thread_id": 76,
"source_id": "7",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1847#msg1847",
"date": "2010-06-28T08:36:42Z",
"text": "Proprietary software developers often start at version 1 for the first release of a program and increment the major version number with each rewrite. This can mean that a program can reach version 3 within a few months of development, before it is considered stable or reliable.
In contrast to this, the free-software community tends to use version 1.0 as a major milestone, indicating that the software is \"complete\", that it has all major features, and is considered reliable enough for general release.
Quote SourceThe above description is how I and most geeks view version 1.0 software. Slashdot readers and editors will understand that 1.0 means that we're ready for business. Getting on Slashdot is the best advertising opportunity we'll probably get for a very long time, so to willfully pass it up seems unwise to me.
I agree with lachesis and NLS. Version 1.0 is better for publicity, and is commonly taken to mean \"we're out of beta now, but don't expect everything to be perfect.\"
",
"nested_level": 0
},
{
"id": 857,
"thread_id": 76,
"source_id": "9",
"poster_name": "teppy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=206",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1850#msg1850",
"date": "2010-06-28T18:38:46Z",
"text": "I agree as well - \"version 1.0\" is ready-made for Slashdot.
",
"nested_level": 0
},
{
"id": 858,
"thread_id": 76,
"source_id": "10",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1851#msg1851",
"date": "2010-06-28T19:20:13Z",
"text": "1.0 is a nice version number to get started off with, and indicates that the software is ready for prime time. A jump from 0.2 to 1.3 would be a little strange.
",
"nested_level": 0
},
{
"id": 859,
"thread_id": 76,
"source_id": "11",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1853#msg1853",
"date": "2010-06-28T21:07:15Z",
"text": "I also agree with v1.0 for the same reasons posted above. Publicity would also be nice.
FWIW I'd vote for 1.0 too.
As NLS and D\u0489ataWraith have pointed, there are certain perceptions associated with a 1.0 release and they are mostly reasonable. Trying to cheat these perceptions in such way is unwise in my opinion. Much better to release 1.0 now and do another minor release or two shortly afterwards.
",
"nested_level": 0
},
{
"id": 861,
"thread_id": 76,
"source_id": "13",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1880#msg1880",
"date": "2010-06-30T00:04:49Z",
"text": "FWIW I'd vote for 1.0 too.
As NLS and D\u0489ataWraith have pointed, there are certain perceptions associated with a 1.0 release and they are mostly reasonable. Trying to cheat these perceptions in such way is unwise in my opinion. Much better to release 1.0 now and do another minor release or two shortly afterwards.
And if not 1.0, there's nothing wrong with 0.3. Tor is only at 0.2 and is a popular anonymity network. It's all about networking and how you present the application. Tor has user-friendly client software and a user-friendly website. Is Bitcoin really even 1.0 software? I would argue that it is still missing a lot of polish and features. 0.3 is fine; just improve the marketing, the user-friendliness and look & feel of the website, and usage will keep increasing.
I vote for \"1.0\" and not \"1.3\" or something, bleh!
(I also advice we use a major, minor and patch level version number, \"0.0.00\".)
I've used bitcoin-1.3.0.rc3-linux
[1] and found it to be mature enough to be called \"1.0\" in my opinion.
(It was already called 1.3 there, but I guess we cal all agree it's the next release, thus right now can be called both 1.3 and 0.3.)
[1] http://www.bitcoin.org/download/bitcoin-1.3.0.rc3-linux.tar.gzI think version 0.3 would be a better choice if Bitcoin wasn't making financial transactions on Windows. A significant number of people, particularly Windows users, don't trust software below version 1.1 or 1.2, but going from version 0.2 to 1.3 will backfire when those users find out we skipped the first three 1.x versions.
",
"nested_level": 0
},
{
"id": 864,
"thread_id": 76,
"source_id": "16",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1885#msg1885",
"date": "2010-06-30T02:45:27Z",
"text": "I'm not much of a marketing guy or anything but it makes sense to me to refer to software like this by the version in source control, like Bitcoin r82 or whatever.. maybe that's too geeky for some people.
",
"nested_level": 0
},
{
"id": 865,
"satoshi_id": 164,
"thread_id": 76,
"source_id": "17",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Beta?",
"url": "https://bitcointalk.org/index.php?topic=217.msg1928#msg1928",
"date": "2010-07-02T22:03:41Z",
"text": "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#msg1927Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy.
Hello, I heard about this project around freenode, and I really like the idea.
I am wondering if there is a chance you could develop a fully headless version, but with controlling options? Maybe something similar to ncurses work, like rtorrent? So we can make and share bitcoins on headless computers, while still having the ease and control of te GUI interface?
Another suggestion that would be nice would be an update module, if you are running an old version (don't know if there is already, didn't look around much).
Boot strapping to a different type of medium, as well as IRC, would be an improvement as well. Maybe something similar to Bittorrent trackers? Some ISPs block IRC, and some people dislike the thought of IRC.
Lastly, IPv6 support would be pretty awesome, if possible. Then people would worry less about the IRC bootstrapping, I'd think.
I am also running bitcond 1.3 (RC?) that satoshi just posted. How do I use it though? There aren't many docs on using bitcoind... it just said \"starting bitcoin server\", and my IP appears in the #bitcoin room on irc.lfnet.org. How would I figure out my bitcoin address, how many coins I have, send to other people, etc?
I am no C programmer, so I would not be able to implant any of these suggestions, but I would hope that it could be possible
Thanks in advance!
I am also running bitcond 1.3 (RC?) that satoshi just posted. How do I use it though? There aren't many docs on using bitcoind... it just said \"starting bitcoin server\", and my IP appears in the #bitcoin room on irc.lfnet.org. How would I figure out my bitcoin address, how many coins I have, send to other people, etc?
You can talk to the running bitcoind either by:
1. sending JSON-RPC calls; see
http://www.bitcoin.org/wiki/doku.php?id=api for more details.
2. re-running bitcoind and giving it extra arguments; it will figure out that there's already a bitcoind running and will pass along the commands.
For example, running \"bitcoind help\" gives you the list of commands it understands:
bitcoind help
getaddressesbylabel <label>
listreceivedbyaddress [minconf=1] [includeempty=false]
getreceivedbyaddress <bitcoinaddress> [minconf=1]
getbalance
getblockcount
getblocknumber
getconnectioncount
getdifficulty
getgenerate
getinfo
getlabel <bitcoinaddress>
getnewaddress [label]
getreceivedbyaddress <bitcoinaddress> [minconf=1]
getreceivedbylabel <label> [minconf=1]
help
listreceivedbyaddress [minconf=1] [includeempty=false]
listreceivedbylabel [minconf=1] [includeempty=false]
listtransactions [count=10] [includegenerated=false]
sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <generate> [genproclimit]
setlabel <bitcoinaddress> <label>
stop
To figure out what your bitcoin address is, run:
bitcoind getaddressesbylabel \"\"(your default address has the empty string as its label). bitcoind getaddressesbylabel \"Your Address\"
To figure out how many coins you have, run:
bitcoind getbalance
or
bitcoind getinfo
Regarding running headless: the non-daemon bitcoin will run via remote (e.g. ssh forwarded) X-windows, if you install the necessary X11-client stuff on your server.
Ah, nice, thanks for that.
When I run,
./bitcoind getaddressesbylabel \"\"
[
]
Is it normal for it to give nothing, or what?
getinfo gives me
./bitcoind getinfo
{
\"balance\" : 0.000000000000000,
\"blocks\" : 62899,
\"connections\" : 39,
\"proxy\" : \"\",
\"generate\" : false,
\"genproclimit\" : -1,
\"difficulty\" : 19.40479632838217
}
When I run,
./bitcoind getaddressesbylabel \"\"
[
]
Is it normal for it to give nothing, or what?
Hmm, yeah, it's probably normal; I THOUGHT the default address was given an empty label; I'm wrong, they're given the label \"Your Address\".
So:
./bitcoind getaddressesbylabel \"Your Address\"
should work.
Or just generate a new address, either with or without a label:
./bitcoind getnewaddress
Welcome, Harry.
I hadn't thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial.
The focus for bitcoind so far has been more on backend support for websites. There's demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for \"generated\" and \"hashmeter\" for some feedback. Generated blocks take about 24 hours before they're credited to your balance.
",
"nested_level": 0
},
{
"id": 871,
"thread_id": 78,
"source_id": "1",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1859#msg1859",
"date": "2010-06-29T00:41:52Z",
"text": "I'd like to see an option (with an RPC interface as well) to limit the number of connections that a Bitcoin client accepts. My home client is connected to 70 different nodes and my poor wimpy router just can't keep up. It's starting to slow my network down, to the point where I'll need to force Bitcoin to ignore connection requests (with -connect=<a node>) if this keeps up.
A connection limiting option would be a great alternative.
",
"nested_level": 0
},
{
"id": 872,
"thread_id": 78,
"source_id": "2",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1864#msg1864",
"date": "2010-06-29T01:19:51Z",
"text": "Unforward port 8333
It'll limit it to 15 and still work fine.
Alright. Thanks.
Would still be a nice feature. I don't mind people connecting to me to bootstrap or something, and I'd probably leave it at 40 rather than 15.
",
"nested_level": 0
},
{
"id": 874,
"thread_id": 78,
"source_id": "4",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1883#msg1883",
"date": "2010-06-30T01:54:04Z",
"text": "Might I 2nd this request as a 'standard' GUI feature.
I've recently tested bitcoin through various socks proxies / providers and the ability to limit connections below 10 would be really useful.
",
"nested_level": 0
},
{
"id": 875,
"satoshi_id": 161,
"thread_id": 78,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1924#msg1924",
"date": "2010-07-02T19:21:36Z",
"text": "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 messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally.
It would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections.
I will implement a feature to stop accepting inbound connections once you hit a certain number.
Which version are you running?
Anyone know how many connections typical P2P software like BitTorrent can get up to?
",
"nested_level": 0
},
{
"id": 876,
"thread_id": 78,
"source_id": "6",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1925#msg1925",
"date": "2010-07-02T19:33:24Z",
"text": "BitTorrent clients can do hundreds of connections easily - this is why they end up killing those little embedded routers. It should be no problem for a regular IP router but the little embedded things are doing NAT so they're tracking state on all those connections and run out of memory.. also they're very slow SoC style computers so everything going through them suffers.
Torrent clients generally have options for configuring a global maximum number of connections, maximum inbound and maximum outbound connections.
I think it would be good to allow configuration of unlimited inbound/outbound connections for those who have the capability to do it, and provide a conservative default for those who are using NAT, tor, proxies, etc.
",
"nested_level": 0
},
{
"id": 877,
"satoshi_id": 165,
"thread_id": 78,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Feature Request: Limiting Connections",
"url": "https://bitcointalk.org/index.php?topic=223.msg1929#msg1929",
"date": "2010-07-02T22:20:20Z",
"text": "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 accepting nodes get.
If anyone wants more than 8 connections, they can open port 8333 on their firewall.
",
"nested_level": 0
},
{
"id": 878,
"thread_id": 79,
"source_id": "1",
"poster_name": "teppy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=206",
"subject": "Slashdot Submission for 1.0",
"url": "https://bitcointalk.org/index.php?topic=234.msg1967#msg1967",
"date": "2010-07-05T16:07:52Z",
"text": "Unless anyone else knows a Slashdot editor, I'd be willing to submit this when 1.0 is released. (More people submitting their own versions will improve the chances of hitting the front page.)
(Technology Section)
Headline: Bitcoin releases Version 0.3
Tag: Encryption
Body: How's this for a disruptive technology? Bitcoin is a peer-to-peer network based digital currency with no central bank, and no transaction fees. Using a proof-of-work concept, nodes burn CPU cycles searching for bundles of coins, broadcasting their findings to the network. Analysis of energy usage indicates that the market value of Bitcoins is already above the value of the energy needed to generate them, indicating healthy demand. The community is hopeful the currency will remain outside the reach of any government.
Comments?
[Edited the \"energy backed\" language.]
[Eliminated the 21M number, as db suggested. Mentioning subdividing would be too wordy.]
[Incorporated some of amall's suggestions, including eliminating the passive voice in the final sentence.]
[Integrated satoshi's suggestions, eliminating the word \"anonymous\", mention of Hashcash, and the \"developers expect\" taunt.]
[Changed the closing sentence to dwdollar's \"...community is hopeful...\" language. Satoshi, are you OK with that?]
",
"nested_level": 0
},
{
"id": 879,
"thread_id": 79,
"source_id": "2",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Slashdot Submission for 1.0",
"url": "https://bitcointalk.org/index.php?topic=234.msg1968#msg1968",
"date": "2010-07-05T17:05:08Z",
"text": "I wouldn't call bitcoin \"energy backed\". There has been ample discussion on this and varying opinions, but I think most people would say that the bitcoin's value determines the amount of energy required to generate them, and not the other way around.
In the short run, the energy cost of generation may ensure a baseline value, but in the long run the value will be solely based on human behavior.
Thanks for pushing for a slashdot feature, bitcoin could really use some publicity to help it grow.
",
"nested_level": 0
},
{
"id": 880,
"thread_id": 79,
"source_id": "3",
"poster_name": "Timo Y",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=271",
"subject": "Re: Slashdot Submission for 1.0",
"url": "https://bitcointalk.org/index.php?topic=234.msg1969#msg1969",
"date": "2010-07-05T17:21:02Z",
"text": "Unless anyone else knows a Slashdot editor, I'd be willing to submit this when 1.0 is released. (More people submitting their own versions will improve the chances of hitting the front page.)
(Technology Section)
Headline: Bitcoin releases Version 1.0
Body: How's this for a disruptive technology? Bitcoin is a buyer-anonymous, seller-anonymous cryptocurrency with no central bank, and no transaction fees. Using a concept similar to Hashcash, clients burn CPU cycles attempting to discover some of the 21,000,000 Bitcoins that will eventually be found. It is expected that over time, the market value of Bitcoins will reach parity with the energy needed to generate them, resulting in an energy-backed currency outside the reach of any government.
Comments?
1) I like the first two sentences.
2) Not sure whether I would include the \"similar to Hashcash\" phrase. I doubt that the majority of slashdot users has ever heard of Hashcash.
3) I have a problem with the \"energy-backed\" claim. It's misleading. Just because you need to invest energy to generate Bitcoins doesn't make them energy-backed. They would only be energy-backed if there was some sort of guarantee that they could be traded back into energy. Which there isn't. The generation of Bitcoins is irreversible. If the software was hardcoded so that you could buy other users' CPU cycles with Bitcoins, then maybe we could call them energy-backed.
Mentioning the 21 000 000 bitcoins but not that they can be divided in 100 000 000 pieces each is confusing. It doesn't sound like a practical currency.
",
"nested_level": 0
},
{
"id": 882,
"thread_id": 79,
"source_id": "5",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Slashdot Submission for 1.0",
"url": "https://bitcointalk.org/index.php?topic=234.msg1973#msg1973",
"date": "2010-07-05T19:24:56Z",
"text": "Good revisions so far.
More suggestions:
1) How about mentioning bittorrent instead of hashcash? Bittorrent is a huge buzz word and could grab some attention. As a completely distributed and anonymous network, I'd say that Bitcoin is similar enough to justify the comparison.
2) \"...clients burn CPU cycles...\" --> \"...nodes burn CPU cycles...\"
3) Throw in \"decentralized\" and \"proof-of-work based\" somewhere
4) Personally, I'm still not fully satisfied with the mention of energy-backing. Maybe you could replace it with something about the time-stamped transaction history being voted on / secured by the majority of CPU power?
5) Not to be a smartass, but watch out for passive voice (e.g. \"It is expected that over time...\"). Headlines and news articles usually try to grab readers' attention by using the more exciting active voice.
Feel free to take all, none, or somewhere in between. We're critical because we care
BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0.
I really appreciate the effort, but there are a lot of problems.
We don't want to lead with \"anonymous\". (I've been meaning to edit the homepage)
\"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government.\" -- I am definitely not making an such taunt or assertion.
It's not stable-with-respect-to-energy. There was a discussion on this. It's not tied to the cost of energy. NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.
Sorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to.
",
"nested_level": 0
},
{
"id": 884,
"satoshi_id": 168,
"thread_id": 80,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin 0.3 released!",
"url": "https://bitcointalk.org/index.php?topic=238.msg2004#msg2004",
"date": "2010-07-06T18:32:35Z",
"text": "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 managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.
What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero)
Get it at
http://www.bitcoin.org or read the forum to find out more.
Has there been a concerted effort to attack, subvert, or break Bitcoin? One way to test that it is secure from attack would be to actually try to undermine it, by double-spending coins, creating fake coins, posting false transactions, etc... and if flaws are found, better that they are found now than later, when the bitcoin economy is potentially larger and there is more to lose.
",
"nested_level": 0
},
{
"id": 886,
"thread_id": 81,
"source_id": "2",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Security",
"url": "https://bitcointalk.org/index.php?topic=240.msg2104#msg2104",
"date": "2010-07-09T18:11:27Z",
"text": "It's a bad idea to try to break the \"in-production\" bitcoin network.
If anybody is starting serious work on either extending Bitcoin or developing compatible implementations or trying to break it by creating bad transactions, I think creating a \"parallel universe\" test network with its own block chain, data directory, etc makes sense.
Satoshi: would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel? Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.
",
"nested_level": 0
},
{
"id": 887,
"thread_id": 81,
"source_id": "3",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Security",
"url": "https://bitcointalk.org/index.php?topic=240.msg2105#msg2105",
"date": "2010-07-09T20:13:27Z",
"text": "
Satoshi: would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel? Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.
I second this, however I don't think block generation time should be changed. I think it should be identical to the production network. This, for example, would allow testers to try to subvert the system by creating nodes with particularly low latency, and keep the results applicable to the real network.
Great idea Gavin!
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 to the main network, the difficulty is still at the original low difficulty. If you've port-forwarded though, then outside nodes might still connect inward to you.
With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn't want the -connect computers on IRC.
void ThreadIRCSeed(void* parg)
{
if (mapArgs.count(\"-connect\"))
return;
",
"nested_level": 0
},
{
"id": 889,
"thread_id": 82,
"source_id": "1",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2025#msg2025",
"date": "2010-07-07T16:54:44Z",
"text": "The current BitCoin implementation is certainly better than using a credit card, but I wouldn't use it in environments requiring strong anonymity without a lot of changes.
The history of a coin is publicly available. Anyone can see the flow of BitCoins from address to address.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg707.imageshack.us%2Fimg707%2F317%2Funknownaddress.th.png&t=589&c=eaO-sQGLTbwtGA\"/)
This becomes a problem when certain points in the \"transaction chain\" become known to the attacker. In the image below, the attacker controls both the source of Mr. Doe's BitCoins and the destination. Since Doe bought his coins using non-anonymous methods, he is easily identified. His identity is tied to an address in the transaction chain.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg682.imageshack.us%2Fimg682%2F6671%2Fknown.th.png&t=589&c=aWYj6VV_LFnRdQ\"/)
A more likely scenario is for your BitCoin balance to come from transactions made over insecure channels (email, this forum, etc.). If you're particularly careless, the destination can just Google all of the addresses in the transaction chain. Maybe he'll find that one of them is in your forum signature here.
I've thought of two ways to make this harder. The first is to randomly send your coins to new addresses that you've generated just for this purpose. The coins are still part of your balance, but it's impossible for an outsider to prove that you sent the coins to yourself instead of a real person. However, the transaction chain still has your identity in it. In a real investigation, you would be targeted for close examination because you either know (directly or indirectly) the real person who is under investigation, or you are that person.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg692.imageshack.us%2Fimg692%2F7418%2Fsimplemix.th.png&t=589&c=jWxI4SumT9BYnw\"/)
The second way is for an external service to take the coins of many different people, mix them up, and send similar amounts back to those peoples' addresses. If the mixer keeps no logs of who gets which coins, any investigation must stop here.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg293.imageshack.us%2Fimg293%2F3070%2Fexternal.th.png&t=589&c=uWGtC-5hroQjDA\"/)
For maximum security, BitCoin should have the capability to automatically send coins through several external mixers. Assuming at least one of them doesn't keep logs (and all of them actually return your coins), this should keep you completely safe.
There's a problem with safely coordinating all of this. You want all of your coins to be mixed at least once, but keeping track of this in a database will ruin your plausible deniability. Probably you'd have to initially keep track, but then delete the database after all the coins have been made safe.
Unrelated to the chain issues above, BitCoin is vulnerable to network analysis. If an attacker can watch all of your incoming and outgoing traffic, he can easily see which transactions are yours. If the connection is unencrypted (as it is now), he can see when you broadcast a transaction that you didn't receive.
Even when encrypted (through Tor or a built-in mechanism), it's not impossible for an attacker to see which transactions are yours if he can see both ends of one of your connections to the BitCoin network.
Your transactions can be identified through Tor like this:
1. The attacker fills the BitCoin network with IP addresses that he controls.
2. When one of these \"evil nodes\" receives a packet, the attacker sees if it was received close to the time when he saw you send a packet. If this happens a few times, the attacker knows who you are and can see your transmissions to the network.
3. When you send a transaction, the attacker knows it's yours if you send it without receiving a packet in a while.
To fix this, BitCoin should implement encryption, padding (to prevent any size-based identification), dummy packets, and randomization in sending times. Some plausible deniability could also be added if BitCoin could export and import transactions to/from a file (importing would broadcast the transaction to the network, while exporting would not). Then you could transmit this file in other ways (a flash drive, for example).
I also see two structural problems not related to anonymity:
- If the network is segmented at the network layer (because the PoTUS executed his \"Internet kill switch\", for example), the block chain will be forked. This would be really bad.
- It's very easy for an attacker with lots of IP addresses to fill the network with cancer nodes. I'm not sure how badly BitCoin could be affected by this.
Whatever mechanism is chosen, it had better not significantly slow down the network or client unless strong anonymity is required/requested.
I've tried I2P and Tor, and, for me, super-strong privacy isn't worth the performance cost.
Also, regarding forking the block chain by a network split:
It's only \"really bad\" if I can get away with double-spending some coins before the network merges again.
If I'm buying valuable stuff, then the merchants will likely require 6 confirmations before releasing the goods, so I'd have to be able to keep the network split for an hour or more.
Merchants will likely have very-well-connected, long-running nodes. For example, the Bitcoin Faucet has 66 connections right now. If I wanted to try to implement a \"fork the block chain attack\" I'd have to somehow manage to insert my \"cancer nodes\" in between two merchants that I want to rip off (I'll end up ripping off one of the two, because eventually one of the two double-spend transactions will \"win\").
I don't know enough about network analysis to figure out how many cancer nodes you'd need to have a significant chance of getting in between two merchants with 60+ connections in a network of (say) 1,000 non-cancerous nodes, but I bet it is a very large number.
",
"nested_level": 0
},
{
"id": 891,
"thread_id": 82,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2029#msg2029",
"date": "2010-07-07T18:35:21Z",
"text": "Everything I mentioned could be user-configurable, and most of it wouldn't slow down actual transactions. Even if you had all of these security features disabled, just having them implemented would give you plausible deniability in certain cases.
Block generation would be slowed in the case of a network split, so executing a double-spend would be even more difficult. I was thinking more of a problem like the Cogent-Level3 peering dispute, where there is no path between two ISPs for a long while. In this case, lots of transactions would be lost when the network is recombined and one of the chain's branches is discarded.
",
"nested_level": 0
},
{
"id": 892,
"thread_id": 82,
"source_id": "4",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2030#msg2030",
"date": "2010-07-07T18:41:56Z",
"text": "Would the transactions on the other block chain be lost?
I thought they'd just be re-integrated into the new-best-chain (if they were valid), just starting with '1 confirmation' again...
",
"nested_level": 0
},
{
"id": 893,
"thread_id": 82,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2031#msg2031",
"date": "2010-07-07T18:53:04Z",
"text": "I don't know how this is currently handled. It might already be fixed. I haven't looked at the source.
",
"nested_level": 0
},
{
"id": 894,
"thread_id": 82,
"source_id": "6",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2034#msg2034",
"date": "2010-07-07T19:28:05Z",
"text": "Anonymity is not a feature that most users need.
",
"nested_level": 0
},
{
"id": 895,
"thread_id": 82,
"source_id": "7",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2038#msg2038",
"date": "2010-07-07T20:26:06Z",
"text": "*Strong
Anonymity is not a feature that most users need.
*Strong
Anonymity is not a feature that most users need.
That's my Steve Jobsian statement of the day
I'm not saying that it's not something worth working on, but we shouldn't prioritize anonymity features ahead of basic functionality, ease-of-use, and driving adoption. There can always be a special implementation (maybe a separate client even) down the road that takes care of all of the features for ensuring anonymity. As Gavin implied, many anonymity features would come at cost to users who don't need them.
I don't know, I personally find it rather disconcerting if users in the chain can be identified. For example, it wouldn't be enough for me to simply get bitcoins at an exchange, send them to a random address, and then use them from that point on. Your identity would still be linked. However, given the public nature of the transactions, I'm not sure if there is any way around this.
I agree with you though, the software needs to be usable with a well-designed UI, and it needs to be robust. Bitcoin needs a full security audit to see how robust it is to different kinds of attacks, and what is compromised.
*Strong
Anonymity is not a feature that most users need.
That's my Steve Jobsian statement of the day
I'm not saying that it's not something worth working on, but we shouldn't prioritize anonymity features ahead of basic functionality, ease-of-use, and driving adoption. There can always be a special implementation (maybe a separate client even) down the road that takes care of all of the features for ensuring anonymity. As Gavin implied, many anonymity features would come at cost to users who don't need them.
I don't know, I personally find it rather disconcerting if users in the chain can be identified. For example, it wouldn't be enough for me to simply get bitcoins at an exchange, send them to a random address, and then use them from that point on. Your identity would still be linked. However, given the public nature of the transactions, I'm not sure if there is any way around this.
I'm sure somebody somewhere would/will be happy to sell you bitcoins anonymously; just put cash and a bitcoin receiving address in an envelope and mail it. The exchange (who you'd have to trust to actually send you the coins) takes the cash and send coins to the address. They have no idea who you are, and your identity isn't linked to the coins.
Well, it isn't linked to the coins until you forget to turn on TOR or I2P before spending coins on something illegal. Or you remain completely and utterly anonymous right up until you spend coins on something physical and have it shipped to your home address. Or you arrange to have contraband \"dead dropped\" somewhere, and you get arrested when you go to pick it up.
None of which have anything to do with Bitcoins, and all of which seem to me to be more likely ways of getting into trouble than somebody managing to figure out that \"transaction for purchase of illegal stuff\" is linked to \"Gavin purchased a bunch of Bitcoins from Bobby's Discount Bitcoin Emporium\" last year.
+1 to Previous Post by gavinandresen
Because Bitcoin transactions are not forced through the regulated banking system, bitcoins can range from being not at all anonymous if I announce my transactions on twitter, to being completely anonymous so long as I purchase anonymously, obfuscate ownership by transferring to one or more intermediary addresses and then spend them anonymously. There's nothing wrong with adding that obfuscation optionally, but it's overkill to apply it to all transactions because not everyone needs that level of anonymity and no matter how anonymous you make it, it's never going to be anonymous to the folks who voluntarily reveal their identity.
",
"nested_level": 0
},
{
"id": 900,
"thread_id": 82,
"source_id": "12",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2049#msg2049",
"date": "2010-07-08T01:48:25Z",
"text": "90% of money has cocaine on it.
Real life example
1) I set up a fresh Bitcoin address/Bitcoin Client in a VPS hosted in Panama, connected via Tor.
2) I purchase a 100 EUR paysafecard code at some newsagent in a big, densely populated city. I pay cash, and make sure the newsagent is 2 km away from my home.
3) I advertise the sale of the paysafecard code on this forum, via Tor and a free public wifi hotspot, using a fresh username.
4) A buyer shows up. I send him my bitcoin address and the paysafecard code from a freshly set up webmail address, again via Tor and a free public wifi hotspot.
Using above precautions, it will be very difficult to link my physical identity to my bitcoin address. Not impossible, but difficult enough for my purposes.
",
"nested_level": 0
},
{
"id": 902,
"thread_id": 82,
"source_id": "14",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Anonymity",
"url": "https://bitcointalk.org/index.php?topic=241.msg2057#msg2057",
"date": "2010-07-08T16:37:01Z",
"text": "Not bad.
As far as anonymous internet connections go, prepaid phones aren't a bad choice either. They're cheap, nearly impossible to tie to the user, and can be destroyed when finished. Again, they can be bought in densely crowded shopping malls or walmarts.
Dont forget to use an anonymous method to pay for the VPS foreverdamaged. Perhaps a prepaid credit card also bought from a crowded location would do the trick.
By the way, I like to imagine that this user is in China and is trying to buy a book about freedom
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 chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated.
If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over.
If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.
It wouldn't be easy to take advantage of the segmentation to double-spend. If it's impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over.
You would usually know whether you're in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you're in the smaller segment, you should assume nothing is confirmed.
",
"nested_level": 0
},
{
"id": 904,
"thread_id": 83,
"source_id": "1",
"poster_name": "user",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=298",
"subject": "BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2028#msg2028",
"date": "2010-07-07T18:15:28Z",
"text": " Hi. (I'm sorry if I don't understand any concept).
What you think if anyone intruder will buy up bitcoin currency and erase all binary data. This way can destroy bitcoin systems. Is btc network protected against that attack?
",
"nested_level": 0
},
{
"id": 905,
"thread_id": 83,
"source_id": "2",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2033#msg2033",
"date": "2010-07-07T19:16:20Z",
"text": "That would be the same as an attacker buying all US dollars and burning them. It's not an effective attack, because people only \"sell\" their dollars when they are getting something of equal or greater value anyway.
So, yes, it is possible that someone could buy up all or many Bitcoins and then \"destroy\" the private key so that nobody can ever use those bitcoins again, but it really isn't a problem because the attacker is the only one who will actually lose wealth!
The only scenario that would be at all likely would be if something like a stupid government didn't like bitcoins and thought it was a threat, so they would spend $30,000 or w/e to buy all bitcoins and \"destroy\" them. That would be pretty stupid though, because another ecurrency just like bitcoin would pop right up!
I suppose if a government actually wanted to hold off these ecurrencies, they should buy lots of the currency but not tell anyone. However, instead of \"destroying\" it or never spending it, they should just manipulate the market a lot while it's young (buy a ton at once, then sell way undervalue, etc). Then, not realizing the currency was being manipulated, people would just lose faith in these types of ecurrency...
Sorry that got rambly, I'm thinking out loud here.
",
"nested_level": 0
},
{
"id": 906,
"thread_id": 83,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2035#msg2035",
"date": "2010-07-07T19:42:47Z",
"text": "Or they could buy them while they're inexpensive, artificially increase their value, causing people to invest, crash the market, causing lots of people to lose their money and then repeat. Although a concerted effort might be considered fraud.
",
"nested_level": 0
},
{
"id": 907,
"thread_id": 83,
"source_id": "4",
"poster_name": "user",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=298",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2039#msg2039",
"date": "2010-07-07T20:57:27Z",
"text": " (Hypnotically) If I run any two (or more) unique e-currency exchanger I can displace btc e-currency from it circulation.
I seems, \"truly\" system must include mechanisms that protect self from any fraud activity.
And what do you think?
2Developers and BTC-system designers: please, join to discussion
",
"nested_level": 0
},
{
"id": 908,
"thread_id": 83,
"source_id": "5",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2040#msg2040",
"date": "2010-07-07T20:58:41Z",
"text": "My daughter ripped a dollar bill in half earlier when she got into her mom's wallet.. It's not really worth it for me to try to get a dollar bill replaced by the treasury so I just consider it destroyed - but it's not really going to affect my budget and certainly not the economy of the United States. There are about 65000 blocks so over 3 million bitcoins have been in circulation. Many of them have probably been destroyed by accident when someone lost a wallet file or whatever..
If you want to buy a bunch of bitcoins (or dollar bills) from me and destroy them let me know, I can give you a good exchange rate for bulk transactions like that
For dollar bills I would charge 1.03 to make it worth my while but I will have them sent by air mail or courier depending on the distance.
I think if a government wanted to get rid of bitcoins they would just take us away in black helicopters - probably Satoshi first..
I don't think you understood my point.
It is a lot easier to arrest and lock up the prominent bitcoin users than to manipulate the market. Like it was pointed out, a market is not just a single currency, it can be a lot of different types of currency and goods. Trying to manipulate one end or the other would be difficult. It is better to just get the people - fear of being arrested is much more effective than trying to shake up confidence in the currency.
Destroying a large amount of currency just causes deflation and makes the remaining currency that much more desirable - imagine if you had a pallet of gold bars in your garage and nobody else did.
Maybe you don't agree with my assessment of the situation but what you posted was far from constructive.
In response to your original post, I don't believe the situation you describe is a big risk.
",
"nested_level": 0
},
{
"id": 910,
"thread_id": 83,
"source_id": "7",
"poster_name": "user",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=298",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2070#msg2070",
"date": "2010-07-08T19:02:27Z",
"text": "I don't think you understood my point.
Ok, let's elaborate It.
You wrote:
It is a lot easier to arrest and lock up the prominent bitcoin users than to manipulate the market.
But I write earlier:
What you think if anyone intruder will buy up bitcoin currency and erase all binary data. This way can destroy bitcoin systems. Is btc network protected against that attack?
And If you try to lookup subject carefully you can find:
Massive Attack against BTC system.
I don't discuss in another attack that you indicated (I understand you idea: attack to system through people).
Ok. Follow next.
Maybe you don't agree with my assessment of the situation but what you posted was far from constructive.
The main idea why I begin this thread:
I seems, \"truly\" system must include mechanisms that protect self from any fraud activity.
In response to your original post, I don't believe the situation you describe is a big risk.
But I think that It will be better if in design-time developers build mechanisms that decrease potential of fraudulent ability. And you?
Please, explain me if I am wrong. I want to understand you reflections.
You can't destroy them all, more will be generated constantly. That 21 million number is not going to be reached in the foreseeable future. As you know, the generation algorithm adjusts itself to slow the generation rate intentionally.
",
"nested_level": 0
},
{
"id": 912,
"thread_id": 83,
"source_id": "9",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2074#msg2074",
"date": "2010-07-08T21:13:56Z",
"text": "It is unnecessary to protect against an attack in which an attacker buys all Bitcoins and deletes their wallet.
Assuming we were all willing to sell, the attacker would just give us large amounts of cash for our Bitcoins. We could then start another Bitcoin block chain and start over from square one (only with a much larger confidence in the market, since it worked once!) and reinvest that money if we wanted.
Essentially, no matter what happens there is always the nuclear option of \"starting over.\"
There are much more dangerous and likely attacks to be worried about.
",
"nested_level": 0
},
{
"id": 913,
"satoshi_id": 174,
"thread_id": 83,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)",
"url": "https://bitcointalk.org/index.php?topic=242.msg2078#msg2078",
"date": "2010-07-09T03:28:46Z",
"text": "What the OP described is called \"cornering the market\". When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.
The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979:
\"Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]\"
http://en.wikipedia.org/wiki/Cornering_the_marketI know it's not the smartest move to name my user account using non-latin characters. Anyway, 0.2 has no problems with this.
Verified as follows... created a 'normal' new user and 0.3 opened the data folder. Created new, fresh data folder and copied it to the non-standard user - 0.3 fails with DB_RUN_RECOVERY.
",
"nested_level": 0
},
{
"id": 915,
"satoshi_id": 171,
"thread_id": 84,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username",
"url": "https://bitcointalk.org/index.php?topic=246.msg2068#msg2068",
"date": "2010-07-08T18:24:19Z",
"text": "Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that.
Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not?
",
"nested_level": 0
},
{
"id": 916,
"satoshi_id": 173,
"thread_id": 84,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username",
"url": "https://bitcointalk.org/index.php?topic=246.msg2077#msg2077",
"date": "2010-07-09T03:01:35Z",
"text": "I think I see where the problem is. Coincidentally, I recently coded a replacement for the function in question which should fix it. It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison.
",
"nested_level": 0
},
{
"id": 917,
"satoshi_id": 175,
"thread_id": 84,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username",
"url": "https://bitcointalk.org/index.php?topic=246.msg2092#msg2092",
"date": "2010-07-09T15:37:05Z",
"text": "I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it. This change is revision 102 of the SVN.
",
"nested_level": 0
},
{
"id": 918,
"thread_id": 85,
"source_id": "1",
"poster_name": "jib",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=333",
"subject": "Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2292#msg2292",
"date": "2010-07-12T11:36:17Z",
"text": "Am I correct in understanding that every node receives information about every transaction (as the technical paper says)? Doesn't that make bitcoin completely impractical for use as a currency on a large scale?
",
"nested_level": 0
},
{
"id": 919,
"thread_id": 85,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2300#msg2300",
"date": "2010-07-12T12:28:24Z",
"text": "Why do you say that? Pretty much every P2P system works by replicating the information across all the participating nodes, even 100G movie packs for BitTorrent - we're talking about less than a kilobyte of information for a transaction.
",
"nested_level": 0
},
{
"id": 920,
"thread_id": 85,
"source_id": "3",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2303#msg2303",
"date": "2010-07-12T13:05:08Z",
"text": "By the time Bitcoins replace the Euro
I think most people will be running lightweight clients on wireless smartcards in their (physical) wallet that don't pay attention to every single transaction.
But that's WAAAY down the road. And who knows, by then maybe we'll all have a hundred-gigabits of bandwidth in our pants.
hundred-gigabits of bandwidth in our pants.
![\"Lips](\"/static/img/emoticons/lipsrsealed.gif\"/)
Every other P2P system is replicating the information across a small group of participating nodes who are all interested in that content. On average each BitTorrent user downloads the movie once and uploads it once and that's it. And if you can't or don't want to download that 100G movie pack (like the vast majority of internet users) you can still use BitTorrent for smaller things.
Bitcoin, on the other hand, gives the whole world (assuming the whole world uses it) a live feed of the whole world's financial transactions all the time, and doesn't stop.
Say it becomes a popular payment method like Paypal or Alipay, which each process a few million transactions a day. That few million multiplied by \"less than a kilobyte\" makes at least a few hundred MB per day. That's more than the average person's internet usage. In some places it's more than the average person's available internet quota. And then that has to be distributed to millions of nodes, putting a significant load on some networks, not just individuals' connections.
I guess it's not quite as bad as I initially thought, but it's still enough to make it impractical for many people to run their own bitcoin clients in a world where bitcoin is popular. The likely scenario (assuming no change to how Bitcoin works) is that most people use big payment providers instead and those providers use Bitcoin between each other.
And then one of those providers ends up dominating and has more CPUs than the rest combined, and the whole \"bitcoin is secure as long as the honest CPUs collectively outnumber any attacker\" thing becomes moot.
Maybe.
",
"nested_level": 0
},
{
"id": 923,
"thread_id": 85,
"source_id": "6",
"poster_name": "TopSoil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=389",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2546#msg2546",
"date": "2010-07-13T13:05:24Z",
"text": "This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?
I see 3 scaling issues:
1) Having every node need to know about all transactions that happened ever.
2) Keeping the network connected
3) Amount of coins scaling with increased economic activity.
1) This seems like the biggest issue. Is the hope is that bandwidth and storage will keep pace with the number of transactions? Like the OP said paypal has millions of transactions a day. This will totally clog a lot of users bandwidth if they all have to be notified of each transaction.
Is the plan to eventually have the chain drop off old blocks? or is there a way to split the chain into parts so only part of the network has to keep track of certain span of coins.
2) What happens when there are a few million concurrent users? everyone connects to IRC still? (Granted this is fixable as the network grows since it seems outside of the whole block chain system)
3) You have this clever method of slowly introducing coins by time but time isn't really the important thing. Shouldn't the amount of coins in circulation be proportional to the amount of users? If you want to avoid inflation & deflation the number of coins shouldn't the number of coins be proportional to the number of users or number of transactions or some other metric that is closer to the size of the economy?
(Also I was able to figure out how/why the 21 million number was chosen?)
1 & 2 could be solved by using a distributed hash table:
You should really look at
http://en.wikipedia.org/wiki/Kademlia I haven't looked lately to see if someone has come up with a better distributed storage system but it was by far the best solution a few years ago. (and I've implemented it before if you have questions)
As my first post, I would like to say I'm interested. Experimental Code is always running on this thing, having more won't cause any harm
This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?
I see 3 scaling issues:
1) Having every node need to know about all transactions that happened ever.
2) Keeping the network connected
3) Amount of coins scaling with increased economic activity.
1) Actually, from what I read in the PDF, I don't think it's necessary. It only needs to know that a transfer of *this* coin from Owner A to Owner B was valid. It doesn't matter if 1 year ago, Owner C gave Owner A that coin.
2) It's P2P, someone out there will be connected. I run a 24/7 Dedicated Server just for Bit Coin now on a Fiber connection. Not because I work with them, but because I see the need to donate the resources for the cause.
3) Don't let the 21 million limit fool you. It's more like 21000000.00000000 limit because the coin is so divisible, but for sanity reasons, it would make sense not to be trading coin in the Quadrillion Bundles
1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.
2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?
",
"nested_level": 0
},
{
"id": 927,
"thread_id": 85,
"source_id": "10",
"poster_name": "spaceshaker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=371",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2633#msg2633",
"date": "2010-07-13T20:13:11Z",
"text": "3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?
I think we need to be clear to separate inflation/deflation from supply/demand.
So that means that the value of bitcoins will have to change over time which isn't ideal.
What is the value of bitcoin? It has value only in that people perceive that it has value (the same as any fiat currency). Perceptions change all the time. If you want to see how this plays out look at the currency exchange market today. The value of bitcoin will float over time as supply and demand for it ebbs and flows. The important point is that the supply is fixed (once most of the coins are in circulation) and this serves to protect the value of bitcoin. Inflation erodes the value of currency and punishes savers; its a type of tax.
Perhaps this thread would be more appropriate in the economics forum.
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?
A currency with a fixed supply has 0 inflation/deflation by definition.
You are probably referring to price inflation/deflation, which is a seperate phenomenon and is unimportant as long as there is no monetary inflation/deflation. Even if you wanted to, there is no meaningful way to do it. Just look at how fudged the CPI numbers are.
I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.
Now the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.
",
"nested_level": 0
},
{
"id": 930,
"thread_id": 85,
"source_id": "13",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2649#msg2649",
"date": "2010-07-13T21:16:37Z",
"text": "I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.
Now the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.
You have a point here; it would probably be good if there was a mechanism to regenerate lost coins, but I'm not sure how that could be implemented.
As Bitcoins become more valuable, people will increasingly take precautions. Therefore, the loss should decrease as time goes on. Losing 5000 BTCs worth $5 isn't such a big deal; losing 5000 BTCs worth $10,000 is!
1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.
That is a good point, one I didn't think about. So, let me think out loud here. There are a possible 21 million coins. Every time a block is generated by someone, they earn 50 coins. Right now, I see 66,618 blocks have been generated since the beginning. So that's 66618 x 50 = 3,330,900 coins so far. To reach 21 million, we need to reach 21,000,000 / 50 = 420,000 blocks. 66,618 blocks take up about 56 megabytes of hard disk space. So, perhaps 420,000 blocks (if every single coin is created) would take up about 420000 x 56 / 66618 = 353 megabytes of hard disk space.
The rest would be transaction history to make sure the owners are valid and older transactions are pruned after a while, so perhaps at full scale, this application could eat up as much as 1GB of hard disk space. So, someone correct me if I'm wrong, but even at full scale, the clients would need about 1GB of hard disk space to contain a fully generated coin network?
2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.
From what I read in the release notes, the IRC is just a bootstrap, the new version can work around IRC failure as it has an alternative (but slower) ways to sync up the first time users to the network.
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?
Well, imagine if you will, the US and our national gross. It's somewhere in the multi-trillions last I heard. So, if everything had to be converted to dollars, that would be a trillion dollars in circulation (ignore how a complex system like a countries currency, this is way over simplifying). No imagine all of that was to be transfered into Bit Coins? Well, there are only 21 million Bit Coins, so a 1 to 1 conversion is out of the question. Basically it would have to be scaled back to the decimal points (probably 4 places) to fit all of that in. That still leaves 4 more decimal places in which any economy working in the Quadrillion range is probably out of scope of any country in the world (or all countries combined really)
So, if you don't think of a 1 to 1 conversion for Bit Coins, because even I want to think of Bit Coins as dollars for example. But it isn't. It is it's own currency within itself whose value is only dependent on the people that use it and what value they give it. It's like that for any currency really, the only difference is, instead of the bank or government in XYZ country being the one who controls how it's created and distributed, WE *all* control how it's created and distributed.
We are *minting* the coin (through CPU cycles to generate the encryption hashes) and at the same time using it for trade and value. The only difference is, this isn't a USA currency or a Swedish currency, it's all completely electronic. The bank, the teller, the minting; is all of us at the same time. Basically, all of our clients have agreed upon certain rules to follow and as long as each client follows those rules, it can participate. Any client that doesn't (through hacking, cheating, etc.) is basically ignored by the rest. It's like playing a game of soccer where you have two teams competing and one guy just up and grabs the ball, runs down to the other side and throws the ball in. Dances up and down that he scored a point. Well, everyone else will just ignore him and his point, he wasn't playing by the set rules.
Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better:
http://bitcointalk.org/index.php?topic=57.0knightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.
Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.
Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.
I will second this. I am investigating whether this is a project I want to invest time and energy into (I am a professional C++ developer) as I see the potential for a revolutionary technology. However if the solution doesn't scale to millions and millions of transactions per-day (and a very large number of blocks) I fear this solution is destined to become more of an interesting research project rather than something that will have longevity and practical usefulness.
Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better:
http://bitcointalk.org/index.php?topic=57.0knightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.
Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.
Thanks for pointing that out, I wasn't sure how that would scale over time, was just making some guess. Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.
I'm curious myself to how much space it will take.
Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.
I'm curious myself to how much space it will take.
From the
pdf:
\"A block header with no transactions would be about 80 bytes.\"
and
\"Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space.\"
so 80 x number of blocks + average transaction size * number of transactions.
Practically, from my disk:
77428 transactions in 66663 blocks is about 46,752,464 bytes.
which works out to about 600 bytes per transaction (including block headers + database overheads)
77428 transactions in 66663 blocks is about 46,752,464 bytes.
which works out to about 600 bytes per transaction (including block headers + database overheads)
That sounds about right.
So a million transactions a day would be 600 million bytes. 600 megabytes a day, 18 GB a month.
That's not bad. Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers). You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month. And 18GB isn't much disk space in these days of terabyte hard drives.
A million transactions per day is a
LOT! For comparison, in 2006 there were about
60 million credit card transactions per day in the US.
Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something). And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network. And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.
You know, kind of like how we have those Big Routers in the Sky that handle Internet backbone traffic (or the ultra-fast DNS root servers). The Internet didn't start out with astoundingly fast routers zinging packets around.
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.
Is this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I am just thinking out loud here...
Although the peer-to-peer model is certainly novel perhaps it seems to me to be somewhat utopian. Bear with me for a minute here (I am not trying to troll). Consider banks. Banks have a system whereby they can work together efficiently. I take take money out of a ATM from bank X even though I bank with bank Y. Banks loan money to each other. They are generally cooperative. Instead of every Tom, Dick & Harry having a Bitcoin client on his/her PC (or smartphone) participating in an open P2P network, perhaps there is a collection of Bitcoin \"banks\" who provide the service of hosting and \"peering\" the Bitcoin block chain. These are large enough organizations that they can afford the bandwidth and hardware needed to maintain an infinitely long block chain with a million (or more) transactions a day. These banks would still be peer-2-peer, and hopefully also completely open. Ideally anybody could participate in the peer-2-peer network, its just that the average person won't because of the barrier to entry. These banks still operate using the same fundamental technology we have to day. All of the beautiful facets of Bitcoin are preserved, except that the number of active participants is somewhat reduced. Anybody that _wanted_ to participate still could.
The problem remaining would be the typical \"last mile\" problem. How does Tom (or Dick or Harry) perform transactions? Well the issue becomes much more straight forward at this point. Now the trust only has to be between two parties (the \"bank\" and Tom). This really becomes more of a proxy issue. Now Tom has to send a transaction request through his \"bank\". It might even be possible to bake into Bitcoin a protocol for proxy transactions.
Anyway...This is just my 2 cents. I would really like a tangible answer to this problem because it seems foundational to the success of this endeavor to me.
I think a lightweight client would need to trust the fast node it talks to that sees every transaction.
",
"nested_level": 0
},
{
"id": 939,
"thread_id": 85,
"source_id": "22",
"poster_name": "TopSoil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=389",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2719#msg2719",
"date": "2010-07-14T02:15:31Z",
"text": "That's not bad. Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers). You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month. And 18GB isn't much disk space in these days of terabyte hard drives.
Not bad? huh? That seems totally broken to me.
I'm less worried about storage space than the bandwidth and time it will take a new node to enter the network.
Like you said the blocks are duplicated so a given node must download some multiple of the transactions a day. That is a tremendous amount of downloading.
Also any new node must download 216GB for each year the network has been this large!
Doesn't the system also just completely break at some point when the rate of transactions is too high? I could be wrong since I'm not sure exactly how it is decided which transactions go into a particular block. Again the pdf is kind of lacking.
Also isn't there a problem when 2 computers both solve a block before they realize the other one has? This will become more and more likely as there are more nodes.
Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be
But it seems like a lot of these things aren't just issues of network structure. They seem inherent in the cryptographic design so it wouldn't be that straight forward to replace. Plus why not address these issues now if only to instill faith that the system is well thought out rather than just wave hands and say \"computers will be faster\" or \"we'll tack on some better networking later\"
Again I think the general idea is great and I hope the developers have good answers for all these questions. I just want to understand it/make sure it has been thought through carefully enough. I sincerely hope that it actually can work. I'd love to never have to use paypal again.
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.
Is this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I'm imagining:
A lightweight client would have a wallet with coins in it (public+private key pairs).
And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.
The lightweight client sends money by:
creating a transaction (signing coins with the private key)
sending the signed transaction securely to the ultra-fast server, which puts it on the network.
receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
(or getting a \"you already spent those coins\" error from the server)
The lightweight client receives money by:
Either polling the server every once in a while, asking \"Any payments to these BC addresses that I have in my wallet?\"
... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
a relevant transaction with N confirmations)
When transactions occur, the lightweight client updates its wallet (adds the coins).
You don't have to trust the server; it never has your private keys.
Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?
I think then now would be a good point to work out a separate \"server\" and \"client\" for the next release. Those want to run servers that sit on fast fiber connections and run 24/7 (like myself) can do this for the good of the service. Those that just want to send money from point A to point B can use the client which either function as a full blown node server (like it does now) or give the option to connect to \"trusted\" servers in the network and just have the server do the hard work and report back to the client when coins are transfered around properly.
Since the network can be participated by both dedicated server farms and Joe Blow with his laptop, you still maintain the open network and crypto security that you need, but also offer another solution for those less technical and wanting an easy click and send interface that they have now, website payments, etc.
I mean, I'm seeing stories about Bit Coin all over the web now, so the popularity is coming quickly and people are going to poke around the source code and program, then come here to make suggestions/complaints/worship/etc.
Might as well get a head start.
It's win/win because people can run thin clients, people can run servers, and those that don't trust either can run their own client/server/p2p application themself, but it all benefits BitCoin one way or another.
Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.
There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem. Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.
I think Satoshi has done an amazingly fantastic job; over the last two days of Bitcoin being \"slashdotted\" I haven't heard of ANY problems with Bitcoin transactions getting lost, or of the network crashing due to the load, or any problem at all with the core functionality.
Yes, it's annoying to have to wait for the block chain to download (especially with the Microsoft Security Essentials weirdness), and yes it would be nice if all the pieces of Bitcoin functionality were already nicely separated and ready to be rearranged and extended in all the ways we all want to rearrange and extend it. But I've been poking at the Bitcoin code for over a month now, and the more I learn the more impressed I become at the thought that's gone into it.
This quote seems appropriate:
\"We reject: kings, presidents and voting.
We believe in: rough consensus and running code.\" -- David D. Clark
",
"nested_level": 0
},
{
"id": 943,
"thread_id": 85,
"source_id": "26",
"poster_name": "spaceshaker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=371",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2800#msg2800",
"date": "2010-07-14T11:31:16Z",
"text": "Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.
Don't worry much about it until just before it becomes a problem. Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.
I agree with both points but they also seem to be somewhat mutually contradictory to me (this may be because of ignorance more than anything). Perhaps you can illuminate what steps you think need to be taken to \"make it easier for merchants to accept bitcoins and users to pay using them\". In my view, having a lightweight client, build on fairly open standards would facilitate making transactions easier. Ideally this lightweight client would/could be implemented in a number of languages/platforms.
Don't worry much about it until just before it becomes a problem. Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.
This is certainly good advice: \"beware of premature optimization\". I would like to point out though that optimization and system architecture are different beasts. Planning for scalability is a system architecture task. The whole \"Don't overengineer\" paradigm is more of an implementation & design principle and suggests that we should be agile in that we only implement what we need today. An agile perspective does not preclude thinking about and planning out the system architecture, at least testing assumptions mentally and ensuring that \"it could scale\" when the time comes for that ability to be added. I have been involved in a number of projects that failed not because the underlying technology was bad, but because scalability was never considered or tested up front. Everything worked perfectly until the system was put \"to the (scalability) test\". A lack of planning and foresight up-front was usually the cause.
This quote seems appropriate:
\"We reject: kings, presidents and voting.
We believe in: rough consensus and running code.\" -- David D. Clark
I like this quote. There is certainly something to be said for having something that works. I tend to struggle with being a bit of a purist; I have to work at pragmatism. Having said this, you can say: \"we have great software. It has very few bugs and it hardly ever crashes\" and that all sounds well and good until the day it becomes untrue. Scalability issues can hit you quickly and silently, especially in this day-in-age.
My preference would be, for a project like this, would be to continue to have \"working software\" but also establish a well defined road-map of where we hope the software is going. This road map needs to discuss scalability and how we envision a system with a million transactions a day would work and looks, not just today but 20 years from now. A currency needs to be resilient. For people to assign value to Bitcoin they need to perceive that it has value and that it is safe. This means they need to be able to trust that the infrastructure & design is (and will be) perpetually reliable. Unfortunately I don't Bitcoin, if it is to be successful, as the luxury of being just another hacked together open source project (I'm not implying that it is hacky...I'm implying that the prevailing mindset and practice in open source tends to be a \"hack it together\" mind set).
There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem. Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.
He is also talking about a website. The scalability issues with websites are well known and solved and can be easily tacked on as you get bigger. So yeah you don't need to worry about them when you start. bitcoin is a whole new beast.
Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.
It seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs...
Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.
It depends on how it was implemented. I don't think having transaction clearing houses necessarily excludes p2p. It depends on how the network was implemented. Assuming things remained open, the transaction clearing houses could still be p2p. Anybody could join in and work to clear transactions. It's just that it wouldn't be required in order to send/receive transactions. It would actually be extremely beneficial if there were literally thousands of transaction clearing houses or if some regular users did participate in the full system to prevent the established clearing houses from conspiring together to cheat the system. That is one of the beauties of bitcoin IMO.
It seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs...
Although DHT is an interesting concept I don't know if it really solves the problem. Smartphones are a good use case:
- You don't want to be acting as a peer on a p2p network with a smartphone. It hurts battery life and it could be costly in cellular data charges.
- Smartphones don't have the processing power or storage capacity to either process blocks or store even parts of the block chain.
The future is not desktop PCs but is \"thin\" machines like smartphones, tablets and netbooks. These lightweight devices will vastly out-number PCs in the years to come. It isn't tenable to participate in p2p from a thin device, at least in the forseeable future. I think Gavin's ideas of a lightweight bitcoin client seem to address this issue.
Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system.
Why? E-Mail and
Jabber work the same way. Everyone
can run their own server, and many do, but most users prefer to use someone else's server(s).
Edit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a
supernode that then searches for files on your behalf.
Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).
Sure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation? What happens if some attackers start running a cluster of supernodes? The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement.
Edit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a supernode that then searches for files on your behalf.
Yeah and I would argue neither of those systems are very well designed. Limewire replaced the gnutella routing with Kademlia actually.
spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.
Having to download the entire chain also causes issues with new user acceptance. I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain. As time goes on this is only going to get worse. While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.
Say your neighbor wanted to buy something with bitcoins. You tell him to install the program, then go to the exchange and buy some coins. Sounds great, right? How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks? Do you think he would recommend it to his friends? To gain more widespread acceptance, initial transactions would need to overcome this factor.
",
"nested_level": 0
},
{
"id": 949,
"thread_id": 85,
"source_id": "32",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2872#msg2872",
"date": "2010-07-14T16:34:44Z",
"text": "Having to download the entire chain also causes issues with new user acceptance. I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain. As time goes on this is only going to get worse. While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.
Say your neighbor wanted to buy something with bitcoins. You tell him to install the program, then go to the exchange and buy some coins. Sounds great, right? How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks? Do you think he would recommend it to his friends? To gain more widespread acceptance, initial transactions would need to overcome this factor.
I agree, I've been looking into packaging \"blocks\" for download so that you can install the client, unzip a fresh stack of blocks and let the client finish off the rest to get people up and running faster. I'm experimenting with Windows and Linux clients (don't have a Mac that can run the Mac client, sorry folks)
Hopefully that will help with the issue.
Of course, the trust factor comes in (should I download these from this guy instead of letting the network do it for me)
Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).
Sure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation?
Not really. If you're worried, you can always run your very own server.
What happens if some attackers start running a cluster of supernodes?
Nothing. Unless you happen to use one of those supernodes, which you don't have to, because you can run your own supernode. Or use a trusted one, much like people trust Google with their E-Mail.
The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement.
It isn't easier to implement? I'd like to see some proof here.
Counterexample: The
totally distributed E-Mail system developed at Rice University is a hell of a lot more complex than running a (network of) semi-centralized mail server(s).
spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.
Um. That's exactly what a supernode server would do.
I've had luck with testing of packaging blocks into a zip file and dumping them on a new Bit Coin to speed up the block download process. I'll leave the link in my signature and if anyone finds it useful or time saving, feel free to donate.
spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.
Um. That's exactly what a supernode server would do.
Um. Sure. I think I've gone full circle. I think Gavin said it best:
A lightweight client would have a wallet with coins in it (public+private key pairs).
And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.
The lightweight client sends money by:
creating a transaction (signing coins with the private key)
sending the signed transaction securely to the ultra-fast server, which puts it on the network.
receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
(or getting a \"you already spent those coins\" error from the server)
The lightweight client receives money by:
Either polling the server every once in a while, asking \"Any payments to these BC addresses that I have in my wallet?\"
... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
a relevant transaction with N confirmations)
When transactions occur, the lightweight client updates its wallet (adds the coins).
You don't have to trust the server; it never has your private keys.
Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?
In this scenario, the Bitcoin client could remain largely the same as it is today, although the focus would be that it is used on the \"super-nodes\" or \"transaction servers\" or \"proxy servers\" (these systems would probably serve all three roles) or by anyone wishing to play in that game. If the Bitcoin client was augmented to use DHT then that may be improvement but there is still a need for a \"lightweight client\" as Gavin described above. It seem's Gavin's \"lightweight client\" concept obviates my scalability concerns somewhat.
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.
Is this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I'm imagining:
....
you don't even have to imagine , actually it's already possible to \"remote-control\" the node, so just create ur own little lightweight-client, that just sends and gets some info to/from your (highspeed-connected, hdd-packed) homeserver.
some kind of \"managed server-client-version\" already exists in MyBitcoin, you could run something like that on your own webhost and connect to it from wherever u are on whatever connection-speed.
the \"lightweight client\" doesnt have to be one, but connect to it and tell it what todo.
we can do that with JSON.
I second the DHT idea for maintaining a client list - we can't have millions of people relying upon an IRC channel, etc. As far as the scaling issue goes, the issue is not at all HDD space, its network bandwidth. Everyone is forgetting, its not bytes_per_transaction*transactions, which is the number everyone is using. That number, as everyone has said, is fully manageable. No, the number we're interested in is bytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combined
THIS is the amount of bandwidth which the protocol for BTC consumes as the network scales. We're not just talking about sending one copy of each transaction to each client - we're talking about multiple clients broadcasting potentially redundant data to one another, and doing it across numerous hops, meaning numerous rebroadcasts. Much larger number, much more difficult to handle. However, it is manageable, just not in the current incarnation of network handling in the client.
Perhaps in the \"popular\" phase, BTC chains could be broken up by region, similar to the purviews of domain name authorities now - and there could be an alternative protocol for transactions across these regional boundaries? This would help the raw numbers of the problem, and also cut down on latency and related issues. Not that I think this is an excellent solution - but P2P flooding across all active clients is obviously out barring some massive breakthrough in quantum computing or whatnot.
",
"nested_level": 0
},
{
"id": 955,
"satoshi_id": 188,
"thread_id": 85,
"source_id": "38",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Scalability",
"url": "https://bitcointalk.org/index.php?topic=286.msg2947#msg2947",
"date": "2010-07-14T21:10:52Z",
"text": "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 does not need to trust a node to verify payments, it can still verify them itself.
The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.
At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.
",
"nested_level": 0
},
{
"id": 956,
"thread_id": 86,
"source_id": "1",
"poster_name": "Mionione",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=334",
"subject": "Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2293#msg2293",
"date": "2010-07-12T12:04:24Z",
"text": "hi, what would happen if someone sends millions of 0.00000001 BC to millions of address please ?
=> all of the networks peers must store all transactions ?
=> are each 0.00000001 owner/hash stocked in blocks on all peers?
i don't really understand how bitcoin handle fractions of bc
",
"nested_level": 0
},
{
"id": 957,
"thread_id": 86,
"source_id": "2",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2295#msg2295",
"date": "2010-07-12T12:08:45Z",
"text": "From the source code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
Hmm, I didn't realize that was in there, and I really don't like that approach.
That pretty much ruins the possibility of using bitcoin for true micropayments. Wouldn't it be better for clients to just ignore a spammy IP? Sure an attacker could get more, but he couldn't get millions.
",
"nested_level": 0
},
{
"id": 959,
"thread_id": 86,
"source_id": "4",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2319#msg2319",
"date": "2010-07-12T14:45:54Z",
"text": "But how would you distinguish between a legitimate micropayment-processing IP and a spammy \"I want to make Bitcoin use so much bandwidth nobody is willing to run it any more\" IP?
Really small micropayments seem to me to be a really hard problem, and I don't think Bitcoin should try to solve too many very hard problems all at once.
",
"nested_level": 0
},
{
"id": 960,
"thread_id": 86,
"source_id": "5",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2322#msg2322",
"date": "2010-07-12T14:56:11Z",
"text": "Gavin,
It's simple. You will need a fixed component transaction fee, but it will probably be much smaller than that. The fixed component should reflect the true cost to the network of running the transaction. So, the additional bandwidth, latency, etc that the transaction actually costs the network.
Chances are, this will be tiny. I'd guess something like 0.00001 BC, even at the current exchange rate.
",
"nested_level": 0
},
{
"id": 961,
"thread_id": 86,
"source_id": "6",
"poster_name": "Mionione",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=334",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2327#msg2327",
"date": "2010-07-12T15:05:44Z",
"text": "if i send many 0.00000001 BC using a friend node that take no fee (or that send fee back to me).
Will the friend node spead all the transactions over the network?
",
"nested_level": 0
},
{
"id": 962,
"thread_id": 86,
"source_id": "7",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2328#msg2328",
"date": "2010-07-12T15:22:31Z",
"text": "if i send many 0.00000001 BC using a friend node that take no fee (or that send fee back to me).
Will the friend node spread all the transactions over the network?
The fee is paid to whoever generates the block that the transactions are in, and that's random.
Your friend could run a node that refunds the fee, but unless your friend can convince a lot of other people to run nodes that do the same thing you're almost certainly going to end up paying the fee.
Remember that all transactions (even payments from you to your friend) are broadcast across the payment network; they HAVE to be, because if they weren't you could spend the same coins twice without getting caught.
so the fee must be the same for all nodes isn't it ?
do the nodes reject other nodes that doesn't apply the same fee?
if not, there is no way to wait/find a node that apply a lower fee?
",
"nested_level": 0
},
{
"id": 964,
"thread_id": 86,
"source_id": "9",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2342#msg2342",
"date": "2010-07-12T16:50:59Z",
"text": "You can send a billion small transactions, it doesn't slow anything down, except the user interface because you end up with a ton of items in the list. Just go ahead and try it, see for yourself.
All of the transactions are included by nodes that are attempting to generate the next block and only the header is hashed so it is not harder to generate a block that represents a million transactions than it is to generate a simple coinbase only. This is what the confirmations are, blocks that include your transaction.
",
"nested_level": 0
},
{
"id": 965,
"thread_id": 86,
"source_id": "10",
"poster_name": "bencoder",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=243",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2399#msg2399",
"date": "2010-07-12T22:10:51Z",
"text": "I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.
If there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms.
",
"nested_level": 0
},
{
"id": 966,
"thread_id": 86,
"source_id": "11",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2400#msg2400",
"date": "2010-07-12T22:14:50Z",
"text": "I think a 0.01 BTC minimum send is fine for now. At the current exchange rate, that's 8/1000 of a penny USD, or 80 millionths of a dollar. Any micropayment smaller than that would not be made one at a time. If, for example, you wanted to charge 0.001BTC for something, you could just charge 0.01 and keep a balance.
If bitcoins become much more valuable, we can change this and push out a new version.
",
"nested_level": 0
},
{
"id": 967,
"thread_id": 86,
"source_id": "12",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2407#msg2407",
"date": "2010-07-12T22:30:20Z",
"text": "I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.
If there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms.
Ideally, you raise the ceiling in this situation. Right now, there is a 21 million coin limit. So as the value goes up, so does the ceiling so to speak. Unless one person has 20 million bitcoins and the rest of the world has to trade with 1 million, there should be no reason go in the opposite direction for the value to value comparison. But I do understand exactly what you mean though because some world currency is traded like that where 1 unit of XYZ country equals 20,000 of another, so small decimal values have to be used.
Since the transaction fee can't get below 0.01, the value should always be greater than the fee, otherwise, people are not making any financial sense. It would be like living in a city where it cost $10.00 to drink from a water fountain. The business model should fail in light of free, public water fountains outside, so who would bother to pay that much money when the alternative makes more financial sense.
Same way with the 0.01 fee limit, people already expect it and won't value things beneath it as it wouldn't make financial sense. If the lowest possible fee is 0.01, why would anyone sell anything for less than that? You would put yourself out of business quickly.
If I understand the workings of the system correctly, clients on the network are broadcast the details on the new transactions coming in. If a given client is generating they take any transactions they have seen come into them, bundle them into a \"trial block\" (along with a new 50 BTC token for themselves) and then commence trying to find a nonce which hashes this block to something below the target value.
Since blocks with more transactions in them will take longer to hash, the flood of small payments would make the client work harder before it solves a block. What if we change the transaction format from the current \"123 wants to send X coins to 456\", to be something like \"123 wants to send X coins to 456 and will pay Y coins to whomever solves the block containing this transaction\".
Then each client sets their own minimum transaction fee (which defaults to 0). If they receive new transaction from someone, they check that the fee is greater than or equal to their own minimum transaction fee. If the fee is high enough they will add the transaction to the pool of transactions they are trying to find a solution for. If not, they will just ignore the update (still forwarding it on to others though so the network still functions). When they add the transaction they will really add it as 2 parts, the X coins from 123 to 456, and a second transaction of 123 to themself.
This allows for the creation of a \"processing market\" and allows the fee to be set by the market itself. Some people will be willing to solve blocks for free and will include any transaction they are sent. Other clients will set a very high fee and only try to solve the few that meet this fee. In this way transactions with higher fees get \"priority\" processing since they will be included in more nodes calculations. People who don't want to pay a transaction fee can still put packets out and they will eventually be solved but will take longer because some nodes won't work on them.
This allows the transaction fee to move up and down with the value of bitcoins and it also gives people an incentive to keep running the program after new blocks are not generating bitcoins (as they will be 20 years from now).
-Buck
",
"nested_level": 0
},
{
"id": 969,
"thread_id": 86,
"source_id": "14",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg2905#msg2905",
"date": "2010-07-14T18:31:31Z",
"text": "Since blocks with more transactions in them will take longer to hash, the flood of small payments would make the client work harder before it solves a block.
This is not quite right. The block header that is being hashed is a constant size no matter how many transactions the block contains.
So blocks with more transactions in them should still take the same amount of time to hash.
The rest is correct and insightful though.
From the source code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
I added this little tidbit into my IRC bot:
According to
http://is.gd/dsqcH the world population is 6,855,986,675. If everyone had the same amount of bitcoins, everyone would have 0.00306302 bitcoins. If 0.00000001 bitcoins were equivalent to US$0.01, then everyone would have equivalent of US$3,063.01645489 and the value of all bitcoins would be equivalent of US$21,000,000,000,000.00.
How would the BTC0.01 fee affect things considering above?
By the time everyone has Bitcoins, the fee will have been removed or adjusted.
",
"nested_level": 0
},
{
"id": 972,
"thread_id": 86,
"source_id": "17",
"poster_name": "melvster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=545",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg4728#msg4728",
"date": "2010-07-21T13:57:44Z",
"text": "From the source code:
main.h: // To limit dust spam, require a 0.01 fee if any output is less than 0.01
Would love to see this value at 0.001 rather than 0.01
What would happen if someone modified their client to not offer to pay the fee, and also modified their client to not require the fee?
Here's my best guess:
* They generate a 0.00000001 BC payment (but don't include the fee)
* This transaction goes to the clients peers
* The peers don't include it in the block they are solving since fee not paid.
* Do the peers still pass the transaction along to the rest of the network?
* A block gets solved without the transaction in it
* client notices its transaction wasn't in the block and re-broadcasts the transaction?
* eventually client solves a block itself and that transaction is included in it so it goes out to the rest of the network
",
"nested_level": 0
},
{
"id": 974,
"thread_id": 86,
"source_id": "19",
"poster_name": "nenolod",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=566",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg5200#msg5200",
"date": "2010-07-23T05:03:00Z",
"text": "That pretty much ruins the possibility of using bitcoin for true micropayments.
I do not see how it does that. 1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.
Does paying the \"fee\" require the use of the \"pay to anyone\" signature I read about in another thread?
",
"nested_level": 0
},
{
"id": 976,
"thread_id": 86,
"source_id": "21",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg5270#msg5270",
"date": "2010-07-23T13:39:41Z",
"text": "Hi.
That pretty much ruins the possibility of using bitcoin for true micropayments.
I do not see how it does that. 1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.
Micropayment is less that 0.01 $, I suppose.
Having an (economically) effective implementation of micropayment system will affect the way current economics works.
For example, it may make the media producer's business unprofitable in some areas, I suppose.
So, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.
But that system still does not exists
![\"Sad\"](\"/static/img/emoticons/sad.gif\"/)
Hi.
That pretty much ruins the possibility of using bitcoin for true micropayments.
I do not see how it does that. 1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.
Micropayment is less that 0.01 $, I suppose.
Having an (economically) effective implementation of micropayment system will affect the way current economics works.
For example, it may make the media producer's business unprofitable in some areas, I suppose.
So, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.
But that system still does not exists
You can do it if you have a system of micropayments with the CASH OUT in bitcoins. That way most transactions will not go through the bitcoin system.
I think it's very important that the transaction fee reflect no more than the true cost that the transaction causes the network.
Micropayments can be useful even if they're very very tiny. Imagine a lightbulb that sends a little ping bitcoin charge for every millisecond it's turned on. There are countless applications for tiny tiny payments.
",
"nested_level": 0
},
{
"id": 979,
"thread_id": 86,
"source_id": "24",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7443#msg7443",
"date": "2010-08-04T06:22:56Z",
"text": "Well, right now nothing stops someone from creating a system where:
A sends 1.00000001 to B
B sends 1.00000000 back to A
Net result is a micro-payment and no processing fee. I am creating a system that does something very similar to the above. The reality is that any \"micro-payment\" system should probably be handled outside the BTC block and have the payments \"summed up\" before being sent.
I think the processing fee design is brilliant. Every node can pick and choose which transactions it wants to include and thus the \"time until included\" is directly proportional to the number of nodes who accept your \"offer\". Worst case you have to wait until your lonely PC can create a block which at the moment could be weeks!
In fact, I think it would be reasonable to offer to pay the nodes that propagate your transaction if there was some way to \"enforce it\" and prevent rouge clients from collecting fees but not doing work.
",
"nested_level": 0
},
{
"id": 980,
"thread_id": 86,
"source_id": "25",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7454#msg7454",
"date": "2010-08-04T11:58:58Z",
"text": "Well, right now nothing stops someone from creating a system where:
A sends 1.00000001 to B
B sends 1.00000000 back to A
Net result is a micro-payment and no processing fee.
... unless B started with zero bitcoins. Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).
... unless B started with zero bitcoins. Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).
Surely this is not correct?
The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.
The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.
The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":
main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":
Since there is no way to tell which is the 'change' transaction.
That's kinda cool.
(and somewhat horrible at the same time.)
The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.
The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":
main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
Wow, ok this needs to go or it becomes impossible to do micropayment systems. For example, I am trying to build an automated system you \"pay per packet\" sent across a P2P network. Payments would generally be advanced, say 1 BTC at a time and when the connection closes any \"change\" would be returned. This rule makes it impossible to pay for a simple \"search query\" with no further transactions. I suppose that I would have to release the P2P program with its own BTC client that does not have this rule. It would take longer for transactions to post, but in theory if all clients are mining then you would still have a good chance of getting the payment in.
What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.
",
"nested_level": 0
},
{
"id": 986,
"thread_id": 86,
"source_id": "31",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7500#msg7500",
"date": "2010-08-04T15:02:02Z",
"text": "
What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.
There are builds that remove this limit, mainly for testing right now, I think that's why it's disabled until it can be tweaked a little more.
What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.
Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.
A better solution would be to deprioritize transactions below 0.01 and completely drop them if there are more than 10,000 (or whatever) in the queue. Then these transactions would be slower and less reliable than other transactions, but they would work and not interfere with \"real\" transactions.
priority is all contingent upon how many nodes accept them. Thus if only 1% of the nodes accept a transaction fee of 0.000001 btc then you will have a 1% chance of being included in the next block. If all nodes accept transaction fees of 1BTC then you have near 100% chance of being in the next block.
",
"nested_level": 0
},
{
"id": 989,
"thread_id": 86,
"source_id": "34",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7521#msg7521",
"date": "2010-08-04T16:11:55Z",
"text": "What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?
Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.
Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
Bitcoin isn't practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, certainly not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.
Why not?
I don't see how size would make a difference.
Is it just due to the number of transactions that the system is able to handle?
User sends you 1.005 bc's, you send them back 1. Is a fee charged in that scenario? Because the change coming back to you would be .005?
Yes, this was covered above.
The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":
main.h:
foreach(const CTxOut& txout, vout)
if (txout.nValue < CENT)
nMinFee = CENT;
In your scenario there are two outputs, 1 is 1 BTC and the other is 0.005 BTC.
0.005 < 0.01 therefore a fee applies to the transaction.
Can the fee rules be arbitrarily complicated? And is the size limit hard wired or completely up to the node?
Does including more slow down your hashing rate?
",
"nested_level": 0
},
{
"id": 994,
"thread_id": 86,
"source_id": "39",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7674#msg7674",
"date": "2010-08-05T14:52:32Z",
"text": "What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?
Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.
Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?
I'd like to repeat that question. Why could someone with 1 bc, not just send it back and forth between accounts a billion times? No fees would be charged.
Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.
Only if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Well, right now nothing stops someone from creating a system where:
A sends 1.00000001 to B
B sends 1.00000000 back to A
Net result is a micro-payment and no processing fee.
... unless B started with zero bitcoins. Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).
ok if a and b both start out with 1 BTC and agree to transfer 0.0001 using two inputs and two outputs on a single transaction can change a to 0.9999 and b to 1.0001. The rest of the network it would seem would accept the transaction.
The only stumbling block is whoever creates the transaction needs the private keys for both inputs which would come from different wallets normally. The one who creates the transaction could cheat.
Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.
Why isn't it practical? I agree that a good micropayment system would avoid generating thousands of transactions (e.g. one per packet), but that doesn't mean that bytemaster's change idea is wrong:
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any \"change\" would be returned. This rule makes it impossible to pay for a simple \"search query\" with no further transactions.
That seems like a great use case. Furthermore, as llama said, the fixed component of a transaction fee should always represent the real cost of including that transaction in a block. So, are there any more intelligent and less painful ways of implementing anti-dust spam systems?
I think the current system works fine. If someone wants to implement a micro-payment system then they will have to host enough nodes and contribute enough processing power to include their small transactions. I see no reason to require any node to accept or forward micro-payment transactions if said nodes does not wish to.
The real issue is that even a simple legitimate automated micro-payment system could overload bitcoin by introducing more transactions than the credit card system currently uses. The net result is that block sizes could become HUGE.
In my use case you have a P2P system where they pay for priority downloads. Assume you have a single \"torrent\" file with 100,000 people all seeding and downloading. That could easily generate 100,000 micro-payments per minute. Now clearly, the program would only have to use BTC in the event that upload != download between two clients.
It would be distributed and thus there would be no easy way to identify \"spam\" from legitimate usage. Even using my solution of transferring 1+ BTC at a time and giving change if the balance is greater than 0.01 could cause a transaction bloat writ large.
I suspect that the \"cost\" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those little transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.
The only solution to this problem is to make broadcasting of a transaction \"non free\". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.
The implication is that you may not even receive notice of payment until a node that you paid to receive your transaction and *attempt* to integrate it into a block manages to do so. This means that you would not even see 0/unconfirmed and that a transaction must make it into a block before anyone that wasn't paid to *attempt* to integrate it even knows it exists.
This structure would encourage pay-to-ip systems because that make the receiver of the payment responsible for paying to get it integrated. Either they run their own bitcoin generators *or* they pay to send the transaction to someone who is.
",
"nested_level": 0
},
{
"id": 998,
"satoshi_id": 318,
"thread_id": 86,
"source_id": "43",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7687#msg7687",
"date": "2010-08-05T16:03:21Z",
"text": "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 may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
I am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)
If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.
That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically.
Does including more slow down your hashing rate?
No, not at all.
Payments would generally be advanced, say 1 BTC at a time and when the connection closes any \"change\" would be returned. This rule makes it impossible to pay for a simple \"search query\" with no further transactions.
One alternative is to use a round-up system. You pay for, say, 1000 pages or images or downloads or searches or whatever at a time. When you've used up your 1000 pages, you pay for another 1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.
Or you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.
Per 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it's harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.
Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.
Only if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Improved attack would be : start with 1BTC then transfer 0.999999999BTC, then 0.999999998BTC, ...
It results 1 million accounts (minus 10000) with 0.000000001BTC each.
The only solution to this problem is to make broadcasting of a transaction \"non free\". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.
I don't know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?
The transaction fee transaction would be designed to be a completely predictable consequence of the main transaction and hopefully any fee for processing the main transaction would also take into account the need for a fee transaction too. In other words the fee transaction would contain its own fee. This therefore seems to be a manageable aspect of the problem.
ByteCoin
Right now the transaction fee address is left \"blank\" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.
If the transmit fee <= block integration fee no one could profitably forward the transaction and thus must generate a block themselves.
",
"nested_level": 0
},
{
"id": 1004,
"satoshi_id": 324,
"thread_id": 86,
"source_id": "49",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7710#msg7710",
"date": "2010-08-05T17:49:43Z",
"text": "Right now the transaction fee address is left \"blank\" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.
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 needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won't relay them to you. It probably won't be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying.
The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction. In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway. The tip would be below the amount that would allow said user to \"rebroadcast\" their transmit fee. So you don't get recursive transmit fees.
Say I want to send .001 BTC to Fred. The cluster is operating at 1billion k/hash/second, then I need to distribute my transactions to enough nodes so that the k/hash/second % of the total is acceptably high for the transaction to get logged within the next N blocks.
So generating nodes A, B, and C each price their transmit fee proportional to their khash rate. (how do they prove their khash rate? total blocks generated over time?)
So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A. I send a different one to B and C.
Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.
The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.
",
"nested_level": 0
},
{
"id": 1006,
"thread_id": 86,
"source_id": "51",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg7727#msg7727",
"date": "2010-08-05T19:43:02Z",
"text": "Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.
Only if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?
Can the line be moved down slightly? Any bad side-effects if it was?
So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A. I send a different one to B and C.
Now A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.
The trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.
I'm thoroughly confused on what, exactly, you're proposing.
I want to make a 100 Bitcoin transaction to you.
You're proposing that I need to pay a \"transmit fee\" ... which is paid to who and does what, exactly?
If I pay it to A, B, and C, does that mean they rebroadcast the transaction to everybody they're connected to? Do they, in turn, pay transmit fees to the nodes they're rebroadcast it to? What stops them from saying \"Thank you very much for the transmit fee\" and cheating (drop my transaction on the floor)?
Satoshi's proposal that all transaction carry a minimum fee to cover network overhead makes sense; whoever generates the block with the transaction gets the fee.
Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.
Only if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.
Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?
Can the line be moved down slightly? Any bad side-effects if it was?
I don't think you understood, it's nothing to do with the size of the transaction. it's the way transactions get split up. If you start with 1 BTC and send 100 x 0.01 transactions to your friend thats 100 transaction chains one step long. He may or may not combine them back together into a single 1BTC transaction but untill he does the net must keep all 100 transactions stored.
If you start with the same 1BTC or 0.01BTC or any single amount and pass it back and forth to your friend 100 times. Its a similar amount of traffic and storage at first but once the last one gets deeply confirmed (ie 6 blocks/1 hr later) you can forget/delete from your disk database all the transactions but the last one. It's the Merkle hash tree pruning stuff in the white paper.
Are:
1) The transaction fees charged entirely up to the block processing node?
Or
2) The transaction fees enforced by the network, which would mean that any block that contains an 'invalid' transaction because it did not include the correct fee would be rejected?
",
"nested_level": 0
},
{
"id": 1010,
"thread_id": 86,
"source_id": "55",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg8508#msg8508",
"date": "2010-08-10T10:13:30Z",
"text": "Does that mean, that my abilities to DDoS the entire Bitcoin network are only limited by my BTC
bying power? And not by the number of my network connections, nodes, etc?
BTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.
I suppose, we should caution the other users...
",
"nested_level": 0
},
{
"id": 1011,
"thread_id": 86,
"source_id": "56",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Flood attack 0.00000001 BC",
"url": "https://bitcointalk.org/index.php?topic=287.msg8541#msg8541",
"date": "2010-08-10T14:53:41Z",
"text": "BTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.
I suppose, we should caution the other users...
You should use the
Test networkBTW, let's test the network someday?
It is trivial to automate the process of sending small transactions to the list of known addresses.
Let's abuse the network and know the effect precisely.
I suppose, we should caution the other users...
You should use the
Test networkTest network have test scale.
Hmm, I think the other guys may not ask your permission to abuse the real network next time.
They will just do it.
I'm sure, the Bitcoin is useless if it is vulnerable to such a simple intrusion.
We should prove, that it is sustainable to real world threats.
Like me Perhaps somebody just experimented already?
It would be nice to keep the blk*.dat files small as long as we can.
The eventual solution will be to not care how big it gets.
But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore.
There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI.
Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.
",
"nested_level": 0
},
{
"id": 1014,
"thread_id": 87,
"source_id": "1",
"poster_name": "hubdawg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=340",
"subject": "Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2320#msg2320",
"date": "2010-07-12T14:47:00Z",
"text": "Just got started with bitcoin. I followed the directions. Forwarded the port. Had quite a few connections up to 40 at one time. I wake up this morning and I see I have 12 connections. ANd five errors saying this bitcoin was generated but not received by any other nodes. I gave bitcoin access through the firewall and allowed an exception. I am running Windows 7 64 bit. Any ideas?
BC: 1KDwVb4udipVSYLgRPWg9GiFiKJpXBFPHg
",
"nested_level": 0
},
{
"id": 1015,
"thread_id": 87,
"source_id": "2",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2335#msg2335",
"date": "2010-07-12T16:18:22Z",
"text": "Does it really say, that the bitcoins could not get received or does it say the transaction is still unconfirmed ?
Don't worry about the second case, it just means that the bitcoins have to get confirmed by the other nodes.
This happened after 120 blocks in the old bitcoin version (0.2). I`m not sure about the amount of block on 0.3.
If they really couldn't get received I can't give you an advice, this is above my knowledge, but I'm sure the other forum members are able to help you with that
Well I restarted the computer and the logs are now cleared. My connection count is low at the moment. I have 11 connections. About an hour after I installed it yesterday I had around 40 connections. I am not sure what is happening. I wonder if my isp is blocking the traffic. If it looks like bittorrent traffic they may be blocking it. I am so fed up with isp thinking they can control what I do on the internet.
",
"nested_level": 0
},
{
"id": 1017,
"thread_id": 87,
"source_id": "4",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2339#msg2339",
"date": "2010-07-12T16:40:59Z",
"text": "It is normal for some blocks not to be accepted. One connection is enough, the others are just redundant. The client will make 8 outbound connections but will accept all inbound connections (on port 8333).
The blocks are generated in sequence so if two nodes happen to generate at almost the same time there will be a collision and one or the other will win. If the current block count is 5000 and your node finds a suitable block 5001, but meanwhile some other node already created a 5001 and your node just didn't know because it's on a laggy connection possibly, your block won't be valid and you have to start searching for 5002. I think this is explained in the pdfs, I'm not sure.
Are you seeing a lot of these happen or was it just one?
",
"nested_level": 0
},
{
"id": 1018,
"thread_id": 87,
"source_id": "5",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2340#msg2340",
"date": "2010-07-12T16:42:09Z",
"text": "Sorry I misread, it's possible that you just weren't connected properly and it couldn't broadcast a transaction, what was the exact wording of the message? Can you include a screen shot? I might have been describing a different problem than you were having especially if it cleared up after restarting..
",
"nested_level": 0
},
{
"id": 1019,
"thread_id": 87,
"source_id": "6",
"poster_name": "hubdawg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=340",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2341#msg2341",
"date": "2010-07-12T16:47:26Z",
"text": "It had 5 in a row... saying Warning: This block was not received by any other nodes. I did not get a screen shot I should have though. I will keep an eye on it. If it happens again I will get the SS and post it in this thread. I am concerned though if this app generates bittorrent type traffic my isp may be interfering with it.
",
"nested_level": 0
},
{
"id": 1020,
"thread_id": 87,
"source_id": "7",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2343#msg2343",
"date": "2010-07-12T16:54:45Z",
"text": "You could try using tor maybe and see if that works better, though it will increase your latency even more.
",
"nested_level": 0
},
{
"id": 1021,
"thread_id": 87,
"source_id": "8",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2396#msg2396",
"date": "2010-07-12T21:51:50Z",
"text": "This kind of error has only happened to me once, but I'm on a low latency connection at my Uni. Typically it occurs, like Laszlo said, when another node solves the next block and you don't receive it before you transmit your own connection.
It could be due to a whole number of things, but a bad internet connection is probably the first thing to look at.
",
"nested_level": 0
},
{
"id": 1022,
"thread_id": 87,
"source_id": "9",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2402#msg2402",
"date": "2010-07-12T22:16:37Z",
"text": "Since it's happening so frequently (you shouldn't get more than two generations per day normally with the current difficulty), you probably haven't downloaded the entire block chain. There are 66145 blocks as I write this; how many do you have (lower right in BitCoin's UI)?
If you're running Microsoft Security Essentials, you need to add BitCoin as an exception for blocks to be downloaded at a reasonable speed.
",
"nested_level": 0
},
{
"id": 1023,
"thread_id": 87,
"source_id": "10",
"poster_name": "ksd5",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=311",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2460#msg2460",
"date": "2010-07-13T02:27:55Z",
"text": "My friend got the same error. He has about 1600 khash/s, 48 connections, but only 3 blocks.
",
"nested_level": 0
},
{
"id": 1024,
"thread_id": 87,
"source_id": "11",
"poster_name": "hubdawg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=340",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2471#msg2471",
"date": "2010-07-13T03:29:42Z",
"text": "I am at the moment at 1046 khash/s 12 connections 66331 blocks. I am on 10mb Newwave cable in west kentucky. My internet is very fast pretty much all the time. I average good speeds. Still waiting to see if I get those errors again.
",
"nested_level": 0
},
{
"id": 1025,
"thread_id": 87,
"source_id": "12",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2482#msg2482",
"date": "2010-07-13T04:02:37Z",
"text": "Basically anything that's generated while the node doesn't have all the blocks just ends up being rejected because it would fall in the middle of the block chain not at the end (but your node thought it was at the end because it didn't know there were a lot more blocks). The blocks are small but it takes a while for your computer to validate each one so that's why the initial download takes a while. I'm not exactly sure why it's taking so long for some people, maybe it's because the database is flushed to disk constantly and some kind of antivirus is scanning every file write, but it takes about 10 minutes for me to get it all back if I remove my data directory.
",
"nested_level": 0
},
{
"id": 1026,
"thread_id": 87,
"source_id": "13",
"poster_name": "hubdawg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=340",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2485#msg2485",
"date": "2010-07-13T04:08:27Z",
"text": "The only antivirus I use is Microsoft security essentials. I don't know if that is any help. I am running a Core2Duo 3ghz with 2gb of ram on Windows 7 64bit. Just a few of my stats.
",
"nested_level": 0
},
{
"id": 1027,
"thread_id": 87,
"source_id": "14",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2487#msg2487",
"date": "2010-07-13T04:19:17Z",
"text": "Would be interesting to see if you get better results without it - someone else reported trouble with that until they added an exception for the %APPDATA%/Bitcoin directory.
",
"nested_level": 0
},
{
"id": 1028,
"thread_id": 87,
"source_id": "15",
"poster_name": "hubdawg",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=340",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2490#msg2490",
"date": "2010-07-13T04:22:16Z",
"text": "I did add an exception for it as I noticed someone else had in the forum.
",
"nested_level": 0
},
{
"id": 1029,
"thread_id": 87,
"source_id": "16",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2661#msg2661",
"date": "2010-07-13T21:52:33Z",
"text": "Make sure you add bitcoin.exe to the \"Excluded processes\" list, not only files for scanning.
See this thread:
http://bitcointalk.org/index.php?topic=35.0I submitted bitcoin to the MS Security Essentials developers back then with explanation of the problem. They responded they would check the performance concerns, but I don't know what they've made of it.
Okay I am not sure if I should add this here. But It has been a bit over three days since I installed and have had bitcoin running 24hrs a day. The first day in under 15hours it had generated some progress and sent out the 5 failed transactions. Now it has been approximately 72 hours. There has been no activity at all. My client reports that it is working on the current block as noted by the page someone here setup to show the length of the current computations. Is this common can it take days and weeks to generate even one bitcoin. I am not a programmer at all. I read the whitepaper and other stuff but much of it just evades me.
",
"nested_level": 0
},
{
"id": 1031,
"thread_id": 87,
"source_id": "18",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2858#msg2858",
"date": "2010-07-14T15:57:32Z",
"text": "u can't generate just 1coin,
u'll get 50coins for completing 1block, or you dont get them if someone else was quicker.
a few days ago i was able to generate 50coins in less than a day, but the difficulty to create a block tripled since slashdot and so did the time to generate coins.
so yes, its pretty usual to take \"forever\" to generate a coin, at least expect it to take a few days, to get your first 50coins,
depending on how much cpu-power u'v got to spare.
",
"nested_level": 0
},
{
"id": 1032,
"satoshi_id": 186,
"thread_id": 87,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Warning this block was not received by any other nodes",
"url": "https://bitcointalk.org/index.php?topic=291.msg2913#msg2913",
"date": "2010-07-14T18:56:29Z",
"text": "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 make bitcoin.exe an excluded process in Live Protection.
This is becoming a common problem. Someone should write this up in a pegged thread.
The message \"Warning: This block was not received by any other nodes\" occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it.
",
"nested_level": 0
},
{
"id": 1033,
"thread_id": 88,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Donations to freebitcoins.appspot.com needed!",
"url": "https://bitcointalk.org/index.php?topic=295.msg2365#msg2365",
"date": "2010-07-12T19:15:46Z",
"text": "The Bitcoin Faucet is handling the slashdotting really well... except that I'm running out of coins to give away. over 5,000 have flowed out of the Faucet since I refilled it last night.
Any of you early adopters who generated tens of thousands of coins back in the early days, are you willing to send a few to the Faucet to be given away so more people can try out Bitcoin? I know that most of them are likely to be lost (I suspect there a lot of slashdot lookey-loos who won't stick around long enough to spend their 5 bitcoins), but if that's the case then that'll just increase the value of your other bitcoins, anyway...
Fountain donation address is: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC
Depending on donations and how long the slashdotting lasts, I might have to start giving away bitnickels...
",
"nested_level": 0
},
{
"id": 1034,
"thread_id": 88,
"source_id": "2",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Donations to freebitcoins.appspot.com needed!",
"url": "https://bitcointalk.org/index.php?topic=295.msg2453#msg2453",
"date": "2010-07-13T01:57:24Z",
"text": "Thanks for the donations... whoever you are who donated!
The Faucet has about 2,000 coins in it at the moment; I just deployed a new version that will automatically start giving out bit-nickels if the balance falls below 500 (but allows anybody who gets a bit-nickel to come back later and get the 5 bitcoins \"they deserve\" if/when the Faucet is refilled).
",
"nested_level": 0
},
{
"id": 1035,
"thread_id": 88,
"source_id": "3",
"poster_name": "XaviorPenguin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=366",
"subject": "Re: Donations to freebitcoins.appspot.com needed!",
"url": "https://bitcointalk.org/index.php?topic=295.msg2705#msg2705",
"date": "2010-07-14T01:05:41Z",
"text": "You can have the 5 you gave me back. I just wanted to see how this all works and all and hopefully, I will have some coins popping up every couple of days.
Thank you for running a great program/incentive! I appreciate it!
Thanks Xavier!
To everyone else: the Faucet is now giving out bit-nickels; it just went under 500 BTC. I've got just under 2,000 BTC left to refill it, but I think I'll start letting it drain a nickel-at-a-time and keep it above zero for as long as I can (refilling it to just under 500 if it gets near zero).
",
"nested_level": 0
},
{
"id": 1037,
"thread_id": 88,
"source_id": "5",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Donations to freebitcoins.appspot.com needed!",
"url": "https://bitcointalk.org/index.php?topic=295.msg2847#msg2847",
"date": "2010-07-14T15:30:03Z",
"text": "i send my 5 coins back right after i got them,
was a great way to check our system and still is a great way for new \"potential customers\", to test us.
regrettably i havent been around back in those early days, but i'll gladly send all incoming 5coin credits back to you.
5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.
This is an important service so new users can at least get something if generating is too hard.
",
"nested_level": 0
},
{
"id": 1039,
"thread_id": 89,
"source_id": "1",
"poster_name": "chupacabra",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=350",
"subject": "Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2367#msg2367",
"date": "2010-07-12T19:27:30Z",
"text": "I get this when trying to run bitcoin:
[michael@fed13 64]$ ./bitcoin
./bitcoin: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
Fedora 13 uses this:
/lib64/libcrypto.so.1.0.0a
How can I get around this?
I tried a symlink and running ldd and ldconfig to no avail.
Thanks
",
"nested_level": 0
},
{
"id": 1040,
"thread_id": 89,
"source_id": "2",
"poster_name": "diven",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=353",
"subject": "Re: Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2369#msg2369",
"date": "2010-07-12T20:05:15Z",
"text": "I am having the same issue on Slackware64 13.1.
",
"nested_level": 0
},
{
"id": 1041,
"thread_id": 89,
"source_id": "3",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2567#msg2567",
"date": "2010-07-13T15:26:15Z",
"text": "I am having the same problem on Fedora 12 32-bit, which also uses libcrypto.so.1.0.0a.
As chupacabra says, a symlink doesn't help because the different library versions contain different symbols.
",
"nested_level": 0
},
{
"id": 1042,
"thread_id": 89,
"source_id": "4",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2578#msg2578",
"date": "2010-07-13T17:09:31Z",
"text": "I too am having issues running it. Same error as above.
Does anyone know how to build it from source on F13? If we could do that, it should work just fine with the new module.
",
"nested_level": 0
},
{
"id": 1043,
"thread_id": 89,
"source_id": "5",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2585#msg2585",
"date": "2010-07-13T17:27:28Z",
"text": "If you're ok with hacking the makefile to update your paths and such, try looking these notes I took to get you started:
http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdfI would hope some real developer fixes this so Fedora and Slackware users can use it. No telling what other distros it fails on. What was it built on? I'm guessing Ubuntu/Debian which in my opinion is the most broken fork existing.
Please guys. Help us out.
Thanks.
I'm having my wedding today so I dont have time to code.
Mazel tov!
Don't be hatin' on Ubuntu though. It's a good OS, and it's helping to drive Linux adoption in the home.
Try building yourself when you get some free time on the honeymoon!
Alternatively, try this build: (x86_64 only, sorry)
http://www.alloscomp.com/bitcoin/bitcoin-r102Second confirmation that this is the WORKING build for Fedora 13.
Thanks!
Thanks for the link to that binary.
Unfortunately it doesn't work for me. The bash shell gives a \"cannot execute binary file\" error.
I guess bitcoin-r102 is a 64-bit binary, and I'm running 32-bit Fedora.
",
"nested_level": 0
},
{
"id": 1049,
"thread_id": 89,
"source_id": "11",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: Fedora 13 libcrypto",
"url": "https://bitcointalk.org/index.php?topic=296.msg2664#msg2664",
"date": "2010-07-13T22:14:26Z",
"text": "Thanks for the link to that binary.
Unfortunately it doesn't work for me. The bash shell gives a \"cannot execute binary file\" error.
I guess bitcoin-r102 is a 64-bit binary, and I'm running 32-bit Fedora.
True. This is only a 64-bit binary.
If no one else gets a binary uploaded tonight, I will try my hand at building one tomorrow morning.
... I will try my hand at building one ...
I'll pledge my first hundred bitcoins to anyone who can post a 32-bit Fedora version. I'd pledge more, except I don't know how many I'll be able to generate. Perhaps other 32-bit Fedora users can add their pledges to mine.
Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:
http://bitcointalk.org/index.php?topic=383.0Let me know if that works.
I tried building it myself but it didn't compile.
Which ports did you use?
I tried with wxgtk28-unicode and db42-4.2.52_5 & db50-5.0.21.0
Here the latest attempt:
nagilum@cakebox ~/src > uname -a
FreeBSD cakebox.tis 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Tue Jun 29 22:25:46 CEST 2010 root@cakebox.tis:/usr/obj/export/src/sys/net5501 i386
nagilum@cakebox ~/src > gmake -f makefile.unix
g++45 -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.8\" -I\"/usr/local/include/db50\" -o headers.h.gch headers.h
In file included from headers.h:108:0:
ui.h:13:142: error: default argument for 'const wxString& caption' has type 'const char [8]'
ui.h: In function 'int MyMessageBox(const wxString&, const wxString&, int, wxWindow*, int, int)':
ui.h:19:51: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'
/usr/local/lib/gcc45/include/c++/bits/basic_string.tcc:219:5: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
/usr/local/lib/gcc45/include/c++/bits/basic_string.tcc:212:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]
...
",
"nested_level": 0
},
{
"id": 1053,
"thread_id": 90,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Building Bitcoin 0.3",
"url": "https://bitcointalk.org/index.php?topic=298.msg2374#msg2374",
"date": "2010-07-12T20:42:10Z",
"text": "Looks like your wxWidgets and STL - you should compile your own wxWidgets from the 2.9 release.
Use something like this to configure it and adjust the reference paths in your makefile.unix
mkdir buildgtk
cd buildgtk
../configure --prefix=/home/my_user/bitcoin/deps \\
--with-gtk \\
--disable-shared \\
--disable-debug_flag \\
--enable-stl \\
--enable-utf8 \\
--with-libjpeg=builtin \\
--with-libpng=builtin \\
--withregex=builtin \\
--with-libtiff=builtin \\
--with-zlib=builtin \\
--withexpat=builtin
It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet.
",
"nested_level": 0
},
{
"id": 1055,
"thread_id": 91,
"source_id": "1",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2378#msg2378",
"date": "2010-07-12T20:59:16Z",
"text": "I did a forum search, didn't see this mentioned by anyone yet.
I have 5 Bit Coin clients, some running Windows Bit Coin, others running Linux Bit Coin.
I only have one 64 bit Linux system, but when I run Bit Coin, after about 10 minutes, the CPU usage runs away and brings the system to a stall unless I kill the Bit Coin application.
Now I have 2 other computers running a 32 bit Linux Bit Coin client and they work just fine, no runaway CPU.
I've tried running the 32 bit Bit Coin on the 64 bit Linux system, but the same thing still happens. My 64 bit Linux system has a dual-core processor, and even when I choose the \"use only 1 processor\" option, after a while Bit Coin ends up using both CPU to the 100% max that it can.
Is this a bug that only affects 64 bit Linux users at the moment?
Using the latest version 0.3.0 from the front page of the website.
System OS: Linux Mandriva 2010.0 (64 bit)
RAM 16GB
Processor - Intel Dual-Core 3.06 CPU
Feedback or advice welcome.
Edit by Xunie: I merged this thread with the other \"Bitcoin slowing down your Linux system?\" thread, so things my be confusing for a second, heh.There has been a problem in settings the \"nice\" level on Linux.
A programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!
So, we have a bug.
",
"nested_level": 0
},
{
"id": 1057,
"thread_id": 91,
"source_id": "3",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Bitcoin slowing down your Linux system?",
"url": "https://bitcointalk.org/index.php?topic=299.msg2385#msg2385",
"date": "2010-07-12T21:28:16Z",
"text": "I never noticed responsiveness issues. Perhaps I should nice Bitcoin until the fix.
",
"nested_level": 0
},
{
"id": 1058,
"thread_id": 91,
"source_id": "4",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2386#msg2386",
"date": "2010-07-12T21:29:03Z",
"text": "I wondered about that, but I've never noticed any issues on a dual-core 64bit system.
",
"nested_level": 0
},
{
"id": 1059,
"thread_id": 91,
"source_id": "5",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2391#msg2391",
"date": "2010-07-12T21:41:29Z",
"text": "There has been a problem in settings the \"nice\" level on Linux.
A programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!
So, we have a bug.
Yeah, that always gets me too. You would think a negative number would mean less and positive number means more, but it turns out \"Nice\" works the opposite of that, you want it to be more \"nice\" so you want a higher number, LOL.
I checked the 32bit Linux clients, they run a Nice level of 0, so I guess it's running equal time with everything else.
On the Windows clients, Bit Coin runs at \"normal\" priority as well.
It's easy to start the process in low priority via command line for both of them, so for now I can do that to manually control their priority
It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest.
I think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried.
So, I think the dirty hack of editing /etc/security/limits.conf might fix it.
I wondered about that, but I've never noticed any issues on a dual-core 64bit system.
I don't have any problems on my quad core system here either!
It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest.
I think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried.
So, I think the dirty hack of editing /etc/security/limits.conf might fix it.
I wondered about that, but I've never noticed any issues on a dual-core 64bit system.
I don't have any problems on my quad core system here either!
That may be the issue because you can't \"Nice 20\" anything, 19 is the max
So far, I've \"Nice 19\" 3 clients (one 64 bit and two 32 bit) for the last hour and they haven't changed the Nice level on me yet.
I figured since the process is started at that level, it would remain for all child processes spawned afterwards. I could be wrong though, I'll check again in another few hours to see.
On a side note, I've tracked down the other GUI issue.
The \"minimize to tray instead of taskbar\" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns multiple \"tray\" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?
knightmb - just curious, if you check not just the main process, but all the thread processes (ps -eflL | grep bitcoin - need the L, or else it will just show the main process), do you see the other thread processes change the priority after a little while ? When I change the priority or renice, it will just stick for the main process, but some of threads will change priority everytime it goes to the generate coin function..
there may be some confusion in thinking that nice is working in that if people dont use -L to list all threads, they just see the PID of the main process, and think that the nice/renice has worked, when in fact the 2 subthreads that are maxing the CPU are the ones that are changing the priority back..
I myself just ripped out the whole priority changing function, so that whatever priority I set sticks permanently..
my post about ripping out priority change function is in :
http://bitcointalk.org/index.php?topic=72.0also shows the whole process tree.. in that code pasting, the main process would stay to whatever you nice/renice to, but 2 of the threads would change back, until i ripped out the function
also
http://bitcointalk.org/index.php?topic=285.0 describes the bug with bitcoin changing the threads to use the highest priority instead of lowest
knightmb - just curious, if you check not just the main process, but all the thread processes (ps -eflL | grep bitcoin - need the L, or else it will just show the main process), do you see the other thread processes change the priority after a little while ? When I change the priority or renice, it will just stick for the main process, but some of threads will change priority everytime it goes to the generate coin function..
Feedback from the ps -elfL | grep bitcoin command
[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 11200 6781 11200 0 10 99 19 - 114169 poll_s 17:17 ? 00:00:02 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11202 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11203 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11204 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11212 0 10 99 19 - 114169 sk_wai 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11213 0 10 99 19 - 114169 - 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11214 0 10 99 19 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 S knightmb 11200 6781 11215 0 10 82 2 - 114169 hrtime 17:17 ? 00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11216 86 10 99 19 - 114169 - 17:17 ? 00:40:37 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
1 R knightmb 11200 6781 11219 85 10 99 19 - 114169 - 17:17 ? 00:40:11 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin
0 R knightmb 13291 12282 13291 0 1 80 0 - 1842 - 18:04 pts/1 00:00:00 grep --color bitcoin
Anything in that look out of place? I did notice one that was nice to \"2\" instead of \"19\"
[edit] I see now from the other topic, I'm running the client, the other was the server daemon, might be a bug with just the daemon, not sure though.
yep, that 2 is exactly what im talking about..
wait a little longer and another thread might reset too.. after my change all my threads all stay 19 forever....
",
"nested_level": 0
},
{
"id": 1066,
"thread_id": 91,
"source_id": "12",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2418#msg2418",
"date": "2010-07-12T23:15:01Z",
"text": "yep, that 2 is exactly what im talking about..
wait a little longer and another thread might reset too.. after my change all my threads all stay 19 forever....
Ah I see now. Since you've already dove into the code and disabled the function, is there any reason why the function in question wouldn't just set everything to lowest priority by default? Why would it need to change it around? I'm afraid to dive in myself, otherwise I'll spend days fixing it, hehe.
from what I saw, there was an error in util.h basically the THREAD_PRIORITY_LOWEST was defined as PRIO_MIN.. the intention was to switch to the \"lowest\" priority, but in the linux kernel source in resourch.h PRIO_MIN is actually the lowest NUMBER (-20), meaning it actually changed to the HIGHEST priority.. and then after that function is done, it will change priority again (to either 0 or 2, not as bad as -20) but either way it is changing it, so either way no matter what you nice/renice the threads to, it will switch to diff priority levels automatically, with those particular threads that switch priorities never being the most unobtrusive at 19..
Its been stated in the latest source code, this min/max is fixed, so if you dl the latest source tree and compile the min/max reversal should be fixed... personally I didnt care of having any of the threads change priority on its own at all, so I just removed the function alltogether..
",
"nested_level": 0
},
{
"id": 1068,
"thread_id": 91,
"source_id": "14",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2422#msg2422",
"date": "2010-07-12T23:27:27Z",
"text": "from what I saw, there was an error in util.h basically the THREAD_PRIORITY_LOWEST was defined as PRIO_MIN.. the intention was to switch to the \"lowest\" priority, but in the linux kernel source in resourch.h PRIO_MIN is actually the lowest NUMBER (-20), meaning it actually changed to the HIGHEST priority.. and then after that function is done, it will change priority again (to either 0 or 2, not as bad as -20) but either way it is changing it, so either way no matter what you nice/renice the threads to, it will switch to diff priority levels automatically, with those particular threads that switch priorities never being the most unobtrusive at 19..
Yeah, I finally found it as well (I knew I shouldn't have peaked in the code, LOL). I'm going to try manually setting it to hard code 19 and see if that makes a difference after a compile. If so, it might be a more elegant solution that removing the function all together since it appears it's trying to balance out when to use more CPU depending on the system load.
hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)
I agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don't want any part of it)
",
"nested_level": 0
},
{
"id": 1070,
"thread_id": 91,
"source_id": "16",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2427#msg2427",
"date": "2010-07-12T23:49:40Z",
"text": "hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)
I agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don't want any part of it)
Good point. I just wanted to test if it made a difference (I suspect it will). But after reading the other topics, seems the fix was already checked into the SVN, just not in time for the release so there is no sense in me trying a fix that which is already fixed code wise, hehe.
I agree though, it just needs to run at the lowest prioirty at *all* times, I mean it's suppose to run off of idle CPU and a nice level of 2 isn't far from *shared* CPU cycles than *idle* CPU cycles in my opinion.
One fairly simple workaround is to run bitcoind as a user other than root. Since bitcoin does not require root permissions it will run just fine and it won't be able to set a negative niceness (only root can do that). That will ensure that the highest priority bitcoind can use is 0 (normal).
",
"nested_level": 0
},
{
"id": 1072,
"satoshi_id": 185,
"thread_id": 91,
"source_id": "18",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2908#msg2908",
"date": "2010-07-14T18:45:53Z",
"text": "After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.
There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.
On a side note, I've tracked down the other GUI issue.
The \"minimize to tray instead of taskbar\" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns multiple \"tray\" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?
That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux.
After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.
There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.
On a side note, I've tracked down the other GUI issue.
The \"minimize to tray instead of taskbar\" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns multiple \"tray\" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?
That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux.
It only seems to happen if
A) you minimize to tray, later bring it back up, minimize again, bring it back up. It starts stacking tray icons out (but they are blank, but still labeled as BitCoin)
B) sometimes the program does it randomly
I'll turn it back on with mine to make a screen shot, doesn't take long for it to happen, hehe.
Ok, easy to replicate (well for me anyway)
64bit Client Linux
Having either the \"minimize to tray instead of taskbar\" or \"minimize on close\" options checked will cause the bug.
First thing you notice (as per the first screen-shot), the tasktray is being filled up with invisible icons \"spaces\". If you hover the mouse over them, they all say \"Bitcoin (not connected\" but the one that does have an Bit Coin icon, just says \"Bitcoin\" and that's what you can bring the window back up with.
If you just have \"minimize on close\" checked, it still sends it to task tray causing the bugs.
After a while, all your CPU will be consumed by the X server, even after you close Bitcoin, I think some process stay stuck in memory, not sure.
The 32bit Client for Linux doesn't have this exact issue. I will still make at least one invisible Bitcoin icon, but doesn't tear up the CPU later. So the 32 bit client sort-a has the bug, but not in a way to bring the system down after a short while.
",
"nested_level": 0
},
{
"id": 1075,
"thread_id": 91,
"source_id": "21",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg2943#msg2943",
"date": "2010-07-14T20:50:56Z",
"text": "Could you make it possible to reenable that feature with a startup switch or even compile flag? I like it a lot, and I don't have this issue.
",
"nested_level": 0
},
{
"id": 1076,
"satoshi_id": 189,
"thread_id": 91,
"source_id": "22",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg3008#msg3008",
"date": "2010-07-15T00:18:23Z",
"text": "OK, the undocumented switch \"-minimizetotray\" which re-enables the option.
I uploaded the change to SVN.
",
"nested_level": 0
},
{
"id": 1077,
"thread_id": 91,
"source_id": "23",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Runaway CPU usage for 64bit BitCoin (Linux Client)",
"url": "https://bitcointalk.org/index.php?topic=299.msg3009#msg3009",
"date": "2010-07-15T00:21:16Z",
"text": "Could you make it possible to reenable that feature with a startup switch or even compile flag? I like it a lot, and I don't have this issue.
I like it alot too, wished it work for me
The fix for the thread priority level on linux is available in the 0.3.1 release candidate here:
http://bitcointalk.org/index.php?topic=383.msg3198#msg3198I created a send coins transaction when my laptop was offline; now it's stuck at 0/unconfirmed and not visible to the recipient, even though other transactions I created later went through. How do I force the transaction to be re-sent to the network so it can make progress? Or alternately, how do I cancel the transaction so I can get my funds back?
",
"nested_level": 0
},
{
"id": 1080,
"thread_id": 92,
"source_id": "2",
"poster_name": "bdonlan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=359",
"subject": "Re: Resending transaction",
"url": "https://bitcointalk.org/index.php?topic=303.msg2417#msg2417",
"date": "2010-07-12T23:11:59Z",
"text": "It seems the transaction went through after about an hour and a half.
",
"nested_level": 0
},
{
"id": 1081,
"thread_id": 92,
"source_id": "3",
"poster_name": "gazoakley",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=476",
"subject": "Re: Resending transaction",
"url": "https://bitcointalk.org/index.php?topic=303.msg3429#msg3429",
"date": "2010-07-16T11:01:52Z",
"text": "I'm having the same problem - opened BitCoin to create a transaction and possibly exited before it sent out the payment details. Now I have a 0/unconfirmed transaction.
Having the ability to resend a stuck transaction would be nice - if no nodes have picked it up yet then surely sending it again won't cause an issue (and if some have then they'll just ignore it right?)
",
"nested_level": 0
},
{
"id": 1082,
"thread_id": 92,
"source_id": "4",
"poster_name": "d1337r",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=449",
"subject": "Re: Resending transaction",
"url": "https://bitcointalk.org/index.php?topic=303.msg3438#msg3438",
"date": "2010-07-16T11:39:34Z",
"text": "Looks like exiting BitCoin should be disabled until each transaction will get at least 1 confirmation
Phew - it's taken a couple of hours but it's now gone through
. Wish I could generate coins more easily!
0/unconfirmed means that your client has seen the transaction
1/unconfirmed means that your transaction has been included in 1 block, at this point you can be reasonably sure someone has picked up your transaction and it's now in the chain.
as the number of confirmations increases, so does the confidence in the 'truth' of the transaction.
There is no way to cancel a transaction.
It is not possible with the current client to resend a transaction.
",
"nested_level": 0
},
{
"id": 1085,
"satoshi_id": 213,
"thread_id": 92,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Resending transaction",
"url": "https://bitcointalk.org/index.php?topic=303.msg3499#msg3499",
"date": "2010-07-16T15:01:33Z",
"text": "Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block.
",
"nested_level": 0
},
{
"id": 1086,
"thread_id": 93,
"source_id": "1",
"poster_name": "ellimistd",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=364",
"subject": "Stuck on 513 blocks",
"url": "https://bitcointalk.org/index.php?topic=305.msg2429#msg2429",
"date": "2010-07-13T00:18:19Z",
"text": "When I started bitcoin (windows) It started adding blocks, everything was going well. Then i went and port forwarded (I don't knwo if that's related) and around then, probably a bit after, it stuck at 513 blocks. I left it on overnight, and generated 11 more (to be precise, the 513 is from today, idk if it was that before or not, it was low 500s though) They all say Generated (50.00 matures in [118-108] more blocks). Also, I did the 5 free bitcoins website thing, and it hasn't given me them. I currently have 10 connections, 11 transactions, 513 blocks, and 0.00 balance. What should I do?
",
"nested_level": 0
},
{
"id": 1087,
"thread_id": 93,
"source_id": "2",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: Stuck on 513 blocks",
"url": "https://bitcointalk.org/index.php?topic=305.msg2667#msg2667",
"date": "2010-07-13T22:22:33Z",
"text": "Are you by any chance using Microsoft Security Essentials or 'Live Protection' antivirus program? It is known to interfere with bitcoin's operation, see here:
http://bitcointalk.org/index.php?topic=35.0It should be enough to just add bitcoin.exe to the \"Excluded processes\" list in settings.
It is a good idea to add this to the FAQ somewhere.
",
"nested_level": 0
},
{
"id": 1089,
"thread_id": 93,
"source_id": "4",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Stuck on 513 blocks",
"url": "https://bitcointalk.org/index.php?topic=305.msg2692#msg2692",
"date": "2010-07-14T00:29:55Z",
"text": "513 is my area code.
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 data to be sent or received on them.
We need to understand this problem better.
Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.
",
"nested_level": 0
},
{
"id": 1091,
"thread_id": 94,
"source_id": "1",
"poster_name": "vishwambar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=388",
"subject": "Error on Ubuntu 10.04",
"url": "https://bitcointalk.org/index.php?topic=318.msg2537#msg2537",
"date": "2010-07-13T11:56:45Z",
"text": "Hi,
Tried bitcoind 0.3 on Ubuntu 10.04 and I get the following error when I run bincoind
05:23:02 IST: Debug: ../src/common/intl.cpp(2554): assert \"!m_strShort.empty()\" failed in AddCatalog(): must initialize catalog first
[Debug] Generating a stack trace... please wait../src/common/intl.cpp(2554): assert \"!m_strShort.empty()\" failed in AddCatalog(): must initialize catalog first
Call stack:
[00] 0x80ed73b
[01] 0x80ebf3e
[02] 0x80eca8a
[03] 0x80ed06a
[04] 0x8133e72
[05] 0x8133ddf
[06] 0x80e3942
[07] 0x80e7181
I get a similar error when running bitcoin UI but it has a continue handle and hence it works fine.
Can somebody tell me what this error means and how to go about resolving this?
What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like \"nl-??\"?
It's trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn't try to use it.
Can someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?
",
"nested_level": 0
},
{
"id": 1093,
"thread_id": 95,
"source_id": "1",
"poster_name": "ksd5",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=311",
"subject": "No blocks downloaded - MS Security Essentials users please read",
"url": "https://bitcointalk.org/index.php?topic=323.msg2576#msg2576",
"date": "2010-07-13T16:57:43Z",
"text": "I got my friend to download and try Bitcoin out. I sent him one coin, but he hasn't received it. For some reason, his client isn't downloading any blocks. He turned on \"Generate Coins\" the minute he started the program for the first time. His speeds were in the 1400-1600 khash/s range, and he had 3 blocks. He generated 50 coins which will mature in another 100 blocks or so. He has around 40 connections.
To my knowledge, his coins will be invalid because none of the other nodes will accept his blocks. And, since he hasn't downloaded any blocks, he won't receive the one Bitcoin I sent him.
He uses Microsoft Security Essentials, but has added Bitcoin to its unblock list. He does have port 8333 open, but has a Linux network firewall. (He doesn't have the rights to access the firewall.)
What could be the problem?
",
"nested_level": 0
},
{
"id": 1094,
"thread_id": 95,
"source_id": "2",
"poster_name": "Strofcon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=347",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2577#msg2577",
"date": "2010-07-13T17:08:13Z",
"text": "Might need to have him start it with -addnode=x.x.x.x, where x.x.x.x is someone's static IP. Hopefully someone should be able to share theirs for that purpose... if that's the issue, of course. :-) I don't know for sure though.
",
"nested_level": 0
},
{
"id": 1095,
"thread_id": 95,
"source_id": "3",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2588#msg2588",
"date": "2010-07-13T17:31:44Z",
"text": "This seems like a commonly reported problem now - something to do with the block downloading being really slow. It may be related to the excessive amount of disk I/O that is generated during the initial download. The database file is flushed to disk every time a block is added so this is being really slow for some people. I think we can probably fix this up now that we know about it.. I for one didn't do much testing without having all the blocks, so it never occurred to me to try this under different systems.
",
"nested_level": 0
},
{
"id": 1096,
"thread_id": 95,
"source_id": "4",
"poster_name": "agaumoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=400",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2589#msg2589",
"date": "2010-07-13T17:35:39Z",
"text": "The static IP using addnode will probably work.
However the software is designed to bootstrap using IRC. Probably connecting out to the IRC server is being blocked either by Microsoft or his Linux firewall. Without IRC his system is unable to discover other nodes.
IRC has nothing to do with port 8333, but most likely the Linux firewall is blocking incoming port 8333, so bitcoin will need to establish outgoing connections to other systems with a 8333 open for incoming connections. Without opening incoming 8333 the max connections will be limited to 8 (I think).
",
"nested_level": 0
},
{
"id": 1097,
"thread_id": 95,
"source_id": "5",
"poster_name": "ksd5",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=311",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2591#msg2591",
"date": "2010-07-13T17:42:00Z",
"text": "Well, I don't have port 8333 open, but I was able to download all the blocks. (I don't use a firewall, though.)
I'll ask him to get rights to the firewall and check what it does with port 8333 connections. His port 8333 is open, but the firewall may be messing with it.
",
"nested_level": 0
},
{
"id": 1098,
"thread_id": 95,
"source_id": "6",
"poster_name": "Strofcon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=347",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2597#msg2597",
"date": "2010-07-13T17:58:08Z",
"text": "I think I read somewhere that if he has any connections, he is connecting to the IRC channel just fine... I think you're correct on the 8 connection limit without having port 8333 forwarded.
My thinking was that the static IP -addnode would help by providing a dedicated download source. If that still doesn't work well then I'd guess that laszlo has hit the nail on the head, and the constant full-rewrite of the file is to blame.
",
"nested_level": 0
},
{
"id": 1099,
"thread_id": 95,
"source_id": "7",
"poster_name": "agaumoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=400",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2604#msg2604",
"date": "2010-07-13T18:13:42Z",
"text": "I think I read somewhere that if he has any connections, he is connecting to the IRC channel just fine... I think you're correct on the 8 connection limit without having port 8333 forwarded.
My thinking was that the static IP -addnode would help by providing a dedicated download source. If that still doesn't work well then I'd guess that laszlo has hit the nail on the head, and the constant full-rewrite of the file is to blame.
Oh, right. Missed that he had 40 connections.
But 0 blocks downloaded?
My macmini is currently downloading blocks. It is up to 38xxx after about 4 hours. That is with two dedicated sources on the same lan plus another 6 it discovered out on the 'net. (It is a 2009 model with 4gb of ram using only a 150GB partition of a 500GB, 7200rpm, 2.5\" drive, running the 0.30 .zip'd version as a -server.)
The old macmini drive is in an atom D510 system and is a very slow hard disk. It took a long time (18+hours) to download the blocks even with a dedicated source. But even then it did not stay at 0 blocks for more than a minute or so.
I wonder how much downloading to a ramdisk would speed it up...
Maybe, the hdd is full?
",
"nested_level": 0
},
{
"id": 1101,
"thread_id": 95,
"source_id": "9",
"poster_name": "Strofcon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=347",
"subject": "Re: No blocks downloaded... why?",
"url": "https://bitcointalk.org/index.php?topic=323.msg2613#msg2613",
"date": "2010-07-13T18:42:25Z",
"text": "Yea, possibly a full disk, or a failing disk... It's odd that even with a dedicated connection within your LAN it took that long to get that number of blocks. My 100 Mbps router funneled them from one of my PCs to another in less than 15 minutes, at the 65K+ blocks it needed.
Maybe a flakey router or internet connection? Might be worthwhile to do a speed test, or research Microsoft Security Essentials to make sure it's not toying with Bitcoin's ability to build the block list in some other way... not too familiar with Microsoft products I'm afraid.
![\"Undecided\"](\"/static/img/emoticons/undecided.gif\"/)
Okay, I solved the problem. The solution was in
http://bitcointalk.org/index.php?topic=35.0.
So that was responsible for keeping blocks from downloading?
The link: \"Win32 CPU Cycles vs 'Live Protection' Engines\"
For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?
",
"nested_level": 0
},
{
"id": 1104,
"thread_id": 96,
"source_id": "1",
"poster_name": "InterArmaEnimSil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=375",
"subject": "Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2606#msg2606",
"date": "2010-07-13T18:23:55Z",
"text": "I've seen a number of posts complaining that coin generation on old machines is impractical (actually, the posts say impossible, but that's not correct). A number of others have espoused the general idea that flops*luck=coins, which seems to me to be about right. One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the \"flops\" category of flops*luck.
Now, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck. They operate upon statistical averages. (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).
Therefore, why not cap the number of hashes per second? If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the \"minimum requirements\" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope). Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.
",
"nested_level": 0
},
{
"id": 1105,
"thread_id": 96,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2608#msg2608",
"date": "2010-07-13T18:35:38Z",
"text": "Couldn't I just run 500 instances of the proposed capped client? This is more about trading than generating - the generation is just to make it so the supply is limited.
",
"nested_level": 0
},
{
"id": 1106,
"thread_id": 96,
"source_id": "3",
"poster_name": "Xunie",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=10",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2634#msg2634",
"date": "2010-07-13T20:18:13Z",
"text": "flops*luck=coins, which seems to me to be about right. One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the \"flops\" category of flops*luck.
Now, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck. They operate upon statistical averages. (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).
Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times.
We will keep statistics of how many times it gives us what number between 0 and 1024.
The more we run it, the more difference in the array between the two numbers which got out putted the least and the most.
And so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the \"chance\" of generating a block.
Therefore, why not cap the number of hashes per second? If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the \"minimum requirements\" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope). Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.
We can't.
Bitcoin's Opensource so anyone can run a modified client and thus remove the cap!
Now, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck. They operate upon statistical averages. (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).
The Linux kernel RNG is seeded by noise on the system actually.
Couldn't I just run 500 instances of the proposed capped client? This is more about trading than generating - the generation is just to make it so the supply is limited.
The original question still applies here, however, and the idea that people new to the network don't have coins with which to even experiment is an issue, where in this case it is a hoarding issue of those who have come earlier.
Is it possible to have a multi-tiered coin generation system, where you would have a cryptographically difficult series that would generate a whole bunch of coins at once when the series is completed (taking a few days, weeks, or even months to complete on average), but for those who are more interested in generating coins on a more gradual basis could generate say one bitcoin or even a fractional amount of a bitcoin every few minutes or hours?
The complaint right now is that given the current number of users on the network (which has increased substantially since the slashdot story.... look at the download statistics on Source Forge with a huge spike in the last few days for downloads alone) that coins simply aren't being generated at all.
BTW, it would be nice to see if some other alternative random number generators could be used, as the current one seems to be a time-randomized Linear Congruential Generator. (see
http://en.wikipedia.org/wiki/Linear_congruential_generator for details) BTW, feel free to correct me if I'm wrong on this point too.
It might be kind of interesting to experiment with alternate number generators, and it certainly would be healthy for the network if more than one kind of generator was being used. The nice thing with the LCG as a random number generator is that it can be implemented using only integer arithmetic (often with floating point operations, however) and generally is the most efficient generator in terms of simply getting a number for most common implementations (such as is found with a typical video game) with the fewest CPU cycles. There are some classes of numerical analysis applications where a generator of this nature may not be the best choice.
I'm not sure which random number thing you're referring to, but here is a quick outline of how the generation works:
Prepare a block of memory organized as a struct - certain fields like the hash of the previous block, the current time and some other housekeeeping information is filled in. The struct has an integer field and another 'expansion' field where the data is free form. This free form data is altered (simple increment of a number) and then the struct is hashed. The resulting hash is interpreted as a large integer. If it is equal to or less than the current difficulty function then the proof of work has been found and this block is added locally and broadcast to other nodes.
This is similar to having a 100 sided die - if you roll below 70 you win. To make the game harder you have to roll below 50, then 40, etc. Basically there is no known shortcut to go from a desired hash value to the original input, we only know how to do it quickly in the other direction, so it is simply a brute force iterative process. Statistically, less blocks of data will be below the target value, the lower the target value is. Finding a block that hashes below the difficulty value proves that you worked on the problem, or got lucky and hit it on the first try, but over a long period of time you won't keep getting lucky, you'll have to try lots and lots of different values.
",
"nested_level": 0
},
{
"id": 1109,
"thread_id": 96,
"source_id": "6",
"poster_name": "InterArmaEnimSil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=375",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2736#msg2736",
"date": "2010-07-14T03:31:23Z",
"text": "Couldn't I just run 500 instances of the proposed capped client? This is more about trading than generating - the generation is just to make it so the supply is limited.
Maybe, or maybe not. It would depend upon whether the code did any checking for running clients. The software could easily run some check and prevent a machine from running more than one client. Of course, there are ways around this, a la VMs, etc, but that's another issue altogether.
Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times.
We will keep statistics of how many times it gives us what number between 0 and 1024.
The more we run it, the more difference in the array between the two numbers which got out putted the least and the most.
And so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the \"chance\" of generating a block.
Actually, the number of outputs for the least output number and the number of the outputs for the most output number would tend, as you increased the number of runs to infinity, toward the same number. Specifically, each would tend toward RUNS*1/RNG_RANGE. This was my initial point - there is no luck involved - there's a mechanistic algorithmic process that simulates luck for a small set, but for any large number of runs or large number of machines performing runs, you get the result of the above formula.
We can't.
Bitcoin's Opensource so anyone can run a modified client and thus remove the cap!
Just because the program is open source doesn't mean that it can't check work for validity. This comment is akin to saying \"Anyone could modify the program to create fifty billion bitcoins, since its open source.\" No. The other nodes on the network run checks to determine that blocks (I think blocks is the right terminology, I just found bitcoin recently) are legitimate. Similarly, there are a myriad of ways to sign work to verify that it is originating from an un-hacked client. This would reject work from clients which had been modified to remove the cap, or to remove the limit of one instance of the program per machine. Sure, someone is free to modify the source and remove all caps. However, if they do that, their work would be rejected by the network of legitimate clients, and the \"hacked\" client would be useless unless someone wanted to start an entire new chain, and thus a competitive currency.
The Linux kernel RNG is seeded by noise on the system actually.
Yes, dev/random works this way, but it is blocking, and as I said, very slow. Run \"cat /dev/random\" and see how quickly the bytes pour onto your screen - they trickle. This may or may not be fast enough for bitcoin - I haven't delved into the source as of yet. Conversely, dev/urandom does not work exclusively off of atmospheric noise, and thus is not truly random. Run \"cat /dev/urandom\" and you'll be deluged with pseudorandom noise. /dev/urandom, obviously, is more practical due to the fact that it doesn't hang the machine as it waits for more truly random data - it generates more as it needs it if there is none left in the kernel noise pool. Even with fully random clients, however, they tend, statistically, over time, to the RUNS*1/RNG_RANGE formula for each output possibility. Luck applies per each individual chance. Statistically, as the number of blocks processed grows, it ceases to be a factor.
My key point, or key question....Do those with faster computers have an advantage, or do they not? In the general forums people claim that the \"luck\" factor makes up for this...but statistics beg to differ. Granted, and I do agree, the point is trading, not generation, but essentially with generation we're handing out free (though inflating) money. I would like to think that the process is equitable and not based upon one's ability to afford, in USD, a beast of a machine. This would loosely tie the initial distribution of BTC to the present distribution of USD of those willing to contribute...and seems to undermine the currency philosophically, apart from being unfair.
Thanks for all the hearty discussion on the matter, everyone.
My key point, or key question....Do those with faster computers have an advantage, or do they not? In the general forums people claim that the \"luck\" factor makes up for this...but statistics beg to differ. Granted, and I do agree, the point is trading, not generation, but essentially with generation we're handing out free (though inflating) money. I would like to think that the process is equitable and not based upon one's ability to afford, in USD, a beast of a machine. This would loosely tie the initial distribution of BTC to the present distribution of USD of those willing to contribute...and seems to undermine the currency philosophically, apart from being unfair.
Thanks for all the hearty discussion on the matter, everyone.
Yes, they do. If the old PC can only generate 1 block in 48 hours and the super fast modern PC can generate 1 block in 12 hours, then statistically, the old PC is 4 times as slow as the modern PC during coin generation. The difference is the luck factor. It's possible that the old PC will find a crypto solution by pure luck in less time. So it's possible that the old PC finds one in 2 hours while the super fast PC has to burn through the entire brute force before finding a block in 12 hours. So the advantage is the odds. Simplified of course, but yes, the faster PC gives you a 1 in 12 chance to get the solution and the old PC gives you a 1 in 48 chance (again, way over simplified example)
So the faster PC is like having a few extra lottery tickets
Yes, they do. If the old PC can only generate 1 block in 48 hours and the super fast modern PC can generate 1 block in 12 hours, then statistically, the old PC is 4 times as slow as the modern PC during coin generation. The difference is the luck factor. It's possible that the old PC will find a crypto solution by pure luck in less time. So it's possible that the old PC finds one in 2 hours while the super fast PC has to burn through the entire brute force before finding a block in 12 hours. So the advantage is the odds. Simplified of course, but yes, the faster PC gives you a 1 in 12 chance to get the solution and the old PC gives you a 1 in 48 chance (again, way over simplified example)
So the faster PC is like having a few extra lottery tickets
Given our sample size of 67082 runs, I think that luck is ironed out by statistics at this point. Finding a crypto solution by \"luck\" would imply that the machines began the calculations at a different starting point in instruction sequence, wouldn't it? However, if my machine does, say, 100MFLOPS, and begins a 10-trillion operation procedure to decode a block, and another machine with 1GFLOPS begins the same procedure at ANY time when I'm not 90% done with the process, then the faster machine will always finish faster, will it not? These are deterministic machines working on deterministic problems, with finite starting and ending points and X number of steps in between....I fail to see where luck comes in to play.
On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.
One question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done? In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally. Anyone care to shed any clarity on the situation?
Given our sample size of 67082 runs, I think that luck is ironed out by statistics at this point. Finding a crypto solution by \"luck\" would imply that the machines began the calculations at a different starting point in instruction sequence, wouldn't it? However, if my machine does, say, 100MFLOPS, and begins a 10-trillion operation procedure to decode a block, and another machine with 1GFLOPS begins the same procedure at ANY time when I'm not 90% done with the process, then the faster machine will always finish faster, will it not? These are deterministic machines working on deterministic problems, with finite starting and ending points and X number of steps in between....I fail to see where luck comes in to play.
Everybody is working on a different problem.
I am trying to find a hash for a block which includes a transaction paying ME 50 BTC, you are trying to find the hash for a block which includes a transaction paying YOU 50BTC. These blocks will be different, so the nonce value required to hash them below the target value will be different.
On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.
I have an old slow machine that is only getting about 80khash/s, I managed to generate a block when the difficulty was 23. That seems pretty lucky to me.
One question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done? In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally. Anyone care to shed any clarity on the situation?
Once a valid block comes through, everyone stops working on the one they were working on and starts working on the next block.
It doesn't really matter if you start a few seconds before anyone else, because you're working on a different problem as I explained above.
On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.
One question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done? In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally. Anyone care to shed any clarity on the situation?
From what I've read, when a new block is discovered, the other machines will take a few milliseconds to verify if it's real or not first because say two people's computer discovered a solution within a second of each other. How do we know who the winner is? Well, again more luck. Other people's computers have to verify that your PC wasn't cheating/stupid/error/etc for the block. After a hundred or more confirmations, it's accepted by the \"group\" that your PC founding the winning block and everyone assigns the credit to your PC. So when two computers at the same time find the block, it's more luck on how fast it will be accepted by the group by how many other people's computers verify your find.
The chain is updated and if your neighbors computer was working on block 66777, it hears the news that your found the winning block and says \"well, time to start on the next block\" and begins the calculations over. Now your computer and your neighbors computer are working on block 66778, but each is doing it's own unique brute force. They aren't both working on the same brute force for the same block, otherwise, the fastest computer would always win over and over. The faster computer does have an advantage that it can brute force the next find faster than the slow guy, but the slow guy still has luck on his side.
Now imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet
I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually.
Now imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet
I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually.
This is a good point. My weaker PC is barely squeaking out 1,000 khash/s on two cores, and has netted me 100 coins in less than 48 hours. My server, on the other, hitting closer to 1,200 khash/s on two cores (not a huge bump, but still more), and has been running for about 12 hours longer than the other and has netted me 0 coins. So, like knightmb said... there's hope still.
Okay - if everyone's machines are working on a hash to a different problem, then I can see how luck would be a factor. However, what is the source of the variation between the problem my machine is working on, the problem yours is, etc? One reply earlier seemed to imply that it had to do with transactions in which the individual recently took part....but what about those of us not taking part in any recent transactions? (My most recent one is at least two days old now)
",
"nested_level": 0
},
{
"id": 1116,
"thread_id": 96,
"source_id": "13",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2917#msg2917",
"date": "2010-07-14T19:17:43Z",
"text": "Okay - if everyone's machines are working on a hash to a different problem, then I can see how luck would be a factor. However, what is the source of the variation between the problem my machine is working on, the problem yours is, etc? One reply earlier seemed to imply that it had to do with transactions in which the individual recently took part....but what about those of us not taking part in any recent transactions? (My most recent one is at least two days old now)
In terms of Coin Generation, you need only be connected to the network. That's all that is needed for your computer to broadcast \"I found it!!\" message and for other computers to check if it's valid. Since blocks are being generated on a constant basis, doing offline Coin generation won't be practical. Because if 2 days ago your computer found a block, but so did mine and my PC was online the whole time, mine will be proclaimed the winner/owner of that Coin by the network as a whole. Your PC comes in 2 days later and broadcast that it has the same solution and the other computers will just snide a \"too late, XYZ already solved it, better luck next time\".
In terms of variation between problems, when a block is found, everyone starts on the next block. So if your computer was only 1% towards solving block 68000 and got the message \"XYZ solved the block 68000 just a few minutes ago\", your PC thinks \"well, on to the next one\". It doesn't waste CPU trying to solve a block that was already solved by someone else. That's where the verification part comes in. Otherwise, someone would just hack together a client that broadcast \"I solved block 68000, 680001, 68002, etc\" to claim ownership of the entire range. When a client says it solved a block, all the other computers say \"ok, well prove it then, send me your results\". When enough of them talk to each other about it, they will agree that \"yes, your PC solved block 68000, you are the new owner, congratulations\".
The key part is that it takes hours/days for our PCs to solve a block, but only milliseconds for everyone else to check if it's true. That prevents a \"fake block found\" attack from happening on the network.
Another example, you have a room with hundreds of people in it. Everyone is given a randomly mixed up Rubix cube to solve. The first one to solve his/her cube gets 50 coin.
Now if someone shouts \"I solved it\", it won't take but a mere glance from the surrounding people to tell if it's true or not (solid colors on all sides) If someone shouts \"I solved it\" and it's still a jumbled mess, well everyone just ignores that person and continues on. The first person who solves it for \"real\" wins the prize and then everyone throws away their current Rubix cube and a bunch more randomly mixed Rubix cubes drop from the ceiling to start the process all over again.
In terms of variation between problems, when a block is found, everyone starts on the next block. So if your computer was only 1% towards solving block 68000 and got the message \"XYZ solved the block 68000 just a few minutes ago\", your PC thinks \"well, on to the next one\". It doesn't waste CPU trying to solve a block that was already solved by someone else.
But the problem for solving block X is the same across all the computers, right? So they have a starting point, an algorithm for finding the hash, and a processor. Each starts churning away at the instruction sequence...fastest one wins. I still don't see the luck.
...randomly mixed Rubix cubes drop from the ceiling to start the process all over again.
So the starting point for the crypto hash problems is different for the various nodes? This would make sense - if a slow machine happened to get a block that needed only 100,000 steps to solve, but a fast machine happened to get a block that needed 10 trillion steps, the slow machine might \"win.\" My question remains, though. What is the source of the variation between starting points? How are the differences created? Obviously, if every machine starts in the same place each time, the fastest machine always wins...so from where do the different starting points come?
Aside from the housekeeping fields needed to make sense of the data, the rest of the data that is being hashes is just random. Everyone's is different and you never get any closer to solving it. Every time it is twiddled and re-hashed you have the same chance of finding a solution. This is just like buying raffle tickets. Everyone's numbers are different and they could all be winners, however the guy who gets more raffle tickets might win more often, if this process was repeated over and over. Computers that can try hashing faster have more raffle tickets but every hash calculation has the same chance of being a winner.
",
"nested_level": 0
},
{
"id": 1119,
"thread_id": 96,
"source_id": "16",
"poster_name": "Strofcon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=347",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2927#msg2927",
"date": "2010-07-14T19:50:02Z",
"text": "Take this lightly until confirmed, but here's my understanding...
There is no variation in the problem itself - every node is intended to work on the same block at the same time (accounting for latencies and such). The luck factor is really the random number generated at the beginning of each node's attempt to solve a new block. When a new block needs to be solved, each node generates a random value (nonce), which is used to hash the block. If that hash isn't the right one, the nonce is incremented, and the new incremented value is used to hash the block again.
Say my clunker manages 1,000 khash/s (which it really does...
), and you have a cluster that cranks out 100,000 khash/s, there's still a reasonable chance that my clunker will randomly (and very luckily) land on the value that solves the block within a very small number of hashes... say my nonce is a winner after only 10 hashes. I'm working out 1,000,000 hashes per second, so it only took me 1/100,000 of a second to solve the block. You cluster would have to (again, luckily) generate the right nonce in less than 0.00001 seconds to beat my lucky guess... which means your cluster would have guess correctly in less than 100,000,000 (hash/s) / 100,000 (s) = 1,000 hashes. Given the huge number of hashes possible, the likelihood of you hitting it in under 1,000 is remarkably low...
Granted, my chances of hitting it in under 10 hashes was even more insanely low, but you get the idea I think. So yes, the cluster will, overall, solve more blocks than my clunker, but it won't win out every single time.
Now that I've gone through all that... I'm sure someone will point out a flaw in my reasoning!
I'm fine with that though, I want to make sure I understand it all correctly!
Edit - Laszlo said it much more conscisely, but I think we made the same point...? Hopefully!
In addition the the random nonce, each block also contains a BitCoin address (newly-generated, used only for this purpose) that the 50 BC reward is credited to if you solve a block. Even if two nodes choose the same random nonce to start at (which is unlikely), they're pretty much guaranteed to have different BitCoin addresses.
",
"nested_level": 0
},
{
"id": 1121,
"satoshi_id": 187,
"thread_id": 96,
"source_id": "18",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Hash/sec Throttling for Democracy",
"url": "https://bitcointalk.org/index.php?topic=325.msg2935#msg2935",
"date": "2010-07-14T20:25:06Z",
"text": " So if your computer was only 1% towards solving block 68000
This is a common point of confusion. There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.
It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.
The RNG is the OpenSSL secure random number generator. On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random.
This is mostly for those having troubles on fedora with newer openssl than the binaries on the front page of the site were built with.
Please try these or compile yourself using these instructions:
http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdfhttp://heliacal.net/~solar/bitcoin/builds/Linux-amd64-SVN-102/Thanks!
Works on Slackware64 13.1.
",
"nested_level": 0
},
{
"id": 1124,
"thread_id": 97,
"source_id": "3",
"poster_name": "dougztr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=415",
"subject": "Re: Static Linux x86_64 bins for those having libcrypto troubles",
"url": "https://bitcointalk.org/index.php?topic=326.msg2753#msg2753",
"date": "2010-07-14T05:02:47Z",
"text": "No dice on my Gentoo system. I get the following.
$ bitcoin
bitcoin: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by bitcoin)
and then
$ ldd bitcoind
./bitcoind: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)
linux-vdso.so.1 => (0x00007fffc9bff000)
libdl.so.2 => /lib/libdl.so.2 (0x00007ffeefbe1000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007ffeef8d3000)
libm.so.6 => /lib/libm.so.6 (0x00007ffeef64e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffeef437000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffeef21a000)
libc.so.6 => /lib/libc.so.6 (0x00007ffeeeea4000)
/lib64/ld-linux-x86-64.so.2 (0x00007ffeefde5000)
This file isn't statically linked. I'm only trying to use it because my gentoo system is in a bad state and will take some time to get upgraded to build the source code.
Anyways, thought I'd send a bug report
",
"nested_level": 0
},
{
"id": 1125,
"thread_id": 97,
"source_id": "4",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: Static Linux x86_64 bins for those having libcrypto troubles",
"url": "https://bitcointalk.org/index.php?topic=326.msg3025#msg3025",
"date": "2010-07-15T01:07:17Z",
"text": "I get the same:
`GLIBCXX_3.4.11' not found
on Debian.
The libg++ is not as new as the one bitcoind was compiled with, and the newer one is not available in stable.
",
"nested_level": 0
},
{
"id": 1126,
"thread_id": 97,
"source_id": "5",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Static Linux x86_64 bins for those having libcrypto troubles",
"url": "https://bitcointalk.org/index.php?topic=326.msg3048#msg3048",
"date": "2010-07-15T01:56:37Z",
"text": "Is it possible to statically link the c++ library? If it is possible, is it something that is an acceptable practice or does it cause problems? Maybe just include the library with the program? When I said static I was only referring to openssl
We don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There's probably a compiler switch that would tell it to static link it. I'm not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable.
",
"nested_level": 0
},
{
"id": 1128,
"thread_id": 98,
"source_id": "1",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg2624#msg2624",
"date": "2010-07-13T19:19:47Z",
"text": "i've read through the forums, seen a few topics...
but...
this program really does slow things down.
don't really understand why, if it's supposed to give priority to other progs.
but, crap, makes my system move like it's walking through treacle!!
not a great system,
pentium d, 2.8 mhz each cpu.
3 gb ram
windows 7 home 64
",
"nested_level": 0
},
{
"id": 1129,
"thread_id": 98,
"source_id": "2",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg2628#msg2628",
"date": "2010-07-13T19:45:37Z",
"text": "I guess you are still at the initial download of the current block chain.
until your blockcount is around 66k you still have to download the blocks and verify them. this takes quite some hard-drive performance, so maybe thats what is slowing down your system.
",
"nested_level": 0
},
{
"id": 1130,
"thread_id": 98,
"source_id": "3",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg2639#msg2639",
"date": "2010-07-13T20:38:01Z",
"text": "i'm sorry, but no!
i started at 666## something, ages ago. now up to 66812
and got my 5 freebies
still got max cpu usage?
It will always use max CPU to generate but the generating thread is scheduled at a low priority so it should yield to other processes. I can compile code and do other things on my windows machine with 0.3 running and it doesn't seem to slow it down for me at least.
",
"nested_level": 0
},
{
"id": 1132,
"thread_id": 98,
"source_id": "5",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg2642#msg2642",
"date": "2010-07-13T20:49:14Z",
"text": "It will always use max CPU to generate but the generating thread is scheduled at a low priority so it should yield to other processes. I can compile code and do other things on my windows machine with 0.3 running and it doesn't seem to slow it down for me at least.
thanks for the quick answer
i have bitcoin running, gomez peer and BOINC.
there is definitely a major slow down.
if i have bitcoin running, and click on gomez icon, it takes a good 30+seconds to open. should be instantaneous!!
while i'm at it.
probably totally wrong place, but,...
248 confirmations and my address has changed. why has my address changed. please?
HELP!!!
hehe
It generates a new address and puts it in the main window for you if a payment is received for the previous address. This is so each time you click 'copy to clipboard' to send it to someone, it's easier to get a unique one. The old one is still valid and it's still in your address book.
Try renicing bitcoin and see if it helps. Find the pid in top or ps and then renice +19 1234 where 1234 is the pid.
",
"nested_level": 0
},
{
"id": 1135,
"thread_id": 98,
"source_id": "8",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg2653#msg2653",
"date": "2010-07-13T21:28:06Z",
"text": "windows 7 home 64
I don't think their is any renicing under Windows.
windows 7 home 64
I don't think their is any renicing under Windows.
C:\\Windows\\System32\\cmd.exe /c start \"BitCoin\" /LOW /MIN \"C:\\Program Files\\Bitcoin\\bitcoin.exe\"
In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.
If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.
It could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk.
",
"nested_level": 0
},
{
"id": 1138,
"thread_id": 98,
"source_id": "11",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: resource hog",
"url": "https://bitcointalk.org/index.php?topic=327.msg3149#msg3149",
"date": "2010-07-15T14:00:09Z",
"text": "In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.
If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.
It could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk.
thanks every one for your help
have tried manually setting priority to below normal, and it plays nice!! but stays at 100%
also, when i turn off generate coins, cpu usage drops to zero!
turning generate on sends cpu back up to 100%
Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It's normal that your CPU meter is 100%. Since it's idle priority, it won't actually slow anything else down, even though the CPU meter is 100%.
",
"nested_level": 0
},
{
"id": 1140,
"thread_id": 99,
"source_id": "1",
"poster_name": "fernly",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=414",
"subject": "wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg2743#msg2743",
"date": "2010-07-14T04:09:21Z",
"text": "I tried to register with the wiki, it said \"The user has been created and the password sent by email,\" but no email has arrived. Then I went thru the registration process again, same username and email, and it didn't object to the duplication (nor sent an email).
",
"nested_level": 0
},
{
"id": 1141,
"thread_id": 99,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg2748#msg2748",
"date": "2010-07-14T04:36:08Z",
"text": "Have you checked your spam folder?
",
"nested_level": 0
},
{
"id": 1142,
"thread_id": 99,
"source_id": "3",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg5418#msg5418",
"date": "2010-07-24T01:11:58Z",
"text": "Have you checked your spam folder?
I'm having the same problems.
Yes, I checked my spam folder. I've even created a second account in case the first one I made a mistake on with the e-mail address. Neither are working.
I eventually got the email, very slow though.
",
"nested_level": 0
},
{
"id": 1144,
"thread_id": 99,
"source_id": "5",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg5664#msg5664",
"date": "2010-07-25T08:52:04Z",
"text": "I eventually got the email, very slow though.
How long is that supposed to take? Weeks? Months?
12 hours? Not sure exactly because I went to bed and when I next checked it was there.
",
"nested_level": 0
},
{
"id": 1146,
"thread_id": 99,
"source_id": "7",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg5689#msg5689",
"date": "2010-07-25T14:02:17Z",
"text": "12 hours? Not sure exactly because I went to bed and when I next checked it was there.
It has now been more than four days for me.... this time with three different accounts that I've used to apply. I'm going to try another mail ISP just in case the host for bitcoins has somehow been blocked by the main ISP I'm using.
As a follow-up, switching to a completely different ISP (I just created a new \"throw away\" e-mail account to see what was going on here) I was able to get the registration to be completed. Still, bitcoins.org is on some kind of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.
",
"nested_level": 0
},
{
"id": 1148,
"thread_id": 99,
"source_id": "9",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: wiki registration email?",
"url": "https://bitcointalk.org/index.php?topic=338.msg5884#msg5884",
"date": "2010-07-26T15:30:54Z",
"text": "As a follow-up, switching to a completely different ISP (I just created a new \"throw away\" e-mail account to see what was going on here) I was able to get the registration to be completed. Still, bitcoins.org is on some kind of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.
Looks like bitcoin.org is
listed on the PBL.
WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.
",
"nested_level": 0
},
{
"id": 1150,
"thread_id": 100,
"source_id": "1",
"poster_name": "Giulio Prisco",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=417",
"subject": "They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg2771#msg2771",
"date": "2010-07-14T07:21:08Z",
"text": "http://en.wikipedia.org/wiki/BitcoinThis article is being considered for deletion in accordance with Wikipedia's deletion policy.
Please share your thoughts on the matter at this article's entry on the Articles for deletion page.
This article needs references that appear in reliable third-party publications. Primary sources or sources affiliated with the subject are generally not sufficient for a Wikipedia article. Please add more appropriate citations from reliable sources.
The recent Slashdot article should be considered as a reliable reference:
http://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03I cannot edit at this moment, can you guys save the WP artcile?
",
"nested_level": 0
},
{
"id": 1151,
"thread_id": 100,
"source_id": "2",
"poster_name": "Stone Man",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=288",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg2774#msg2774",
"date": "2010-07-14T07:57:43Z",
"text": "Thanks for the heads up. I added a section titled \"Recent appearance in the news.\"
",
"nested_level": 0
},
{
"id": 1152,
"thread_id": 100,
"source_id": "3",
"poster_name": "joechip",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=397",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg2795#msg2795",
"date": "2010-07-14T11:07:26Z",
"text": "The WP page should discuss the maintenance cost of the p2p network. Not only are there costs associated with the generation of the bitcoins, but their value can only be maintained as long as the 'proof-of-work' network is available and stable.
This cost, of course, is difficult to calculate but it is non-zero, though it may be trivial. There is opportunity cost associated with the storage and maintenance of the network itself. This could be seen as analogous to third-party gold storage fees.
",
"nested_level": 0
},
{
"id": 1153,
"thread_id": 100,
"source_id": "4",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Deletion of Bitcoin Wikipedia Article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4157#msg4157",
"date": "2010-07-19T03:32:02Z",
"text": "This is mainly a notice to the Bitcoin community that the article about Bitcoins on Wikipedia is being deleted.
http://en.wikipedia.org/wiki/BitcoinFrom my own perspective, I think that the rationale for its deletion is valid, as there is little in the way of 3rd party discussions of Bitcoins and their role in alternate currencies, other than discussions on this forum. On the other hand, if there is anybody in the Bitcoin community that is aware of a presentation about Bitcoins at a scholarly conference, some sort of published scholarly paper, or something that perhaps is even in a \"mainstream\" news source.... it would be appreciated to either note that link here or on that Wikipedia article.
The reason for the deletion is non-notability. In other words, nobody outside of the Bitcoin community is really paying attention to the currency or saying much about it. There needs to be some better public relations and discussion beyond personal blogs and such. Yes, I get that this is a chicken or egg situation where if an article like this is deleted that nobody will hear about it either, but it is an issue.
On the other hand, if you are a student (or better yet a professor) and want to make a splash about an interesting topic, this could be something useful to not just the project but also to help spread the word about this project. There is a need to do some real scholarship about Bitcoins, the people involved with getting it going, and how it is different (or the same) from other alternative currencies. Such a paper wouldn't hurt, and could be useful for a number of reasons... not just writing Wikipedia articles.
Once deleted, are the contents of the article lost forever, or can they be restored at some point?
",
"nested_level": 0
},
{
"id": 1155,
"thread_id": 100,
"source_id": "6",
"poster_name": "mtgox",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=489",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4297#msg4297",
"date": "2010-07-19T17:36:03Z",
"text": "Once deleted, are the contents of the article lost forever, or can they be restored at some point?
They can be restored.
Haven't there been articles on slashdot, ronpaul.com and other places? I've found quite a few links on Googling.
",
"nested_level": 0
},
{
"id": 1157,
"thread_id": 100,
"source_id": "8",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4317#msg4317",
"date": "2010-07-19T18:57:19Z",
"text": "Haven't there been articles on slashdot, ronpaul.com and other places? I've found quite a few links on Googling.
None of which are considered credible sources on Wikipedia. ronpaul.com is about as good as it gets, and that still is just an ordinary blog entry from a site participant than something that is a credible independent source.
Slashdot in particular was something generated by fans of Bitcoins and was talked about extensive on this forum before it was even posted. Not that it was something bad for Slashdot, but that isn't how Wikipedia works. Essentially Bitcoins still hasn't become a part of the larger world culture yet.
The purpose of this work for credible sources of information and insistence on reliable 3rd party accounts is in part to keep people like \"UFO Researchers\" and others with fringe theories from taking over Wikipedia. Anybody can come up with some theory that may seem credible, but nobody is really taking seriously. You need to demonstrate that others outside of your immediate community at least consider the concept to be credible and at least worth criticism. None of this is happening with Bitcoins at the moment.
I don't really get it, if there was a group of 11,000 UFO researchers who called themselves UFORO and spent hours every night searching would they get no article unless someone who did not want to join took them seriously enough to write peer reviewed papers?
I think BitCoin has great potential, blah blah, but that doesn't matter. Thousands of people are doing something that's at least moderately interesting. I can't see what the harm of putting a neutrally worded article in the worlds largest encyclopedia is. It isn't like the thing is going to get to heavy to sit on a shelf.
",
"nested_level": 0
},
{
"id": 1159,
"thread_id": 100,
"source_id": "10",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4371#msg4371",
"date": "2010-07-19T22:27:32Z",
"text": "The idea behind bitcoin has been around in research white papers for years. I imagine we should be able to list such research papers as a source. Bitcoins is the first time this theoretical idea which has been around for quite a while, has actually been implemented. I don't have sources available at the moment, but if I get some time, I'll try to look around. If anybody can find these historical research papers and discussions from before Bitcoin was started, please post links to them.
",
"nested_level": 0
},
{
"id": 1160,
"thread_id": 100,
"source_id": "11",
"poster_name": "bdonlan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=359",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4415#msg4415",
"date": "2010-07-20T02:30:38Z",
"text": "I don't really get it, if there was a group of 11,000 UFO researchers who called themselves UFORO and spent hours every night searching would they get no article unless someone who did not want to join took them seriously enough to write peer reviewed papers?
I think BitCoin has great potential, blah blah, but that doesn't matter. Thousands of people are doing something that's at least moderately interesting. I can't see what the harm of putting a neutrally worded article in the worlds largest encyclopedia is. It isn't like the thing is going to get to heavy to sit on a shelf.
The thing is, if they allow an exception to the policy once, then people will ask for exceptions _all the time_. The rule is really quite simple: \"significant coverage in reliable sources that are independent of the subject\". Independent means the papers on bitcoin are out, as is the forum - after all, anything can have lots of non-independent sources. And a single slashdot article is clearly not 'significant coverage' (or reliable coverage
.
The idea behind bitcoin has been around in research white papers for years. I imagine we should be able to list such research papers as a source. Bitcoins is the first time this theoretical idea which has been around for quite a while, has actually been implemented. I don't have sources available at the moment, but if I get some time, I'll try to look around. If anybody can find these historical research papers and discussions from before Bitcoin was started, please post links to them.
You can reference them, but they don't count for notability, as they either don't discuss bitcoin itself (and instead discuss the general concept), or they are not independent (ie, they're written by Satoshi).
Clearly the wiki community knows how to run an open encyclopedia, and clearly I'm biased. I still feel the need to say though that the \"human race\" has not been independent verified. It's only those damn humans ever talk about it.
",
"nested_level": 0
},
{
"id": 1162,
"thread_id": 100,
"source_id": "13",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4502#msg4502",
"date": "2010-07-20T17:49:45Z",
"text": "Would Wikipedia have ignored the airplane until it was independently verified an explained by \"professionals\" who weren't smart enough to invent it in the first place?
",
"nested_level": 0
},
{
"id": 1163,
"satoshi_id": 249,
"thread_id": 100,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: They want to delete the Wikipedia article",
"url": "https://bitcointalk.org/index.php?topic=342.msg4508#msg4508",
"date": "2010-07-20T18:38:28Z",
"text": "Bitcoin is an implementation of Wei Dai's b-money proposal
http://weidai.com/bmoney.txt on Cypherpunks
http://en.wikipedia.org/wiki/Cypherpunks in 1998 and Nick Szabo's Bitgold proposal
http://unenumerated.blogspot.com/2005/12/bit-gold.htmlThe timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment?
It would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.
If you post in
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin please don't say \"yeah, but bitcoin is really important and special so the rules shouldn't apply\" or argue that the rule is dumb or unfair. That only makes it worse. Try to address how the rule is satisfied.
Search \"bitcoin\" on google and see if you can find more big references in addition to the infoworld and slashdot ones. There may be very recent stuff being written by reporters who heard about it from the slashdot article.
I hope it doesn't get deleted. If it does, it'll be hard to overcome the presumption. Institutional momentum is to stick with the last decision. (edit: or at least I assume so, that's how the world usually works, but maybe Wiki is different)
Hi
im using the 64bit linux version. i installed two days ago and produced three lots of 50 coins. yesterday i produced 50 coins within two hours of the last lots completing and have had no others even starting since then. the last lots completed 8:51 am yesterday and its now 10am the next morning and ive got no transactions working at all. have i been snubbed for completing the last two too quickly? if so how long does this last?
",
"nested_level": 0
},
{
"id": 1165,
"thread_id": 101,
"source_id": "2",
"poster_name": "joechip",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=397",
"subject": "Re: stopped prodicing coins",
"url": "https://bitcointalk.org/index.php?topic=343.msg2798#msg2798",
"date": "2010-07-14T11:19:24Z",
"text": "Hi
im using the 64bit linux version. i installed two days ago and produced three lots of 50 coins. yesterday i produced 50 coins within two hours of the last lots completing and have had no others even starting since then. the last lots completed 8:51 am yesterday and its now 10am the next morning and ive got no transactions working at all. have i been snubbed for completing the last two too quickly? if so how long does this last?
I've been generating for nearly two days straight and have not produced a single coin. It seems distribution is completely random.
The production rate depends on your hashs per second and the probability of 1 hash to be the right one.
so basically khash/s * luck factor = generaterd bitcoins.
",
"nested_level": 0
},
{
"id": 1167,
"thread_id": 101,
"source_id": "4",
"poster_name": "joechip",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=397",
"subject": "Re: stopped prodicing coins",
"url": "https://bitcointalk.org/index.php?topic=343.msg2805#msg2805",
"date": "2010-07-14T11:42:26Z",
"text": "The production rate depends on your hashs per second and the probability of 1 hash to be the right one.
so basically khash/s * luck factor = generaterd bitcoins.
Given the current jump in 'difficulty' at around 875 khash/s I should be generating a block every 2.8 days.
So, no complaints.... yet.
http://www.alloscomp.com/bitcoin/calculator.phpThanks for making that calculator.
The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.
",
"nested_level": 0
},
{
"id": 1169,
"thread_id": 102,
"source_id": "1",
"poster_name": "bdonlan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=359",
"subject": "Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg2982#msg2982",
"date": "2010-07-14T22:37:56Z",
"text": "Hi,
The Hash() function in util.h forms the backbone of most of bitcoin's crypto:
template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
uint256 hash1;
SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!
A better solution would be something like:
template<typename T1>
inline vector<unsigned char> HashV(const T1 pbegin, const T1 pend)
{
uint256 sharesult;
uint160 riperesult;
SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&sharesult);
RIPEMD160((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&riperesult);
vector<unsigned char> ret;
ret.insert(ret.end(), (unsigned char *)(&sharesult), (unsigned char *)(&sharesult + 1));
ret.insert(ret.end(), (unsigned char *)(&riperesult), (unsigned char *)(&riperesult + 1));
return ret;
}
The key is to concatenate the hashes, not merge them. This means the attacker has to break both hashes - even in the worst case, this cannot be less secure than a single hash.
Unfortunately, changing hashes would break the chain...
Incidentally, a similar problem exists with Hash160, only worse - an attacker can break _either_ RIPEMD160 or SHA256, and win. At least with Hash() the attacker _must_ break SHA256.
",
"nested_level": 0
},
{
"id": 1171,
"thread_id": 102,
"source_id": "3",
"poster_name": "jib",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=333",
"subject": "Re: Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg3014#msg3014",
"date": "2010-07-15T00:41:15Z",
"text": "The original hash isn't what you're trying to break. You're trying to break the hash bitcoin uses, which is the double hash.
",
"nested_level": 0
},
{
"id": 1172,
"thread_id": 102,
"source_id": "4",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg3024#msg3024",
"date": "2010-07-15T01:05:21Z",
"text": "As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!
If I understand correctly, you've got two chances to find a collision instead of one.
So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal. Bitcoin is using, essentially SHA255 instead of SHA256. It'll still take longer than forever to find a collision...
As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!
If I understand correctly, you've got two chances to find a collision instead of one.
So this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal. Bitcoin is using, essentially SHA255 instead of SHA256. It'll still take longer than forever to find a collision...
It's true that it's not a big deal, but what concerns me is that someone went out of their way to implement an unproven hashing method, without thinking it through to realize that it actually decreases security. Things like this reduce one's confidence in the system as a whole - after all, if such a mistake exists, what other problems may be lurking?
What we really need is a documented protocol, so it can be audited by third parties. I'm working on reverse-engineering it from the source, but it's slow going - the intent of much of the scripting system is poorly documented.
You're trying to solve:
SHA256(SHA256(d'))==256-bit number
This still has 256 bits of security, and you have to do two hashes per attempt to brute-force it.
",
"nested_level": 0
},
{
"id": 1175,
"thread_id": 102,
"source_id": "7",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg3054#msg3054",
"date": "2010-07-15T02:12:37Z",
"text": "You're trying to solve:
SHA256(SHA256(d'))==256-bit number
This still has 256 bits of security, and you have to do two hashes per attempt to brute-force it.
I agree, basically I get what he is saying at the top, but it isn't as bad as everyone thinks.
To brute force your 256bit hash, you either guess the starting string or the second hash string. Which means you have to guess, convert to 256, convert to 256 again and see if that matches. If you attack the second hash, you can't start a guess at 0000000.....1 for example, you know it's already another 256bit number that have to start with. That's like trying to brute force a password and knowing ahead of time the guy's password was 100 digits long. Does it make it any easier? Well no because the first 99 digits could be 0 and the last 1 but either way you still have to try all in between.
Mathematically, I see no advantage. Either you guess the first string to generate the hash or guess the first hash that generates the second hash. Either way you are going to have to brute force the entire key-space to do this. The only advantage is that instead of having \"one\" correct answer, you have \"two\" correct answers out of the billion trillion million guesses possible.
There's a
stackoverflow question about double hashing, by the way. Consensus is that it's not less secure. It's too late for my brain to process the nuances of hashing...
Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.
Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.
Nope! At least, not easily - block and transaction identities are based on this hash, among other things, so this would break the chain. You'd need to do a phased rollout - first, add parsing support to all clients, then obsolete older clients, then roll out a new version which generates a new version of the block serialization format using the new hashing method.
I have no doubt that hashing multiple times is secure, since it is specified in
PKCS #5 and other standards:
An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.
Nope! At least, not easily - block and transaction identities are based on this hash, among other things, so this would break the chain. You'd need to do a phased rollout - first, add parsing support to all clients, then obsolete older clients, then roll out a new version which generates a new version of the block serialization format using the new hashing method.
All the better to practice now, while the network is still young! Well, if it is not a real flaw, it's not necessary, but it would be good practice. This could always be done first in the test network.
I have no doubt that hashing multiple times is secure, since it is specified in
PKCS #5 and other standards:
An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
That quote is about using hashes to transform passwords, which is a different application to what Bitcoin is using SHA-256 for. I don't think the security issues in the two cases are analogous.
PKCS #5 is used by TrueCrypt (and GPG, I think). If each iteration reduced the difficulty of finding collisions, as bdonlan suggests, then TrueCrypt would be easy to break. You'd just attack the hashing algorithm to find the master key.
",
"nested_level": 0
},
{
"id": 1183,
"thread_id": 102,
"source_id": "15",
"poster_name": "Some Mouse",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=426",
"subject": "Re: Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg3145#msg3145",
"date": "2010-07-15T12:44:59Z",
"text": "There's a
stackoverflow question about double hashing, by the way. Consensus is that it's not less secure. It's too late for my brain to process the nuances of hashing...
Note that that discussion is referring to hashing passwords - and the most upvoted comment is explicitly discussing such with that in mind. Trying to do a dictionary attack has no coherent meaning, and someone directly attacking the algorithms behind bitcoin would obviously not start there. It will attack the algorithm.
What is being hashed in this function? <-- let's call this item x
If the total number of possible x is smaller than 256bit space that sha256 provides than an attack would come in the form of a table of all sha256(x) values.
If all of the possible combination's of x is greater than the 256bit space, then here is some math for you (the attack would be at the hash value itself rather than a table on known sha256(x)):
What follows is from
www.atmel.com/dyn/resources/prod_documents/doc8668.pdfIf there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.
Here are some estimates of big numbers:
2^66 Number of grains of sand on the earth
2^76 Number of stars in the universe
2^79 Avogadro's number. The number of carbon atoms in 12 grams of coal.
2^96 Number of atoms in a cubic meter of water
2^190 Number of atoms in the sun
2^255 Number of attempts to find the key value from above
But what about very well funded entities such as the US National Security Agency (NSA)? Could they build a machine to crack a 256 bit key? Assume they could build a theoretical nanocomputer that executes 10^13 instructions per second (approximate rate of atomic vibrations) in a space of a cube with a side that is 5.43nm across (This is the approximate size of a silicon lattice10 atoms wide, or a crystal containing 1000 silicon atoms). Assume that it could calculate an attempt in 10 cycles. Such a computer the size of the earth would take more than 10^13 years (roughly 58 times the estimated age of the earth) to attack a 256 bit algorithm via brute force.
I want some nanocomputers!
",
"nested_level": 0
},
{
"id": 1186,
"thread_id": 102,
"source_id": "18",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Hash() function not secure",
"url": "https://bitcointalk.org/index.php?topic=360.msg3225#msg3225",
"date": "2010-07-15T18:05:23Z",
"text": "What is being hashed in this function? <-- let's call this item x
If the total number of possible x is smaller than 256bit space that sha256 provides than an attack would come in the form of a table of all sha256(x) values.
If all of the possible combination's of x is greater than the 256bit space, then here is some math for you (the attack would be at the hash value itself rather than a table on known sha256(x)):
What follows is from
www.atmel.com/dyn/resources/prod_documents/doc8668.pdfIf there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.
Here are some estimates of big numbers:
2^66 Number of grains of sand on the earth
2^76 Number of stars in the universe
2^79 Avogadro's number. The number of carbon atoms in 12 grams of coal.
2^96 Number of atoms in a cubic meter of water
2^190 Number of atoms in the sun
2^255 Number of attempts to find the key value from above
But what about very well funded entities such as the US National Security Agency (NSA)? Could they build a machine to crack a 256 bit key? Assume they could build a theoretical nanocomputer that executes 10^13 instructions per second (approximate rate of atomic vibrations) in a space of a cube with a side that is 5.43nm across (This is the approximate size of a silicon lattice10 atoms wide, or a crystal containing 1000 silicon atoms). Assume that it could calculate an attempt in 10 cycles. Such a computer the size of the earth would take more than 10^13 years (roughly 58 times the estimated age of the earth) to attack a 256 bit algorithm via brute force.
Quantum computing and encryption:
http://stackoverflow.com/questions/2768807/quantum-computing-and-encryption-breakingIf there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.
That's true, but only when you brute-force every singe hash.
There are other know attacking methods for SHA algorithms, thats why it is planned to replace the SHA-2 family with SHA-3 soon.
German source:
Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das National Institute of Standards and Technology (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt den \u00dcbergang von SHA-1 zu Hashfunktionen der SHA-2-Familie (SHA-224, SHA-256, SHA-384, SHA-512). Langfristig sollen diese durch einen neuen Standard SHA-3 ersetzt werden. Dazu ruft das NIST nach Vorbild des Advanced Encryption Standard (AES) zu einem Ausschreiben auf. Die endg\u00fcltige Wahl und Benennung des Hash-Standards ist f\u00fcr 2012 vorgesehen.
http://de.wikipedia.org/wiki/Secure_Hash_Algorithm#Empfehlungen...
2^255 Number of attempts to find the key value from above
1) Your equations don't take into account reversible computing advancements at all. These techniques could halve the search space by being able to take advantage of algorithms that traditional computers find impossible.
2) Your equations assume the algorithm is perfectly secure. Given that NIST is rather gung ho about developing SHA-3, I'm not terribly confident in that analysis.
3) An attacker does not need to find a specific key to compromise the system, they just need to find the keys to someone's wallet. If you want this to be a viable currency for Earth's population, plus corporate accounts, you drop the search space by 10^10 to 10^12.
That 2^256 search space could get whittled down to the 2^110 range by the end of the century. Assuming no major attacks on its integrity exist.
I'm not particularly sold on the technical soundness of this program, honestly. Why use SHA256 rather than Whirlpool or SHA512?
I'm not particularly sold on the technical soundness of this program, honestly. Why use SHA256 rather than Whirlpool or SHA512?
For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000
There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it, are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?
When they can crack SHA256 in under 10 minutes, I'll be worried, but until then, time is on your side.
For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000
No. SHA512 and Whirlpool exist, are well defined, well supported, well analyzed, and they exist for a reason.
There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it,
Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.
You are basically betting the entire economy (if you believe bitcoins will succeed anyway) on no one developing a means to halve the effective bit length as has been done with e.g. AES.
It's careless.
are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?
Ten years, assuming only minor flaws in SHA256.
If there is a major flaw (again, see the push for SHA-3) there is a much more serious problem. There does not appear to be a clear mechanism for handling a compromise of the basic algorithm, and there should be.
For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000
No. SHA512 and Whirlpool exist, are well defined, well supported, well analyzed, and they exist for a reason.
I'm sure the same was said back when 40, 64, 128, and 256 bit encryption was coming out. SHA512 is part of SHA2, I remember when everyone was talking about how insecure SHA1 was with that significant *flaw* and how we all need to move to SHA2 because it was well defined, well supported, and well analyzed; sound familiar?
There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it,
Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.
You are basically betting the entire economy (if you believe bitcoins will succeed anyway) on no one developing a means to halve the effective bit length as has been done with e.g. AES.
It's careless.
I'm not betting anything for the simple fact that unless you can see into the future, we work with what we have in front of us. We can debate all day that in the future computers will be a million times faster or that some math genius is going to discover a flaw in the system that would bring everything down. I'm well aware of many peer reviewed papers and tech journals, even blogs about encryption. Not everything in existence, as I don't have the time for all of it, but enough practical experience to be able to visualize what it would really take to do what you propose.
are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?
Ten years, assuming only minor flaws in SHA256.
If there is a major flaw (again, see the push for SHA-3) there is a much more serious problem. There does not appear to be a clear mechanism for handling a compromise of the basic algorithm, and there should be.
10 years is a good a guess as my 1 million years. SHA1 still has not been broken, but you can brute force/exploit flaws on a super-computer in under 60 hours if you have $35 million to throw at it.
Overall, I hear what you say and if BitCoin jumped in the SHA3 realm, I would sleep just as well at night as I did with it using the older SHA2 realm of technology.
I'm not trying to nitpick your post, just offering up my opinion and I certainly respect yours. I think we can both agree that if the encryption is bumped up another notch in the future, it would be a good thing for the system and community as a whole.
I'm sure the same was said back when 40, 64, 128, and 256 bit encryption was coming out. SHA512 is part of SHA2, I remember when everyone was talking about how insecure SHA1 was with that significant *flaw* and how we all need to move to SHA2 because it was well defined, well supported, and well analyzed; sound familiar?
I'm not aware of any 40 bit hash length. The reason for SHA512 and Whirlpool's excessive bit lengths are just for such future proofing. A collision has a 50% chance of occurring at half of the bit length (roughly), so weak hashes such as MD5 would have problems at around 2^64 elements, this was well known and few people thought this was impossible to achieve in the future.
So no, it's not exactly familiar. Wanting to double it again because the idea is to form a basis for a new economy is not crazy talk - there is no technical reason not to use Whirlpool or SHA512 (or both). The only hurt would be a lower hash generation rate... which isn't exactly a problem.
I'm not betting anything for the simple fact that unless you can see into the future, we work with what we have in front of us. We can debate all day that in the future computers will be a million times faster or that some math genius is going to discover a flaw in the system that would bring everything down. I'm well aware of many peer reviewed papers and tech journals, even blogs about encryption. Not everything in existence, as I don't have the time for all of it, but enough practical experience to be able to visualize what it would really take to do what you propose.
Your participation is your bet.
10 years is a good a guess as my 1 million years. SHA1 still has not been broken, but you can brute force/exploit flaws on a super-computer in under 60 hours if you have $35 million to throw at it.
$35 million to swipe any single person's bank account.
I'm not trying to nitpick your post, just offering up my opinion and I certainly respect yours. I think we can both agree that if the encryption is bumped up another notch in the future, it would be a good thing for the system and community as a whole.
I'm honestly rather keen on exploring alternative possibilities for generation. As one Slashdotter put it, the current scheme is like claiming a forest of unknown size as currency, burning it down, then proclaiming the most select 21 tons of ash as the representative medium. I have an idea but I have no clue about who would be interested.
That's why I'm glad we have people like you here to participate in the discussion as well. A room full of \"yes men\" is a dangerous thing.
Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.
Wait, what? I thought reversible computation just uses less energy. Where does the non-determinism come in?
Anyway, about the hashing being insecure: Wikipedia says that attacks on SHA-256 still take on the order of 2
250 operations. And unless I made a big thinko here, doesn't the hash target change every ~10 minutes? Wouldn't that throw of an attacker? And if it was possible to break SHA faster, wouldn't the system adjust by raising the difficulty level?
Wait, what? I thought reversible computation just uses less energy. Where does the non-determinism come in?
It's the theoretical limit of how far you can go with it. When doing a brute force search, you can reverse back to any previous state and try new states.
Anyway, about the hashing being insecure: Wikipedia says that attacks on SHA-256 still take on the order of 2250 operations. And unless I made a big thinko here, doesn't the hash target change every ~10 minutes? Wouldn't that throw of an attacker? And if it was possible to break SHA faster, wouldn't the system adjust by raising the difficulty level?
It's doubtful that SHA2 would be that broken before all coins have been minted. The issue is it then becomes a question of how much it costs to hijack someone's bank account.
SHA256 is not like the step from 128 bit to 160 bit.
To use an analogy, it's more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.
SHA256 is not going to be broken by Moore's law computational improvements in our lifetimes. If it's going to get broken, it'll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.
If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.
",
"nested_level": 0
},
{
"id": 1197,
"thread_id": 103,
"source_id": "1",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3027#msg3027",
"date": "2010-07-15T01:09:23Z",
"text": "I've been working on a project inspired by a suggestion (and the offer of bounty
) over from
another thread. I thought I should stop derailing that thread and start my own project thread.
Basically, the idea of the project is an easy way for websites to integrate bitcoin payment. How it works is the user runs a website on their local machine, which is only accessible to them, then when the shop wants a user to pay some money, they simply send them to this local site, which handles sending the money and then redirects back to the shop site to finish the transaction.
So at the moment, I have a test of this running on my PC, visiting this URL:
http://127.0.0.1:8080/BitcoinSalepoint/LandingPage?continue=http://www.google.co.uk&paymentname=testaddress&address=
1DoMXge6kToHZN8m4B2my43anCPbD4rJgE&amount=
0.25will simply send 0.25BC to my laptop from my PC, and then redirect me to google.
My todo list:
-> Add some stylesheets for prettiness
-> Add a confirm/deny button
-> Add a way to communicate to the shop if the transaction succeeded or failed (mostly done)
-> Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies.
Suggestions
(and donations) very welcome
Don't use 8080. Freenet Message System uses that port by default (on localhost), and I expect that there are a lot of FMS users here. It's also a registered port. I suggest using a port that isn't listed
here.
Good point! I hadn't thought about that as 8080 is just the default test port. I'll see about changing to port 18011 tomorrow
Hey Martin,
\"Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies.\"
My only concern with this is that we need to open the JSON API, which is insecure. So easy for a trojan to wipe out a user's wallet.
If this feature were embedded directly within Bitcoin, there would be no need to open the JSON API, and security measures could be taken (such as a captcha to be entered before a pay could be fired, or a password).
I am not, however, a security expert. What do you think?
",
"nested_level": 0
},
{
"id": 1201,
"thread_id": 103,
"source_id": "5",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3223#msg3223",
"date": "2010-07-15T18:03:52Z",
"text": "And alternatively, the JSON API itself can be password secured; would there be a man in the middle attack possible, though?
Lots of security issues to address, but great stuff. I can't wait to see this in action!
",
"nested_level": 0
},
{
"id": 1202,
"thread_id": 103,
"source_id": "6",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3251#msg3251",
"date": "2010-07-15T18:52:13Z",
"text": "The JSON-API definitely needs some sort of security features. On Linux, you can use iptables to restrict the users who can access it, but that's hardly secure. If I want to access it from my website backend, then whatever user runs my httpd needs to be able to access it, and that's the user most likely to be compromised on my server!
Of course, a password wouldn't help that scenario too much, since the password would just be another variable in django's settings.py for an attacker to read, but still, it beats a blank!
",
"nested_level": 0
},
{
"id": 1203,
"thread_id": 103,
"source_id": "7",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3270#msg3270",
"date": "2010-07-15T19:42:43Z",
"text": "This is definately a temporary solution, ideally this functionality would be built into the client itself.
A temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.
Of course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.
",
"nested_level": 0
},
{
"id": 1204,
"thread_id": 103,
"source_id": "8",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3371#msg3371",
"date": "2010-07-16T03:21:59Z",
"text": "This is definately a temporary solution, ideally this functionality would be built into the client itself.
A temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.
Of course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.
Thanks for this martin.If it works as easily as copy and pasting code from paypal onto my site you will have an amazon giftcard coming your way
This is definately a temporary solution, ideally this functionality would be built into the client itself.
A temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.
Of course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.
Security through obscurity?
3 things I can think of
- Allow sellers to specify the value of their goods and services easily.
-Have a message section for the buyers when making payment to allow for such things as contact details and postage etc...
- ping bitmarket for the latest exchange prices to allow automatic conversion between currencies.
I'm not certain how paypal is integrated into your site, but it should be fairly easy - simply direct the user to the payment address, then wait for them to come back to your site and when they do check that you've received payment off them.
The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely u nacceptable for acommerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.
Security through obscurity?
It's terrible, I know, but the only other option is to request changes to the client and wait until they get implemented.
Edit: Anyone out there any good at doing stylesheets? I can make them, but I'm not great at it
The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely u nacceptable for acommerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.
you could still create a new address for any transaction,
if only one person knows that address, it's pretty obvious where bitcoins came from.
true that you can't get a list of all transactions from JSON yet, but from received credits by addresses, or labels,
no need to know about generated coins on a payment-system, or about sending, when your system is only supposed to accept payments.
It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side. Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people.
",
"nested_level": 0
},
{
"id": 1209,
"thread_id": 103,
"source_id": "13",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: Website integration for bitcoin",
"url": "https://bitcointalk.org/index.php?topic=364.msg3476#msg3476",
"date": "2010-07-16T14:09:09Z",
"text": "The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely unacceptable for a commerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.
you could still create a new address for any transaction,
if only one person knows that address, it's pretty obvious where bitcoins came from.
Absolutely, I realised a while after posting that you can simply have a unique address per transaction.
It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side. Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people.
It is, I hope that ultimately this is just a proof of concept, and once it's shown to work it can be integrated into the client (using the same port and URLs).
It is, I hope that ultimately this is just a proof of concept, and once it's shown to work it can be integrated into the client (using the same port and URLs).
*nods* It's a good initiative, and ANY development in the interest of bitcoins right now is good development.
I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail. It would be nice if you didn't have to re-invent the wheel like you're doing here. Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.
",
"nested_level": 0
},
{
"id": 1212,
"thread_id": 104,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "[Bitcoin 0.3.0] Runtime error",
"url": "https://bitcointalk.org/index.php?topic=373.msg3118#msg3118",
"date": "2010-07-15T09:11:26Z",
"text": "Installed Bitcoin 0.3.0 on disk \"D\". When I try to start it i get these errors:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg197.imageshack.us%2Fimg197%2F2007%2F15071a.png&t=589&c=DGO96sJZz4fL8g\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg441.imageshack.us%2Fimg441%2F3341%2F15072.png&t=589&c=qD4JSUc9tmSugg\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg196.imageshack.us%2Fimg196%2F6972%2F15073.png&t=589&c=s1gCpWf0-yCUtg\"/)
What am I doing wrong?
You are using Windows I can tell, but what version, arch (32 or 64 bit) ,etc?
",
"nested_level": 0
},
{
"id": 1214,
"thread_id": 104,
"source_id": "3",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: [Bitcoin 0.3.0] Runtime error",
"url": "https://bitcointalk.org/index.php?topic=373.msg3136#msg3136",
"date": "2010-07-15T10:52:35Z",
"text": "I'm using Microsoft Windows XP Professional Service Pack 3, 32 bit.
",
"nested_level": 0
},
{
"id": 1215,
"thread_id": 104,
"source_id": "4",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: [Bitcoin 0.3.0] Runtime error",
"url": "https://bitcointalk.org/index.php?topic=373.msg3144#msg3144",
"date": "2010-07-15T12:25:16Z",
"text": "",
"nested_level": 0
},
{
"id": 1216,
"satoshi_id": 190,
"thread_id": 104,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: [Bitcoin 0.3.0] Runtime error",
"url": "https://bitcointalk.org/index.php?topic=373.msg3150#msg3150",
"date": "2010-07-15T14:05:20Z",
"text": "More directly, this:
http://bitcointalk.org/index.php?topic=246.0I will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem.
could there be a possible copyright thing here?
did a search for bitcoin on twitter and came up with these links...
http://twitter.com/bitcoinwhich leads to
http://bitcoin.com/or are these somehow related?
I also wonder about this.
",
"nested_level": 0
},
{
"id": 1219,
"satoshi_id": 222,
"thread_id": 105,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoin trademark?",
"url": "https://bitcointalk.org/index.php?topic=378.msg3540#msg3540",
"date": "2010-07-16T17:47:05Z",
"text": "No, not related at all.
",
"nested_level": 0
},
{
"id": 1220,
"satoshi_id": 193,
"thread_id": 106,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin 0.3.1 released",
"url": "https://bitcointalk.org/index.php?topic=383.msg3198#msg3198",
"date": "2010-07-15T17:05:54Z",
"text": "This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of \"start on windowing system startup\" option
",
"nested_level": 0
},
{
"id": 1221,
"thread_id": 106,
"source_id": "2",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3200#msg3200",
"date": "2010-07-15T17:11:49Z",
"text": "hi satoshi,
are there any back-ups need to be done before installing?
",
"nested_level": 0
},
{
"id": 1222,
"satoshi_id": 194,
"thread_id": 106,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3205#msg3205",
"date": "2010-07-15T17:23:48Z",
"text": "Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
",
"nested_level": 0
},
{
"id": 1223,
"thread_id": 106,
"source_id": "4",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3206#msg3206",
"date": "2010-07-15T17:25:33Z",
"text": "Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
okey dokey
been crunching away for a couple of days now, don't want to start all over again!!!!
on this end,
hasn't helped.
still same symptoms, but can't set to belownormal. access is denied!!
edit:
strange,
firefox and windows explorer open quickly enough, bit laggy, but the likes of gomez doesn't!
",
"nested_level": 0
},
{
"id": 1226,
"satoshi_id": 195,
"thread_id": 106,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3221#msg3221",
"date": "2010-07-15T17:56:43Z",
"text": "I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
",
"nested_level": 0
},
{
"id": 1227,
"thread_id": 106,
"source_id": "8",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3224#msg3224",
"date": "2010-07-15T18:04:30Z",
"text": "I am really scared to lose my wallet due to an install, re-install, or backing up. In another thread a user backed up his wallet only to lose all of his bitcoins, forever.
See this thread:
http://bitcointalk.org/index.php?topic=359.0Maybe we can have a step-by-step procedure to successfully backup and to restore.
He tried to double spend his coins and the system prevented it. In the process he also lost the coins he didn't spend because he lost one of the wallet files while swapping them around.
It is enough to back up the wallet.dat, try it out with some free coins from the bitcoin faucet.
",
"nested_level": 0
},
{
"id": 1229,
"thread_id": 106,
"source_id": "10",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3233#msg3233",
"date": "2010-07-15T18:16:50Z",
"text": "This build solved my problem (additional info in this topic
http://bitcointalk.org/index.php?topic=373.0).
I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
possible.
but, and i'm NOT being offensive here, this sort of performance lag has only appeared while i'm running bitcoin.
and BOINC is active, but not running any projects at the moment.
3gig memory,
cached 1524,
available 1573,
free 108.
not going to stop bitcoin, but it does seem a bit strange
anything you would like me to send?
ps...
haven't noticed any extra disk thrashing while bitcoin is running
Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)? It's hard to diagnose without seeing it first hand, sorry.
",
"nested_level": 0
},
{
"id": 1232,
"thread_id": 106,
"source_id": "13",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3243#msg3243",
"date": "2010-07-15T18:38:50Z",
"text": "Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)? It's hard to diagnose without seeing it first hand, sorry.
on a windows machine here. sorry!
any better pointers?
i'm re-installing .3
this update isn't quite working lol
Very nice Satoshi. What about the slow block download bug?
",
"nested_level": 0
},
{
"id": 1234,
"thread_id": 106,
"source_id": "15",
"poster_name": "diven",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=353",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3267#msg3267",
"date": "2010-07-15T19:29:20Z",
"text": "Working on 32 bit Slackware 12.2 and 13.0 (with updated gcc-g++). I have not reverted the upgrade to test if it works with the stock gcc.
",
"nested_level": 0
},
{
"id": 1235,
"thread_id": 106,
"source_id": "16",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3269#msg3269",
"date": "2010-07-15T19:37:10Z",
"text": "On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.I should have counted the cores ahead of time
, confirmed NOT to be a bug when testing Windows 2000, XP, Vista 32/64, Windows 7/ 32-64
On the Linux client (64 bit), the \"minimize on close\" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
But, the priority of the threads all seem to be \"nice\" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.
[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin
1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13682 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687 0 9 82 2 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70 9 99 19 - 113704 - 14:52 pts/1 00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71 9 99 19 - 113704 - 14:53 pts/1 00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75 9 99 19 - 113704 - 14:53 pts/1 00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76 9 99 19 - 113704 - 14:53 pts/1 00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77 9 99 19 - 113704 - 14:53 pts/1 00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79 9 99 19 - 113704 - 14:53 pts/1 00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81 9 99 19 - 113704 - 14:53 pts/1 00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84 9 99 19 - 113704 - 14:53 pts/1 00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86 9 99 19 - 113704 - 14:53 pts/1 00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87 9 99 19 - 113704 - 14:53 pts/1 00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89 9 99 19 - 113704 - 14:53 pts/1 00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90 9 99 19 - 113704 - 14:53 pts/1 00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
I'm not exactly sure what the \"Start BitCoin on window system startup\" is suppose to do?
On library errors, you get a
/usr/lib/libstdc++.so.6 'GLIBCXX_3.4.11' not found on older linux clients (one was only a year old). I checked the file, it's just linked to libstdc++.so.10 but I don't know if that's a high enough version or not.
i'm sorry, but this is mostly ??
i'm not a complete thickie, but most of this is way over my loaf!!
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
",
"nested_level": 0
},
{
"id": 1239,
"thread_id": 106,
"source_id": "20",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3291#msg3291",
"date": "2010-07-15T21:22:18Z",
"text": "The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
yep!
i'm sure they are!!
already said, i haven't a clue!
what on earth are you talking about???
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example:
http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.
Do you have dual-proc? Are you sure you weren't running a single processor hog?
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example:
http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.
Do you have dual-proc? Are you sure you weren't running a single processor hog?
LOL, I think you are right. I've got waaaayy too many PCs around me and it's difficult to keep track of which is single core, dual core, quad, 8 core, etc. I'll test it again on the single proc PC and see what happens.
Yeah, you are right, works just fine. *smacks forehead for not counting cores ahead of time*, so scrap the prioirty bug then, I'll go back and edit my post. Works just fine on Windows 2000, XP, Vista, and 7
",
"nested_level": 0
},
{
"id": 1243,
"satoshi_id": 201,
"thread_id": 106,
"source_id": "24",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3305#msg3305",
"date": "2010-07-15T22:07:35Z",
"text": "On the Linux client (64 bit), the \"minimize on close\" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gzThe listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Yes a bug. It'll have to be fixed in the next version.
On Linux 0.3.0 gets nice 0 when generating but with 0.3.1 the generating thread gets nice 19 while the other threads stay at 0. Looks good.
",
"nested_level": 0
},
{
"id": 1246,
"thread_id": 106,
"source_id": "27",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3311#msg3311",
"date": "2010-07-15T22:29:28Z",
"text": "I'm not exactly sure what the \"Start BitCoin on window system startup\" is suppose to do?
In Windows, it should put Bitcoin.exe into \"HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" for the system registry... or as an alternative into \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\"
I don't see either happening, although it did get put into the \"Startup\" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows
should behave.
I haven't done a full forensics with this new version in Windows, but the install seemed to go without a hitch for me... using the Windows install.
But, the priority of the threads all seem to be \"nice\" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.
I confirm this. bitcoind is actually nice now.
I don't see either happening, although it did get put into the \"Startup\" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.
OpenOffice is another example of something that puts its link in the Startup folder.
On the Linux client (64 bit), the \"minimize on close\" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!
http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gzSatoshi, you didn't fix the bug; you just ripped out the minimize to tray code. Could you possibly make this optional? I wasn't experiencing the original bug, and I very much like the minimize to tray feature.
Run it with the undocumented switch -minimizetotray and the option is available in the options menu.
I don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome.
",
"nested_level": 0
},
{
"id": 1251,
"thread_id": 106,
"source_id": "32",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3344#msg3344",
"date": "2010-07-16T01:12:26Z",
"text": "Alright, thanks. That's all I need.
",
"nested_level": 0
},
{
"id": 1252,
"thread_id": 106,
"source_id": "33",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3396#msg3396",
"date": "2010-07-16T05:24:59Z",
"text": "Build 0.3.1 on an x86 gentoo linux system with my own makefile (builds a dynamic client instead of a static one), seems to run more smoothly than 0.3.0.
B.T.W. Why does the standard makefile builds a static version anyway?
",
"nested_level": 0
},
{
"id": 1253,
"satoshi_id": 214,
"thread_id": 106,
"source_id": "34",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3505#msg3505",
"date": "2010-07-16T15:09:59Z",
"text": "Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
",
"nested_level": 0
},
{
"id": 1254,
"thread_id": 106,
"source_id": "35",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3509#msg3509",
"date": "2010-07-16T15:27:26Z",
"text": "Anyone notice, that for Windows Clients anyway, when you connect a bunch of other clients to it manually (through the -connect option) that if you go over 8, the windows client ends up cutting out the \"outside world\" connections and stick with the original 8 or more internal machines thinking that it's the entire network?
I never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just \"internal clients\" only.
When this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from \"the network\" and all the other clients all think that they are the entire network now. If I do a \"netstat -a -n\" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)
It's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.
",
"nested_level": 0
},
{
"id": 1255,
"satoshi_id": 220,
"thread_id": 106,
"source_id": "36",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3536#msg3536",
"date": "2010-07-16T17:26:17Z",
"text": "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 will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
",
"nested_level": 0
},
{
"id": 1256,
"thread_id": 106,
"source_id": "37",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 0.3.1 release candidate, please test",
"url": "https://bitcointalk.org/index.php?topic=383.msg3544#msg3544",
"date": "2010-07-16T17:58:24Z",
"text": "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 will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
The Windows Client had it's own static IP with port 8333 open for it, I could see from the gateway device that it was connecting out to other peers and other peers were connecting back in. But after the 8, it's like it quit connecting out to peers and after a while the incoming peers stopped as well since it appeared to only be concerned with the peers on the LAN vs the WAN. The behavior of the Linux client is different though I've noticed, even if 50 people are connected to it, it will still seek outbound connections to other peers and inbound peers continue to trickle in as well.
While this will only be a problem for people like me that have hundreds of PCs at their disposal, the reverse is, one could setup PC(s) to connect to a single client 8 or more times and then after a while, the poor windows client would suck itself into it's own matrix world where it thinks it's on the network solving blocks, but it's really trapped back in time.
This is just a theoretical attack of course, I'm not going to lose any sleep over it, but I figured I would throw it out there for the future. The easiest way to negate this would be to put in some self-checking code for IPs. Basically, have to check that is has 8 connections or more that are NOT from the LAN/Same IP Address/etc when it's running as a dual node/client mode.
Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
I think size (static binary is 8x as big in my case) is not the problem, but security.
Boost, openssl and Berkeley DB are fairly common on unix systems (many things depend on them) and also Wxwidgets (the only argument is that bitcoin uses the current development branch and not the stable branch). Second, static linking doesn't mean you can always run it (in my case it tries to load libpng-1.2, which is not present on my system, libpng-1.4 is, and the static fails to load). Third, openssl hasn't been free of security issues, by statically compiling people keep using the insecure version even if their system provides an updated safe version.
I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.
You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.
",
"nested_level": 0
},
{
"id": 1259,
"thread_id": 107,
"source_id": "1",
"poster_name": "EricJ2190",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=357",
"subject": "\"SetIcons(): icon bundle doesn't contain any suitable icon\"",
"url": "https://bitcointalk.org/index.php?topic=391.msg3265#msg3265",
"date": "2010-07-15T19:22:53Z",
"text": "In Windows, when opening the \"Send Coins\" or the \"Your Receiving Addresses\", I get the following message.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg444.imageshack.us%2Fimg444%2F9941%2Fwxerror.png&t=589&c=GoouFk2uBczp2w\"/)
Clicking Cancel allows me to make it go away, and everything still works fine, but it is still a bit annoying.
I am running BitCoin 0.3.0 on Windowx Vista SP2 x64.
That's surprising that we've never heard of that before now.
Maybe you're the first person to ever run it on Vista
I have to guess it has something to do with your display color depth selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a weird video card, display setup or running it on a tablet or mobile or something?
Also happens here - Windows XP, 32-bit color depth, 1680x1050 LCD screen in 120DPI mode. Perhaps the use of an unusual DPI is breaking it?
",
"nested_level": 0
},
{
"id": 1262,
"satoshi_id": 206,
"thread_id": 107,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: \"SetIcons(): icon bundle doesn't contain any suitable icon\"",
"url": "https://bitcointalk.org/index.php?topic=391.msg3323#msg3323",
"date": "2010-07-15T23:41:23Z",
"text": "in 120DPI mode.
What is \"120DPI mode\"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided.
in 120DPI mode.
What is \"120DPI mode\"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided.
In XP, display properties -> settings -> advanced. It basically makes all display elements a bit larger.
Also using 120 DPI here. Same bit depth and resolution as the previous user as well.
",
"nested_level": 0
},
{
"id": 1265,
"satoshi_id": 209,
"thread_id": 107,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: \"SetIcons(): icon bundle doesn't contain any suitable icon\"",
"url": "https://bitcointalk.org/index.php?topic=391.msg3362#msg3362",
"date": "2010-07-16T02:43:29Z",
"text": "That must be it then.
It must be looking for a larger icon like 20x20 but we don't have one.
",
"nested_level": 0
},
{
"id": 1266,
"thread_id": 108,
"source_id": "1",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3292#msg3292",
"date": "2010-07-15T21:30:23Z",
"text": "Hello to the other developers, I finally got a working build environment set up on my Ubuntu machine here and have been perusing the sourcecode a bit. So far I like what I am seeing, the program makes use of the standard template library to avoid messy data structure code and the class structure seems to make pretty good use of public/private access to promote modularity.
The thing that really seems to be lacking though is a good organizational structure between the .h and .cpp files, as well as a lack of function documentation. I would be happy to start writing documentation for the functions using the
doxygen documentation system. I am using this on
OpenDungeons which is a game I am the lead coder on and it has served me well.
For those that are unfamiliar with it, Doxygen works by reading your sourcefiles to extract information which it automatically collects (like function parameters, class organization and inheritance, etc), as well as information you add yourself (comments describing what functions do, what variables are used for, etc). After it parses all of the code it produces a directory containing a bunch of HTML files which are very well crosslinked and easy to navigate. It can also be configured to autogenerate neat little call graphs showing what subfunctions are called from each function (so you can trace dependancies/bugs).
All in all Doxygen is an excellent system and I would be happy to get it set up and begin writing documentation for the functions (at least the ones I can figure out anyway) and provide patches so they can be uploaded to SVN. I don't want to do this though if other developers would be opposed to it so I wanted to post here before I got started. Let me know if you would like me to do this.
EDIT: In case people want to see what the documentation on an existing system looks like, here is a
link to the documentation for the OGRE 3d rendering system. The best place to get a feel for the documentation is to click the \"Classes\" link at the top and then look at the pages for a couple of classes.
-Buck
I think that would be cool, but as always, the decision rests with Satoshi, the project lead.
",
"nested_level": 0
},
{
"id": 1268,
"thread_id": 108,
"source_id": "3",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3480#msg3480",
"date": "2010-07-16T14:15:47Z",
"text": "I think that would be cool, but as always, the decision rests with Satoshi, the project lead.
I didn't think this would be something people would object to. Hopefully I hear definitively from Satoshi that it is OK. I will probably start working on this tonight then (tonight in USA time). Also, I saw another thread questioning how to send in patches; the stated answer was that we should e-mail them to Satoshi, is this still the preferred method?
-Buck
I like that in libraries for the external API's, but you can probably tell from the code that I'm not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.
To add them now at this point, what would be written would just be what's obvious from looking at the function.
The external API we have, in rpc.cpp, the usage documentation is in the help string.
Sorry to be a wet blanket.
",
"nested_level": 0
},
{
"id": 1270,
"thread_id": 108,
"source_id": "5",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3514#msg3514",
"date": "2010-07-16T15:52:10Z",
"text": "No problem, that is why I asked about documentation before I started writing it. I still would like to document it though and maybe we can come to some system which you would find acceptable. One possible way is that I just run Doxygen on my own code and just use the auto-generated docs without adding any descriptions, etc. This would have no impact on the project and myself or anyone else could do this whenever but it limits the usefulness of the documentation.
A second, and perhaps more appealing method would be to utilize the fact that Doxygen does not require the added documentation to be in the same file as the source code it is documenting. We could add a single file that contains the documentation blocks with links pointing to the function names. Doxygen then combines this with the auto-generated info it collects from the source to produce the docs.
Finally, whether we use Doxygen or not, I would like to write a \"man page\" for the program documenting the command-line options it takes. Where is the command line processed in the code? I looked at main.cpp and didn't see it (in fact I couldn't even find the \"main\" function).
-Buck
",
"nested_level": 0
},
{
"id": 1271,
"satoshi_id": 219,
"thread_id": 108,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3534#msg3534",
"date": "2010-07-16T17:15:47Z",
"text": "It's in init.cpp.
It's a wxWidgets app, so it doesn't have a main() function. It may in a little while, since I'm pretty close to making bitcoind build w/o wxBase. (it'll be in init.cpp)
Sorry about my choice of the filename \"main.cpp\", another possible name would have been \"core.cpp\". It's much too late to change. I still prefer main.cpp.
We're still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments.
",
"nested_level": 0
},
{
"id": 1272,
"thread_id": 108,
"source_id": "7",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3584#msg3584",
"date": "2010-07-16T19:54:13Z",
"text": "I don't know anything about JSON and my knowledge of website design is quite limited so I will be of no use here. I do have pretty extensive C++ knowledge though so I should be able to do a bit of work on the codebase.
I am currently tweaking the commandline handling a bit to make it behave more like the standard unix/linux command line (specifically I am adding -h to display help). I also plan to get the man-page text written up based on the current code.
I will put the man page on the wiki when I get it written, where should I submit the patch for the source code?
EDIT: Actually since I am writing the man page in the man page markup language I will include this in the patch as well since it would look like nonsense on the wiki.
-Buck
",
"nested_level": 0
},
{
"id": 1273,
"thread_id": 108,
"source_id": "8",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3756#msg3756",
"date": "2010-07-17T14:27:04Z",
"text": "I am still crunching along on the man page, it is starting to look pretty good. I did come across a couple of issues though. First, there is a \"-printtodebugger\" command line option. I added it to the \"usage\" information when you give -h and I also added it to the man page but I can't tell what it does by looking at the code, other than to see that it is only used on windows machines.
Secondly, in the process of investigating the OutputDebugStringF() function I discovered that the code has the ability to output to a console by setting the global variable fPrintToConsole to true. The variable, however, was initialized to false and there was no where in the code that sets it to true. Because of this I added a -printtoconsole which sets both this variable and fDebug to true. I think both should be set but I am wondering if I should leave fDebug alone. If I don't set it in the code then the user would have to do \"-printtoconsole -debug\" on the command line instead, we may or may not want this depending on whether there is more/less verbosity implied by debug but from a quick grep of the code it looks like it should be the way I currently have it where it automatically sets both variables.
-Buck
",
"nested_level": 0
},
{
"id": 1274,
"thread_id": 108,
"source_id": "9",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3765#msg3765",
"date": "2010-07-17T15:49:56Z",
"text": "Sorry to keep replying to myself but I am posting these little snippets as I stumble across them. I am currently documenting the -dropmessagestest command line switch and I see a minor improvement you may want to add to the code. Currently if a message is dropped as a result of this switch, a debug message is printed to the log indicating a message was dropped. It would probably be pretty useful to print the contents of the dropped message to the log as well. This way if one of the dropped messages really does break bitcoin, you can see what message caused the problem. It would also allow you to later re-create the problem by adding a filter on the incoming network stream blocking messages like the one that broke it the first time so that you can verify that you have fixed the issue later on.
If you think it is a good idea I can probably add this myself as well.
-Buck
",
"nested_level": 0
},
{
"id": 1275,
"thread_id": 108,
"source_id": "10",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3777#msg3777",
"date": "2010-07-17T17:28:31Z",
"text": "Thanks Andrew.
All your hard work is not going unnoticed.
",
"nested_level": 0
},
{
"id": 1276,
"thread_id": 108,
"source_id": "11",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3785#msg3785",
"date": "2010-07-17T19:05:33Z",
"text": "Thanks Insti. I got the man page written. I documented all of the command line switches the program supports, not just the ones in the usage output given by \"bitcoin -h\". Any of the ones that do not appear in the usage output should have a comment in the man page file noting this (comment lines start with .\" which is a period then a double quote).
I provided the update as a patch since I also made some changes to the sourcecode itself. If you want to install the man page first extract it from the diff file with the patch program and then copy the file \"bitcoin.1\" to section 1 of you man pages. On my Ubuntu systems the directory /usr/local/man/man1/ serves as a good place to keep it. Actually on my systems I put a symlink from there to the bitcoin/trunk/bitcoin.1 file so it stays up to date if it gets updated in SVN.
I have also exported the man page using man2html and will post this to the wiki so people can reference it without having to install it on their systems, as well as for the underprivileged Windows users who have to forgo the true awesomeness of the man page system.
Attached to this message you should find a zip file with the patch in it.
EDIT: The wiki doesn't seem to be sending the registration e-mail so I can log in to edit, is there some problem with the server or something?
-Buck
I didn't realize you were going to document all the intentionally undocumented commands. They're unsupported and not intended to be used by users.
All the user-facing commands are listed in the -? help.
",
"nested_level": 0
},
{
"id": 1278,
"thread_id": 108,
"source_id": "13",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3861#msg3861",
"date": "2010-07-18T01:50:06Z",
"text": "I wondered if they were not really meant to be public facing. I think they are useful to have documented though, at least for now. If the program accepts it as valid input it should be documented. You can either add a notice to the commands in the man-page that are experimental, or just remove them. In my opinion it makes more sense to label them experimental so people know they might change, but can use them if they need to. I would just add the following to the beginning of each of the commands in the makefile:
\fBUnsupported - Behaviour may change in future versions\fR
The \fB switches on bold text and the \fR switches back to regular. This way people can use the program to its fullest potential during the development stages. Too much documentation is never a bad thing, especially for an open source project. Since people can see the code they will find these calls anyway and use them whether you want them to or not. If they are documented and marked as volatile then people can at least make an informed choice on whether or not they want to use them.
For example, just at the moment someone in IRC is making use of the -printblock command to generate statistics about the block chain that might help us understand the program better (as in how it performs in the real world). Although the output of this command may change in the future, and therefore we shouldn't be building complex frameworks around it, it is nice to know it exists if you need something done as a quick hack. Also because the program is open source, if someone comes to depend on a certain command line switch they can maintain it. Eventually what you thought was just a temporary debugging tool make end up being one of the most widely used switches available.
-Buck
",
"nested_level": 0
},
{
"id": 1279,
"satoshi_id": 239,
"thread_id": 108,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Source code documentation",
"url": "https://bitcointalk.org/index.php?topic=393.msg3999#msg3999",
"date": "2010-07-18T15:12:54Z",
"text": "They're only intended for intrepid programmers who read the sourcecode.
",
"nested_level": 0
},
{
"id": 1280,
"thread_id": 109,
"source_id": "1",
"poster_name": "gould",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=348",
"subject": "Request: expected bitcoins per day display",
"url": "https://bitcointalk.org/index.php?topic=397.msg3338#msg3338",
"date": "2010-07-16T00:40:51Z",
"text": "I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware, and the bitcoins per day figure is what I really want to know.
I know I can use the calculator at
http://www.alloscomp.com/bitcoin/calculator.php but it's still easier just to see it displayed automatically.
what one could \"expect\" depends on luck and how much of it you expect to have on our block lottery.
i guess that's pretty hard to calculate.
the average time to generate a block shown on the calculator website doesnt mean, you'll find a block after X days,
it still might happen, that you dont find one for a very long period.
people would complain even more than they do already, if the client tells them \"you should have generated xy coins so far, but you had no luck\".
Agreed, I had a 933MHz PIII generate (2) blocks when I have other machines running multiple cores that don't generate anything. It's mainly luck of the draw with those that have faster systems having a bit better luck.
I setup a new system for the farm a few hours ago and it got a block within the first hour, I was stunned, it wasn't even that fast, like 135 khash/s old PC.
",
"nested_level": 0
},
{
"id": 1283,
"thread_id": 109,
"source_id": "4",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Request: expected bitcoins per day display",
"url": "https://bitcointalk.org/index.php?topic=397.msg3404#msg3404",
"date": "2010-07-16T06:16:27Z",
"text": "hehe,
i just checked my old pIII laptop, that i set up ~12hrs ago,
it does ~150khash/sec @1066MHz and already won the race 10hrs ago.
I've been running two laptops. One does 1280k/sec and the other 580. The 580 found one first. It does run 24/7 though and I make my faster one stop when I do other stuff.
Oh, I keep hearing that there should be 6 blocks an hour, but it seems more like 80. And didn't the difficult just rest? So shouldn't it be close to the goal? I must have some misunderstanding.
",
"nested_level": 0
},
{
"id": 1285,
"thread_id": 109,
"source_id": "6",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Request: expected bitcoins per day display",
"url": "https://bitcointalk.org/index.php?topic=397.msg3453#msg3453",
"date": "2010-07-16T12:49:13Z",
"text": "Oh, I keep hearing that there should be 6 blocks an hour, but it seems more like 80. And didn't the difficult just rest? So shouldn't it be close to the goal? I must have some misunderstanding.
Difficulty only adjusts every 2016 blocks.
The amount of processor power being applied is increasing faster than the difficulty is adjusting so we're getting about 27 blocks per hour at the moment.
There will be a big difficulty jump later today when we hit 68,544 blocks.
what one could \"expect\" depends on luck and how much of it you expect to have on our block lottery.
i guess that's pretty hard to calculate.
I think of my machines running bitcoin as slot machines. I put in CPU time and energy costs in at a regular rate, and once in a while I get money back. If I'm to treat bitcoin as part of a business, then I need to be able to calculate my expected return on investment, just as a casino owner needs to be able to calculate how much money she's making off of her slot machines. I know that the bitcoin generation difficulty will stabilize at some point in the future, but at this point it would be useful to me to be able to calculate my ROI quickly and easily.
So, if nobody else is going to do it, I'll probably make a patch for this. Bitcoin donations appreciated, of course, and would help motivate me to make it available quickly.
Many businesses are like that. For a car salesman, when will the next customer walk in the door?
On the OP's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time? \"it said 7 days and I waited more than a week and didn't get anything!\" Approx, average, but still they're going to think that way. It can't be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?
The difficulty quadrupled a few minutes ago to 181.54. It's going to take typically about a week to generate now.
",
"nested_level": 0
},
{
"id": 1288,
"thread_id": 110,
"source_id": "1",
"poster_name": "singpolyma",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=463",
"subject": "Assertion Failure - Ubuntu Lucid",
"url": "https://bitcointalk.org/index.php?topic=400.msg3384#msg3384",
"date": "2010-07-16T04:30:15Z",
"text": "I'm running Ubuntu Lucid (32 bit), all packages up to date. I had run bitcoin 0.2 previously, and just downloaded 0.3. I ran bitcoind and I got:
bitcoin: main.cpp:823: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.
Aborted
So I ran the bitcoin GUI, and it came up and showed my existing coins, but quickly gave me the same error and died. Then I went back and ran the 0.2 GUI again and I get:
bitcoin: main.cpp:743: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.
Aborted
Has my db got corrupted? Do I have a broken dependancy?
I tried to build 0.3 from source but got many errors, probably missing some *-dev packages. Will look at that more later.
",
"nested_level": 0
},
{
"id": 1289,
"satoshi_id": 211,
"thread_id": 110,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Assertion Failure - Ubuntu Lucid",
"url": "https://bitcointalk.org/index.php?topic=400.msg3492#msg3492",
"date": "2010-07-16T14:52:04Z",
"text": "That's the first time I've seen this error.
How many blocks do you have? (in the status bar)
You should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don't mind, could you keep the old blk*.dat files for a little while in case I need to look at them?
",
"nested_level": 0
},
{
"id": 1290,
"thread_id": 110,
"source_id": "3",
"poster_name": "singpolyma",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=463",
"subject": "Re: Assertion Failure - Ubuntu Lucid",
"url": "https://bitcointalk.org/index.php?topic=400.msg3814#msg3814",
"date": "2010-07-17T22:17:16Z",
"text": "I have 58464 blocks... haven't run the software in awhile
",
"nested_level": 0
},
{
"id": 1291,
"thread_id": 110,
"source_id": "4",
"poster_name": "singpolyma",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=463",
"subject": "Re: Assertion Failure - Ubuntu Lucid",
"url": "https://bitcointalk.org/index.php?topic=400.msg3815#msg3815",
"date": "2010-07-17T22:19:48Z",
"text": "Moved the block files... it's working through them all again. My coins disappeared, but I assume they'll come back when it's up to current?
",
"nested_level": 0
},
{
"id": 1292,
"satoshi_id": 234,
"thread_id": 110,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Assertion Failure - Ubuntu Lucid",
"url": "https://bitcointalk.org/index.php?topic=400.msg3823#msg3823",
"date": "2010-07-17T22:37:06Z",
"text": "My coins disappeared, but I assume they'll come back when it's up to current?
Right, they'll re-appear when it's finished downloading all the blocks.
I run my computers off solar-generated electricity, so I keep pretty tight tabs on how much power they consume.
I have one headless Ubuntu server that is always-on, usually with the disk array spun down, as it has some central network management roles. It's an Intel Core2Duo E6300 @ 1.86 GHz, and mines at about 950 khash/s.
I was curious to see the impact bitcoind generation would have on it. Here is what it looks like:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.trix.com%2FGroundLoop%2Fbitcoin.png&t=589&c=OZl2FBYhFPMIcg\"/)
The lowest level on the left is idle, and the noise after it is bitcoind inhaling the block history. The step up is the bitminer threads.
In short, hashing raised the idle floor from about 120W to 160W, or +40W.
This draws 29 kilowatt-hours a month from my generation, which means I net some $3.80 less for power ($0.13/kwh marginal power rate)
If I generate an average of 13 blocks a month at the current difficulty, BTC 650, that puts my cost at about US$0.005/BTC.
In short, I'm better off buying BTC from the exchange than generating them on this particular machine. Food for thought.
It's like they always say, \"To make a billion dollars, you have to start with 4 billion dollars first\"
In short, I'm better off buying BTC from the exchange than generating them on this particular machine. Food for thought.
Don't forget to amortize your fixed costs. Those parts don't last forever and eventually need replacing.
Neat chart.
Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.
",
"nested_level": 0
},
{
"id": 1297,
"satoshi_id": 226,
"thread_id": 112,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Sample account system using JSON-RPC needed",
"url": "https://bitcointalk.org/index.php?topic=417.msg3579#msg3579",
"date": "2010-07-16T19:45:10Z",
"text": "We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system. Most sites that sell things will need something like this. Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.
When a user is logged in to their account, you show the bitcoin address they can send to to add funds. Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>). You only need to keep the latest bitcoin address for the account in your database. (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)
You use getreceivedbylabel <username> with the username as the label to get the \"credit\" amount of the account. You need to keep a \"debit\" amount in your database. The current balance of the account is (credit - debit). When the user spends money, you increase debit.
If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged. Not all sites need to wait for confirmations, so the dual current & available should be optional. Most sites selling digital goods are fine to accept 0 confirmations.
A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address. The sample code should be the simplest possible with the minimum extra stuff to make it a working site.
vekja.net is an example of a site like this.
",
"nested_level": 0
},
{
"id": 1298,
"thread_id": 113,
"source_id": "1",
"poster_name": "InterArmaEnimSil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=375",
"subject": "Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3614#msg3614",
"date": "2010-07-16T23:04:44Z",
"text": "Is there any way to query the current size of the network, say, in connected clients, actively generating clients, FLOPS, or preferably, all three? I see that my client is connected, and has been connected, to 15 clients for the past four days....yet somehow I doubt there are only 15 people generating coins. I'm looking for this in the context of scalability assessments.
",
"nested_level": 0
},
{
"id": 1299,
"thread_id": 113,
"source_id": "2",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3741#msg3741",
"date": "2010-07-17T13:41:52Z",
"text": "How is it that you get more than 15, all of my clients exactly level out at 15 and never go higher like there is some hard limit imposed. Did you have to tweak the source to make that happen?
-Buck
",
"nested_level": 0
},
{
"id": 1300,
"thread_id": 113,
"source_id": "3",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3791#msg3791",
"date": "2010-07-17T19:37:03Z",
"text": "15 connections was the maximum of 0.2 without port forwarding.
but it doesn't matter how much connections you have, 1 is enough, all the others are redundant.
",
"nested_level": 0
},
{
"id": 1301,
"thread_id": 113,
"source_id": "4",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3792#msg3792",
"date": "2010-07-17T19:46:48Z",
"text": "I am aware that 1 is plenty for proper functioning, but more connections helps prevent the network from becoming segmented. I was just wondering if there was a limit because I am always at 15 which seemed odd to me.
Anyway in regards to the question I think the protocol itself should support some kind of mechanism like this as it is good to know. As far as I understand it the IRC server is more of a temporary thing until a more permanent solution is implemented. This will probably have to happen sooner, rather than later, since the growth of the system will soon overwhelm the IRC server. It is also somewhat of a single point of failure, even though the clients have other ways of finding eachother losing the IRC server could end up fragmenting the network causing several \"islands\" of interconnected nodes. If this islanding persisted for long enough transactions could be lost.
-Buck
",
"nested_level": 0
},
{
"id": 1302,
"thread_id": 113,
"source_id": "5",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3817#msg3817",
"date": "2010-07-17T22:22:09Z",
"text": "Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.
",
"nested_level": 0
},
{
"id": 1303,
"thread_id": 113,
"source_id": "6",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3822#msg3822",
"date": "2010-07-17T22:34:41Z",
"text": "I have v3 w/ no forwarding and never get more than 8.
",
"nested_level": 0
},
{
"id": 1304,
"satoshi_id": 237,
"thread_id": 113,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Network Size",
"url": "https://bitcointalk.org/index.php?topic=419.msg3830#msg3830",
"date": "2010-07-17T23:25:16Z",
"text": "Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.
In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.
Please upgrade to 0.3.2, it's available now.
How would a Bitcoin snack machine work?
1) You want to walk up to the machine. Send it a bitcoin.
2) ?
3) Walk away eating your nice sugary snack. (Profit!)
You don't want to have to wait an hour for you transaction to be confirmed.
The vending machine company doesn't want to give away lots of free candy.
How does step 2 work?
",
"nested_level": 0
},
{
"id": 1306,
"thread_id": 114,
"source_id": "2",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3650#msg3650",
"date": "2010-07-17T02:58:29Z",
"text": "For low value items like that you would normally accept the transaction without any confirmations. If the bitcoin node that the vending machine is talking to accepted the transaction then it's probably valid. I think the only danger in that is if it was somehow double spent in a short time window - then it may never get into any blocks. I'm not sure if that's really possible, maybe it is, but it seems like it would be hard to pull it off reliably.
",
"nested_level": 0
},
{
"id": 1307,
"thread_id": 114,
"source_id": "3",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3651#msg3651",
"date": "2010-07-17T03:08:25Z",
"text": "I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.
",
"nested_level": 0
},
{
"id": 1308,
"thread_id": 114,
"source_id": "4",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3676#msg3676",
"date": "2010-07-17T05:06:29Z",
"text": "I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.
It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.
The first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.
I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.
It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.
The first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.
That might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first.
I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.
It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.
The first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.
That might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first.
Oh, yeah. It doesn't have to be two vending machines though. I could even send the coin to my friend then immediately spend it at the vending machine. I think the way things are you aren't safe to release until the transaction is embedded in a block that the majority finds acceptable.
The problem with slow confirmations is because of a little amount of nodes. When Bitcoin will become somewhat popular, then you could get the confirmations much quicker (especially the ones in the limit of an ISP/city/region[or state]/country)
",
"nested_level": 0
},
{
"id": 1312,
"thread_id": 114,
"source_id": "8",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3699#msg3699",
"date": "2010-07-17T08:15:41Z",
"text": "
You can act on a transaction before it is included in a block.
So you can still check for double spending in all the transactions you can see already.
So to buy 2 snacks with the same coin you'd have to spend it at 2 distant nodes simultaneously and get your snack faster than the network propagation time.
So vending machines are easily possible and the scope of the attack is actually quite limited?
",
"nested_level": 0
},
{
"id": 1313,
"thread_id": 114,
"source_id": "9",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3701#msg3701",
"date": "2010-07-17T08:20:14Z",
"text": "The solution is for the snack vendor to have debit accounts. You've got a fantastic vending machine at work, so you transfer \u0e3f2000 bitcoins to it which can be withdrawn or spent at any time. Withdrawing the bitcoins takes about ten minutes, but spending them is instantaneous. Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow, which is trusted by both parties and perhaps regulated by the government. They hold bitcoins 100% in reserve and offer instant transfer of balances between customer/merchant/supplier accounts. Withdrawals and deposits take about ten minutes, but purchases are instant.
",
"nested_level": 0
},
{
"id": 1314,
"thread_id": 114,
"source_id": "10",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3702#msg3702",
"date": "2010-07-17T08:23:59Z",
"text": "The solution is for the snack vendor to have debit accounts. You've got a fantastic vending machine at work, so you transfer \u0e3f2000 bitcoins to it which can be withdrawn or spent at any time. Withdrawing the bitcoins takes about ten minutes, but spending them is instantaneous. Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow, which is trusted by both parties and perhaps regulated by the government. They hold bitcoins 100% in reserve and offer instant transfer of balances between customer/merchant/supplier accounts. Withdrawals and deposits take about ten minutes, but purchases are instant.
If the machine is setup to only connect to their node, that could work since it would be kind of a central spending point that would quickly be able to tell if someone was trying to double-spend the coin.
As for different networks and nodes, like Bob's Escrow is different from Jane's Escrow, the added delay would make a theoretical attack possible, but no one is going to get rich ripping off vending machines.
Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow
Perhaps there could be a variety of intermediary service providers that offer this type of 3rd party escrow service and the customer can decide which 3rd party they like to use and the vending machine can choose which 3rd party escrow services it is compatible with. If the customer finds a vending machine that accepts using a particular 3rd party escrow, then the customer can buy from the vending machine. Of course, it would be useful if the most popular/trusted/established escrow services are used both by vending machine and customer.
what you folks are calling an escrow sounds a lot like a debit card account.
",
"nested_level": 0
},
{
"id": 1317,
"thread_id": 114,
"source_id": "13",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3708#msg3708",
"date": "2010-07-17T08:36:19Z",
"text": "what you folks are calling an escrow sounds a lot like a debit card account.
Bitcoins are the equivalent to cold hard cash. There's nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in
this related thread. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off.
what you folks are calling an escrow sounds a lot like a debit card account.
Bitcoins are the equivalent to cold hard cash. There's nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in
this related thread. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off.
Yeah, I understood the fractional reserve thread. I am not sure that I fully understand escrow, I know it is usually used in large transactions to ensure the seller that the cash is indeed on hand, and will stay that way. Part of the purpose, as far as I can tell, is usually to slow down transactions, thus making them more secure. In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is.
The beauty of bitcoin is you don't need 3rd parties like banks.
I can see how an escrow could be useful.
Surely it's still possible to do this without one.
Adding an escrow will add cost to the transaction.
",
"nested_level": 0
},
{
"id": 1320,
"thread_id": 114,
"source_id": "16",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3784#msg3784",
"date": "2010-07-17T18:37:58Z",
"text": "In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is.
You're not misunderstanding. Escrow and debit are similar services and their definitions overlap. I was stretching the definition. Debit fits my description just as well if not better than escrow. I was just putting the emphasis on the fact that the company, whatever it's called, can transfer bitcoin balances on an accounting sheet instantly without having to wait for a real bitcoin transaction, but like is described in the fractional reserve lending thread.
Even better than an escrow, you just fund the beverage machine company itself.
Like this: you go to the company's website and send them 100 BC. Then, they give you an ID. They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.
",
"nested_level": 0
},
{
"id": 1322,
"thread_id": 114,
"source_id": "18",
"poster_name": "Babylon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=454",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3806#msg3806",
"date": "2010-07-17T21:27:07Z",
"text": "Even better than an escrow, you just fund the beverage machine company itself.
Like this: you go to the company's website and send them 100 BC. Then, they give you an ID. They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.
a prepaid account with the snack machine company works great for snack machines in corporate cafeterias (or other places with a fairly static consumer base) not so much for areas with a large transitory consumer base, such as airports, ferry boats, train stations etc.
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 a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%
So if a double-spend has to wait even a second, it has a huge disadvantage.
The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
",
"nested_level": 0
},
{
"id": 1324,
"thread_id": 114,
"source_id": "20",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Bitcoin snack machine (fast transaction problem)",
"url": "https://bitcointalk.org/index.php?topic=423.msg3836#msg3836",
"date": "2010-07-18T00:03:29Z",
"text": "The service provider has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the service provider's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
This is a good start, but still not impermeable. This kind of security relies on the fact that the majority of nodes (which really just boils down to the majority of IP's) are honest. However, if the attacker could amass many IP addresses, then he could control the propagation (for example, by refusing to propogate word of the transaction at the vending machine), and still lead a successful double-spending attack. Which sort of brings us back to the main novel idea of bitcoin: truth is voted on by computing power, not IP.
For just a beverage, it may seem like this attack is uneconomical. But imagine if instead the machine dispensed small-denomination giftcards, and the attack was performed thousands of times (maybe even at the same time in a concerted effort). Suddenly, the cost of that IP block might be a bargain for the attacker...
This is a good start, but still not impermeable.
I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.
(for example, by refusing to propogate word of the transaction at the vending machine)
No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes.
So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.
His name is William Pitock aka Nenolod
http://twitter.com/nenolodWhat do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.
If he does, we all loose.
I hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.
Also, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3
so I can prove him he's wrong.
Please discuss the issue.
what is the issue?
",
"nested_level": 0
},
{
"id": 1328,
"thread_id": 115,
"source_id": "3",
"poster_name": "wobber",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=251",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3737#msg3737",
"date": "2010-07-17T13:38:01Z",
"text": "what is the issue?
He hoards massive amounts of BTC only to create inflation later by putting them into circuit.
Now that the network is still relatively small, he can create swings in the proof-of-work difficulty and to some extent in BTC price if he sells his coins in large quantities. Nothing too serious, I think.
",
"nested_level": 0
},
{
"id": 1330,
"thread_id": 115,
"source_id": "5",
"poster_name": "juengasa",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=495",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3759#msg3759",
"date": "2010-07-17T14:46:52Z",
"text": "Hi, i'm new from a week. My question is.. where i can see the cost of generation of new coin? i suppose that with people with 1000 cores, we will need more time for get new coins.
bye bye
Juan.
",
"nested_level": 0
},
{
"id": 1331,
"thread_id": 115,
"source_id": "6",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3761#msg3761",
"date": "2010-07-17T15:06:18Z",
"text": "How much money is he wasting to tie up 1000 cores? I'd love to have that kind of disposable income to prove my point
Probably the son of a [paper] banker. Or some other powerful interest that will be hurt by a disruptive technology.
nope, hes the Technology Director at SystemInPlace
http://www.linkedin.com/in/nenolod Appears to be a hosting company
http://www.linkedin.com/companies/system-in-place.
I would guess that if he doesn't manage to break the market, he will find something useful to do with it that will benefit him and probably bitcoin as a whole (though maybe not all individual users of bitcoin).
I wonder how much he spends for using these 1000 cores... Because the price of bitcoins you get is NOT much larger than price you have to pay to generate them.
",
"nested_level": 0
},
{
"id": 1334,
"thread_id": 115,
"source_id": "9",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3768#msg3768",
"date": "2010-07-17T16:00:29Z",
"text": "Nenolod, you're welcome to join this forum or #bitcoin-dev on Freenode. It would be interesting to have a chat with you.
BTW, Nenolod writes on Twitter:
bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.
He hasn't sold anything at BitcoinExchange.com and the service is down just for technical maintenance. Should be up today or tomorrow. Maybe he meant that 1500 \u0080 was the rate for the 84,732 BTC he supposedly has.
If he was generating one block per minute before the difficulty increase that would mean he is actually representing more than 50% of bitcoin's CPU power. Actually, rather nearly all of it.
",
"nested_level": 0
},
{
"id": 1336,
"satoshi_id": 231,
"thread_id": 115,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3773#msg3773",
"date": "2010-07-17T16:56:06Z",
"text": "0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.
But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.
",
"nested_level": 0
},
{
"id": 1337,
"thread_id": 115,
"source_id": "12",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3775#msg3775",
"date": "2010-07-17T17:12:18Z",
"text": "Satoshi, could you explain this security safeguard? Is this an undocumented feature of the Bitcoin client or something?
",
"nested_level": 0
},
{
"id": 1338,
"thread_id": 115,
"source_id": "13",
"poster_name": "Some Mouse",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=426",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3781#msg3781",
"date": "2010-07-17T17:56:06Z",
"text": "It looks like the generation rate dropped to about half about six hours ago.
Some of the things he mentions are a bit suspicious. Generating 207... then 913 coins. The former could be explained by selling a random number, the latter... In addition, a thousand cores on Amazon EC2 instances is not so cheap as to make it economical even if he prepaid for the nodes.
",
"nested_level": 0
},
{
"id": 1339,
"thread_id": 115,
"source_id": "14",
"poster_name": "d1337r",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=449",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3783#msg3783",
"date": "2010-07-17T18:19:52Z",
"text": "Well, yeah. Even at the usual difficulty level generating coins is NOT so profitable, and at the harder one, it is just pure waste of real money.
",
"nested_level": 0
},
{
"id": 1340,
"thread_id": 115,
"source_id": "15",
"poster_name": "dwdollar",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=24",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3790#msg3790",
"date": "2010-07-17T19:22:47Z",
"text": "Maybe he's trying to cause panic selling through rumor and hearsay. Wouldn't be the first time someone's tried.
",
"nested_level": 0
},
{
"id": 1341,
"thread_id": 115,
"source_id": "16",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3793#msg3793",
"date": "2010-07-17T19:49:57Z",
"text": "I can't see whats malicious about his actions.
Hording bitcoins and selling them later to create inflation ?
So ? Wow, inflation, that's definitely something a free market can't handle ...
",
"nested_level": 0
},
{
"id": 1342,
"thread_id": 115,
"source_id": "17",
"poster_name": "BitcoinFX",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=30",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3811#msg3811",
"date": "2010-07-17T21:59:52Z",
"text": "Nenolod is a highly talented individual, coder and open source developer according to
http://nenolod.net/about/ where he indicates he has \"highly functional autism.\"
With the up most respect I welcome his 'actions' to openly challenge Bitcoin. As the technical director of
http://www.systeminplace.net/ he certainly has the processing power to back-up the claims.
I cannot imagine that a founding member of
http://atheme.org/ has malicious intent against Bitcoin. I'm sure Nenolod is just 'testing' Bitcoin and will find a good use for all those Bitcoins !
~ Anyone who destroys 'money' in the name of art or otherwise will always regret it...
See: K Foundation Burn a Million Quid -
http://en.wikipedia.org/wiki/K_Foundation_Burn_a_Million_Quid Maybe he's trying to cause panic selling through rumor and hearsay. Wouldn't be the first time someone's tried.
Cause a panic or a problem and then take advantage of the confusion to push through your agenda...
hmmmmm...where have I heard that before?
http://twitter.com/nenolodbitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.
11:34 AM Jul 15th via web
I'm curious about that. Is this why bitcoinexchange.com is down ?
",
"nested_level": 0
},
{
"id": 1345,
"thread_id": 115,
"source_id": "20",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3855#msg3855",
"date": "2010-07-18T01:37:53Z",
"text": "http://twitter.com/nenolodbitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.
11:34 AM Jul 15th via web
I'm curious about that. Is this why bitcoinexchange.com is down ?
He probably exchanged more bitcoins than the exchange has cash reserves ....
I thought there was a daily limit on the amount of bitcoins you could exchange at one time?
bitcoin exchange has been down for a while. I don't think it has anything to do with him.
",
"nested_level": 0
},
{
"id": 1347,
"thread_id": 115,
"source_id": "22",
"poster_name": "kosovito",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=158",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3860#msg3860",
"date": "2010-07-18T01:48:41Z",
"text": "as expected, bitcoin difficulty cranked up to 181.5. this basically takes the little man out of the equasion...
I am really worried about this....
I'm not. It will adjust downward again once he takes his node offline.
",
"nested_level": 0
},
{
"id": 1349,
"thread_id": 115,
"source_id": "24",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3872#msg3872",
"date": "2010-07-18T02:12:23Z",
"text": "Bitcoin is not about generating coins and sell them for money.
Bitcoin is about trading and people should start seeing it this way.
Of course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you.
",
"nested_level": 0
},
{
"id": 1350,
"thread_id": 115,
"source_id": "25",
"poster_name": "eugene2k",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=469",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3874#msg3874",
"date": "2010-07-18T02:16:30Z",
"text": "Hmm... think I'll rent a few servers too for easy money...
",
"nested_level": 0
},
{
"id": 1351,
"thread_id": 115,
"source_id": "26",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3885#msg3885",
"date": "2010-07-18T02:41:44Z",
"text": "http://twitter.com/nenolodbitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.
11:34 AM Jul 15th via web
I'm curious about that. Is this why bitcoinexchange.com is down ?
BTW, Nenolod writes on Twitter:
bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.
He hasn't sold anything at BitcoinExchange.com and the service is down just for technical maintenance. Should be up today or tomorrow. Maybe he meant that 1500 \u0080 was the rate for the 84,732 BTC he supposedly has.
Hmm... think I'll rent a few servers too for easy money...
You actually found servers to rent at a price to make this profitable?
His stated goal of bankrupting the exchanges is where I think his basic mistake is. I don't think he realizes that bitcoinmarket is not an exchange in the same way bitcoinexchange is. It's a market place and if he sells enough bitcoins to exhaust the current demand he will make the price go down, for a while, but he won't be making any real difference. He will make himself some money, but he seems to be doing so at the expense of his server clients, which is pretty poor business practices and I hope it is pointed out to them.
",
"nested_level": 0
},
{
"id": 1354,
"thread_id": 115,
"source_id": "29",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg3912#msg3912",
"date": "2010-07-18T03:52:44Z",
"text": "Bitcoin is not about generating coins and sell them for money.
Bitcoin is about trading and people should start seeing it this way.
Of course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you.
operation: bankrupt the bitcoin exchanges is now underway.
LOL
Though, I'm not sure how an exchange can be \"bankrupted\". Any trade should always be zero-sum or profitable for an exchange; only the individual players should possibly lose out. That is, unless the exchange itself is doing their own trades and not simply acting as a mediator.
Bitcoin is not about generating coins and sell them for money.
Bitcoin is about trading and people should start seeing it this way.
Of course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you.
operation: bankrupt the bitcoin exchanges is now underway.
LOL
Though, I'm not sure how an exchange can be \"bankrupted\". Any trade should always be zero-sum or profitable for an exchange; only the individual players should possibly lose out. That is, unless the exchange itself is doing their own trades and not simply acting as a mediator.
Yep, that was my point. The only exchange that isn't just a mediator is, I believe, bitcoinexchange.com
So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.
His name is William Pitock aka Nenolod
http://twitter.com/nenolodWhat do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.
If he does, we all loose.
I hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.
Also, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3
so I can prove him he's wrong.
Please discuss the issue.
I'm 100% certain that he isn't really generating that much and I'll leave it at that.
Hmm... think I'll rent a few servers too for easy money...
You actually found servers to rent at a price to make this profitable?
Not sure as I have no idea what their output will be, but for the sake of experiment...
So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.
His name is William Pitock aka Nenolod
http://twitter.com/nenolodWhat do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.
If he does, we all loose.
I hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.
Also, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3
so I can prove him he's wrong.
Please discuss the issue.
I'm 100% certain that he isn't really generating that much and I'll leave it at that.
I agree, there are many things about his statements which don't seem to be in line with reality. In particular his quoted generation rates are not divisible by 50.
when you modulo-devide it trough 50, the rest could be from transaction fee, he's running ~1000 instances (or at least cores) of bitcoin, so the probability of him getting transaction fees is very high.
",
"nested_level": 0
},
{
"id": 1360,
"thread_id": 115,
"source_id": "35",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.",
"url": "https://bitcointalk.org/index.php?topic=431.msg4069#msg4069",
"date": "2010-07-18T21:24:40Z",
"text": "when you modulo-devide it trough 50, the rest could be from transaction fee, he'`s running ~1000 instances (or at least cores) of bitcoin, so the probability of he getting transaction fees is very high.
What amount does one have to send to incur a transaction fee though? I've send some large amounts around myself and never saw a fee?
Typically, over 25,000 BTC.
",
"nested_level": 0
},
{
"id": 1362,
"thread_id": 116,
"source_id": "1",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "BUG Report: Rounding glitch",
"url": "https://bitcointalk.org/index.php?topic=432.msg3748#msg3748",
"date": "2010-07-17T14:10:03Z",
"text": "Check this out...
I just installed 0.3.1 on two different machines and moved one bitpenny (0.01):
-= Before the transfer =-
[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo
{
\"balance\" : 1.150000000000,
\"blocks\" : 68717,
\"connections\" : 6,
\"proxy\" : \"\",
\"generate\" : false,
\"genproclimit\" : -1,
\"difficulty\" : 181.5432893640505
}
[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo
{
\"balance\" : 0.000000000000,
\"blocks\" : 68717,
\"connections\" : 22,
\"proxy\" : \"\",
\"generate\" : false,
\"genproclimit\" : -1,
\"difficulty\" : 181.5432893640505
}
-= AFTER the transfer =-
[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo
{
\"balance\" : 1.139999999999,
\"blocks\" : 68717,
\"connections\" : 10,
\"proxy\" : \"\",
\"generate\" : false,
\"genproclimit\" : -1,
\"difficulty\" : 181.5432893640505
}
[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo
{
\"balance\" : 0.010000000000,
\"blocks\" : 68717,
\"connections\" : 20,
\"proxy\" : \"\",
\"generate\" : false,
\"genproclimit\" : -1,
\"difficulty\" : 181.5432893640505
}
I personally think it is a display problem, but I can't be sure.. strange, no?
Both machines are running FreeBSD 7.2/amd64.
",
"nested_level": 0
},
{
"id": 1363,
"satoshi_id": 229,
"thread_id": 116,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: BUG Report: Rounding glitch",
"url": "https://bitcointalk.org/index.php?topic=432.msg3769#msg3769",
"date": "2010-07-17T16:06:12Z",
"text": "It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result. The only place where it uses floating point to represent money is returning a value in JSON-RPC.
1.139999999999 is longer than bitcoin can internally represent.
internally, it could only be:
1.13999999 or
1.14000000
1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.
The code is this:
(double)GetBalance() / (double)COIN.
(I can't think of an easy way to fix it at the moment)
",
"nested_level": 0
},
{
"id": 1364,
"thread_id": 117,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Privacy versus Safety: handling change",
"url": "https://bitcointalk.org/index.php?topic=434.msg3750#msg3750",
"date": "2010-07-17T14:13:46Z",
"text": "Here's how you can lose coins by backing up and restoring your wallet file:
Lets say you have one shiny 1,000 Bitcoin coin in your wallet (it's actually just a transaction for 1,000 bitcoins paid to a public key that's stored in your wallet).
You backup that file.
Now you spend 1 Bitcoin. Your shiny 1,000 BTC coin is broken into 1BTC, plus 999BTC in change. That change is given a new, different public key.
Now if you restore your wallet file, Bitcoin sees that the 1,000BTC coin has been spent-- 1BTC was sent somewhere, and the other 999BTC was sent somewhere else. Because you don't have the key for the 999BTC, it has no idea that those coins belong to you.
So they're lost.
Trying out alternative policies for handling change on the TEST network would be a good idea, in my opinion.
Maybe change transactions should always get signed with the same public key, so you wouldn't lose coins when restoring your wallet... although that would give you less privacy because it would tend to tie all your transactions together.
Maybe your wallet should get initially populated with 100 \"change\" addresses, with one randomly chosen as needed. And some super-geeky way of replacing them with another, new, 100 addresses.
Maybe there's an even better way of handling the \"I lost BTC when I restored my wallet\" problem; ideas?
",
"nested_level": 0
},
{
"id": 1365,
"thread_id": 117,
"source_id": "2",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Privacy versus Safety: handling change",
"url": "https://bitcointalk.org/index.php?topic=434.msg3755#msg3755",
"date": "2010-07-17T14:25:28Z",
"text": "Isn't this just a result of restoring to an out of date backup?
That aside,
Simple possible change return methods:
a) change gets returned to the address it came from.
b) change gets returned to a newly generated bitcoin address.
Most people wont care and will expect the a) behavior, so make this the default.
Those who care about the privacy of their transactions can enable b) through some option setting in the client.
",
"nested_level": 0
},
{
"id": 1366,
"satoshi_id": 230,
"thread_id": 117,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Privacy versus Safety: handling change",
"url": "https://bitcointalk.org/index.php?topic=434.msg3770#msg3770",
"date": "2010-07-17T16:27:39Z",
"text": "We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.
There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
",
"nested_level": 0
},
{
"id": 1367,
"satoshi_id": 232,
"thread_id": 118,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg3807#msg3807",
"date": "2010-07-17T21:35:51Z",
"text": "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 of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.
The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday. (if you have this update)
I'll probably put a checkpoint in each version from now on. Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.
",
"nested_level": 0
},
{
"id": 1368,
"thread_id": 118,
"source_id": "2",
"poster_name": "llama",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=270",
"subject": "Re: Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg3810#msg3810",
"date": "2010-07-17T21:56:25Z",
"text": "Satoshi,
The \"block lock\" is an interesting idea, and I'll have to think more about it. However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.
Instead, you should only lock in everything except the last thousand or so blocks (the exact number should be a subject of future inquiry). Maybe this is actually what you did?
Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?
",
"nested_level": 0
},
{
"id": 1369,
"satoshi_id": 235,
"thread_id": 118,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg3825#msg3825",
"date": "2010-07-17T22:54:24Z",
"text": "However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.
I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block.
Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?
Sorry, not yet, but I do want to make the initial block download faster.
...Everyone should upgrade to this version...
I use 0.3.0 beta for Windows.
- Do I need to deinstall it before 0.3.2 installation?
- What about my bitcoins I already generated? Do I need to backup them and restore after installation?
Do I need to deinstall it before 0.3.2 installation?
No, you don't.
What about my bitcoins I already generated? Do I need to backup them and restore after installation?
No, you don't, but it's always good to make a backup.
- Spanish translation by milkiway.
It looks great
FYI, 0.3.2 on Linux (Ubunu 10.04) the task bar icon no longer appears. It seems to run fine though.
",
"nested_level": 0
},
{
"id": 1374,
"thread_id": 118,
"source_id": "8",
"poster_name": "AndrewBuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=378",
"subject": "Re: Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg3991#msg3991",
"date": "2010-07-18T14:14:04Z",
"text": "Traktion, you could try running the client with -minimizetotray that seemed to work for me (10.04 as well). It will start minimized there so you need to click on it to get the main window but it seems to work after that.
-Buck
",
"nested_level": 0
},
{
"id": 1375,
"thread_id": 118,
"source_id": "9",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg3993#msg3993",
"date": "2010-07-18T14:28:14Z",
"text": "I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block.
Cool! How exactly are you analyzing the topography of the chain?
Traktion, you could try running the client with -minimizetotray that seemed to work for me (10.04 as well). It will start minimized there so you need to click on it to get the main window but it seems to work after that.
-Buck
Ah, that sorted it! Thanks! I guess the default has changed between the versions.
Anyone know where the changelist is, I'm curious to what was fixed/changed/etc.
",
"nested_level": 0
},
{
"id": 1378,
"satoshi_id": 241,
"thread_id": 118,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin 0.3.2 released",
"url": "https://bitcointalk.org/index.php?topic=437.msg4037#msg4037",
"date": "2010-07-18T18:58:21Z",
"text": "The change list is basically encompassed by what's listed in the first message. Everyone should upgrade to get the important security improvements.
Minimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again. You can still re-enable the option with \"-minimizetotray\" if you want to use it anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them. Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature.
",
"nested_level": 0
},
{
"id": 1379,
"thread_id": 119,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "adg",
"url": "https://bitcointalk.org/index.php?topic=441.msg3838#msg3838",
"date": "2010-07-18T00:20:04Z",
"text": "adgf
",
"nested_level": 0
},
{
"id": 1380,
"thread_id": 119,
"source_id": "2",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Did block generation crawl to a halt?",
"url": "https://bitcointalk.org/index.php?topic=441.msg3859#msg3859",
"date": "2010-07-18T01:48:21Z",
"text": "Say, the last 6 hours? They seem few and far between, maybe just a couple per hour? Confirmations are taking a long time. Did the super node take his computers offline?
http://nullvoid.org/bitcoin/statistix.phpThat says the last block was found over 50 minutes ago.
Maybe he pushed the difficulty level so high it will take a bit for the remaining nodes to generate?Apparently his supernode was doing the majority of the generating at one point.I would be interested if he posts on the forum or someone gets in contact with him how his experiment went?
How often does the difficulty get adjusted?
",
"nested_level": 0
},
{
"id": 1382,
"thread_id": 119,
"source_id": "4",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Did block generation crawl to a halt?",
"url": "https://bitcointalk.org/index.php?topic=441.msg3901#msg3901",
"date": "2010-07-18T03:23:03Z",
"text": "The difficulty gets reevaluated and adjusted every 2016 blocks.
",
"nested_level": 0
},
{
"id": 1383,
"thread_id": 119,
"source_id": "5",
"poster_name": "MacRohard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=478",
"subject": "Re: Did block generation crawl to a halt?",
"url": "https://bitcointalk.org/index.php?topic=441.msg3902#msg3902",
"date": "2010-07-18T03:24:28Z",
"text": "I created a realtime graph of the current block generation speed here;
http://titania.smutfairy.com/~rm/time.gifMacRohard: Cool graph. It would be nice if it should time on the x axis and number of blocks on the y
",
"nested_level": 0
},
{
"id": 1385,
"satoshi_id": 245,
"thread_id": 119,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Did block generation crawl to a halt?",
"url": "https://bitcointalk.org/index.php?topic=441.msg4095#msg4095",
"date": "2010-07-18T23:35:27Z",
"text": "Nice graph! A moving average to smooth it out would be nice.
http://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24 hours, or 8.8 per hour.
I've managed to set up dependencies and build bitcoin with MS Visual C++ 2008 Express Edition. I'll give 2010 a try at some time.
There is a custom allocator class in serialize.h, secure_allocator, that fails to build with non-debug runtime selected. It is my understanding allocator classes require a template copy constructor, I've attached a small patch that solves the problem.
As Satoshi noted elsewhere, the MSVC build is indeed significantly slower khash/s-wise (more than twice) than the prebuilt one (MinGW?), even though I enabled the highest optimization level options and also global optimization with link-time code generation. I find that result strange, since MSVC is not known to have significantly worse optimizer than GCC's. Most probably the problem can be traced to the sha module that is extracted from Crypto++. I find in Crypto++ SVN there are revised versions of the module, including x86/x64 assembly for SHA-256. Using the newer versions would involve reintegrating their dependencies, though. On that note, why aren't we using OpenSSL's SHA-2 hashing functions instead? Since we already use OpenSSL, this would be a better solution than to manually support a SHA module from another library.
",
"nested_level": 0
},
{
"id": 1387,
"satoshi_id": 243,
"thread_id": 120,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: MSVC build & SHA-256",
"url": "https://bitcointalk.org/index.php?topic=453.msg4068#msg4068",
"date": "2010-07-18T21:24:09Z",
"text": "OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256. SHA256 begins by wrapping your data in a specially formatted buffer. Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do. It's intended that the time is amortised if you were hashing many KB or MB of data. In BitcoinMiner, we format the buffer once and keep reusing it.
If you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great! (although, keep licensing in mind) The one we have is the only one I tried, so there's significant chance for improvement.
When I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256. That's a lot of time for them to come up with better stuff. SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be. Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.
(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)
",
"nested_level": 0
},
{
"id": 1388,
"thread_id": 121,
"source_id": "1",
"poster_name": "ArtemZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=496",
"subject": "Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg3992#msg3992",
"date": "2010-07-18T14:27:18Z",
"text": "Hi,
Since Ubuntu is most popular desktop linux distro why there are no repository or even builds of bitcoin client? I think someone should start to create something like repo with bitcoin's builds, better ppa on launchpad. It will be so cool to have native payment system in ubuntu, maybe one day bitcoin will be included in the main repository
",
"nested_level": 0
},
{
"id": 1389,
"thread_id": 121,
"source_id": "2",
"poster_name": "d1337r",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=449",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg3994#msg3994",
"date": "2010-07-18T14:35:11Z",
"text": "Well, If you can compile bitcoin and create a source DEB, you can set up a PPA.
",
"nested_level": 0
},
{
"id": 1390,
"thread_id": 121,
"source_id": "3",
"poster_name": "imnichol",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=483",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg4475#msg4475",
"date": "2010-07-20T15:55:24Z",
"text": "I'm actually working on setting up a PPA for bitcoin, but it also requires the dev branch of wxWidgets, so I've got to get that up first.
",
"nested_level": 0
},
{
"id": 1391,
"thread_id": 121,
"source_id": "4",
"poster_name": "Dark_Ghost",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=380",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg4545#msg4545",
"date": "2010-07-20T22:11:00Z",
"text": "keep us informed, i'm on ubuntu 10.04 64bit and i'd like to see a ubuntu specific build of bitcoin and bitcoind.
",
"nested_level": 0
},
{
"id": 1392,
"thread_id": 121,
"source_id": "5",
"poster_name": "imnichol",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=483",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg5059#msg5059",
"date": "2010-07-22T16:03:24Z",
"text": "Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet. Anyone who can throw some documentation my way would be awesome. Right now I'm trying a different strategy.
",
"nested_level": 0
},
{
"id": 1393,
"thread_id": 121,
"source_id": "6",
"poster_name": "melvster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=545",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg5069#msg5069",
"date": "2010-07-22T16:34:29Z",
"text": "Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet. Anyone who can throw some documentation my way would be awesome. Right now I'm trying a different strategy.
I run ubuntu on my desktop maybe I can help ...
EDIT: first time I've tried it, but I made a launch pad project here:
https://launchpad.net/bitcoin hopefully we can work out how to do ppa etc.
I run ubuntu on my desktop maybe I can help ...
EDIT: first time I've tried it, but I made a launch pad project here:
https://launchpad.net/bitcoin hopefully we can work out how to do ppa etc.
I've got a launchpad ppa set up too, but launchpad is a huge PITA from what I've tried.
I've got bitcoin compiled for AMD64 linux. yay.
So now I've just got to figure out how to hack it so that I can package it as a deb.
",
"nested_level": 0
},
{
"id": 1396,
"thread_id": 121,
"source_id": "9",
"poster_name": "eugene2k",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=469",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg5649#msg5649",
"date": "2010-07-25T07:36:05Z",
"text": "Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet. Anyone who can throw some documentation my way would be awesome. Right now I'm trying a different strategy.
If I'm not mistaken, Ubuntu's PPA requires you to have your project uploaded in source form. Launchpad then compiles it and offers debs.
If I'm not mistaken, Ubuntu's PPA requires you to have your project uploaded in source form. Launchpad then compiles it and offers debs.
So do I have to do anything special to the source? I know that the standard method of building a .deb doesn't work, 'make -f makefile.unix' just spits out a binary. No chance to checkinstall or anything
Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet. Anyone who can throw some documentation my way would be awesome. Right now I'm trying a different strategy.
I run ubuntu on my desktop maybe I can help ...
EDIT: first time I've tried it, but I made a launch pad project here:
https://launchpad.net/bitcoin hopefully we can work out how to do ppa etc.
Would you add me to the maintainers of the project on launchpad? My username is cdecker and I have ready built deb packages from my efforts on openSuse Build Service
http://bit.ly/bUqiRYWell, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet. Anyone who can throw some documentation my way would be awesome. Right now I'm trying a different strategy.
I run ubuntu on my desktop maybe I can help ...
EDIT: first time I've tried it, but I made a launch pad project here:
https://launchpad.net/bitcoin hopefully we can work out how to do ppa etc.
Would you add me to the maintainers of the project on launchpad? My username is cdecker and I have ready built deb packages from my efforts on openSuse Build Service
http://bit.ly/bUqiRYSure!
I've created a team
Added you ..
Has anyone built a package for the GUI client yet?
",
"nested_level": 0
},
{
"id": 1401,
"thread_id": 121,
"source_id": "14",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg7019#msg7019",
"date": "2010-08-02T15:41:04Z",
"text": "Has anyone built a package for the GUI client yet?
GUI builds are quite a bit harder since they also require WX to be built along with it.
I'll try to create a statically linked version on OBS soon.
Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk
",
"nested_level": 0
},
{
"id": 1403,
"thread_id": 121,
"source_id": "16",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Builds for Ubuntu?",
"url": "https://bitcointalk.org/index.php?topic=454.msg7284#msg7284",
"date": "2010-08-03T17:54:46Z",
"text": "Has anyone built a package for the GUI client yet?
I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)
Not a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way.
I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)
Not a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way.
Yeah I've built the binaries before, I want to be able to upgrade via the update manager rather than manually downloading the binaries.
I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)
Not a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way.
Yeah I've built the binaries before, I want to be able to upgrade via the update manager rather than manually downloading the binaries.
Oh you mean official binaries in package form hosted by the Ubuntu folks?
Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk
Yes, 0.3.7 has it. It was in rev 112.
I don't seem to be able to find any md5s for your code downloads. Is it just me, or are there none?
",
"nested_level": 0
},
{
"id": 1408,
"thread_id": 122,
"source_id": "2",
"poster_name": "Mionione",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=334",
"subject": "Re: md5?",
"url": "https://bitcointalk.org/index.php?topic=458.msg4060#msg4060",
"date": "2010-07-18T20:52:19Z",
"text": "md5 checksums are still widely used but not secure
",
"nested_level": 0
},
{
"id": 1409,
"thread_id": 122,
"source_id": "3",
"poster_name": "Mionione",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=334",
"subject": "Re: md5?",
"url": "https://bitcointalk.org/index.php?topic=458.msg4070#msg4070",
"date": "2010-07-18T21:33:47Z",
"text": "md5 is evil, two differents files can have the same md5 checksum (
http://www.coresecurity.com/content/md5-harmful)
but unfortunately people still use it ;(
They can, but the odds that you'll get useful exploit code that just happens to be that collision are still insanely high.
Nah, it's insanely easy nowadays. Have you seen evilize?
http://www.mscs.dal.ca/~selinger/md5collision/Yeah... In earlier days, you could easily set an 8-letter Upper-Lower-Digit password and be sure no one will be interested in cracking it (which he will do for 30 days minimum). Now, we have Playstation 3's and cloud services, and cracking that MD5 is a matter of minutes or hours. Now i'll have to change every my password to something stronger.
BTW, SMF FTW, cause it uses SHA-256 instead of MD5.
",
"nested_level": 0
},
{
"id": 1413,
"thread_id": 122,
"source_id": "7",
"poster_name": "fresno",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=507",
"subject": "Re: md5?",
"url": "https://bitcointalk.org/index.php?topic=458.msg4496#msg4496",
"date": "2010-07-20T17:39:00Z",
"text": "Yeah, I guess SHA-256 will be good enough. ;-)
",
"nested_level": 0
},
{
"id": 1414,
"thread_id": 122,
"source_id": "8",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "gpg!",
"url": "https://bitcointalk.org/index.php?topic=458.msg5762#msg5762",
"date": "2010-07-25T21:16:03Z",
"text": "Hashes are good but it's already time to start doing gpg-signatures to tarball. Suffice it now to hack the site or even deception to obtain control over the wiki, put \"fresh\" version of the client and everything collapses.
",
"nested_level": 0
},
{
"id": 1415,
"satoshi_id": 276,
"thread_id": 122,
"source_id": "9",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: md5?",
"url": "https://bitcointalk.org/index.php?topic=458.msg5772#msg5772",
"date": "2010-07-25T22:06:57Z",
"text": "For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later.
http://www.bitcoin.org/Satoshi_Nakamoto.ascI 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 JSON-RPC port open
bitcoind -rpcpw=<password> -- daemon with password
If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too. I'm not sure but I think they may want to use different passwords for the two.
It gives a warning if you don't set a password.
All commands now require the password as the first parameter. It'll tell you that if you run \"bitcoind help\".
The central code:
// Check password
if (params.size() < 1 || params[0].type() != str_type)
throw runtime_error(\"First parameter must be the password.\");
if (params[0].get_str() != strRPCPassword)
{
if (strRPCPassword.size() < 15)
Sleep(50);
begin = strRequest.end();
printf(\"ThreadRPCServer incorrect password attempt\n\");
throw runtime_error(\"Incorrect password.\");
}
Any comments on these decisions?
1) if (strRPCPassword.size() < 15) Sleep(50); -- this means if it's a short password, it'll wait 50ms after each attempt. This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan. This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15. If you want to close the DoS possibility, just use a password 15 characters or longer.
2) begin = strRequest.end(); -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password. This is so you can't stuff it with millions of password attempts in one packet. What do you think, is this the right thing to do? (multiple invocation is probably almost never used anyway)
I also fixed the two duplicated commands listed in the help:
getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>
I guess it's ok for remotely doing it but if your concern is that someone else on the same unix machine can steal your bitcoins this still doesn't help because they can see your command line in /proc, top, ps etc. It could read the password on stdin or use readline or something, to guard against that particular thing at least. Allowing it to be passed on the command line is not good, in my opinion.
Even better might be to use a key file, then you can use unix permissions to make it readable to only that user, kind of like ssh does.. then the bitcoind could have an 'authorized_keys' file with the public keys. Anyway I don't mean to be an ass but the command line thing is just a false sense of security.
",
"nested_level": 0
},
{
"id": 1418,
"thread_id": 123,
"source_id": "3",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4131#msg4131",
"date": "2010-07-19T01:25:12Z",
"text": "I'm afraid I have to agree with laszlo here, using a certificate/keyfile would be far more secure. Saying that, thanks for adding some security to the JSON api
Right, that is quite a bit better.
Can you give me any examples of other stuff that does it that way? (and what the command line looks like)
The main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right? (any ideas what I should name the switch?)
",
"nested_level": 0
},
{
"id": 1420,
"thread_id": 123,
"source_id": "5",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4215#msg4215",
"date": "2010-07-19T12:02:39Z",
"text": "The Bitcoin Faucets (production and TEST) are now running with this change.
I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.
I'll try to do some research on how other projects tackle JSON-RPC authentication.
",
"nested_level": 0
},
{
"id": 1421,
"thread_id": 123,
"source_id": "6",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4221#msg4221",
"date": "2010-07-19T12:30:03Z",
"text": "The Transmission BitTorrent client does authenticated JSON-RPC; see \"Remote Control\" section of:
https://trac.transmissionbt.com/wiki/ConfigurationParametersE.g. setting.json file might look like:
{
\"rpc-enabled\":1
\"rpc-authentication-required\": 1,
\"rpc-password\": \"xxxxxxxxxx\",
\"rpc-port\": 9091,
\"rpc-username\": \"xxxxxxxxxx\",
\"rpc-whitelist-enabled\":1
\"rpc-whitelist\":\"127.0.0.1,192.168.*.*\"
}
It uses
HTTP 'basic' authentication (Authorization: basic base64(username:password) in the HTTP headers).
After further research... I think the Transmission approach, combined with the existing \"only allow connections from 127.0.0.1\" is a good short/medium-term solution.
Putting the username:password in a settings.json file in the Bitcoin directory aught to work nicely (since Bitcoin can already parse JSON). And keeping the authentication stuff off the command line and in the HTTP headers instead of the JSON request params is nice and clean.
Long term, the \"right\" way to do authenticated, secure JSON-RPC is with client-side certificates and https. But that looks like it would be a lot of work to implement and a
big learning curve for users to figure out how to generate client-side certificates and how to get both sides of the JSON-RPC connection using them. And I'm not even certain a full-blown client certificate solution would solve the problem of malicious Javascript making JSON-RPC requests via XMLHttpRequests to localhost; if the user installed the client certificate in the browser (because maybe there was a nifty JSON-RPC-powered web front-end to controlling Bitcoin), would the browser automatically send the client certificate if a malicious website made requests?
So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the \"no password is set\" warning, it could tell you where the file is and what to do.
What is the most popular and common settings file format?
HTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits? Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.
I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.
You're also confusing me, what do you mean? Did I do something unintended?
So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the \"no password is set\" warning, it could tell you where the file is and what to do.
What is the most popular and common settings file format?
You ask hard questions! Most common: probably
Windows INI files, because Windows is most common OS.
I'd lobby for using JSON; it's (mostly) a subset of YAML (which is a common choice for config files), so any JSON or YAML parser will read it.
HTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits?
I think the only big advantage is that it keeps authentication where it belongs in the transport layer, so if, in the future, you
do want to go with full-fledged HTTPS with certificates the API doesn't have to change.
I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.
You're also confusing me, what do you mean? Did I do something unintended?
No, I just confused \"command\" with \"parameter\", and did this:
> bitcoind help
error: First parameter must be the password.
> bitcoind <my password> help
error: unknown command: <my password>
>bitcoind help <my password>
... that works.
Should bitcoind be more of a system-wide daemon? With PAM authentication and support for all system users, not just the one running it?
Like scanning /home/*/.bitcoin folders for a wallet file and provide access by both username and system password...
",
"nested_level": 0
},
{
"id": 1426,
"thread_id": 123,
"source_id": "11",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4380#msg4380",
"date": "2010-07-19T22:53:12Z",
"text": "If you're using another JSON-RPC client that you wrote you can take care to protect the password, but using the bitcoin binary as the client and passing the password on the command line has the same issue as starting the daemon with it. It's still visible to every user that way.
So both the server and the client mode invocation need to use the file and not accept the password on the command line. Generally programs like this refuse to start if the mode on the file isn't 600 or something like that, because that means other users can read it.
",
"nested_level": 0
},
{
"id": 1427,
"satoshi_id": 250,
"thread_id": 123,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4577#msg4577",
"date": "2010-07-21T00:05:20Z",
"text": "Still need to know what's the most typical settings file format on Linux. Is there a standard file extension? I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes. I think what I usually see is like:
# comment
setting=value
Is there a settings file thing in Boost?
When you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?
Gavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters. (JSON-RPC is fine) Still under construction.
",
"nested_level": 0
},
{
"id": 1428,
"thread_id": 123,
"source_id": "13",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4582#msg4582",
"date": "2010-07-21T00:30:26Z",
"text": "You could do worse than using
yaml for the settings
I was researching config file formats, here's a comparison.
YAML is massive. I'm not sure there's a lightweight easy to build library we can integrate into our project. Seems overkill.
JSON is tempting and I'm inclined to like it, but two main sticking points:
1) No comments! How can you have a config file where you can't comment out a line to disable it?
2) Not very user friendly to have to \"quote\" all the strings, including the keys, and also have to remember the comma at the end of lines.
{
\"key\" : \"value\",
}
I suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or \"//\"?), concatenate them into a string and pass it to JSON, so you could go:
# comment
\"key\" : \"value\", # still have to remember the comma
\"key2\" : \"value\", // comment like this or both
Boost has boost::program_options.
We could read lines ourselves and feed them into a map<string, string> mapConfig.
while (!eof)
read line
if '#' found, truncate line
split line at first ':' -> key, value
mapConfig.insert(key, value)
If we use the syntax:
# comment
key : value
...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.
If we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed. If an option needs a list or more structured data, it could always parse its value as json:
key : [\"item1\", \"item2\", \"item3\"]
Although it has to be all on one line then.
I guess I'm leaning towards self parsed mapConfig:
# comment
key : value
",
"nested_level": 0
},
{
"id": 1430,
"thread_id": 123,
"source_id": "15",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4660#msg4660",
"date": "2010-07-21T06:52:43Z",
"text": "The simplest Linux config files typically have formats that look something like this:
# how often (in minutes) data is saved when all interface are offline
OfflineSaveInterval 30
# force data save when interface status changes (1 = enabled, 0 = disabled)
SaveOnStatusChange 1
# file used for logging if UseLogging is set to 1
LogFile \"/var/log/vnstat.log\"
# file used as daemon pid / lock file
PidFile \"/var/run/vnstat.pid\"
The standard extension, if there is one, is .conf. Hash (#) is the most common comment character by far. Semicolon (
and C-style comments crop up too.
I think a good, human-manipulatable config file that ISN'T part of the wallet would be a big step forward. There are a lot of options that are currently specified on the command line (noirc, for example, or -minimizetotray) which might be better specified in a config file.
Out of those options Satoshi presented, I'd go with the self parsed file with the key/value separator character being a space like lachesis suggested, especially if that's the typical format for at least one OS.
",
"nested_level": 0
},
{
"id": 1432,
"thread_id": 123,
"source_id": "17",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4709#msg4709",
"date": "2010-07-21T12:11:10Z",
"text": "I think there's no such thing a a \"typical\" settings file on Linux!
I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used \"key value\"
5 used \"key=value\" (actually, a couple were \"key = value\", allowing whitespace around the \"=\")
14 did their own thing.
The 14 that did their own thing were all over the map; from one-value-per-line to \"key:value\" to full-blown XML. # is
the universal comment character in the Linux world.
My vote would be for:
# comment
key1=value1
",
"nested_level": 0
},
{
"id": 1433,
"satoshi_id": 252,
"thread_id": 123,
"source_id": "18",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4758#msg4758",
"date": "2010-07-21T16:07:57Z",
"text": "I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used \"key value\"
5 used \"key=value\"
Thanks for that survey!
I find \"key value\" a little unnatural. There ought to be a more definite separator between key and value that suggests assignment. The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it. # seems more clear
key some full sentence with spaces in it. # than this
Allright then, lets go with self-parsed mapConfig, syntax:
# comment
key=value
file extension .conf. What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?
I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # \"this sentence would be this\"
key = value # guess this is ok too
nextkey = value
right = justified
The normal syntax should be \"key=value\", but you can't blame people for the occasional \"key = value\".
boost::program_options has the same \"key=value\" format. Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction. We can use more features if we want later.
Lets go ahead with HTTP basic authentication instead of password as a parameter.
",
"nested_level": 0
},
{
"id": 1435,
"thread_id": 123,
"source_id": "20",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4908#msg4908",
"date": "2010-07-22T01:11:26Z",
"text": "I volunteered to implement this, and made good progress today. Satoshi: I should have patches for you tomorrow.
Done: teach Bitcoin to read settings from {BITCOIN_DIR}/bitcoin.conf file, and added -conf=path_to_config_file.conf command-line option.
Done: teach Bitcoin RPC to require HTTP Basic authentication, and reject requests with the wrong username/password.
TODO: teach Bitcoin command-line RPC to add the Authorization: header. You won't have to give the username/password when controlling bitcoin from the command line, it'll read them from the bitcoin.conf file and Do the Right Thing.
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
TODO: limit password guessing attempts if the rpc.password is < 15 characters long.
TODO: update the JSON-RPC wiki page
After all that is done and I've sent patches to Satoshi, I'm going to add a couple more things to bitcoin.conf :
port= # to set the listen port (override default 8333)
rpc.port= # to set the JSON-RPC port (override default 8332)
With the existing -datadir option, that'll make it easier for me to run multiple bitcoins on one box.
",
"nested_level": 0
},
{
"id": 1436,
"thread_id": 123,
"source_id": "21",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4913#msg4913",
"date": "2010-07-22T01:27:46Z",
"text": "Excellent Gavin. We should start a list of proposed config file options in this thread.
I, for one, suggest a noirc (off by default) option and a minimizetotray option, both of which would do the same thing as the command-line switches by the same name. That'll stop the hackery of launching my Bitcoin with -minimizetotray each time. Also, maybe -server and -daemon should get similar options?
",
"nested_level": 0
},
{
"id": 1437,
"thread_id": 123,
"source_id": "22",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4918#msg4918",
"date": "2010-07-22T01:51:40Z",
"text": "I've implemented it so that all the command-line options can also be specified in the bitcoin.conf file.
Options given on the command line override options in the conf file. But I need to do more testing, especially with the \"multiargs\" options like \"addnode\".
",
"nested_level": 0
},
{
"id": 1438,
"satoshi_id": 254,
"thread_id": 123,
"source_id": "23",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg4928#msg4928",
"date": "2010-07-22T02:34:23Z",
"text": "TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.
In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(__WXMSW__) && wxUSE_GUI
MyMessageBox(\"Warning: rpc password is blank, use -rpcpw=<password>\n\", \"Bitcoin\", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, \"Warning: rpc password is blank, use -rpcpw=<password>\n\");
#endif
I've updated the
RPC wiki page for how the password stuff will work in Bitcoin 0.3.3.
One nice side effect: you can prepare for the changes now; create a bitcoin.conf file with a username and password and modify your JSON-RPC code to do the HTTP Basic Authentication thing. Old code will just ignore the .conf file and the Authorization: HTTP header.
Question for everybody: should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication? PHP and Python make is really easy-- just use the
http://user:pass@host:port/ URL syntax. I don't want to just duplicate the HTTP Basic authentication Wikipedia page.
Question for everybody: should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication? PHP and Python make is really easy-- just use the
http://user:pass@host:port/ URL syntax.
Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.
Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.
OK, I did Python and PHP, and I added what I know about Java. Can somebody who has used Java JSON-RPC update the wiki page with a working example?
The password definitely shouldn't be required. Also, the new code chokes on \"rpcpassword=\". If there's no config file, the config file doesn't contain an rpcpassword line, or it contains \"rpcpassword=\", the password should be disabled.
",
"nested_level": 0
},
{
"id": 1444,
"thread_id": 123,
"source_id": "29",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg5357#msg5357",
"date": "2010-07-23T18:51:34Z",
"text": "The password definitely shouldn't be required.
I strongly disagree; software should be secure by default, and running bitcoind without a password (or bitcoin -server) is definitely NOT secure.
I just don't see somebody saying \"Man, Bitcoin sucks because I have to add a password to a configuration file before running it as a daemon.\" I
can see somebody saying \"Man, Bitcoin sucks because I accidently ran it with the -server switch and somebody stole all my money.\"
I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain \"rpcpassword\", but what if it contains \"rpcpassword=\"?
I can see both points.
What if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library? Should they be able to explicitly disable the password requirement?
OTOH, what if there's a template conf file, with
rpcpassword= # fill in a password here
There are many systems that don't allow you to log in without a password. This forum, for instance. Gavin's point seems stronger.
BTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?
",
"nested_level": 0
},
{
"id": 1446,
"thread_id": 123,
"source_id": "31",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg5390#msg5390",
"date": "2010-07-23T21:18:05Z",
"text": "BTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?
Yes, that's right, rpcpassword is only required if you use -server or -daemon or bitcoind (I just tested to be sure).
RE: what if the programmer can't figure out how to make their legacy COBOL code do HTTP authentication?
Then I think another config file setting to explicitly turn off RPC authentication would be better than a magical \"if you set a blank rpcpassword then that turns off authentication.\" But I wouldn't implement that until somebody really does have a problem or until we have more than one way of doing the authentication (maybe https someday...).
lachesis: is supporting HTTP Basic Authentication a problem for you?
Gavin, no. I know my way around urllib2 so that's not a problem. I would like to see the option to disable password authentication in the bitcoin.conf. We really shouldn't be protecting (advanced) users from themselves.
I was just annoyed that to even start -server (albeit on my test client), I had to edit the config file and insert a password. I can always hack my version of Bitcoin to not require a password by default if that's what I want, but I don't like the fact that bitcoin completely fails to start when I put in \"rpcpassword=\" with -server. I think the right way to do it would be to warn users (perhaps with a popup box if the GUI is starting) but still start the other stuff, even if the RPC server won't start.
Running with a password only marginally improves the security for a lot of applications anyway, since that password will have to sit in an httpd-readable file for my web server to execute JSON-RPC commands. The only user that's ever been hacked on my server? httpd. It is an important step for machines with multiple users, though, as is allowing the port number to be changed.
",
"nested_level": 0
},
{
"id": 1448,
"thread_id": 123,
"source_id": "33",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg5738#msg5738",
"date": "2010-07-25T19:52:35Z",
"text": "I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
POST / HTTP/1.1
User-Agent: json-rpc/1.0
Host: 127.0.0.1
Content-Type: application/json
Content-Length: 40
Accept: application/json
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like \"bitcoin getinfo\" fail. The server still works fine with properly behaving clients.
This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
There's probably a more elegant solution, but that works for me. Here's a patch:
http://www.alloscomp.com/bitcoin/patches/bitcoin-svn-109-rpcbug-2010-07-25.patchWhilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
",
"nested_level": 0
},
{
"id": 1450,
"thread_id": 123,
"source_id": "35",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg5745#msg5745",
"date": "2010-07-25T20:30:16Z",
"text": "Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
The PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:
http://username:password@localhost:8332/Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?
Also, whilst we're on the subject is bitcoind only binding to the loopback interface?
The PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:
http://username:password@localhost:8332/Of course, you can specify the username and password as part of the URL
. Think a BC or two is deserved for that one
- sent.
Think a BC or two is deserved for that one
- sent.
Thank you sir.
If you are using PHP+JSON+CURL you can easily specify the user/pass with a curl_setopt() line. The parameter is \"CURLOPT_USERPWD\".
Thanks for the basic auth patch. Before the patch I was using uid/gid firewall lines to limit the bitcoind to only my special users/IPs that ran various scraps of code on crontabs. I'll likely still leave those protections in and just add in the basic http auth as well.
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(
http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
Hmm.. shouldn't it be using digest auth instead of basic auth?
I usually wrap everything into SSL or IPSec anyway, but digest auth might keep noobs from getting pwned so easily.
Digest auth is a fair bit harder to implement on both the client and the server side. It _should_ be using SSL and client certificates, but that's just a major PITA. Either that, or unix sockets.
",
"nested_level": 0
},
{
"id": 1457,
"thread_id": 123,
"source_id": "42",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: JSON-RPC password",
"url": "https://bitcointalk.org/index.php?topic=461.msg5759#msg5759",
"date": "2010-07-25T21:05:43Z",
"text": "Hmm... I implemented digest auth into a custom webserver I wrote a decade ago. From what I remember, it was fairly easy. However, client support back then was rather shoddy. It has improved a lot since then.
Perhaps we could document a simple stunnel + bitcoin configuration on the wiki then? Under a section called \"Securely using bitcoind from remote\"?
Just offering my 2c as usual.
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like \"bitcoin getinfo\" fail. The server still works fine with properly behaving clients.
This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
+1 to you for having such a long password that you found this bug.
Uploaded to SVN as rev 110.
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind ... inserts a newline every 64 characters
Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function:
diff --git a/rpc.cpp b/rpc.cpp
index 72bdc50..703b757 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -765,13 +765,14 @@ string EncodeBase64(string s)
BUF_MEM *bptr;
b64 = BIO_new(BIO_f_base64());
+ BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL);
bmem = BIO_new(BIO_s_mem());
b64 = BIO_push(b64, bmem);
BIO_write(b64, s.c_str(), s.size());
BIO_flush(b64);
BIO_get_mem_ptr(b64, &bptr);
- string result(bptr->data, bptr->length-1);
+ string result(bptr->data, bptr->length);
BIO_free_all(b64);
return result;
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(
http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong.
I hope it's not going to put up this much of a fight for all PHP users.
Looks like we've got the Fortran scenario already.
Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
SVN rev 111
Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.
We're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.
Update:
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
",
"nested_level": 0
},
{
"id": 1463,
"thread_id": 124,
"source_id": "2",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4265#msg4265",
"date": "2010-07-19T16:03:41Z",
"text": "satoshi: How many other developers do you have working with you?
Martin (another forum member and I) were talking about writing a .Net compatible library for integrating bitcoins into other programs.
",
"nested_level": 0
},
{
"id": 1464,
"thread_id": 124,
"source_id": "3",
"poster_name": "franzl",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=534",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4440#msg4440",
"date": "2010-07-20T11:07:52Z",
"text": "Martin (another forum member and I) were talking about writing a .Net compatible library for integrating bitcoins into other programs.
I think this is a very good idea! I also think it's important to have a PHP library since this is an important programming language for e-commerce sites. It would help a great deal in acceptance of bitcoin as a currency.
Franzl: >_> I abhor PHP, so I can't help you there, but some day (Completely overwhelmed with projects right now, but some day...) we might write the .net library.
",
"nested_level": 0
},
{
"id": 1466,
"thread_id": 124,
"source_id": "5",
"poster_name": "Axcella",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=514",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4511#msg4511",
"date": "2010-07-20T18:52:45Z",
"text": "this is the only computer i have at present i am working on getting a standalone for the bit coin program until then how do i retain the kash if the connection is lost?
",
"nested_level": 0
},
{
"id": 1467,
"thread_id": 124,
"source_id": "6",
"poster_name": "fresno",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=507",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4602#msg4602",
"date": "2010-07-21T01:42:34Z",
"text": "Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.
This sounds like something I would not like to have happen, but what does it mean? Let's face it, we're ALL generating Bitcoins on everything we can get hold of. What is the potential damage, in language my Mom might understand?
Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.
This sounds like something I would not like to have happen, but what does it mean? Let's face it, we're ALL generating Bitcoins on everything we can get hold of. What is the potential damage, in language my Mom might understand?
Malicious websites could have a javascript that steals all your coins.
You can still generate bitcoins, just don't run bitcoind or bitcoin -server or bitcoin -daemon on machine that you use to browse the Web.
As sirius says, if you do you could browse to a website that empties your Bitcoin wallet without your knowledge or permission.
",
"nested_level": 0
},
{
"id": 1470,
"thread_id": 124,
"source_id": "9",
"poster_name": "fresno",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=507",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4744#msg4744",
"date": "2010-07-21T15:27:49Z",
"text": "I'm full of dumb questions today: Are there any other conceivable problems? And would the daemon be protected of it were on a VM and/or chrooted? Thanks.
",
"nested_level": 0
},
{
"id": 1471,
"thread_id": 124,
"source_id": "10",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg4759#msg4759",
"date": "2010-07-21T16:10:32Z",
"text": "chroot: won't protect you.
Running as a separate VM: I think will protect you. But I thought browsers wouldn't allow XMLHTTPRequests to \"localhost\" from web pages fetched from the web, so my advice would be to test it. See if you can talk to the Bitcoin daemon from another VM on the same machine by running \"bitcoind getinfo\" or \"bitcoin getinfo\" on the non-bitcoin-vm.
",
"nested_level": 0
},
{
"id": 1472,
"satoshi_id": 263,
"thread_id": 124,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Warning: don't use -server or bitcoind on a machine where you web browse",
"url": "https://bitcointalk.org/index.php?topic=479.msg5432#msg5432",
"date": "2010-07-24T02:29:09Z",
"text": "The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.
",
"nested_level": 0
},
{
"id": 1473,
"thread_id": 125,
"source_id": "1",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4518#msg4518",
"date": "2010-07-20T21:02:02Z",
"text": "So, after a lot of experimentation, pulling out of hair, cursing of the developer, I finally managed to get a build of Bitcoin compiled under MSVC.
all optimizations are on including SSE2, LTCG and favouring of Intel64 (well hey, that's my processor)
Performance difference? The two builds I made (namely 32 and 64 bit) are practically equal in terms of performance - however, their performance is not equal to the stock build currently available.
On my quad-core with the stock Windows binary available from bitcoin.org I get about 1700k hashes a second. With the builds I produced under MSVC I get 2500K a second. Anyone interested?
",
"nested_level": 0
},
{
"id": 1474,
"thread_id": 125,
"source_id": "2",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4519#msg4519",
"date": "2010-07-20T21:04:36Z",
"text": "I am... would it be even faster on SSE3?
",
"nested_level": 0
},
{
"id": 1475,
"thread_id": 125,
"source_id": "3",
"poster_name": "ender_x",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=139",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4520#msg4520",
"date": "2010-07-20T21:05:29Z",
"text": "sure, I'd like to see if it removes my 20% difference from the linux bin's.
",
"nested_level": 0
},
{
"id": 1476,
"thread_id": 125,
"source_id": "4",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4530#msg4530",
"date": "2010-07-20T21:30:02Z",
"text": "So, after a lot of experimentation, pulling out of hair, cursing of the developer, I finally managed to get a build of Bitcoin compiled under MSVC.
all optimizations are on including SSE2, LTCG and favouring of Intel64 (well hey, that's my processor)
Performance difference? The two builds I made (namely 32 and 64 bit) are practically equal in terms of performance - however, their performance is not equal to the stock build currently available.
On my quad-core with the stock Windows binary available from bitcoin.org I get about 1700k hashes a second. With the builds I produced under MSVC I get 2500K a second. Anyone interested?
I've got a spare server using a 8-core 64-bit Intel - 64 bit Windows 2003 server. I'd be curious if there is a difference from the stock, the machine currently does about 5000khash/s, I'd be curious if the 64bit native build would be better.
I am... would it be even faster on SSE3?
potentially yes, I compiled it with the Microsoft compiler, I'm in the process of getting the Intel compiler so that could well offer a significant performance boost given that it supports far more instruction sets than MS's does.
Anyhow, I've uploaded the 2 binaries and the required DLLs to make them work and you can get them from
right here. After a bit of testing I found that the x64 binary does outperform the 32 bit by 100-200k or so but it does depend a lot on what other crap you have running on your system.
And if anyone feels generous...
18em7jEuKe1W74ChAZMFShUuqmwudWmpgusee my previous post.
Feedback on performance is appreciated, bitcoins even moreso.
",
"nested_level": 0
},
{
"id": 1480,
"thread_id": 125,
"source_id": "8",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4571#msg4571",
"date": "2010-07-20T23:52:41Z",
"text": "see my previous post.
Feedback on performance is appreciated, bitcoins even moreso.
I keep getting a \"MSVCR100.dll\" not found error when trying to start it. I copied the file over from another system into the system32 folder, but the program still can't find it for some reason. Do we need the full Microsoft dev environment installed to test it?
How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
",
"nested_level": 0
},
{
"id": 1482,
"thread_id": 125,
"source_id": "10",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4573#msg4573",
"date": "2010-07-20T23:57:07Z",
"text": "How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
I'll guinea pig, I'm running it on a test system that has no balance yet, well trying to run, it won't start.
It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins
This version has between 200-700 more khash per second on my machine.
It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins
This version has between 200-700 more khash per second on my machine.
No missing DLL errors when you try to start it?
It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins
This version has between 200-700 more khash per second on my machine.
correct, it's not a scam, the code is completely vanilla, I didn't obsfusicate it so you can feel free to examine it in the disassembler of your choice.
so, with my build you've gone from 5000k to 5700k?
Get visual C 2010 redist from Microsoft -- pointers here:
http://www.mydigitallife.info/2010/04/17/visual-c-2010-runtime-redistributable-package-x86-x64-ia64-free-download/The new code is full of win.. hash rate (4 core) went from 1350 to 1880 khash/s. Sweet!
For those that get the DLL error and don't want to install the full dev environment, you need to download the Visual C++ 2010 Redistributable x64 located
http://www.microsoft.com/downloads/details.aspx?FamilyID=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=enHow do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be
I can assure you the code is 100% clean.
that's very interesting, what processor/frequency are you on? x86 or x64?
Win7 64-bit
Intel Xeon 5130 (2.0GHz dual-proc)
I'll send you the first 50.0 it finds.
Nice job, this is just my initial testing, but the 64 bit compile speeds up hashing by over 28% so far over the 32 bit counterpart.
So for example, my 8-core system does (600 khash/s per core = 4800 khash/s) for normally, but now averages 5700 khash/s
I'll certainly be sending some bitcoins your way
Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.
",
"nested_level": 0
},
{
"id": 1494,
"thread_id": 125,
"source_id": "22",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4618#msg4618",
"date": "2010-07-21T02:52:40Z",
"text": "Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.
]
do you have the Visual C++ 2010 runtime installed? if not, that's why.
Does that apply for the x86 one also, since that's what I was using to test the 32bit build he had?
[edit] I just checked, it was good for the 32bit
no, that's definitely correct.
there is another possibility however... what processor is in your XP machine? if it doesn't support SSE2, it'll crash.
",
"nested_level": 0
},
{
"id": 1498,
"thread_id": 125,
"source_id": "26",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4622#msg4622",
"date": "2010-07-21T02:59:09Z",
"text": "Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.
]
do you have the Visual C++ 2010 runtime installed? if not, that's why.
Yes, straight from the download link on the previous page for x86.
I looked through the error log a little, didn't spot anything that stood out.
no, that's definitely correct.
there is another possibility however... what processor is in your XP machine? if it doesn't support SSE2, it'll crash.
Tested it a Celeron machine (1.1 GHz)
Good point, I'll see what the others do.
How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be
I can assure you the code is 100% clean.
Sorry to be so skeptical, but there was a victim on this site when someone claimed to have compiled a CUDA client that used the graphics processor to hash. One guy fell for it and lost some bitcoins.
But yes, if I get a chance I will look at the dlls I suppose before running it.
Or, maybe you can release the project files and we can compile it ourselves?
How do we know this is not a scam? Give us your IP to donate with or something so we can make sure you are reputable. I am scared to install it, it might steal my bitcoins.
If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be
I can assure you the code is 100% clean.
Sorry to be so skeptical, but there was a victim on this site when someone claimed to have compiled a CUDA client that used the graphics processor to hash. One guy fell for it and lost some bitcoins.
But yes, if I get a chance I will look at the dlls I suppose before running it.
Or, maybe you can release the project files and we can compile it ourselves?
Point well taken, but the CUDA never materialized, this one actually does what he said it does. So if it is a scam, it sure is taking a lot of effort.
I think he should really present to this devs to get credit for it and some BC because I'm going to send some to him for raising my khash/s up and beyond the already insane levels that I have.
For 32bit clients, this makes a huge speed increase (if your PC supports it)
I was using a little netbook to test with, it could manage about 185 khash/s but his compile does 238 khash/s so over a 28% increase (what I saw in the 64 bit clients), so another thumbs up for this build. (Exe size is smaller too
)
Here's a weird question.. has anyone actually generated a block with this faster version?
I have a few machines that used to regularly generate, and since switching to this version -- zip. I know these things are subject to random variation, and it could be a dry spell, and the difficulty is going up, but... could it be a bug?
",
"nested_level": 0
},
{
"id": 1505,
"thread_id": 125,
"source_id": "33",
"poster_name": "ichi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=316",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4788#msg4788",
"date": "2010-07-21T18:16:32Z",
"text": "Don't worry, getting BTC now requires supercomputers, clusters and/or botnets
Counterexamples, with Khash/s noted, welcome
Ichi: I got 2 blocks in a row back when I was running 1200khash. I'm up to 2500 now, as per the update, so we'll see if I get some more blocks. =)
",
"nested_level": 0
},
{
"id": 1507,
"thread_id": 125,
"source_id": "35",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4793#msg4793",
"date": "2010-07-21T18:50:30Z",
"text": "I did the same thing with VC++ 2008:
http://bitcointalk.org/index.php?topic=453.0As I wrote there, the results were slower than stock.
Haven't yet tried x64 or 2010 because rebuilding the dependencies/setting up is a hassle. Your builds give improvement over stock on my system though.
Curious.
It should be the sha.cpp module that matters. Did you modify the source in any way, or specify any special defines?
Hey, I just made this improvement that will vastly improve your khash/s!
In main.cpp, ~2751, change:
string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/1000.0);
to:
string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/300.0);
Then on ~2758, change:
printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/1000.0);
to:
printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/300.0);
(DISCLAIMER: THIS IS A JOKE.)
",
"nested_level": 0
},
{
"id": 1509,
"thread_id": 125,
"source_id": "37",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4800#msg4800",
"date": "2010-07-21T19:09:30Z",
"text": "Don't worry, getting BTC now requires supercomputers, clusters and/or botnets
Counterexamples, with Khash/s noted, welcome
Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night
My 300 khash laptop got lucky and produced one the first day I used Bitcoin.
Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night
My 300 khash laptop got lucky and produced one the first day I used Bitcoin.
That's good news. Thanks
Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night
My 300 khash laptop got lucky and produced one the first day I used Bitcoin.
I grabbed one on a 480-500 khash/sec machine last night too, so it's still doable. Also, that same machine is in the 530-550 range with this new build (32 bit). Sending some bit-love to Olipro right now. The effort's gotta be worth something. Nice work.
So --- Bitquux, that was Olipro's binary that found the coin?
",
"nested_level": 0
},
{
"id": 1513,
"thread_id": 125,
"source_id": "41",
"poster_name": "Bitquux",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=511",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4828#msg4828",
"date": "2010-07-21T20:32:00Z",
"text": "So --- Bitquux, that was Olipro's binary that found the coin?
Negative, that was before the switch. And at this rate, it will be a long time before I can tell if it will. Even if it's a dirty bin it's clever enough to earn a donation.
So --- Bitquux, that was Olipro's binary that found the coin?
Negative, that was before the switch. And at this rate, it will be a long time before I can tell if it will. Even if it's a dirty bin it's clever enough to earn a donation.
It shouldn't be dirty, the SHA256 is untouched and I don't think the compiler has introduced any errors.
It shouldn't be dirty, the SHA256 is untouched and I don't think the compiler has introduced any errors.
Yes, let me clarify. This is not a dirty bin. There is no reason so far to believe it's anything other than what Olipro says it is. The performance of my previously mentioned machine has even gone up since I first posted those numbers.
Here's a weird question.. has anyone actually generated a block with this faster version?
I have a few machines that used to regularly generate, and since switching to this version -- zip. I know these things are subject to random variation, and it could be a dry spell, and the difficulty is going up, but... could it be a bug?
Yes, about 10 so far. The other \"regular\" clients acknowledge test Coin transfer between the two, so far it appears good. I also have a packet sniffer running on my test machine and it's basically doing what the other clients do, nothing out of the ordinary so far.
This worked perfectly! On linux and windows if you compile yourself. I went from 380khash/s on one core to over 1200khash/s!
yeah, because dividing a number by 300 instead of 1000 makes it look a lot bigger, doesn't *actually* improve performance.
OK, I've made a new build of Bitcoin, this one is compiled using the Intel compiler which is considerably more advanced than the standard MS compiler.
Please note this build is 64-bit only since I see no reason to compile a build for 32-bit when most 32-bit processors lack the newer SSE instructions anyway.
Performance? my MSVC build averages about 2400K for me, this averages 2900K so you're looking at an improvement of about 125k per core or thereabouts although this does come at the cost of a larger EXE, improved performance is worth it in my opinion
My next goal is to see if this PolarSSL SHA256 algo really is faster. for now however,
download Bitcoin x64 ICC optimised build hereRuns about the same speed as the VC++ version here (Xeon, Win7 64-bit).
",
"nested_level": 0
},
{
"id": 1520,
"thread_id": 125,
"source_id": "48",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4964#msg4964",
"date": "2010-07-22T05:27:44Z",
"text": "OK, I've made a new build of Bitcoin, this one is compiled using the Intel compiler which is considerably more advanced than the standard MS compiler.
Please note this build is 64-bit only since I see no reason to compile a build for 32-bit when most 32-bit processors lack the newer SSE instructions anyway.
Performance? my MSVC build averages about 2400K for me, this averages 2900K so you're looking at an improvement of about 125k per core or thereabouts although this does come at the cost of a larger EXE, improved performance is worth it in my opinion
My next goal is to see if this PolarSSL SHA256 algo really is faster. for now however,
download Bitcoin x64 ICC optimised build hereAwesome, gives a 41% speed boost over the stock binary.
My experience so far.
Stock = Stock
Last x64 Build = 28% speed increase over stock
This x64 Build = 41% speed increase over stock
Nice stuff!
Runs about the same speed as the VC++ version here (Xeon, Win7 64-bit).
which Xeon, there's quite a few.
I don't think I need to point this out but here goes anyway: the significance of the performance benefit from using any of my builds will depend entirely on how many cores your computer has.
Also, in case anyone missed it: the PolarSSL algo is *not* faster.
next step... CUDA.
What would I expect for two Xeon 5570?
",
"nested_level": 0
},
{
"id": 1523,
"thread_id": 125,
"source_id": "51",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg4979#msg4979",
"date": "2010-07-22T07:43:34Z",
"text": "What would I expect for two Xeon 5570?
a 4 core processor with hyperthreading... and two of them? a pretty significant performance increase.
OK, I've made a new EXE, this one seems to get me an extra 100-200k (or about 25-50k per core).
Difference? I modified the ByteSwap function to operate on 64-bit integers; it does this by using the bswap intrinsic on a 64 bit register followed by rotate right through 32 bits to put the result in the correct order. it also initializes the SHA256 vectors using unsigned 64 bit values (however, the actual hashing still uses 32-bit so I doubt this is making much of a difference) and yes, I did convert the 32 bit numbers to 64 bit correctly (i.e. 0x12345678UL 0xabcdef0UL -> 0xabcdef012345678ULL) if that appears wrong to you, think about how little endian machines store 32 bit integers in memory.
anyway,
grab it hereWow, that tweaked one... I'm getting stunning rates. I have a quad core Intel laptop.
I have two different number sets, 1 while operating as usual, with other programs running, and one while everything but bitcoin (including explorer.exe) is shut down.
| Stock: | x64 v1 | x64 v2 | x64 v2 Tweaked |
| Standard Usage: | 500-1200 | 1000-1800 | 750-1500 | 2200-2700 |
|
| Optimized Usage: | 1500-1800 | 2000-2500 | 1500-2000 | 2700-3400 |
O_O
May I kindly ask you, mighty Olipro, to patch bitcoin 0.3.1 or may be 0.3.2? There were some issues in 0.3
",
"nested_level": 0
},
{
"id": 1527,
"thread_id": 125,
"source_id": "55",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5037#msg5037",
"date": "2010-07-22T14:51:11Z",
"text": "OK, I've made a new EXE, this one seems to get me an extra 100-200k (or about 25-50k per core).
Difference? I modified the ByteSwap function to operate on 64-bit integers; it does this by using the bswap intrinsic on a 64 bit register followed by rotate right through 32 bits to put the result in the correct order. it also initializes the SHA256 vectors using unsigned 64 bit values (however, the actual hashing still uses 32-bit so I doubt this is making much of a difference) and yes, I did convert the 32 bit numbers to 64 bit correctly (i.e. 0x12345678UL 0xabcdef0UL -> 0xabcdef012345678ULL) if that appears wrong to you, think about how little endian machines store 32 bit integers in memory.
anyway,
grab it hereI'll give this one a run, the last build would crash randomly after a few hours
May I kindly ask you, mighty Olipro, to patch bitcoin 0.3.1 or may be 0.3.2? There were some issues in 0.3
my builds are from the latest SVN source code, of course, had you checked the about page, you would notice it clearly states itself as 0.3.2
hmmmmm, that's strange... because I am experiencing the problem already fixed in
http://bitcoin.svn.sourceforge.net/viewvc/bitcoin?view=revision&revision=102then either it got re-broken or he also modified something in wxWidgets itself which I don't have.
on an unrelated note: I have CUDA working for SHA256 hashing... currently the host has to iterate the nonce so performance is terrible, working on moving the whole kit and kaboodle into the card and then performance should be pretty damn sexy.
DEFINITELY in to test CUDA!
",
"nested_level": 0
},
{
"id": 1532,
"thread_id": 125,
"source_id": "60",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5085#msg5085",
"date": "2010-07-22T17:26:39Z",
"text": "Oli: One alternative is to start the CUDA part hashing with a nonce of MAXINT and subtract one, and the host client start at one and go upwards. Then, either one could find a hash and you're not repeating work.
",
"nested_level": 0
},
{
"id": 1533,
"thread_id": 125,
"source_id": "61",
"poster_name": "ichi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=316",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5097#msg5097",
"date": "2010-07-22T18:30:17Z",
"text": "Wow, that tweaked one... I'm getting stunning rates. I have a quad core Intel laptop.
I have ... one while everything but bitcoin (including explorer.exe) is shut down.
| Stock: | x64 v1 | x64 v2 | x64 v2 Tweaked |
| <snip> |
| Optimized Usage: | 1500-1800 | 2000-2500 | 1500-2000 | 2700-3400 |
On a Quad-Core AMD Opteron 2376 server running Ubuntu 10.04 Desktop x64 (wubi) and Bitcoin 0.3.0 x64, I get ~2,200 khash/s. With Bitcoin 0.3.0 x86, I get ~2,000 khash/s. What would I expect running Windows Server 2008 x64 and Olipro's x64 v2 Tweaked?
Is it faster than the stock Linux x64 build? Could the Linux build be similarly tweaked?
Ichi: Probably pretty fast, I saw a huge increase in performance to the tweaked version. No tellin until you try it though.
",
"nested_level": 0
},
{
"id": 1535,
"thread_id": 125,
"source_id": "63",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5124#msg5124",
"date": "2010-07-22T20:00:49Z",
"text": "I'll give this one a run, the last build would crash randomly after a few hours
same here,
MSVC build didnt work at all (missing DLL even after vcredist_x64 install),
Intel build seems to work fine for 1-2hours and then crashes.
I get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.
Update: this one seems to crash even faster, 30minutes first run, almost 1hour second run
I'll give this one a run, the last build would crash randomly after a few hours
same here,
MSVC build didnt work at all (missing DLL even after vcredist_x64 install),
Intel build seems to work fine for 1-2hours and then crashes.
I get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.
Update: this one seems to crash even faster, 30minutes first run, almost 1hour second run
the missing DLL is in my first release (libeay32.dll)
Vista x64 here
From regular version ~1700khash/s to this version ~2300khash/s (last versios posted here)
Really nice, but i think need to be more stable
",
"nested_level": 0
},
{
"id": 1538,
"thread_id": 125,
"source_id": "66",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5155#msg5155",
"date": "2010-07-22T22:33:54Z",
"text": "Vista x64 here
From regular version ~1700khash/s to this version ~2300khash/s (last versios posted here)
Really nice, but i think need to be more stable
given that it's based on stock code and I doubt there's an issue with the compiler, it's more likely there's a bug in the SVN source, I'll make a build from the last stable production version just as soon as I've finished this CUDA code off.
I'll give this one a run, the last build would crash randomly after a few hours
same here,
MSVC build didnt work at all (missing DLL even after vcredist_x64 install),
Intel build seems to work fine for 1-2hours and then crashes.
I get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.
Update: this one seems to crash even faster, 30minutes first run, almost 1hour second run
the missing DLL is in my first release (libeay32.dll)
thats not the one causing MSVC build not to work, that'd be MSVCR100.dll.
anyway, the Intel build does work, although it crashes.
keep coding, i'm looking forward to test a cuda-version on my gtx260.
My experience is similar, the first release was rock solid like the original client, the other releases, while still faster, randomly crash after minutes/hours/days so it's kind of random.
So it's a trade off between stability and speed. The faster it gets, the less stable it seems.
Of course, I have mine on a batch to restart if there is a crash and to count how many times the program crashed during the day for example. So far up to about 2 crashes a day.
There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S
",
"nested_level": 0
},
{
"id": 1542,
"thread_id": 125,
"source_id": "70",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5413#msg5413",
"date": "2010-07-24T00:19:34Z",
"text": "There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S
Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.
Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.
There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S
Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.
Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.
that's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something.
There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S
Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.
Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.
that's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something.
Yes, sorry, I left that part out, the Linux servers (same hardware) always generate higher khash/s than the windows machines, at least mine do. Your mileage may vary.
There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S
Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.
Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.
that's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something.
Yes, sorry, I left that part out, the Linux servers (same hardware) always generate higher khash/s than the windows machines, at least mine do. Your mileage may vary.
On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build.
On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build.
OK. Could someone please explain the why of that, in terms that a non-programmer can understand? Why is the stock Windows build slower than the stock Ubuntu build?
On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build.
OK. Could someone please explain the why of that, in terms that a non-programmer can understand? Why is the stock Windows build slower than the stock Ubuntu build?
Optimizations mainly. When the program is being compiled on Windows, certainly optimizations make the program more efficient.
On Linux, we have both 32bit and 64bit builds to take advantage of the 64bit arch of the system. On windows, there was only a 32bit build.
Thank you. I'm glad that I'm moving to Ubuntu.
",
"nested_level": 0
},
{
"id": 1549,
"thread_id": 125,
"source_id": "77",
"poster_name": "Bitcoiner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=269",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5640#msg5640",
"date": "2010-07-25T06:13:57Z",
"text": "Thank you. I'm glad that I'm moving to Ubuntu.
I still prefer windows 7 for many things, but I am liking Ubuntu more and more. If only some things weren't such a pain in the ass to use (Tor: Windows 7? 1 minute install. Ubuntu? WTF...)
I really like Windows Server 2008, which is pretty close to Windows 7. It'll be a while before I give that up.
OTOH, I'm thinking very seriously re going with Ubuntu for my next primary desktop. As a test, I've recently installed Ubuntu 10.04 Server x64 + GNOME on an old Core 2 Quad machine. Everything except boot lives on an encrypted RAID5 array managed by LVM. Losing Excel 2007 might be a problem, though.
Although I don't use Tor, I'm sure that there must be many setup guides for Ubuntu.
This is way off topic. Sorry.
",
"nested_level": 0
},
{
"id": 1551,
"thread_id": 125,
"source_id": "79",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5695#msg5695",
"date": "2010-07-25T14:59:03Z",
"text": "I absolutely hate Ubuntu, mostly because of the community surrounding it. I much prefer gentoo, Debian, etc.
",
"nested_level": 0
},
{
"id": 1552,
"thread_id": 125,
"source_id": "80",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5727#msg5727",
"date": "2010-07-25T19:15:26Z",
"text": "mind if i ask?
satoshi has released a couple of updates recently, mostly about security concerns as far as i can see.
how are the 64bit versions keeping up with these developments?
Here is several builds based on the latest SVN code (0.3.3), it contains the following:
Visual Studio Builds in x86 and x64 flavour.
Intel Builds in x64 only, one with stock code and the other with the 64bit byte reversal/state init tweak since it seems to squeeze a few more drops of speed out of it.
grab it hereOK, I've made a new build now; this version uses the 64bit SHA256 Assembler code from Crypto++ which means the Byteswap function is now only used for re-ordering the resulting hash - and of course it's using 64-bit ASM to create the hash in the first place.
Performance? I've gone from an average of 2900k hashes on my previous builds up to a pretty stellar 3300k hashes (an improvement of about 100k per core) - I would be very surprised if the Linux builds outperform this.
Grab x64 Asm Optimised Bitcoin hereCan you release the source for these builds, please? I would very much like to look over the changes that you made.
",
"nested_level": 0
},
{
"id": 1556,
"thread_id": 125,
"source_id": "84",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5807#msg5807",
"date": "2010-07-26T03:11:09Z",
"text": "If you want the code, get Crypto++
",
"nested_level": 0
},
{
"id": 1557,
"thread_id": 125,
"source_id": "85",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5809#msg5809",
"date": "2010-07-26T03:17:27Z",
"text": "OK, so given that the SHA256 is now 100% assembler code, I figured I might as well just build it entirely using Visual Studio, so I did just that and performance was exactly the same.
So, for those of you who have found the VS builds to be more stable,
click here to get itafter tinkering around a bit and reinstalling the vcredist, i even got the VS build to work now.
on the regular client i get around 1600khash/sec, your latest VS build currently runs at ~2750khash/sec,
+70% that's an outstanding performance!
",
"nested_level": 0
},
{
"id": 1559,
"thread_id": 125,
"source_id": "87",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5814#msg5814",
"date": "2010-07-26T05:22:06Z",
"text": "OK, so given that the SHA256 is now 100% assembler code, I figured I might as well just build it entirely using Visual Studio, so I did just that and performance was exactly the same.
So, for those of you who have found the VS builds to be more stable,
click here to get itYeah, runs every bit as fast as the Intel tweaked ones from what I could tell in testing, plus the program is half the size compiled.
OK, now for some absolutely incredible performance.
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Grab SHA state caching Bitcoin hereWow, all I can say is once again the magic of optimizations and asm come through again. I went from 1300khash/s with the stock 0.3.3 to 3200khash/s with this latest build. My machine is running a dual-core Celeron 3300 @ 3.8ghz.
",
"nested_level": 0
},
{
"id": 1562,
"thread_id": 125,
"source_id": "90",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5818#msg5818",
"date": "2010-07-26T07:30:23Z",
"text": "Um.. Wow. That last one was a bit of a leap.
Intel Core i7-870 (2.93 GHz) running 4950 khash/s here. (4 cores Turbo'd to 3.2 GHz)
(Intel version)
Anyone seeing a speed difference between VS and Intel?
",
"nested_level": 0
},
{
"id": 1563,
"thread_id": 125,
"source_id": "91",
"poster_name": "ichi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=316",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5820#msg5820",
"date": "2010-07-26T07:40:54Z",
"text": "Wow. Thank you
Windows Server 2008 x64 VM in Hyper-V
4 cores
8 connections
stock 0.3.0 build => ~2,250 khash/s
Intel x64 build => ~5,600 khash/s
It was indeed a large jump, not sure how stable it will be in the long run but, we will find out. The stock client ran fine 24 on this machine so I will post back some time tomorrow. I am getting less khash/s with the vc build, around 2600khash/s. The intel build for me is pushing the most khash/s.
",
"nested_level": 0
},
{
"id": 1565,
"thread_id": 125,
"source_id": "93",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5824#msg5824",
"date": "2010-07-26T08:17:47Z",
"text": "It was indeed a large jump, not sure how stable it will be in the long run but, we will find out. The stock client ran fine 24 on this machine so I will post back some time tomorrow. I am getting less khash/s with the vc build, around 2600khash/s. The intel build for me is pushing the most khash/s.
yes, as I said, the Intel compiler produces far better code than the VS compiler does.
I'm a total newb, I tried to use Olipro's file and it failed because I was missing
MSVCR100.dll I got it, now it says \"The application was unable to start correctly.\" Should I just not mess with this? Is it supposed to be all good to go?
Just say Olipro's new thread. Got it working, so sweet.
",
"nested_level": 0
},
{
"id": 1567,
"thread_id": 125,
"source_id": "95",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5838#msg5838",
"date": "2010-07-26T12:01:45Z",
"text": "",
"nested_level": 0
},
{
"id": 1568,
"thread_id": 125,
"source_id": "96",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5853#msg5853",
"date": "2010-07-26T13:39:41Z",
"text": "OS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86.
OS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86.
the more cores your computer has, the more significant the performance boost, you should also use the EXE from the intel folder, the VS one is inferior but included for completeness.
OS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86.
the more cores your computer has, the more significant the performance boost, you should also use the EXE from the intel folder, the VS one is inferior but included for completeness.
I'm confused now, I don't see a VS or an Intel folder. When I unzipped vcredist_x64 I'm getting a bunch of numbered folders 1028, 1031, etc. I ran Setup and when I rerun it it just wants to repair Microsoft Visual C++ x64 Redistributable to it's original state each time.
I've also just noticed that it's getting incoming blocks like 3 or 4 at a time. It could be they're coming in close together, but I think I'm getting them like simultaneously.
EDIT: Okay, I see it now.
OK, now for some absolutely incredible performance.
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Grab SHA state caching Bitcoin hereWow, this is the biggest jump I've ever seen. Nearly a 250% increase in speed from the stock version, amazing. Now let's see how stable it is
I hit 2700, up from 1250 stock.
I have 7 cores, how do I tell how many it's using? Can I control it?
",
"nested_level": 0
},
{
"id": 1573,
"thread_id": 125,
"source_id": "101",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5866#msg5866",
"date": "2010-07-26T14:16:05Z",
"text": "I hit 2700, up from 1250 stock.
I have 7 cores, how do I tell how many it's using? Can I control it?
Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.
I hit 2700, up from 1250 stock.
I have 7 cores, how do I tell how many it's using? Can I control it?
Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.
Long time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.
I had to register to rebel against some of the crap I see been posted here!
They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has.
",
"nested_level": 0
},
{
"id": 1576,
"thread_id": 125,
"source_id": "104",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5887#msg5887",
"date": "2010-07-26T15:43:43Z",
"text": "I hit 2700, up from 1250 stock.
I have 7 cores, how do I tell how many it's using? Can I control it?
Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.
Long time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.
I had to register to rebel against some of the crap I see been posted here!
Every time he posts I want to poke him in the eye, the one conveniently posted to the left of his friendly well-meaning nonsense
They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has.
VMware only permits even numbers of processors/cores although I believe you can expose 8 cores and then configure the OS to only see 7.
if he really does have this setup, I'm going to bet that he's opted for more processors/cores than his CPU actually has (yep, you can do this but it will have a pretty negative effect on performance)
This is going off topic completely but, there is a very slim theoretical chance that you could have 7 cores on an amd machine. You could disable a core on a dual quad-core system or it might be possible to get another core or two by core unlocking (using the extra cores that are some times on amd cpus but,\"locked\"). Based on how many khash/s they are getting they do not have 7 cores or a running in a vm. If they do have 7 cores they should post a cpuz screenshot because, it would seem that we have an outlier in the performance boosts and it would be good to figure out why.
Back on topic, My desktop have been crunching away since last night @ 06:57 am forum time (9 hours) using the intel build, no crashes, blocks are coming in, and I have 29 connections.
",
"nested_level": 0
},
{
"id": 1579,
"thread_id": 125,
"source_id": "107",
"poster_name": "TG12",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=602",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5894#msg5894",
"date": "2010-07-26T16:05:59Z",
"text": "I hit 2700, up from 1250 stock.
I have 7 cores, how do I tell how many it's using? Can I control it?
Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.
Long time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.
I had to register to rebel against some of the crap I see been posted here!
Every time he posts I want to poke him in the eye, the one conveniently posted to the left of his friendly well-meaning nonsense
Ive only had one post . . . so far! OliPro love the work your doing with BitCoin
They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has.
VMware only permits even numbers of processors/cores although I believe you can expose 8 cores and then configure the OS to only see 7.
if he really does have this setup, I'm going to bet that he's opted for more processors/cores than his CPU actually has (yep, you can do this but it will have a pretty negative effect on performance)
I was thinking about Virtual Box when I wrote that
I've thought about dialing BitCoin down to 7 active cores on my desktop machine, just to keep one free for general lightweight UI use.
",
"nested_level": 0
},
{
"id": 1582,
"thread_id": 125,
"source_id": "110",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x64 for Windows",
"url": "https://bitcointalk.org/index.php?topic=501.msg5912#msg5912",
"date": "2010-07-26T18:11:26Z",
"text": "I've thought about dialing BitCoin down to 7 active cores on my desktop machine, just to keep one free for general lightweight UI use.
the BitCoin threads are automatically assigned low priority; as soon as any other processes want to use the CPU it will automatically lose CPU time
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Is that still starting from Crypto++? Lets get this into the main sourcecode.
I noticed from a hint that Satoshi dropped in the JSON-RPC password thread about so-called \"Multiple Invocation\" support in Bitcoin's JSON-RPC.
As I run a site that polls bitcoind for payments to a large number of addresses twice a minute, I was intrigued. First of all, this isn't JSON-RPC 2.0's \"Batch\" support, where requests are submitted in an array and responses are received the same way:
request = [
{\"jsonrpc\": \"2.0\", \"method\": \"sum\", \"params\": [1,2,4], \"id\": \"1\"},
{\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42,23], \"id\": \"2\"},
{\"jsonrpc\": \"2.0\", \"method\": \"get_data\", \"id\": \"9\"}
]
response = [
{\"jsonrpc\": \"2.0\", \"result\": 7, \"id\": \"1\"},
{\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": \"2\"},
{\"jsonrpc\": \"2.0\", \"result\": [\"hello\", 5], \"id\": \"9\"}
]
Instead, it's something different, and I can't figure out how to parse the responses in Python. Here's a screen capture of a telnet session to the Bitcoin RPC server:
$ telnet localhost 8332
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
POST / HTTP/1.1
Content-Type: text/plain
Content-Length: 97
{\"params\":[],\"id\":1,\"method\":\"getconnectioncount\"}
{\"params\":[],\"id\":2,\"method\":\"getdifficulty\"}
HTTP/1.1 200 OK
Connection: close
Content-Length: 33
Content-Type: application/json
Date: Sat, 08 Jul 2006 12:04:08 GMT
Server: json-rpc/1.0
{\"result\":8,\"error\":null,\"id\":1}
HTTP/1.1 200 OK
Connection: close
Content-Length: 49
Content-Type: application/json
Date: Sat, 08 Jul 2006 12:04:08 GMT
Server: json-rpc/1.0
{\"result\":181.5432893640505,\"error\":null,\"id\":2}
Connection closed by foreign host.
As you can see, the server replies with two complete HTTP 200 responses instead of (as I would have expected) one response with the two lines concatenated as I did in the request.
I can't figure out how to parse that with anything at all semi-automated in Python. urllib2 and httplib both return after the first response and drop the second one on the floor.
Has anyone encountered this problem before? Does anyone know of a Python library that can handle this strange multi-request behaviour?
Alright, I know it hasn't been more than an hour since I last posted about this, but I decided to solve this problem myself.
If there's a better solution out there, I'd be glad to hear it, but here's my version 0.1 attempt to make this work:
http://www.alloscomp.com/bitcoin/btcjsonrpc.pysLet me know if you like it, hate it, or see any obvious flaws with it. There's some getting started docs in the source, but here's the code of the test suite:
from btcjsonrpc import Service
s = Service()
print 'preparing getbalance; id:',s.getbalance() # Each call returns its ID so you can find it later in the results
print 'preparing getdifficulty; id:',s.getdifficulty()
print 'preparing listreceivedbyaddress; id:',s.listreceivedbyaddress(10000) # Call with a parameter
print 'preparing getbalance; id:',s.getbalance(id='getbalance 2') # You can also specify your own ID
print '\nexecuting call\n\nresults:'
results = s() # Get the results by calling the Service object
for id,value in results.iteritems():
print id,value
# If you'd prefer to work directly with the JSON responses instead of a dict of IDs, then access the list Service.responses.
print '\njson responses'
print s.responses
And here's the output, including the docstr:
$ ./btcjsonrpc.py
Socket-based, Bitcoin-compatible JSON-RPC v1.0 client.
By: Eric Swanson (http://www.alloscomp.com/bitcoin)
Version 0.1, July 21, 2010
Don't use this for one-off request->response pairs. Use something like the reference python-jsonrpc library, or urllib2 + json. This client is hackish, but it works for me (and has sped up my JSON-RPC accesses tremendously).
For details of WHY exactly I felt the need to redo python-jsonrpc using a raw socket, check out the follow forum post: http://bitcointalk.org/index.php?topic=528.0
Usage is fairly straightforward, and a code sample can be found below the library code (in the if __name__=='__main__' clause).
preparing getbalance; id: jss-1
preparing getdifficulty; id: jss-2
preparing listreceivedbyaddress; id: jss-3
preparing getbalance; id: getbalance 2
executing call
results:
jss-2 181.543289364
jss-3 []
getbalance 2 2345.94
jss-1 2345.94
json responses
[{u'id': u'jss-2', u'result': 181.54328936405051, u'error': None}, {u'id': u'jss-3', u'result': [], u'error': None}, {u'id': u'getbalance 2', u'result': 2345.9400000000001, u'error': None}, {u'id': u'jss-1', u'result': 2345.9400000000001, u'error': None}]
Obviously it's a bug that it repeats the header.
I was trying to follow the 1.0 spec:
http://json-rpc.org/wiki/specification It called for multiple invocation.
I think they mean it's like this, but I'm not sure:
Post:
{\"method\": \"postMessage\", \"params\": [\"Hello all!\"], \"id\": 99}
{\"method\": \"postMessage\", \"params\": [\"I have a question:\"], \"id\": 101}
Reply:
{\"result\": 1, \"error\": null, \"id\": 99}
{\"result\": 1, \"error\": null, \"id\": 101}
I can't remember where I think I saw that it's supposed to send back HTTP status 500 for an error reply. If it contains multiple responses and one is an error, I wonder if that makes the status 500 for the whole thing, I guess so. Maybe it should always return 200. I think someone sounded like the 500 might be causing a problem.
This probably gets fixed after 0.3.3. Until then, just use single invocation. I wonder if any JSON-RPC package even supports multiple invocation, probably not.
It would be nice if we could pin down better how multiple-invocation is supposed to work, if at all, before trying to fix it, and whether returning HTTP status 500 for error response is right.
I'm curious about the developers feelings on scalability. For example, could the system handle a million users, doing say 5 transactions each per day. 5 million transactions per day is roughly 35,000 transactions per 10 minute period?
Is there a bottle neck in propagating 35,000 transactions to a million nodes for block generation? Or has that issue been designed for?
",
"nested_level": 0
},
{
"id": 1588,
"thread_id": 127,
"source_id": "2",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg4968#msg4968",
"date": "2010-07-22T06:45:58Z",
"text": "
Large transaction rates are a key future bottleneck of the current bitcoin system.
",
"nested_level": 0
},
{
"id": 1589,
"thread_id": 127,
"source_id": "3",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg4970#msg4970",
"date": "2010-07-22T06:54:45Z",
"text": "
Large transaction rates are a key future bottleneck of the current bitcoin system.
Is this a completely connected network? Or is there some sort of ordered propagation scheme? Didn't read that section of code yet.
As far as I can tell, it's a completely connected network. And it kind of has to be for the security to work - the main idea is that an attacker needs nearly 50% of the computing power of the entire network to inject false transaction information into (or delete honest transactions from) the network. If there was a propagation system, you'd only need to to have about 50%+ of whatever the lowest rung is, and then the rung would be duped into transmitting your false information, possibly beating out the other lowest rungs to dupe the next higher up rung, and so on.
The bottleneck was my first reaction when I read about bitcoin. For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction. So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there. And since the blocks form a straight chain, all of those 35,000 transactions need to go into the same block (if block generation continues to average one per ten minutes). There's currently no way to split that up and have the network work on 350 blocks with 100 transactions each simultaneously, because each block needs the hash of the previous block. That seems particularly silly with the way bitcoin transactions are verified. If everyone waits for one to three blocks to verify a transaction before spending their bitcoins, that means that none of the 35,000 transactions in one ten minute period can depend on each other, and most shouldn't even depend on the previous block. And as far as I can tell, there's no way for the network to speed up block creation in response to transaction overload - if the network ever hit the point where transactions were being made faster than they were being hashed into blocks, the problem would snowball until enough people quit bitcoin out of frustration that the number of transactions dropped below block creation speed. And if block creation were to speed up (via difficulty decrease) then the reward for hashing a new block would have to go down to maintain the planned rate of bitcoin introduction. The nodes would have to know that during the Great Bitstorm of August 2013 blocks only netted the creator 2.5 bitcoins - and they'd have to figure it out during the Great Bitstorm of August 2013.
Also, there's a potential problem if block creation speed were to exceed the speed of information on the network. Chains could be built faster than they would be distributed to the rest of the network, which could mean that two different network segments could work on two different chains simultaneously.
And of course it's worse than 35,000 transactions / ten minutes - we'd probably see something like 50-60k+ transactions during peak hours (depending on how geographically distributed the network is) and much less during the off hours. There would be a need to dynamically throttle proof-of-work difficulty and coin reward hour-by-hour. Since bitcoin is computer based, there'll probably eventually be a fair number of automated systems buying and selling bitcoins - a sudden sharp fluctuation in stock markets or currency exchange rates could set those off all at once. (Although the verification system might help with this, since you can't do microsecond scale trading with bitcoins.)
",
"nested_level": 0
},
{
"id": 1591,
"thread_id": 127,
"source_id": "5",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5043#msg5043",
"date": "2010-07-22T15:09:19Z",
"text": "It's not a completely connected network in the sense that every client isn't connected to every other client. If by completely connected you mean there's x degrees of separation between everyone, then yes, that's how it is. Data gets \"spread\" throughout the network as time goes on, not instantaneously (though it is pretty fast).
This was mostly a thought experiment for satoshi, as I understand it. If the userbase continues to grow substantially, then obviously a great amount of work will go into optimizing and revising the algorithm to support more advanced and intelligent distribution.
",
"nested_level": 0
},
{
"id": 1592,
"thread_id": 127,
"source_id": "6",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5068#msg5068",
"date": "2010-07-22T16:28:30Z",
"text": "Thank you both!
I understand that all transactions and all validated blocks need to get to every node. I was just curious about the implementation of the broadcast mechanism.
At worst case a million nodes would each have a million minus one open connections (bad). A better case would have each node broadcast to log(n) nodes who relayed to log(n) node, and to complete the broadcast in log(n) time.
Do you have any details of the thought experiment quantumplication?
",
"nested_level": 0
},
{
"id": 1593,
"thread_id": 127,
"source_id": "7",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5070#msg5070",
"date": "2010-07-22T16:42:44Z",
"text": "Thanks for your analysis Hepatizon! It was about what I was expecting.
However, I don't think this is quite correct.
For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction. So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there.
It appears that each new transaction has direct links to each prior transaction being used as an input. To validate a transaction you only need to validate the immediate dependancies. You don't need to validate those dependancies' dependancies as they were previously validated as part of the block chain. That means closer to constant time rather than linear.
I'm new though so I could be reading it wrong. Please correct me if I did.
The rest of your critique seems well analyzed and a bit frightening. Thanks again!
Thanks for your analysis Hepatizon! It was about what I was expecting.
However, I don't think this is quite correct.
For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction. So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there.
It appears that each new transaction has direct links to each prior transaction being used as an input. To validate a transaction you only need to validate the immediate dependancies. You don't need to validate those dependancies' dependancies as they were previously validated as part of the block chain. That means closer to constant time rather than linear.
You're right - I keep forgetting that the actual coins are tracked rather that just the account balance. So yeah, you only need to go back find whoever last owned the coins in question and verify that they're the same person sending them. Which is
technically linear time in that if the first coin ever was hoarded for ten years you really would need to go through the entire ten year block chain (unless you indexed it, which would be easy as all the coins are numbered) to see who had it - but in practice it would be closer to constant time because most people won't hoard bitcoins. (Unless they figure out that deflation is all but guaranteed...) For some reason I keep thinking that you would need to verify the account balance of the sender, and that would require verifying the account balance of everyone who has sent the sender money, and everyone who sent them money, and so forth.
Er, by \"thought experiment\", I meant \"proof of concept\". Satoshi seems to be pretty intelligent, and I don't think he was naive enough to think he would come up with the final specifications for the algorithm in the first go. In ANY project, there's always new things that crop up, and a well designed system is not one that accounts for every possibility, it's one that can adapt and change cleanly.
",
"nested_level": 0
},
{
"id": 1596,
"thread_id": 127,
"source_id": "10",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5258#msg5258",
"date": "2010-07-23T12:53:42Z",
"text": "I didn't mean anything other than how does the network communicate now?
When I run the network I see 20ish connections. I'm assuming that is not every node running. How does the algorithm decide who talks to who?
There are several know distributed hash table topologies. Was wonder if it was using one of those.
Granted, it could be everyone talks to everyone at the moment, and to be optimized in the future. I'd find that a reasonable answer too.
Cheers!
",
"nested_level": 0
},
{
"id": 1597,
"thread_id": 127,
"source_id": "11",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5263#msg5263",
"date": "2010-07-23T13:18:56Z",
"text": "AFAIK, it chooses some random connections to connect to from the IRC bootstrapper, but I'm not sure.
",
"nested_level": 0
},
{
"id": 1598,
"thread_id": 127,
"source_id": "12",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg5346#msg5346",
"date": "2010-07-23T18:13:43Z",
"text": "AFAIK, it chooses some random connections to connect to from the IRC bootstrapper, but I'm not sure.
Actually communicating through federated irc servers would probably work as well as anything. :-)
Based upon my understanding of economics there is only one way to resolve the scalability problem: the pricing system. Internet bandwidth, CPU time, hard disk space, etc are all valuable resources and expecting individuals to \"donate time\" or make a profit in \"bit coin mining\" is to arbitrary and leaves little room for innovation.
Effectively, if you want to post a transaction there must be a fee awarded to the individual who gets it posted in a block. There should also be some kind of fee for propagating the transaction to all of the nodes to begin with. Thus propagation isn't automatic it comes at a price. Each node that passes along your transaction to other block creators should get a cut of the transaction fee. In this way the network can load balance based upon economic incentive and the \"most valuable\" transactions get highest priority at a price.
",
"nested_level": 0
},
{
"id": 1600,
"thread_id": 127,
"source_id": "14",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg6223#msg6223",
"date": "2010-07-28T16:32:06Z",
"text": "expecting individuals to \"donate time\" or make a profit in \"bit coin mining\" is to arbitrary and leaves little room for innovation.
...
Effectively, if you want to post a transaction there must be a fee awarded to the individual who gets it posted in a block...
I used to have similar thoughts, but I decided I was wrong. It turns out that BitCoin is peer to peer in the sense that tier-1 internet providers are peer to peer. It is not P2P in the same sense that bittorrent is P2P.
Satoshi points out that he sees the NEED for at most 100,000 nodes verifying transactions and logging blocks. Others would use those nodes in a more client/service fashion. If I was guessing that number I would put it much lower (3<X<100) independent interested parties. Anyone can choose to be one of those X parties, or can choose to validate some or all of the work of those X parties, but only a small number are really REQUIRED.
Because in effect, the entire block list is mostly a distributed notary service. And though that requires rigor, it is not a particularly hard job.
So who would choose to do that job for free?
Knightmb for one. I'm have no doubt that many others like NewLibertyStandard will as well. Why Knightmb specifically? Well he has lots of coins and his business model and personal wealth relies on a well functioning honest system. Without that, his wealth and business simply evaporate. It is altruism and cooperation though self interest.
If you want a real world example consider the internet itself. At its amorphous core are about 7 tier-1 service providers. They are called tier-1 only because each has a mutually self interested \"peering agreement\" with the other six providers. That means these huge services providers move phenomenal amounts of date back and forth with zero accounting and zero payments among each other. They make all their money by selling their service to NON-tier-1 providers who make their money from selling it to you.
There is nothing to stop anyone from becoming a tier-1 provider. All you have to do is convince the others that it is in their self interest to peer with you. So for a example, Google is thought to pay zero in bandwidth to transmit youtube videos. There is enough traffic both ways, that it is in everyones self-interest to peer with them.
I expect that the same will happen with BitCoin. All the internal accounting and transfers will be free. (with the exclusion of transaction fees meant to avoid spam and mischief). Value will be created at the edges where people exchange bitcoins for something else of value.
Was the original question ever answered? Can the clients handle 35000 transactions per block? What about 100000? What is the bytesize of a transaction in the block? How much bandwidth is needed for the network to push these around in 10 minutes?
",
"nested_level": 0
},
{
"id": 1602,
"thread_id": 127,
"source_id": "16",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg6269#msg6269",
"date": "2010-07-28T20:59:42Z",
"text": "I am convinced that bandwidth, disk space, and computation time necessary to distribute and \"finalize\" a transaction will be prohibitively expensive for micro-payments. Consider for a second that the current banking industry is unable to provide a reasonable micropayment solution that does not involve depositing a reasonable sum and only allowing a withdraw after a reasonable sum has been accumulated.
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
Thus we need bit-banks that allow instant transfers among members and peer banks. Anyone can open a bit-bank but the system would, by necessity operate on some level of trust. Transfers in and out of the banks and peer-to-peer would still be possible but will be more costly. Thus, a bit bank could make money by enabling transfers cheaper and faster than the swarm with the added risk of trusting the bank. A bank has to maintain trust to make money.
",
"nested_level": 0
},
{
"id": 1603,
"satoshi_id": 287,
"thread_id": 127,
"source_id": "17",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Scalability and transaction rate",
"url": "https://bitcointalk.org/index.php?topic=532.msg6306#msg6306",
"date": "2010-07-29T02:00:38Z",
"text": "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 is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819Occasionally bitcoind will not respond to RPC I'm calling it from php and I get this error:
Warning: fopen(
http://127.0.0.1:8332) [function.fopen]: failed to open stream: HTTP request failed! HTTP/1.1 500 Internal Server Error
It happens a lot locally on my windows machine and less frequently on my linux server.
Anyone else have this problem?
Try taking the \"http://\" out of your fsockopen(). The JSON-RPC server isn't really HTTP.
I've had the best luck with the curl+json php extensions, myself.
",
"nested_level": 0
},
{
"id": 1606,
"thread_id": 128,
"source_id": "3",
"poster_name": "mtgox",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=489",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5320#msg5320",
"date": "2010-07-23T16:25:59Z",
"text": "Well it works 95% of the time which is what is weird
",
"nested_level": 0
},
{
"id": 1607,
"thread_id": 128,
"source_id": "4",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5325#msg5325",
"date": "2010-07-23T16:39:00Z",
"text": "Strange. I use my bitcoind almost every day from PHP, and I haven't encountered that.
",
"nested_level": 0
},
{
"id": 1608,
"thread_id": 128,
"source_id": "5",
"poster_name": "mtgox",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=489",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5331#msg5331",
"date": "2010-07-23T16:47:36Z",
"text": "I also get it anytime I send an invalid bitcoin address. Which is weird since it doesn't seem like that would effect the connecting.
",
"nested_level": 0
},
{
"id": 1609,
"satoshi_id": 257,
"thread_id": 128,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5339#msg5339",
"date": "2010-07-23T17:23:47Z",
"text": "If I recall correctly, 500 is the prescribed status code for JSON-RPC error responses. There is still a JSON response in the body of the reply telling the explanation of the error, which could be something like {\"result\":\"\",\"error\":\"bitcoin address not found\",\"id\":\"1\"}.
",
"nested_level": 0
},
{
"id": 1610,
"thread_id": 128,
"source_id": "7",
"poster_name": "mtgox",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=489",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5347#msg5347",
"date": "2010-07-23T18:14:48Z",
"text": "Weird I guess fopen() in php dies if the response is 500?
It seems like errors such as invalid address should just be normal replies just not \"sent\" so we can just check the reply string. I think of 500 errors as the server itself having an error.
",
"nested_level": 0
},
{
"id": 1611,
"satoshi_id": 262,
"thread_id": 128,
"source_id": "8",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoind not responding to RPC",
"url": "https://bitcointalk.org/index.php?topic=548.msg5419#msg5419",
"date": "2010-07-24T01:15:58Z",
"text": "Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply? I can't remember where I picked that up, maybe it's wrong. It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself. (and maybe that's what it said and I forgot and spread 500 to all error responses)
",
"nested_level": 0
},
{
"id": 1612,
"satoshi_id": 258,
"thread_id": 129,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Faster initial block download (5x faster)",
"url": "https://bitcointalk.org/index.php?topic=550.msg5349#msg5349",
"date": "2010-07-23T18:24:56Z",
"text": "By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes.
The database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.
I only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.
I built a test build if you'd like to start using it:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gzThese binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.
I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.
There are no changes to the way it handles wallet.dat. This change is only for blk*.dat and the non-critical addr.dat. You can always delete blk*.dat if it gets screwed up and let it re-download.
Are these for use with the test network you have setup or the current public network?
",
"nested_level": 0
},
{
"id": 1614,
"thread_id": 129,
"source_id": "3",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Faster initial block download",
"url": "https://bitcointalk.org/index.php?topic=550.msg5353#msg5353",
"date": "2010-07-23T18:42:25Z",
"text": "Are these for use with the test network you have setup or the current public network?
This is for the regular network. The test network doesn't have enough blocks to test it effectively. From what I can tell, satoshi's builds are always for the live network unless he specifies otherwise.
Awesome, got some extra slow machines to wipe/test with then. Will be curious to see what it does on faster machines as well.
So far, awesome increase for the Windows client. Doing about 500 blocks / second using a private node. After the timer is done, I'll try it on a wild node out on the Internet to see if the speed is just as good.
",
"nested_level": 0
},
{
"id": 1617,
"thread_id": 129,
"source_id": "6",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Faster initial block download",
"url": "https://bitcointalk.org/index.php?topic=550.msg5369#msg5369",
"date": "2010-07-23T19:32:58Z",
"text": "By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes.
The database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.
I only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.
The first part of the 70k downloaded in about 20 minutes, the rest of the remaining 2000 blocks in about 7 minutes, so only 27 minutes from 0 to 100%, very nice! Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?
In case anyone was curious, average download speed was around 3 Mbps for each burst of download.
Blocks download just as fast in the wild (about 3 Mbps), so a big thumbs up, this will certainly get new users up and running much quicker.
",
"nested_level": 0
},
{
"id": 1619,
"satoshi_id": 259,
"thread_id": 129,
"source_id": "8",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Faster initial block download",
"url": "https://bitcointalk.org/index.php?topic=550.msg5378#msg5378",
"date": "2010-07-23T20:13:27Z",
"text": "Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?
Not really. I'll change it to 1000 next time.
I'm trying to understand the way Bitcoin stores block data - among other things I want to run some statistics on the block chain / transaction history and check just how anonymous Bitcoin really is. So I went to the source to see how Bitcoin reads/writes block data to file.
(ETA: this is in 0.3.2)
In main.h we have:
bool WriteToDisk(bool fWriteTransactions, unsigned int& nFileRet, unsigned int& nBlockPosRet)
{
// Open history file to append
CAutoFile fileout = AppendBlockFile(nFileRet);
if (!fileout)
return error(\"CBlock::WriteToDisk() : AppendBlockFile failed\");
if (!fWriteTransactions)
fileout.nType |= SER_BLOCKHEADERONLY;
// Write index header
unsigned int nSize = fileout.GetSerializeSize(*this);
fileout << FLATDATA(pchMessageStart) << nSize;
// Write block
nBlockPosRet = ftell(fileout);
if (nBlockPosRet == -1)
return error(\"CBlock::WriteToDisk() : ftell failed\");
fileout << *this;
// Flush stdio buffers and commit to disk before returning
fflush(fileout);
#ifdef __WXMSW__
_commit(_fileno(fileout));
#else
fsync(fileno(fileout));
#endif
return true;
}
and
bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)
{
SetNull();
// Open history file to read
CAutoFile filein = OpenBlockFile(nFile, nBlockPos, \"rb\");
if (!filein)
return error(\"CBlock::ReadFromDisk() : OpenBlockFile failed\");
if (!fReadTransactions)
filein.nType |= SER_BLOCKHEADERONLY;
// Read block
filein >> *this;
// Check the header
if (CBigNum().SetCompact(nBits) > bnProofOfWorkLimit)
return error(\"CBlock::ReadFromDisk() : nBits errors in block header\");
if (GetHash() > CBigNum().SetCompact(nBits).getuint256())
return error(\"CBlock::ReadFromDisk() : GetHash() errors in block header\");
return true;
}
FLATDATA is defined in serialize.h like so:
//
// Wrapper for serializing arrays and POD
// There's a clever template way to make arrays serialize normally, but MSVC6 doesn't support it
//
#define FLATDATA(obj) REF(CFlatData((char*)&(obj), (char*)&(obj) + sizeof(obj)))
class CFlatData
{
protected:
char* pbegin;
char* pend;
public:
CFlatData(void* pbeginIn, void* pendIn) : pbegin((char*)pbeginIn), pend((char*)pendIn) { }
char* begin() { return pbegin; }
const char* begin() const { return pbegin; }
char* end() { return pend; }
const char* end() const { return pend; }
unsigned int GetSerializeSize(int, int=0) const
{
return pend - pbegin;
}
template<typename Stream>
void Serialize(Stream& s, int, int=0) const
{
s.write(pbegin, pend - pbegin);
}
template<typename Stream>
void Unserialize(Stream& s, int, int=0)
{
s.read(pbegin, pend - pbegin);
}
};
Now - and I apologize if I'm reading this wrong, this is a little more advanced C/C++ code than I'm used to - as I understand it, the FLATDATA call interprets the raw bytes of a CBlock object as an array (stream??) of characters. The CBlock::WriteToDisk method writes the constant 4-byte message header (0xf9, 0xbe, 0xb4, 0xd9), the size of the CBlock object in bytes, and then the FLATDATA of the CBlock it's writing to disk - which is just the raw bytes of the CBlock object. So after the header, the data written to file is byte-for-byte the same as the CBlock object represented in memory. Also, if I'm reading it correctly, CBlock::ReadFromFile copies those bytes directly into the space allocated for a CBlock object in memory to re-create the block. Is this correct?
Related question - I am under the impression that the exact way an instance of a C++ class is represented internally not guaranteed under standards; compiling a program with different compilers or different optimization flags can change the order in which member variables are stored in memory, and some debug mode compilers even add a few bytes between member variables to make memory inspection easier. I'm not positive about this, it's just something I've picked up and never seriously questioned.
They key bits of code are:
fileout << FLATDATA(pchMessageStart) << nSize;
...
fileout << *this;
pchMessageStart are the four magic bytes, and those are written with FLATDATA.
The CBlock itself is written by << *this, and that's done by the IMPLEMENT_SERIALIZE in main.h:
IMPLEMENT_SERIALIZE
(
READWRITE(this->nVersion);
nVersion = this->nVersion;
READWRITE(hashPrevBlock);
READWRITE(hashMerkleRoot);
READWRITE(nTime);
READWRITE(nBits);
READWRITE(nNonce);
// ConnectBlock depends on vtx being last so it can calculate offset
if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY)))
READWRITE(vtx);
else if (fRead)
const_cast<CBlock*>(this)->vtx.clear();
)
The READWRITE macros Do The Right Thing, reading in or writing out the members in a machine-independent way.
See
http://github.com/gavinandresen/bitcointools for simplified Python code that can dump out transactions and blocks.
Thanks for clearing that up for me.
I keep making really elementary code mistakes....
",
"nested_level": 0
},
{
"id": 1623,
"satoshi_id": 265,
"thread_id": 130,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Reading/Writing Blocks and FLATDATA",
"url": "https://bitcointalk.org/index.php?topic=555.msg5450#msg5450",
"date": "2010-07-24T04:04:20Z",
"text": "FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
",
"nested_level": 0
},
{
"id": 1624,
"satoshi_id": 264,
"thread_id": 131,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.2.5 -- please test!",
"url": "https://bitcointalk.org/index.php?topic=556.msg5443#msg5443",
"date": "2010-07-24T03:32:52Z",
"text": "Please test 0.3.2.5 in preparation for the 0.3.3 release! This build is looking good and should be the one that goes into 0.3.3. I encourage you to go ahead and upgrade now if you're on Windows or Linux.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
Download here:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gzThanks!
I have seen some speculation about scalability and denial of service by spam transactions in the IRC channel so I thought it would be a good idea to try a test.
I set up a stupid little bitcoind script on a couple of my linux machines to send 1000 tiny transaction to a third machine as quickly as they would run.
I asked on IRC for any obvious reasons why I shouldn't do it and got one supporting response thinking it was a good idea to try and one reserved response saying I should ask here first. I brashly decided to go ahead with it.
The scripts just printed a countdown of the number of remaining steps in the loop and the output of the bitcoind sendtoaddress command, normally just \"sent\".
They both started out quickly till there was something like 600 transactions submitted then both senders started to slow down perceptibly. One was quite a bit faster than the other, 3 or 4 times faster, due I think to a faster CPU. I thought at first it was the clients throtteling me to save the net from overload or something but that was just speculation. We later figured maybe it was the databases getting a bit slow on my old disks.
Then one of my machines suddenly seemed to speed up. But it wasn't really. It was an error, the bitcoind daemon had died. A little bit of investigation found the .bitcoin drive was full so you can't fault the program for giving up there! grin
The other machine was grinding pretty slow by then down to maybe 5 sec per transaction or so just judging by eye. It eventually finished after about 50 minutes. no errors at all.
The machine that crashed after I gave it some more disk space started right back up and showed it had only sent 424 transactions so there is an initial benchmark then - 1424 transactions in 50 minutes. It should be easy to get more.
I think the main thing slowing them down was the .bitcoin/database directory. They seemed to get a lot of data written to them some 184MB on the one that ran outa disk space and 1341 MB on the one that did the full 1000 transactions.
It seems another test with more people more distributed around the net might be in order to try to shake down any potential problems.
The net seemed to shrug it off as if nothing special happened anyway so that is a positive result. The clients mostly did just what they were told and expected except for a possible performance problem with the database.
Thats all I can think of for now.
",
"nested_level": 0
},
{
"id": 1626,
"thread_id": 132,
"source_id": "2",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: a simple traffic load test run",
"url": "https://bitcointalk.org/index.php?topic=567.msg5686#msg5686",
"date": "2010-07-25T13:09:05Z",
"text": "I was able to run IRC and discus the progress of the test thruout so I don't think I was anywhere near saturating any network resources.
",
"nested_level": 0
},
{
"id": 1627,
"thread_id": 132,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: a simple traffic load test run",
"url": "https://bitcointalk.org/index.php?topic=567.msg5687#msg5687",
"date": "2010-07-25T13:13:16Z",
"text": "There was a lot of slowdown in the rate of transactions during the second half of the test. If this was a problem with the network, then I would be very worried about future denial of service attacks. Hopefully a bigger test can be organized later.
Here is a packet capture of the event (from an \"edge\" computer with only one connection) if anyone is interested in exact times and stuff.
http://www.freefilehostingnow.com/filedownload.aspx?code=6bb2dbeea18e6a419daaadda5798bb05ec6bPlease do these tests on the test network. That's what it's for. Thanks.
",
"nested_level": 0
},
{
"id": 1631,
"satoshi_id": 268,
"thread_id": 133,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Bitcoin 0.3.3 released -- PLEASE UPGRADE",
"url": "https://bitcointalk.org/index.php?topic=570.msg5707#msg5707",
"date": "2010-07-25T16:55:09Z",
"text": "Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and 0.3.3.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
",
"nested_level": 0
},
{
"id": 1632,
"thread_id": 134,
"source_id": "1",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5708#msg5708",
"date": "2010-07-25T17:08:03Z",
"text": "I think there is a pretty significant crypto flaw in Bitcoin as currently implemented. I'm not sure it is exploitable now (I'm not a real cryptohacker) but it is more than plausible that will be in the near future.
The flaw would enable anonymous stealing of coins from arbitrary bitcoin addresses. And no it doesn't involve solving any of the hard problems that keep existing crypto systems secure. It is simply a *potential* correctable logic flaw in the implementation.
I would like bitcoins to succeed, so I'd rather not jump up and down in public yelling about flaws in public. Is there an appropriate place to discuss these types of issues?
",
"nested_level": 0
},
{
"id": 1633,
"thread_id": 134,
"source_id": "2",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5709#msg5709",
"date": "2010-07-25T17:19:29Z",
"text": "It's open source software, better to discuss it now than try to keep it a secret for someone else to discover and they may not be willing to share any details.
",
"nested_level": 0
},
{
"id": 1634,
"satoshi_id": 269,
"thread_id": 134,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5712#msg5712",
"date": "2010-07-25T17:45:22Z",
"text": "It's best if you tell it to me privately so it can be fixed first.
I just e-mailed you my e-mail address. (or you could PM me here)
",
"nested_level": 0
},
{
"id": 1635,
"thread_id": 134,
"source_id": "4",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5715#msg5715",
"date": "2010-07-25T18:07:31Z",
"text": "You stopped my post just in time! :-)
",
"nested_level": 0
},
{
"id": 1636,
"thread_id": 134,
"source_id": "5",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5716#msg5716",
"date": "2010-07-25T18:09:40Z",
"text": "Once it's fixed or proven not to work, could you post the details here? I'm very curious. =)
",
"nested_level": 0
},
{
"id": 1637,
"thread_id": 134,
"source_id": "6",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5719#msg5719",
"date": "2010-07-25T18:15:05Z",
"text": "I think I know what he means, but I was certain that the odds of doing it a bit too random to make an attack out of it.
",
"nested_level": 0
},
{
"id": 1638,
"satoshi_id": 270,
"thread_id": 134,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5724#msg5724",
"date": "2010-07-25T19:06:23Z",
"text": "Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA.
",
"nested_level": 0
},
{
"id": 1639,
"thread_id": 134,
"source_id": "8",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5725#msg5725",
"date": "2010-07-25T19:09:43Z",
"text": "Thanks Satoshi,
Here is what I sent him.
-----------
Public key cryptography depends on the fact that it is hard to factor large prime numbers. Everyone knows that. If bitcoins were transfers were assigned to a well formed public key, and an associated private key signature was required for future transfer I would concede that bitcoins crypto transfers were completely secure.
However, bitcoin transactions don't seem to work that way (by my reading). Transactions assign coin amounts to a particular \"bitcoin address\". Where the address is a hash of the public key.
To validate a transaction, nodes take the public key from the signature and use that to verify the actual signature. If the signature is valid, it then hashes the public key to confirm it matches the bitcoin address assigned in the previous transaction. If both match, by definition, the transaction is good.
The potential weakness is in associating the public key in the signature with the bitcoin address.
There is a many to one relationship between public keys and a given hash. Now, if finding a pair of prime numbers that creates a secure public/private key pair where the public key part hashes to a particular bitcoin address seems hard... it probably is.
However, that is not required.
All you need is ANYTHING representing a public key that hash collides with a know large bitcoin account. It does NOT have to be a secure key pair based on primes. It is simply has to work once and allow the transfer of the stolen money to another account. That is potentially much easier.
Some hashes are harder to collide than others. I'm not sure the strength of the hash being used. However, colliding any hash gets much easier if you don't have to care about the content being hashed.
Because of the nature of public keys they look like random data. As I understand them, you can't know if a public key is based upon secure math unless you succeed in factoring it. Therefore clients don't try. They normally just do the validation of the signature and presume the public key was generated in a secure fashion if it worked.
NOTE: The following analysis needs double checking by a real cryptohacker. IANACR
So depending on the hash, you could use one of the up-and-coming hash collision algorithms to generate a colliding block of data which represents a public key. Then by reversing the public/private key math, generate an associated (but hardly secure at all) private key that would generate valid signatures.
You then take your insecure, easily factorable, key pair and generate a signed transaction that matches the target bitcoin address.
Since the transaction log, can't validate the full public key the coins were intended for, it simple presumes it must have been the one presented.
By recording the full public key of the transfer target in the block list you can regain the intended strength. However, you lose the ability to pass around 34 character addresses.
If I'm off base, I apologize for wasting your time.
Cheers!
Red
",
"nested_level": 0
},
{
"id": 1640,
"thread_id": 134,
"source_id": "9",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5728#msg5728",
"date": "2010-07-25T19:22:14Z",
"text": "Satoshi pointed out that my scenario still required the hash function to be broken. That is true, but I was surprised to learn how successful some have been with that. MD4 and MD5 are obvious examples. But work is well underway at colliding SHA-1 and siblings like SHA-256.
What hash is being used in this part of Bitcoin?
He is also skeptical that you could you could use something other than a generated keypair.
On this point, I'm pretty confident that it is a simple matter of mathematics. I didn't pay enough attention to this until I learned about \"blind signing\" of documents.
It turns out you can take a document and multiply it by a random number. Then have someone sign the jumbled file. Finally, you divide your random number out of their signature and the result is still a valid signature for the original document. Who'd figured that would work!
Anyway, if keypairs are only secure if they are based upon pairs of primes. Then nothing changes any of the math if the numbers are not prime. They are just much easier to factor.
I'd be perfectly happy for some crypto guy to prove me an idiot. It effects some features of a previous project I created that relied on the same association. I didn't think of this then either.
",
"nested_level": 0
},
{
"id": 1641,
"thread_id": 134,
"source_id": "10",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5733#msg5733",
"date": "2010-07-25T19:34:42Z",
"text": "Very nice. *another reason why I love open source*
As I understand it then, and please correct me if I'm wrong
Since the hash of the public key is smaller than the actual public key itself, one need only find a collision that matches the hash and when that collision is found you'll know the public/private key combo. Then you simply spend coin using the known ones and the other clients will think it's a valid transfer because the clients are only concerned that your hash matches the hash of the victim and the transaction is recorded for all time.
Currently the hash is 35 characters long, alpha-numeric
26 (upper case) +26 (lower case) +10 (numbers) = 62 possible per character
So we have 541,638,008,296,341,754,635,824,011,376,225,346,986,572,413,939,634,062,667,808,768 possible combinations.
So I think we have about half of much work to do compared to going brute force against the main private/public key. Never hurts to plan for the future
Satoshi pointed out that my scenario still required the hash function to be broken. That is true, but I was surprised to learn how successful some have been with that. MD4 and MD5 are obvious examples. But work is well underway at colliding SHA-1 and siblings like SHA-256.
What they often don't mention though is *collision generating* still takes a lot of CPU time.
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.
From what I was told, bitcoin is using one of the 160 bit hashes for generating bitcoin address.
The SHA-1 family of hash algorithms are some of the most commonly used. SHA-1 is a 160 bit hash.
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
http://www.ictlex.net/wp-content/iacrhash.pdfThe MD5 hashes can already be crashed in seconds on laptops. That was why it was retired from certificate based signatures.
And yes what I'm saying is **I think** you can think of a public key as two secret numbers mathematically combined together. And the private key as those two numbers kept separately. The thing that make the system secure requires that the two secret numbers be really large prime numbers.
But if they are really large non-prime numbers the combination math still works, it is just must faster to break the algorithm.
I'll do a little more googling and see if I can substantiate my claims. I was hoping someone could dismiss them out of hand though.
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.
You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.
When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.
Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.
He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt.
You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.
When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.
Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.
He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt.
Yeah, I thought the private key had to be in the mix somewhere. It kind of adds another randomness though, you have to find the hash that collides with another public key and at the same time, the private key has to be weak enough to break. I'm not saying it's impossible, but it introduces 2 variables into the reverse collision finding.
Basically, one would build a rainbow table of weak private keys and then have to compare those to public hashes and then have to hope that someone out there has a hash that happens to be a part of that attack. Not impossible of course, but how feasible even if computers were 100 times faster in 10 years?
[edit] ok, re-read what you wrote, the public key is generated from the private key, not independently. So just finding a weak public key is the issue.
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
2^80 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2^160 bits. Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.
Bitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as:
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.
For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case.
I think you are correct on the analytical attack. At least a far as I understand (minimally) the mathematical genius that is analyzing them.
I was worried it was the simpler:
bitcoinaddress = RIPEMD-160(publickey)
So the way I read it.
Given two numbers p and q. Which for RSA are supposed to be large primes.
Then n = p*q
The public key is the two fields (n, e). e is called the public exponent and appears to be chosen from a set of common values.
The private key is also two fields (n, d). d is called the private exponent it it is derived by knowing e, p-1, and q-1.
The trick is, it is really hard to factor n into p & q. Therefore it is equally as hard to find p-1 and q-1
My postulation is that if n is arbitrary, and e is one of the common values, then there are lots of different p, q pairs that would work. The less prime the numbers the easier to find p and q, and therefore p-1 and q-1. And if you have a big block of arbitrary data that give you lots of flexibility in trying to collide a hash.
(That is the point where I could be totally off base though. Really interested, if a crypto geek knows better than me.)
I did read that the key generation algorithms create p and q such that they are \"very likely prime\" but it is too much work to know for sure. This leads me to believe non-primes don't cause any obvious FAILs. I could be wrong though.
",
"nested_level": 0
},
{
"id": 1649,
"satoshi_id": 277,
"thread_id": 134,
"source_id": "18",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Stealing Coins",
"url": "https://bitcointalk.org/index.php?topic=571.msg5778#msg5778",
"date": "2010-07-25T22:27:36Z",
"text": "Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said \"prime numbers\". ECDSA doesn't take much time to generate a keypair.
",
"nested_level": 0
},
{
"id": 1650,
"thread_id": 135,
"source_id": "1",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Bitcoin x86 for Windows",
"url": "https://bitcointalk.org/index.php?topic=572.msg5823#msg5823",
"date": "2010-07-26T08:17:20Z",
"text": "Figured I'd make a new topic since anyone on x86 Windows probably won't even bother to read the x64 thread, however, since you're here, I suggest you read page 5 of that thread after reading this.
OK, so essentially I've compiled 2 builds of Bitcoin with the new SHA caching optimisation, one build has full optimisation for the SSE instruction sets and will require a modern CPU, and the other is compiled without any SSE optimisation at all and should therefore run on pretty much any CPU capable of running XP or higher. The SSE version is a bit faster than the non-SSE version and both are inferior to the x64 builds, if you have a 64-bit OS, don't bother with these.
Beware however that the libeay32.dll that I included may have SSE and therefore, if you can't get either to run on your machine, replace that DLL with the one bundled with the stock BitcoinYou can grab the builds hereAmazing. ~1250 up to ~2200.
Is this for real? Other machine from ~600 to ~1350
",
"nested_level": 0
},
{
"id": 1652,
"thread_id": 135,
"source_id": "3",
"poster_name": "BlackEye",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=539",
"subject": "Re: Bitcoin x86 for Windows",
"url": "https://bitcointalk.org/index.php?topic=572.msg5840#msg5840",
"date": "2010-07-26T12:12:41Z",
"text": "I don't see the source code included with any of your builds. It would be great to be able to independently verify and compile the sources.
",
"nested_level": 0
},
{
"id": 1653,
"thread_id": 135,
"source_id": "4",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x86 for Windows",
"url": "https://bitcointalk.org/index.php?topic=572.msg5841#msg5841",
"date": "2010-07-26T12:13:45Z",
"text": "I don't see the source code included with any of your builds. It would be great to be able to independently verify and compile the sources.
If you don't trust my builds, don't use them, if you want to set up your own build environment, do the work yourself, all the source code in the app is publically available.
No need to be hostile. I do have a build environment set up, but I am completely unable to compile your changes without your source code. This just sends up a big red flag for me as you've obviously modified the source for some of your builds and are unwilling to provide those changes for peer review. I think this goes against the spirit of open source. Modified binary only releases don't help progress the software and create an unnecessary dependency on an individual to provide those binaries.
",
"nested_level": 0
},
{
"id": 1655,
"thread_id": 135,
"source_id": "6",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x86 for Windows",
"url": "https://bitcointalk.org/index.php?topic=572.msg5851#msg5851",
"date": "2010-07-26T13:04:41Z",
"text": "No need to be hostile. I do have a build environment set up, but I am completely unable to compile your changes without your source code. This just sends up a big red flag for me as you've obviously modified the source for some of your builds and are unwilling to provide those changes for peer review. I think this goes against the spirit of open source. Modified binary only releases don't help progress the software and create an unnecessary dependency on an individual to provide those binaries.
Crypto++ 5.6.0:
http://www.cryptopp.com/Cached SHA256:
http://pastebin.com/rJAYZJ32 (although I'm pretty sure this is publically submitted elsewhere, I was linked to it on IRC)
Thanks for thinking about those still on the 32bit chips
Or those with servers stuck on 32-bit OSes. :-D
Quad core
Xeon@1.6GHzStock: 1100kh/s
Full Opt: 2600kh/s
THANKS!
More than doubled my khash/sec from 800 to 1900.
AMD Phenon II X2 550
",
"nested_level": 0
},
{
"id": 1659,
"thread_id": 135,
"source_id": "10",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Bitcoin x86 for Windows",
"url": "https://bitcointalk.org/index.php?topic=572.msg5886#msg5886",
"date": "2010-07-26T15:42:01Z",
"text": "Or those with servers stuck on 32-bit OSes. :-D
Quad core
Xeon@1.6GHzStock: 1100kh/s
Full Opt: 2600kh/s
THANKS!
BitCoins are always appreciated, address in my sig
I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread.
I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?
Or those with servers stuck on 32-bit OSes. :-D
Quad core
Xeon@1.6GHzStock: 1100kh/s
Full Opt: 2600kh/s
THANKS!
BitCoins are always appreciated, address in my sig
I just sent you a wad of coin
I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?
I recently also made an attempt to use Crypto++ 5.6.0 (as an external library) instead of the old integrated code, with the same result - it crashed on the first invocation of CryptoPP::SHA256::Transform. Only I built everything with VC++ 2008. I haven't investigated in depth, but someone mentioned Crypto++'s routine required aligned input - maybe that's the reason, or we may have other bug we don't figure.
You need to change the assembly instructions that require aligned input to unaligned -
http://bitcointalk.org/index.php?topic=453.msg5774#msg5774, or make the blocks that are being hashed aligned. I haven't tried yet, but this assembly code combined with the state caching modification should make this blazing fast.
I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.
I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.
I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA.
I aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3.
I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.
It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.
This is SVN rev 114.
...
I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.
It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I do want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.
I've got some older machines (for the windows client and linux clients) to test with that don't support SSE2. Mainly if you try to run them, the program just crashes when I tried some of the experimental builds here, but I'll be glad to test some future official builds to see if the \"detect SSE2\" part works or the program goes belly up.
OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating.
",
"nested_level": 0
},
{
"id": 1667,
"satoshi_id": 278,
"thread_id": 136,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "bitcoind without wxWidgets",
"url": "https://bitcointalk.org/index.php?topic=576.msg5904#msg5904",
"date": "2010-07-26T17:23:33Z",
"text": "I replaced the last of the few wxBase dependencies in bitcoind.
bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.
main(int argc, char* argv[]) is added to init.cpp. CMyApp and the Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren't linked by bitcoind.
The makefiles have -DGUI to control whether the GUI is used.
I test compiled MinGW, VC and Ubuntu. I don't know if I broke the Mac OSX build, someone will need to check that.
",
"nested_level": 0
},
{
"id": 1668,
"thread_id": 137,
"source_id": "1",
"poster_name": "xc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=40",
"subject": "Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg5984#msg5984",
"date": "2010-07-27T02:09:27Z",
"text": "The Money Regression and Emergence of Money from the Barter Economy
The entire purpose of the regression theorem was to help explain an apparent paradox of money: how does money have value as a medium of exchange if it is valued because it serves as a medium of exchange? Menger and Mises helped break this apparent circularity by explaining the essential time component missing from the phrasing of the paradox.
As Rothbard explains in Man, Economy, and State (p 270),
\"...a money price at the end of day X is determined by the marginal utilities of money and the good as they existed at the beginning of day X. But the marginal utility of money is based, as we have seen above, on a previously existing array of money prices. Money is demanded and considered useful because of its already existing money prices. Therefore, the price of a good on day X is determined by the marginal utility of the good on day X and the marginal utility of money on day X, which last in turn depends on the prices of goods on day X \u0096 1. The economic analysis of money prices is therefore not circular. If prices today depend on the marginal utility of money today, the latter is dependent on money prices yesterday.\" [all emphasis added]
Rothbard then goes on to explain that in order for money to emerge from a barter economy, it must have a preexisting commodity value. This commodity value arises from barter demand for the potential money in direct consumption (i.e. ornamentation). This value seeds future estimations of the value of the money as a medium of exchange. The natural market emergence of money is thus fully explained.
The Monetary Economy
However, once an economy has been monetized and a memory of price ratios for goods and services has been established, a money may lose its direct commodity value and still be used as a money (medium of indirect exchange). Rothbard explains (p 275):
\"On the other hand, it does not follow from this analysis that if an extant money were to lose its direct uses, it could no longer be used as money. Thus, if gold, after being established as money, were suddenly to lose its value in ornaments or industrial uses, it would not necessarily lose its character as a money. Once a medium of exchange has been established as a money, money prices continue to be set. If on day X gold loses its direct uses, there will still be previously existing money prices that had been established on day X \u0096 1, and these prices form the basis for the marginal utility of gold on day X. Similarly, the money prices thereby determined on day X form the basis for the marginal utility of money on day X + 1. From X on, gold could be demanded for its exchange value alone, and not at all for its direct use. Therefore, while it is absolutely necessary that a money originate as a commodity with direct uses, it is not absolutely necessary that the direct uses continue after the money has been established.\"
This explains the history of fiat currencies. They originally started off as simple names for weights of commodity money (silver) that developed out of the pre-monetary barter economy. Despite later losing their ties to direct commodity value through state interference, paper currency retained status as money because of memory of previous money prices. This factor is so strong that the relationship between gold and the USD, for example, is somewhat inverted. Gold no longer circulates as a common medium of exchange. Prices are set in USD, not in gold. Most individuals wishing to trade in gold do so based on their knowledge of USD/gold price ratios. (\"Hey, let me buy that $100 couch from you in gold?\" \"Ok, USD/gold is $1000/oz. Give me 1/10oz of gold.\") Legal tender laws, state taxation, and the entire financial regulatory environment maintain this inertia of USD prices and make it challenging to return to gold money directly, despite the destructive inflationary nature of fiat currencies.
The Emergence of the Bitcoin Economy
The very first businesses in the Bitcoin economy were exchangers (NewLibertyStandard, BitcoinMarket, BitcoinExchange,....). This is not an accident, but flows from the analysis above. In order for Bitcoins to serve as a medium of exchange without commodity value for uses besides indirect exchange, there must be a translated knowledge of money prices. Market exchangers fill this gap and give Bitcoin users access to this knowledge. Bitcoins may therefore currently serve as a money intermediary for paypal dollars\\pecunix\\euros. But why is there demand for Bitcoin over USD?? This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.
The essential point is that once exchange can occur between a money (USD) and Bitcoins, providers of goods have a means by which to value Bitcoins as a potential medium of exchange. The money regression is satisfied, because taken back far enough we reach traditional commodity money: BITCOINS -> USD -> MONETIZED GOLD & SILVER [start monetary economy] -> [end barter economy] COMMODITY GOLD & SILVER.
Of course, if a major meltdown occurred and knowledge of all price ratios was wiped out, Bitcoin probably would NOT directly emerge as a money (assuming Bitcoins have limited value outside of exchange). Fiat currencies with zero direct barter value certainly would not. Commodities such as gold and silver that have widely recognized direct value in barter would likely emerge first. The economy would then be monetized with price ratios in gold and silver. Bitcoins then, being valued for intrinsic properties amenable to exchange, might then become prevalent in trade. Initially, creators of value would continue to make their price value ratios in terms of the true money (gold oz/BTC ratio), but with time Bitcoin prices (BTC) can emerge (see vekja.net as example). We are in this initial phase now.
Therefore, so long as exchange of BTC and USD/Euros/etc\u0085 occurs, knowledge of existing price ratios can be utilized in the Bitcoin economy. In time as Bitcoins become increasingly marketable, these fiat<->BTC price ratios will seed direct BTC price ratios. The Bitcoin Economy thus emerges. The Misean regression theorem is satisfied.
XC
edit: clarified possibility of direct emergence of bitcoin as money from barter economy.
",
"nested_level": 0
},
{
"id": 1669,
"thread_id": 137,
"source_id": "2",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg5997#msg5997",
"date": "2010-07-27T04:05:16Z",
"text": "YOU WIN 20 BTC!
Now all I need is your address for you to claim Kiba's AWESOME POST prize.
Edit: got it.
Yes, quite an impressive analysis! Alas I have no coins to send.
Why is there no PPC build for the Mac? I really need new hardware.
",
"nested_level": 0
},
{
"id": 1671,
"thread_id": 137,
"source_id": "4",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg6015#msg6015",
"date": "2010-07-27T10:01:16Z",
"text": "Excellent economic breakdown.
A hash cookie for you!
",
"nested_level": 0
},
{
"id": 1672,
"thread_id": 137,
"source_id": "5",
"poster_name": "joechip",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=397",
"subject": "Re: Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg6065#msg6065",
"date": "2010-07-27T18:06:28Z",
"text": "Excellent breakdown. That helps satisfy my worries about the process by which one type of money can supplant another. I have not read Man, Economy and State (though I really should) and therefore, missed that portion of Rothbard's analysis.
Thanks again.
Ta,
",
"nested_level": 0
},
{
"id": 1673,
"thread_id": 137,
"source_id": "6",
"poster_name": "hugolp",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=183",
"subject": "Re: Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg7839#msg7839",
"date": "2010-08-06T11:39:14Z",
"text": "But why is there demand for Bitcoin over USD?? This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.
Exactly this. Bitcoins have value because they offer some qualities, and some people value them. Also, I would add ideological value.
But why is there demand for Bitcoin over USD?? This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.
Exactly this. Bitcoins have value because they offer some qualities, and some people value them. Also, I would add ideological value.
What if someone wants to buy something and they dont want it showing on their credit card statement? Bitcoins are the ultimate thing for it.
The simpler answer is that Rothbard is wrong here. Not a statement about Rothbard in general, but on this particular point he's off. There need be no preexisting \"direct\" value for money, where the value of money itself is artificially deemed as of some second-class \"indirect\" sort. The value of a commodity _as money_, because it more securely scarce (and portable, hard to steal, etc.) than an alternative commodity, is quite sufficient to make it valuable as money and thus to get it going as money. Enabling exchange, i.e. lowering transaction costs, is a form of economically useful consumption just as much as satisfying hunger, decoration, or some other \"direct\" use is a form of economic consumption. In the same way, a stock exchange doesn't have to satisfy your hunger or make a good decoration or have any other \"direct consumption\" value, it just has to be good at exchanging stocks.
This is well explained here (interestingly enough by the guy who originally came up with the bit gold idea):
http://szabo.best.vwh.net/shell.htmlThis might just be semantics. But I'd say that the \"pre-existing value\" was the expectation of some people that it would be a good money.
",
"nested_level": 0
},
{
"id": 1677,
"satoshi_id": 428,
"thread_id": 137,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin does NOT violate Mises' Regression Theorem",
"url": "https://bitcointalk.org/index.php?topic=583.msg11405#msg11405",
"date": "2010-08-27T17:32:07Z",
"text": "As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose
and one special, magical property:
- can be transported over a communications channel
If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.
Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.
I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.
(I'm using the word scarce here to only mean limited potential supply)
",
"nested_level": 0
},
{
"id": 1678,
"thread_id": 138,
"source_id": "1",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6018#msg6018",
"date": "2010-07-27T10:11:51Z",
"text": "http://nullvoid.org/bitcoin/difficultiez.php<?
header(\"Content-type: text/html\");
require_once 'jsonRPCClient.php';
$data=new jsonRPCClient('http://127.0.0.1:8332');
$blockcount = $data->getblockcount();
$now = date(\"U\");
$blockfile = \"blockdata\";
$data = file($blockfile, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES); array_pop($data);
?><html>
<head>
<meta http-equiv=\"refresh\" content=\"100000\">
</head>
<body>
<pre>
<?
function humantime($secs) {
if ($secs<0) return false;
$m = (int)($secs / 60); $s = $secs % 60; $s = ($s <= 9) ? \"0$s\" : $s;
$h = (int)($m / 60); $m = $m % 60; $m = ($m <= 9) ? \"0$m\" : $m;
$d = (int)($h / 24); $h = $h % 24; $h = ($h <= 9) ? \"0$h\" : $h;
$d = ($d <= 9) ? \"0$d\" : $d;
return $d.\"d $h:$m:$s\";
}
// Converted from ArtForz's python code http://bitcointalk.org/index.php?topic=464.msg4080#msg4080
function uint256_from_compact($c) {
$nbytes = ($c >> 24) & 0xFF;
return bcmul($c & 0xFFFFFF,bcpow(2,8 * ($nbytes - 3)));
}
$tblock = 0;
$nTargetTimespan = 60 * 60 * 24 * 14;
bcscale(256);
foreach ($data as $line) {
$blocks = strtok($line, \" \");
$date = strtok(\" \");
$avghash = strtok(\" \");
$bits = strtok(\" \");
if ($blocks == 0 || $blocks == $tblock) {
$tblock = $blocks + 2016;
$blocknum = str_repeat(\" \", 6 - strlen($blocks)).$blocks;
echo \"Block $blocknum was generated at $date (\".date(\"r\", $date).\")\";
if ($blocks != 0) {
$intervalnum = $date - $lastdate;
$interval = str_repeat(\" \", 9 - strlen($intervalnum)).$intervalnum;
echo \" $interval seconds interval (\".humantime($intervalnum).\")\";
echo \" Difficulty: \".bcdiv(bcdiv(bcmul(uint256_from_compact(0x1D00FFFF),1000), uint256_from_compact($bits)), 1000);
$lastdate = $date;
}
echo \"<br>\";
}
}
?>
</pre>
</body>
</html>
",
"nested_level": 0
},
{
"id": 1679,
"thread_id": 138,
"source_id": "2",
"poster_name": "mpkomara",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=293",
"subject": "Re: Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6036#msg6036",
"date": "2010-07-27T14:32:42Z",
"text": "nice precision! latest difficulty = 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 17840402922938076799906
",
"nested_level": 0
},
{
"id": 1680,
"thread_id": 138,
"source_id": "3",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6040#msg6040",
"date": "2010-07-27T14:52:04Z",
"text": "Hehe, thanks. I could provide more accurate precision, but I think that is good enough.
",
"nested_level": 0
},
{
"id": 1681,
"thread_id": 138,
"source_id": "4",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6048#msg6048",
"date": "2010-07-27T15:45:03Z",
"text": "I'm just thankful the difficulty isn't 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 17840402922938076799907
Just imagine how hard it would be to win a block then!!!!!
",
"nested_level": 0
},
{
"id": 1682,
"thread_id": 138,
"source_id": "5",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6122#msg6122",
"date": "2010-07-28T00:31:31Z",
"text": "Actually, calculating with another digit comes out to 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 178404029229380767999068 and thus could be rounded up to the value you suggested Insti.
",
"nested_level": 0
},
{
"id": 1683,
"thread_id": 138,
"source_id": "6",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Difficulty",
"url": "https://bitcointalk.org/index.php?topic=587.msg6130#msg6130",
"date": "2010-07-28T01:44:28Z",
"text": "It appears that block 70718 was found two hours in the future and followed with block 70719 being found about two hours in the past (from the future date of previous block).
-7017 seconds to find block 70719
8153 seconds to find block 70718
49 seconds to find block 70717
524 seconds to find block 70716
block timestamp
70715 1280275621
70716 1280276145
70717 1280276194
70718 1280284347
70719 1280277330
This doesn't seem to have any effect on things so much other than providing a kind of inaccurate depiction of statistical results every now and then (when a block is claimed to be from the future or the past), however what would happen if either the first or second (whichever one triggers new difficulty being established) of a new set of 2016 blocks is generated to have a timestamp 2+ weeks in the past or the future? If in the past, I presume according to the code in main.cpp: GetNextWorkRequired function that the lowest accepted interval is 3.5 days. And if in the future I presume according to the code the lowest accepted interval is 56 days.
You were looking at the wrong code. Here's the code that applies:
bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error(\"CheckBlock() : block timestamp too far in the future\");
...
bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error(\"AcceptBlock() : block's timestamp is too early\");
The timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.
I've been working on adding -port= / -rpcport= command line / config file options to bitcoin. The idea is to let you run multiple copies of bitcoind on one machine; I need this because I'm planning on having at least two Bitcoin-related web services (the Bitcoin Faucet and a service to be named later), I want them to have completely separate wallets, but I don't want to rent multiple servers to host them.
Usage looks like this:
$ ./bitcoind getbalance # The TEST network Faucet bitcoind
40616.66159265000
$ ./bitcoind -datadir=/home/bitcoin/.bitcoinTEST2 getbalance
1000.000000000000
$ cat /home/bitcoin/.bitcoinTEST2/bitcoin.conf
rpcpassword=.....
port=18666
rpcport=18665
Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database. To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes).
Issues that came up as I was doing this:
I left a call to wxSingleInstanceChecker in the Windows GUI code, so no multiple-gui-bitcoins-listening-on-different-ports on Windows. I don't do Windows...
I didn't bother making the error handling graceful if you point two bitcoins at the same datadir (you get a runtime exception \"Cannot lock db.log, is bitcoin already running?\").
Patches are at
http://pastebin.com/2e4hfXSS; I've only tested on Linux so far, anybody willing to try this on Windows?
If I was a C++ programmer, I would make multiple instances of Bitcoin automatically talk to each other. But then again, I don't know how hard it is to do cross platform interprocess communication. If a data directory was already being used by one instance, then the new instance would be required to use a different data directory. Sure, you probably can make multiple instances share some or all the files in a data directory, but I think it's a bad idea since it the likelihood for little bugs is high, but the likelihood of the likelihood of those being discovered, researched, reported and fixed is low since the feature wouldn't get much exposure. Imagine the mess it will make if somebody starts half a dozen instances.
Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database. To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes).
Additionally you could run each client as a different system user.
I've been working on adding -port= / -rpcport= command line / config file options to bitcoin
Nice. In addition it would be good to have an -ip= option for what address to bind the port. (rpcport binds to 127.0.0.1 but currently port binds to 0.0.0.0 which is all IP addresses on the machine. On my multi-homed system I'd like to bind bitcoin to the external address different from the bitcoin(s) that binds to the internal address(es).)
Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
",
"nested_level": 0
},
{
"id": 1690,
"thread_id": 139,
"source_id": "6",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Running on a port other than 8333",
"url": "https://bitcointalk.org/index.php?topic=589.msg8552#msg8552",
"date": "2010-08-10T17:07:15Z",
"text": "Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
It does open with DB_PRIVATE.
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/envopen.htmlAlso, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.
Is there a way to open BerkeleyDB exclusive?
DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.
I've dropped the DB_PRIVATE flag in rev 153.
Whilst not amazingly critical, i find it strange that i consistently get the below error messages from the console and debug.log when i try to specify the datadir option with anything other than the period char (current directory).
This is using the bitcoind program on an archlinux terminal session, im not using the GUI at all (headless box accessed via ssh)
From Console:
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
and from the debug.log inside the datadir : -
Bitcoin version 0.3.4.0 beta
Default data directory /home/psyvenrix/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=./datadir2/database strErrorFile=./datadir2/db.log
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
Yes, that is a SVN build, as the tar.gz from the main site is linked against openssl ver 0.9.8 i think and my arch linux system has 1.0.0 i think, so i just grabed the latest SVN source and built that (aside from a makefile tweak it compiled ok).
ive checked the permissions on both the directory containing the binaries and the aforementioned datadir, all are writable by my login (& no other ACL/SELinux trickery in the background either)
I have only just started using bitcoin, so i find it strange that it's throwing a recovery type error when the contents of that directory are freshly generated (i.e. i can rm -rf the lot, then start bitcoind with a new non-existent directory, watch it create the files needed then bomb out)
Thoughts anyone?
Does it work if you specify the full path? e.g. -datadir=/home/psyvenrix/datadir2 ?
",
"nested_level": 0
},
{
"id": 1694,
"satoshi_id": 284,
"thread_id": 140,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Having problems specifing -datadir",
"url": "https://bitcointalk.org/index.php?topic=601.msg6268#msg6268",
"date": "2010-07-28T20:58:26Z",
"text": "It was able to reproduce this. The database doesn't like the relative path.
\"bitcoind -datadir=./subdir getinfo\" works against a running daemon, but trying to start the daemon as \"bitcoind -datadir=./subdir\" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
",
"nested_level": 0
},
{
"id": 1695,
"thread_id": 140,
"source_id": "4",
"poster_name": "Tilka",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=687",
"subject": "Re: Having problems specifing -datadir",
"url": "https://bitcointalk.org/index.php?topic=601.msg7644#msg7644",
"date": "2010-08-05T07:07:36Z",
"text": "+1 for quick bug fix. I'd like to be able to do that, too.
",
"nested_level": 0
},
{
"id": 1696,
"thread_id": 140,
"source_id": "5",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Having problems specifing -datadir",
"url": "https://bitcointalk.org/index.php?topic=601.msg8773#msg8773",
"date": "2010-08-11T17:58:43Z",
"text": "It was able to reproduce this. The database doesn't like the relative path.
\"bitcoind -datadir=./subdir getinfo\" works against a running daemon, but trying to start the daemon as \"bitcoind -datadir=./subdir\" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
I've tried to do it before too, but I never considered it a large enough bug to report. It would be nice to see a fix, though.
Fixed in SVN rev 130.
",
"nested_level": 0
},
{
"id": 1698,
"thread_id": 141,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Build error SVN r115 on my Mac: workaround",
"url": "https://bitcointalk.org/index.php?topic=604.msg6206#msg6206",
"date": "2010-07-28T15:18:25Z",
"text": "I get:
/var/folders/n7/n7Do3Krz2RWPeE+1YxvhUU+++TM/-Tmp-//cc8PgHsQ.s:879:suffix or operands invalid for `call'
... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc version 4.2.1).
I fixed it by adding -DCRYPTOPP_DISABLE_ASM to my makefile; perhaps somebody with more experience compiling C++ on a Mac can figure out a better fix.
Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?
I had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.
We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.
The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).
I uploaded this makefile.osx change to SVN. (let me know if that compiles now)
",
"nested_level": 0
},
{
"id": 1700,
"thread_id": 142,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "[PATCH] implement 'xlisttransactions'",
"url": "https://bitcointalk.org/index.php?topic=611.msg6295#msg6295",
"date": "2010-07-29T00:34:53Z",
"text": "Here is a patch against SVN 117, implementing 'xlisttransactions' RPC:
http://pastebin.ca/1910553 At present, the options are ignored, and it dumps all transactions it finds.
Raw patch:
http://pastebin.ca/raw/1910553Edit: Patch's current home is
http://yyz.us/bitcoin/patch.bitcoin-listtransactionsEdit2: RPC command has been renamed to 'xlisttransactions'
Here's an updated version, that sorts by number of confirmations:
http://pastebin.ca/1910564Raw patch:
http://pastebin.ca/raw/1910564OK, here's version 4. Output now matches what you see in the UI, and gives you information on debits/credit/generated/etc. The 'count' and 'includegenerated' parameters are now honored.
Patch:
http://pastebin.ca/1910623Raw patch:
http://pastebin.ca/raw/1910623Here's sample output from my dev box:
$ /usr/local/src/bitcoin/bitcoind -datadir=/usr/local/bitcoin/data listtransactions
[
{
\"address\" : \"15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5\",
\"label\" : \"\",
\"class\" : \"credit\",
\"amount\" : 0.02000000000000000,
\"confirmations\" : 160
},
{
\"address\" : \"15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5\",
\"label\" : \"\",
\"class\" : \"credit\",
\"amount\" : 0.01000000000000000,
\"confirmations\" : 162
},
{
\"address\" : \"1GKgKYtV79jYHR2mr1SSDp9EjXQuLTmUTw\",
\"label\" : \"\",
\"class\" : \"debit\",
\"amount\" : 0.02000000000000000,
\"confirmations\" : 1525
},
{
\"address\" : \"191ALqREPdXCGE6mhfS7HqRZCeQB2AHT6y\",
\"label\" : \"\",
\"class\" : \"credit\",
\"amount\" : 0.02000000000000000,
\"confirmations\" : 1531
},
{
\"address\" : \"1HVYQQ5K489fMx5Aqt48M5oTJPsmUhrpkx\",
\"label\" : \"\",
\"class\" : \"debit\",
\"amount\" : 0.01000000000000000,
\"confirmations\" : 1572
},
{
\"address\" : \"1KTpPjGWyhTBC5NNYFwNzkyjW6UDL9jKPG\",
\"label\" : \"Your Address\",
\"class\" : \"credit\",
\"amount\" : 0.01000000000000000,
\"confirmations\" : 1587
}
]
Added a couple small cleanups, and verified it still works under 0.3.6 / SVN r119.
Version 5 of listtransactions:
http://pastebin.ca/1911295Raw patch:
http://pastebin.ca/raw/1911295FAQ:
Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?
A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly.
Very nice! Send Satoshi an email and ask him to add it to trunk.
By the way, anyone having trouble applying this on unix can use:
curl http://pastebin.ca/raw/1911295 | awk 'sub(\"$\", \"\r\")' | patch
That'll make the line endings on the removed parts match the Windows line endings in the code files.
Very nice! Send Satoshi an email and ask him to add it to trunk.
He is welcome to pick it up now.
But I didn't want to push the patch to him until the two FIXME's are resolved. Those FIXMEs are for 0.01% cases, but still...
Could you make count=0 return all transactions?
",
"nested_level": 0
},
{
"id": 1707,
"thread_id": 142,
"source_id": "8",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: [PATCH] implement 'listtransactions'",
"url": "https://bitcointalk.org/index.php?topic=611.msg6537#msg6537",
"date": "2010-07-29T23:02:49Z",
"text": "Could you make count=0 return all transactions?
Returning all transactions is pretty easy, sure.
I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your \"count=0\" the default.
I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your \"count=0\" the default.
Perhaps. In that case, you should switch the order of includegenerated and count. Perhaps even make includegenerated true? Generations are included by default in the UI, after all.
Version 6 of listtransactions:
http://pastebin.ca/1911570Raw patch:
http://pastebin.ca/raw/1911570listtransactions implementation should be complete at this point. The following command syntax is used:
listtransactions [count=10] [minconf=1] [includegenerated=true]
As lachesis suggested, count=0 will dump
all transactions.
FAQ:
Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?
A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly.
Couple of quick suggestions:
Using the key name \"class\" will cause problems for, at least, JavaScript, and probably other languages where \"class\" is a reserved word. \"type\" or \"variety\" or some other synonym will cause fewer problems later.
Or, maybe better, get rid of that field and just report credits as positive numbers and debits as negative. And add a separate \"generated\" field (boolean true or false).
Since each entry refers to a transaction, I'd suggest adding a \"tx_id\" SHA256 hex-encoded transaction id. Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).
Code to get that would look something like:
uint256 tx_hash = transaction.GetHash();
string tx_id = tx_hash.GetHex();
mapJSONResponse.push_back(Pair(\"tx_id\", tx_id));
Couple of quick suggestions:
Using the key name \"class\" will cause problems for, at least, JavaScript, and probably other languages where \"class\" is a reserved word. \"type\" or \"variety\" or some other synonym will cause fewer problems later.
Can you be more specific? All mainstream programming language seem sensibly insensitive to abitrary string contents, JS included. String content can certainly include language-reserved keywords and parsing tokens.
Since each entry refers to a transaction, I'd suggest adding a \"tx_id\" SHA256 hex-encoded transaction id. Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).
Code to get that would look something like:
uint256 tx_hash = transaction.GetHash();
string tx_id = tx_hash.GetHex();
mapJSONResponse.push_back(Pair(\"tx_id\", tx_id));
Added, thanks for the suggestion.
Here is 'listtransaction' version 7:
http://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactionsThis adds the suggested txn_id field -- very nice suggestion, gavin! I wanted a unique transaction id, and now I have one
What are you needing to use listtransactions for?
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say \"use this! use this! don't use listtransactions!\", I don't think we should implement listtransactions.
When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like \"0/unconfirmed 0:0:0 date comment debit 4 credit 0\" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
",
"nested_level": 0
},
{
"id": 1714,
"thread_id": 143,
"source_id": "1",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Linux distribution download",
"url": "https://bitcointalk.org/index.php?topic=612.msg6312#msg6312",
"date": "2010-07-29T03:22:37Z",
"text": "Hi,
I am a software developer and while I am well versed with building things on Linux I thought I might provide some pointers to making like easier for others.
There is one aspect with distributing a single download package for Linux that is dynamically linked, \"You should use the oldest versions of glibc/libstdc++ you can get away with. i.e. unless you know you need a new feature or a bug fix take is as a given that the libraries at runtime will be newer and contain those fixes.\"
The problem with linking against the bleeding edge versions of glibc/libstdc++ is that you force the users to have a bleeding edge system also (to run these binaries). Which should not be a necessary pre-requisite unless you know of specific cause for it to be so. Such causes should be explained in documentation. Where as if you simply linked on an older system it would work both on that older system and on the bleeding edge system.
If there are areas of C code which you really-really need some new and recent GCC optimization to be enabled, consider providing the dumped out ASM file *.s which you generate once from your bleeding edge GCC version but include in the source to allow anyone to complile (even on older GCC versions).
Here are some recomendations:
* Use the oldest base distribution you can get away with to build the binaries. For example the most recent copy of the _PREVIOUS_ release of debian. Not the most update to date copy of the current release of debian.
* Provide a download containing static binaries (use the \"-static\" option to linking and maybe add this so the name of the executables \"bitcoind-static\"). Provide this in a seperate download file.
* Make the source distribution build work from working copies of the libraries they need. In particular boost and wxWidgets, if you know you need very recent versions of these to build against, then make building and linking work right out of their respective build tree (so you don't have to install them). Installing them in /usr/local maybe an issue (it certainly is for me) but having themin the current working directory just for bitcoin's use would be fine. At the end of the day all bincoin needs is access to header filer and DSOs or *.a to build and access to the DSOs at runtime.
I can put a 24/7 headless bitcoind up but because of these issues, until I find/make time to resolve them I can not at this time.
",
"nested_level": 0
},
{
"id": 1715,
"thread_id": 143,
"source_id": "2",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Re: Linux distribution download",
"url": "https://bitcointalk.org/index.php?topic=612.msg6317#msg6317",
"date": "2010-07-29T03:44:10Z",
"text": "Sorry to post to my own post.
One possible solution would be to create a project on the OpenSUSE OBS platform
http://wiki.meego.com/Build_Infrastructure .
This platform is an auto-builder anyone can use (by creating your own account and home area).
You can upload your project and *.spec (build descriptor) and it will build your distribution in the format of all the leading Linux distributions (OpenSUSE, CentOS/RHEL, Fedora, Ubuntu, ...). So there is no need for you to maintain them seperately it will do that for you.
The result will be a *.deb or *.rpm or whatever your platform uses.
Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.
",
"nested_level": 0
},
{
"id": 1717,
"thread_id": 143,
"source_id": "4",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Re: Linux distribution download",
"url": "https://bitcointalk.org/index.php?topic=612.msg6540#msg6540",
"date": "2010-07-29T23:10:15Z",
"text": "Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.
Fair enough. I've not found any version of bitcoin that works with any enterprise version of Linux I have found. Often enterprise linux uses older tried and trusted versions several years old. This has parity with the LTS series of Ubuntu.
I think you'd be better doing your distribution with
http://releases.ubuntu.com/hardy/ (8.04.4 LTS Hardy Heron). If you really must use Ubuntu. This being the _PREVIOUS_ release of their LTS series, once 10.4 LTS passes the 18months old test consider a release engineering rebase.
Maybe you can setup a 2Gb \"8.04.4 LTS\" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use.
Maybe you can setup a 2Gb \"8.04.4 LTS\" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use.
Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.
Constantly reformatting your main dev machine is for the birds
I have to support OpenSolaris and FreeBSD in my cloud computing project, in addition to the primary target, Linux. Virtual machines are a life-saver (and cost-saver).
Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.
Just to clear up any (potential) misconception, from the use of the phrase \"for older distro support\". Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way.
When they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries. Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC.
I am somewhat asserting that, if it is indeed possible to compile with older versions (because the features the newer versions add are not actually required by the application) then this version that should be made available via a single binary download (since it will work with the widest audience).
Also to repeat, that the OpenSUSE Build Service is like a remote virtualized service which you can use compile your application on multiple major distributions and the output is a bunch of packages tailored to suit each distro.
The clear problem I see is not with the support for aux lbiraries (Xlib,GTK+,OpenSSL,freetype) but with basic GLIBC and GCC libstdc++. The problem with this is that you can't expect to simply place the DLLs you need in the same directory as the bitcoin executable and fix up LD_LIBRARY_PATH (man ld.so) so it can see them.
For example lets say that it was compiled with an older GTK+ than is available for your distribution of choice (a DSO major release change, this is indicated in the 2nd \"0\" in the /usr/lib{,64}/libgtk+-x11-2.0.so.0.1800.9) - note it is still zero, this indicates long term stability re-backward compatibility. Well it is possible to easily fix this problem without installing the libraries by fixing them up with LD_LIBRARY_PATH. But for glibc solving the problem in this way is not so straightforward.
Make him a virtual box container and upload it or mail him a disk. Then all he needs to do is install vbox and run it.
Google found me
http://virtualboxes.org/images/ubuntu/Maybe head for item 3 for
http://downloads.sourceforge.net/virtualboximage/ubuntu-8.04-x86.7z (505Mb download, for a 2.67Gb uncompressed image)
Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.
Just to clear up any (potential) misconception, from the use of the phrase \"for older distro support\". Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way.
When they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries. Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC.
Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs. Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version. That practice makes glibc the primary compatibility worry.
Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs. Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version. That practice makes glibc the primary compatibility worry.
Please cite exactly which library is using which feature of very recent glibc version (or any library for that matter) ? (just so we can all understand the problem in the way you state).
From what I can see wxWidgets and boost are linked statically. I guess this is due to the \"build against very specific versions of its dependent libs\". But from what I can see there is _NO_ need for either of thes libraries to use a recent glibc, wxWidgets for example only has a check for glibc 2.1 or newer (during its ./configure). But it is not clear which features of wxWidgets 2.9.0 and/or boost 1.40.0 require the use of a glibc say above version 2.5 (which is also pretty old, but pretty compatibile). I have sucessfully been able to build these versions (of wxWidgets/boost) against glibc 2.5.
I believe this can be confirmed by the use of -Bstatic in \"src/makefile.unix\".
The only reason that glibc is a \"compatibility worry\" (as you put it) is because the project was build on a very new linux system. This forces all the downloaders to have as-new-a linux system as the build system in order to run it. This is not because there is some intrinsic compatibility worry as you describe it.
I think I have created a custom wxWidgets 2.9.x build on OpenSUSE build service (OBS). I shall have a go with \"boost\" over the new few hours if all goes well. Then I can commit bitcoind package and get openSuSE builds. Then I can enable other distribution repos (CentOS, Ubuntu, SLE, Fedora, etc...).
Can anyone confirm if boost \"1.40.0\" is needed or just \"1.40.0 or newer\" ? since 1.42.x is current (and that is already available for a number of platforms as packages). Can anyone explain the story behind this matter.
With wxWidgets 2.9.x is a development series so it is pre-release, so that is clear cut that a custom version needs to be built to get access to pre-release versions. But this problem I have solved in an OBS build.
It can be built with Boost 1.37 or later.
",
"nested_level": 0
},
{
"id": 1724,
"thread_id": 144,
"source_id": "1",
"poster_name": "Brre",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=551",
"subject": "Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6361#msg6361",
"date": "2010-07-29T11:20:33Z",
"text": "I did a transaction about 2 hours ago and it is staying at 0/unconfirmed, the recipient has no credit showing or even an unconfirmed line... The coins seems to disapeared in the void...
Should I wait is this just a transaction that is going to take exceptionally long?
",
"nested_level": 0
},
{
"id": 1725,
"thread_id": 144,
"source_id": "2",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6371#msg6371",
"date": "2010-07-29T12:33:43Z",
"text": "The transaction will be accepted into a solved block if the person who solves said block chooses to incorporate your transaction into his solution. That means it needs to propagate across the network. Is your \"Connections\" greater than 0?
",
"nested_level": 0
},
{
"id": 1726,
"thread_id": 144,
"source_id": "3",
"poster_name": "Brre",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=551",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6376#msg6376",
"date": "2010-07-29T13:13:17Z",
"text": "Yep 4 connections...
I just restarted.
Was the transaction not sent for some reason, is there a way to force the client to rebroadcast the transaction... if there is some glitch/bug?
",
"nested_level": 0
},
{
"id": 1727,
"thread_id": 144,
"source_id": "4",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6385#msg6385",
"date": "2010-07-29T13:48:37Z",
"text": "If your client says 0/unconfirmed then afaik that means it knows that it needs to continue to be broadcast until it gets into a block. I don't know why it would take 2 hours though, maybe someone else knows. Do you normally only have 4 connections?
",
"nested_level": 0
},
{
"id": 1728,
"thread_id": 144,
"source_id": "5",
"poster_name": "Quantumplation",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=450",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6392#msg6392",
"date": "2010-07-29T14:20:44Z",
"text": "Brre: Your client will relentlessly broadcast that transaction into infinity until it's accepted. It's VERY persistent.
A block just probably hasn't been solved in two hours. The difficulty's up there, I know that.
",
"nested_level": 0
},
{
"id": 1729,
"thread_id": 144,
"source_id": "6",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6404#msg6404",
"date": "2010-07-29T15:20:12Z",
"text": "Yeah, a block is being solved every 10 minutes or less, it shouldn't take 2 hours unless the client has somehow lost connection to the rest of the network.
",
"nested_level": 0
},
{
"id": 1730,
"thread_id": 144,
"source_id": "7",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Transaction disappeared in the void...",
"url": "https://bitcointalk.org/index.php?topic=615.msg6418#msg6418",
"date": "2010-07-29T16:28:35Z",
"text": "I did a transaction about 2 hours ago and it is staying at 0/unconfirmed, the recipient has no credit showing or even an unconfirmed line... The coins seems to disapeared in the void...
Should I wait is this just a transaction that is going to take exceptionally long?
Are you still downloading the block chain? If you don't already have all 70,000+ blocks in the block chain, then you transaction won't show up as confirmed until you catch up.
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 version.
You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient.
",
"nested_level": 0
},
{
"id": 1732,
"satoshi_id": 289,
"thread_id": 145,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "*** ALERT *** Upgrade to 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=626.msg6451#msg6451",
"date": "2010-07-29T19:13:06Z",
"text": "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 upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.
Also in 0.3.6, faster hashing:
- midstate cache optimisation thanks to tcatm
- Crypto++ ASM SHA-256 thanks to BlackEye
Total generating speedup 2.4x faster.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
is this in the SVN?
",
"nested_level": 0
},
{
"id": 1734,
"thread_id": 145,
"source_id": "3",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: *** ALERT *** Upgrade to 0.3.5 ASAP",
"url": "https://bitcointalk.org/index.php?topic=626.msg6455#msg6455",
"date": "2010-07-29T19:26:39Z",
"text": "I appreciate the quickness of this security update, but unfortunately none of the Linux builds work (32bit or 64 bit) because the file is missing. I'm assuming if I go find the file it will work, not sure what luck others will have though using the new build.
Error
./bitcoin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
are satoshi and Olipro working together?
if not, any chance you could?
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!
Please upgrade to 0.3.5 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.5!
Like Olipro, got a lot of people doing custom builds out there -- in fact, I
must use a custom build on several machines.
May we assume SVN has
all necessary updates?
are satoshi and Olipro working together?
if not, any chance you could?
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!
So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity.
are satoshi and Olipro working together?
if not, any chance you could?
i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!
So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity.
So far I'm seeing a comparable hashing rate to the most recent of the Olipro 32-bit binaries. It might even be slightly faster.
With the official Linux-64bit build, run on Fedora 13, I see it failing badly:
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
Praying my bitcoins aren't eaten...
With the official Linux-64bit build, run on Fedora 13, I see it failing badly:
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
Praying my bitcoins aren't eaten...
I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release
With the official Linux-64bit build, run on Fedora 13, I see it failing badly:
Same result on another machine. BDB errors, and death. 0.3.5 on 64bit Linux is questionable. You didn't mix up the builds with 32-bit Linux, did you?
debug.log says:
Bitcoin version 0.3.5 beta
Default data directory /g/g/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=/garz/bitcoin/data/database strErrorFile=/garz/bitcoin/data/db.log
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release
Double-ACK
older version (SVN 117 + listtransactions + getinfo KHPS) works fine, all bitcoins there. And yes, I should back up before following \"please upgrade\" instructions...
Can windows users upgrade to the 3.5 for now?
Yes, I've tested on Windows XP, 2003, and 7 all went through just fine. You'll enjoy the speed increase as well.
[
err, wait I guess, new version about to spawn]
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.
",
"nested_level": 0
},
{
"id": 1745,
"satoshi_id": 291,
"thread_id": 145,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: *** ALERT *** version 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=626.msg6480#msg6480",
"date": "2010-07-29T20:30:15Z",
"text": "SVN is updated with version 0.3.6.
Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.
",
"nested_level": 0
},
{
"id": 1746,
"thread_id": 145,
"source_id": "15",
"poster_name": "RudeDude",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=481",
"subject": "Re: *** ALERT *** version 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=626.msg6485#msg6485",
"date": "2010-07-29T20:35:54Z",
"text": "Ha! One of the changes in there is updated some v \"0.3.3\" stuff to \"0.3.6\" but that isn't the important part of the update. :-)
",
"nested_level": 0
},
{
"id": 1747,
"thread_id": 145,
"source_id": "16",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: *** ALERT *** version 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=626.msg6486#msg6486",
"date": "2010-07-29T20:48:35Z",
"text": "
SVN r119 seems to work fine here. No BDB explosion.
",
"nested_level": 0
},
{
"id": 1748,
"thread_id": 145,
"source_id": "17",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: *** ALERT *** version 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=626.msg6487#msg6487",
"date": "2010-07-29T20:51:29Z",
"text": "Tested the Windows build across XP, 2003, Vista, 7 (both 32 and 64bit builds), no issues installing or running client. So far so good, looking forward to the Linux client.
0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.
Is that working better?
If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*
Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
",
"nested_level": 0
},
{
"id": 1750,
"thread_id": 145,
"source_id": "19",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6492#msg6492",
"date": "2010-07-29T21:23:21Z",
"text": "Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?
64bit Client Error, will try out 32bit client and see if the error is similar.
./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)
The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.
Same error for 32bit client
./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)
Linux - Mandriva 2010.0 [64bit and 32bit] OS systems setup
0.3.6 binaries for linux works fine on two my machines (64 and 32 bits) with Debian squeeze/sid
",
"nested_level": 0
},
{
"id": 1752,
"thread_id": 145,
"source_id": "21",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6494#msg6494",
"date": "2010-07-29T21:28:55Z",
"text": "0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)
That's good to know, might just need to update mine, checking to see what versions I have currently installed.
Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?
64bit Client Error, will try out 32bit client and see if the error is similar.
./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)
The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.
Same error for 32bit client
./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)
I'm getting this too on 32-bit Ubuntu 9.10.
It works fine on 32-bit and 64-bit Ubuntu 10.04.
0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)
If you (and others) are willing,
please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an
older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).
Ah, mine is linked to 2.10.1, I'll bring my system up to bleeding edge to see if that solves it
[edit] Well turns out I can't package wise as they top out at 2.10 for now
0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)
If you (and others) are willing,
please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an
older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).
I would agree, would help those of us not on the bleeding edge of distro packages.
0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)
If you (and others) are willing,
please post your OS + OS version, when posting success/failure reports.
I will echo a recommendation to satoshi from another forum member: build linux binaries on an
older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).
sorry. I'm checked binaries on Debian GNU/Linux squeeze/sid
\"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)\" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
",
"nested_level": 0
},
{
"id": 1759,
"thread_id": 145,
"source_id": "28",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6503#msg6503",
"date": "2010-07-29T21:44:02Z",
"text": "v0.3.6 works on FreeBSD/i386 7.2,7.3 and on FreeBSD/amd64 8.0
Compiles cleanly without any warnings, and appears to be working fine.
",
"nested_level": 0
},
{
"id": 1760,
"thread_id": 145,
"source_id": "29",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6504#msg6504",
"date": "2010-07-29T21:45:06Z",
"text": "Maybe the points listed in
http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.
Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.
0.3.6 works great on Win7 Pro 64-Bit.
",
"nested_level": 0
},
{
"id": 1762,
"thread_id": 145,
"source_id": "31",
"poster_name": "Gooffy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=604",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6511#msg6511",
"date": "2010-07-29T22:08:14Z",
"text": "Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found
Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found
$ dpkg -l|grep -i glibc
ii libdb1-compat 2.1.3-9 The Berkeley database routines [glibc 2.0/2.
?
On Debian testing 32-bit, I get a few build errors, all resembling:
script.cpp:114: error: \u0091OP_NOP1\u0092 was not declared in this scope
I got these when attempting to \"make bitcoind\" without \"make clean\" or \"make\" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.
If anyone else gets this error, the simplest solution is to \"make clean\" and retry the build.
\"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)\" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
That's strange, 0.3.3 worked fine on it. It's no biggie, I need to upgrade that machine anyway.
Ubuntu Linux 9.10
Error:
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found
dpkg -l | egrep \"(libc6|glibc)\"
# This will display what version you currently have installed
# I guess you have glibc version 2.10 or older installed.
apt-get update
apt-cache showpkg libc6 | less
# Look (near the bottom) for the versions available for a 2.11 version
#Maybe you can just upgrade with:
apt-get upgrade libc6
# Above instruction for a real debian system, they might work with Ubuntu
On Debian testing 32-bit, I get a few build errors, all resembling:
script.cpp:114: error: \u0091OP_NOP1\u0092 was not declared in this scope
I got these when attempting to \"make bitcoind\" without \"make clean\" or \"make\" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.
If anyone else gets this error, the simplest solution is to \"make clean\" and retry the build.
We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to \"make -f makefile.unix clean\" or delete headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.
We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to \"make -f makefile.unix clean\" or delete headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.
I was going to compile a GLIBC_2.10 version until I noticed that I had to keep installing more and more to get through the check errors, LOL. Looks like I just need to fire up a Virtual Box with all the dev packages loaded to do this in a virtual machine to make life easier.
Could someone help me understand why it matters that hashing is 2x faster? If everyone were to upgrade the coin inflation rate would still remain the same. Thus there is a \"slight\" advantage to early adopters. I guess some could say it gives \"honest nodes\" more time and thus makes it even harder for dishonest nodes to gain an edge.
The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy. So I would think we would want to focus on aspects other than \"generation speed\" first.
",
"nested_level": 0
},
{
"id": 1770,
"thread_id": 145,
"source_id": "39",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6572#msg6572",
"date": "2010-07-30T01:25:48Z",
"text": "Could someone help me understand why it matters that hashing is 2x faster? If everyone were to upgrade the coin inflation rate would still remain the same. Thus there is a \"slight\" advantage to early adopters. I guess some could say it gives \"honest nodes\" more time and thus makes it even harder for dishonest nodes to gain an edge.
The #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy. So I would think we would want to focus on aspects other than \"generation speed\" first.
Quite simply to level the playing field for coin generation and to help maintain block generation at a stable rate. If everyone was limited to just 100 khash/s by the client, someone would just compile a client that does not have the limit and load it up on a server farm where they could generate 10,000 khash/s per machine. It would put the coin generation supply in the hands of who ever had a large amount of money to invest in servers and discourage everyone else from trying to mint coin. If we could trust that clients would only act as transaction nodes and that everyone would get a fair shot at coin generation then no one would care if the client was generating at 5 khash/s all the time.
So in a perfect world, no one would care that they can generate 2 or 3 times faster than someone else, but we don't live in a perfect world.
My khash rate went from 700 to 1700.Sweet!
",
"nested_level": 0
},
{
"id": 1772,
"thread_id": 145,
"source_id": "41",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6645#msg6645",
"date": "2010-07-30T13:53:56Z",
"text": "Maybe the points listed in
http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.
Getting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.
Great point. I got the bitcoind (without the wx GUI) compiling for Ubuntu 10.04
I'll try to get the other version to work too, but it's quite annoying that BC needs such a new version of libdb and wx...
https://build.opensuse.org/package/show?package=bitcoind&project=home:cdecker0.3.6 up and running on w2k/xp32/xp64/w7
nice speed-updates on all systems,
guess we can prepare for another major step up in difficulty, now that all nodes do 2-3times the hashes they did before.
is that a good or a bad thing?
",
"nested_level": 0
},
{
"id": 1774,
"thread_id": 145,
"source_id": "43",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6653#msg6653",
"date": "2010-07-30T14:16:08Z",
"text": "Fastest possible stock build removes any advantage other 'special' builds would have. Which is good because generation will be more uniformly distributed. It's important for the official build to be always the fastest available. It should use any known optimization (including CUDA, OpenCL, ability to work on the Cell proc etc).
The one and only effect for now - another difficulty adjustment, still same chance to generate until more users/cores came in.
",
"nested_level": 0
},
{
"id": 1775,
"thread_id": 145,
"source_id": "44",
"poster_name": "andy_3_913",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=385",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6667#msg6667",
"date": "2010-07-30T16:04:51Z",
"text": "would an auto-update function built into bc be possible?
",
"nested_level": 0
},
{
"id": 1776,
"thread_id": 145,
"source_id": "45",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6673#msg6673",
"date": "2010-07-30T16:49:25Z",
"text": "would an auto-update function built into bc be possible?
It's something that I have already suggested here :|
http://bitcointalk.org/index.php?topic=259.0sorry!
32Bit and 64Bit versions for Ubuntu 10.04 are available on the openSuse Build Service:
https://www.bitcoin.org/smf/index.php?topic=644.0I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.
",
"nested_level": 0
},
{
"id": 1780,
"satoshi_id": 300,
"thread_id": 145,
"source_id": "49",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: *** ALERT *** Upgrade to 0.3.6 ASAP!",
"url": "https://bitcointalk.org/index.php?topic=626.msg6711#msg6711",
"date": "2010-07-30T19:53:06Z",
"text": "I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.
I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:
Dependencies
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)
wxWidgets
---------
cd /usr/local
tar -xzvf wxWidgets-2.9.0.tar.gz
cd /usr/local/wxWidgets-2.9.0
mkdir buildgtk
cd buildgtk
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfig
added a comment in makefile.unix:
# for boost 1.37, add -mt to the boost libraries
LIBS= \\
-Wl,-Bstatic \\
-l boost_system \\
-l boost_filesystem \\
-l boost_program_options \\
-l boost_thread \\
-l db_cxx \\
-l crypto \\
-Wl,-Bdynamic \\
-l gthread-2.0
I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:
Dependencies
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)
That part I highlighted is what got me. You can't install all the libboost packages with that command (I tried to cheat with a * also), but part of my issue is I took it too literal like install *everything* that had to do with libboost, LOL.
Really, all that was needed was the libboost1.37-dev package and that made all the compile errors go away. Everything else worked out just fine as far as compiling your own wxWidgets, compiling Boost 1.4, etc.
So that last command should simply be
sudo apt-get install libboost1.37-devOn a side note, I compiled mine on a Ubuntu 64bit system, so the finished program came out 64bit aware. I'm testing it out on some 64bit systems to see how well things go.
So that last command should simply be
sudo apt-get install libboost1.37-dev
Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.
Seems they changed everything around in Boost recently, \"-mt\" and all that, makes it hard.
BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.
Mac OSX version is available now. See bitcoin.org or the SourceForge link.
adg
",
"nested_level": 0
},
{
"id": 1784,
"thread_id": 146,
"source_id": "2",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Implementation bug prior to 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=628.msg6472#msg6472",
"date": "2010-07-29T20:12:02Z",
"text": "In this forum, I don't see why not. Basically, the implementation bug means that the client wasn't following it's own rules. Someone may have found a way to double-spend coin for example that the Client doesn't catch because of how it processes the rules to counter this kind of action.
",
"nested_level": 0
},
{
"id": 1785,
"thread_id": 146,
"source_id": "3",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Implementation bug prior to 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=628.msg6473#msg6473",
"date": "2010-07-29T20:12:14Z",
"text": "Is it too early to discuss what happened until more users upgrade?
I am interested in the meta-discussion, about security policy.
In other open source projects, representatives of \"key parties\" tend to gather on a \"vendor security\" mailing list that is closed to the public. Vulnerabilities that might have real world consequences are discussed there, and then a coordinated release occurs, where all key players publish the security fixes at the same time.
Since we mostly communicate by forum here, the closest would be a member group that has access to a special forum here just for that issue that the public can't normally see. I'm fairly certain the simple machines forum supports that feature?
",
"nested_level": 0
},
{
"id": 1787,
"thread_id": 146,
"source_id": "5",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Implementation bug prior to 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=628.msg6476#msg6476",
"date": "2010-07-29T20:19:16Z",
"text": "I'd support the idea. More trusted members and programmers could post security risks or exploits. Maybe the better way is just to message the developer if they are discovered.
Both can work, but a members forum would help to keep out the noise; otherwise everyone will end up messaging the lead developer with every possible thing they here in the news and end up taking his/her time to filter it out on whether it's really a risk or not.
BTW, an important feature of these mailing lists is that anyone can post... but only the \"vendor security\" group can read the posts.
Thus, it is easy for an outsider with a real security issue to provide detailed information to
vendor-sec@myopensourceproject.org, while preventing unscrupulous people from reading the sensitive information.
I suppose a PM to <somebody>, plus discussion on a closed forum, is the best this forum software can handle.
Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.
",
"nested_level": 0
},
{
"id": 1790,
"thread_id": 147,
"source_id": "1",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Protocol Buffers for Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=632.msg6547#msg6547",
"date": "2010-07-29T23:29:31Z",
"text": "There has been a discussion going on
elsewhere about using protocol buffers for bitcoin. To summarise the advantages:
-> Small encoding
-> Very fast
-> Implementations in loads of languages (So writing new clients become a lot simpler)
-> Forwards compatible (indeed, this is most of the point of protocol buffers)
-> Extremely simpleto use in code
So initially I would suggest storing the wallet file using protocol buffers, this isn't a breaking change and immediately makes the wallet file easier for other programs to parse. Eventually I would hope that bitcoin could use protocol buffers for networking.
Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers. To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?
Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.
I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.
To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?
That would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully:
http://bitcointalk.org/index.php?topic=231.msg6250#msg6250Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.
I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.
That too, although the counter argument people always make to that is that we could do away with reserved bytes anyway. No matter how impractical that would be :/
To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?
That would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully:
http://bitcointalk.org/index.php?topic=231.msg6250#msg6250I was hoping for a transaction packet or something, but I'll give it a go with that for now. I could also test with the wallet file if anyone has decoded that?
Addendum:
Ok, Working from this summary of the version packet layout:
version
* {0xf9,0xbe,0xb4,0xd9}
* \"version\" (0x00 padded)
* 4 byte message size
* 4 byte checksum
* 8 byte nLocalServices (always 1 if !fClient, no idea either what that means)
* 8 byte timestamp (remember to use network byte order)
* Remote address (the address this Node thinks he is):
o nServices - uint64 (8b), still cryptic, don't know the meaning yet
o pchReserved - (12b): some reserved space, apparently for later IPv6
o ip - uint (4b)
o port - unsigned short (2b)
* Local address (the address this Node sees you under):
o nServices - uint64 (8b), still cryptic, don't know the meaning yet
o pchReserved - (12b): some reserved space, apparently for later IPv6
o ip - uint (4b)
o port - unsigned short (2b)
* 8 byte nLocalHostNonce (needed for a handshake, if I'm not mistaken)
* A subversion string \".0\" in my case
* nBestHeight - int (4b): appears to be the last block number
I created this protocol buffer definition:
message version
{
message AddressInfo
{
required unint64 nServices;
required fixed32 ip;
required uint32 port;
}
required uint32 magic = 2045; //0xf9 | 0xbe << 1 | 0xb4 << 2 | 0xd9 << 3
required uint32 version;
required int64 checksum;
required uint64 timestamp;
required uint64 nLocalServices;
required AddressInfo Remote; //the address this node thinks he is
required AddressInfo Local; //the address this node sees you under
required fixed64 nLocalHostNonce;
required string SubversionString;
required uint32 nBestHeight;
}
Does that look correct? The only changes I've made are that the indented things in the bullet point list are nested message types, and I've completely dropped the 12 bytes of reserved ipv6 space (since that can easily be added in later, which is the point of protocol buffers). I should point out that I probbaly haven't picked the best encoding types for all these fields, that depends upon the values they're likely to store, so in practice the packet will probably be a little smaller than my tests indicate
I used the above protocol buffer (as I said before, it's probably not optimal) and data obtained via
http://www.alloscomp.com/bitcoin/version.pys as test data.
Version: 306
nLocalServices: 1
nTime: 1280487684
addrYou: #.#.#.#:#### (nServices: 1)
addrMe: #.#.#.#:#### (nServices: 1)
nLocalHostNonce: 2359069617775922941
vSubStr: \"\"
nBestHeight: 71137
The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is over half the size of the hand built layout!
Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.
I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.
Not only does it allow it to drop reserved fields, but it uses ZigZag encoding and some other tricks to keep integers and the like as absolutely small as possible. So yea, it uses clever encoding. =P It's also blazingly fast to process!
The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is half the size of the hand built layout!
I realize that you are evangelizing for protocol buffers (and you seem to be doing a very good job of it too, I might add), but I will challenge that hand built data layouts are always bad.
Still, I hope this does give some food for thought and on a practical basis any improvement in the network protocol that shaves off a few bytes is always better. This doesn't seem to sacrifice too much in terms of the overhead either. More significantly, you are calling attention to an area of efficiency that needs to be addressed and is very helpful to the project. Thank you for doing that. I'm hoping to get caught up to where you are at now on this protocol business.
Speaking of the network...
... is there any really robust, generic, low-latency, open source p2p network \"middleware\" out there?
I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers \"buys\" enough to be worth the effort (at least not now, when transaction volume is low).
I'd like to see some experimenting with running bitcoin on top of a different networking layer (and use protocol buffers, too). Is there a p2p network that is designed to be extremely highly reliable and difficult to infiltrate or attack with malicious nodes?
",
"nested_level": 0
},
{
"id": 1797,
"thread_id": 147,
"source_id": "8",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Protocol Buffers for Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=632.msg6664#msg6664",
"date": "2010-07-30T15:47:33Z",
"text": "FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet. Packets are padded up to 60 bytes, if they are smaller.
",
"nested_level": 0
},
{
"id": 1798,
"thread_id": 147,
"source_id": "9",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: Protocol Buffers for Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=632.msg6675#msg6675",
"date": "2010-07-30T16:54:27Z",
"text": "The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is half the size of the hand built layout!
I realize that you are evangelizing for protocol buffers (and you seem to be doing a very good job of it too, I might add), but I will challenge that hand built data layouts are always bad.
Still, I hope this does give some food for thought and on a practical basis any improvement in the network protocol that shaves off a few bytes is always better. This doesn't seem to sacrifice too much in terms of the overhead either. More significantly, you are calling attention to an area of efficiency that needs to be addressed and is very helpful to the project. Thank you for doing that. I'm hoping to get caught up to where you are at now on this protocol business.
They're not always bad. However, if you put in so much effort that your hand built packet was smaller than a protocol buffer then you're probably putting too much effort into a micro optimisation
I'll be happy to help anyone catch up with the protocol buffers. If someone is willing to work with me I'd even work on a patch, I have very little C++ experience so I can't do it alone unfortunately.
I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers \"buys\" enough to be worth the effort (at least not now, when transaction volume is low).
I would disagree, protocol buffers are smaller which is nice, but it's not their main advantage - they're forwards compatible which is a hugely important thing in a p2p network, they're also something which can easily be used in many languages, which make implementing new clients in new languages easier, which in my opinion is vital for bitcoin.
FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet. Packets are padded up to 60 bytes, if they are smaller.
Indeed, but the version packet is probably the smallest packet of all the ones sent, so we'll gain more elsewhere. Also, keep an eye on the main point. The fact that protocol buffers are smaller is a nice aside to the fact that they're Forwards compatible and make bitcoin portable between languages.
The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is over half the size of the hand built layout!
The \"0x00\" groups each represent one byte. The length of the standard version packet is 87 bytes plus 20 for the header. The header could be massively optimized as well:
message start \"magic bytes\" - 0xF9 0xBE 0xB4 0xD9
command - name of command, 0 padded to 12 bytes \"version\\0\\0\\0\\0\\0\"
size - 4 byte int
checksum (absent for messages without data and version messages) - 4 bytes
Obviously using proto buffers here, while absolutely a breaking change, would save a fair bit of space, especially because the \"I've created a transaction\" packet has the name \"tx\" meaning that there's at least 10 bytes of overhead in every one of those packets.
The \"0x00\" groups each represent one byte.
Oops
breaking change
I think the best way to phase in protocol bufferswould to avoid breaking changes to start with, instead start with protocol buffers for the local files (like the wallet), which would gain us a little bit of size on disk, ease of reading the wallet file in other software, and get some experience using protocol buffers. Then is the time to start phasing in protocol buffers for networking in my opinion.
Does the current version of bitcoin have any handling for ignoring chunks of a packet? If so, phasing in protocol buffers could be as simple as writing the current packet AND writing the protocol buffer (as an ignored field for older clients), then once enough people have upgraded get rid of the old encoding.
Why do you consider it a breaking change? There's no reason you couldn't first try with the new protocol and then retry using the old bitcoin serialization technique. Also I think this is a change that should be made sooner rather then later while the BitCoin community is still small. It's already been a major blocker in making new clients and delaying it is going to hamper bitcoin's adoption.
",
"nested_level": 0
},
{
"id": 1802,
"thread_id": 147,
"source_id": "13",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: Protocol Buffers for Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=632.msg6992#msg6992",
"date": "2010-08-02T11:37:33Z",
"text": "Why do you consider it a breaking change? There's no reason you couldn't first try with the new protocol and then retry using the old bitcoin serialization technique.
That's a very good idea, and I would say it's the way to go with this.
Also I think this is a change that should be made sooner rather then later while the BitCoin community is still small. It's already been a major blocker in making new clients and delaying it is going to hamper bitcoin's adoption.
Since it's a non breaking change, it should be done as soon as possible in my opinion, for those very reasons.
The question remains, is anyone willing to help implement it? I'm an experience programmer but I have no C++ experience unfortunately, so I'm gonna need a little help if I try to do this myself
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 something unexpected.
I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.
CAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)
The larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.
On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves.
",
"nested_level": 0
},
{
"id": 1804,
"thread_id": 148,
"source_id": "1",
"poster_name": "chaord",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=262",
"subject": "Building initial transaction trust through \"coin ripping\"",
"url": "https://bitcointalk.org/index.php?topic=635.msg6588#msg6588",
"date": "2010-07-30T04:02:55Z",
"text": "I'm certainly not a cryptographer by trade or anything so I'm not sure if this idea holds any water. As I browse the forums I am noticing that perhaps one of the bigger issues when transacting with BC is building reputation between the transacting parties. In particular, the very first transaction seems to be critical.
I'm wondering if a solution, similar to what Professor Markus Jakobsson proposed in his paper could work? See
http://romualdogrillo.net/index.php?option=com_content&view=article&id=48&Itemid=54 for an overview. In a nutshell, the goal with \"coin ripping\" is similar to what could be done with traditional paper money.
- If A is going to perform $5 of service for B, they each can take out a $5 bill and rip them in half.
- Now A and B would each have 2 halve's of a $5 bill, but neither would have the correct halves.
- Therefore A is incentivized to actually perform the service for B, since this is the only way for him to receive both the missing half from his original $5bill back and the missing half of B's original $5 bill.
- The result is a transfer of $5 to A from B (as originally planned) in exchange for service.
Of course, if A or B is a scammer, with this scenario both of them would lose. In other words, it wouldn't pay to be a scammer.
I don't know if this is something that would qualify for design consideration, but if all transactions were \"ripped\" by default, it might set people's minds at ease. Additionally, it could possibly be algorithmically implemented unlike a staffed escrow account.
What do you guys think?
That's very clever. Satoshi has implied that there is great flexibility in the way transactions could work:
http://bitcointalk.org/index.php?topic=195.msg1611#msg1611. I think he may have had such ideas in mind.
In time, hopefully, numerous such arrangements can be used to fully develop the idea of 'smart' contracts (
http://en.wikipedia.org/wiki/Smart_contracts). The current Bitcoin implementation already represents a working example of smart contracts: software encoded rules governing digital property. Rothbard in
Ethics of Liberty talks about how powerful the simple penal bond was to medieval commerce (
http://mises.org/rothbard/ethics/nineteen.asp). Given the right contract tools, the Bitcoin economy will be able to flourish without relying on the expense and ethical contradictions of state courts.
XC
To make that work in bitcoin you would need to be able to create a private key that both of you know, but a public key that each of you only know *half* of. In the crypto sense of half, where there are two secrets that can be combined together mathematically to make a third secret.
You would both transfer 5 BTC to the bitcoin address matching the public key. Then neither could retrieve the coins until one surrendered his half to the other.
A proxy comes to mine, but that is cheating. If you used a proxy to generate the private key and split it, they would know the private key and in that case you might as well trust them to hold the money without splitting the key.
I don't know enough about how elliptic curve based keys are generated to propose an algorithm. But stranger things have happened in crypto than that. In some cases, you can do math with two unknown encrypted numbers and have and have the answer decrypt correctly.
Go figure.
",
"nested_level": 0
},
{
"id": 1807,
"thread_id": 148,
"source_id": "4",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: Building initial transaction trust through \"coin ripping\"",
"url": "https://bitcointalk.org/index.php?topic=635.msg6627#msg6627",
"date": "2010-07-30T08:13:24Z",
"text": "One possibility would be to ask a algorithmically selected node from the network as intermediary. It would be possible, I suspect, to make the system work in such a way that nobody can get the money unless the two parties and the intermediary cooperate (so the intermediary cannot steal the money)
",
"nested_level": 0
},
{
"id": 1808,
"thread_id": 148,
"source_id": "5",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Building initial transaction trust through \"coin ripping\"",
"url": "https://bitcointalk.org/index.php?topic=635.msg7374#msg7374",
"date": "2010-08-04T00:17:33Z",
"text": "I think that Red's idea is great if it can be properly designed.
The only problem with this whole procedure is that both parties are required to put up capital. The one buying a service and the one performing the service both must put up cash. Unfortunately the one providing the service is also putting up their service.
",
"nested_level": 0
},
{
"id": 1809,
"satoshi_id": 316,
"thread_id": 148,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Building initial transaction trust through \"coin ripping\"",
"url": "https://bitcointalk.org/index.php?topic=635.msg7385#msg7385",
"date": "2010-08-04T00:40:40Z",
"text": "The software is designed to support things like this. I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.
",
"nested_level": 0
},
{
"id": 1810,
"thread_id": 149,
"source_id": "1",
"poster_name": "Dybbuk",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=638",
"subject": "Bug: \"Immature\" coins lost in wallet.dat during transaction",
"url": "https://bitcointalk.org/index.php?topic=642.msg6672#msg6672",
"date": "2010-07-30T16:39:16Z",
"text": "Howdy,
I am running R119 on a Linux box, and last night was fortunate enough to solve a block and get 50 BTC. Hooray, right? Well, I tried to send 30 BTC before they were \"mature\" (i.e. before the 100+ block mark had passed), and so of course bitcoind reported an error. However, it also marked those 30 coins as spent, so not only was no transaction created, but the coins aren't usable by me at the moment.
Here is the relevant bit from my debug.log:
ThreadRPCServer method=sendtoaddress
CommitTransaction:
CTransaction(hash=cf3bee, ver=1, vin.size=1, vout.size=2, nLockTime=0)
CTxIn(COutPoint(e9894c, 0), scriptSig=0x014866DE7A1889014BAC9A)
CTxOut(nValue=20.00000000, scriptPubKey=OP_DUP OP_HASH160 0x01BA)
CTxOut(nValue=30.00000000, scriptPubKey=OP_DUP OP_HASH160 0x3F3A)
AddToWallet cf3bee new
CommitTransaction() : Error: Transaction not validreceived: addr (27 bytes)
07/30/10 15:27:00 Flushing wallet.dat
Flushed wallet.dat 1ms
So my wallet started with 50.01 BTC in it (the 0.01 was just a test I'd run the other day from one machine to another), and now my wallet just has 20.01 BTC in it. I'm a little sad---I was excited about generating those coins!
Erik
",
"nested_level": 0
},
{
"id": 1811,
"satoshi_id": 298,
"thread_id": 149,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bug: \"Immature\" coins lost in wallet.dat during transaction",
"url": "https://bitcointalk.org/index.php?topic=642.msg6701#msg6701",
"date": "2010-07-30T19:19:05Z",
"text": "I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says \"you don't have enough money\" or \"Insufficient funds\" from the command line.
How many blocks did it say it had left to mature when you sent?
There's a chance it might still go through.
Have you copied or moved your wallet.dat in any way?
",
"nested_level": 0
},
{
"id": 1812,
"thread_id": 150,
"source_id": "1",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Automated nightly builds",
"url": "https://bitcointalk.org/index.php?topic=644.msg6688#msg6688",
"date": "2010-07-30T18:31:48Z",
"text": "I finally managed to get the openSuse Build Service (OBS) to build working nightly packages of bitcoind (the client without the wx GUI). openSuse and SLE will follow soon.
To install the Ubuntu packages add the following line to your /etc/apt/sources.list:
deb http://download.opensuse.org/repositories/home:/cdecker/xUbuntu_10.04/ ./
Next update:
sudo aptitude update
sudo aptitude install bitcoind
If you get a warning about not being able to verify the validity of the packages, just ignore them, I wasn't able to find the public key yet :-)
Then just create a config file ~/.bitcoin/bitcoin.conf to configure the RPC password:
rpcpassword=<yourpassword>
After this just start the daemon via
bitcoind
and control it using the JSON interface.
I'll be trying to create openSuse and SLE packages too, Debian would be possible too, but compiling wx, boost and libdb sounds a bit excessive to me, anyone interested in helping?
I'll be trying to create openSuse and SLE packages too, Debian would be possible too, but compiling wx, boost and libdb sounds a bit excessive to me, anyone interested in helping?
Nightly builds are a great idea; does the build service do an automatic svn update? Anybody else willing to help get GUI-bitcoin building (or anybody know somebody on the wxWidgets team?)
Actually the openSuse Build Service is more meant for packages that have to be reliably built for a multitude of systems and updated consistently across all of the distros, but adding a small cron job can pull SVN and push the changes to the Build Service, kicking off a recompile. I wouldn't abuse it though.
I think we should sooner or later add a continuous integration tool, to check code submissions against the (until now inexisting) unit tests. That would also be able to create nightly builds ^^
",
"nested_level": 0
},
{
"id": 1815,
"satoshi_id": 531,
"thread_id": 150,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Automated nightly builds",
"url": "https://bitcointalk.org/index.php?topic=644.msg28643#msg28643",
"date": "2010-12-09T18:28:45Z",
"text": "Thanks for setting this up Cdecker.
Is there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?
",
"nested_level": 0
},
{
"id": 1816,
"thread_id": 151,
"source_id": "1",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "A proposal for a semi-automated Escrow mechanism",
"url": "https://bitcointalk.org/index.php?topic=645.msg6704#msg6704",
"date": "2010-07-30T19:29:08Z",
"text": "So, the basic escrow works by two people working through a third party to exchange (usually money) for some other form of goods or services.
In a transaction where both people are honest, the escrow business can essentially be automatic since the buyer gets his goods and approves release of funds, only when there is a dispute does human interaction become necessary. Therefore, I propose the following system:
1) you create an escrow transaction for the amount, authorised by your key and containing the recipient's key/data etc - this block cannot be claimed until a subsequent block is issued by the buyer to approve it, it's also impossible for the buyer to reclaim it without the seller approving it to be returned.
2) it enters the network, gets verified and the seller sends the goods, once the buyer gets them, he creates a release transaction and the seller gets his bitcoins.
3) if a dispute occurs and both parties are refusing to release the money one way or the other, clearly it's now necessary to get a third party to arbitrate - in this situation, a signature from both the buyer and seller authorising a third party is required which will give that third party ownership of the original escrow transaction and they can then arbitrate the matter
",
"nested_level": 0
},
{
"id": 1817,
"thread_id": 151,
"source_id": "2",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: A proposal for a semi-automated Escrow mechanism",
"url": "https://bitcointalk.org/index.php?topic=645.msg6721#msg6721",
"date": "2010-07-30T21:09:51Z",
"text": "Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special \"all clear\" message to that server that then knows to \"release\" what it has to whoever it's suppose to go to.
Programming wise, should be possible with direct IP payments for example, where the \"From\" and \"Comment\" fields can be used to \"reserve\" the BTC until later.
One could send a transaction and in the comment field put something like \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special \"all clear\" message to that server that then knows to \"release\" what it has to whoever it's suppose to go to.
Programming wise, should be possible with direct IP payments for example, where the \"From\" and \"Comment\" fields can be used to \"reserve\" the BTC until later.
One could send a transaction and in the comment field put something like \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\".
When the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.
Very doable from a programming standpoint.
kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.
kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.
I'd go too with websites offering escrow services. The network is quiet complex as it is, without having to add all the confirmation, delay and dispute stuff.
Currently when a transaction is broadcast it'll sooner or later be added to the block chain, what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
Also who do you think will be the third party moderating the dispute? There is no real advantage in adding it to the protocol itself.
what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.
what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.
I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.
if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.
1) be spiteful and nobody will get anything
2) agree on a third party to send the money to. that third party will be an arbitrator who will weigh up both sides of the argument and come to a decision as to who should be returned the money, minus whatever fee they agreed with the two hurt parties.
Subsequent to this, I also realised that my suggestion is open to trolling whereby a seller makes someone do an escrow transaction and then refuses to ship anything or arbitrate, my solution to this issue gives the following modification of the system:
the buyer makes an escrow transaction which is then presented to the seller, if the seller wants to go ahead, they must agree to be debited a sum stipulated by the buyer, the seller agrees and the escrow transaction then goes into the network for inclusion into the block chain, both parties are now down on their money.
if everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his \"trust deposit\" returned.
if the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.
if nobody can agree on a release, both parties now have an incentive to go to an arbitrator, when the arbitrator is authorised to receive the transaction funds, the trust deposit gets immediately returned to the seller, the arbitrator doesn't get a say over those funds.
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
",
"nested_level": 0
},
{
"id": 1823,
"thread_id": 151,
"source_id": "8",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: A proposal for a semi-automated Escrow mechanism",
"url": "https://bitcointalk.org/index.php?topic=645.msg7718#msg7718",
"date": "2010-08-05T18:30:35Z",
"text": "A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
That is really quite clever!
Do you simply assign the transaction to two bitcoin addresses and transmit it to the network for inclusion in the block list?
Can you do more than two? Is it a one-or-more situation?
Is this feature in the GUI yet?
A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.
Due to that recourse, it is unlikely to be used as an escrow mechanism
Due to that recourse, it is unlikely to be used as an escrow mechanism
Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)
This patch will calculate four hashes on one core using vector instructions. There's a test programm included that validates the new hash function against the old one so it should be correct.
The patch is against 0.3.6. Improves khash/s by roughly 115%.
http://pastebin.com/XN1JDb53I take it that you've already tested the hash limit before performance starts to suffer against the stock code? I'm just curious myself.
",
"nested_level": 0
},
{
"id": 1828,
"thread_id": 152,
"source_id": "3",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6730#msg6730",
"date": "2010-07-30T21:47:22Z",
"text": "Performance of stock code (as measured by my test/benchmark program) is about 1500khash/s.
My code does 3500khash/s. Both figures are for one core. It scales well because I do 128 hashes at once and keep the datastructures small enough to fit in the CPU cache.
I have two local collision attacks which will squeeze another 300khash/s out, but they are not stable yet.
",
"nested_level": 0
},
{
"id": 1829,
"thread_id": 152,
"source_id": "4",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6732#msg6732",
"date": "2010-07-30T21:51:10Z",
"text": "Awesome, I'll have to give it a try myself then.
Tell me if it works
Donations are welcome. 17asVKkzRGTFvvGH9dMGQaHe78xzfvgSSA
That's amazing...
So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.
",
"nested_level": 0
},
{
"id": 1832,
"thread_id": 152,
"source_id": "7",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6777#msg6777",
"date": "2010-07-31T04:49:33Z",
"text": "Darn, it means the next release, the difficulty is going to have to increase to 1000 or so to keep up, LOL
That's amazing...
So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.
That's how it works. Four 32 bit values in a 128 bit vector. They're calculated independently, but at the same time.
Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?
hmm...I wasn't able to apply the patch (I'm a noobie). Here's the command I ran from bitcoin-0.3.6/src # patch < XN1JDb53.txt
Output:
1 out of 1 hunk ignored
(Stripping trailing CRs from patch.)
patching file main.cpp
Hunk #1 FAILED at 2555.
Hunk #2 FAILED at 2701.
2 out of 2 hunks FAILED
(Stripping trailing CRs from patch.)
patching file makefile.unix
Hunk #1 FAILED at 45.
Hunk #2 FAILED at 58.
What's the proper command to type into linux? Or do you have linux binaries?
",
"nested_level": 0
},
{
"id": 1835,
"thread_id": 152,
"source_id": "10",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6817#msg6817",
"date": "2010-07-31T14:18:03Z",
"text": "the mean client would send all generated bitcoins to a certain address
@em3rgent0rder: i don't know why it fails, but it should be easy to patch it manually...
hmm...I wasn't able to apply the patch (I'm a noobie). Here's the command I ran from bitcoin-0.3.6/src # patch < XN1JDb53.txt
Output:
1 out of 1 hunk ignored
(Stripping trailing CRs from patch.)
patching file main.cpp
Hunk #1 FAILED at 2555.
Hunk #2 FAILED at 2701.
2 out of 2 hunks FAILED
(Stripping trailing CRs from patch.)
patching file makefile.unix
Hunk #1 FAILED at 45.
Hunk #2 FAILED at 58.
It definitely does not apply to the SVN trunk. Maybe tcatm could post the main.cpp itself?
Looks like pastebin.com messes up the patch...
diff --git a/cryptopp/sha256.cpp b/cryptopp/sha256.cpp
new file mode 100644
index 0000000..15f8be1
--- /dev/null
+++ b/cryptopp/sha256.cpp
@@ -0,0 +1,443 @@
+#include <string.h>
+#include <assert.h>
+
+#include <xmmintrin.h>
+#include <stdint.h>
+#include <stdio.h>
+
+#define NPAR 32
+
+static const unsigned int sha256_consts[] = {
+
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, /* 0 */
+
0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
+
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, /* 8 */
+
0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
+
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, /* 16 */
+
0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
+
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, /* 24 */
+
0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
+
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, /* 32 */
+
0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
+
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, /* 40 */
+
0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
+
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, /* 48 */
+
0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
+
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, /* 56 */
+
0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+};
+
+
+static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {
+
return (b & c) ^ (~b & d);
+}
+
+static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {
+
return (b & c) ^ (b & d) ^ (c & d);
+}
+
+static inline __m128i ROTR(__m128i x, const int n) {
+
return _mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n);
+}
+
+static inline __m128i SHR(__m128i x, const int n) {
+
return _mm_srli_epi32(x, n);
+}
+
+/* SHA256 Functions */
+#define
BIGSIGMA0_256(x)
(ROTR((x), 2) ^ ROTR((x), 13) ^ ROTR((x), 22))
+#define
BIGSIGMA1_256(x)
(ROTR((x), 6) ^ ROTR((x), 11) ^ ROTR((x), 25))
+#define
SIGMA0_256(x)
(ROTR((x), 7) ^ ROTR((x), 18) ^ SHR((x), 3))
+#define
SIGMA1_256(x)
(ROTR((x), 17) ^ ROTR((x), 19) ^ SHR((x), 10))
+
+static inline __m128i load_epi32(const unsigned int x0, const unsigned int x1, const unsigned int x2, const unsigned int x3) {
+
return _mm_set_epi32(x0, x1, x2, x3);
+}
+
+static inline unsigned int store32(const __m128i x, int i) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x;
+
return box.ret[i];
+}
+
+static inline void store_epi32(const __m128i x, unsigned int *x0, unsigned int *x1, unsigned int *x2, unsigned int *x3) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x;
+
*x0 = box.ret[3]; *x1 = box.ret[2]; *x2 = box.ret[1]; *x3 = box.ret[0];
+}
+
+static inline __m128i SHA256_CONST(const int i) {
+
return _mm_set1_epi32(sha256_consts[i]);
+}
+
+#define add4(x0, x1, x2, x3) _mm_add_epi32(_mm_add_epi32(_mm_add_epi32(x0, x1), x2), x3)
+#define add5(x0, x1, x2, x3, x4) _mm_add_epi32(add4(x0, x1, x2, x3), x4)
+
+#define
SHA256ROUND(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+d = _mm_add_epi32(d, T1); \\
+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c)); \\
+h = _mm_add_epi32(T1, T2);
+
+#define
SHA256ROUND_lastd(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+d = _mm_add_epi32(d, T1);
+//T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));
+//h = _mm_add_epi32(T1, T2);
+
+#define
SHA256ROUND_last(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c)); \\
+h = _mm_add_epi32(T1, T2);
+
+static inline unsigned int swap(unsigned int value) {
+
__asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));
+
return value;
+}
+
+static inline unsigned int SWAP32(const void *addr) {
+
unsigned int value = (*((unsigned int *)(addr)));
+
__asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));
+
return value;
+}
+
+static inline void dumpreg(__m128i x, char *msg) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x ;
+
printf(\"%s %08x %08x %08x %08x\n\", msg, box.ret[0], box.ret[1], box.ret[2], box.ret[3]);
+}
+
+#if 1
+#define dumpstate(i) printf(\"%s: %08x %08x %08x %08x %08x %08x %08x %08x %08x\n\", \\
+
__func__, store32(w0, i), store32(a, i), store32(b, i), store32(c, i), store32(d, i), store32(e, i), store32(f, i), store32(g, i), store32(h, i));
+#else
+#define dumpstate()
+#endif
+void Double_BlockSHA256(const void* pin, void* pad, const void *pre, unsigned int thash[8][NPAR], const void *init)
+{
+
unsigned int* In = (unsigned int*)pin;
+
unsigned int* Pad = (unsigned int*)pad;
+
unsigned int* hPre = (unsigned int*)pre;
+
unsigned int* hInit = (unsigned int*)init;
+
unsigned int i, j, k;
+
+
/* vectors used in calculation */
+
__m128i w0, w1, w2, w3, w4, w5, w6, w7;
+
__m128i w8, w9, w10, w11, w12, w13, w14, w15;
+
__m128i T1, T2;
+
__m128i a, b, c, d, e, f, g, h;
+
+
/* nonce offset for vector */
+
__m128i offset = load_epi32(0x00000003, 0x00000002, 0x00000001, 0x00000000);
+
+
+
for(k = 0; k<NPAR; k+=4) {
+
w0 = load_epi32(In[0], In[0], In[0], In[0]);
+
w1 = load_epi32(In[1], In[1], In[1], In[1]);
+
w2 = load_epi32(In[2], In[2], In[2], In[2]);
+
w3 = load_epi32(In[3], In[3], In[3], In[3]);
+
w4 = load_epi32(In[4], In[4], In[4], In[4]);
+
w5 = load_epi32(In[5], In[5], In[5], In[5]);
+
w6 = load_epi32(In[6], In[6], In[6], In[6]);
+
w7 = load_epi32(In[7], In[7], In[7], In[7]);
+
w8 = load_epi32(In[8], In[8], In[8], In[8]);
+
w9 = load_epi32(In[9], In[9], In[9], In[9]);
+
w10 = load_epi32(In[10], In[10], In[10], In[10]);
+
w11 = load_epi32(In[11], In[11], In[11], In[11]);
+
w12 = load_epi32(In[12], In[12], In[12], In[12]);
+
w13 = load_epi32(In[13], In[13], In[13], In[13]);
+
w14 = load_epi32(In[14], In[14], In[14], In[14]);
+
w15 = load_epi32(In[15], In[15], In[15], In[15]);
+
+
/* hack nonce into lowest byte of w3 */
+
__m128i k_vec = load_epi32(k, k, k, k);
+
w3 = _mm_add_epi32(w3, offset);
+
w3 = _mm_add_epi32(w3, k_vec);
+
+
a = load_epi32(hPre[0], hPre[0], hPre[0], hPre[0]);
+
b = load_epi32(hPre[1], hPre[1], hPre[1], hPre[1]);
+
c = load_epi32(hPre[2], hPre[2], hPre[2], hPre[2]);
+
d = load_epi32(hPre[3], hPre[3], hPre[3], hPre[3]);
+
e = load_epi32(hPre[4], hPre[4], hPre[4], hPre[4]);
+
f = load_epi32(hPre[5], hPre[5], hPre[5], hPre[5]);
+
g = load_epi32(hPre[6], hPre[6], hPre[6], hPre[6]);
+
h = load_epi32(hPre[7], hPre[7], hPre[7], hPre[7]);
+
+
SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);
+
+#define store_load(x, i, dest) \\
+
w8 = load_epi32((hPre)[i], (hPre)[i], (hPre)[i], (hPre)[i]); \\
+
dest = _mm_add_epi32(w8, x);
+
+
store_load(a, 0, w0);
+
store_load(b, 1, w1);
+
store_load(c, 2, w2);
+
store_load(d, 3, w3);
+
store_load(e, 4, w4);
+
store_load(f, 5, w5);
+
store_load(g, 6, w6);
+
store_load(h, 7, w7);
+
+
w8 = load_epi32(Pad[8], Pad[8], Pad[8], Pad[8]);
+
w9 = load_epi32(Pad[9], Pad[9], Pad[9], Pad[9]);
+
w10 = load_epi32(Pad[10], Pad[10], Pad[10], Pad[10]);
+
w11 = load_epi32(Pad[11], Pad[11], Pad[11], Pad[11]);
+
w12 = load_epi32(Pad[12], Pad[12], Pad[12], Pad[12]);
+
w13 = load_epi32(Pad[13], Pad[13], Pad[13], Pad[13]);
+
w14 = load_epi32(Pad[14], Pad[14], Pad[14], Pad[14]);
+
w15 = load_epi32(Pad[15], Pad[15], Pad[15], Pad[15]);
+
+
a = load_epi32(hInit[0], hInit[0], hInit[0], hInit[0]);
+
b = load_epi32(hInit[1], hInit[1], hInit[1], hInit[1]);
+
c = load_epi32(hInit[2], hInit[2], hInit[2], hInit[2]);
+
d = load_epi32(hInit[3], hInit[3], hInit[3], hInit[3]);
+
e = load_epi32(hInit[4], hInit[4], hInit[4], hInit[4]);
+
f = load_epi32(hInit[5], hInit[5], hInit[5], hInit[5]);
+
g = load_epi32(hInit[6], hInit[6], hInit[6], hInit[6]);
+
h = load_epi32(hInit[7], hInit[7], hInit[7], hInit[7]);
+
+
SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);
+
+
/* store resulsts directly in thash */
+#define store_2(x,i) \\
+
w0 = load_epi32((hInit)[i], (hInit)[i], (hInit)[i], (hInit)[i]); \\
+
*(__m128i *)&(thash)[i][0+k] = _mm_add_epi32(w0, x);
+
+
store_2(a, 0);
+
store_2(b, 1);
+
store_2(c, 2);
+
store_2(d, 3);
+
store_2(e, 4);
+
store_2(f, 5);
+
store_2(g, 6);
+
store_2(h, 7);
+
}
+
+}
diff --git a/main.cpp b/main.cpp
index ddc359a..d30d642 100755
--- a/main.cpp
+++ b/main.cpp
@@ -2555,8 +2555,10 @@ inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)
CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);
}
+// !!!! NPAR must match NPAR in cryptopp/sha256.cpp !!!!
+#define NPAR 32
-
+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[8][NPAR], const void *init2);
void BitcoinMiner()
@@ -2701,108 +2703,123 @@ void BitcoinMiner()
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
uint256 hashbuf[2];
uint256& hash = *alignup<16>(hashbuf);
+
+ // Cache for NPAR hashes
+ unsigned int thash[8][NPAR];
+
+ unsigned int j;
loop
{
- SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
- SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);
+ Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);
- if (((unsigned short*)&hash)[14] == 0)
+ for(j = 0; j<NPAR; j++) {
+ if (thash[7][j] == 0)
{
- // Byte swap the result after preliminary check
- for (int i = 0; i < sizeof(hash)/4; i++)
- ((unsigned int*)&hash)[i] = ByteReverse(((unsigned int*)&hash)[i]);
-
- if (hash <= hashTarget)
+ // Byte swap the result after preliminary check
+ for (int i = 0; i < sizeof(hash)/4; i++)
+ ((unsigned int*)&hash)[i] = ByteReverse((unsigned int)thash[i][j]);
+
+ if (hash <= hashTarget)
+ {
+ // Double_BlocSHA256 might only calculate parts of the hash.
+ // We'll insert the nonce and get the real hash.
+ //pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
+ //hash = pblock->GetHash();
+
+ pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
+ assert(hash == pblock->GetHash());
+
+ //// debug print
+ printf(\"BitcoinMiner:\n\");
+ printf(\"proof-of-work found \n hash: %s \ntarget: %s\n\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
+ pblock->print();
+ printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
+ printf(\"generated %s\n\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());
+
+ SetThreadPriority(THREAD_PRIORITY_NORMAL);
+ CRITICAL_BLOCK(cs_main)
{
- pblock->nNonce = ByteReverse(tmp.block.nNonce);
- assert(hash == pblock->GetHash());
-
- //// debug print
- printf(\"BitcoinMiner:\n\");
- printf(\"proof-of-work found \n hash: %s \ntarget: %s\n\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
- pblock->print();
- printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
- printf(\"generated %s\n\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());
-
- SetThreadPriority(THREAD_PRIORITY_NORMAL);
- CRITICAL_BLOCK(cs_main)
- {
- if (pindexPrev == pindexBest)
- {
- // Save key
- if (!AddKey(key))
- return;
- key.MakeNewKey();
-
- // Track how many getdata requests this block gets
- CRITICAL_BLOCK(cs_mapRequestCount)
- mapRequestCount[pblock->GetHash()] = 0;
-
- // Process this block the same as if we had received it from another node
- if (!ProcessBlock(NULL, pblock.release()))
- printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\n\");
- }
- }
- SetThreadPriority(THREAD_PRIORITY_LOWEST);
-
- Sleep(500);
- break;
+ if (pindexPrev == pindexBest)
+ {
+ // Save key
+ if (!AddKey(key))
+ return;
+ key.MakeNewKey();
+
+ // Track how many getdata requests this block gets
+ CRITICAL_BLOCK(cs_mapRequestCount)
+ mapRequestCount[pblock->GetHash()] = 0;
+
+ // Process this block the same as if we had received it from another node
+ if (!ProcessBlock(NULL, pblock.release()))
+ printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\n\");
+
+ }
}
- }
+ SetThreadPriority(THREAD_PRIORITY_LOWEST);
- // Update nTime every few seconds
- const unsigned int nMask = 0xffff;
- if ((++tmp.block.nNonce & nMask) == 0)
+ Sleep(500);
+ break;
+ }
+ }
+ }
+
+ // Update nonce
+ tmp.block.nNonce += NPAR;
+
+ // Update nTime every few seconds
+ const unsigned int nMask = 0xffff;
+ if ((tmp.block.nNonce & nMask) == 0)
+ {
+ // Meter hashes/sec
+ static int64 nTimerStart;
+ static int nHashCounter;
+ if (nTimerStart == 0)
+ nTimerStart = GetTimeMillis();
+ else
+ nHashCounter++;
+ if (GetTimeMillis() - nTimerStart > 4000)
{
- // Meter hashes/sec
- static int64 nTimerStart;
- static int nHashCounter;
- if (nTimerStart == 0)
- nTimerStart = GetTimeMillis();
- else
- nHashCounter++;
+ static CCriticalSection cs;
+ CRITICAL_BLOCK(cs)
+ {
if (GetTimeMillis() - nTimerStart > 4000)
{
- static CCriticalSection cs;
- CRITICAL_BLOCK(cs)
- {
- if (GetTimeMillis() - nTimerStart > 4000)
- {
- double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);
- nTimerStart = GetTimeMillis();
- nHashCounter = 0;
- string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/1000.0);
- UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));
- static int64 nLogTime;
- if (GetTime() - nLogTime > 30 * 60)
- {
- nLogTime = GetTime();
- printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
- printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/1000.0);
- }
- }
- }
+ double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);
+ nTimerStart = GetTimeMillis();
+ nHashCounter = 0;
+ string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/1000.0);
+ UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));
+ static int64 nLogTime;
+ if (GetTime() - nLogTime > 30 * 60)
+ {
+ nLogTime = GetTime();
+ printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
+ printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/1000.0);
+ }
}
-
- // Check for stop or if block needs to be rebuilt
- if (fShutdown)
- return;
- if (!fGenerateBitcoins)
- return;
- if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)
- return;
- if (vNodes.empty())
- break;
- if (tmp.block.nNonce == 0)
- break;
- if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
- break;
- if (pindexPrev != pindexBest)
- break;
-
- pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
- tmp.block.nTime = ByteReverse(pblock->nTime);
+ }
}
+
+ // Check for stop or if block needs to be rebuilt
+ if (fShutdown)
+ return;
+ if (!fGenerateBitcoins)
+ return;
+ if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)
+ return;
+ if (vNodes.empty())
+ break;
+ if (tmp.block.nNonce == 0)
+ break;
+ if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
+ break;
+ if (pindexPrev != pindexBest)
+ break;
+
+ pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
+ tmp.block.nTime = ByteReverse(pblock->nTime);
+ }
}
}
}
diff --git a/makefile.unix b/makefile.unix
index 597a0ea..8fb0aa6 100755
--- a/makefile.unix
+++ b/makefile.unix
@@ -45,7 +45,8 @@ OBJS= \\
obj/rpc.o \\
obj/init.o \\
cryptopp/obj/sha.o \\
- cryptopp/obj/cpu.o
+ cryptopp/obj/cpu.o \\
+
cryptopp/obj/sha256.o
all: bitcoin
@@ -58,18 +59,20 @@ obj/%.o: %.cpp $(HEADERS) headers.h.gch
g++ -c $(CFLAGS) -DGUI -o $@ $<
cryptopp/obj/%.o: cryptopp/%.cpp
-
g++ -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_SSE2 -o $@ $<
+
g++ -c $(CFLAGS) -frename-registers -funroll-all-loops -fomit-frame-pointer -march=native -msse2 -msse3 -ffast-math -O3 -o $@ $<
bitcoin: $(OBJS) obj/ui.o obj/uibase.o
g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)
-
obj/nogui/%.o: %.cpp $(HEADERS)
g++ -c $(CFLAGS) -o $@ $<
bitcoind: $(OBJS:obj/%=obj/nogui/%)
g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(LIBS)
+test: cryptopp/obj/sha.o cryptopp/obj/sha256.o test.cpp
+
g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)
+
clean:
-rm -f obj/*.o
diff --git a/test.cpp b/test.cpp
new file mode 100755
index 0000000..7cab332
--- /dev/null
+++ b/test.cpp
@@ -0,0 +1,237 @@
+// Copyright (c) 2009-2010 Satoshi Nakamoto
+// Distributed under the MIT/X11 software license, see the accompanying
+// file license.txt or http://www.opensource.org/licenses/mit-license.php.
+#include <assert.h>
+#include <openssl/ecdsa.h>
+#include <openssl/evp.h>
+#include <openssl/rand.h>
+#include <openssl/sha.h>
+#include <openssl/ripemd.h>
+#include <db_cxx.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <math.h>
+#include <limits.h>
+#include <float.h>
+#include <assert.h>
+#include <memory>
+#include <iostream>
+#include <sstream>
+#include <string>
+#include <vector>
+#include <list>
+#include <deque>
+#include <map>
+#include <set>
+#include <algorithm>
+#include <numeric>
+#include <boost/foreach.hpp>
+#include <boost/lexical_cast.hpp>
+#include <boost/tuple/tuple.hpp>
+#include <boost/fusion/container/vector.hpp>
+#include <boost/tuple/tuple_comparison.hpp>
+#include <boost/tuple/tuple_io.hpp>
+#include <boost/array.hpp>
+#include <boost/bind.hpp>
+#include <boost/function.hpp>
+#include <boost/filesystem.hpp>
+#include <boost/filesystem/fstream.hpp>
+#include <boost/algorithm/string.hpp>
+#include <boost/interprocess/sync/interprocess_mutex.hpp>
+#include <boost/interprocess/sync/interprocess_recursive_mutex.hpp>
+#include <boost/date_time/gregorian/gregorian_types.hpp>
+#include <boost/date_time/posix_time/posix_time_types.hpp>
+#include <sys/resource.h>
+#include <sys/time.h>
+using namespace std;
+using namespace boost;
+#include \"cryptopp/sha.h\"
+#include \"strlcpy.h\"
+#include \"serialize.h\"
+#include \"uint256.h\"
+#include \"bignum.h\"
+
+#undef printf
+
template <size_t nBytes, typename T>
+T* alignup(T* p)
+{
+
union
+
{
+
T* ptr;
+
size_t n;
+
} u;
+
u.ptr = p;
+
u.n = (u.n + (nBytes-1)) & ~(nBytes-1);
+
return u.ptr;
+}
+
+int FormatHashBlocks(void* pbuffer, unsigned int len)
+{
+
unsigned char* pdata = (unsigned char*)pbuffer;
+
unsigned int blocks = 1 + ((len + 8) / 64);
+
unsigned char* pend = pdata + 64 * blocks;
+
memset(pdata + len, 0, 64 * blocks - len);
+
pdata[len] = 0x80;
+
unsigned int bits = len * 8;
+
pend[-1] = (bits >> 0) & 0xff;
+
pend[-2] = (bits >> 8) & 0xff;
+
pend[-3] = (bits >> 16) & 0xff;
+
pend[-4] = (bits >> 24) & 0xff;
+
return blocks;
+}
+
+using CryptoPP::ByteReverse;
+static int detectlittleendian = 1;
+
+#define NPAR 32
+
+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[8][NPAR], const void *init2);
+
+using CryptoPP::ByteReverse;
+
+static const unsigned int pSHA256InitState[8] = {0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19};
+
+inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)
+{
+
memcpy(pstate, pinit, 32);
+
CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);
+}
+
+void BitcoinTester(char *filename)
+{
+
printf(\"SHA256 test started\n\");
+
+
struct tmpworkspace
+
{
+
struct unnamed2
+
{
+
int nVersion;
+
uint256 hashPrevBlock;
+
uint256 hashMerkleRoot;
+
unsigned int nTime;
+
unsigned int nBits;
+
unsigned int nNonce;
+
}
+
block;
+
unsigned char pchPadding0[64];
+
uint256 hash1;
+
unsigned char pchPadding1[64];
+
};
+
char tmpbuf[sizeof(tmpworkspace)+16];
+
tmpworkspace& tmp = *(tmpworkspace*)alignup<16>(tmpbuf);
+
+
+
char line[180];
+
ifstream fin(filename);
+
char *p;
+
unsigned long int totalhashes= 0;
+
unsigned long int found = 0;
+
clock_t start, end;
+
unsigned long int cpu_time_used;
+
unsigned int tnonce;
+
start = clock();
+
+
while( fin.getline(line, 180))
+
{
+
string in(line);
+
//printf(\"%s\n\", in.c_str());
+
tmp.block.nVersion = strtol(in.substr(0,8).c_str(), &p, 16);
+
tmp.block.hashPrevBlock.SetHex(in.substr(8,64));
+
tmp.block.hashMerkleRoot.SetHex(in.substr(64+8,64));
+
tmp.block.nTime = strtol(in.substr(128+8,8).c_str(), &p, 16);
+
tmp.block.nBits = strtol(in.substr(128+16,8).c_str(), &p, 16);
+
tnonce = strtol(in.substr(128+24,8).c_str(), &p, 16);
+
tmp.block.nNonce = tnonce;
+
+
unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));
+
unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));
+
+
// Byte swap all the input buffer
+
for (int i = 0; i < sizeof(tmp)/4; i++)
+
((unsigned int*)&tmp)[i] = ByteReverse(((unsigned int*)&tmp)[i]);
+
+
// Precalc the first half of the first hash, which stays constant
+
uint256 midstatebuf[2];
+
uint256& midstate = *alignup<16>(midstatebuf);
+
SHA256Transform(&midstate, &tmp.block, pSHA256InitState);
+
+
+
uint256 hashTarget = CBigNum().SetCompact(ByteReverse(tmp.block.nBits)).getuint256();
+
//
printf(\"target %s\n\", hashTarget.GetHex().c_str());
+
uint256 hash;
+
uint256 hashbuf[2];
+
uint256& refhash = *alignup<16>(hashbuf);
+
+
unsigned int thash[8][NPAR];
+
int done = 0;
+
unsigned int i, j;
+
+
/* reference */
+
SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
+
SHA256Transform(&refhash, &tmp.hash1, pSHA256InitState);
+
for (int i = 0; i < sizeof(refhash)/4; i++)
+
((unsigned int*)&refhash)[i] = ByteReverse(((unsigned int*)&refhash)[i]);
+
+
//printf(\"reference nonce %08x:\n%s\n\n\", tnonce, refhash.GetHex().c_str());
+
+
tmp.block.nNonce = ByteReverse(tnonce) & 0xfffff000;
+
+
+
for(;;)
+
{
+
+
Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);
+
+
for(i = 0; i<NPAR; i++) {
+
/* fast hash checking */
+
if(thash[7][i] == 0) {
+
//
printf(\"found something... \");
+
+
for(j = 0; j<8; j++) ((unsigned int *)&hash)[j] = ByteReverse((unsigned int)thash[j][i]);
+
//
printf(\"%s\n\", hash.GetHex().c_str());
+
+
if (hash <= hashTarget)
+
{
+
found++;
+
if(tnonce == ByteReverse(tmp.block.nNonce + i) ) {
+
if(hash == refhash) {
+
printf(\"\r%lu\", found);
+
totalhashes += NPAR;
+
done = 1;
+
} else {
+
printf(\"Hashes do not match!\n\");
+
}
+
} else {
+
printf(\"nonce does not match. %08x != %08x\n\", tnonce, ByteReverse(tmp.block.nNonce + i));
+
}
+
break;
+
}
+
}
+
}
+
if(done) break;
+
+
tmp.block.nNonce+=NPAR;
+
totalhashes += NPAR;
+
if(tmp.block.nNonce == 0) {
+
printf(\"ERROR: Hash not found for:\n%s\n\", in.c_str());
+
return;
+
}
+
}
+
}
+
printf(\"\n\");
+
end = clock();
+
cpu_time_used += (unsigned int)(end - start);
+
cpu_time_used /= ((CLOCKS_PER_SEC)/1000);
+
printf(\"found solutions = %lu\n\", found);
+
printf(\"total hashes = %lu\n\", totalhashes);
+
printf(\"total time = %lu ms\n\", cpu_time_used);
+
printf(\"average speed: %lu khash/s\n\", (totalhashes)/cpu_time_used);
+}
+
+int main(int argc, char* argv[]) {
+
if(argc == 2) {
+
BitcoinTester(argv[1]);
+
} else
+
printf(\"Missing filename!\n\");
+
return 0;
+}
Had to manually patch, as I'm not using git for bitcoin and 'patch' doesn't munch this format, I guess. Anyway, got almost double speed on the OSX side, (i5 2.4, now ~2400 from ~1400), but my linux on Q6600 quad 2.4Ghz was pumping ~2500 with 0.3.6 (from source) and now, with the patch it's... ~2400. Need I tweak anything to take advantage on this?
",
"nested_level": 0
},
{
"id": 1839,
"thread_id": 152,
"source_id": "14",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6850#msg6850",
"date": "2010-07-31T20:34:06Z",
"text": "ahm, let me correct myself: on the quad core linux, I went from ~4400 with svn trunk @ 119 to ~2400 with the patch... not exactly what I hoped for after the success in OSX.
",
"nested_level": 0
},
{
"id": 1840,
"thread_id": 152,
"source_id": "15",
"poster_name": "aceat64",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=430",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6853#msg6853",
"date": "2010-07-31T20:57:49Z",
"text": "ahm, let me correct myself: on the quad core linux, I went from ~4400 with svn trunk @ 119 to ~2400 with the patch... not exactly what I hoped for after the success in OSX.
I noticed the same, I went from about 4300 to 2100 when I tested it on Linux.
What CPUs are you running it on? Could you send me sha256.o (compiled object of the algorithm)?
",
"nested_level": 0
},
{
"id": 1842,
"thread_id": 152,
"source_id": "17",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6866#msg6866",
"date": "2010-07-31T23:18:07Z",
"text": "I'm running on the Intel Q6600 2.4Ghz, how shall I get the file to you?
",
"nested_level": 0
},
{
"id": 1843,
"thread_id": 152,
"source_id": "18",
"poster_name": "Mionione",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=334",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6867#msg6867",
"date": "2010-07-31T23:30:11Z",
"text": "care with __attribute__ ((aligned (16))) , it doesn't work with local variable, gcc doesn't align the stack
",
"nested_level": 0
},
{
"id": 1844,
"thread_id": 152,
"source_id": "19",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6868#msg6868",
"date": "2010-07-31T23:37:02Z",
"text": "I'm running on the Intel Q6600 2.4Ghz, how shall I get the file to you?
yes. i will look at the assembler code. maybe the compiler did something \"wrong\".
Patch against SVN. Maybe it'll work now...
diff --git a/cryptopp/sha256.cpp b/cryptopp/sha256.cpp
new file mode 100644
index 0000000..6735678
--- /dev/null
+++ b/cryptopp/sha256.cpp
@@ -0,0 +1,447 @@
+#include <string.h>
+#include <assert.h>
+
+#include <xmmintrin.h>
+#include <stdint.h>
+#include <stdio.h>
+
+#define NPAR 32
+
+static const unsigned int sha256_consts[] = {
+
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, /* 0 */
+
0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
+
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, /* 8 */
+
0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
+
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, /* 16 */
+
0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
+
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, /* 24 */
+
0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
+
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, /* 32 */
+
0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
+
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, /* 40 */
+
0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
+
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, /* 48 */
+
0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
+
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, /* 56 */
+
0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+};
+
+
+static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {
+
return (b & c) ^ (~b & d);
+}
+
+static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {
+
return (b & c) ^ (b & d) ^ (c & d);
+}
+
+static inline __m128i ROTR(__m128i x, const int n) {
+
return _mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n);
+}
+
+static inline __m128i SHR(__m128i x, const int n) {
+
return _mm_srli_epi32(x, n);
+}
+
+/* SHA256 Functions */
+#define
BIGSIGMA0_256(x)
(ROTR((x), 2) ^ ROTR((x), 13) ^ ROTR((x), 22))
+#define
BIGSIGMA1_256(x)
(ROTR((x), 6) ^ ROTR((x), 11) ^ ROTR((x), 25))
+#define
SIGMA0_256(x)
(ROTR((x), 7) ^ ROTR((x), 18) ^ SHR((x), 3))
+#define
SIGMA1_256(x)
(ROTR((x), 17) ^ ROTR((x), 19) ^ SHR((x), 10))
+
+static inline __m128i load_epi32(const unsigned int x0, const unsigned int x1, const unsigned int x2, const unsigned int x3) {
+
return _mm_set_epi32(x0, x1, x2, x3);
+}
+
+static inline unsigned int store32(const __m128i x, int i) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x;
+
return box.ret[i];
+}
+
+static inline void store_epi32(const __m128i x, unsigned int *x0, unsigned int *x1, unsigned int *x2, unsigned int *x3) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x;
+
*x0 = box.ret[3]; *x1 = box.ret[2]; *x2 = box.ret[1]; *x3 = box.ret[0];
+}
+
+static inline __m128i SHA256_CONST(const int i) {
+
return _mm_set1_epi32(sha256_consts[i]);
+}
+
+#define add4(x0, x1, x2, x3) _mm_add_epi32(_mm_add_epi32(_mm_add_epi32(x0, x1), x2), x3)
+#define add5(x0, x1, x2, x3, x4) _mm_add_epi32(add4(x0, x1, x2, x3), x4)
+
+#define
SHA256ROUND(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+d = _mm_add_epi32(d, T1); \\
+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c)); \\
+h = _mm_add_epi32(T1, T2);
+
+#define
SHA256ROUND_lastd(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+d = _mm_add_epi32(d, T1);
+//T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));
+//h = _mm_add_epi32(T1, T2);
+
+#define
SHA256ROUND_last(a, b, c, d, e, f, g, h, i, w) \\
+
T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w);
\\
+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c)); \\
+h = _mm_add_epi32(T1, T2);
+
+static inline unsigned int swap(unsigned int value) {
+
__asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));
+
return value;
+}
+
+static inline unsigned int SWAP32(const void *addr) {
+
unsigned int value = (*((unsigned int *)(addr)));
+
__asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));
+
return value;
+}
+
+static inline void dumpreg(__m128i x, char *msg) {
+
union { unsigned int ret[4]; __m128i x; } box;
+
box.x = x ;
+
printf(\"%s %08x %08x %08x %08x\n\", msg, box.ret[0], box.ret[1], box.ret[2], box.ret[3]);
+}
+
+#if 1
+#define dumpstate(i) printf(\"%s: %08x %08x %08x %08x %08x %08x %08x %08x %08x\n\", \\
+
__func__, store32(w0, i), store32(a, i), store32(b, i), store32(c, i), store32(d, i), store32(e, i), store32(f, i), store32(g, i), store32(h, i));
+#else
+#define dumpstate()
+#endif
+void Double_BlockSHA256(const void* pin, void* pad, const void *pre, unsigned int thash[9][NPAR], const void *init)
+{
+
unsigned int* In = (unsigned int*)pin;
+
unsigned int* Pad = (unsigned int*)pad;
+
unsigned int* hPre = (unsigned int*)pre;
+
unsigned int* hInit = (unsigned int*)init;
+
unsigned int i, j, k;
+
+
/* vectors used in calculation */
+
__m128i w0, w1, w2, w3, w4, w5, w6, w7;
+
__m128i w8, w9, w10, w11, w12, w13, w14, w15;
+
__m128i T1, T2;
+
__m128i a, b, c, d, e, f, g, h;
+ __m128i nonce;
+
+
/* nonce offset for vector */
+
__m128i offset = load_epi32(0x00000003, 0x00000002, 0x00000001, 0x00000000);
+
+
+
for(k = 0; k<NPAR; k+=4) {
+
w0 = load_epi32(In[0], In[0], In[0], In[0]);
+
w1 = load_epi32(In[1], In[1], In[1], In[1]);
+
w2 = load_epi32(In[2], In[2], In[2], In[2]);
+
//w3 = load_epi32(In[3], In[3], In[3], In[3]); nonce will be later hacked into the hash
+
w4 = load_epi32(In[4], In[4], In[4], In[4]);
+
w5 = load_epi32(In[5], In[5], In[5], In[5]);
+
w6 = load_epi32(In[6], In[6], In[6], In[6]);
+
w7 = load_epi32(In[7], In[7], In[7], In[7]);
+
w8 = load_epi32(In[8], In[8], In[8], In[8]);
+
w9 = load_epi32(In[9], In[9], In[9], In[9]);
+
w10 = load_epi32(In[10], In[10], In[10], In[10]);
+
w11 = load_epi32(In[11], In[11], In[11], In[11]);
+
w12 = load_epi32(In[12], In[12], In[12], In[12]);
+
w13 = load_epi32(In[13], In[13], In[13], In[13]);
+
w14 = load_epi32(In[14], In[14], In[14], In[14]);
+
w15 = load_epi32(In[15], In[15], In[15], In[15]);
+
+
/* hack nonce into lowest byte of w3 */
+
nonce = load_epi32(In[3], In[3], In[3], In[3]);
+
__m128i k_vec = load_epi32(k, k, k, k);
+
nonce = _mm_add_epi32(nonce, offset);
+
nonce = _mm_add_epi32(nonce, k_vec);
+ w3 = nonce;
+
+
a = load_epi32(hPre[0], hPre[0], hPre[0], hPre[0]);
+
b = load_epi32(hPre[1], hPre[1], hPre[1], hPre[1]);
+
c = load_epi32(hPre[2], hPre[2], hPre[2], hPre[2]);
+
d = load_epi32(hPre[3], hPre[3], hPre[3], hPre[3]);
+
e = load_epi32(hPre[4], hPre[4], hPre[4], hPre[4]);
+
f = load_epi32(hPre[5], hPre[5], hPre[5], hPre[5]);
+
g = load_epi32(hPre[6], hPre[6], hPre[6], hPre[6]);
+
h = load_epi32(hPre[7], hPre[7], hPre[7], hPre[7]);
+
+
SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);
+
+#define store_load(x, i, dest) \\
+
w8 = load_epi32((hPre)[i], (hPre)[i], (hPre)[i], (hPre)[i]); \\
+
dest = _mm_add_epi32(w8, x);
+
+
store_load(a, 0, w0);
+
store_load(b, 1, w1);
+
store_load(c, 2, w2);
+
store_load(d, 3, w3);
+
store_load(e, 4, w4);
+
store_load(f, 5, w5);
+
store_load(g, 6, w6);
+
store_load(h, 7, w7);
+
+
w8 = load_epi32(Pad[8], Pad[8], Pad[8], Pad[8]);
+
w9 = load_epi32(Pad[9], Pad[9], Pad[9], Pad[9]);
+
w10 = load_epi32(Pad[10], Pad[10], Pad[10], Pad[10]);
+
w11 = load_epi32(Pad[11], Pad[11], Pad[11], Pad[11]);
+
w12 = load_epi32(Pad[12], Pad[12], Pad[12], Pad[12]);
+
w13 = load_epi32(Pad[13], Pad[13], Pad[13], Pad[13]);
+
w14 = load_epi32(Pad[14], Pad[14], Pad[14], Pad[14]);
+
w15 = load_epi32(Pad[15], Pad[15], Pad[15], Pad[15]);
+
+
a = load_epi32(hInit[0], hInit[0], hInit[0], hInit[0]);
+
b = load_epi32(hInit[1], hInit[1], hInit[1], hInit[1]);
+
c = load_epi32(hInit[2], hInit[2], hInit[2], hInit[2]);
+
d = load_epi32(hInit[3], hInit[3], hInit[3], hInit[3]);
+
e = load_epi32(hInit[4], hInit[4], hInit[4], hInit[4]);
+
f = load_epi32(hInit[5], hInit[5], hInit[5], hInit[5]);
+
g = load_epi32(hInit[6], hInit[6], hInit[6], hInit[6]);
+
h = load_epi32(hInit[7], hInit[7], hInit[7], hInit[7]);
+
+
SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);
+
+
w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);
+
w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);
+
w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);
+
w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);
+
w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);
+
w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);
+
w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);
+
w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);
+
w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);
+
SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);
+
w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);
+
SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);
+
w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);
+
SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);
+
w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);
+
SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);
+
w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);
+
SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);
+
w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);
+
SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);
+
w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);
+
SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);
+
w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);
+
SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);
+
+
/* store resulsts directly in thash */
+#define store_2(x,i) \\
+
w0 = load_epi32((hInit)[i], (hInit)[i], (hInit)[i], (hInit)[i]); \\
+
*(__m128i *)&(thash)[i][0+k] = _mm_add_epi32(w0, x);
+
+
store_2(a, 0);
+
store_2(b, 1);
+
store_2(c, 2);
+
store_2(d, 3);
+
store_2(e, 4);
+
store_2(f, 5);
+
store_2(g, 6);
+
store_2(h, 7);
+
*(__m128i *)&(thash)[8][0+k] = nonce;
+
}
+
+}
diff --git a/main.cpp b/main.cpp
index 0239915..50db1a3 100644
--- a/main.cpp
+++ b/main.cpp
@@ -2555,8 +2555,10 @@ inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)
CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);
}
+// !!!! NPAR must match NPAR in cryptopp/sha256.cpp !!!!
+#define NPAR 32
-
+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[9][NPAR], const void *init2);
void BitcoinMiner()
@@ -2701,108 +2703,128 @@ void BitcoinMiner()
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
uint256 hashbuf[2];
uint256& hash = *alignup<16>(hashbuf);
+
+ // Cache for NPAR hashes
+ unsigned int thash[9][NPAR] __attribute__ ((aligned (16)));
+
+ unsigned int j;
loop
{
- SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
- SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);
+ Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);
- if (((unsigned short*)&hash)[14] == 0)
+ for(j = 0; j<NPAR; j++) {
+ if (thash[7][j] == 0)
{
- // Byte swap the result after preliminary check
- for (int i = 0; i < sizeof(hash)/4; i++)
- ((unsigned int*)&hash)[i] = ByteReverse(((unsigned int*)&hash)[i]);
-
- if (hash <= hashTarget)
+ // Byte swap the result after preliminary check
+ for (int i = 0; i < sizeof(hash)/4; i++)
+ ((unsigned int*)&hash)[i] = ByteReverse((unsigned int)thash[i][j]);
+
+ if (hash <= hashTarget)
+ {
+ // Double_BlocSHA256 might only calculate parts of the hash.
+ // We'll insert the nonce and get the real hash.
+ //pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
+ //hash = pblock->GetHash();
+
+ /* get nonce from hash */
+ pblock->nNonce = ByteReverse((unsigned int)thash[8][j]);
+ assert(hash == pblock->GetHash());
+
+ //// debug print
+ printf(\"BitcoinMiner:\n\");
+ printf(\"proof-of-work found \n hash: %s \ntarget: %s\n\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
+ pblock->print();
+ printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
+ printf(\"generated %s\n\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());
+
+ SetThreadPriority(THREAD_PRIORITY_NORMAL);
+ CRITICAL_BLOCK(cs_main)
{
- pblock->nNonce = ByteReverse(tmp.block.nNonce);
- assert(hash == pblock->GetHash());
-
- //// debug print
- printf(\"BitcoinMiner:\n\");
- printf(\"proof-of-work found \n hash: %s \ntarget: %s\n\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
- pblock->print();
- printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
- printf(\"generated %s\n\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());
-
- SetThreadPriority(THREAD_PRIORITY_NORMAL);
- CRITICAL_BLOCK(cs_main)
- {
- if (pindexPrev == pindexBest)
- {
- // Save key
- if (!AddKey(key))
- return;
- key.MakeNewKey();
-
- // Track how many getdata requests this block gets
- CRITICAL_BLOCK(cs_mapRequestCount)
- mapRequestCount[pblock->GetHash()] = 0;
-
- // Process this block the same as if we had received it from another node
- if (!ProcessBlock(NULL, pblock.release()))
- printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\n\");
- }
+ if (pindexPrev == pindexBest)
+ {
+ // Save key
+ if (!AddKey(key))
+ return;
+ key.MakeNewKey();
+
+ // Track how many getdata requests this block gets
+ CRITICAL_BLOCK(cs_mapRequestCount)
+ mapRequestCount[pblock->GetHash()] = 0;
+
+ // Process this block the same as if we had received it from another node
+ if (!ProcessBlock(NULL, pblock.release()))
+ printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\n\");
+
}
SetThreadPriority(THREAD_PRIORITY_LOWEST);
Sleep(500);
break;
}
- }
+ SetThreadPriority(THREAD_PRIORITY_LOWEST);
- // Update nTime every few seconds
- const unsigned int nMask = 0xffff;
- if ((++tmp.block.nNonce & nMask) == 0)
+ Sleep(500);
+ break;
+ }
+ }
+ }
+
+ // Update nonce
+ tmp.block.nNonce += NPAR;
+
+ // Update nTime every few seconds
+ const unsigned int nMask = 0xffff;
+ if ((tmp.block.nNonce & nMask) == 0)
+ {
+ // Meter hashes/sec
+ static int64 nTimerStart;
+ static int nHashCounter;
+ if (nTimerStart == 0)
+ nTimerStart = GetTimeMillis();
+ else
+ nHashCounter++;
+ if (GetTimeMillis() - nTimerStart > 4000)
{
- // Meter hashes/sec
- static int64 nTimerStart;
- static int nHashCounter;
- if (nTimerStart == 0)
- nTimerStart = GetTimeMillis();
- else
- nHashCounter++;
+ static CCriticalSection cs;
+ CRITICAL_BLOCK(cs)
+ {
if (GetTimeMillis() - nTimerStart > 4000)
{
- static CCriticalSection cs;
- CRITICAL_BLOCK(cs)
- {
- if (GetTimeMillis() - nTimerStart > 4000)
- {
- double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);
- nTimerStart = GetTimeMillis();
- nHashCounter = 0;
- string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/1000.0);
- UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));
- static int64 nLogTime;
- if (GetTime() - nLogTime > 30 * 60)
- {
- nLogTime = GetTime();
- printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
- printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/1000.0);
- }
- }
- }
+ double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);
+ nTimerStart = GetTimeMillis();
+ nHashCounter = 0;
+ string strStatus = strprintf(\" %.0f khash/s\", dHashesPerSec/1000.0);
+ UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));
+ static int64 nLogTime;
+ if (GetTime() - nLogTime > 30 * 60)
+ {
+ nLogTime = GetTime();
+ printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());
+ printf(\"hashmeter %3d CPUs %6.0f khash/s\n\", vnThreadsRunning[3], dHashesPerSec/1000.0);
+ }
}
-
- // Check for stop or if block needs to be rebuilt
- if (fShutdown)
- return;
- if (!fGenerateBitcoins)
- return;
- if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)
- return;
- if (vNodes.empty())
- break;
- if (tmp.block.nNonce == 0)
- break;
- if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
- break;
- if (pindexPrev != pindexBest)
- break;
-
- pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
- tmp.block.nTime = ByteReverse(pblock->nTime);
+ }
}
+
+ // Check for stop or if block needs to be rebuilt
+ if (fShutdown)
+ return;
+ if (!fGenerateBitcoins)
+ return;
+ if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)
+ return;
+ if (vNodes.empty())
+ break;
+ if (tmp.block.nNonce == 0)
+ break;
+ if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
+ break;
+ if (pindexPrev != pindexBest)
+ break;
+
+ pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());
+ tmp.block.nTime = ByteReverse(pblock->nTime);
+ }
}
}
}
diff --git a/makefile.unix b/makefile.unix
index e965287..04dac86 100644
--- a/makefile.unix
+++ b/makefile.unix
@@ -41,7 +41,8 @@ OBJS= \\
obj/rpc.o \\
obj/init.o \\
cryptopp/obj/sha.o \\
- cryptopp/obj/cpu.o
+ cryptopp/obj/cpu.o \\
+ cryptopp/obj/sha256.o
all: bitcoin
@@ -51,7 +52,7 @@ obj/%.o: %.cpp $(HEADERS)
g++ -c $(CFLAGS) -DGUI -o $@ $<
cryptopp/obj/%.o: cryptopp/%.cpp
-
g++ -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_SSE2 -o $@ $<
+
g++ -c $(CFLAGS) -frename-registers -funroll-all-loops -fomit-frame-pointer -march=native -msse2 -msse3 -ffast-math -O3 -o $@ $<
bitcoin: $(OBJS) obj/ui.o obj/uibase.o
g++ $(CFLAGS) -o $@ $^ $(WXLIBS) $(LIBS)
@@ -63,6 +64,9 @@ obj/nogui/%.o: %.cpp $(HEADERS)
bitcoind: $(OBJS:obj/%=obj/nogui/%)
g++ $(CFLAGS) -o $@ $^ $(LIBS)
+test: cryptopp/obj/sha.o cryptopp/obj/sha256.o test.cpp
+
g++ $(CFLAGS) -o $@ $^ $(LIBS)
+
clean:
-rm -f obj/*.o
diff --git a/test.cpp b/test.cpp
new file mode 100644
index 0000000..a55e972
--- /dev/null
+++ b/test.cpp
@@ -0,0 +1,221 @@
+// Copyright (c) 2009-2010 Satoshi Nakamoto
+// Distributed under the MIT/X11 software license, see the accompanying
+// file license.txt or http://www.opensource.org/licenses/mit-license.php.
+#include <assert.h>
+#include <openssl/ecdsa.h>
+#include <openssl/evp.h>
+#include <openssl/rand.h>
+#include <openssl/sha.h>
+#include <openssl/ripemd.h>
+#include <db_cxx.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <math.h>
+#include <limits.h>
+#include <float.h>
+#include <assert.h>
+#include <memory>
+#include <iostream>
+#include <sstream>
+#include <string>
+#include <vector>
+#include <list>
+#include <deque>
+#include <map>
+#include <set>
+#include <algorithm>
+#include <numeric>
+#include <boost/foreach.hpp>
+#include <boost/lexical_cast.hpp>
+#include <boost/tuple/tuple.hpp>
+#include <boost/fusion/container/vector.hpp>
+#include <boost/tuple/tuple_comparison.hpp>
+#include <boost/tuple/tuple_io.hpp>
+#include <boost/array.hpp>
+#include <boost/bind.hpp>
+#include <boost/function.hpp>
+#include <boost/filesystem.hpp>
+#include <boost/filesystem/fstream.hpp>
+#include <boost/algorithm/string.hpp>
+#include <boost/interprocess/sync/interprocess_mutex.hpp>
+#include <boost/interprocess/sync/interprocess_recursive_mutex.hpp>
+#include <boost/date_time/gregorian/gregorian_types.hpp>
+#include <boost/date_time/posix_time/posix_time_types.hpp>
+#include <sys/resource.h>
+#include <sys/time.h>
+using namespace std;
+using namespace boost;
+#include \"cryptopp/sha.h\"
+#include \"strlcpy.h\"
+#include \"serialize.h\"
+#include \"uint256.h\"
+#include \"bignum.h\"
+
+#undef printf
+
+int FormatHashBlocks(void* pbuffer, unsigned int len)
+{
+
unsigned char* pdata = (unsigned char*)pbuffer;
+
unsigned int blocks = 1 + ((len + 8) / 64);
+
unsigned char* pend = pdata + 64 * blocks;
+
memset(pdata + len, 0, 64 * blocks - len);
+
pdata[len] = 0x80;
+
unsigned int bits = len * 8;
+
pend[-1] = (bits >> 0) & 0xff;
+
pend[-2] = (bits >> 8) & 0xff;
+
pend[-3] = (bits >> 16) & 0xff;
+
pend[-4] = (bits >> 24) & 0xff;
+
return blocks;
+}
+
+using CryptoPP::ByteReverse;
+static int detectlittleendian = 1;
+
+#define NPAR 32
+
+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[9][NPAR], const void *init2);
+
+using CryptoPP::ByteReverse;
+
+static const unsigned int pSHA256InitState[8] = {0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19};
+
+inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)
+{
+
memcpy(pstate, pinit, 32);
+
CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);
+}
+
+void BitcoinTester(char *filename)
+{
+
printf(\"SHA256 test started\n\");
+
+
struct tmpworkspace
+
{
+
struct unnamed2
+
{
+
int nVersion;
+
uint256 hashPrevBlock;
+
uint256 hashMerkleRoot;
+
unsigned int nTime;
+
unsigned int nBits;
+
unsigned int nNonce;
+
}
+
block;
+
unsigned char pchPadding0[64];
+
uint256 hash1;
+
unsigned char pchPadding1[64];
+
}
+ tmp __attribute__ ((aligned (16)));
+
+
char line[180];
+
ifstream fin(filename);
+
char *p;
+
unsigned long int totalhashes= 0;
+
unsigned long int found = 0;
+
clock_t start, end;
+
unsigned long int cpu_time_used;
+
unsigned int tnonce;
+
start = clock();
+
+
while( fin.getline(line, 180))
+
{
+
string in(line);
+
//printf(\"%s\n\", in.c_str());
+
tmp.block.nVersion = strtol(in.substr(0,8).c_str(), &p, 16);
+
tmp.block.hashPrevBlock.SetHex(in.substr(8,64));
+
tmp.block.hashMerkleRoot.SetHex(in.substr(64+8,64));
+
tmp.block.nTime = strtol(in.substr(128+8,8).c_str(), &p, 16);
+
tmp.block.nBits = strtol(in.substr(128+16,8).c_str(), &p, 16);
+
tnonce = strtol(in.substr(128+24,8).c_str(), &p, 16);
+
tmp.block.nNonce = tnonce;
+
+
unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));
+
unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));
+
+
// Byte swap all the input buffer
+
for (int i = 0; i < sizeof(tmp)/4; i++)
+
((unsigned int*)&tmp)[i] = ByteReverse(((unsigned int*)&tmp)[i]);
+
+
// Precalc the first half of the first hash, which stays constant
+
uint256 midstate __attribute__ ((aligned(16)));
+
SHA256Transform(&midstate, &tmp.block, pSHA256InitState);
+
+
+
uint256 hashTarget = CBigNum().SetCompact(ByteReverse(tmp.block.nBits)).getuint256();
+
//
printf(\"target %s\n\", hashTarget.GetHex().c_str());
+
uint256 hash;
+
uint256 refhash __attribute__ ((aligned(16)));
+
+
unsigned int thash[9][NPAR] __attribute__ ((aligned (16)));
+
int done = 0;
+
unsigned int i, j;
+
+
/* reference */
+
SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
+
SHA256Transform(&refhash, &tmp.hash1, pSHA256InitState);
+
for (int i = 0; i < sizeof(refhash)/4; i++)
+
((unsigned int*)&refhash)[i] = ByteReverse(((unsigned int*)&refhash)[i]);
+
+
//printf(\"reference nonce %08x:\n%s\n\n\", tnonce, refhash.GetHex().c_str());
+
+
tmp.block.nNonce = ByteReverse(tnonce) & 0xfffff000;
+
+
+
for(;;)
+
{
+
+
Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);
+
+
for(i = 0; i<NPAR; i++) {
+
/* fast hash checking */
+
if(thash[7][i] == 0) {
+
//
printf(\"found something... \");
+
+
for(j = 0; j<8; j++) ((unsigned int *)&hash)[j] = ByteReverse((unsigned int)thash[j][i]);
+
//
printf(\"%s\n\", hash.GetHex().c_str());
+
+
if (hash <= hashTarget)
+
{
+
found++;
+
if(tnonce == ByteReverse((unsigned int)thash[8][i]) ) {
+
if(hash == refhash) {
+
printf(\"\r%lu\", found);
+
totalhashes += NPAR;
+
done = 1;
+
} else {
+
printf(\"Hashes do not match!\n\");
+
}
+
} else {
+
printf(\"nonce does not match. %08x != %08x\n\", tnonce, ByteReverse(tmp.block.nNonce + i));
+
}
+
break;
+
}
+
}
+
}
+
if(done) break;
+
+
tmp.block.nNonce+=NPAR;
+
totalhashes += NPAR;
+
if(tmp.block.nNonce == 0) {
+
printf(\"ERROR: Hash not found for:\n%s\n\", in.c_str());
+
return;
+
}
+
}
+
}
+
printf(\"\n\");
+
end = clock();
+
cpu_time_used += (unsigned int)(end - start);
+
cpu_time_used /= ((CLOCKS_PER_SEC)/1000);
+
printf(\"found solutions = %lu\n\", found);
+
printf(\"total hashes = %lu\n\", totalhashes);
+
printf(\"total time = %lu ms\n\", cpu_time_used);
+
printf(\"average speed: %lu khash/s\n\", (totalhashes)/cpu_time_used);
+}
+
+int main(int argc, char* argv[]) {
+
if(argc == 2) {
+
BitcoinTester(argv[1]);
+
} else
+
printf(\"Missing filename!\n\");
+
return 0;
+}
care with __attribute__ ((aligned (16))) , it doesn't work with local variable, gcc doesn't align the stack
Maybe gcc doesn't align the stack, but it can (and automatically does) align variables on the stack.
No joy against SVN tip here.
patching file sha256.cpp
patching file main.cpp
Hunk #1 FAILED at 2555.
Hunk #2 FAILED at 2703.
2 out of 2 hunks FAILED -- saving rejects to file main.cpp.rej
patching file makefile.unix
Hunk #1 FAILED at 41.
Hunk #2 FAILED at 52.
Hunk #3 FAILED at 64.
3 out of 3 hunks FAILED -- saving rejects to file makefile.unix.rej
patching file test.cpp
Trying manually now.
I got the patch knitted in, and I think I did it correctly.. wasn't complicated.
Regrettably, the hash rate has decreased by almost half. I'm down from 2071 (stock build, svn tip) to 1150 khash/sec with the patch.
It's an Intel Xeon 3 GHz, Linux, with these proc flags:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
Has anyone seen gains?
Did I botch it? Missing CPU capabilities? Wrong compiler options?
I have been able to apply the patch against SVN (r121) and I tested it on 2 machines:
- on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)
- on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)
The strange thing is that despite the fact that I have been running it on 6 Opterons (i.e. 6x4=24 cores) for 40 hours with an average rate of 51,000 khash/s, I still haven't generated any blocks. The probability of this (no blocks, 40 hours, 51,000 khash/s and diffuculty=244.2) is 0.09% or 1/1098. Are you sure this thing works correctly and that the reported rate is correct? How do I run the included test program?
Is it a AMD only optimization perhaps?
",
"nested_level": 0
},
{
"id": 1852,
"thread_id": 152,
"source_id": "27",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6985#msg6985",
"date": "2010-08-02T09:00:55Z",
"text": "Is it a AMD only optimization perhaps?
Or a 64-bit only optimization.
With the patch above, I was unable to build the test program. You?
",
"nested_level": 0
},
{
"id": 1854,
"thread_id": 152,
"source_id": "29",
"poster_name": "petree",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=666",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6987#msg6987",
"date": "2010-08-02T09:22:29Z",
"text": "The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client. I was even able to port its minor changes to 0.3.7 successfully, with the same results.
Is there a way we can confirm that the variables are being aligned properly? I'm wondering if the Intel procs are less tolerant of misalignment than the AMD's.
",
"nested_level": 0
},
{
"id": 1855,
"thread_id": 152,
"source_id": "30",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg6988#msg6988",
"date": "2010-08-02T09:31:44Z",
"text": "With the patch above, I was unable to build the test program. You?
Under x86 I had to include cryptopp/obj/cpu.o in the list of object files, otherwise \"make test\" would fail. Under x86_64 I had no such issue.
The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client. I was even able to port its minor changes to 0.3.7 successfully, with the same results.
As I said above I did notice an imporvement in performace too, but I am not sure the patched version works correctly. Have you been able to generate any blocks with the patched version?
Is it a AMD only optimization perhaps?
Or a 64-bit only optimization.
I'm trying on a Q6600 running 64bit linux (ubuntu server) and it makes things slower there, so not 64bit only. And I'm running on my mac laptop which sports an Intel i5 (also 64 bit OSX 10.6), which great speed improvement there, so not AMD only.
With the patch above, I was unable to build the test program. You?
Under x86 I had to include cryptopp/obj/cpu.o in the list of object files, otherwise \"make test\" would fail. Under x86_64 I had no such issue.
The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client. I was even able to port its minor changes to 0.3.7 successfully, with the same results.
As I said above I did notice an imporvement in performace too, but I am not sure the patched version works correctly. Have you been able to generate any blocks with the patched version?
Yes, since applying this patch I've generated 2 blocks.
Is it 2x fast on AMD and 1/2 fast on Intel?
Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?
Tried that, but it doesn't work for things on the stack. I ran some tests.
It doesn't even cause an error, it just doesn't align it.
FWIW, there exists -mstackrealign and -mpreferred-stack-boundary=NUM
",
"nested_level": 0
},
{
"id": 1860,
"thread_id": 152,
"source_id": "35",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7094#msg7094",
"date": "2010-08-02T20:49:25Z",
"text": "After 52 hours of trying with no blocks generated, I give up and I am switching back to the vanilla bitcoin.
The probability of getting no blocks within 52 hours at 51,000 khash/s is 0.011%. So I conclude that the patch doesn't work and I am 99.989% confident about that. I hope that tcatm provides some explanation on how to use the supplied test program.
",
"nested_level": 0
},
{
"id": 1861,
"thread_id": 152,
"source_id": "36",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7096#msg7096",
"date": "2010-08-02T21:07:56Z",
"text": "To use the test program download this file (or generate it yourself from the blockchain):
http://ul.to/hz5wlgThe program will try to find the correct nonce in each block and detect if the hash function does work correctly. It'll also benchmark the algorithm.
From what I've heard the patch does not work on 32 bit systems. I don't know why. I've developed it on an AMD64 machine and it works fine. If it's slower on Intel, try to disable Hyperthreading. The big loop in the SSE2 code doesn't contain any \"normal\" x86 except for one jump at the end.
Btw, there's a git repo at
http://github.com/tcatm/bitcoin-cruncher/I've tried the git branch and results stay the same, almost half of what the vanilla svn can pump out. I'm running Intel and not AMD, but I am on 64bit:
Linux bah 2.6.32-22-server #33-Ubuntu SMP Wed Apr 28 14:34:48 UTC 2010 x86_64 GNU/Linux
Anything I can try to help and debug this?
",
"nested_level": 0
},
{
"id": 1863,
"thread_id": 152,
"source_id": "38",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7115#msg7115",
"date": "2010-08-03T00:21:41Z",
"text": "I've tried the git branch and results stay the same, almost half of what the vanilla svn can pump out. I'm running Intel and not AMD, but I am on 64bit:
Linux bah 2.6.32-22-server #33-Ubuntu SMP Wed Apr 28 14:34:48 UTC 2010 x86_64 GNU/Linux
Anything I can try to help and debug this?
Can you mail me a copy of cryptopp/obj/sha256.o to
tcatm@gawab.com? I still fear Intels microcode in their CPUs wasn't made for such tight loops of SSE code. Have you run the test program? How many khash/s does it crunch?
datla@bah:~/src/bitcoin/bitcoin-cruncher$ ./test blocks.txt
SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 235480 ms
average speed: 592 khash/s
I'll send you the obj file now
",
"nested_level": 0
},
{
"id": 1865,
"thread_id": 152,
"source_id": "40",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7123#msg7123",
"date": "2010-08-03T01:17:53Z",
"text": "Thanks for the object!
There are two things I noticed:
1) The Intel object runs at 3269khash/s on my AMD64 (vs. 3778khash/s) so it's less optimized than the AMD64 code.
2) AMD64 moves less data around and does more calculations. Sometimes it even abuses floating point instructions for integers.
Could you drop in my sha256.o from
http://ul.to/2ckndx to cryptopp/obj/, delete test (not the .cpp!!) and recompile test using make -f makefile.unix test (take care it doesn't recompile sha256.cpp to sha256.o). Then run test again. It should be using AMD64 code now. Maybe it works better...
If not we've found that AMD64 is about four times faster than Intel at SSE2 integer vector arithmetic. Anyone working on a floating point SHA256 implementation?
SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 222110 ms
average speed: 627 khash/s
So slightly better, but still far for good... As for AMD vs Intel, on my Mac, which is an intel i5, the performance boost was almost 100%, so maybe some compiler thing? I did have to remove the -arch i386 from makefile.osx to have it build on osx 10.6, but there's no such flag on linux' g++ and I'm pretty sure the 64bit g++ will not compile 32bit anyway.
",
"nested_level": 0
},
{
"id": 1867,
"thread_id": 152,
"source_id": "42",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7134#msg7134",
"date": "2010-08-03T02:21:50Z",
"text": "i5 is a different architecture than Core2. Maybe SSE in Core2 is broken and was fixed in i5. That means the original client is close to the fastest you can get on Core2. It's not a compiler thing. I compared the output for different architectures and -march=amdfam10 produces the fastest and smallest code. I would be surprised if a longer loop using the same instructions was faster on an older CPU.
",
"nested_level": 0
},
{
"id": 1868,
"thread_id": 152,
"source_id": "43",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7135#msg7135",
"date": "2010-08-03T02:23:48Z",
"text": "Well, kudos to you for trying. Now if I can just get your code merged with the old cuda version on my macbook pro, I'll be a happy camper
Anyone able to send me a compiled version of this for windows? I'm interested to try it out on my AMD server.
",
"nested_level": 0
},
{
"id": 1870,
"thread_id": 152,
"source_id": "45",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7343#msg7343",
"date": "2010-08-03T21:49:12Z",
"text": "I kept running the patched version on 2 machines and the following has happened 5 times: bitcoind crashes and debug.log contains the following:
proof-of-work found
hash: 00000000001c3530e42b2c7e1a20de01436882d0c1de0b63db6be8e6194255dd
target: 00000000010c5a00000000000000000000000000000000000000000000000000
CBlock(hash=00000000001c3530, ver=1, hashPrevBlock=0000000000253ab5, hashMerkleRoot=89541f, nTime=1280867359, nBits=1c010c5a, nNonce=3915571979, vtx=2)
CTransaction(hash=4fcb8e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(000000, -1), coinbase 045a0c011c021b04)
CTxOut(nValue=50.00000000, scriptPubKey=0xCE5264238BAC29160CDC9C)
CTransaction(hash=8f2466, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(77aaae, 1), scriptSig=0x01F561A9044BF348CEF6F4)
CTxOut(nValue=5.00000000, scriptPubKey=OP_DUP OP_HASH160 0xB13A)
vMerkleTree: 4fcb8e 8f2466 89541f
08/03/10 20:29 generated 50.00
AddToWallet 4fcb8e new
AddToBlockIndex: new best=00000000001c3530 height=72112
ProcessBlock: ACCEPTED
sending: inv
I guess this means that a new block has been generated. But when I restart bitcoind the balance is still zero. When I ask for a list of generated blocks I get the following:
$ ./bitcoind listgenerated
[
{
\"value\" : 50.00000000000000,
\"maturesIn\" : -1,
\"accepted\" : false,
\"confirmations\" : 0,
\"genTime\" : 1280867359
}
]
(listgenerated is from the patch at
http://www.alloscomp.com/bitcoin/)
I guess this means that my client produced a block but it crashed before it was able to broadcast it.
did you run it on 32 bit machines? which version of the patch did you use?
",
"nested_level": 0
},
{
"id": 1872,
"thread_id": 152,
"source_id": "47",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7347#msg7347",
"date": "2010-08-03T21:56:47Z",
"text": "r121 from the svn patched with the patch from the post #21 running on a Opteron/x86_64
",
"nested_level": 0
},
{
"id": 1873,
"thread_id": 152,
"source_id": "48",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7348#msg7348",
"date": "2010-08-03T22:00:35Z",
"text": "did it crash with a segfault and can you provide a backtrace (gdb bitcoind; run; bt)?
",
"nested_level": 0
},
{
"id": 1874,
"thread_id": 152,
"source_id": "49",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7368#msg7368",
"date": "2010-08-03T23:51:28Z",
"text": "I did segfault according to dmesg:
bitcoind[2469]: segfault at 0 ip 00007fe92c5b3f32 sp 00007fff15e5f6b0 error 4 in libc-2.11.2.so[7fe92c57e000+150000]
I don't have a stack trace.
Did your kernel write a coredump and if so can you mail me the binary + coredump to
tcatm@gawab.com?
I modified bitcoind so that it doen't fork to the background and now I can debug it with gdb. Next time it crashes gdb will give me a backtrace.
",
"nested_level": 0
},
{
"id": 1877,
"thread_id": 152,
"source_id": "52",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7421#msg7421",
"date": "2010-08-04T03:00:49Z",
"text": "GDB can also generate coredumps with the command generate-core-file. It might be useful to reconstruct the cause for the segfault. Please note, that the coredump might include your wallet so it's probably a good idea to run bitcoind on a seperate datadir.
",
"nested_level": 0
},
{
"id": 1878,
"thread_id": 152,
"source_id": "53",
"poster_name": "vess",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=621",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7467#msg7467",
"date": "2010-08-04T13:34:44Z",
"text": "Just a comment that this would be easier to test if difficulty were set to '1' in the client.
",
"nested_level": 0
},
{
"id": 1879,
"thread_id": 152,
"source_id": "54",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7470#msg7470",
"date": "2010-08-04T13:43:26Z",
"text": "Oh thats easy: Get two nodes on a seperate network and connect them using -connect=other_nodes_ip and a seperate/empty datadir.
",
"nested_level": 0
},
{
"id": 1880,
"thread_id": 152,
"source_id": "55",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7641#msg7641",
"date": "2010-08-05T06:40:16Z",
"text": "I had 5 machines running today and when I checked back 10 hours later, 4 of them had crashed, in the same way as with the previous times (i.e. right after they had generated a new block but before they broadcasted it).
I created a tarball containing the coredump, backtrace, binary and the sources I used to compile it including the compiled object files. You can get it from
here (link removed). Hope that helps.
EDIT: Ok, I just noticed that both your patch and the patch for the getkhps rpc (from http://www.alloscomp.com/bitcoin/) modify the function BitcoinMiner in main.cpp (which is where the segfault occurs) so this must be the reason for the seqfaults. I will try to test it without the getkhps patch.Ok I tried again, this time with no extra patches. I just cloned your git tree and compiled it. It still crashes. Here's the stack backtrace:
#0 0x00007ffff710b1b5 in raise () from /lib/libc.so.6
#1 0x00007ffff710c5e0 in abort () from /lib/libc.so.6
#2 0x00007ffff71042d1 in __assert_fail () from /lib/libc.so.6
#3 0x00000000004628de in BitcoinMiner () at main.cpp:2741
#4 0x0000000000462d70 in ThreadBitcoinMiner (parg=0x391e) at main.cpp:2518
#5 0x00007ffff6ec3894 in start_thread () from /lib/libpthread.so.0
#6 0x00007ffff71aa07d in clone () from /lib/libc.so.6
I have also uploaded
here (link removed) the sources with the object files as well as the a core dump and the binary.
That's not a real crash this time. It's an assert that fails in the miner. Most likely assert(hash == pblock->GetHash());. Can you run the test programm (explained in
http://bitcointalk.org/index.php?topic=648.msg7096#msg7096)? If it fails, can you change -march=amdfam10 back to -march=native in makefile.unix, rm cryptopp/obj/*.o and recompile everything? What cpu are you running it on?
The test program does not fail
$ ./test ../blocks.txt
SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 63250 ms
average speed: 2204 khash/s
Does the test program run on a single thread?
Finally, I have the same problem with both -march=amdfam10 and -march=native. The cpu is a Opteron 2374.
Yes, test is single threaded. Is there any output on stderr? From the coredumps I can tell that there must be some output.
The problem seems to be hard to debug, though. Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
",
"nested_level": 0
},
{
"id": 1885,
"thread_id": 152,
"source_id": "60",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7796#msg7796",
"date": "2010-08-06T06:50:03Z",
"text": "<snip> Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
When the difficulty changed, the first machine in my group to generate a block was the slowest one running the stock client (800 MHz E-machine) and it hadn't generated anything in over a week itself. So I guess every little bit helps, that's so many are interested in getting this to work on their machine.
Here's the output on stderr:
bitcoind: main.cpp:2741: void BitcoinMiner(): Assertion `(\"break caught by CRITICAL_BLOCK!\", !fcriticalblockonce)' failed.
Oh, that's a part in the code my patch doesn't touch. You could try to remove line 2741 (CRITICAL_BLOCK(cs_main)).
",
"nested_level": 0
},
{
"id": 1888,
"thread_id": 152,
"source_id": "63",
"poster_name": "impossible7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=664",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7838#msg7838",
"date": "2010-08-06T11:37:20Z",
"text": "CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
",
"nested_level": 0
},
{
"id": 1889,
"thread_id": 152,
"source_id": "64",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg7841#msg7841",
"date": "2010-08-06T11:54:04Z",
"text": "Thanks! That got probably mixed up when I patched the file with an older diff. I fixed the git:
http://github.com/tcatm/bitcoin-cruncherCRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.
Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs.
I can confirm that the patch now works just fine. I just generated my first 50 BTC with it. And since this patch doubles the speed I think it's only fair if I donated half of that to tcatm.
",
"nested_level": 0
},
{
"id": 1892,
"thread_id": 152,
"source_id": "67",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8170#msg8170",
"date": "2010-08-07T22:59:55Z",
"text": "I can confirm that the patch now works just fine. I just generated my first 50 BTC with it. And since this patch doubles the speed I think it's only fair if I donated half of that to tcatm.
That's nice to hear. Thanks for the donation and thanks to everyone else who donated!
I just tried again with the latest version from your github. I'm still seeing a drop in performance compared to the vanilla source.
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.
",
"nested_level": 0
},
{
"id": 1894,
"thread_id": 152,
"source_id": "69",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8229#msg8229",
"date": "2010-08-08T11:52:53Z",
"text": "It seems to be like this: everything before Core2 will be slower, everything starting with Core2 is faster. Can anyone test the code on an older AMD64? I know there was a change in the way SSE2 instructions are executed in recent architectures.
",
"nested_level": 0
},
{
"id": 1895,
"thread_id": 152,
"source_id": "70",
"poster_name": "nimnul",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=600",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8875#msg8875",
"date": "2010-08-12T12:18:23Z",
"text": "Can we implement a speed test, so different hashing engines are tried and the fastest is chosen?
",
"nested_level": 0
},
{
"id": 1896,
"thread_id": 152,
"source_id": "71",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8883#msg8883",
"date": "2010-08-12T12:57:58Z",
"text": "It seems to be like this: everything before Core2 will be slower, everything starting with Core2 is faster. Can anyone test the code on an older AMD64? I know there was a change in the way SSE2 instructions are executed in recent architectures.
My Core2Quad (Q6600) slowed down 50%, my i5 improved ~200%, thus I don't think what you state is accurate. Maybe starting at some specific Core2?
That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster.
A quick summary:
Xeon Quad 41% slower
Core 2 Duo 55% slower
Core 2 Duo same (vess)
Core 2 Quad 50% slower
Core i5 200% faster (nelisky)
Core i5 100% faster (vess)
AMD Opteron 105% faster
aceat64:
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.
impossible7:
on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)
nelisky:
My Core2Quad (Q6600) slowed down 50%,
my i5 improved ~200%,
impossible7:
on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)
",
"nested_level": 0
},
{
"id": 1898,
"thread_id": 152,
"source_id": "73",
"poster_name": "vess",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=621",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8930#msg8930",
"date": "2010-08-12T22:09:50Z",
"text": "My core i5 doubled in speed. My Core 2 Duo is the same speed.
",
"nested_level": 0
},
{
"id": 1899,
"thread_id": 152,
"source_id": "74",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg8949#msg8949",
"date": "2010-08-13T00:42:47Z",
"text": "Would be interesting to try it out on older AMD64. There's been a change that would explain it there:
http://developer.amd.com/documentation/articles/pages/682007171.aspxMaybe Intel did something similiar without announcing it?
I'll just pitch in that Phenom and Phenom II processors doubled (roughly).
No difference between the two that I can tell.
Sorry I dont have anything older than Phenoms available right now.
Might be able to access a old X2 in a week.
",
"nested_level": 0
},
{
"id": 1901,
"thread_id": 152,
"source_id": "76",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg9105#msg9105",
"date": "2010-08-13T21:10:33Z",
"text": "Just a question for whoever, trying to wrap up the information in this thread.
Does this:
- 1. Work on 32-bit?
- 2. Patch the SVN (r130 as of current) or Git?
- 3. Compile on CentOS?
If anyone has any answers I would greatly appreciate them.
1. Does not work on 32-bit (though that's not a problem with the algorithm).
2. Patch is against older SVN. There's a git repo at
http://github.com/tcatm/bitcoin-cruncher3. Compiles on every 64bit Linux.
It's not intended as a replacement for a standard client but for a dedicated bitcoinminer box. I'm planning a pluggable bitcoinminer someday. But at current difficulty it's easier to work for bitcoins than finding faster ways for mining.
I would really like to have this feature included in an official build sometimes soon along with an internal speed test to determine which algorithm to use. You can always remove the speed test later once you figure out how to determine whether it will be faster or slower without running the speed test.
",
"nested_level": 0
},
{
"id": 1904,
"thread_id": 152,
"source_id": "79",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg9128#msg9128",
"date": "2010-08-13T23:17:51Z",
"text": "1. Does not work on 32-bit (though that's not a problem with the algorithm).
2. Patch is against older SVN. There's a git repo at
http://github.com/tcatm/bitcoin-cruncher3. Compiles on every 64bit Linux.
It's not intended as a replacement for a standard client but for a dedicated bitcoinminer box. I'm planning a pluggable bitcoinminer someday. But at current difficulty it's easier to work for bitcoins than finding faster ways for mining.
1. Do we know why it doesn't work on 32bit? Is is it because it's using 128bits and if so, would it help if we dropped it to 64?
2. Thank you, I will look into implementing it on my 64bit systems.
3. Excellent to hear. I'm looking forward to using it.
I was planning on using it on a PE2650 dual proc Xeon @3.2GHz w/HT. I would really like to get this figured out to utilize that system. I am planning one as well. At current difficulty I would agree, except when the system needs to be run anyway and latency isn't an issue.
MinGW on Windows has trouble compiling it:
g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I\"/boost\" -I\"/db/build_unix\" -I\"/openssl/include\" -I\"/wxwidgets/lib/gcc_lib/mswud\" -I\"/wxwidgets/include\" -msse2 -O3 -o obj/sha256.o sha256.cpp
sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)':
sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make: *** [obj/sha256.o] Error 1
",
"nested_level": 0
},
{
"id": 1906,
"thread_id": 152,
"source_id": "81",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg9146#msg9146",
"date": "2010-08-14T00:50:28Z",
"text": "1. Do we know why it doesn't work on 32bit? Is is it because it's using 128bits and if so, would it help if we dropped it to 64?
No idea, maybe some alignment problem. Someone was trying to figure it out on IRC. I don't have a SSE2 capable 32bit system. The additional registers in 64bit mode are also useful. I don't know if your PE2650 has a recent enough CPU. You might experience a performance drop of 50% if the CPU is too old.
Btw, did anyone with Intel CPU compare performance with Hyperthreading enabled/disabled? The SSE2 loop keeps the arithmetic units and pipelines pretty busy and I can imagine Hyperthreading might decrease performance.
MinGW on Windows has trouble compiling it:
g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I\"/boost\" -I\"/db/build_unix\" -I\"/openssl/include\" -I\"/wxwidgets/lib/gcc_lib/mswud\" -I\"/wxwidgets/include\" -msse2 -O3 -o obj/sha256.o sha256.cpp
sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)':
sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make: *** [obj/sha256.o] Error 1
Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?
If you haven't already, try aligning thash. It might matter. Couldn't hurt.
Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?
No help from -O0, same error.
MinGW is GCC 3.4.5. Probably the problem.
I'll see if I can get a newer version of MinGW.
Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than stock with Core 2.
",
"nested_level": 0
},
{
"id": 1910,
"satoshi_id": 361,
"thread_id": 152,
"source_id": "85",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg9278#msg9278",
"date": "2010-08-14T22:06:13Z",
"text": "MinGW GCC 4.5.0:
Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns
I only got 4-way working with test.cpp but not when called by BitcoinMiner
MinGW GCC 4.4.1:
Crypto++ works
4-way SIGSEGV
GCC is definitely not aligning __m128i.
Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.
By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only:
#define Ch(b, c, d) ((b & c) ^ (~b & d))
#define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d))
#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n))
#define SHR(x, n) _mm_srli_epi32(x, n)
But that's with -O0.
",
"nested_level": 0
},
{
"id": 1911,
"thread_id": 152,
"source_id": "86",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: 4 hashes parallel on SSE2 CPUs for 0.3.6",
"url": "https://bitcointalk.org/index.php?topic=648.msg9353#msg9353",
"date": "2010-08-15T03:19:31Z",
"text": "Well, reporting back.
I got it to compile by specifying -msse and -msse2 to gcc when compiling. I first was hashing about 692kh/s (50% of SVN r130[1400kh/s]) but recompiled and am now receiving about ~1120kh/s. This is currently the equivalent of using both of my CPUs without HyperThreading, though I can verify that it IS using HyperThreading. With HyperThreading turned off, I get ~1350kh/s. Pretty close to the stock build.
Also, does the git contain the patched and updated code?
// SVN r130 Using HT.
08/14/10 19:02 hashmeter 4 CPUs 1392 khash/s
08/14/10 19:32 hashmeter 4 CPUs 1387 khash/s
08/14/10 20:02 hashmeter 4 CPUs 1386 khash/s
08/14/10 20:32 hashmeter 4 CPUs 1380 khash/s
08/14/10 21:02 hashmeter 4 CPUs 1363 khash/s
// With -msse -msse2, first run. Using HT.
08/14/10 21:32 hashmeter 4 CPUs 692 khash/s
08/14/10 22:06 hashmeter 4 CPUs 1011 khash/s
08/14/10 22:11 hashmeter 4 CPUs 1104 khash/s
08/14/10 22:16 hashmeter 4 CPUs 1120 khash/s
// NOT using HT.
08/14/10 22:21 hashmeter 2 CPUs 1359 khash/s
08/14/10 22:26 hashmeter 2 CPUs 1340 khash/s
Just wanted to tell my story and help with whatever information I could.
On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.
I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.
I found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that:
--- \\old\\sha.cpp Mon Jul 26 13:31:11 2010
+++ \new\\sha.cpp Sat Aug 14 20:21:08 2010
@@ -336,7 +336,7 @@
ROUND(14, 0, eax, ecx, edi, edx)
ROUND(15, 0, ecx, eax, edx, edi)
- ASL(1)
+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5
AS2(add WORD_REG(si), 4*16)
ROUND(0, 1, eax, ecx, edi, edx)
ROUND(1, 1, ecx, eax, edx, edi)
@@ -355,7 +355,7 @@
ROUND(14, 1, eax, ecx, edi, edx)
ROUND(15, 1, ecx, eax, edx, edi)
AS2( cmp WORD_REG(si), K_END)
- ASJ( jne, 1, b)
+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5
AS2( mov WORD_REG(dx), DATA_SAVE)
AS2( add WORD_REG(dx), 64)
It would be neat if someone had a page (like that handy calculator at
http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next difficulty adjustment will be.
projected difficulty adjustment multiplier =
blocks_since_last_adjustment / 2016
------------------------------------
time_since_last_adjustment / 14_days
For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:
(1008/2016) / (3.5/14) = 0.5/0.25 = 2.0
Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.
from
http://en.wikipedia.org/wiki/Bitcoin\"This page has been deleted. The deletion and move log for the page are provided below for reference.
10:42, 30 July 2010 Polargeo (talk | contribs) deleted \"Bitcoin\" \u200e (Wikipedia:Articles for deletion/Bitcoin)\"
from
http://en.wikipedia.org/wiki/Bitcoin\"This page has been deleted. The deletion and move log for the page are provided below for reference.
10:42, 30 July 2010 Polargeo (talk | contribs) deleted \"Bitcoin\" \u200e (Wikipedia:Articles for deletion/Bitcoin)\"
Boohoo. They don't like us. Big deal.
Wiki-who? Never heard of it!
Is it some sort of ukulele band?
",
"nested_level": 0
},
{
"id": 1917,
"thread_id": 154,
"source_id": "4",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg6775#msg6775",
"date": "2010-07-31T04:35:24Z",
"text": "It is ironic that wikipedia itself isnt accepted as a reliable source when you quote from it in an argument.
Apparently you are only notable if a celebrity mentions you.
I didn't suggest reading
ae's Wikipedia page
And I definitely didn't link to it.
I didn't suggest reading
ae's Wikipedia page
And I definitely didn't link to it.
I definitely didnt read it
I've started the undelete request here:
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_undeletion#BitcoinIf anyone wants to participate, just edit my undelete request and add more reasons why you think it wasn't fair to delete the article.
What is funny to me, is all the other pages on there asking for undeletion... are garage bands, wanna be \"upcoming actors\", and start up companies trying to advertise...
Without in depth examination, it appears we are the only such type of article that has been deleted asking for reinstatement. Someone must have really been PMSy to request the deletion in the first place.
The admin who deleted the article is an expert on glaciers .
Does this make him an ice-hole?
The admin who deleted the article is an expert on glaciers .
That would explain why he's got the time to admin for wikipedia.
The admin who deleted the article is an expert on glaciers .
That would explain why he's got the time to admin for wikipedia.
I cant believe bitcoin got hit by an ice berg.
Instead of wasting with them (they do frustrate me sometimes), why not create a new article at a more \"friendly\" place like
http://en.citizendium.org/wiki/Welcome_to_CitizendiumCitizendium is a wiki that seems to be a compromise between the free-for-all that is Wikipedia and the strict supervision that accompanies Scholarpedia. One of Wikipedia's founders, Larry Sanger, created Citizendium in the hopes of improving on Wikipedia's model. With what the site refers to as \"gentle oversight\", all articles are subject to approval by the site's editorial team. Articles that haven't been approved will have an accompanying disclaimer, which helps to prevent people from taking potentially false information to heart. Also, you must register under your real name to become a contributor, unlike Wikipedia. Although the site is still in beta form, it is quickly becoming a popular alternative to Wikipedia.
Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,
that is for a long time. Wikipedia represent collective and often inconsistent point of view
of a small (compared to society) group of people.
\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.
I believe, it is some form of sexual perversion, wikipedism or like that...
Just find another wikipedia editor and he will play instead of you.
Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,
that is for a long time. Wikipedia represent collective and often inconsistent point of view
of a small (compared to society) group of people.
\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.
I believe, it is some form of sexual perversion, wikipedism or like that...
Just find another wikipedia editor and he will play instead of you.
There is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.
Similarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed.
Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,
that is for a long time. Wikipedia represent collective and often inconsistent point of view
of a small (compared to society) group of people.
\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.
I believe, it is some form of sexual perversion, wikipedism or like that...
Just find another wikipedia editor and he will play instead of you.
There is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.
Similarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed.
When they moved to that model the outcome was inevitable.... personal empire building. If it continues to a point where it destroys the product, something else will rise to challenge it, as long as they don't use the gov't to enforce their 'right' to be the arbitrators of 'editorial standards.'
Ta,
Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,
that is for a long time. Wikipedia represent collective and often inconsistent point of view
of a small (compared to society) group of people.
\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.
I believe, it is some form of sexual perversion, wikipedism or like that...
Just find another wikipedia editor and he will play instead of you.
There is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.
Similarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed.
Agree.
I just count politicking itself as some form of sexual perversion, or like that...
Anyway, contacting wikipedia editor, who is external to this situation, will help a lot.
Wanted to add another reference here that I found via
http://scholar.google.com/ http://yuumei.co.uk/files/dissertation.pdf. It is a paper Titled \"The Impact of Decentralization on Networked Computer Games\" Written by Ashley Vaughan Smith of School of Computing, University of Derby. The paper mentions bitcoins as a good currency for online games. It is only about a paragraph but, I think a research paper for a University would count as an independent 3rd party and may be more of what Wikipedia would like to see.
Wanted to add another reference here that I found via
http://scholar.google.com/ http://yuumei.co.uk/files/dissertation.pdf. It is a paper Titled \"The Impact of Decentralization on Networked Computer Games\" Written by Ashley Vaughan Smith of School of Computing, University of Derby. The paper mentions bitcoins as a good currency for online games. It is only about a paragraph but, I think a research paper for a University would count as an independent 3rd party and may be more of what Wikipedia would like to see.
Not that anyone looks through my rambling lists.
Somebody (possibly knightmb?) should request
Userfication of the deleted article, to preserve the content.
Somebody (possibly knightmb?) should request
Userfication of the deleted article, to preserve the content.
I just saw that myself, I haven't had time to dig through all the links to see what the process is since the Administrators don't have a direct \"contact me\" button anywhere.
the deleter's stats:
Pages deleted 839
Pages restored 1
",
"nested_level": 0
},
{
"id": 1935,
"thread_id": 154,
"source_id": "22",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg7721#msg7721",
"date": "2010-08-05T18:52:35Z",
"text": "It should be pointed out that \"User:Message_From_Xenu/Bitcoin\" currently has the full edit history of the previous Bitcoin article, and IMHO should be what gets \"moved back\" if there is some substantial improvement in the article that might pass muster if another AfD were to be offered again.
Rather than fighting the tide of those supporting the deletion of this article, finding those 3rd party references would be a much better act to perform and then restore the article when an act of deletion would seem over the top. If the community wants to continue to refine the article, that is a good place to start.
",
"nested_level": 0
},
{
"id": 1936,
"thread_id": 154,
"source_id": "23",
"poster_name": "mpkomara",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=293",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg9000#msg9000",
"date": "2010-08-13T13:12:40Z",
"text": "Should we try submitting bitcoin wikipedia articles in several different languages?
",
"nested_level": 0
},
{
"id": 1937,
"thread_id": 154,
"source_id": "24",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg9003#msg9003",
"date": "2010-08-13T13:41:41Z",
"text": "I don't think it's worth sweating over the Wikipedia deletion.
Just leave it a month or two until there is some good third-party coverage then try again. The article should stick then.
",
"nested_level": 0
},
{
"id": 1938,
"thread_id": 154,
"source_id": "25",
"poster_name": "mpkomara",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=293",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg9010#msg9010",
"date": "2010-08-13T13:57:04Z",
"text": "We could let the community decide the importance of a wikipedia article by offering a bounty for the article to be undeleted in English. You might even consider bribing the original deletist with bitcoins. He would either a) refuse it b) accept it on the basis that third party coverage had reached sufficient wikipedia standards or c) accept it controversially which would create publicity for bitcoin. I would offer 500 bitcoins towards that end.
",
"nested_level": 0
},
{
"id": 1939,
"thread_id": 154,
"source_id": "26",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg9020#msg9020",
"date": "2010-08-13T14:52:04Z",
"text": "I think you might find that offering a bribe would be the surest way to prevent the article from being re-included.
",
"nested_level": 0
},
{
"id": 1940,
"thread_id": 154,
"source_id": "27",
"poster_name": "mpkomara",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=293",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg14623#msg14623",
"date": "2010-09-29T21:10:43Z",
"text": "reviving this post. anyone want to try creating the article in Russian? \u041f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u0441\u0442\u0430\u0442\u044c\u044e. or maybe that catalan speaker is around and he can start an article. wikipedia articles are key to credibility, so i'm not letting this go. and where are the french? the swiss? the germans? let's go, people.
",
"nested_level": 0
},
{
"id": 1941,
"thread_id": 154,
"source_id": "28",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg14716#msg14716",
"date": "2010-09-30T16:45:26Z",
"text": "Can we just make different language versions of a deleted page without getting them removed? Let's do it if we can. I can write a version in Finnish.
",
"nested_level": 0
},
{
"id": 1942,
"satoshi_id": 467,
"thread_id": 154,
"source_id": "29",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: BitCoin Wikipedia page DELETED!!!",
"url": "https://bitcointalk.org/index.php?topic=652.msg14729#msg14729",
"date": "2010-09-30T17:50:32Z",
"text": "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 enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.
The article could be as simple as something like:
\"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/.\"
The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.
",
"nested_level": 0
},
{
"id": 1943,
"thread_id": 155,
"source_id": "1",
"poster_name": "generica",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=154",
"subject": "Linux version => No GUI after upgrade. WTF?",
"url": "https://bitcointalk.org/index.php?topic=655.msg6839#msg6839",
"date": "2010-07-31T19:06:37Z",
"text": "Hey guys,
My linux machine (debian 5 stable, 32 bit) was running bitcoin 0.20 for months now. I upgraded it to 0.36 today and the GUI won't appear, however bitcoin is running and seems to use the CPU. Where is the GUI? It won't appear, but there are no errors in the console when I run bitcoin from xterm.
",
"nested_level": 0
},
{
"id": 1944,
"satoshi_id": 305,
"thread_id": 155,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Linux version => No GUI after upgrade. WTF?",
"url": "https://bitcointalk.org/index.php?topic=655.msg7057#msg7057",
"date": "2010-08-02T17:39:27Z",
"text": "Did it print anything to the console? Are you sure you didn't run \"bitcoind\"?
Try version 0.3.7.
",
"nested_level": 0
},
{
"id": 1945,
"thread_id": 156,
"source_id": "1",
"poster_name": "ArrowJ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=605",
"subject": "Mac Client Problems Outlined...",
"url": "https://bitcointalk.org/index.php?topic=660.msg6875#msg6875",
"date": "2010-08-01T01:52:47Z",
"text": "Hardware
MacBook Pro 2.4 GHz Intel Core 2 Duo (Model 4,1)
2 GB 667 MHz DDR2 SDRAM
Software
Mac OS X 10.6.4 Snow Leopard
Bitcoin 0.3.7 (according to Bitcoin >> About)
Problems
Preferences: the preferences I have tried all have zero effect as far as I can tell. \"Minimize to the tray instead of the taskbar\" & \"Minimize to the tray on close\" do nothing (including effecting the cpu usage...see below). Start Bitcoin on system startup is grayed out although I have added it manually to my login items. I have not tried \"Limit coin generation to 'x' processors\" or \"Connect through socks4 proxy:\", but I can only guess that these options are not working either.
CPU Usage: when generating coins top shows Bitcoin at ~187% CPU...this seems extreme? A friend just explained what a \"nice process\" is. Sorry.
Crash On Close: about ever other time I attempt to close Bitcoin using Bitcoin >> Quit the app crashes rather than closing like a friendly app should.
Coin Generation: frankly I am trusting that this is NOT a bug, but just bad luck. I have been running the app for a few weeks now with zero generation. Again, I assume this is bad luck, but considering the other problems I wanted to mention it in case others were noticing this that were using my setup as well.
-----------
If there are any known solution to these problems or if there is anything I can do to help sort them out please let me know. Thanks!
",
"nested_level": 0
},
{
"id": 1946,
"thread_id": 156,
"source_id": "2",
"poster_name": "andrew",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=547",
"subject": "Re: Mac Client Problems Outlined...",
"url": "https://bitcointalk.org/index.php?topic=660.msg6956#msg6956",
"date": "2010-08-02T02:33:38Z",
"text": "The first 5 minutes I used bitcoin about a three weeks ago I generated a block straight away and haven't generated another since. I think it's purely based on luck. Using the OSX client here.
",
"nested_level": 0
},
{
"id": 1947,
"satoshi_id": 306,
"thread_id": 156,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Mac Client Problems Outlined...",
"url": "https://bitcointalk.org/index.php?topic=660.msg7068#msg7068",
"date": "2010-08-02T18:02:20Z",
"text": "\"Minimize to the tray instead of the taskbar\" & \"Minimize to the tray on close\" must not be implemented yet on the Mac. We should grey them out in the next version.
",
"nested_level": 0
},
{
"id": 1948,
"thread_id": 157,
"source_id": "1",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg6895#msg6895",
"date": "2010-08-01T11:07:24Z",
"text": "Suppose that BitCoins are being widely used all across the globe. Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network. Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network. Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.
Now after several years existing independently, what happens when the two networks are reconnected?
",
"nested_level": 0
},
{
"id": 1949,
"thread_id": 157,
"source_id": "2",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg6961#msg6961",
"date": "2010-08-02T03:05:47Z",
"text": "Suppose that BitCoins are being widely used all across the globe. Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network. Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network. Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.
Now after several years existing independently, what happens when the two networks are reconnected?
If the US and China go to war you will have more things to worry about than bitcoins.
Now after several years existing independently, what happens when the two networks are reconnected?
Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).
Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).
For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.
Question: who can be that entity, whitepaper says there is not any central authority, at all ?
kiba what you say, that's impossible or whitepaper lies?
If the US and China go to war you will have more things to worry about than bitcoins.
Is it typical to ignore real threats here, by the way?
Now after several years existing independently, what happens when the two networks are reconnected?
Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).
For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.
Question: who can be that entity, whitepaper says there is not any central authority, at all ?
kiba what you say, that's impossible or whitepaper lies?
It does not require an entity to know what happen if the design of the bitcoin network didn't anticipated this kind of event. If it does happen anyway, than it may or may not be intended to deal with it.
Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).
For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.
Question: who can be that entity, whitepaper says there is not any central authority, at all ?
kiba what you say, that's impossible or whitepaper lies?
Thanks for addressing my concern! I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly). It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist. I suppose each bitcoin community would properly fork the source code to do something along this line.
If the US and China go to war you will have more things to worry about than bitcoins.
I don't know...I actually think that BitCoin would become popular as a resistance currency in wartime. The State likes to enact all sorts of totalitarian BS during war, such as
massive government spending,
massive inflation,
collection of all scap or private metal,
confiscation of private property. Even FDR in the economic emergency during 1933
outlawed private ownership of gold. But bit coin would be resistant to such measures, as long as the government doesn't
shut down the internet, which I doubt they would do since it would seriously cripple the economy and thereby destroy the tax base (although, I forgot how stupid can be sometimes), or somehow outlaw cryptography by regular folk, institute a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..
Thanks for addressing my concern! I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly). It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist. I suppose each bitcoin community would properly fork the source code to do something along this line.
It would seem to me it still warrant a bitcoin exchange market.
I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them. At the very least you enable \"division of labor\" and allow the \"little guys\" to keep up with the data rates required under heavy transaction loads. Failure to provide some means of breaking the chain and then transferring coins back and forth between chains at full value means that eventually only big players with low-latency high bandwidth connections will be able to handle the transaction volume.
",
"nested_level": 0
},
{
"id": 1956,
"thread_id": 157,
"source_id": "9",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg7051#msg7051",
"date": "2010-08-02T17:17:31Z",
"text": "It is possible to run an experiment just to see what happens. It would take 4 separate clients though running at the same time (probably help to have 4 different PC to do this)
Basically, take a fresh install of 2 PC, have them only connect to each other and let them generate blocks starting at 1, build up some coin, transfer between the two in a few transactions, then shut them down. Do the same thing on 2 different PC, build some coin for longer (more blocks), transfer some coin around, shut them down. Then fire up all 4 at the same time and have all 4 connected to each other and see what happens when one pair had a longer block chain than another.
My guess is the longer block chain will win and the lesser of the pair would lose all of their history/coins.
So if this was on a much larger scale (east vs. west), then whoever had the longest block chain would win once the networks started to merge back together.
Thinking about that thought experiment, one could run their own internal micro-payment system for fun
I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them.
Double that.
Triple that.
That is not possible by current design.
But network splits are inevitable future.
Not every merchant will agree to lose his money due to a
network split, which may sound
really abstract to him.
Those who will still agree will demand a means of determining, whether a network split is
in effect now, to limit their possible loses.
Is it at all possible to monitor Bitcoin for network splits?
Is it at all possible to monitor Bitcoin for network splits?
Not easily because it would entail finding out what \"blocks\" everyone else has. Since everyone is working off the current chain, if you did find a client with \"another\" chain, it would either be silly short or hacker longer.
I'm running an experiment to give everyone a more definitive answer.
I have two fresh PC each running the BitCoin client (new install, no blocks, transactions, etc) and they are only network to each other. I'm having them generate coin against each other.
I think that if such a large network split did happen, it would be from the client standpoint (basically someone would compile a client that uses a different bootstrap method, so in essence you would have a \"new\" bitcoin chain that would forever be separate from everyone else).
",
"nested_level": 0
},
{
"id": 1960,
"thread_id": 157,
"source_id": "13",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg7071#msg7071",
"date": "2010-08-02T18:07:08Z",
"text": "Is it at all possible to monitor Bitcoin for network splits?
Not easily because it would entail finding out what \"blocks\" everyone else has. Since everyone is working off the current chain, if you did find a client with \"another\" chain, it would either be silly short or hacker longer.
I, as a merchant, will only care about whether
my network is a
majority network,
so after a reconnect my transactions will be accepted.
So it will be enough for me to be able to monitor the current number of distinct nodes.
Put that into a graph and stop processing transactions if that number suddenly halves.
It may be a service on a web-server running a Bitcoin node.
But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.
But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.
Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)
As of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.
But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.
Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)
As of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.
But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.
This is a task of counting distinct nodes in a graph. Too bad.
But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.
This is a task of counting distinct nodes in a graph. Too bad.
The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading \"generic\" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.
But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.
This is a task of counting distinct nodes in a graph. Too bad.
The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading \"generic\" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.
Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have
too much connections, so the actual number of active nodes may be larger.
Or how should I understand the connection limit? Is it only an outgoing connection limit?
By the way, I myself run two nodes on public addresses and two other behind a firewall.
The last two are only allowed to connect to first two, and not not the Internet.
AFAIK, it counts as being connected to the network, so they generate blocks.
Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have
too much connections, so the actual number of active nodes may be larger.
Or how should I understand the connection limit? Is it only an outgoing connection limit?
By the way, I myself run two nodes on public addresses and two other behind a firewall.
The last two are only allowed to connect to first two, and not not the Internet.
AFAIK, it counts as being connected to the network, so they generate blocks.
Exactly why a good count would be difficult as it currently is setup. I could have hundreds of clients behind a node and the outside world (Internet) would never know from what I know about how everything works.
I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.
Also I was thinking that if country A goes to war with country B both countries will still most likely maintain a connection to country C, D, E, and F which can maintain the network and prevent a split. If country A blocks all internet access and country B does not then Country A looses because, Country B still connects to C,D,E, and F; Therefor country A's block chain will be shorter. If Country A and B both block internet all together they both loose because C,D,E, and F have the longer block chain. IF A, B, C go to war with D,E,F and they block access to each other on the internet then we have two bit markets now.
I agree that if the world goes to hell in a hand basket a network split would be the least of our worries and it is probable that a split would not likely be due to war. I would think a network split is more likely to be caused by a country with an over zealous government repressing their own citizens via their national firewall. Another possibility would be a mass technical problem such as the rapid undersea cable cuts in 2008 (see
Here or
here) that cause some countries internet connection to slow to a crawl. The worst case scenario I can think of is that a large number of under sea cables or other link failures segment a large chunk of the worlds computer. The nodes outside the segment keep going like nothing happened and the same is true for the nodes in the segment. At some point we have the networks links fixed (would probably less then a week or so for another link to be established be it other land links come online or satellite links take over more bandwidth and a month at most for a more permanent fix.) I would guess that the network with the larger chunk of nodes would win out and the smaller segment would loose. The biggest problem would be that in this type of split there is not much time to try and work out a solution. Though it could be possible that in this situation if there were a super node or two in the segmented group it could still be able to make a connection to other super nodes and keep a split to a minimum.
I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.
I can already tell you, it has almost no impact on the CPU, it will shave off some khash/s, but the big difference is bandwidth and memory.
When running the program by itself (8 connection limit), you'll use between 16 and 28 MB of RAM for the program, 300MB a month for bandwidth (24/7 operation basically)
When you run *nearly* unlimited connections, the memory usage jumps up to about 128MB of RAM, bandwidth usage also jumps way up as well to where you are using 100MB in a day instead of a month.
Truthfully though, for a \"super node\" as you've now coined it
it's not really that hard spec wise for any server to handle, my old celeron server could easily handle this kind of load if it was shaved down to just a few thousand connections.
I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating.
This is interesting to me. What is most robust?
1000 nodes all with 9 connections
1000 nodes with 8 connections and one with 1000 connections
1000 nodes with 8 connections and ten with 100 connections
If you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.
Another thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments).
I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating.
This is interesting to me. What is most robust?
1000 nodes all with 9 connections
1000 nodes with 8 connections and one with 1000 connections
1000 nodes with 8 connections and ten with 100 connections
If you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.
Another thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments).
I would say everyone connected to everyone (first option) because the one big node that has 1,000 other clients connected through it is great for redundancy, but also gives a good central point of attack. It's easier to attack a single node than to try and attack them all.
Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).
For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.
Question: who can be that entity, whitepaper says there is not any central authority, at all ?
kiba what you say, that's impossible or whitepaper lies?
Thanks for addressing my concern! I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly). It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist. I suppose each bitcoin community would properly fork the source code to do something along this line.
If the US and China go to war you will have more things to worry about than bitcoins.
I don't know...I actually think that BitCoin would become popular as a resistance currency in wartime. The State likes to enact all sorts of totalitarian BS during war, such as
massive government spending,
massive inflation,
collection of all scap or private metal,
confiscation of private property. Even FDR in the economic emergency during 1933
outlawed private ownership of gold. But bit coin would be resistant to such measures, as long as the government doesn't
shut down the internet, which I doubt they would do since it would seriously cripple the economy and thereby destroy the tax base (although, I forgot how stupid can be sometimes), or somehow outlaw cryptography by regular folk, institute a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..
a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..
They can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are
I have a definitive answer for you all.
I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.
So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.
",
"nested_level": 0
},
{
"id": 1972,
"thread_id": 157,
"source_id": "25",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg7153#msg7153",
"date": "2010-08-03T04:59:32Z",
"text": "I have a definitive answer for you all.
Woot! Real facts! Nice!
Cool time machine thread too. Nice analysis!
I have a definitive answer for you all.
I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.
So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.
Cool. I guess you aren't seeing the transactions being redone because the accounts had no valid coins at all, right?
I have a definitive answer for you all.
I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.
So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.
So, I suggest not to concentrate heavily on preventing the network split, since that is inevitable event in the life of Internet,
but to invent some method to monitor connected computing power, to allow those, who bother, to stop processing transactions,
until the network's majority reconnects back.
Perhaps that would not be a realtime method, but a reasonable and fixed delay will still be accepted.
I'm sure, GUI client or daemon should inform you about total computing power, but how can it be computed?
Difficulty? It is too slowly updated.
What is your variants?
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks. This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.
Imagine a cable cut, or series of cable cuts that isolated a block of countries.
- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection
These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there. Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.
Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins. When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
",
"nested_level": 0
},
{
"id": 1976,
"thread_id": 157,
"source_id": "29",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: What happens when network is split for prolonged time and reconnected?",
"url": "https://bitcointalk.org/index.php?topic=661.msg7230#msg7230",
"date": "2010-08-03T13:33:08Z",
"text": "If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks. This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.
Imagine a cable cut, or series of cable cuts that isolated a block of countries.
- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection
These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there. Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.
Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins. When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
Satoshi posted about this concern:
http://bitcointalk.org/index.php?topic=241.msg2071#msg2071Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
You think people would fail to notice an entire ISP/country/continent falling off the Internet?
Satoshi posted about this concern:
http://bitcointalk.org/index.php?topic=241.msg2071#msg2071Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
You think people would fail to notice an entire ISP/country/continent falling off the Internet?
Why do you think, that what you describe will be the only reason for a Bitcoin network split?
And if some people will know that a continent is disconnected, then why all others will be as informed?
And even if everyone will know, that some amount of Internet is disconnected from the rest, then
how would they decide whether that is a good reason to stop processing (and sending) transactions?
ISP disconnectivity is not a rarity today, single misconfiguration may shutdown routing for a whole AS.
Will that be enough reason to stop processing transactions or not?
The same with a country and continent.
The question is not wheter there exists some parts of Internet or Bitcoin network, that will reconnect later.
You may always answer YES here, at every moment they exists. My phone loses signal very often, for example.
The actual question is
Whether I am connected with a network, that will be a majority of nodes on reconnect, or not?
It is not possible to give a definitive answer about future, but you may estimate that almost accurately based on the size
of the network before the split and the size of the network after the split.
If your network is not going to be a majority later, then it is safer to use another payment method, I suppose.
a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..
They can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are
I suppose you are right, unfortunately: They can do all those things now...the only real thing stopping them is bad pr.
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks. This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.
Imagine a cable cut, or series of cable cuts that isolated a block of countries.
- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection
These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there. Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.
Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins. When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
^^^ good points...I suppose that the demand for connectivity in the smaller network would produce an strong incentive to find
some way, no matter how primitive, to connect the two networks. It could even be as primitive as using (physical) snail mail or dialup.
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks. This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.
Imagine a cable cut, or series of cable cuts that isolated a block of countries.
- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection
These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there. Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.
Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins. When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
No, I am saying that given enough bitcoin users this is likely to happen, there is no need for them to notice that the bitcoin network split, either they notice that they can't check email/access websites outside of their local area and initiate a temporary alternate connection to the \"rest of the world\" or they just happen to take a laptop with bitcoin on an airplane.
I am also not saying it is a good thing. having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.
I am also not saying it is a good thing. having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.
Transactions won't disappear if they're valid. They'll just move to the longer block chain.
Invalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).
Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).
For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).
It doesn't have to be someone trying to cheat. You can be honest, and yet unlucky and get caught on the other side of a network split. If you generate and spend coins on the unlucky side of the network split, the consequences are the same as for dishonest users.
Transactions won't disappear if they're valid. They'll just move to the longer block chain.
Invalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).
Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours), it should be able to merge back to together without too many issues. So coin generation would probably be the only victim (if no double-spending cheats took place), or more technically, coin generation would be assigned to someone else that was generating at the same time as those that split off.
If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening. Each block in a row that takes longer than the average increases confidence against a false positive. So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening. Each block in a row that takes longer than the average increases confidence against a false positive. So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.
Really? It seems to me more likely that a bunch of people left/crashed than a whole new network half the size of the legit one has gotten to you.
I'm probably misunderstanding.
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 anymore.
Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),
In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.
If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
There's no time limit. Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.
I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis. The equiv. of having multiple wallets running at the same time.
It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
",
"nested_level": 0
},
{
"id": 1988,
"thread_id": 158,
"source_id": "2",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg6940#msg6940",
"date": "2010-08-01T23:14:23Z",
"text": "It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
+1
I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis. The equiv. of having multiple wallets running at the same time.
It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
Would it help to use the attached messages you have when sending to an IP address? It should be easy to record a \"sending ip address\" in that case also.
Nope, I really need it on a per-receiving address so that it is easy to directly track the balances from customers paying me.
",
"nested_level": 0
},
{
"id": 1991,
"thread_id": 158,
"source_id": "5",
"poster_name": "kwukduck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=654",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg13713#msg13713",
"date": "2010-09-22T18:59:52Z",
"text": "It's something im missing too, it would be nice to have seperate 'accounts' with each it's own balance and transactions. One for personal use, one for business, etc.
",
"nested_level": 0
},
{
"id": 1992,
"thread_id": 158,
"source_id": "6",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg14090#msg14090",
"date": "2010-09-26T08:24:11Z",
"text": "I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis. The equiv. of having multiple wallets running at the same time.
It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
I guess one way to do this would be use the -datadir=<dir> command line arg to specify a data directory (other than the default \"$(HOME)/.bitcoin/\"). You would only run the client on one directory at a time. (Note the directory is relative to the current directory for the SERVER bitcoind. Its safest to specify a fully qualified directory starting at the root.) Also of course the client does not need to be running on any specific directory nor running at all to receive payments to addresses in any/all of the wallets.
I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis. The equiv. of having multiple wallets running at the same time.
It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
I guess one way to do this would be use the -datadir=<dir> command line arg to specify a data directory (other than the default \"$(HOME)/.bitcoin/\"). You would only run the client on one directory at a time. (Note the directory is relative to the current directory for the SERVER bitcoind. Its safest to specify a fully qualified directory starting at the root.) Also of course the client does not need to be running on any specific directory nor running at all to receive payments to addresses in any/all of the wallets.
Yeah, I've been considering how to best go about this for the web services. Right now multiple services on the same machine run multiple clients bound to separate rpc ports. It works... to a point.
What I want is a separate wallet per user, and that scales pretty badly, so what I thought could be done is have multiple wallets in memory at the same time, based on some key (which would be the subdir inside the datadir for the wallet) and the rpc calls would take a -wallet= switch. I just don't know how many wallets I would be able to keep in memory at the same time, and I would loose the ability to move money instantly amongst them, but that's ok, I guess.
A slightly more scalable alternative would be to lazily load the wallets on demand. I know wallets keep a bunch of information, but maybe we could limit that to own addresses and transactions?
Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn
Can you just create a new windows user and log in with that user? Bitcoin creates a directory per windows user, I think.
",
"nested_level": 0
},
{
"id": 1995,
"thread_id": 158,
"source_id": "9",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg14199#msg14199",
"date": "2010-09-27T04:34:04Z",
"text": "You could create an additional database file with public keys associated with usernames/passwords. Creating an address logs the resulting public key to the new database (in addition to wallet.dat); CreateTransaction is modified to only select coins from those addresses associated with the account; the various \"list transactions\" commands are modified to only tally/show transactions to addresses associated with the account; new commands are added to transfer keys from one account to another. You could make it possible to transfer funds (without the keys) from one account to another without a real transaction, but this would involve much more complexity.
Implementation wouldn't be too difficult, I think (if you don't have to deal with the UI). The worst part would be dealing with the new database file and figuring out how to replace the existing authentication with your own stuff.
",
"nested_level": 0
},
{
"id": 1996,
"thread_id": 158,
"source_id": "10",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg14243#msg14243",
"date": "2010-09-27T13:48:18Z",
"text": "Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn
I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,
free from his dictatorship and tyranny. That is solely my own opinion.
For the techical issue discussed: It is clear, that the \"node\" instance, that holds the blocks database, connects to the network,
exchanges data with peers and with users, is architecturally independent from the \"wallet\" instance(s).
Wallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.
So it is feasible to have \"block chain\" daemon, that will cache block database on disk and may also act as an intermediary
between the local users and \"the network\", so it will have no secret keys at all, no sensitive information.
And the local \"wallets\" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no \"bind to port 8XXX\" issue.
They will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.
And so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like \"getreceivedbyaddr\" does now.
Generation should happen at admin's local wallet, not at the networking node. That means \"wallets\" will be permitted to publish not only transactions, but solved blocks too.
For current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.
So the only hope is the alternative implementations, that aren't possible without the standard.
Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn
I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,
free from his dictatorship and tyranny. That is solely my own opinion.
For the techical issue discussed: It is clear, that the \"node\" instance, that holds the blocks database, connects to the network,
exchanges data with peers and with users, is architecturally independent from the \"wallet\" instance(s).
Wallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.
So it is feasible to have \"block chain\" daemon, that will cache block database on disk and may also act as an intermediary
between the local users and \"the network\", so it will have no secret keys at all, no sensitive information.
And the local \"wallets\" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no \"bind to port 8XXX\" issue.
They will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.
And so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like \"getreceivedbyaddr\" does now.
Generation should happen at admin's local wallet, not at the networking node. That means \"wallets\" will be permitted to publish not only transactions, but solved blocks too.
For current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.
So the only hope is the alternative implementations, that aren't possible without the standard.
Well put, the standard is certainly needed to move this into mainstream, and source code as documentation sucks. But that is slightly longer, more important goal, not one I will hold off on projects for. I'm sure you agree the standard definition alone will take a good amount of time, especially when people look at it and start saying what if, or wouldn't it be better if... Then we still have to develop standards compliant clients.
I'm not saying that effort isn't worth it, much the opposite, it's mandatory for the immediate future. This hack jobs we do are actually a great way to get to know how things are being done, thus gathering any knowledge to help in describing the protocol
The \"label\" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.
If the API was extended as I describe below, would it solve the same problems as having multiple wallets?
Proposal:
+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
(change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
(returns array of [ \"address\" : \"bcaddresssentto\", \"amount\" : x.yz, \"confirmations\": n ])
Each customer \"account\" would be a bitcoin <label>. Account handling would look like:
Create account / create new address for account:
getnewaddress [account_id_label]
... tell user \"fund your account by sending coins to {the address returned}\"
Customer withdraws/spends:
sendfrom [account_id_label] [address] [amount]
(FAILS if balance for that account too low)
Show customer their balance:
getbalance [account_id_label]
Show customer their transactions in/out
listreceivedbylabel [account_id_label]
listsentbylabel [account_id_label]
---------
Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer. At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.
",
"nested_level": 0
},
{
"id": 1999,
"thread_id": 158,
"source_id": "13",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg14259#msg14259",
"date": "2010-09-27T15:33:59Z",
"text": "The \"label\" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.
If the API was extended as I describe below, would it solve the same problems as having multiple wallets?
Proposal:
+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
(change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
(returns array of [ \"address\" : \"bcaddresssentto\", \"amount\" : x.yz, \"confirmations\": n ])
Each customer \"account\" would be a bitcoin <label>. Account handling would look like:
Create account / create new address for account:
getnewaddress [account_id_label]
... tell user \"fund your account by sending coins to {the address returned}\"
Customer withdraws/spends:
sendfrom [account_id_label] [address] [amount]
(FAILS if balance for that account too low)
Show customer their balance:
getbalance [account_id_label]
Show customer their transactions in/out
listreceivedbylabel [account_id_label]
listsentbylabel [account_id_label]
---------
Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer. At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.
That is a much better approach, agreed. Assuming one label spans multiple addresses, so a client can accept transactions from an imported priv key (this being discussed on another thread), it seems to fit my needs perfectly, with only one small caveat which is internal transfers; say I use this approach for the lottery users (though that is not my use case, I actually would be more about site separation than user separation, but still):
- Each account has on inbound address, annotated with the login label
- Every time a user withdraws, I use the sendfrom mechanism you describe
- The user hits the jackpot, but the prize is actually held in multiple users' accounts so
a) I need to, when users buy tickets, move the amount to a separate address (forces external transaction, sucks)
b) I leave coins where they are, and then on payout I make a normal sendtoaddress (both external transaction and breaks the label accounting logic)
c) I leave coins where they are, payouts do nothing to the wallet, withdrawals do as many transactions as needed from each user account (what a nightmare!)
I don't see any good option here, and the best one, if I'm doing external transactions anyway, is a). I can trust these transactions with 0 blocks confirmed, because I'm both the sender and the recipient, and this would keep the accounts/labels in check, which serves as a great verification to the overall balances. Can you think of any alternative?
Separate \"accounts\" (addresses with labels) to accumulate Jackpots is the right idea. Users buy tickets, bitcoins are moved to the appropriate Jackpot account. When a Jackpot is won, transactions flow out of its account back to whoever won.
",
"nested_level": 0
},
{
"id": 2001,
"thread_id": 158,
"source_id": "15",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg14265#msg14265",
"date": "2010-09-27T17:16:18Z",
"text": "Separate \"accounts\" (addresses with labels) to accumulate Jackpots is the right idea. Users buy tickets, bitcoins are moved to the appropriate Jackpot account. When a Jackpot is won, transactions flow out of its account back to whoever won.
Yeah, it is quite obvious. I suffer for over optimization obsession syndrome
I feel that as data flows only inside the application there's no need to register transactions and put that 'extra load' on the system, but quite frankly the extra load is perfectly ignorable, and the transactions help keep everything tidy. Are you planning to do anything on this regard? I'm sure I can find my way around to do it myself, it will just take time, but I don't want to duplicate any work though.
I have the beginning of something like this. It's mostly like what Gavin described.
Some more rpc interface:
move <fromaccount> <toaccount> <amount>
Move from one internal account to another. I think blank account name (\"\") will be your default account. If you sell something to a user, you could do move \"theiraccount\" \"\" 123.45.
Is \"move\" the best name for this? I shied away from \"transfer\" because that sounds too close to sending a transaction.
I'm thinking a new function getaccountaddress instead of overloading getnewaddress:
getaccountaddress <account>
Gives you an address allocated from getnewaddress <account>. It'll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did)
Would these commands make it possible in simple cases to implement your website without needing a database of your own?
Wouldn't it be much simpler to be able to run several instances of bitcoin, each of them running on a specific \"wallet.dat\" file ?
I mean, we would just add a --wallet long option to the client/server app. The name of your account would be the name of your wallet file.
",
"nested_level": 0
},
{
"id": 2004,
"thread_id": 158,
"source_id": "18",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: Multiple Wallets, one computer",
"url": "https://bitcointalk.org/index.php?topic=665.msg18367#msg18367",
"date": "2010-10-24T20:58:32Z",
"text": "I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis. The equiv. of having multiple wallets running at the same time.
It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.
use -datadir and change the port on the source code and then use a different dir and port for every bitcoin instance
Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.
print \"send to \" + getaccountaddress(username) + \" to fund your account\"
print \"balance: \" + getbalance(username, 0)
print \"available balance: \" + getbalance(username, 6)
// if you make a sale, move the money out of their account
move(username, \"\", amount, 6)
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6)
",
"nested_level": 0
},
{
"id": 2006,
"thread_id": 159,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "adf",
"url": "https://bitcointalk.org/index.php?topic=671.msg7000#msg7000",
"date": "2010-08-02T13:12:03Z",
"text": "asdf
",
"nested_level": 0
},
{
"id": 2007,
"thread_id": 159,
"source_id": "2",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: Porn",
"url": "https://bitcointalk.org/index.php?topic=671.msg7002#msg7002",
"date": "2010-08-02T13:22:18Z",
"text": "I hate to say this, but I think davidonpda is completely correct. This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.
Take this as a business idea if you want, but charging 0.01 BTC per image download, 0.10 BTC per movie, and 0.05 BTC per audio clip sounds like something that could catch on real well.
Then again, even if you didn't want to necessarily get into porn, you could still do that in terms of building up some sort of licensed media library where folks could download images of say sunsets, bridges, and other high quality stuff (aka screensavers, etc.) and maybe a sound effects library. There is a market for stuff like this, and charging small amounts for individual pieces could be a lot of fun.
",
"nested_level": 0
},
{
"id": 2008,
"thread_id": 159,
"source_id": "3",
"poster_name": "mtgox",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=489",
"subject": "Re: Porn",
"url": "https://bitcointalk.org/index.php?topic=671.msg7004#msg7004",
"date": "2010-08-02T13:23:12Z",
"text": "I think bitcoin poker will really establish the BTC.
",
"nested_level": 0
},
{
"id": 2009,
"thread_id": 159,
"source_id": "4",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Porn",
"url": "https://bitcointalk.org/index.php?topic=671.msg7005#msg7005",
"date": "2010-08-02T13:38:45Z",
"text": "I hate to say this, but I think davidonpda is completely correct. This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.
Take this as a business idea if you want, but charging 0.01 BTC per image download, 0.10 BTC per movie, and 0.05 BTC per audio clip sounds like something that could catch on real well.
You hate to say this? You don't like porn or something?
I'd like to refer your attention to the walmart thread if you haven't read it already
http://bitcointalk.org/index.php?topic=659.0The easiest industry to get on board of bitcoin? Come on... micropayment capable... a little anonymous? No adult store names on the credit card receipt? Someone should make a BitPorn store if they want to see bitcoins really catch on haha.
lmao
I dont know about the \"micro\" part
I believe there's a huge difference between porn (which is art, weather you like it or not) and poker (or, as the governments like to put it, gambling). Basically, gambling is highly legislated, and online gambling even more so these days. The sites need to keep records of everything and while BTCs could be seen as 'play money' that would only work to a point, I believe.
Porn, on the other hand, is just art (so as long as all those involved are at or above legal age, of course) and, \"no dear, of course I don't browse those stupid misogynous sites\" but I would certainly pay in bitcoins for that because... ahem... I want to help the economy pick up.
It would also rock at poker, sure, but I don't think any of the established sites will want to venture a government action because they allow 'anonymous money' to go in.
",
"nested_level": 0
},
{
"id": 2012,
"thread_id": 159,
"source_id": "7",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Porn",
"url": "https://bitcointalk.org/index.php?topic=671.msg7013#msg7013",
"date": "2010-08-02T14:36:53Z",
"text": "Why does the government hates internet gambling?
I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.
You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.
Who will provide the p0rn?
Why does the government hates internet gambling?
Why would you assume they hate it? The problem, afaict, is just controlling it. It's hard, almost as hard as the drug market. If they find a way to prevent anyone from gambling online without their approval and scrutiny, then you'll see online gambling on government sponsored ads everywhere (with a disclaimer saying \"gamble responsibly\" in very small letters). The same applies to bitcoins in general, it is just something they don't control which means can't easily tax, which obviously is seen as a threat, especially when they have a concurrent thing, which is controlled and taxed by said governments.
I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.
You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.
Who will provide the p0rn?
Great...now we have to put up with ads for adultfriendfinder
I used to own the domain name sexrssize
Give people free iphone 4's to perform on facetime for 10 bitcoins a minute........
I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.
You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.
Who will provide the p0rn?
I have some sparetime
...but I guess my girlfriend will be a little bit less happy with the ideaPoker sites aren't illegal in a lot of places. In fact they aren't illegal in the US. It is just illegal to fund the site with a credit card and even that is about to be repealed it looks like:
http://en.wikipedia.org/wiki/Online_gamblingWho will provide the p0rn?
It's my impression that most online porn these days is made by amateurs. That really annoys the professionals, or so I've read.
Poker sites aren't illegal in a lot of places. In fact they aren't illegal in the US. It is just illegal to fund the site with a credit card and even that is about to be repealed it looks like:
http://en.wikipedia.org/wiki/Online_gamblingYou mean to say that playing poker at poker sites is not illegal in the US, right?
Running one would not be legal, afaik.
Do you play much online?
I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.
You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.
Who will provide the p0rn?
I have some sparetime
...but I guess my girlfriend will be a little bit less happy with the idealmao
Who will provide the p0rn?
It's my impression that most online porn these days is made by amateurs. That really annoys the professionals, or so I've read.
It's the opposite for poker. More amateurs is good for the pros ;-)
If we could just find a way for the pros to do porn vs amateurs I think everyone would be happy.
If we could just find a way for the pros to do porn vs amateurs I think everyone would be happy.
Actually, I believe that the future of professional porn is MMRPG with AIs and dongles
I hate to say this, but I think davidonpda is completely correct. This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.
You hate to say this? You don't like porn or something?
Been there, done that in terms of getting tied up with the porn industry. Some of the people involved on a full-time level in the \"porn industry\" certainly are folks you would not want hanging around your kids, or for that matter even being around at all. I'm sort of lucky I'm even still alive frankly for even having been however briefly associated with this crowd. Money is to be made, but there is a price to be paid. Make sure you are willing to pay the price and know very well what the price is that has to be paid when getting into an enterprise like this.
The guys that make you pay don't care about courts, and many are into.... let's just say other enterprises of questionable legality.
Been there, done that in terms of getting tied up with the porn industry.
Bondage is a fairly common fetish, afaik.
It would also rock at poker, sure, but I don't think any of the established sites will want to venture a government action because they allow 'anonymous money' to go in.
http://www.pokerth.net/could be a winning combination...
Why does the government hates internet gambling?
B/c they can't tax it.
Ta,
Why does the government hates internet gambling?
B/c they can't tax it.
Ta,
DING! DING! DING! DING! DING!
Why does the government hates internet gambling?
B/c they can't tax it.
Ta,
DING! DING! DING! DING! DING!
The UK government seems to be doing an OK job of it.
I'll say this from experience.. a lot experience.. Don't ask.
The online adult market won't adopt Bitcoin easily. The type of person who buys online porn is a 'revolver' of credit. They don't have money to spend on porn. They *need* credit. That's why credit cards work so well.
Bitcoin is too difficult for the average guy to use. He wants porn. He doesn't care about hashing/encrypting/p2p. No amount of convincing will tell him that Bitcoin is better than a credit card. Also, the thought of downloading and installing an application is scary to an experienced porn customer. They've all had their fair share of viruses, excessive popups from CJ sites, and other general web annoyances.
Porn sites won't adopt Bitcoin because it is a waste of time. It can't do recurring billing. That is their bread and butter. Being able to silently just keep billing someone's credit card, until they cancel, is what fuels their affiliate programs and their promises to pay $150-$200 per sale (aka \"join\") to affiliates.
Lets say that you solved some of these problems by directing porn customers and merchants to a web interface system like MyBitcoin. Let's also say that they have a working shopping cart system for the merchants. I'll explain the problems with that next...
You could get porn customers to use it. But, you'd end up with the problem of funding the wallet. Assuming that the customer doesn't easily give up. (They *buy* porn because finding it for free is too much of a hassle. They are *LAZY*.) The customer will seek out PayPal or credit card to Bitcoin exchangers. (They stick with what they know.) The liabilities would be held by the exchangers. The levels of chargebacks will slowly increase on these exchangers until they are out of business.
After that happens, it would grind to a halt. Merchants would drop it like a hot potato. They are used to dropping payment options. It is their first reaction when something goes wrong. The online adult industry is riddled with bank/Visa/whatever freeze-ups.
From the merchant side, you'd have the problem of \"cashing out\". The porn merchants don't give a damn about your virtual currency. They want dollars. MyBitcoin, in this example, would have to guarantee to buy (under contract) every single Bitcoin or no merchant in their right mind would use it. Sure, they could pass the Bitcoins to their affiliates/promoters to alleviate some of their liabilities. This would require some serious adoption (and convincing) across the entire industry.
The only viable option for Bitcoin in the adult arena is the micropayment one. Period. You'd have to supply absolutely *all* of the web technology. (Customer AND merchant.) It would have to be entirely web-based. You'd have to guarantee, in writing, to buy each coin back. This would only work on a few sites. Sites that sell porn per image, video, software download, etc. Sites that don't rely on recurring revenues.
Personal reservations aside; the fastest way to encourage adoption would be a dumbed-down HYIP.
I wouldnt sell porn directly with bitcoins.What I would do is setup an adult verification service using bitcoins that has agreements with other avs companies to accept your avs as acceptable. Customers could then use their sites without having to reveal identity or credit card info.
Just an FYI: AVS is a scam. They don't verify anything. AVS has nothing to do with verifying someone's age.
They came about to skirt the Visa regulations on selling porn. (Around 2001) They claim to Visa that they are selling an age verification service and not porn. This evolved into \"ticket service providers\" who would sell tickets that could be redeemed for porn, and many other systems that 'skirt' the banking rules.
Are you really going to verify the age of the customer? You are going to sell them an anonymous currency and then ask for ID? Do you really think that current AVSes want Bitcoins? They rely on selling recurring billing.
Sorry to burst your bubble.
I'm not trying to be mean. I'm just being realistic.
I think bitcoin poker will really establish the BTC.
I disagree. All you can get with bitcoins by playing poker is bitcoins. Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.
I think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me.
I think bitcoin poker will really establish the BTC.
I disagree. All you can get with bitcoins by playing poker is bitcoins. Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.
I think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me.
Why not replace SharingMatrix/MegaUpload/et. al with a (user friendly) bitcoin based file host, and get all the \"free\" porn sites (like adultbay, for instance) to use it instead. I'd actually pay for the increased bandwidth and concurrent downloads if I didn't have to risk my personal and CC details and those evil, evil automatic recurring payments.
This way we can use porn (and music blogs) in a roundabout way.
I think bitcoin poker will really establish the BTC.
I disagree. All you can get with bitcoins by playing poker is bitcoins. Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.
I think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me.
Why not replace SharingMatrix/MegaUpload/et. al with a (user friendly) bitcoin based file host, and get all the \"free\" porn sites (like adultbay, for instance) to use it instead. I'd actually pay for the increased bandwidth and concurrent downloads if I didn't have to risk my personal and CC details and those evil, evil automatic recurring payments.
This way we can use porn (and music blogs) in a roundabout way.
Yeah, Bitcoin serve as good captcha.
Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to \"porn guys\", or afraid of recurring billing.
",
"nested_level": 0
},
{
"id": 2037,
"thread_id": 160,
"source_id": "1",
"poster_name": "nimnul",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=600",
"subject": "Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7207#msg7207",
"date": "2010-08-03T10:33:13Z",
"text": "Does anyone have the binary?
",
"nested_level": 0
},
{
"id": 2038,
"thread_id": 160,
"source_id": "2",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7231#msg7231",
"date": "2010-08-03T13:45:19Z",
"text": "Does anyone have the binary?
Which version? I haven't tried to build any yet, but after building on a few different distro so far, kind of got the process down pat.
I've got a CentOS 5.5 machine I could experiment with.
[foo@bar ~]# cat /etc/issue
CentOS release 5.5 (Final)
[foo@bar ~]# uname -a
Linux foo.bar 2.6.18-194.3.1.el5.028stab069.6 #1 SMP Wed May 26 18:31:05 MSD 2010 i686 i686 i386 GNU/Linux
",
"nested_level": 0
},
{
"id": 2040,
"thread_id": 160,
"source_id": "4",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7241#msg7241",
"date": "2010-08-03T14:09:33Z",
"text": "Cool, we could both use a build then
My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?
Anyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.
",
"nested_level": 0
},
{
"id": 2042,
"thread_id": 160,
"source_id": "6",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7261#msg7261",
"date": "2010-08-03T16:20:59Z",
"text": "Apparently, even after copying over the header file; those libraries are disabled, grrrr.
Guess I'll have to hack one together
Ok, got around the encryption issue (guess it's never going to be part of the Cent OS library since they don't use that part of openssl), legal issues aside, just left with the DB issues during compile, so I'll need to compile a db4.7 version and hopefully we'll have a test build here soon.
",
"nested_level": 0
},
{
"id": 2044,
"thread_id": 160,
"source_id": "8",
"poster_name": "nimnul",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=600",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7272#msg7272",
"date": "2010-08-03T17:21:58Z",
"text": "Yes, it's not that simple - otherwise I could have compiled it myself.
1) In CentOS OpenSSL rpm elliptic curves cryptography is disabled, so you have to build OpenSSL yourself.
2) CentOS Boost-devel RPM is outdated and missing a lot of things, so you have to build Boost yourself too.
3) CentOS WxWidgets RPM is outdated so you have to build it yourself too. And its build requires more than 256 mb ram. Satoshi improved bitcoind so doesn't require wxWidgets any more, but I'm not sure whether that patch is in 0.3.7 or whatever sources you are building.
",
"nested_level": 0
},
{
"id": 2045,
"thread_id": 160,
"source_id": "9",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7274#msg7274",
"date": "2010-08-03T17:29:28Z",
"text": "I've been able to get around all of those, I'm actually stuck at the DB4.7 stuff.
I build it directly from the source and during the compile I get an error:
db_cxx.h:1083: error: expected class-name before \u0091{\u0092 token
I checked the header file, I think there is a syntax error, but not sure.
Any suggestions?
This is the block of code it stalls at, the class is defined at the top of the file, so I'm not sure why it hangs at that error without digging through all the Berkeley DB code. I don't want to go to a newer version of the DB if it's going to mess with everyone's BitCoin database that uses this build.
// Almost any error in the DB library throws a DbException.
// Every exception should be considered an abnormality
// (e.g. bug, misuse of DB, file system error).
//
class _exported DbException : public __DB_STD(exception)
{
public:
virtual ~DbException() throw();
DbException(int err);
DbException(const char *description);
DbException(const char *description, int err);
DbException(const char *prefix, const char *description, int err);
int get_errno() const;
virtual const char *what() const throw();
DbEnv *get_env() const;
void set_env(DbEnv *dbenv);
DbException(const DbException &);
DbException &operator = (const DbException &);
private:
void describe(const char *prefix, const char *description);
char *what_;
int err_; // errno
DbEnv *dbenv_;
};
I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk.
{snip} And its build requires more than 256 mb ram. Satoshi improved bitcoind so doesn't require wxWidgets any more, but I'm not sure whether that patch is in 0.3.7 or whatever sources you are building.
Yeah, the bitcoind build gets around any errors for those, but I still get stuck at the DB error.
Just for kicks, tried to compile with DB4.8 got the same error, LOL (the line number was slightly different, but at the same class)
Didn't get this on other Distros, might be a CentOS related error, but not sure why.
",
"nested_level": 0
},
{
"id": 2049,
"thread_id": 160,
"source_id": "13",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Bitcoind x86 binary for CentOS",
"url": "https://bitcointalk.org/index.php?topic=685.msg7289#msg7289",
"date": "2010-08-03T18:10:24Z",
"text": "My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?
Anyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.
Yes, ecdsa.h is considered patent-encumbered, so Red Hat and other distros turn off ec-dsa.
Yes, Virginia, this means that bitcoin potentially has patent problems.
I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk.
I'm probably going to load up a virtual machine of CentOS 5.5 and work with that. I've really barfed up the server I was experimenting on trying make it build the binary, LOL.
I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk.
I urge you not to use BDB 4.8. The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.
Ok, conquered the DB issue after pestering an Oracle developer all day
When you compile DB 4.7.25, you have to use an extra config command or else the compile will be missing those vital header files (why???)
Anyway, here is what it was
../dist/configure --enable-cxx
make
When you compile the source, this fixes the DB compiling related errors.
Ah, crap. I totally forgot about that extra flag. I knew about that before from Lazslo's Linux Build Document. Sorry about that. Get a working build up and running and you'll definitely be getting some BTC from me.
Oh, but there's more!
Even after I did that, I couldn't get it to compile due to linking errors. I was able to get a solid compile of bitcoind though, this is the extra steps it took.
After compiling and installing the BerkeleyDB4.7, you need to add it's include path to the makefile.unix
Add
-I\"/usr/local/BerkeleyDB.4.7/include\"Then you need to copy all the libraries from \"
/usr/local/BerkeleyDB.4.7/lib\" to \"
/usr/lib\"
BUT WAIT, there's MORE!
Yes, and if that was not annoying enough, now it will fail to compile because of an OpenSSL error, Grrrrr..
Now you must copy libcrypto.a and libssl.a from \"
/usr/local/ssl/lib\" to \"
/usr/lib\"
Yes, those can be linked, but I got tired of chasing down compiler errors, was easier to just copy them.
After all of that, then you should be able to compile a bitcoind binary.
I'm testing it now, seems to be working just fine. Downloading blocks and such. When it finishes, I'll experiment with some coin generation and coin transfer.
I'm still caught on the GUI client compile, currently hangs at
/usr/bin/ld: cannot find -lSM
If anyone is good with Google, let me know.
I've posted the binary up here (32 bit only - bitcoind):
Click HereThere are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
Will probably tackle the GUI client build another day, this one wore me out. Donate some BTC to my sig if you are feeling generous
There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
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.
Hi all,
Does anyone have jsonrpc or something similar working with HTTP Authentication? I'm trying to hit up my bitcoin server with python over JSON-RPC, and of course, getting authorization errors from the new server.
I couldn't find much about this online, surprisingly, so thought I'd ask here.
",
"nested_level": 0
},
{
"id": 2058,
"thread_id": 161,
"source_id": "2",
"poster_name": "vess",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=621",
"subject": "Re: Authentication, JSON RPC and Python",
"url": "https://bitcointalk.org/index.php?topic=689.msg7271#msg7271",
"date": "2010-08-03T17:20:44Z",
"text": "Update: Here is the current state of my hackish code:
postdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})
req = urllib2.Request('http://127.0.0.1:8332', postdata)
base64string = base64.encodestring( '%s:%s' % ('username','rpcpassword'))[:-1]
authheader = \"Basic %s .\" % base64string
req.add_header(\"Authorization\",authheader)
handle = urllib2.urlopen(req)
print handle.read()
If username or password is wrong, then I get an Authorization error from the server as expected.
Otherwise, I get nothing, just a closed connection.
Any leads or tips?
Did you see
http://bitcointalk.org/index.php?topic=528.msg4923#msg4923 ? That might be the problem... I had read somewhere about python urllib and bitcoing not playing along, but curl had no issues. Can't find that thread though.
Thanks for the pointer, interesting, but not what seems to be affecting me.
Here's my current code (running on Google App Engine)
postdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})
req = urllib2.Request('http://127.0.0.1:8332', postdata)
userpass = 'user:a'.encode('base64')[:-1]
authheader = \"Basic %s\" % userpass
req.add_header(\"Authorization\",authheader)
handle = urllib2.urlopen(req)
json_response = handle.read()
self.response.out.write (json_response)
This yields a HTTPError: HTTP Error 500: Internal Server Error
from the GAE local python script.
using
postdata = jsonrpc.dumps([{\"jsonrpc\": \"2.0\",\"method\": 'getbalance', \"params\":'','id':'1'}])
Yields the same result.Thanks for the pointer, interesting, but not what seems to be affecting me.
Here's my current code (running on Google App Engine)
postdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})
req = urllib2.Request('http://127.0.0.1:8332', postdata)
userpass = 'user:a'.encode('base64')[:-1]
authheader = \"Basic %s\" % userpass
req.add_header(\"Authorization\",authheader)
handle = urllib2.urlopen(req)
json_response = handle.read()
self.response.out.write (json_response)
This yields a HTTPError: HTTP Error 500: Internal Server Error
This is a verified bug in bitcoin.
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
What you say is true, but urllib2 does send Content Length.
In my case, we had a datatypes problem which Gavin helped me find: params needs to get a list in python, so
\"params\" : []
will work.
\"params\" : \"\"
did not.
With that amendation, my second sample code works well now. Hope it's helpful to others.
",
"nested_level": 0
},
{
"id": 2063,
"thread_id": 161,
"source_id": "7",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)",
"url": "https://bitcointalk.org/index.php?topic=689.msg7299#msg7299",
"date": "2010-08-03T18:56:44Z",
"text": "bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.
The two JSON RPC libs available at CPAN (Perl), and a compliant C lib that I wrote locally to verify the behavior.
Another issue I noticed with bitcoind's JSON-RPC is that by default there is no user, and PHP's fopen() function does not try to send the authentication information if no user was specified.
For example, this URL does not work:
But this one does:
I had to set the \"rpcuser\" in my node's bitcoin.conf file in order to get PHP to play nicely.
I encountered this as well: there's no documentation as to what auth string should be accepted in the case of no user.
It's probably best to require rpcuser and rpcpassword in future versions is my two cents. This is generally what's expected from an HTTP Auth anyway.
",
"nested_level": 0
},
{
"id": 2067,
"satoshi_id": 311,
"thread_id": 161,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)",
"url": "https://bitcointalk.org/index.php?topic=689.msg7335#msg7335",
"date": "2010-08-03T21:26:26Z",
"text": "bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.
I guess we should try to support the case where there's no Content-Length parameter. I don't want to rip and replace streams though, even if it has to read one character at a time.
Edit: That is, assuming there actually are any libraries that don't support Content-Length.
Another thread that asked what would happen if the bitcoin network were to split over a period of time and reconnect got me thinking....
One way to protect against such an unlikey event would be to have a watchdog process that kept track of the average time between blocks since the last change in difficulty, and alert the owner if the time between blocks were to jump significantly and uncharacteristicly over one or more consecutive blocks. This would also help protect a vendor from a double-spending scam if the theives involved were talented enough to be able to spoof his client's connections to delay another spend event from reaching him.
But then I realized that a server running a modified client on another machine, without a hard connection limit, could do the above for a collection of vendors, while monitoring the vendor's client by maintaining a connection to it and notifying the vendor by other means if the connection is lost. Also, if a war, internet virus, or other were to divide the bitcoin network for an extended time; the watchdog would be able to deterimine *where* the problem on the Internet actually is by analysis of it's customers' connections that were lost, and notify all customers in the affected zone that, presumedly, they are on the wrong side of the split.
The watchdog would also work quite well as a rapid annouce clearinghouse, improving the odds for it's customers that if they are subjects of a double-spending scam, that it's less likely that they are those left holding the raw deal.
Any talented programmers willing to take this up?
",
"nested_level": 0
},
{
"id": 2069,
"thread_id": 162,
"source_id": "2",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Bitcoin Watchdog Service",
"url": "https://bitcointalk.org/index.php?topic=691.msg7290#msg7290",
"date": "2010-08-03T18:12:28Z",
"text": "A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary.
",
"nested_level": 0
},
{
"id": 2070,
"thread_id": 162,
"source_id": "3",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Bitcoin Watchdog Service",
"url": "https://bitcointalk.org/index.php?topic=691.msg7301#msg7301",
"date": "2010-08-03T18:59:58Z",
"text": "A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary.
But that is only as good as the trust you have in the distribution channels, which are being discussed in other threads. If a compromised client was to be served as an upgrade, and most running clients would be using this version, then a new chain would replace the old one. What would happen when, after some time, the attack was disclosed and new clients with the real block chain signatures were run? Would the old (real) chain still be alive and replace the bogus one?
Definitively, we need some overall network hps meter in every node.
And at last I've found that article:
http://www.informit.com/articles/article.aspx?p=1237179Network splits are easier to produce, and happen more often, than many users on this forum think.
You don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.
You don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).
I have one
So, it is possible to talk about a short (1 - 3 hours) and controlled network split.
Not just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that
really depends on work hours. Weekend attack may have more prolonged effect.
Perhaps in the future that will be fixed and no BGP router will be vulnerable, but
anyway, nobody should count on Internet stability and persistent connectivity.
A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary.
But that is only as good as the trust you have in the distribution channels, which are being discussed in other threads. If a compromised client was to be served as an upgrade, and most running clients would be using this version, then a new chain would replace the old one. What would happen when, after some time, the attack was disclosed and new clients with the real block chain signatures were run? Would the old (real) chain still be alive and replace the bogus one?
We could convince satoshi to always post SHA1 signatures of uploads inside a PGP-signed blocks... establish a chain of trust for both source code and official binaries.
Definitively, we need some overall network hps meter in every node.
And at last I've found that article:
http://www.informit.com/articles/article.aspx?p=1237179Network splits are easier to produce, and happen more often, than many users on this forum think.
You don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.
You don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).
I have one
So, it is possible to talk about a short (1 - 3 hours) and controlled network split.
Not just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that
really depends on work hours. Weekend attack may have more prolonged effect.
Perhaps in the future that will be fixed and no BGP router will be vulnerable, but
anyway, nobody should count on Internet stability and persistent connectivity.
How would an attacker connect to both sides during this split in order to spend the coins? And if the attacker can do it, the likelihood that one or more honest nodes could bridge the divide is pretty good.
True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.
ISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block.
I favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities.
",
"nested_level": 0
},
{
"id": 2075,
"thread_id": 162,
"source_id": "8",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: Bitcoin Watchdog Service",
"url": "https://bitcointalk.org/index.php?topic=691.msg8978#msg8978",
"date": "2010-08-13T06:45:50Z",
"text": "Definitively, we need some overall network hps meter in every node.
And at last I've found that article:
http://www.informit.com/articles/article.aspx?p=1237179Network splits are easier to produce, and happen more often, than many users on this forum think.
You don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.
You don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).
I have one
So, it is possible to talk about a short (1 - 3 hours) and controlled network split.
Not just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that
really depends on work hours. Weekend attack may have more prolonged effect.
Perhaps in the future that will be fixed and no BGP router will be vulnerable, but
anyway, nobody should count on Internet stability and persistent connectivity.
How would an attacker connect to both sides during this split in order to spend the coins? And if the attacker can do it, the likelihood that one or more honest nodes could bridge the divide is pretty good.
1. Why an attacker is forced to be a single person with a single PC?
Copy the wallet on another PC and use it anywhere!
2. Why should network isolation only be used for double spending?
Can't it be used to slow down block generation? Will that affect difficulty adjustment?
True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.
But there will be no irc server to bootsrap from.
But there will be no irc server to bootstrap from.
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 completely redundant since 0.3.0.
Version 0.3.8 adds an important security improvement. Everyone should upgrade to get this change.
The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.
If it sees a longer chain, but it can't process it, then it knows something is wrong. It displays \"WARNING: Displayed transactions may not be correct! You may need to upgrade.\" and makes most RPC commands return an error. It still keeps generating as normal, which is necessary for the stability of the network.
There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!
Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/Link takes me to 3.7
",
"nested_level": 0
},
{
"id": 2079,
"satoshi_id": 315,
"thread_id": 163,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Please upgrade to 0.3.8!",
"url": "https://bitcointalk.org/index.php?topic=696.msg7381#msg7381",
"date": "2010-08-04T00:29:37Z",
"text": "I guess SourceForge hasn't updated its mirrors yet. The files are there on the admin side, but not on the user side. I have no idea how long that will take. It's always been immediate in the past.
Edit: SourceForge is updated now.
",
"nested_level": 0
},
{
"id": 2080,
"thread_id": 164,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7575#msg7575",
"date": "2010-08-04T20:40:55Z",
"text": "I just shut down freebitcoins.appspot.com; it looks like somebody in Spain is being a jerk and getting a new IP address, bitcoin address, and solving the captcha. Over and over and over again:
79.154.133.217 - - [04/Aug/2010:12:46:55 -0700]
\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"
\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\"
79.146.112.13 - - [04/Aug/2010:12:45:20 -0700]
\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"
\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\"
81.44.159.81 - - [04/Aug/2010:12:42:20 -0700]
\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"
\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\"
Those IP addresses all map to Telefonica de Espana. If it was you: give them back, please: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC
Now that 5 bitcoins is worth a fair bit, I'm thinking I need more cheating countermeasures. I can think of four things to try:
1. Rate limit based on the first byte of the IP address (79. or 81. in this case).
2. Rate limit based on the USER-AGENT string (\"Opera/9.8...\" in this case).
3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).
4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).
If you get rate limited, you'll get a message that asks you to try again tomorrow.
BitcoinFX: thanks again for the donation to the faucet; I'm going to drain the Faucet below 500 coins temporarily, and will refill it with your donation after the new cheating countermeasures are in place.
This has been going on for a while I would say. I noticed that when I would donate BTC to it, I would check the site a few minutes later and it would be back down below 500 again very quickly (but not further down since it appears to stop after it reaches below 500)
I'm afraid with how the nature of Bitcoin works, even if you narrow it down to IP address, Bitcoin Address, cookies, browser string, etc. someone can still fake/change all of those to drain it.
I think your recommendation of 0.50 with it being reduced to the 0.05 when it hits below 500 BTC would work better to deter this kind of thing. Also, a rate per hour limit (because someone with a botnet could have all of them descend on it and empty it even at 0.05 a piece just for kicks)
It's obvious from your logs, the guy/gal was just renewing his IP address, generate a new bitcoin address, refresh the page, copy/paste new bitcoin address, send 5 BTC; rinse and repeat.
",
"nested_level": 0
},
{
"id": 2082,
"thread_id": 164,
"source_id": "3",
"poster_name": "omegadraconis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=597",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7577#msg7577",
"date": "2010-08-04T21:25:46Z",
"text": "You know the same thing crossed my mind that you could drain the faucet by grabbing a new ip address. I figured most of the people would be honest enough to not do it or there was something behind the scenes preventing it. One idea might be Browser finger print and a 81.x.x.x or 71.x.x.x limit.
http://panopticlick.eff.org was something the eff did to show just how easy it is to finger print your browser (it checks your os build, Browser build, java, flash, other add-on versions, etc). If you were to combo detect the the browser id's and the first ip block it would be a fairly good way, though it would probably be a fair bit of work.
Another idea would be to add a delay to the coins being sent out, like say an hour after they are cleared the coin goes out. This wouldn't give someone instant satisfaction and would allow you to prevent the coins going out during that hour (Add a check to email yourself if a large number of transactions come through or something like that). Also dropping the coins being given out to 1 or 0.5 would significantly decrease the incentive of doing such a thing.
That's a really good idea, just make a queue system with a simple \"click to approve\" button.
I don't know how much traffic the faucet site gets though, might not be practical from a human standpoint, but I don't often see the faucet that far below 500 most of the time.
",
"nested_level": 0
},
{
"id": 2084,
"thread_id": 164,
"source_id": "5",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7584#msg7584",
"date": "2010-08-04T22:23:11Z",
"text": "I would make it give out 0.001% of the total bitcoins with a minimum of \u0e3f0.02 and I would move those two decimal points to the left whenever the official client changes to displays another precision point. Thanks for the service, it's very useful to new users. I hope you can stay one step ahead of the cheaters.
",
"nested_level": 0
},
{
"id": 2085,
"thread_id": 164,
"source_id": "6",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7589#msg7589",
"date": "2010-08-04T23:56:42Z",
"text": "Also dropping the coins being given out to 1 or 0.5 would significantly decrease the incentive of doing such a thing.
The incentive will always exist. It just makes it harder/take longer, more effort and creativity involved.
What if they just use different proxy's, than the checking the first byte of the IP is useless.
You could make a registration form on the site where they first got to activate they're email address, and than get a login code.
After login than they can request the free coins, of course there is a limit of one request for one email address and you keep on checking the ip.
So if you want a lot of coins, you first got to register a lot of email adresses and than you got to register with all those addresses, you really got to have no life to do all that trouble just to drain down the Faucet
This is a nice exercise in what happens when you give free stuff away.
Hint: People try to get the free stuff.
I do think it's a nice idea, I'm not saying you shouldn't do it.
",
"nested_level": 0
},
{
"id": 2088,
"thread_id": 164,
"source_id": "9",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7612#msg7612",
"date": "2010-08-05T01:32:56Z",
"text": "Whoever cheats to take free bitcoins wins this award.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Frlv.zcache.com%2Fidouche_bag-p1499008313458078112ih44_125.jpg&t=589&c=tI65l0ONlabDrA\"/)
It is the douche-bag of the year.
Thanks for all the ideas!
First: I'm definitely going to drop from 5 BTC; I think I'll go all the way down to 0.50 BTC (rather than do 1 or 2). Giving away a percentage of how much the faucet has is an interesting idea, but I want it to be as simple as possible.
Second: I really don't want to make getting coins from the Faucet a whole heavy-weight \"register and check your email and yada yada yada.\"
But I do like the idea of adding an extra hurdle for 'suspicious-looking' behavior. So I'm leaning towards doing some fuzzy browser fingerprinting combined with rate-limiting and, if you look suspicious or the fountain has been giving away a larger-than-usual number of coins, require that you login with your google account before getting any coins. No google account: no coins.
It is hard to create lots of google accounts; they're requiring either phone or SMS account verification these days...
",
"nested_level": 0
},
{
"id": 2090,
"thread_id": 164,
"source_id": "11",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7617#msg7617",
"date": "2010-08-05T02:11:34Z",
"text": "This is a nice exercise in what happens when you give free stuff away.
Hint: People try to get the free stuff.
I do think it's a nice idea, I'm not saying you shouldn't do it.
Yeah, I shoulda anticipated problems when Bitcoins went from 0.005 USD each to 0.06 each. If it takes somebody two minutes to go through the \"get a new IP, get a new BC address, solve the captcha\" process then they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which, if you're unemployed, bored, and/or 13 years old is easy money.
This is a nice exercise in what happens when you give free stuff away.
Hint: People try to get the free stuff.
I do think it's a nice idea, I'm not saying you shouldn't do it.
Yeah, I shoulda anticipated problems when Bitcoins went from 0.005 USD each to 0.06 each. If it takes somebody two minutes to go through the \"get a new IP, get a new BC address, solve the captcha\" process then they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which, if you're unemployed, bored, and/or 13 years old is easy money.
Hmm, now that I think about it....13 years old would find bitcoins to be a money making opportunities, especially since they generally can't be employed by business and such. They can however, offer services and goods of some kind to bitcoiners in exchange for some money. When he/she saved up a bit, she/he can buy hosting services and bootstrap their way to bigger business operations.
Sadly, I don't think there's a viable anti-abuse system when you have an automated system dispensing coins for free. (anonymous, irrevocable coins)
The only countermeasure that makes sense is to slow down the value and pace of the whole faucet to where someone has a chance to manually keep an eye on flow.
But coming back to the roots of why it's neat, and what people reasonably get from it, the specific value is not really important. I see it as more a \"system test\", where someone can watch coins come in, transfer them to another computer, and so on. It's not supposed to be \"what can I buy with these\", but test coins. Having 0.02 coins is much more fun than having zero.
To that end, a system that dispenses BTC 0.02 and has a significant delay (30 mins?) is less likely to be attractive to even automated abuse plots.
",
"nested_level": 0
},
{
"id": 2093,
"thread_id": 164,
"source_id": "14",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7638#msg7638",
"date": "2010-08-05T06:12:25Z",
"text": "I've tried it last week and got 0.05BC, which is fine for its purpose (testing how it works and if it works). I also send the same amount back. I think it works just fine like this. I wouldn't have tried it when I had to get a google account, or something similar (getting such thing for only 0.05BC is just to much effort for testing it).
",
"nested_level": 0
},
{
"id": 2094,
"thread_id": 164,
"source_id": "15",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7660#msg7660",
"date": "2010-08-05T11:30:37Z",
"text": "Perhaps it would help to be more clear about the Faucet operating on an honor principle, and that no one is really allowed more than 5.05 bitcoins (or 0.55 bitcoins if you change it to that). When I revisit the site today it says \"Right now the rule is 0.05 bitcoins given per unique IP address.\" Such language could be interpreted as if it was actually OK to get more payouts from the Faucet using several unique IP addresses, since it would not be \"against the rules\". Improving the technical system to prevent cheating is probably a good idea anyway, since there are probably cheaters who don't care about being cheaters. But some may actually think they are just being clever, maximizing their benefit without breaking any rules.
",
"nested_level": 0
},
{
"id": 2095,
"thread_id": 164,
"source_id": "16",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7670#msg7670",
"date": "2010-08-05T14:09:51Z",
"text": "Just an idea... you could remove the message that tells the user he already got coins and always pretend to have sent coins when in reality you didn't. Maybe with a nice \"If it doesn't work contact me at ...\" message. Hopefully they'll just assume it's broken and don't bother trying to get coins from it anymore.
",
"nested_level": 0
},
{
"id": 2096,
"satoshi_id": 321,
"thread_id": 164,
"source_id": "17",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Who's the Spanish jerk draining the Faucet?",
"url": "https://bitcointalk.org/index.php?topic=704.msg7703#msg7703",
"date": "2010-08-05T17:06:03Z",
"text": "Silently failing would look bad.
1. Rate limit based on the first byte of the IP address (79. or 81. in this case).
Definitely needed. What rate are you thinking of? Ultimately, it's better to rate limit it than to let it all drain out.
3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).
That might work surprisingly well. If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.
4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).
Definitely time to lower it.
I cant figure out how to send a transaction to an ip address from bitcoind command line interface. Has the function been implemented yet? (linux 64 if it matters)
",
"nested_level": 0
},
{
"id": 2098,
"satoshi_id": 322,
"thread_id": 165,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoind transaction to ip address",
"url": "https://bitcointalk.org/index.php?topic=711.msg7705#msg7705",
"date": "2010-08-05T17:28:40Z",
"text": "It's not implemented.
It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.
",
"nested_level": 0
},
{
"id": 2099,
"thread_id": 166,
"source_id": "1",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Transaction Overload Solution",
"url": "https://bitcointalk.org/index.php?topic=713.msg7688#msg7688",
"date": "2010-08-05T16:05:07Z",
"text": "In another thread I posted the comment below, but I felt that it was an important enough flaw that it should be addressed asap before bitcoin is overrun with huge numbers of automated non-micro payments.
The real issue is that even a simple legitimate automated payment negotiation system could overload bitcoin by introducing more transactions than the credit card system currently uses. The net result is that block sizes could become HUGE.
In my use case you have a P2P system where they pay *anonymous users* for priority downloads. Assume you have a single \"torrent\" file with 100,000 people all seeding and downloading. That could easily generate 100,000 payments greater than 0.01 per minute. Now clearly, the program would only have to use BTC in the event that upload != download between two clients. But you never know what kind of crazy ideas people will eventually come up with.
Such a system would be distributed and thus there would be no easy way to identify \"spam\" from legitimate usage. Even using my solution of transferring 1+ BTC at a time and giving change if the balance is greater than 0.01 could cause a transaction bloat writ large.
I suspect that the \"cost\" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.
The only solution to this problem is to make broadcasting of a transaction \"non free\". Namely, if you want me to even *attempt* to include it you have to pay me whether or not I succeed in getting it in first. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.
The implication is that you may not even receive notice of payment until a node that you paid to receive your transaction and *attempt* to integrate it into a block manages to do so. This means that you would not even see 0/unconfirmed and that a transaction must make it into a block before anyone that wasn't paid to *attempt* to integrate it even knows it exists. You are protected against people taking your payment and then not even attempting to integrate it because they must find away to get your payment to them integrated or they don't even get paid and it would cost more for them to \"forward\" the generation transaction fee to another node than they could get by having the transaction go through.
This structure would encourage pay-to-ip systems because that make the receiver of the payment responsible for paying to get it integrated. Either they run their own bitcoin generators *or* they pay to send the transaction to someone who is.
The \"winner take all\" transaction fee requires that I incur the cost for receiving and attempting to integrate transactions yet I would only get paid 1 time every couple of weeks if I was lucky and *if* my internet connection could handle receiving every transaction that occurred.
People should pay others to generate whether or not the generation was the first one to integrate your transaction into a block. What are the technical challenges to implementing this.
",
"nested_level": 0
},
{
"id": 2100,
"thread_id": 166,
"source_id": "2",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Transaction Overload Solution",
"url": "https://bitcointalk.org/index.php?topic=713.msg7690#msg7690",
"date": "2010-08-05T16:14:00Z",
"text": "The downside to a non \"broadcast\" system is that it makes it easier to double-spend and in fact your payment to generate would be a prime candidate for double spending.
I am not sure that the system can stand such delays in the broadcast system. I suppose those worried about double spending would pay to have the transaction \"vetted\" by more nodes and those that can handle a loss would take the risk.
",
"nested_level": 0
},
{
"id": 2101,
"satoshi_id": 323,
"thread_id": 166,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Transaction Overload Solution",
"url": "https://bitcointalk.org/index.php?topic=713.msg7706#msg7706",
"date": "2010-08-05T17:38:21Z",
"text": "I can't think of a way to implement that. All the transaction fees would be additional transactions. What about the transaction fees for the transaction fee's transaction?
",
"nested_level": 0
},
{
"id": 2102,
"thread_id": 167,
"source_id": "1",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7771#msg7771",
"date": "2010-08-06T01:52:00Z",
"text": "Let me begin by saying that Bitcoin is an amazing project and I am very impressed with the implementation and the goals. From reading these forums it seems to be understood that debate about the design and operation of the bitcoin economy ultimately serves to strengthen it, so I hope these comments are taken in that spirit. *EDIT - I have been convinced by further research and discussion that Bitcoin is actually highly efficient compared to most traditional currencies, because the infrastructure required to support a government issued fiat currency represents a much larger investment of resources than Bitcoin's cpu power consumption. I am leaving this thread active though because it has been generating a lot of interesting discussion.*
I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.
One argument is that anyone who chooses to generate coins is actually making the choice to purchase bitcoins with electricity/computational resources, and that because some/many people are in fact making that choice, bitcoins have at least that much \"value\" to the generators, who can be assumed to be maximizing their utility. A contrasting argument is that cost of production is different than market value, and the most objective measure is the current market conversion price to a more liquid and widely traded currency such as the US dollar.
My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.
As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value. *Edit - as mentioned above, I am now much more optimistic about Bitcoin long term. I still think compucoins would be a cool idea, though!*
",
"nested_level": 0
},
{
"id": 2103,
"thread_id": 167,
"source_id": "2",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7772#msg7772",
"date": "2010-08-06T02:26:50Z",
"text": "I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.
One argument is that anyone who chooses to generate coins is actually making the choice to purchase bitcoins with electricity/computational resources, and that because some/many people are in fact making that choice, bitcoins have at least that much \"value\" to the generators, who can be assumed to be maximizing their utility. A contrasting argument is that cost of production is different than market value, and the most objective measure is the current market conversion price to a more liquid and widely traded currency such as the US dollar.
My only counter is that it will seem that way to a first time user, because they have no bitcoins at all. But there are a possible 3.6 million bitcoins out there plus a member here runs a site that gives away free bitcoins so people can experiment with the system. The amount of actually energy, if you break it down, is only that of the PC itself. When you consider how few watts a processor runs to get a block where each 50 BTC block is worth about $3 USD, that's much more than the electricity cost it took to create it. Right now, you can generate BitCoins and sell them for more than it cost the electricity to run the PC to do it unless your electrical rates are the highest in the world. The only reason no one does is the scale of economics that would be required to make it profitable.
My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.
The same can be said about gene folding or SETI since a ton of CPU time and electricity often does not reward the individual user of the their client software. It's the collection as a whole that rewards everyone in non-monetary ways (find cure for cancer, find aliens, etc.)
As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value.
Unless electrical rates go up higher than the value of BTC, there will always be people willing to trade out CPU resources for it. Currently, cheap VPS farming has a return on BTC generation, though not very much. The other benefit is that the generation rate tries to remain constant, so it's not always going be hard to generate BTC if less and less people decide to do it, the difficulty goes back down.
Thanks very much for the extensive and informative reply. I do not disagree with the points that you made, but I also don't believe it invalidates my fundamental point: it is not inherently necessary for a digital currency such as bitcoin to require as much energy input as bitcoin does. A digital currency that offers bitcoin's behavior at a \"lower cost\" of energy overhead of the currency and transaction system has a competitive advantage. The digital currencies that will win and become standards, I believe, are the ones that offer the most value-added on top of the costs of running the system. Of course, there is room for many currencies - we already have a multiplicity - so it is not necessary for Bitcoin to become the \"one true money\" for it to succeed, but I believe the current minting policies will be harmful to its growth and adoption long-term. Much of the utility value of bitcoin resides in the work done to establish the security and reliability of the system - accomplishing that work with a smaller energy input would seem to be beneficial.
",
"nested_level": 0
},
{
"id": 2105,
"thread_id": 167,
"source_id": "4",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7777#msg7777",
"date": "2010-08-06T03:30:45Z",
"text": "Thanks very much for the extensive and informative reply. I do not disagree with the points that you made, but I also don't believe it invalidates my fundamental point: it is not inherently necessary for a digital currency such as bitcoin to require as much energy input as bitcoin does. A digital currency that offers bitcoin's behavior at a \"lower cost\" of energy overhead of the currency and transaction system has a competitive advantage. The digital currencies that will win and become standards, I believe, are the ones that offer the most value-added on top of the costs of running the system. Of course, there is room for many currencies - we already have a multiplicity - so it is not necessary for Bitcoin to become the \"one true money\" for it to succeed, but I believe the current minting policies will be harmful to its growth and adoption long-term. Much of the utility value of bitcoin resides in the work done to establish the security and reliability of the system - accomplishing that work with a smaller energy input would seem to be beneficial.
I think though you are comparing apples to oranges. The coin generation is for currency creation. You don't need to generate any coin to use the bitcoin system. You can purchase it from many market sites or get some donated for free from other sites. The current minting policy is what makes it useful because a digital currency where everyone has unlimited amounts (or large starting amounts) just causes unnecessary starting inflation. The overhead for the currency is by design, otherwise if someone creates an *easier* system, it will be quickly abused. Since you can't make everyone play fair, you create something where it's nearly impossible to cheat by using math. To make cheating expensive instead of \"easy\" is where this system works. If it's more profitable to generate coin than to cheat it, guess which one everyone will go with?
Nicely written gridecon. I completely agree.
I've been considering posting a similar critique but you've laid the issue out clearly. if you don't mind I'll add my thoughts here.
As the minting process and the transaction recording process are one, there is really no reason to separate them. I don't disagree with knightmb's points at all. But I do think that is is really important to point out that all that CPU power and electricity usage is absolutely NOT required for the task at hand.
Generating blocks serves three critical but independent functions in the bitcoin system.
1. It permanently records valid transactions in a roughly chronological order.
2. It creates *consensus* among all nodes on what transactions took place and when, WITHOUT relying on a central authority. That was a hugely clever breakthrough.
3. It trickles bitcoins into circulation at a regularly scheduled rate. (roughtly 50 BTC/10 min) Also a nice motivational trick.
However, all of these required tasks could be done in a much more efficient manner.
Generally in a P2P system, if you add more nodes then the necessary machine resources needed per node decrease. (for a given usage level of the service)
However, if we add more nodes to the bitcoin network the necessary machine resources needed per node increase. This is true of CPU usage and network bandwidth.
Satoshi already pointed out that the goal of this is not to scale to millions of pure P2P nodes. But instead to have thousands of transaction checking peers each having thousands of clients. That means the goal is to create core \"central authority\" of peer nodes each of which is trusted by some clients, but the core peers do not necessarily need to trust each other. This is a absolutely critical design construct if the current implementation of bitcoin is expected to scale to millions of traders.
However, there are other design possibilities that could meet each of these three critical goals without exponential growth in resources utilization.
Implementing the transaction graph using a redundant distributed hash table comes to mind. This could be done with or without a core of central peers. Another possibility would be just to store the transaction graph in a SQL database and use database replication among the core peers. Either of those satisfies goal 1 and 2 using minimal system resources.
Goal 3 is implementable by simply generating a distributed shared secret, then using that shared secret as a concensus random node to send 50 BTC to.
I agree with gridecon that such an implementation would out compete the current implementation. Even if it otherwise following exactly the same external behavior and transaction validation rules.
",
"nested_level": 0
},
{
"id": 2107,
"thread_id": 167,
"source_id": "6",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7783#msg7783",
"date": "2010-08-06T03:53:24Z",
"text": "I understand that bitcoin's utility as a currency is independent of the method of minting - that is crucial to what I'm trying to express. My claim is that the positive properties of bitcoin's security could be implemented using a different method of minting, and that users will likely gravitate to currencies with whatever they believe are the most fair and efficient minting systems.
Maybe an even simpler way to put it is that I think that it is a huge waste of resources to generate a digital currency by doing fundamentally useless computational work. If you want to regulate currency production in this way, it should be done \"parasitically\" on top of useful computation, such as that done by distributed computing research projects.
Let me make an analogy that I believe is actually very close to the current truth of the matter. The current method of coin minting is similar to a currency based on photographs of burned wheat. People grow wheat, burn it, and take photos of the burned wheat to prove that it was really grown and burnt, and then use the photographs as a medium of exchange. Does that sound sensible? No, and fundamentally it is just as senseless to waste potentially useful computer cycles on calculating the hash of random data until you hit the winning number.
",
"nested_level": 0
},
{
"id": 2108,
"thread_id": 167,
"source_id": "7",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7790#msg7790",
"date": "2010-08-06T04:51:07Z",
"text": "I understand that bitcoin's utility as a currency is independent of the method of minting - that is crucial to what I'm trying to express. My claim is that the positive properties of bitcoin's security could be implemented using a different method of minting, and that users will likely gravitate to currencies with whatever they believe are the most fair and efficient minting systems.
Go for it. In the meantime, I think that you both miss some fundamental truths.
1) The point of the system is not to 'mint' coins at a high energy cost, but a high computational cost, to protect the system no matter how high Moore's law may go.
2) The award of bitcoins is not 'minting' really anyway, it is an award by lottery for participating in the strenghtening the currency. Those 50 bitcoins already existed from the moment that the rules were conceived and the process set into motion. They are just distrubuted from the original owner in a systematic manner.
The computations are a neccessary part of keeping the system strong and confidence high, and are a small price to pay when compared to the costs that we all incur from the administration of fiat currencies. I think that it was a brilliant idea.
I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.
I don't accept that.
The idea that the value of a Bitcoin is in some way related to the value of the electricity required on average is a fallacy that has been widely spread by armchair economists to get-rich-quick merchants who don't understand the system.
My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.
It's not about the minting at all.
The computation required is to maintain the integrity of the system by growing the block chain which serves as a 'timestamp' of transactions.
It is probably possible to make the computation required for this process less than it currently is, but it would be at the expense of disk space or bandwidth or integrity or processing power required to validate transactions, or all of the above. The current system provides a good balance of all these things.
The minting is just a side effect, and an elegant way to reward those who have contributed processing power to the integrity of the system.
There are many other threads that try to propose 'better' ways of rewarding these contributions, but the 'winner takes all' system is the one we have at the moment.
As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value.
Good luck with implementing compucoins..
Again, it is
not about the mintingI understand the bitcoin is not INTENDED to be about the minting. The essence of my criticism is that a digital currency SHOULD NOT be \"about the minting\" but the current bitcoin system works against that goal! My argument is that the current minting system limits the utility of the currency largely because entirely too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive. If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.
",
"nested_level": 0
},
{
"id": 2111,
"thread_id": 167,
"source_id": "10",
"poster_name": "pyrrhos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=635",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7819#msg7819",
"date": "2010-08-06T09:37:43Z",
"text": "The minting should be seen as digging for gold in a gold mine. This is similarly wasting energy and resources for actually not doing anyone any favor since you increase the supply of gold. Except for yourself of course, and that why people will always will dig for gold as long as the price of gold dug will be higher than the cost of resources needed to dig. However, this difficulty is what gives scarcity and therefore value to gold.
Similarly, if and when bitcoin becomes more mainstream and follows economic sense (rather than beeing driven by curiosity, fun and excitement for participating in something new) the cost of electricity (in dollars or equivalent bitcoins) to create a bitcoin will never exceed the value of the created bitcoin. If that would happen, many will shut down their bitcoin generation for it would make no economic sense (I already stopped mine!). Luckily, and unlike gold mining, this behavior will adjust the cost of creating bitcoin to a sensible level (below the value of the generated bitcoin)
In the long run i expect that bitcoin minting will indeed be left to the supernodes which will probably have specialized hardware that are excellent in hash calculations and can do that way better than anyone with a general purpose pc. Similarly to specialized gold digging machines.
So although you are right that it would be nice to find a system that provides scarcity without cost (I dont know whether this is possible, it seems not), the costs are certainly connected and less to the value of the created bitcoin. And it is a self regulated system that will increase the cost of creation only if the use of bitcoin actually adds value (in the form of ease of use, anonimity etc.) and therefore is worth it.
The cost of creation is therefore is no limitation of the growth but more and indication of the added value of the use of bitcoin.
fuuny note: Following this logic the cost of minting will be somewhat less than 21million bitcoins which with the current prize of bitcoin is around 1 million dollars.
------
1neNcqV4yRUNwP9xCdcgRvBrNwWdFo3Wv
",
"nested_level": 0
},
{
"id": 2112,
"thread_id": 167,
"source_id": "11",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7825#msg7825",
"date": "2010-08-06T10:00:16Z",
"text": "Thanks to everyone for all the well-considered responses. I am, you could say, half-convinced - I understand the motivations for the design decisions bitcoin has made, but I still think more optimal solutions are likely to evolve. That said, the obvious intelligence and open-mindedness shown by the discussion here is in some ways the most convincing selling point! Any currency with a user community who engages in quality dialogue earns additional credibility with me, so based on the quality of this thread, I have acquired a few bitcoins, and distributed some of them to the posters who included a bitcoin address. As I hope I have emphasized, I think bitcoin is brilliant and I want it to succeed, I raise these issues because I would hate to see the success of bitcoin impeded by something, the minting model, that everyone agrees is in many ways arbitrary.
",
"nested_level": 0
},
{
"id": 2113,
"thread_id": 167,
"source_id": "12",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7828#msg7828",
"date": "2010-08-06T10:46:29Z",
"text": "If the problem you are identifying is that too much attention is
too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive.
I would tend to agree with you on the first part, but disagree on the second.
Chosing the 'winners' is a side-effect of the security of the system, if we were to choose the winners just based on picking a random address out of the transaction list this would certainly be less resource intensive, but you still need to make sure that the that the blocks cannot be easily forged by an attacker.
Perhaps you could contribute your ideas on how bitcoin should be publicized.
We (the bitcoin community) don't have a large corporate PR department who are paid to sit around and come up with good ideas.
Bitcoin video bounty thread might be a good place to start.
Another problem is that there is no one controlling focus group to set the direction of Bitcoin publicity and there are people who want to use bitcoins for all kinds of different reasons.
P.S. Thanks for the tip.
I understand the bitcoin is not INTENDED to be about the minting. The essence of my criticism is that a digital currency SHOULD NOT be \"about the minting\" but the current bitcoin system works against that goal! My argument is that the current minting system limits the utility of the currency largely because entirely too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive.
I think that's the issue you have though, you think it's inefficient and resource intensive on purpose when really it's not. No one is required to generate coins to use the system. If you click the generate coin list, you are basically volunteering your resources to strengthen the network and in exchange, you *might* get some coin for it. Since coin is in demand to use the system, someone has to generate it. If generation was as easy as \"input how many you want, *bam*, you have 1 million now\" it would make the entire system pointless. It's a chicken and the egg puzzle except there really isn't a puzzle here. People need bitcoins, they generate them at a fixed rate to make it worth spending the CPU time.
If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.
There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.
I have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.
If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.
There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.
I have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.
I think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.
In making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.
Again, an analysis of the behavior of self-interested actors is instructive. The most energy-efficient scenario for bitcoin generation in the current regime would be if there was ONE NETBOOK that generated all the coins - the rate of coin production is fixed, so you'd still have the same amount of coins entering circulation. The person who ran that netbook would obviously be in a position to charge a high \"rent\" from the population that needed bitcoins for their transactions. An examination of this limit case makes it clear that bitcoin minters have a strong incentive to encourage use and circulation of the currency while discouraging additional minting nodes from coming online. This is not any kind of criticism of anyone's ethics - it is simply an examination of how the game is set up, and what strategies players will adopt.
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.
There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.
I have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.
I think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.
In making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.
The computational and energy cost for generating bitcoins is quite irrelevant to the bitcoin economy since it does not compromise the integrity of bitcoins. People should be more concerned about a botnet trying to cheat rather than mine bitcoins.
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
Hear hear!
I though I tried to explain the lack of necessity, but people seem distracted by their repetition of mantras.
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
You seem to have things backwards.
The \"dice rolling\" is to maintain the \"chain of proof\".
Actually giving out the coins is a side effect.
I have 2 questions for you:
Without high computational burden how do you propose we:
a) Maintain the integrity of the system?
b) Distribute/Seed the system with coins?
I think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.
A botnet is a stolen computer already, the concern people have is that it will take over bitcoin in some way. What you are talking about is what we already know. They use the stolen CPU time to generate BTC and then sell it on the market. It's stolen CPU time, we have no control of that. What we do have control over is how much damage it can do to others that are running honest clients.
In making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.
The system was designed with that in mind. That's why it uses a formula that forces anyone that participates in the protocol to behave or else they are ignored. So if anyone is going to game the system, they have to do it by the rules that everyone else is following. Right now, the only rule to game is CPU time. It's either expensive, donated, or stolen.
Again, an analysis of the behavior of self-interested actors is instructive. The most energy-efficient scenario for bitcoin generation in the current regime would be if there was ONE NETBOOK that generated all the coins - the rate of coin production is fixed, so you'd still have the same amount of coins entering circulation. The person who ran that netbook would obviously be in a position to charge a high \"rent\" from the population that needed bitcoins for their transactions. An examination of this limit case makes it clear that bitcoin minters have a strong incentive to encourage use and circulation of the currency while discouraging additional minting nodes from coming online. This is not any kind of criticism of anyone's ethics - it is simply an examination of how the game is set up, and what strategies players will adopt.
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
That's the problem with having one PC generate all the coin, that one PC is a central authority of it and can price it anyway he/she likes. To de-centralize it means you need some way to force everyone to play by the rules or else one person will try to bend the rules.
I respect that you don't agree with how it works, so I offer up that we be shown a better way that we can't all punch holes in. It's open source software, if there is a better way, it can be used. Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".
Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".
You mean it is designed to \"trust no one\", not of \"trust everyone collectively\"?
Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".
You mean it is designed to \"trust no one\", not of \"trust everyone collectively\"?
Trust no one node, but if enough nodes are saying the same thing, then trust that.
Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".
You mean it is designed to \"trust no one\", not of \"trust everyone collectively\"?
Trust no one node, but if enough nodes are saying the same thing, then trust that.
This exchange is fascinating! At some sense it's just a matter of semantics, but it is very insightful semantics.
Logically I can support knightmb's statement \"trust everyone collectively\".
However kiba's statement \"trust no one\" is disprovable,
as is knightmb's statement \"Trust no one node, but if enough nodes are saying the same thing, then trust that.\"
The way the system works is every node attempts to receive every transaction, they each try to put every received transaction into a block at the same time. And while they are doing that, they each play the hashing game individually looking for fate to bless them with a match before it does anyone else.
So at any given point in time the system is really *trust (but validate) someone arbitrarily*. This happens when someone declares a block & hash \"solved\". All the other nodes check the block for self consistency, but they DON'T check the block's transactions for consistency with the transactions they themselves were working on. Nor do they check against the transactions other nodes received. So I see no support for the \"if enough nodes are saying the same thing, then trust that.\"
All nodes simply declare, \"I will trust this node's work as the next increment of bitcoin truth, because fate has blessed it.\" So it doesn't qualify as a \"trust no one\" system. Node's never say, \"Hey you fuck head! I have 5 known transactions you didn't bother to put in your block! You are a lying bastard.\" Everyone just presumes the missing transactions will be resubmitted and they'll end up in a subsequent block. This is heuristically plausible, but not absolutely deterministic. Everyone has to keep checking to make sure their transactions actually cleared the process.
So if knight's \"trust everyone collectively\" meant, \"trust in the process\" I find that insightful and a good motto. I'd probably add \"...but keep doing your own validation!\"
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
You seem to have things backwards.
The \"dice rolling\" is to maintain the \"chain of proof\".
Actually giving out the coins is a side effect.
I have 2 questions for you:
Without high computational burden how do you propose we:
a) Maintain the integrity of the system?
b) Distribute/Seed the system with coins?
I understand that the incredibly thermodynamic inefficiency I was complaining about is in fact very deliberate, and bitcoin might be said to waste as much energy as possible, as a security feature! Now I really don't know what to think - because exactly what I was complaining about gives the system its diabolical effectiveness. I think my earlier analogy with deliberately burning wheat and trading photographs of the ruined crops is very apt. We are all ceremonially burning computer cycles as an investment of resources in a \"trust pool\". The irreversibility of the process - the fact that we are burning our computational wheat crop just to crank out unusually numerically small hashes - is definitely perverse, and deliberately so. The entirely stupid amount of resources wasted minting bitcoins makes it nigh-impossible that anyone would choose to be EVEN STUPIDER as to waste the amount of resources necessary to outcompute you.
The problem is, if you look at the competition in the world of digital currencies - online casino currencies, mmorpg currencies, and the like - they often have much larger economies than bitcoin, with much less security, verifiability, and certainly much lower thermodynamic burden! The market, in the form of consumers, does not seem to demand a massive investment of random numbers to be willing to trade in a currency. I understand of course that the competition is generally centralized and that the thermodynamics of bitcoin are designed as a substitute for central authority - but I personally would regard a \"large enough\" network of nodes signing a transaction history using standard public key cryptography to be secure enough to use without demanding to see photographs of 500 billion bushels of burnt wheat as proof of the network's seriousness.
I see three additional replies written while I was typing this, so I'll try to refocus:
I understand the system, and appreciate its strengths. I am actually happy to participate in the bitcoin economy, sending coins around as tips for forum posts and the like is enjoyable as a \"game\" and the cost of entry is currently pretty low. My personal concern is not over botnets taking over with forged currency, but with botnets taking over the issuance of genuine coins. That is why I think the \"security through wasting energy\" concept is flawed - not because it isn't secure, but because it has the potential to create incentives for harmful behaviors, which in turn diminishes the likelihood of building social trust in the currency.
I see three additional replies written while I was typing this, so I'll try to refocus:
I understand the system, and appreciate its strengths. I am actually happy to participate in the bitcoin economy, sending coins around as tips for forum posts and the like is enjoyable as a \"game\" and the cost of entry is currently pretty low. My personal concern is not over botnets taking over with forged currency, but with botnets taking over the issuance of genuine coins. That is why I think the \"security through wasting energy\" concept is flawed - not because it isn't secure, but because it has the potential to create incentives for harmful behaviors, which in turn diminishes the likelihood of building social trust in the currency.
Ah I understand then, the answer is botnets can't forge currency because the swarm would not accept it. The only thing they can do is produce \"real\" currency at the expense of the stolen CPU time. Just like forcing slaves to mine gold will still net you real gold, just at no cost.
The only known *practical* attack to bitcoin from a botnet would be to have more CPU than the swarm at your command and to use that CPU power to double-speed currency. So while that could possible fall in into the \"forged currency\" category, it's not so much to make fake currency as it is spending valid currency twice before anyone notices.
I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency. Yeah, they're stealing the electricity and yeah, they're profiting, but at least they're putting their stolen CPU cycles to a useful and accepted purpose instead of more harmful activities that they probably would be engaged in if they had not discovered bitcoin.
",
"nested_level": 0
},
{
"id": 2126,
"thread_id": 167,
"source_id": "25",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg7938#msg7938",
"date": "2010-08-06T19:30:32Z",
"text": "I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency. Yeah, they're stealing the electricity and yeah, they're profiting, but at least they're putting their stolen CPU cycles to a useful and accepted purpose instead of more harmful activities that they probably would be engaged in if they had not discovered bitcoin.
Ok, bravo for an amazingly honest and straightforward answer. That is probably the most overall convincing argument I have seen made in the thread. You are arguing that the overall social utility of Bitcoin is \"worth it\" - worth both the raw energy cost of the computational work, and worth the regrettable fact that it provides a profit opportunity for botnet operators. I don't have a proposal for how exactly you measure the costs and benefits, but I entirely agree with your analysis of the bottom line of the situation. You could even make the argument that minting bitcoins as an activity is less harmful than other botnet activities like sending out spam.
You could even make the argument that minting bitcoins as an activity is less harmful than other botnet activities like sending out spam.
I think that he already did.
I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency.
Well said.
Participation in the network as an honest node helps everyone.
You are arguing that the overall social utility of Bitcoin is \"worth it\" - worth both the raw energy cost of the computational work, and worth the regrettable fact that it provides a profit opportunity for botnet operators.
I'd rather like to support a system like bitcoin, that i can use myself for value-transaction, than searching for E.T. to make some scientist save cash. That's a waste of energy and still people do it voluntarily without any benefits.
And i really dont care if some botnet-ops make a profit or not, as long as they don't bother ME (or anyone else).
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.
I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore,
not having Bitcoin would be the net waste.
As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.
Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it.
If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.
I suppose it might be possible to measure CPU power
at certain times. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.
Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
I say this half flippantly and half seriously. :-)
If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.
If I were you, I would have considered a mapping that included, \"For each entry into the bitcoin transaction recording/gold mining lottery, please send $10 to Satoshi.\"
That would discourage botnet operators from thousands of nodes. And if it didn't you would have tens of thousands of dollars! ;-)
I say this half flippantly and half seriously. :-)
If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.
If I were you, I would have considered a mapping that included, \"For each entry into the bitcoin transaction recording/gold mining lottery, please send $10 to Satoshi.\"
That would discourage botnet operators from thousands of nodes. And if it didn't you would have tens of thousands of dollars! ;-)
I can't imagine a more splintered network.
I can't imagine a more splintered network.
You laugh and I did too. But consider that the launch of bitcoin could have gone this way.
--------
Hi I'm Satoshi, you a are the 20 largest ISP's in the world. I'm launching a new network cash service. It will add significant value to your existing customer base and make you some additional revenue.
So here is the deal, In exchange for each of you running a bitcoin transaction verification peer and signing this contract, you will receive 1,000,000 BTC. You agree (in the contract) to distribute >= 500,000 BTC to your existing customer base in the first year. You may sell them, give them away to new subscribers or as a value add to promotions. Compete among yourselves, dispose of them anyway you want. Dispose of or keep the rest to dispose of in the future.
You also agree to run the transaction verification servers honestly for X years. Here is a free client you can pass out to your customers, you can give it away or charge them a service fee. Compete among yourselves.
Each of you pay me $100 for the privilege, you'll make that back the first day.
Thank you for your $2,000 good luck to you all!
Poof, now there is a functioning bitcoin network will all 21,000,000 coins in circulation. Satoshi gets to keep the last 1,000,000 BTC + he gets the $2,000.
Bitcoin builds on the reputation of the 20 largest ISP's and is adopted immediately. 20 trusted nodes can reach consensus quickly so there is no reason for the hashing game or new minting rewards.
----
I don't think that is too pie in the sky for some of the clever salesmen I know to pull off.
I can't imagine a more splintered network.
You laugh and I did too. But consider that the launch of bitcoin could have gone this way.
--------
Hi I'm Satoshi, you a are the 20 largest ISP's in the world. I'm launching a new network cash service. It will add significant value to your existing customer base and make you some additional revenue.
So here is the deal, In exchange for each of you running a bitcoin transaction verification peer and signing this contract, you will receive 1,000,000 BTC. You agree (in the contract) to distribute >= 500,000 BTC to your existing customer base in the first year. You may sell them, give them away to new subscribers or as a value add to promotions. Compete among yourselves, dispose of them anyway you want. Dispose of or keep the rest to dispose of in the future.
You also agree to run the transaction verification servers honestly for X years. Here is a free client you can pass out to your customers, you can give it away or charge them a service fee. Compete among yourselves.
Each of you pay me $100 for the privilege, you'll make that back the first day.
Thank you for your $2,000 good luck to you all!
Poof, now there is a functioning bitcoin network will all 21,000,000 coins in circulation. Satoshi gets to keep the last 1,000,000 BTC + he gets the $2,000.
Bitcoin builds on the reputation of the 20 largest ISP's and is adopted immediately. 20 trusted nodes can reach consensus quickly so there is no reason for the hashing game or new minting rewards.
----
I don't think that is too pie in the sky for some of the clever salesmen I know to pull off.
You would then have to rely on \"for profit\" companies to be the central authority for the new currency and how long would it take to generate the full chain even at a difficulty of 1.00?
I'm not opposed to for profit companies. Nor am I opposed to your for profit venture. Eventhough you have a huge advantage by learning about bitcoin before most people.
My point was, if you have only twenty-one nodes validating transactions you don't need the block list at all. There are easier ways of reaching consensus with a smaller pool of peers.
",
"nested_level": 0
},
{
"id": 2136,
"thread_id": 167,
"source_id": "35",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg8165#msg8165",
"date": "2010-08-07T22:43:17Z",
"text": "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. I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.
[...]
Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.
Thanks very much for your reply. I agree with your analysis, and this thread has actually changed my mind as to my initial criticism. After more careful study of the design of the Bitcoin network and trying to understand the exact manner in which Bitcoin attempts to create value from the computational work invested, I am now inclined to think that bitcoin is in fact high EFFICIENT rather than inefficient. My thinking now is that bitcoin does not, in fact \"waste\" computational work at all - instead it works hard to deliver the most value possible from that computational work. Something like a governnment issued fiat currency may not have any obvious energy burden beyond its printing - but in fact, maintaining the value of a fiat currency requires a substantial investment in maintaining police enforcement, a legal system, and national defense. In comparison to the energy cost of hiring police officers to enforce economic honesty, the energy costs of investing cpu cycles in guaranteeing that honesty mathematically seem very small!
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.
I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.
I agree with nearly everything you said, but I disagree, fundamentally, with the bolded. Gold mining is not a waste of energy. It is the opposite of waste, it is the measure of value people place in the 'utility of having gold as a medium of exchange' or a store of wealth, jewelry around their body parts or connectors on their home theater system. If there was no demand for gold, the price would be zero. Hence it is not a 'waste,' by definition.
I object strenuously to this idea, promulgated by the Monetarists, that the production of money is wasted capital which could be spent on other wealth-building projects. It's a short-sighted argument which does not fully encompass the value we place in our money.
It's semantics, yes, but the negative connotations associated with the word \"waste\" is a tool of the money masters designed to confuse us and elevate their bankrupt system.
Ta,
I really I understood the point of this thread but I guess I didn't.
I assumed that if you could design to do the exact same thing in the same commodity quantities and at the same protection level, BUT consuming less energy and producing less BTUs of heat, then that would be less wasteful.
You can mine gold in lots of ways, some require less resources than others. If two processes produce the same amount of gold then no point in optimizing anything else?
",
"nested_level": 0
},
{
"id": 2139,
"thread_id": 167,
"source_id": "38",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg8394#msg8394",
"date": "2010-08-09T19:12:09Z",
"text": "The power used is not wasteful. It is simply what the owner is willing to commit to the project. Even so, it may be used even as \"waste heat\". I am an electritian by trade, and years ago I had the following idea form, while installing a 'heat trace' network on insulated sprinkler lines inside an open air parking garage.
The 'heat trace' is a fairly expensive cable that has a continuous resistive core to produce low intensity electric heat along the length of the pipe that it's taped onto. Insulation is then wrapped around this assembly. The best, and most efficient, systems have a temp reactive core; so that the closer to the freezing point that the cable itself becomes at any given length, the lower the resistance across the core becomes, resulting in an increase in heat output along the colder and less well insulated sections.
At the time, I was playing with an early form of distributed computing called \"Condor\", which allowed single processes to be exported to other computers upon a network and their disk I/O shipped back across the network to a master server without the process being able to tell the difference. I thought then that a small \"computer on a chip\" wired upon a flat network cable would be able to effectively perform the same functions of keeping the pipes above freezing with local temp sensitivity while also crunching numbers in exactly the same way that bitcoin requires. Such an idea would require a network that permited quite a bit of power in order to not need an unacceptable number of power points along the pipe, but imagine the usefulness of such a system for companies that have such needs in very high (or very low) latitudes.
What if such a system were retrofitted onto the Alaskan Oil Pipeline, for example, one mile at a time?
",
"nested_level": 0
},
{
"id": 2140,
"satoshi_id": 337,
"thread_id": 167,
"source_id": "39",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin minting is thermodynamically perverse",
"url": "https://bitcointalk.org/index.php?topic=721.msg8431#msg8431",
"date": "2010-08-09T21:28:39Z",
"text": "The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer.
If you have other cheaper heating than electric, then the waste is only the difference in cost.
If it's summer and you're using A/C, then it's twice.
Bitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free.
",
"nested_level": 0
},
{
"id": 2141,
"thread_id": 168,
"source_id": "1",
"poster_name": "mkrogh",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=696",
"subject": "latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7797#msg7797",
"date": "2010-08-06T07:05:56Z",
"text": "Hi bitcoin users
I found bitcoin yesterday, and I am really impressed by the idea of avoiding issuers/banks in a digital cash system.
However, I have one objection that I would like your view on.
That is the latency, or delay in a local transaction. Let us say that a payer and payee are located in the same city for example. I will claim, that they want a payment to go through
with a delay not much slower than the latency of network connections. With an issuer and using local coins (a prefix, say, can be used to localize a server of the issuer), the transaction should be done and verified in 100 microseconds or less. With a global p2p network, it is necessary to have all nodes receive the transaction, do some calculations and send results back.
It is not feasible, with the speed of light as an upper limit, to do this faster than a second. As I understand it you actually use something like 10 minutes for one block, or even more for several block verifications. This means that verification of the absence of double spending is 10,000 or even tens of millions times too slow. This would get even worse in interplanetary trade of course.
The ideal payment system should be decentralized but also local, i.e., the verification of a local transaction must not have to wait for a light signal to travel to the other end of the \"universe\" and come back again.
Locality, in the sense describe here, is crucial, I will claim.
Sincerely,
Morten Krogh.
",
"nested_level": 0
},
{
"id": 2142,
"thread_id": 168,
"source_id": "2",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7801#msg7801",
"date": "2010-08-06T07:35:55Z",
"text": "Why is it crucial?
One system doesn't have to be used for all needs. If interstellar money is needed people will choose whatever is best for that, same if people need their money in less than a second.
",
"nested_level": 0
},
{
"id": 2143,
"thread_id": 168,
"source_id": "3",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7806#msg7806",
"date": "2010-08-06T08:04:38Z",
"text": "It is not feasible, with the speed of light as an upper limit, to do this faster than a second. As I understand it you actually use something like 10 minutes for one block, or even more for several block verifications. This means that verification of the absence of double spending is 10,000 or even tens of millions times too slow. This would get even worse in interplanetary trade of course.
It depends on your network layout. If you are using the entire public network, then yes you are depending on that time for the data to be processed by everyone else that is running a node. But, you don't have to do it that way. You can build a trusted node (like a server) and have your clients direct connect to it and let it do the fast verification for you.
It won't net you 20 confirmations in a few milliseconds, but it will help stop double-spending as long as you remain in control of that node because it knows what is being spent. The whole double-spending issue arises from trust. When you are comparing anonymous seller to anonymous buyer, the only \"middle man\" for trust is the entire swarm (hence confirmations that neither is cheating)
If you know you can trust your own node(s), then it reduces the likely-hood that double-spending will occur within your own trusted network. So if your example applied to an ATM like card for example, the bank (or whoever) would have all of those ATM machines networked to their own private node (or server) which would then further connect to the outside (Internet) for the rest of the transactions. So if you went to an ATM, withdrew 100 BTC (say the entire account only had that much), then moments later went to another ATM elsewhere and tried to withdraw that amount again, somewhere along that trusted chain would spot a double-spend attempt and basically report back no BTC left for that address.
The whole verification process is how you put the swarm to work, all those clients are examining if your transaction was valid or not, but you don't have to wait for them to transfer the coin around. You can spend the coin around in circles all day without a single transaction verification. It's only when double-spending occurs does the network correct for itself and fix the balances.
Banks already have this exact same problem. They all have their own networks that connect to other bank networks and it's just as easy to double-spend on their ATM as has been demonstrated at black-hat hacker conventions for probably 10+ years now. I remember reading about the issue back in 1997 because a lot of networks will still on dial-up then for banks and the latency issue was part of the attack because everyone had their own *database* that all had to inter-connect.
With bitcoin, everyone is the database and banker and guard at the same time, so while it's not perfect, it's actually a lot better than what banks are using. Have you ever noticed at an ATM they have about 20 \"network\" stickers for all the different banks and setups that the ATM has to be compatible with?
FreeMoney, I think it is crucial to have fast local transactions. It is needed for many businesses and person to person payments.
10 minutes or even 10 seconds is too slow. An extraterrestrial system was just an extreme example.
The most pressing problem, as I see it, is to get a digital cash system that makes it possible for people and small businesses to pay each other fast and without
registration and supervision from a big company/government.
I read the thread about vending machines. There were no real solutions except companies that would monitor for double checking in a few seconds. I agree that would be possible,
but we would lose the whole point of not having an issuer. This company needs to be trusted, it will break anonymity, and people need an account with that company.
What is wrong with the follwing \"standard\" system. A central bank/government issues a currency like today. It sets up servers around the world to validate transactions.
People pay each other by means of a single verification with one of the centeal bank's servers. The speed issue is solved by coins having the location of the relevant server embedded in them. In worst case, the server would need to make long round trips to other severs, but in most cases the first server would know the answer already. The cental bank could have an algorithm for distributing coins around the network to optimise latency and server load. The wallet would have an algorithm for choosing the most local coins when making a payment.
The wallet could also prepare by exchanging coins with the server. On your way to Europe, the wallet replaces \"American coins\" with European coins, such that payments will be fast in Europe. For the user, this is incredibly easy. It is anonymous, and it requires no agreements with any processing companies.
Also, there could be many issuers of the same currency if so desired.
Bitcoin gets rid of the issuers, but instead introduces unacceptable slowness or a lot of middlemen like credit card companies/debit accounts etc. Satoshi's solution, on the vending machine thread, with a double spending checking company is still too slow, even though faster than a block, and this company needs an omnipresence on the network almost like
an issuer.
But discarding speed, bitcoin seems extremely elegant. And of course there are uses for this kind of system. One could imagine many local bitcoin systems with an exchange between
different currencies. That would work except that an attacker can take over a small currency.
",
"nested_level": 0
},
{
"id": 2146,
"thread_id": 168,
"source_id": "6",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7843#msg7843",
"date": "2010-08-06T12:50:12Z",
"text": "The most pressing problem, as I see it, is to get a digital cash system that makes it possible for people and small businesses to pay each other fast and without
registration and supervision from a big company/government.
...
What is wrong with the follwing \"standard\" system. A central bank/government issues a currency like today. It sets up servers around the world to validate transactions.
So the solution to avoiding a big company/government regulation is a big company/government?
It is currently possible with Bitcoin to do transactions which are practically instant particularly if you do not fear some vast conspiracy to defraud you.
If you really do have need of transactions faster than Bitcoin can offer, use a different system, but you will probably have to forgo some of the benefits that Bitcoin currently offers.
No, my goal is not to avoid government involvement in the payment system, but to not have the government monitor every transaction. There is a difference.
The current bill/coin system works like that. The government/central bank issues the currency but they don't monitor individual cash payments.
I think that is okay.
You claim that is possible to make almost instantaneous payments with bitcoin. How? That is what I thought everybody agreed upon was not possible. You need to wait for
one or more blocks to be solved before you can trust a coin. That takes minutes. Even in the best case it is limited by propagation, with the speed of light, around the network which is slow. The only solution is to create another banking system on top of this. Bitcoin then becomes the backbone of an intebank transfer system, not what the population at large is using.
It is not just me that needs fast transactions. There is giant demand for fast transfers of digital cash from cell phone to cell phone, web shopping, stock trading etc.
But, we might just have different expectations from a digital cash system.
Has anyone ever stated clearly what problem bitcoin is solving? It seems to solve the problem of payments that don't need to be fast. But who are the potential users of that beyond people who thinks it is theoretically interesting like people on this board.
Do people agree with me on this point: We still need another digital cash system, and that probably needs to be issuer based.
",
"nested_level": 0
},
{
"id": 2148,
"thread_id": 168,
"source_id": "8",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7855#msg7855",
"date": "2010-08-06T14:30:50Z",
"text": "No, my goal is not to avoid government involvement in the payment system, but to not have the government monitor every transaction. There is a difference.
The current bill/coin system works like that. The government/central bank issues the currency but they don't monitor individual cash payments.
I think that is okay.
Every transaction
is monitored in the bitcoin system.
You claim that is possible to make almost instantaneous payments with bitcoin. How? That is what I thought everybody agreed upon was not possible. You need to wait for
one or more blocks to be solved before you can trust a coin.
That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.
And people are going to shop with those who will give them speedy transactions.
That takes minutes. Even in the best case it is limited by propagation, with the speed of light, around the network which is slow. The only solution is to create another banking system on top of this. Bitcoin then becomes the backbone of an intebank transfer system, not what the population at large is using.
It is not just me that needs fast transactions. There is giant demand for fast transfers of digital cash from cell phone to cell phone, web shopping, stock trading etc.
But, we might just have different expectations from a digital cash system.
Clearly.
Has anyone ever stated clearly what problem bitcoin is solving? It seems to solve the problem of payments that don't need to be fast. But who are the potential users of that beyond people who thinks it is theoretically interesting like people on this board.
Anyone who currently uses PayPal for a start.
Do people agree with me on this point: We still need another digital cash system, and that probably needs to be issuer based.
I don't. But I'm just one person.
Every transaction is monitored in the bitcoin system.
But you can make it anonymous. Why are you bringing this up?This is a point, were I thought we agreed.
When I said monitoring, I meant including identification of the payer and payee.
That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.
And people are going to shop with those who will give them speedy transactions.
Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.
Anyone who currently uses PayPal for a start.
Most of those will prefer a fast issuer based system over a slow decentralized system, I will claim.
But they might prefer bitcoin over paypal.
Every transaction is monitored in the bitcoin system.
But you can make it anonymous. Why are you bringing this up?This is a point, were I thought we agreed.
When I said monitoring, I meant including identification of the payer and payee.
Ok, when you said monitoring I thought you meant monitoring, so I was just pointing out that all the transactions were trackable in case you did not already understand this. Since it seems you do it's not a problem
That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.
And people are going to shop with those who will give them speedy transactions.
Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.
Anyone who currently uses PayPal for a start.
Most of those will prefer a fast issuer based system over a slow decentralized system, I will claim.
But they might prefer bitcoin over paypal.
It seems we have differing opinions on the way future will develop. Which is fine.
It'll probably turn out nothing like either of us expect anyway.
Yes, it might turn out very differently. No digital cash for the masses for instance. A giant banking cartel that bribes politicians to keep the current system.
",
"nested_level": 0
},
{
"id": 2152,
"thread_id": 168,
"source_id": "12",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7908#msg7908",
"date": "2010-08-06T17:33:30Z",
"text": "mkrogh: Yes, you are correct.
There is absolutely no requirement for there to be such latency in the bitcoin system. Nothing fundamental would change if the system were implemented with a block list that updated every 10 seconds, instead of every 10 minutes. It was just a design decision that could be changed without effecting monetary policy a bit.
In fact, there is no requirement their be a block list that updates in increments at all. The system would work fine if each transaction were validated one-by-one. In effect one transaction per block. That was a design decision to make networked consensus building easier.
However, when you say \"local transaction validation\" what you are grasping for is a truly distributed system, rather than a monolithic system made redundant. The current version of bitcoin is the latter. Each node does exactly the same work as every other node. Each redundantly checking every transaction. It is a system horribly wasteful of resources. And because it is so wasteful, generates latency as a waste product.
Bitcoin could be made into a truly distributed system by storing the transaction graph in a distributed hash table. This is the kind of magic that is behind most other P2P systems. In effect, each bitcoin address would be arbitrarily mapped to a smaller set of nodes that checked its transactions. In such a system, there is no need to broadcast global state to every machine. This takes huge amount of latency out without needing to change any of the desired behavior.
",
"nested_level": 0
},
{
"id": 2153,
"thread_id": 168,
"source_id": "13",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7915#msg7915",
"date": "2010-08-06T17:45:32Z",
"text": "
Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.
Did you know about this? You don't need to wait for it to get in a block to have way better certainty than PP or checks.
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 a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%
So if a double-spend has to wait even a second, it has a huge disadvantage.
The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.
FreeMoney, yes I knew about that.
Red, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated. That must be coin
dependent because of double spending. So, if I understand, it must be possible, for any transaction, to choose which location the resulting coin should be validated in when that
coin is used next time. A random choice would not be good enough. But, are there some problems with an attacker taking over a certain location. The global system had the strength that an attacker would be outworked by the sum of all other CPUs.
Red, can you elaborate more on such a distributed version of bitcoin. Is it described anywhere?
Cheers.
",
"nested_level": 0
},
{
"id": 2155,
"thread_id": 168,
"source_id": "15",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7940#msg7940",
"date": "2010-08-06T19:36:12Z",
"text": "Bitcoin could be made into a truly distributed system by storing the transaction graph in a distributed hash table. This is the kind of magic that is behind most other P2P systems. In effect, each bitcoin address would be arbitrarily mapped to a smaller set of nodes that checked its transactions. In such a system, there is no need to broadcast global state to every machine. This takes huge amount of latency out without needing to change any of the desired behavior.
Interesting idea.
So, lets see, I create a transaction to pay you (say) 100 of my newly minted bitcoins.
That'll be a transaction with two 50BTC TxIns (signed by me, pointing to two mature GENERATE transactions somewhere in the block chain) and one 100BTC TxOuts.
You want to make sure I haven't double-spent those TxIns, so instead of flooding the network with that transaction you find the hash of the two GENERATE transactions and send two queries down into the DHT network: \"Hey, here's a transaction, tell me if it is valid.\" They say \"yup\", and then... what? Include it in any blocks they're lucky enough to generate? Broadcast it to everybody (which'd be no better than the current scheme) or some subset of the DHT network (what subset?)?
How do you know that you won't get a different answer to \"is this transaction valid\" if you ask again in 10 minutes when the network topology might have changed?
I don't know much about DHT networks and how they manage to keep reliable information when nodes may be coming and going (or buggy or malicious). How would it work?
Red, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated.
I think that you are getting lost in the choice of wording on this list. Every bitcoin client, whether or not it is 'generating' or not, has a very recent copy of the entire block chain, and can check any new transactions against that block chain to see if those bitcoins were owned by the *address* that the other client claims he owns, at least up until the last block update. I'm not saying local verification is implimented in the current client, but it's possible. But that doesn't protect you from a concurrent double spend. The distributed verification will add confidence in the validity of the transaction with each passing block, but it's not neccessary to perform a transfer. Cash in person has similar problems, as the vendor can never be *certain* that the customer isn't passing off counterfit currency. The risks of fraud are included in the costs of retail business, and if speed of transactions are paramount, the vendor can simply accept the results of his own client and take the risks that he might get burned. Waiting for confirmation would help protect against fraud, but it's not a *requirement* for completion of a trade. I would expect that smartphone clients would do this quick local verify by default, particularly when communicating with each other directly over ad-hoc wireless.
Also, the system doesn't even require that the receiving client be on the network at the time of the transfer. You can send money to any address at any time, and their client could find out about it long after the transfer had been verified by the bitcoin network.
Just agree to both use the same free online wallet before you make your trade. MyBitcoin.com offers instant transfers.
",
"nested_level": 0
},
{
"id": 2158,
"thread_id": 168,
"source_id": "18",
"poster_name": "mkrogh",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=696",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7982#msg7982",
"date": "2010-08-06T21:38:46Z",
"text": "creighto, I am only talking about verifying the absence of double spending. Of course, you can always receive a coin and just hope. That is clear.
I don't think that physical coins have this issue. Or gold. Firstly counterfeiting is really difficult, secondly \"bill verifiers or gold verifiers\" are local machines. If someone could
counterfeit gold or coins in a way that no local machine could detect, then it would be the same. But no one can do that.
With bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it. I don't understand what red exactly is proposing.
NewLibertyStandard, your suggestion is a bank, that the payer and the payee need an account with. I don't mind, but I don't think it is an answer to the issue of this thread.
What I see as the ideal solution has these properties.
1. You can participate by just having some software on your computer/phone.
2. The coins are stored by yourself. A coin is a string of characters, no physical gold or so is involved. Encryption keys are fine if you can generate them yourself.
3. No accounts or registrations with banks or governments are needed.
4. Payments can be totally verified including double spending checks. Tiny probabilites can be ignored. But I mean tiny, not just reasonably small.
5. If a person is traveling to a city, he (she) can prepare for the visit by exchanging coins. This exchange can be slow. After arriving to the city, the person can make fast payments
to a person residing in that city. By fast payments, I mean payments that are completely validated in a time frame that does not depend on the total size of the coin system. In other words local trade should be possible, even if the digital cash system is used all over the world (or galaxy). The preparation before arrival is important here. Of course, many coins can not be verified, fast, against double spending by the payee, but there should exist some coins that can, given the location. And the payer can prepare before arrival by getting such coins.
6. No issuer on whose honesty the system relies.
1-5 is possible with an issuer. The coins have a tag that denotes where double spending will be verified. The issuer keeps the information about those coins on their servers in that location. In other words, the issuer's distributed hash table follows some rules for what coins are stored where. And those rules are publicly available.
1,2,3,4,6 seems to be bitcoin if I understand correctly.
Does 1-6 exist. Is that what red is saying?
",
"nested_level": 0
},
{
"id": 2159,
"thread_id": 168,
"source_id": "19",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7986#msg7986",
"date": "2010-08-06T21:56:38Z",
"text": "In real life, bank wires take much much longer than ten minutes. Most traditional services which you see as instantaneous are actually not instantaneous. Credit card charges don't go through immediately, the funds are just reserved immediately and the retailer trusts the credit card company. Not to mention that charges can be challenged, which means the final transaction could take weeks. Real bitcoin transactions occur much more quickly than real traditional electronic money transfers. If you need instant transfers, then you just have to set up the same tricks which the traditional electronic currency market uses, and that is basically what I suggested.
",
"nested_level": 0
},
{
"id": 2160,
"thread_id": 168,
"source_id": "20",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg7995#msg7995",
"date": "2010-08-06T22:27:03Z",
"text": "creighto, I am only talking about verifying the absence of double spending. Of course, you can always receive a coin and just hope. That is clear.
There is more to it than just hoping. For starters, you could already have an existing business relationship, and trust built between two parties due to honest prior trading.
I don't think that physical coins have this issue. Or gold. Firstly counterfeiting is really difficult, secondly \"bill verifiers or gold verifiers\" are local machines. If someone could
counterfeit gold or coins in a way that no local machine could detect, then it would be the same. But no one can do that.
Counterfeiting bitcoins is really difficult as well, and that is what a local blockchain check would protect you against. It would also protect you against a double spend that wasn't concurrent, as if one guy backs up his wallet file and then spends his coins the night before and attempts to yank your chain. It does not protect you against a professional criminal, but against the petty attempt.
[/quote]
With bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it.
[/quote]
I know from other threads that Red has a different understanding than I about how the system works. Either or both of us could be wrong. My understanding is that, at present, the clients attempt to announce a transfer and then wait for the collective to confirm the transfer via accepting the claim as valid in at least two blocks, after which point the network believes that you have valid bitcoins, therefore you do.
However, two clients can interact directly, in theory.
Imagine this picture...
You have a full client on your Iphone running in the background, and then there is a power failure. You head down to the corner store, and find that the shopkeeper has put everything in the cooler on sale half price, cash or bitcoins only. Your cellphone client connects with the shopkeeper's cell phone client over ad-hoc bluetooth. Signs the transfer accouncement (there are no actual cryptocoins in your wallet, they exist only as a series of entries into an encrypted ledger we call the blockchain, more like writing a check than actual coins) over to the shopkeeper's address. Shopkeeper's client can then (but does not have to) check his copy of the blockchain to verify that you actually owned said bitcoins at the time of his last blockchain update. If it's good locally, he can assume that you are not trying to cheat him and accept the trade and you leave with your half priced milk. This does not protect the shopkeeper from an intentional double spend, but you still had to have honestly owned the coins at one time in order to do this. If you did not own the coins at the time the power went out, his client would have rejected the transfer.
This also means that the shopkeeper can only spend bitcoins that he had at the time of the power failure himself, since any new bitcoins that he receives will not yet be included in the blockchains of any other vendor, and any attempts by his client to transfer his unannounced coins will be rejected by the other clients. All transfers will either be verified or rejected by the network within 30 minutes of network reconnection.
What I'm suggesting doesn't exist yet. There was related talk about similar issues on the thermodynamic perversity of generating blocks. If I have just one central node, the system could generate a transaction block in a fraction of a second. If you wanted, it could do this only once every ten minutes. But it wouldn't need any more than a fraction of a second of CPU time on a single processor.
The reason is purely related to consensus.
So if you had two nodes, you could have them both redundantly capture all transactions, and then in a fraction of a second each could generate a block. They could then exchange block hashes and if they matched, they would have consensus. If they didn't match you could reach consensus in one of two ways. 1) compare the transactions of each block one by one, and create a block consisting of the union of all transactions. or 2) Just pick one of the blocks and go with it. The second is what bitcoin actually does now.
It just picks using the worlds most expensive coin flipper. You could accomplish the same task with a much cheaper coin flipper and nothing in bitcoin would change one bit.
That is what I mean by \"design decision\" a it doesn't change any of the requirements for the system's features or behavior. It just implements things differently.
----
So when I talk about distributing the transaction graph throughout a distributed hash table it is just a different possible (but currently non-coded) way of implementing bitcoin's key feature. The feature of verifying the transfer of bitcoins from one address to another, in a way that makes it impossible to double spend coins.
Optimally, if you had x,000 transactions per minute and 100 nodes, each node would only have to do 1/100th of the work of a single node handling x,000 transactions per minute. Each transaction is only required to be recorded once.
However, with the current bitcoin implementation, if you have 100 nodes, they all run at 100% cpu for x,000 transactions. If you add another 100 nodes, they all still run at 100% cpu but do exactly the same job. We used to call it \"government work\" when you could do a job with 5 guys, but instead they used 50 guys, because more people working is better for the economy!
So the new design constraint I'm proposing, is that for a given number of nodes (n), it should take (Order (1/n)) or maybe (Order log(n)) work per cpu to handle a given number of transactions. In this case work means CPU time and network communication. My design modifications FAIL if they give up any of the transaction protections of the existing system.
----
It turns out that the block list itself is not required to validate transactions. Only the transactions are required. So to understand what I'm suggesting you have to think about an equivalent bitcoin implementation without a monolithic block list containing every transaction in the history of the system.
Instead, the transactions are redundantly scattered across all the nodes. No node need keep a complete list off all transactions, but they must be able to quickly retrieve any transaction on demand. Optimally in Order(1) time, but Order(log(n) time would probably suffice. That reduces the storage requirements of any given node to Order(1/n).
Transactions are mapped to nodes by transaction out-points. You generate two unique out-point identifiers by hashing the transaction+out-point information. You then store the transaction redundantly on the five \"closest nodes\" to each out-point ID. That means for a system with 10,000 nodes. Each transaction is stored with 10X redundancy instead of 10,000X redundancy. (the 10X was an arbitrary choice, the redundancy would be based upon the DHT algorithm and characteristics of the node population.)
Now each of those 10 nodes holds that out-point data completely privately, unless another node can show a \"need to know\". In this case a need to know is demonstrated by submitting a signed transaction that includes a given out-point as an in-point. In this case the storage node stores the new transaction. It also returns any known transactions referencing that out-point. If there is a previous transaction in-point associated with the out-point the second transaction is a double spend.
So for any new transaction, to verify it, you send it to the five closest nodes to each in-point on the transaction. They record the transaction and immediately tell you if they've seen a double spend. If any have, it's a bogus transaction, which gets broadcast to the other close nodes.
Now the what I'm suggesting also increases anonymity because you no longer have to broadcast every transaction you make to the world. Also random individuals can't go poking around in your business.
There are many ways to map bitcoin transactions to DHTs. I just chose an example that would be easy to explain. There may be other possibilities offer improvement. But this one is sufficient to get the point across.
There is also a fun technology called a \"dining cryptographers network\" that could further improve some of the anonymity aspects of bitcoin.
",
"nested_level": 0
},
{
"id": 2162,
"thread_id": 168,
"source_id": "22",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: latency and locality",
"url": "https://bitcointalk.org/index.php?topic=723.msg8013#msg8013",
"date": "2010-08-06T23:32:05Z",
"text": "So for any new transaction, to verify it, you send it to the five closest nodes to each in-point on the transaction. They record the transaction and immediately tell you if they've seen a double spend. If any have, it's a bogus transaction, which gets broadcast to the other close nodes.
What happens when they disagree about which transaction happened first? Majority rule? Who decides what the majority is, and can it change if 4 of the five nodes leave the network and are replaced by another 5 nodes?
And if I know that I'm going to create a large transaction, can I do some work precomputing node IDs such that the transaction (which I haven't yet sent out) will hash to nodes that I control? If I control all the nodes storing the transaction, then I can just answer \"yes, absolutely, that transaction is valid and hasn't been double-spent...\"
The brilliant insight behind bitcoin is the distributed timestamping mechanism; everybody agrees on an order of transactions. I don't see how your scheme solves that problem.
Imagine this picture...
You have a full client on your Iphone running in the background, and then there is a power failure. You head down to the corner store, and find that the shopkeeper has put everything in the cooler on sale half price, cash or bitcoins only. Your cellphone client connects with the shopkeeper's cell phone client over ad-hoc bluetooth. Signs the transfer accouncement (there are no actual cryptocoins in your wallet, they exist only as a series of entries into an encrypted ledger we call the blockchain, more like writing a check than actual coins) over to the shopkeeper's address. Shopkeeper's client can then (but does not have to) check his copy of the blockchain to verify that you actually owned said bitcoins at the time of his last blockchain update. If it's good locally, he can assume that you are not trying to cheat him and accept the trade and you leave with your half priced milk. This does not protect the shopkeeper from an intentional double spend, but you still had to have honestly owned the coins at one time in order to do this. If you did not own the coins at the time the power went out, his client would have rejected the transfer.
There was another point here that I intended to make.
As with the example above, most cash transactions are not actually anonymous, but psuedo-anonymous. For example, one party can be well established (the shopkeeper) while the other is mostly anonymous, (the bargain hunter in the above example) but even the buyer is not truely anonymous. He has been in the shop many times before, and even if the shopkeeper doesn't know his name, he has seen his face enough times to recognize it. So there is some trust that, since he is a local or regular customer, that he is not some pro trying to sting him with an opprotunistic scam.
Another example of a psuedo-anonymous transaction is the kind that both parties are anonymous to the world, but not to each other. This is actually how *most* cash transactions work in the real world; but online it could go like this...
You want to get something, let's say, unusual. You find this guy on, say, Tor with a hidden website selling your wanted commodity. He is known to you only as, \"pothead420\" on the website. You have no other way to contact him, and no means of finding out who is actually is. You don't trust this guy, but someone is going to have to take a leap of faith, and that someone is likely going to be you. So at first, you order small. After a few succesful trades, your trust grows that \"pothead420\" is an honest dealer; so your orders grow larger. He could screw you over at any time without recourse, but then he would be cutting off a regular customer, so he has an incentive to continue to treat you properly.
A third kind of pseudo-anonymous trust relationship could be found on this very forum that depends on reputation. Most of us do not use our real names, but some of us do. We assume that the member who uses the name of the bitcoin programmer is the actual programmer, and have some evidence to support this, but we cannot know for sure. But, as far as this forum is concerned, he has a reputation. So if you were to do direct business with him, and screw him, his word that you are not trustworthly would harm any business that you desired to conduct in the future, solely because he has a longer reputation than any newcomer.
All of these examples involve some kind of two party trust, but not one requires both parties trust a third. Not even the verification of the blockchain.
All of these examples involve some kind of two party trust, but not one requires both parties trust a third. Not even the verification of the blockchain.
Trusted third parties are very useful when trading with someone you don't trust. One person trusts the trading administrator enough to deposit bitcoins and the other person trusts a payment processor such as Liberty Reserve or Pecunix to provide proof to the trading administrator that the payment occurred and he trust the trading site administrator that he'll accept proof of payment. Both traders have to trust the trading site and the payment processor, both third parties, but they don't need to trust each other.
If you look for reasons to dismiss the idea out of hand, you will find them. However if you use the example to increase your understanding of why some P2P systems succeed yet many more fail, it will give you some insight.
In that spirit, let me answer your questions directly.
What happens when they disagree about which transaction happened first? Majority rule? Who decides what the majority is, and can it change if 4 of the five nodes leave the network and are replaced by another 5 nodes?
If ANY other transaction using that out-point is found there is a double spend, same rules as the current bitcoin system. The only way there can be disagreement is conflicting transactions got broadcast simultaneously but one arrived a close node A first and the conflicting one arrived at close node E first. By the end of the two 5 node broadcasts, both parties would discover the double spend.
So which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins. Distributed coin flipping algorithms are trivial. All of this can be done almost immediately. Much faster than in 10 minute windows. So no, the majority doesn't change if 4 nodes leave, because consensus was reached and the nodes were made consistent.
By the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join.
And if I know that I'm going to create a large transaction, can I do some work precomputing node IDs such that the transaction (which I haven't yet sent out) will hash to nodes that I control? If I control all the nodes storing the transaction, then I can just answer \"yes, absolutely, that transaction is valid and hasn't been double-spent...\"
No, this would be a requirement constraint. It is possible for the same reason that it is impossible to generate two public keys that match to the same bitcoin address. See my previous faux pas.
Nodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible. All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out.
The brilliant insight behind bitcoin is the distributed timestamping mechanism; everybody agrees on an order of transactions. I don't see how your scheme solves that problem.
It actually solves the problem in exactly the same way, just with much less CPU power.
The brilliant insight behind bitcoin's distributed time stamping mechanism is you don't need absolute timestamps at all! You only need relative order. And for conflicts in a short window, you don't have to care at all. You can simply arbitrarily choose one.
My solution does exactly the same thing. It maintains relative order among transactions. It arbitrarily reaches consensus on conflicts. Neither method has a requirement to accurately order unrelated transactions by time. Again, that was a brilliant insight.
So which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins.
Now I'm confused again. I thought your scheme didn't have blocks, just transactions. What do you mean, whoever solves \"the block\" first?
By the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join.
But standard DHTs are typically used to store chunks of MP3s or movies, indexed by a torrent file that has the hash for every piece. So it is easy for me to tell whether or not I'm getting bad data from any particular DHT node. I don't have to trust them.
Nodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible.
Huh? Lets say the network has 10,000 nodes in it. I query the network to find the network node closest to a transaction that I want to double-spend.
So I generate a private key. It has about a 1 in 10,000 chance of being closer than the current closest node. So I keep generating private keys until I have 5 that are closer. It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5. My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000.
I create 5 nodes with those keys (telling the rest of the network \"honest, folks, I chose those keys RANDOMLY...\") and I've won.
All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out.
I'm not trying to generate a transaction with a particular hash, I'm trying to generate node ids that are \"closer\" to that transaction's hash than any other node currently on the network. That's much easier.
All of these examples involve some kind of two party trust, but not one requires both parties trust a third. Not even the verification of the blockchain.
Trusted third parties are very useful when trading with someone you don't trust.
Yes, but I was pointing out that waiting for verification is not usually neccessary in common usage of the currency. It's the unknowns that call for waiting for verification or the use of a trusted third party.
So most everyday transactions, either online or IRL, can be performed with faith instantly, or with the additional confidence of the local client verification almost instantly. The 10 minute lag isn't really a detriment.
Now I'm confused again. I thought your scheme didn't have blocks, just transactions. What do you mean, whoever solves \"the block\" first?
My scheme doesn't have blocks. I was referring here to how the existing system operates.
Huh? Lets say the network has 10,000 nodes in it. I query the network to find the network node closest to a transaction that I want to double-spend.
So I generate a private key. It has about a 1 in 10,000 chance of being closer than the current closest node. So I keep generating private keys until I have 5 that are closer. It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5. My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000.
I create 5 nodes with those keys (telling the rest of the network \"honest, folks, I chose those keys RANDOMLY...\") and I've won.
I'm trying to generate node ids that are \"closer\" to that transaction's hash than any other node currently on the network. That's much easier.
Yes, It's much easier!
You've made a quite plausible argument for this particular case. Kudos!
I'm not going to do the math either because that is really not the point. I'm not proposing \"The solution\". I'm suggesting that the amount of compute resources doesn't need to scale so badly to satisfy bitcoin's requirements. I'm only trying to show that there are other reasonable designs that can meet bitcoin's requirements with significantly lower CPU usage, and in the case of this thread less latency.
I think with the brain-trust that is this forum, any limitations in a distributed solution are easily discovered and rectified. Just as is being done with the current implementation. Perhaps I chose a poor way to create a node ID. Freenet proposes an entirely different way of shared generation of node IDs. It doesn't suffer from the issues you point out. Perhaps it has other issues in this situation. But I'm confident there exist a distributed implementation that would work.
Is the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction?
(100,000 was Satoshi's number of expected core nodes for a system that supported millions of users)
Is the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction?
No, not at all. Like I said when I jumped into this thread, I think using a DHT network to somehow distribute the work is a very interesting idea, it just seems to me any solution that partitions the network will be more vulnerable to attacks that insert malicious nodes. I think it would be fantastic to come up with less resource-intensive solution that actually works.
How does Freenet generate node IDs? The only info I see in the latest Freenet paper is:
When joining, nodes choose an identity at random, and then connect to those peers with whom they have a pre-established trusted relationship.
.... and:
The perhaps largest advantage that the trusted-connection model offers over traditional anonymity networks is protection against the Sybil attack [13], where a single attacker infiltrates the network by pretending to have many identities. Since the network depends on out of band trust relationships, an attacker gains strength only through the number of people he can fool into trusting him, and gains nothing by presenting multiple identities online.
...which doesn't sound like it would work very well for Bitcoin.
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?
",
"nested_level": 0
},
{
"id": 2171,
"satoshi_id": 329,
"thread_id": 169,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Escrow",
"url": "https://bitcointalk.org/index.php?topic=750.msg8140#msg8140",
"date": "2010-08-07T20:13:52Z",
"text": "Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.
The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.
While this system does not guarantee the parties against loss, it takes the profit out of cheating.
If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.
The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.
Now, an economist would say that a fraudulent seller could start negotiating, such as \"release the money and I'll give you half of it back\", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.
",
"nested_level": 0
},
{
"id": 2172,
"thread_id": 169,
"source_id": "2",
"poster_name": "Tilka",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=687",
"subject": "Re: Escrow",
"url": "https://bitcointalk.org/index.php?topic=750.msg8147#msg8147",
"date": "2010-08-07T21:23:28Z",
"text": "Cryptography at its finest
Could you explain how this would work on a technical basis?
Buyer not having recourse except burning the money will limit the utility, I think.
",
"nested_level": 0
},
{
"id": 2174,
"thread_id": 169,
"source_id": "4",
"poster_name": "aceat64",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=430",
"subject": "Re: Escrow",
"url": "https://bitcointalk.org/index.php?topic=750.msg8189#msg8189",
"date": "2010-08-08T02:55:59Z",
"text": "Buyer not having recourse except burning the money will limit the utility, I think.
Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously you'd want to choose a trustworthy arbitrator).
Buyer not having recourse except burning the money will limit the utility, I think.
Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously you'd want to choose a trustworthy arbitrator).
That's how online escrow operates today. Buyer and seller agree to let a 3rd party physically hold the money. Buyer and seller both agree to rules that the neutral 3rd party will follow, for transaction resolution / redemption. The neutral third party is the one who disburses funds to one party or the other.
This is a pretty decent overview:
https://www.escrow.com/solutions/escrow/process.aspSome people might choose to use the bitcoin-specific signed escrow method... but I think the \"burn the money\" recourse serves as a incentive to
avoid bitcoin escrow entirely, rather than an incentive to use bitcoin escrow honestly.
I like Olipro's suggestion is this thread:
http://bitcointalk.org/index.php?topic=645.0The buyer and seller both an equal amount of bitcoins into escrow and the seller can't retrieve both sets until the buyer signs off on it. Optionally if both parties agree the funds are returned to their original owners or both sets are transfered to an agreed upon arbitrator. I deviate from his suggestion that the arbitrator only have control over the buyers half, I think they should have control of both so that both parties still have a bitcoin stake in the issue.
The Satoshi solution is good, because if customer can take money back, it will be a big problem to sellers. See current situation with internet credit card payments and chargebacks. Chargebacks are major PITA for sellers, bitcoin must avoid that at all cost
The Satoshi solution is good, because if customer can take money back, it will be a big problem to sellers. See current situation with internet credit card payments and chargebacks. Chargebacks are major PITA for sellers, bitcoin must avoid that at all cost
Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
Regardless of what the technical options are, I think that an escrow will always need to be, by definition, a trusted entity. I can see the automated workflow being easy enough when things go well:
- Buyer sends btc to escrow, stating the recipient address
- Seller sees btc in escrow, marked to send to his address
- Buyer can release funds to seller
- Escrow will automatically do so after x days
- Both parties can open a complaint
And that's all I would automate. When things go bad, both parties should have a fee to pay to the escrow (that fee may be paid in advance to open account there?) so everyone looses something. Then the escrow will just have to mediate.
Because there's a fee *and* a human intermediary, the chances of successful fraud will probably not be economically interesting in the long run. Someone already trusted would make the ideal person for this, and maybe for a small fee some of us 'common guys' could help assert allegations from either side, if we are local to them.
But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
",
"nested_level": 0
},
{
"id": 2180,
"satoshi_id": 340,
"thread_id": 169,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Escrow",
"url": "https://bitcointalk.org/index.php?topic=750.msg8649#msg8649",
"date": "2010-08-11T01:30:02Z",
"text": "Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.
When you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that.
Either party always has the option to release it to the other.
But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
Then you must also be against the common system of payment up front, where the customer loses.
Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn't get the money either.
Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?
Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.
It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about \"money burning\" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.
I was starting to wonder when my systems seemed to quit generating coins if there was something going on. They went from about 1 block / day to none in a week.
ArtForz in irc suggested I run a test isolated net with two nodes only connected to each other with empty wallet dir. I took a couple of quad core systems and set them up. they have produced no blocks in about 90 minutes now while hashing at a combined rate of over 8000 khash/sec. Is this evidence of a problem yet or is it more bad luck?
The systems are Linux 64 bit one Intel quad q6600 and one AMD quad phenom II 940.
",
"nested_level": 0
},
{
"id": 2182,
"thread_id": 170,
"source_id": "2",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8193#msg8193",
"date": "2010-08-08T03:09:03Z",
"text": "The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.
",
"nested_level": 0
},
{
"id": 2183,
"thread_id": 170,
"source_id": "3",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8194#msg8194",
"date": "2010-08-08T03:13:09Z",
"text": "The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.
This is on an isolated test net with just two machines, connections = 1, difficulty = 1
The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.
maybe only a problem with 64 bit linux or something
I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.
",
"nested_level": 0
},
{
"id": 2186,
"thread_id": 170,
"source_id": "6",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8199#msg8199",
"date": "2010-08-08T03:38:21Z",
"text": "The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.
This is on an isolated test net with just two machines, connections = 1, difficulty = 1
Oh, that is odd then, that would be like not finding one in over 500 hours, possible I guess, but getting out there
I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.
I guess I want to know how long I need to run 8000 khash/s at difficulty 1.0 to have any reasonable evidence of a problem. ArtForz said it should tell me in an hour or so.
At ~ 8Mhash/s combined not generating a block at 1.0 diff in over 1h is pretty unlikely.
As in, under 0.1% probability unlikely (50% is ~6 min, 1% ~42 min)
<edit>
Forgot to mention, he's running a custom compile of stock 0.3.8 sources.
",
"nested_level": 0
},
{
"id": 2189,
"thread_id": 170,
"source_id": "9",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8205#msg8205",
"date": "2010-08-08T03:58:09Z",
"text": "I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.
I am wondering if its something odd in the way I have my systems set up or
just various plain ubuntu installs so far as I know.
I'm having a similar problem with my own compile of the SVN trunk. I just reverted to the stock builds to test and see what happens. I should try setting up my own network of two nodes with my builds.
",
"nested_level": 0
},
{
"id": 2191,
"thread_id": 170,
"source_id": "11",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8218#msg8218",
"date": "2010-08-08T07:18:55Z",
"text": "Ok chatting with lachesis in irc he tried this and I get the same result: We added some prints in main.cpp at the SHA calls like so :
loop
{
SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);
printf(\"mid hash =\n\");
for (int i = 0; i < 8; i++)
printf(\" %08x\", ((unsigned *)&tmp.hash1)[i]);
printf(\"\n\");
SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);
printf(\"full hash =\n\");
for (int i = 0; i < 8; i++)
printf(\" %08x\", ((unsigned *)&hash)[i]);
printf(\"\n\");
if (((unsigned short*)&hash)[14] == 0)
and then in the log we get:
mid hash =
6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
full hash =
6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
mid hash =
6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
full hash =
6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19
repeating! The hash call isn't doing anything!
(he maybe got a different repeating value, I don't know)
There is one behavior that I've noticed.
Block sync stalling.
When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block. The problem is, if you stop and restart the client, it just picks up where it left off on the same stuck block. The only way I've seen to fix this is to delete the block chain so that the client will re-download it.
I've had to clear out a few block chains for a few servers because of this, I'll notice they are stuck on block 70,000 for example, while the rest of the network is working on block 70,839 for example.
That might explain why you go weeks without winning a block with a 24/7 PC going.
The server farm I had running before were spitting out blocks all day, but now that I'm just down to a few dozen servers and the difficulty is way up, I barely see about 3 or 4 blocks a day spread across all of them. But I know the 0.3.8 version is working like it should, except for the occasional block freeze.
",
"nested_level": 0
},
{
"id": 2193,
"thread_id": 170,
"source_id": "13",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8226#msg8226",
"date": "2010-08-08T10:32:32Z",
"text": "This seems to be a different problem. The blocks do not seem to be \"stuck\" on my systems. The getinfo shows them up to date
It seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others.
There is one behavior that I've noticed.
Block sync stalling.
When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.
...
Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
",
"nested_level": 0
},
{
"id": 2195,
"thread_id": 170,
"source_id": "15",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8233#msg8233",
"date": "2010-08-08T13:13:30Z",
"text": "Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.
That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.
That appears to fix it for me too.
EDIT:
I've uploaded corrected Linux builds to
http://www.alloscomp.com/bitcoin/binaries/release-r123-2010-08-08/. Enjoy!
Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.
I just tested it out, I get the same results. Repeating values with stock, more random values with the flag modification. Probably needs to be fixed for the next release, though I'm not sure how mine are generating anything then?
@lachesis: 404 not found
@knightmb: What about a fixed CentOS build?
",
"nested_level": 0
},
{
"id": 2199,
"thread_id": 170,
"source_id": "19",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8246#msg8246",
"date": "2010-08-08T17:56:09Z",
"text": "@lachesis: 404 not found
@knightmb: What about a fixed CentOS build?
Should be simple enough for CentOS, I was going to test it out first to see if those suffered the same issue, thought it seems like all the builds would suffer this issue if the compile flag is what makes the difference.
This seems to be a different problem. The blocks do not seem to be \"stuck\" on my systems. The getinfo shows them up to date
It seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others.
There is one behavior that I've noticed.
Block sync stalling.
When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.
...
I'm starting to wonder if the two are connected now since the hashing seems to get stuck, maybe that's why it gets stuck on a block.
After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what's being produced, it's the 64bit Linux machines (the 64bit windows machines don't appear to have this problem) that aren't producing any coin since the latest releases. All of the 32bit builds (stock or custom) appear to be just fine.
",
"nested_level": 0
},
{
"id": 2202,
"thread_id": 170,
"source_id": "22",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8257#msg8257",
"date": "2010-08-08T18:32:27Z",
"text": "Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
This works for the 64bit builds, strange that it has no affect on the 32bit builds? Should it be disabled for 32bit builds as well?
I don't really know what it changes. I wonder why the define was made in the first place. The code should be able to determine whether it's running on a SSE2 CPU or not. I discovered it while comparing my 4xSSE2 hash function to the original one in 0.3.6 so it really means, that no 64bit build since 0.3.6 was able to generate any coins. Maybe satoshi can tell us why he put the define in the makefile.
",
"nested_level": 0
},
{
"id": 2204,
"thread_id": 170,
"source_id": "24",
"poster_name": "ArtForz",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=584",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8306#msg8306",
"date": "2010-08-09T00:31:45Z",
"text": "Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
",
"nested_level": 0
},
{
"id": 2205,
"thread_id": 170,
"source_id": "25",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8309#msg8309",
"date": "2010-08-09T01:16:31Z",
"text": "Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Not on 64bit linux, just 32bit and 64bit everything else in between (Linux/Windows)
I didn't notice until I checked the generation dates against the release dates of the software.
If you don't strip the debug symbols the binary is 8 times it's normal size.
Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Nice work mate! Time to PM Satoshi.
Sent you \u0e3f5.01 for your troubles.
The 32 bit Linux build seems ok for those who don't care to try to build it themselves. It's only a few percent slower than the 64 when built right.
I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
",
"nested_level": 0
},
{
"id": 2208,
"thread_id": 170,
"source_id": "28",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8369#msg8369",
"date": "2010-08-09T15:45:39Z",
"text": "I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Yet another argument for cmake or similar.
I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility. I was trying to take the safer option.
It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place.
Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
",
"nested_level": 0
},
{
"id": 2210,
"thread_id": 170,
"source_id": "30",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: bitcoin generation broken in 0.3.8?",
"url": "https://bitcointalk.org/index.php?topic=753.msg8389#msg8389",
"date": "2010-08-09T19:02:12Z",
"text": "I found that SSE2 only added a slight speedup, about 2%, which didn't seem worth the incompatibility.
I do the see point because a non-SSE2 machine, the client would crash?
It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place.
Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn't work for some reason.
I think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).
Have one branch of source that cross-compiles across multiple operating systems is always tricky business.
Yet another argument for cmake or similar.
It's a
fact.
I intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.
On that note, I'm currently tackling x64 build for windows and notice that for 64-bit MSVC, the X86_SHA256_HashBlocks function is deferred to an external definition that is not present in the project. In the original CryptoPP library it seems to be in a separate asm module. I wonder how are people building x64 on windows, are they setting defines to use the C-source sha version?
Or will it suddenly die then?
",
"nested_level": 0
},
{
"id": 2214,
"thread_id": 171,
"source_id": "2",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8354#msg8354",
"date": "2010-08-09T12:34:56Z",
"text": "As far as I can read C++, Bitcoin implementation stores timestamps as unsigned integers
and block timestamp is a part of binary block format, of which a hash is computed.
Since blocks are chained and the previous block is referenced in the current by it's hash,
you cannot simply recompile the client with 64bit timestamps.
You will need to recompute the whole chain, is that an option?
Or we need to propose some transition plan to another binary block format.
Or, I am wrong and everybody should relax.
What do you think?
",
"nested_level": 0
},
{
"id": 2215,
"thread_id": 171,
"source_id": "3",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8356#msg8356",
"date": "2010-08-09T12:43:49Z",
"text": "I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks.
",
"nested_level": 0
},
{
"id": 2216,
"thread_id": 171,
"source_id": "4",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8360#msg8360",
"date": "2010-08-09T13:30:25Z",
"text": "I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks.
Great.
Everybody, how do you think, is it time to bother on implementing that plan or we should wait for something to happen?
Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.
",
"nested_level": 0
},
{
"id": 2218,
"thread_id": 171,
"source_id": "6",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8379#msg8379",
"date": "2010-08-09T17:39:03Z",
"text": "Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.
main.cpp: unsigned int nTime;
in the block headers. Thats 32 bits if you don't know.
It seems to be a crazy mix...
CWalletKey(main.h): 64-bit
Rest of main.h, including in-memory block/txn objects: 32-bit
Internal main.cpp calculations: 64-bit
Network(version): 64-bit
Network(addr): 32-bit
Network(getblock): 32-bit
Network(submitorder): 32-bit
At a minimum, there are plenty of 32-bit time variables that clearly need changing to 64-bit.
",
"nested_level": 0
},
{
"id": 2220,
"thread_id": 171,
"source_id": "8",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8409#msg8409",
"date": "2010-08-09T19:58:09Z",
"text": "I'm not a programmer, but I have doubts that any of those 32 bit variables are subject to rolling over antime near 2038. My understanding, however limited it may be, is that the timestamp of the blockchain is relative only to it's position within the chain, and not subject to any such limitations. I'm sure that the two week difficulty calculations require an accurate count of seconds, but at worst, that would just throw off the calculations for the two weeks around the rollover in 2038. And since there is a limit to just how much the difficulty may change in any two week period, even that isn't particularly crucial.
",
"nested_level": 0
},
{
"id": 2221,
"thread_id": 171,
"source_id": "9",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: What could be the transition plan to Y2038 compliant Bitcoin?",
"url": "https://bitcointalk.org/index.php?topic=760.msg8412#msg8412",
"date": "2010-08-09T20:12:02Z",
"text": "The problem with the time stamps, is a unix time stamp as a 32 bit integer WILL overflow in 2038. I am a programmer, but you can find more info on it by googling unix time problem or 2038
I understand the Y2038 problem from a layman's perspective. My point was that, I doubted that a Y2038 problem exists within the structure of bitcoin. Since the timestamp is relative only to a particular position within the blockchain, there is no reason that a client should require an accurate timestamp within the block. And then, what would that be? GMT? I'm pretty sure that my client is doing fine with local time. If that could be getting any successful blocks rejected, let me know, please.
unsigned int is good until 2106. Surely the network will have to be totally revamped at least once by then.
There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.
",
"nested_level": 0
},
{
"id": 2223,
"satoshi_id": 332,
"thread_id": 172,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8402#msg8402",
"date": "2010-08-09T19:46:58Z",
"text": "When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on SourceForge with the 64-bit binary updated.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/downloadFuture versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem?
The difficulty has gotten high enough that I wouldn't worry about dropping block generation support for old computers if it's hard to maintain compatibility. But the client should definitely provide some feedback explaining why the feature isn't available. Perhaps you could make a message pop up that explains why generating bitcoins is not supported on old hardware.
",
"nested_level": 0
},
{
"id": 2225,
"thread_id": 172,
"source_id": "3",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8421#msg8421",
"date": "2010-08-09T20:46:14Z",
"text": "
IMO, SSE should be required for generation, not simply to run the client.
",
"nested_level": 0
},
{
"id": 2226,
"satoshi_id": 335,
"thread_id": 172,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8422#msg8422",
"date": "2010-08-09T20:55:06Z",
"text": "That's a good point, I believe you could run with generation off if you don't have SSE2.
How about add to the top of cryptopp/config.h:
#if !defined(_M_X64) && !defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2 1
#endif
that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC)
",
"nested_level": 0
},
{
"id": 2227,
"thread_id": 172,
"source_id": "5",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8423#msg8423",
"date": "2010-08-09T20:57:02Z",
"text": "From what I understand, removing the offending define is required only for 64-bit builds and 64-bit architectures are already guaranteed to support SSE2 instructions. 32-bit builds can retain the flag and thus continue to disable SSE2 instructions and remain compatible with older computers.
",
"nested_level": 0
},
{
"id": 2228,
"thread_id": 172,
"source_id": "6",
"poster_name": "dkaparis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=192",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8425#msg8425",
"date": "2010-08-09T21:02:49Z",
"text": "That's a good point, I believe you could run with generation off if you don't have SSE2.
How about add to the top of cryptopp/config.h:
#if !defined(_M_X64) && !defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2 1
#endif
that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC)
Yes, but better have that specified in the makefile. That way anyone who doesn't care for old CPU's can compile with SSE2 support by removing the flag, without fiddling with the source.
I can also add a CMake property for that in the CMake build.
From what I understand, removing the offending define is required only for 64-bit builds and 64-bit architectures are already guaranteed to support SSE2 instructions. 32-bit builds can retain the flag and thus continue to disable SSE2 instructions and remain compatible with older computers.
Older CPU that don't support SSE2 shouldn't be excluded from coin generation in my opinion. They can still serve a vital role in block generation; I have many machines that don't support the SSE2 enhancements, but still generate blocks all the time, even if they are only churning 300-400 khash/s
I'm still running an old node without SSE2 @600khash/s. The algorithm works so I don't see why we should make SSE2 a requirement.
",
"nested_level": 0
},
{
"id": 2231,
"thread_id": 172,
"source_id": "9",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8461#msg8461",
"date": "2010-08-10T02:45:47Z",
"text": "My impression of the difficulty was based on my broken client, haha! I've already generated a block tonight for the first time in such a long time. Having older computers generate coins doesn't seem as futile as it did earlier today. If you can keep the compatibility intact, I think it would be well worth it.
",
"nested_level": 0
},
{
"id": 2232,
"thread_id": 172,
"source_id": "10",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8464#msg8464",
"date": "2010-08-10T03:38:23Z",
"text": "Hah! This sure helps explain a long-standing mystery.. why my 10,000 khash/sec Linux 64-bit machine is the only one that has never, in two weeks, generated a block.
Just to confirm -- this fix is in SVN 125?
",
"nested_level": 0
},
{
"id": 2234,
"thread_id": 172,
"source_id": "12",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8485#msg8485",
"date": "2010-08-10T06:18:28Z",
"text": "Hah! This sure helps explain a long-standing mystery.. why my 10,000 khash/sec Linux 64-bit machine is the only one that has never, in two weeks, generated a block.
You're not the only one. I haven't generated in over a month.
Fix is in svn r124, r125 added -maxconnections.
",
"nested_level": 0
},
{
"id": 2236,
"satoshi_id": 338,
"thread_id": 172,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.8.1 update for Linux 64-bit",
"url": "https://bitcointalk.org/index.php?topic=765.msg8628#msg8628",
"date": "2010-08-10T23:46:00Z",
"text": "SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC. Other compilers might have different 64-bit defines.
",
"nested_level": 0
},
{
"id": 2237,
"satoshi_id": 336,
"thread_id": 173,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Connection limits",
"url": "https://bitcointalk.org/index.php?topic=766.msg8424#msg8424",
"date": "2010-08-09T20:58:45Z",
"text": "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 unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.
I haven't really tested -maxconnections much, could someone test it?
",
"nested_level": 0
},
{
"id": 2238,
"thread_id": 174,
"source_id": "1",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8477#msg8477",
"date": "2010-08-10T05:45:45Z",
"text": "As some might have noticed, one of the things that bugs me about bitcoin is that the entire history of transactions is completely public. I totally understand the benefits of how this simplifies things and makes it easy for everyone to prove coins are valid.
So this is not a suggestion for a change to bitcoin. Rather it is a question about what could be possible, and what couldn't be possible.
The general question is, could the block list be/have been implemented in a way that didn't store the full transactions in the list? Specifically, *perhaps* it would be possible to store only hashes of the in-points, out-points in the block list. These would be time stamped (notarized) in the blocklist exactly as is being done now.
The major difference is that it would be the coin receiver's responsibility to store the full transaction. And perhaps he might have to store previous transactions (X) deep to show history.
Then when he wanted to transfer the coins to the next party, he would create a transaction exactly as is being done now, except he would have to submit the antecedents to the transaction for validation as well. For validation, each antecedent of the in-points would be hashed and validated as existing in the block list. The in-points would be hashed and identified in the blocklist as not yet spent. Then the transaction would be validated as is currently done.
If everything validated correctly, the additional in/out-point hashes would be added to the block. This closes the transaction's in-points, and marks the new out-point hashes as unspent.
Once a node completes the block (by winning the hashing contest), he then broadcasts the block of hashes and the related transactions+plus antecedents to the other nodes for confirmation and acceptance.
as a rough example:
{block-9
hash-a, hash-b, hash-c, hash-x
}
{block-12
hash-a, hash-y, hash-c, hash-d
}
{block-17
hash-b, hash-d, hash-e, hash-z, hash-f
}
{Transaction
{in-points: hash-x, hash-y, hash-z}
{address, signature and other transactions stuff}
{out-points: hash-payed, hash-change
}
{generating-block
hash-x, hash-y, hash-z, hash-payed, hash-change
}
So basically, if the i/o-point hash existed twice in the block list, it has been spent. If it exists only once it has not been spent.
So in after block-17:
a, b, c & d are spent.
e, f, x, y, z are unspent.
The transaction spends x, y & z and creates hash-payed & hash-change, so the transaction is valid.
After the generating-block:
a, b, c, d, x, y, & z are spent.
e, f, payed, change are unspent.
====
The Goal:
The goal is to provide all the same security of the existing system, but to avoid creating a public graph of every transaction that is easily correlated. In this case, the hashes don't even have to associate in the block. The block could simply sort all hashes in ascending order.
In effect, I want to create real gold coins. I can give my coins to you, but everyone in the world doesn't know I did. You can give them to the next guy and prove they are pure gold coins, because you have the pedigree of the coins AND every generation in the pedigree was notarized in the public record.
====
The Question:
Satoshi showed that you can remove transactions from the block list through the Merkle tree structure, without compromising security. I guess my real question is:
\"What is the earliest you can remove the transactions?\"
You could argue that nodes could remember everything anyway (the web never forgets). But if you structured the protocol so that new nodes would only receive a block list of hashes, they could only remember from this moment forward. That would give a little additional privacy. (Maybe)
====
Any thoughts? Is there an obvious way that people could cheat and get rich?
",
"nested_level": 0
},
{
"id": 2239,
"thread_id": 174,
"source_id": "2",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8504#msg8504",
"date": "2010-08-10T09:34:14Z",
"text": "
In your system, Rather than just getting transactions from the block chain I just have to watch every transaction (which I'll see anyway) and log them to my secret server.
You're just advocating security through obscurity.
",
"nested_level": 0
},
{
"id": 2240,
"thread_id": 174,
"source_id": "3",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8509#msg8509",
"date": "2010-08-10T10:28:59Z",
"text": "By the way, doesn't the idea of
the coin receiver's responsibility to store the full transaction. And perhaps he might have to store previous transactions (X) deep to show history.
make the limitation on the minimal value of transaction redundant?
Thus making micropayments use case more feasible.
You're just advocating security through obscurity.
I did mention that. I wouldn't count on this for monetary security. I would like the system to be equivalent to the current one.
However, privacy obscurity is known to add value. Your neighbors, or the FBI could me watching everything you do all day long. But they probably aren't. If you happen to become \"of interest\", sure they could start watching you now and from this time forward.
But the most asked for additional legal powers seems to be, \"let me examine everyone's logs!\" (phone calls, cell towers, email connections, facebook connections, credit/debit card transactions, Google history, browser history.) The other systems are \"security though authority.\" Bitcoin doesn't have that.
====
By the way, I'd rather not broadcast every transaction to every node either. But that is for another thread.
By the way, this is the way most digital notary services work. You send them a hash of a signed document and they log it permanently. Then they create a hash chain like bitcoin does. They periodically publish the current hash chain value in a newspaper or other offline redundant record.
You don't have to send your private documents/transaction to the notary for them to be time stamped and recorded. The notary is just certifying that something that matched this hash existed at this point in time.
",
"nested_level": 0
},
{
"id": 2243,
"thread_id": 174,
"source_id": "6",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8542#msg8542",
"date": "2010-08-10T15:06:16Z",
"text": "By the way, this is the way most digital notary services work. You send them a hash of a signed document and they log it permanently. Then they create a hash chain like bitcoin does. They periodically publish the current hash chain value in a newspaper or other offline redundant record.
You don't have to send your private documents/transaction to the notary for them to be time stamped and recorded. The notary is just certifying that something that matched this hash existed at this point in time.
You also don't have to prove to the notary that you have X BTC in your account to spend.
Although I was recently reading about
Zero-knowledge proofs if you could use something like that to prove that your account had X BTC in it without revealing anything else it might be what you're looking for.
I'm just worried what you want is theoretically impossible.
Interesting idea to revisit! Thanks. Hadn't thought of them in a while.
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 could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?
It's hard to think of how to apply zero-knowledge-proofs in this case.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
",
"nested_level": 0
},
{
"id": 2246,
"thread_id": 174,
"source_id": "9",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8681#msg8681",
"date": "2010-08-11T04:58:50Z",
"text": "Satoshi: I know you know the first part of what I'm writing, but I want others to be able to follow and for you to correct any misconceptions I might have.
I was looking at the current Merkle tree implementation trying to figure out when transactions could be removed without losing security.
In transaction graph terms, the transactions represent the nodes. The edges of the transaction graph are represented by the in-points which point to previous transactions using a BlockHash->TransHash->OutPoint kind of structure. It is the existence of an in-point that marks a previous out-point spent.
So for a transaction to be valid, you most show for every in-point in a transaction that BOTH, a previous out-point exists AND no previous in-point exists that references that out-point. So for every out-point, there are zero or one in-points referring to it. zero = unspent. one = spent.
That also means that no transaction can be culled from the block list, until both its out-points are spent. Otherwise coins will disappear.
You can however, delete all double-bound transactions as soon as you are confident the 2nd binding block will stick around. (earliest possibility)
However, as you delete transactions and replace them with their tree hashes, you lose the graph structure present in the block list. In effect, all transactions undeleted from the block list have unspent value purely because they still exist. They can no longer prove validity by ancestry since that part of the graph was culled.
Which got me thinking, is there a way to prove validity if you never put the whole transactions into the graph to begin with?
The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?
The key is to hash the transaction information as part of the out-point hash. So instead of creating a single transaction hash, you represent the transaction as two out-point hashes. (I originally considered an in-point/transaction/out-point structure using hashes, but that proved unnecessary.)
Only transaction validators need to know the bitcoin address associated with a recorded out-point hash. That comes from the submitted antecedent transaction for an in-point of the current transaction. The antecedent transaction and out-point is hashed and presumed BOTH valid and unspent if that hash appears one-and-only-one time in the block list.
The current transaction must be signed by the key for the address in the antecedent transactions of course. If this proves valid, two new out-point hashes are generated and inserted in the current block. The in-point hashes are marked spent by including them in the current block as well. (If a hash exists twice it is spent.) If you want to represent the transaction as a unit (and the currently visible transaction graph), the in-point hashes and out-point hashes could be grouped. However, this is not strictly necessary to prove validity.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
In this case we are trying to prove the presence of ONE matching hash and the absence of TWO matching hashes. It does require knowing all of them to prove.
I think the prohibitions against double spending are as strong as in the current version.
==== CAUTION! ====
However, you have to consider the case where a node causes mischief by deliberate adding random \"canceling hashes\". In this case, the node wouldn't be able to gain access to the coins, as he has no signed transaction hashing to a valid unspent out-point hash. However, the current owner wouldn't be able to spend the coins either. The in-point would be presumed already spent.
That means the validation conditions are EXACTLY THE SAME as with the current implementation. All validating nodes must examine and validate all transactions represented in a block before accepting it and building on it.
If there exist any hashes in the proposed block that are not represented by valid transactions, the block must be rejected.
That is exactly the same as the current system's, if any transaction doesn't validate, the block must be rejected.
I had hoped the condition to pass all transactions to all validators could be weakened but I can't see how (yet) without relying on trusted delegation.
----------
An interesting feature is that this simplifies the validation process. All that needs to be done is to parse the block list (of hashes) once. As each hash is parsed you simply look it up in a hash-set. If it doesn't exist you add it. If it does exist you delete it. When you are done parsing the block list, you will have the minimal set of valid and unspent out-points. You might even be able to keep the whole set in memory. (at least for a while!)
It's hard to think of how to apply zero-knowledge-proofs in this case.
It's hard for me too! :-) Was interesting to re-read though!
Was hoping it would spawn some insight on a way for nodes to demonstrate that they \"always follow\" the block generating rules, in absence of everyone needing to have the set of all transactions to double check.
It didn't. :-)
Still thinking this idea through...
The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.
If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:
- the value
- the association of inpoints and outpoints in one transaction
The network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.
I believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment.
The fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
",
"nested_level": 0
},
{
"id": 2249,
"thread_id": 174,
"source_id": "12",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Not a suggestion",
"url": "https://bitcointalk.org/index.php?topic=770.msg8824#msg8824",
"date": "2010-08-12T01:10:19Z",
"text": "Still thinking this idea through...
It's a bit of a brain twisting idea isn't it. :-)
It turns out the notion of a cancelable notarization generalizes nicely.
For example this system is not limited to bitcoin transactions. Since the signed contracts are kept externally, with additional validation/notarization rules, you could easily implement things like IOUs/claim checks.
If someone gave you $5, you could give him a $5 IOU. Its IOU hash would be notarized into the blocks list (of hashes). When you pay them back you could have them sign the IOU for confirmation. Then have the notary insert an IOU hash cancellation. Then no one could show back up with a copy of the IOU and demand double payment.
I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit.
I thought this too at first. But then I convinced myself otherwise.
It is really a matter of how much trust you place in the verifiers and the process of verification. People like the warm fuzzys that having every transaction available lets them trace the roots of their money back to its creation. However that is not required.
If you are confident in the process that validated the transactions during block creation (> 50% CPU agreement). And if you are confident the previous blocks can't be changed (you proved this). Then you only need to check that related out-points have not been spent. The security features remain in the block list and procedure, even if the transactions themselves are stored externally and the predecessors are not stored at all. You showed this yourself by proving old transactions can be deleted using the Merkle tree to maintain consistency.
Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.
True, privacy is directly related to observability. If there is a central party like a money changer, he can relate a lot of out-points. But if we get away from the notion that every coin must be traced back to creation, the observation horizons will be much closer.
----
It's really weird getting used to the notion that this coin is valid simply because the process wouldn't let it be included otherwise. But really, that is exactly how bitcoin generation works. The transaction has no inputs, but everyone decides the out-point must be valid purely because otherwise, it wouldn't be in the block at all. :-)
I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit.
I thought this too at first. But then I convinced myself otherwise.
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 for them, so the clients would have to keep the history all the way back.
If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.
But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think.
I thought this too at first. But then I convinced myself otherwise.
Are you back to talking about the existing Bitcoin system here?
Yes, I am talking about the hypothetical system.
The way I proposed the system, each time a block gets generated every validating node must accept or reject that block by validating the transactions and confirming the hashes in the block. In effect, the same work that is being done with the current system, plus the out-point hash checks. Since the other validators were already competing to generate the block, they already have (at least most of) the transactions.
As with the current system, if the transactions don't validate (plus match included out-point hashes) the other nodes will reject the block. If the block doesn't get acceptance by at least 50% of the CPU power, it doesn't make the block list.
So the presence of the hashes in the block list, signifies that at least 50% of the existing validators at that time saw and validated all the containing transactions and out-point hashes.
Therefore (barring hash crashes) if someone submits an antecedent transaction that matches an unspent out-point, it must be valid.
That antecedent's antecedent must have been valid as well, otherwise the antecedent would have been rejected. And so on and so on.
For that not to be the case, you have to postulate that there was a period in time where blocks weren't being validated against out-point hashes. But that's plausibly implausible with the CPU competition system.
If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.
If a client joined the network recently, it did so presuming that prior validators followed the rules and all pre-existing blocks are valid. (No one would join a known corrupt network)
Sure, in the current system, if transactions were never purged, a new node could validate all prior blocks for self consistency. But they still couldn't prove absolute truth. A bot net could have taken over and erased some transactions leaving \"a new truth\" and unhappy users. Equivalent to case 1) above.
In the current system, if transactions were Merkle tree purged then you have case 2) above. New comers must trust in the process. Anything missing, they don't need to worry about. Everyone must presume it was valid.
The unique thing I'm saying is that, if you have confidence in the bitcoin validation competition process (and we do!), then you really don't need \"a 2) thoroughly deep block\" to be very deep at all. Someone said in another thread that clients reject any changes to blocks more than two hours old. So we can have absolute confidence in all blocks buried 12 deep.
So if a transaction is unspent and buried 12 deep, we can purge all it's ancestors. They add warm fuzzies but no additional validation. We have to rely on them. There is simply no way to back up and change course.
After that, every succeeding block presumes all the preceding blocks are true. Otherwise it would be a fork and not a succeeding block. So for any transaction validated against out-points in a preceding block, if those out-points exist and are unspent, they must be presumed valid. If those are presumed valid, their ancestors must be presumed valid even if purged.
---
In the proposed system, exactly the same things are true.
If an antecedent out-point hash is unspent and buried 12 blocks deep, then it is absolutely unspent. Nothing can change that fact. No point in checking its ancestors. You can finish validating the transaction, cancel the in-points hashes and create new out-point hashes.
Interestingly, if an antecedent out-point hash is unspent and buried LESS THAN 12 blocks deep, then it is RELATIVELY unspent. Curiously, there is still no point in checking its ancestors. The only thing that could change the antecedent's validity is a branch swap to a longer chain. If an ancestor of the antecedent you are validating this transaction against was swapped out, this transaction would be swapped out as well.
It's one of those cheesy time machine movie plots. Someone when back in time and spent my ancestor. Now I don't exist!
=====
So what I'm saying is that in BOTH systems (existing and proposed) the only thing validators need to do is to validate that the antecedent out-points exist and are unspent (for the current block chain). The process assures that everything else remains relatively or absolutely valid.
The rest is just warm fuzzies.
-- PS --
I know this is too long and redundant, but I'm to tired to edit. :-)
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 could keep a record of it.
Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.
Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it.
Crypto may offer a way to do \"key blinding\". I did some research and it was obscure, but there may be something there. \"group signatures\" may be related.
There's something here in the general area:
http://www.users.zetnet.co.uk/hopwood/crypto/rh/What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m.
When paying to a bitcoin address, you would generate a new blinded key for each use.
Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.
As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.
Here are the details.
1) Bought 9,000 BTC on one of the exchanges over time.
2) Transferred them to my client running on a linux live CD distro of Debian.
3) Backed up the wallet file to a flash drive.
4) Sent 1 BTC to myself
5) Closed client before any confirmations
6) Shut down system (wiped system disk loaded into memory and therefore the ./bitcoin folder
7) Loaded system back up
Copied old wallet.dat file into ./bitcoin folder
9) After some confirmations appeared the balance was 1 BTC and there was a transaction saying I spent 8,900 BTC to an address I did not recognize
10) I read on the forum threads that people have had problems like this but it seemed only when they were trying to double-spend by sending coins to another address and reloading an old wallet file
Is there anything I can do?
I do have the address that the 8,900 were supposedly sent to but the old wallet file is gone for good.
Thanks,
Stone Man
Do you still have the wallet.dat that once \"contained\" the 9000 BTC? I might be able to help you.
",
"nested_level": 0
},
{
"id": 2255,
"thread_id": 175,
"source_id": "3",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8625#msg8625",
"date": "2010-08-10T23:23:11Z",
"text": "It sounds like they are lost for good.
Lesson to other people: Remember you need to back your wallet up after every transaction!
(The wallet metaphor is actually a bad one, because it makes problems like this more common than they should be.)
Edit: (more explaination)
When you do a transaction you always spend ALL of the coins in that address, part of the money goes to whoever you're paying, and there rest is returned to you an a new 'change' address. (This helps your anonymity as someone watching cannot tell which amount you spent and which amount you kept.)
Before transaction:
Address1: 9000
Address2: 0
After transaction:
Address1: 0
Address2: 1
Address3: 8999
It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.
(Although the numbers in your story don't add up.)
What were the Bitcoin addresses? (If we know these we can do some more in-depth block chain research)
Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?
That sucks.
",
"nested_level": 0
},
{
"id": 2257,
"thread_id": 175,
"source_id": "5",
"poster_name": "Stone Man",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=288",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8634#msg8634",
"date": "2010-08-11T00:08:19Z",
"text": "Do you still have the wallet.dat that once \"contained\" the 9000 BTC? I might be able to help you.
Yes, I do.
I saw on another thread that gavinanderson has made some tools to do more in depth research but did not know how to proceed.
If you could point me in the right direction I would greatly appreciate it.
It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.
(Although the numbers in your story don't add up.)
What were the Bitcoin addresses? (If we know these we can do some more in-depth block chain research)
Address1: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW
Address2: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW
Address3: 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg
I used bitcointools:
http://github.com/gavinandresen/bitcointoolsTo look for your transactions in the block chain.
(Here are the edited highlights)
python dbdump.py --search-blocks 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW
Block: 73261
Time: Mon Aug 9 22:08:34
734 tx in, 1 out
['TxIn: .... <snipped. There were a lot> ']
['TxOut: value: 9000.00 pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW Script: DUP HASH160 20:2d15...8e7a EQUALVERIFY CHECKSIG']
Block: 73272
Time: Mon Aug 9 23:35:11 2010
1 tx in, 2 out
['TxIn: prev(8bda...4675:0) pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW sig: 72:3045...5301 65:04bc...2d42']
['TxOut: value: 1.00 pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW Script: DUP HASH160 20:2d15...8e7a EQUALVERIFY CHECKSIG',
'TxOut: value: 8999.00 pubkey: 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg Script: DUP HASH160 20:3816...7437 EQUALVERIFY CHECK SIG']
So the transactions are definitly in there.
Your only hope is to have the private key for the 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg address.
If you can get bitcointools working you can dump your wallet.dat using:
python dbdump.py --wallet
which will show you all the keys you know about in your wallet.
But you'll probably find that 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg is not in there
On the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...
Edit: I'd pasted the wrong block number and date for the first block. Fixed.Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?
That sucks.
Actually, the sad part was I wasn't even testing the wallet backup when this happened. I was trying to watch when the network should have confirmed a payment to a website that takes bitcoins by paying myself 1 coin at about the same time. I never dreamed it could compromise my whole balance, especially since I was sending to myself.
Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?
That sucks.
Actually, the sad part was I wasn't even testing the wallet backup when this happened. I was trying to watch when the network should have confirmed a payment to a website that takes bitcoins by paying myself 1 coin at about the same time. I never dreamed it could compromise my whole balance, especially since I was sending to myself.
Ugh, that's awful.
Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.
Sorry about your loss, Stone Man.
",
"nested_level": 0
},
{
"id": 2263,
"thread_id": 175,
"source_id": "11",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8657#msg8657",
"date": "2010-08-11T02:01:53Z",
"text": "I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.
",
"nested_level": 0
},
{
"id": 2264,
"thread_id": 175,
"source_id": "12",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8684#msg8684",
"date": "2010-08-11T05:38:22Z",
"text": "This has the implication that if you create a receiving address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins associated with that address are lost. If you lose your wallet entirely, all of your coins are lost and can never be recovered.
On the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...
So, they aren't lost forever? I guess it is more likely to generate the key of the address of someone else then from this specific address.
Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.
If you backup a spreadsheet, do you not expect to lose changes you made after that backup when you restore?
There are many types of transactions that will survive a wallet restore. This is one of the circumstances in which you will lose coins.
If he'd transferred all 9000 to the address he would still have them.
I'm not trying to blame the user. I agree this is a problem that needs to be fixed.
This problem has been previously identified and there are plans to implement a fix, which has been talked about in the
Privacy versus Safety: handling change thread. But it has not been implemented yet.
Perhaps a bounty is in order?
On the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...
So, they aren't lost forever? I guess it is more likely to generate the key of the address of someone else then from this specific address.
According to the theory, generating a address collision is so remotely unlikely as to never happen.
(You're more likely to get struck by lightning, win all the worlds lotteries, and then get abducted by aliens on the same day.)
However if you manage to find a weakness in a) the encryption method or b) Bitcoins implementation of it. it may make it easy enough that you don't have to get abducted by aliens as well.
So they practically
are lost forever.
Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.
Sorry about your loss, Stone Man.
+1
This shocked me actually. The poor guy didn't do anything stupid.
Automatic backups are really important after knowing that. And while that cannot be implemented, I think a sort of information message explained this in short words should be displayed every time someone sends coins. A popup saying something like, if I have T coins and I send S coins:
\"S coins where sent to address X.
(T-S) coins where sent to address Y, which belongs to you, in order to improve privacy. Please, realize that old backups you might have of your wallet will now be useless. You should make a new one.\"
This simple message would have avoided this awful lost. (of course, you may also add a \"Don't display this again\" check box)
Regards
I think Satoshi proposed a protection against this in the following post:
We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.
There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
This is indeed a good solution. Solves more than one problem actually.
",
"nested_level": 0
},
{
"id": 2269,
"thread_id": 175,
"source_id": "17",
"poster_name": "skull88",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=667",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8732#msg8732",
"date": "2010-08-11T10:45:55Z",
"text": "Good to know this, I thougt I was save with my backups, but it could have happened to me to.
Stoneman didn't really do anything stupid.
News to me is that *all* your coins are at risk. I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance. Yikes.
As a countermeasure, I've manually split my wallet up into five new wallets of distributed value. Now only one is at risk at any given time.
",
"nested_level": 0
},
{
"id": 2271,
"thread_id": 175,
"source_id": "19",
"poster_name": "vess",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=621",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8771#msg8771",
"date": "2010-08-11T17:49:51Z",
"text": "A simple solution to this would be to store your wallet.dat on an encrypted partition that goes to an S3-based storage system, like Dropbox. They'll keep versions for you on update.
This would make a nice opt-in service that could be sold in the native client as a way to help fund research, by the way. The data storage needs are incredibly small.
",
"nested_level": 0
},
{
"id": 2272,
"thread_id": 175,
"source_id": "20",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8772#msg8772",
"date": "2010-08-11T17:57:20Z",
"text": "News to me is that *all* your coins are at risk. I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance. Yikes.
You were right before. The reason all of his coins were lost is that he first transfered all \u0e3f9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself \u0e3f1, he would have only lost the smallest payment that he had previously received that was over \u0e3f1.
I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.
News to me is that *all* your coins are at risk. I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance. Yikes.
You were right before. The reason all of his coins were lost is that he first transfered all \u0e3f9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself \u0e3f1, he would have only lost the smallest payment that he had previously received that was over \u0e3f1.
I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.
Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.
In other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out.
News to me is that *all* your coins are at risk. I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance. Yikes.
You were right before. The reason all of his coins were lost is that he first transfered all \u0e3f9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself \u0e3f1, he would have only lost the smallest payment that he had previously received that was over \u0e3f1.
I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.
Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.
In other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out.
My understanding is that it finds an address or addresses that have at least the number of coins you want to send and sends the change to a new address.
So if he had addresses with 1000, 2000, 2500, and 3500. It would have selected one of them (the lowest one?) and sent 1 away and sent all but 1 back to a new address of his. In this case he would not lose them all, just the remainder of what was in that one address.
It appears he had only 1 address with coins in it. This is probably because he got them all from the market in one go. If that is not the case, then I don't know why he would lose them all.
Ok, re-reading carefully and checking the referenced thread, I finally understand this in detail. It's not that bitcoin \"empties your wallet\" at each transaction - it fully empties an address used to send coins. In this particular case, the user had previously sent themselves the 9000 coins in a lump, resulting in all those coins being held at a single address.
So far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is \"really important\" that information might be of value.
",
"nested_level": 0
},
{
"id": 2276,
"thread_id": 175,
"source_id": "24",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Lost large number of bitcoins",
"url": "https://bitcointalk.org/index.php?topic=782.msg8800#msg8800",
"date": "2010-08-11T21:25:01Z",
"text": "Your 'wallet' is more like your own personal bank
It contains many different accounts. (in Bitcoin these are called Addresses)
Each Address has a balance associated with it, how much money is in it.
Your Wallet balance is the sum of all the balances of the Addresses in your wallet.
When you perform a transaction, it empties enough Addresses to make up the required output amount, but since it has to completely empty each Address there is often money left over in this case the 'change' is returned to you at a new Address.
In this case Stone Man did a transaction that sent all the money from 700+ addresses into a single address and therefore had a wallet containing only one Address that had any money in it.
That Address/Account was emptied as part of the 1BTC transaction and the 8999 change was returned to a new Address to which he lost the private key.
If he had not consolidated all his coins into one Address, he would have lost far fewer coins.
I think the moral of the story might be: \"Don't put all your eggs in one basket\"
So far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is \"really important\" that information might be of value.
No you can't find out which addresses have which balances using the current GUI.
I think it is \"very important\" information.
I also think it is important to be able to chose which addresses are the source of transactions.
This is an example of why the wallet metaphor is bad.
I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.
You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds)
Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction.
No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.
Building r127 here, we see some missing casts, apparently:
rpc.cpp: In function \u0091json_spirit::Value gethashespersec(const json_spirit::Array&, bool)\u0092:
rpc.cpp:340: error: conversion from \u0091int64\u0092 to \u0091json_spirit::Value\u0092 is ambiguous
json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:275: note: json_spirit::Value_impl<Config>::Value_impl(uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:267: note: json_spirit::Value_impl<Config>::Value_impl(int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:259: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:251: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:219: note: json_spirit::Value_impl<Config>::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
rpc.cpp:341: error: conversion from \u0091int64\u0092 to \u0091json_spirit::Value\u0092 is ambiguous
json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:275: note: json_spirit::Value_impl<Config>::Value_impl(uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:267: note: json_spirit::Value_impl<Config>::Value_impl(int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:259: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:251: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]
json/json_spirit_value.h:219: note: json_spirit::Value_impl<Config>::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >] <near match>
The following patch seems to solve the problem:
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -337,8 +337,8 @@ Value gethashespersec(const Array& params, bool fHelp)
\"Returns a recent hashes per second performance measurement while g
if (GetTimeMillis() - nHPSTimerStart > 8000)
- return (int64)0;
- return (int64)dHashesPerSec;
+ return (int64_t)0;
+ return (int64_t)dHashesPerSec;
}
Updated SVN. Thanks.
There's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me.
",
"nested_level": 0
},
{
"id": 2280,
"thread_id": 177,
"source_id": "1",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Where is the separate discussion devoted to possible Bitcoin weaknesses.",
"url": "https://bitcointalk.org/index.php?topic=788.msg8757#msg8757",
"date": "2010-08-11T15:45:42Z",
"text": "Just to be able to ask \"What if ...?\" and have all ideas collected in one place.
For example.
It seems, that a generating node does not need to receive all that transactions at all.
The only data it needs is the previous block hash.
Right?
Next.
It is possible to connect to almost every publicly accessible node, right?
We can collect their addresses and establish connections to almost all of them.
And send them all the data we want.
Like fake (or not so) transactions in huge volumes.
What if it is possible to throttle their generating capability by forcing them to receive and verify
very large amounts of (possibly invalid) transactions (or perhaps another trash)?
If that is true, then we can lower the difficulty, right?
Just do this for a long period of time.
When it lowers to an acceptable for our supercomputer (botnet) value,
we may connect it to the network, but not directly.
Connect it via special node, that does forward messages in a special way, to filter the trash data we are still flooding.
So, the supercomputer will receive the blocks and will participate in generation, the others will be flooded and will get
only a small portion of generated BTCs.
Then, if we are not interested in generated BTCs, we may start generating a blockchain fork.
Immediately after the difficulty drops, we start to generate alternative version of blockchain in a isolated environment.
Since difficulty does not change immediately, we can try to outperform the rest of the network, while they are chewing our
trash data. Fast enough we present everybody with the longest chain, but then the difficulty raises back.
By doing this it is possible to wipe our previous spend transactions, if they are made after the blockchain fork.
So, is it possible that we recover them and get back unspent transactions? And spend them again?
How will previous transactions incorporate into the new blockchain if they were \"respent\" in that manner?
And then it can be repeated.
If I'm wrong, just say: \"you are wrong\".
But you may also give me a hint why.
",
"nested_level": 0
},
{
"id": 2281,
"thread_id": 177,
"source_id": "2",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.",
"url": "https://bitcointalk.org/index.php?topic=788.msg8761#msg8761",
"date": "2010-08-11T16:10:56Z",
"text": "Bitcoin's p2p network is subject to various kinds of denial of service attacks.
There, I said it.
Do you have constructive suggestions for how to fix it, or are you the kind of person who just enjoys breaking things because you can?
Ideas that have been bouncing around my head that may or may not work:
+ have clients tell each other how many transactions per unit of time they're willing to accept. If a client sends you more (within some fuzz factor), drop it. Compile in a default that's based on estimated number of transactions for a typical user and estimate on the number of current users.
+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
This is an active area of research; see, for example:
http://scholar.google.com/scholar?q=ddos+attacks+by+subverting+membershipKnightmb said increasing connections and bandwidth had little effect on khash speed.
Game over. Try again?
",
"nested_level": 0
},
{
"id": 2283,
"thread_id": 177,
"source_id": "4",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.",
"url": "https://bitcointalk.org/index.php?topic=788.msg8765#msg8765",
"date": "2010-08-11T16:40:07Z",
"text": "+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
Isn't that a brilliant idea? Like hashcash?
You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power.
I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea! Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)...
+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
Isn't that a brilliant idea? Like hashcash?
You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power.
I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea! Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)...
Unfortunately, as simple to implement as it is, in order to be effective it would have to be a breaking change.
Older clients won't send the proof of work because they don't know to. So an attacker could just claim that their client version was, say, 308 - too old for the protection. So your node would have to choose between dropping support for older clients and being secure against this sort of attack or continuing to support older clients and being insecure against this.
I'm not saying we shouldn't do it, but I think we ought to get a list of important breaking changes together before we make one. Users really don't like being told that they have to upgrade every other day.
Also, I don't know how the message relay protocol works. I guess each node could just relay that Tx with the same nonce and hash that the first one gave it. There's no danger of \"reusing\" a hash since a duplicate transaction is by nature invalid (although it could still harass the nodes).
Some detection and blacklisting code would be useful too. If an IP sends you a certain number of invalid transactions within a certain time, disconnect and refuse to accept connections from them for a certain period of time. If they do it again upon reconnecting, block them for longer... etc.
+ have clients tell each other how many transactions per unit of time they're willing to accept. If a client sends you more (within some fuzz factor), drop it. Compile in a default that's based on estimated number of transactions for a typical user and estimate on the number of current users.
+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).
I agree that eventually the latter will have to be done. It's for the reasons you pointed out that my DHT solution has flaws. Curiously it's all a side effect of not being able to implement the former constraint.
If you allow validating nodes to arbitrarily ignore transactions you risk breaking the key requirement that all validating nodes receive and record all transactions. The current presumption is that all validators try to receive and record all transactions. If a transaction is non-uniformly delayed and missed by the node who completes the block, it is presumed that statistically the transaction would be recorded in a subsequent block. However, that requires continually rebroadcasting the transaction to assure it gets through.
Let's say throughput was right and there was an advantage to a node saying, \"I'm only willing to take 5 transactions a 10 block period.\" in that case it still generates blocks that can't be rejected by others, but an increasing number of unrecorded transactions backlogs with each minimal block. This causes additional retransmissions exacerbating the bandwidth problem.
In effect you rely on unrestricted nodes to compensate for a problem caused by restricted nodes. So if the restricted nodes are causing problems and doing less validation and recording work than other nodes, why should they be rewarded equally for generating blocks? That seems counter productive.
It would be better to say, \"record all transactions or you can't be a validator!\" Less validators means less bandwidth usage overall. It also becomes easier to spot abusers.
----ps----
An zero knowledge proof-of-completeness would be for competing validators to reject a proof-of-work block if it didn't contain 99% of the known outstanding transactions.
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 transactions, but only a limited number per time period.
I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster.
A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.
Bitcoin's p2p network is subject to various kinds of denial of service attacks.
There, I said it.
+1
Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.
There is this piece of code in headers.h:
#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif
In my testing it's not caught on FreeBSD 8.1
I propose it be changed to:
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
And then checks for BSD should be
#ifdef BSDThis is the recommended way of detecting BSD in the
FreeBSD Porter's Handbook.
This change is already done in my CMake tree.
There is this piece of code in headers.h:
#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif
That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__.
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
Will that definitely cause BSD to be defined on Mac?
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
Will that definitely cause BSD to be defined on Mac?
Don't know if Mac OS X is technically a BSD and I don't have access to a Mac, maybe someone else may test it.
If there are other Mac (and not BSD) specialties, then we'd need to check both for __WXMAC_OSX__ and BSD or detect these in some other way altogether.
This is in SVN rev 130. Check that it compiles right.
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h> // to get BSD define
#endif
#ifdef __WXMAC_OSX__
#ifndef BSD
#define BSD 1
#endif
#endif
Misc bugfixes in rev 130:
fix -datadir with relative path
autostart is now off by default except on windows
fix occasional \"vector iterator not dereferencable\" assertion when compiled with msvc
fix readlink compile warning on linux build
use sys/param.h and BSD define instead of __BSD__
-paytxfee switch, e.g. -paytxfee=0.01
",
"nested_level": 0
},
{
"id": 2292,
"thread_id": 179,
"source_id": "2",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Bugfixes in SVN rev 130",
"url": "https://bitcointalk.org/index.php?topic=795.msg8941#msg8941",
"date": "2010-08-12T23:39:12Z",
"text": "-paytxfee switch, e.g. -paytxfee=0.01
So, -paytxfee sets nTransactionFee.
Can someone explain how nTransactionFee causes a client to behave?
And more specifically, what happens when node A sets 1000.0 and all other nodes use 0.01?
-paytxfee switch, e.g. -paytxfee=0.01
So, -paytxfee sets nTransactionFee.
Can someone explain how nTransactionFee causes a client to behave?
And more specifically, what happens when node A sets 1000.0 and all other nodes use 0.01?
From what I understand a node will not include transactions in it's blocks unless the transaction includes a fee that meets the node's requirements. So in the case of a node setting the fee to 1,000 it would likely never include any transactions in blocks it generates, which means it will miss out on any transaction fees other nodes would have gotten. There really isn't a reason to set a nodes requirements higher then the rest of the network since you are basically just pricing yourself out of the market.
No, that's not what it is.
-paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using \"-paytxfee=0.01\". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01.
It's just there in case we need it. It probably won't be needed, and it can be explained more if we do.
",
"nested_level": 0
},
{
"id": 2295,
"satoshi_id": 355,
"thread_id": 180,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.9 rc1, please test",
"url": "https://bitcointalk.org/index.php?topic=806.msg9046#msg9046",
"date": "2010-08-13T17:40:00Z",
"text": "Here's a test build if you'd like to help test before 0.3.9 is released.
(or if you'd rather get upgrading out of the way now instead of waiting)
Downloads: (binaries only)
http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip(
http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)
SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip
SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz
Edit:
Linux please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This will only be for Linux:
http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gzSHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz
Please report back your results
http://bitcointalk.org/index.php?topic=820What's new? Do we have an official changelog yet?
",
"nested_level": 0
},
{
"id": 2297,
"thread_id": 180,
"source_id": "3",
"poster_name": "Tilka",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=687",
"subject": "Re: Version 0.3.9 rc1, please test",
"url": "https://bitcointalk.org/index.php?topic=806.msg9439#msg9439",
"date": "2010-08-15T14:11:20Z",
"text": "What's new? Do we have an official changelog yet?
Unfortunately we don't have an official changelog yet (except for the SVN revision descriptions).
Here is my unofficial changelog:
- fix: makefile.osx
- change: enable SSE2 in 64 bit builds
- change: connection rules
- always make 8 outbound connections
- only one connection per a.b.*.* range - add: switch \"-maxconnections=#\" (discussed here)
- change: JSON-RPC API prints floats with 8 decimal places
- change: \"bitcoind help <command>\" instead of \"bitcoind <command> -?\" (based on a patch by jgarzik)
- add: JSON-RPC \"gethashespersec\" (based on a patch by lachesis)
- add: \"version\" and \"hashespersec\" fields in JSON-RPC \"getinfo\"
- fix: \"-datadir=<path>\" with relative path (bug described here)
- change: autostart disabled by default except on Windows (requested here)
- fix: occasional \"vector iterator not dereferencable\" assertion when compiled with msvc
- fix: readlink compile warning on Linux build
- fix: BSD detection (bug described here)
- add: \"-paytxfee=#\" switch (explained here)
Please tell me if you know of any other forum threads discussing the bugs/changes so I can add them to the list.
Unfortunately we don't have an official changelog yet (except for the SVN revision descriptions).
...
Please tell me if you know of any other forum threads discussing the bugs/changes so I can add them to the list.
That's a
great changelog. I sent you \u0e3f2 for your trouble.
Don't wanna take credit where it's not due
the hashes/sec patch was from lachesis, and the extended-help might have been based on my idea, but the code was somewhat different.
the extended-help might have been based on my idea, but the code was somewhat different.
The idea was the main part. When you posted your patch, I realized it should have been done that way instead of \"-?\". I always had reservations about \"-?\" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.
I'm proposing one small change to Bitcoin's JSON-RPC api: return a transaction ID when Bitcoins are successfully sent.
Why? Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes. The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.
So I propose doing the simplest thing possible: modify the JSON-RPC sendtoaddress call so it returns the string 'sent:' followed by the 256-bit-hexadecimal transactions id.
This could break any applications that look for exactly the string 'sent' (which is what sendtoaddress does now). The fix would be to modify the apps to see if the string began with 'sent'.
Alternatives I thought about but think I don't like:
+ make it a new api call so old apps do not break (sendtoaddress2 ? yuck)
+ return just the transaction id on successful send instead of 'sent:...'
+ return an array with more information (maybe [ \"tx_id\": \"...\", \"fee\" : 0.0 ] )
Comments/criticisms?
",
"nested_level": 0
},
{
"id": 2302,
"thread_id": 181,
"source_id": "2",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Proposed change to sendtoaddress API call",
"url": "https://bitcointalk.org/index.php?topic=807.msg9075#msg9075",
"date": "2010-08-13T19:40:20Z",
"text": "
100% agreed with your suggestion, about the need for txn_id association.
However, it seems better to avoid API breakage, because this API is so heavily used. It is almost guaranteed that anyone automating bitcoins is using sendtoaddress.
Either create a \"send2\" RPC call, or add an \"[extended-JSON=0]\" parameter to the existing sendtoaddress RPC call, or something similar that preserves existing application data flows.
",
"nested_level": 0
},
{
"id": 2303,
"thread_id": 181,
"source_id": "3",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: Proposed change to sendtoaddress API call",
"url": "https://bitcointalk.org/index.php?topic=807.msg9076#msg9076",
"date": "2010-08-13T19:41:14Z",
"text": "Just add a flag (like true/false) to the function with the default \"false\" so it works with older uses of the function call.
Like
sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return transaction ID, default false]
So
sendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 \"Blah Comment\" \"Blah From\" true
returns
sent XYZ....
But
sendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 \"Blah Comment\" \"Blah From\"
returns
sent
Also without having to break compatibility.
I think it would be a handy addition.
RE: adding a flag: great idea!
If you set the flag, I don't see any reason to prepend 'sent' to the transaction ID; better to just return the transaction ID on successful send.
Patches:
diff --git a/rpc.cpp b/rpc.cpp
index 920fe90..8714b7e 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -342,10 +342,11 @@ Value getaddressesbylabel(const Array& params, bool fHelp)
Value sendtoaddress(const Array& params, bool fHelp)
{
- if (fHelp || params.size() < 2 || params.size() > 4)
+ if (fHelp || params.size() < 2 || params.size() > 5)
throw runtime_error(
- \"sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]\n\"
- \"<amount> is a real and is rounded to the nearest 0.01\");
+ \"sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return-tx-id-flag]\n\"
+ \"<amount> is a real and is rounded to the nearest 0.01\n\"
+ \"returns string 'sent' if return-tx-id-flag is false (default), otherwise returns transaction id.\");
string strAddress = params[0].get_str();
@@ -361,9 +362,15 @@ Value sendtoaddress(const Array& params, bool fHelp)
if (params.size() > 3 && params[3].type() != null_type && !params[3].get_str().empty())
wtx.mapValue[\"to\"] = params[3].get_str();
+ bool fReturnTxID = false;
+ if (params.size() > 4)
+ fReturnTxID = params[4].get_bool();
+
string strError = SendMoneyToBitcoinAddress(strAddress, nAmount, wtx);
if (strError != \"\")
throw runtime_error(strError);
+ if (fReturnTxID)
+ return wtx.GetHash().ToString();
return \"sent\";
}
@@ -1103,6 +1110,7 @@ int CommandLineRPC(int argc, char *argv[])
if (strMethod == \"setgenerate\" && n > 0) ConvertTo<bool>(params[0]);
if (strMethod == \"setgenerate\" && n > 1) ConvertTo<boost::int64_t>(params[1]);
if (strMethod == \"sendtoaddress\" && n > 1) ConvertTo<double>(params[1]);
+ if (strMethod == \"sendtoaddress\" && n > 4) ConvertTo<bool>(params[4]);
if (strMethod == \"listtransactions\" && n > 0) ConvertTo<boost::int64_t>(params[0]);
if (strMethod == \"listtransactions\" && n > 1) ConvertTo<bool>(params[1]);
if (strMethod == \"getamountreceived\" && n > 1) ConvertTo<boost::int64_t>(params[1]); // deprecated
What happens when we desire to return additional information, beyond tx-id?
For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.
",
"nested_level": 0
},
{
"id": 2306,
"thread_id": 181,
"source_id": "6",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Proposed change to sendtoaddress API call",
"url": "https://bitcointalk.org/index.php?topic=807.msg9096#msg9096",
"date": "2010-08-13T20:26:06Z",
"text": "What happens when we desire to return additional information, beyond tx-id?
For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.
A 'gettransaction tx_id' API call is on my short list.
What do other folks think; should sendtoaddress .... true return just the tx_id, and you have to make another API call to get details if you need them?
Or should it return an Array?
Do you need 'gettransaction', given the existence of 'getblock'?
",
"nested_level": 0
},
{
"id": 2308,
"satoshi_id": 357,
"thread_id": 181,
"source_id": "8",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Proposed change to sendtoaddress API call",
"url": "https://bitcointalk.org/index.php?topic=807.msg9134#msg9134",
"date": "2010-08-13T23:39:14Z",
"text": "It's too soon to start junking up the API for backward compatibility at all costs.
Just return \"<txid>\".
",
"nested_level": 0
},
{
"id": 2309,
"thread_id": 182,
"source_id": "1",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9186#msg9186",
"date": "2010-08-14T12:43:54Z",
"text": "The difficulty for generating bitcoins is periodically adjusted using a method
that has worked well this far. However, I am afraid there are plausible
scenarios where the current method would misbehave quite spectacularly.
One scenario goes like this:
1) As bitcoins become more known, competition among minters continues to
increase, with corresponding increases in difficulty. The increased
difficulty will eventually make bitcoin minting clearly unprofitable for
those who do not have access to good energy prices and cheap access to an
energy-efficient HW/SW combination.
2) Some bitcoin users may continue to mint bitcoins even though it is not
profitable for them. This could be due to ideology, the fun factor, or
just ignorance. But it is quite plausible that the vast majority of
bitcoins will be minted by those who profit from it. Let's say that 99% of
all bitcoins are eventually minted by for-profit-minters.
3) The competition among for-profit-minters will drive profit margins down, to
the point where it is profitable to continue minting, but barely so. Let's
say that the typical profit margin during one difficulty adjustment period
(2016 blocks) is 10%.
4) Since bitcoin minting is a decentralized uncoordinated process, we can
expect random fluctuations in bitcoin minting activity. This does not
affect the difficulty during a specific 2016-block period, so the minting
activity can e.g. increase by 20% during a period without making minting
unprofitable within that period.
Given the above assumptions, we now have a disaster at hand at the next
difficulty adjustment. As bitcoin production was 20% more than target,
difficulty is adjusted upwards by 20%. But the profit margin was only 10%, so
for-profit-minters would now lose money if they continued minting. They will
therefore stop minting, and as they make up 99% of the minting capacity,
generating the next 2016 blocks will take 100 times longer than normal.
Everything that depends on block generation will slow to a crawl, and this
slowness will persist for a very long time, since the next 2016 blocks will
take 100 times longer to generate (almost 4 years rather than two weeks).
Now, if this was to happen, I guess a new client could be released that resets
the difficulty to some sensible number and started using a better algorithm
for difficulty adjustment. But it would be much better to do it proactively
before it becomes a problem (perhaps with a predetermined \"flag day\"
activating the new algorithm at a certain time in the future, giving the new
client a chance to propagate).
A simple(?) modification of the algorithm would be to apply the adjustment
after a certain amount of time rather than at a certain block number. The
switch could still be synced to take effect for the next block, so time
synchronization between clients would not need to be super exact to have the
vast majority of them agree on when the new difficulty is to be applied.
Also, the difficulty adjustment should probably take into account the
adjustments of the number of bitcoins minted per event (now 50, halved every 4
years). Halving the number of bitcoins generated each time is equivalent to
doubling the difficulty as far as profitability is concerned, and such a
drastical drop in profitability is unnecessary if it can be avoided easily.
I'm not sure if the current adjustment algorithm already takes that into
account somehow, but I couldn't see any obvious adjustment for it in the
source code.
",
"nested_level": 0
},
{
"id": 2310,
"thread_id": 182,
"source_id": "2",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9195#msg9195",
"date": "2010-08-14T14:01:24Z",
"text": "I think there is a limit to the amount that the difficulty can increase at each step.
The more the bitcoin network grows, the less likely it is to have large spikes in difficulty. The likelihood of a jump of that magnitude from a single entity is very unlikely. If that kind of jump does occur, it will more likely be from a large interested demographic discovering Bitcoin all at once, such as if it was featured in a major magazine. Bitcoin will cope with such increases and subsequent decreases just fine.
In the very unlikely event of blocks taking hours or days to be completed, the transaction fee feature would quickly be added back to the program and people would start including a \u0e3f0.01 transaction fee with each transaction they sent. The mega-minter would have a modified client which would monitor how many bitcoins in transaction fees were available and once it was enough to be profitable, they would turn on their mega-hash-cruncher and you'd get your block within ten minutes on average.
It doesn't much matter whether minting is profitable or not. In not too many years, total transaction fees per block will be higher than new bitcoins per block.
",
"nested_level": 0
},
{
"id": 2311,
"thread_id": 182,
"source_id": "3",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9209#msg9209",
"date": "2010-08-14T15:14:44Z",
"text": "I think there is a limit to the amount that the difficulty can increase at each step.
The more the bitcoin network grows, the less likely it is to have large spikes in difficulty. The likelihood of a jump of that magnitude from a single entity is very unlikely. If that kind of jump does occur, it will more likely be from a large interested demographic discovering Bitcoin all at once, such as if it was featured in a major magazine. Bitcoin will cope with such increases and subsequent decreases just fine.
There is a limit to the difficulty adjustment, but for upward adjustments it is 300% (factor of 4 between new and old) rather than the 20% in my scenario, so it wouldn't help.
I would argue that a 20% difficulty adjustment is in no sense extreme - the last five adjustments were 44%, 35%, 300%, 93%, and 21%. This hasn't been a problem up to now, but obviously not because a 20% adjustment would be too extreme, but more likely because it hasn't been enough to make minting unprofitable (or otherwise uninteresting). My scenario does not assume that a single entity is responsible for a jump in difficulty - it is just as problematic if e.g. publicity makes minting 20% more popular at a time when the profit margin is less than 20%. The extreme effects come from the proportion of minters who are unwilling to continue minting at a loss. If this proportion is large while the profit margin is low, the system becomes very unstable.
Also, if I am right about the 4-year halving of bitcoins generated (i.e. that it
doesn't affect the difficulty adjustment) such events alone would be equivalent to a 100% upward difficulty adjustment. And it seems very reasonable to assume that most minters will have a lower profit margin than 100% in the future.
It's already not interesting to mint bitcoins. Also, for the average person, I think they're hardly profitable. Even if the average person can sell bitcoins at slightly above production costs, it's difficult to invest more than pocket change worth of electricity per day. Profit on pocket change in exchange for hearing your fan running full blast all day everyday is not very interesting to the average person. If there is a sudden spike in new users, they're not going to all show up at the beginning of a difficulty cycle, stay until the cycle until it's over and then all leave. Most will not last a week generating bitcoins on our already boring to generate network, so as all these flaky new users quit generating, we'll have half a week without them and half a week with them. Those that do stick around will help adjust difficulty back to what it should be.
And like I said about the worst case scenario, if we're going on a week without generating a block, then we start including some transaction fees and somebody from the community rents a cloud to get to the next adjustment.
In short, I don't think there's much anything to worry about. But you're welcome to go on worrying about it.
The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.
In addition, as Bitcoin grows, people will develop dedicated hardware that maximizes the khash/dollar spent. In addition, people will tune the software in more and more precise ways to squeeze slightly more khash/second out of the same hardware. The people who invest a large fixed cost to do that will receive a correspondingly lower variable cost per Bitcoin minted in return, so they'll be able to mint at price levels that would drive others out.
Finally, at the point that this becomes an issue, everyone will be including transaction fees with their transactions to incentivize minting.
",
"nested_level": 0
},
{
"id": 2314,
"thread_id": 182,
"source_id": "6",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9232#msg9232",
"date": "2010-08-14T18:34:23Z",
"text": "It's already not interesting to mint bitcoins. Also, for the average person, I think they're hardly profitable.
Well, there might be an important psychological difference between being marginally profitable and by clearly losing money. The range of efficiency in bitcoin minting is such that some people may be profitable at a difficulty level where most are clearly losing money. If this happens, I suspect the share of nonprofit minting activity would dwindle quite quickly. We are then in the unstable situation I warned about.
In short, I don't think there's much anything to worry about. But you're welcome to go on worrying about it.
Of course I'm worrying - my entire bitcoin fortune (150 BC) is at stake here!
You ignore all kinds of things that help solve this.
Transaction fees will increase if blocks come more slowly because it will be more desirable to get your transactions in the next block.
If an entity calculates that (fixed costs + variable costs < revenue) adjusted for risk the it is pretty unlikely that they will hit the (variable costs > revenue) easily at all and that is the shutdown point.
These minters will usually have and use bitcoins themselves. This gives two extra incentives to operate at a \"loss\". They want their transactions to get processed, and they want to maintain bitcoin as a working system.
",
"nested_level": 0
},
{
"id": 2316,
"thread_id": 182,
"source_id": "8",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9243#msg9243",
"date": "2010-08-14T19:30:43Z",
"text": "The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.
Actually, I was not assuming that. In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%. The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be
above 20% - then the typical profit margin would not be 10%).
Regarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost. There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me.
The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.
Actually, I was not assuming that. In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%. The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be
above 20% - then the typical profit margin would not be 10%).
Regarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost. There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me.
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Having a secure, open, P2P, pseudonymous, limited quantity money, is worth a ton. People who agree will pay the .001BTC or whatever to make a transaction if that's about what it ends up costing.
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs. I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs. I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
Really? Source?
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs. I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
I'll bite.
How would you fix the algorithm?
I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
Really? Source?
Sorry, I was wrong about that. I though I had read something on the forum to that effect, but now I can't find it. Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification.
I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
Really? Source?
Sorry, I was wrong about that. I though I had read something on the forum to that effect, but now I can't find it. Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification.
I thought so, but still, some changes can be made. What is the change that solves this problem?
What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.
Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs. I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.
I'll bite.
How would you fix the algorithm?
It's in my original post:
A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number. The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.
Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years). Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
It's in my original post:
A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number. The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.
Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years). Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
How will you account for latency and time hacking then?
It's in my original post:
A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number. The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.
Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years). Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.
How will you account for latency and time hacking then?
Could you elaborate on what kind of scenarios you see where the proposed algorithm would be more vulnerable than the current one? Note that the current algorithm also uses wallclock time in the difficulty adjustment calculation and is synchronized using newly generated blocks.
You greatly under estimate the power of the profit motive and a market. Bitcoins will continue to be generated as people find more clever ways to reduce hardware and power costs. A lot of people are generating them at zero cost by using their employer's computer. It's unfair to the employer, but it is the reason why bitcoins will continue to generate. The current algorithm for difficulty is fine the way it is.
But let's assume you are correct and people stop generating bitcoins early. So what? There will always be a market price for the remaining bitcoins.
",
"nested_level": 0
},
{
"id": 2327,
"thread_id": 182,
"source_id": "19",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9308#msg9308",
"date": "2010-08-15T00:35:24Z",
"text": "But let's assume you are correct and people stop generating bitcoins early. So what? There will always be a market price for the remaining bitcoins.
Transactions are verified by generating blocks, so although I don't think it will happen, blocks being too difficult to generate would cause the economy to grind to a halt.
Why would it \"grind to a halt\"? Economies don't function just because money is being printed. Are you using the same argument for the US dollar and assuming our \"economy would grind to a halt\" if the government didn't print more dollars? Of course not.
",
"nested_level": 0
},
{
"id": 2329,
"thread_id": 182,
"source_id": "21",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Potential disaster scenario",
"url": "https://bitcointalk.org/index.php?topic=813.msg9337#msg9337",
"date": "2010-08-15T02:15:12Z",
"text": "Why would it \"grind to a halt\"? Economies don't function just because money is being printed. Are you using the same argument for the US dollar and assuming our \"economy would grind to a halt\" if the government didn't print more dollars? Of course not.
Blocks are used to verify transactions. For example, Bitcoin Market requires two confirmations. If a block takes two hours to make, then it would take four hours to put Bitcoins into Bitcoin Market. This would not be good.
When people start adding transaction fees, the value of the current block will steadily rise until it is solved. If this gets very high, everyone will attempt to \"win the jackpot\". The market will solve the problem.
Botnets will probably be supporting Bitcoin in the future, so it doesn't really matter anyway.
A lot of people are generating them at zero cost by using their employer's computer. It's unfair to the employer, but it is the reason why bitcoins will continue to generate.
This is a good point. I don't think I underestimated people's ability to generate bitcoins efficiently and
legitimately - the difficulty adjustment does a good job of compensating for that, and that makes it a non-issue in my scenario. But I probably underestimated the effect of minters using other people's resources without their knowledge and consent. The FAQ theorizes that the cost of minting will approach the price of electricity minus a thin profit margin, and I probably accepted that theory too uncritically. If resource theft becomes the primary way to finance bitcoin minting, flaws in the difficulty adjustment will have a more subtle impact.
Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them
There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.
How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.
There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.
Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.
",
"nested_level": 0
},
{
"id": 2332,
"thread_id": 183,
"source_id": "1",
"poster_name": "chromicant",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=777",
"subject": "Big endinan code problems",
"url": "https://bitcointalk.org/index.php?topic=816.msg9280#msg9280",
"date": "2010-08-14T22:08:00Z",
"text": "I've seen a lot of messages about some big-endian \"issues\" (ok, no worky) with the bitcoin client. Before I sit and try to analyze all the source code, are there any known \"bad bits\" of the code that assume LE?
I have some idle G4 and Sparc machines that can happily be put to use...plus an old decrepit Alpha that needs to be tested to see if it still boots...
",
"nested_level": 0
},
{
"id": 2333,
"thread_id": 183,
"source_id": "2",
"poster_name": "teknohog",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=575",
"subject": "Re: Big endinan code problems",
"url": "https://bitcointalk.org/index.php?topic=816.msg9290#msg9290",
"date": "2010-08-14T23:07:54Z",
"text": "I also have a couple of G4 machines, but I think this issue is about much more than getting these old(ish) machines to good use. It is something like the Y2038 problem that some people are already discussing; will everyone keep using x86 all those decades, or should we drop the assumption of that particular architecture?
It is a nice fact that bitcoin happens to compile and run on ARM, one of the most serious contenders of the x86 monopoly, at least in the mobile and embedded space. Nevertheless, a digital currency is too important to be limited in computing architectures. Don't banks tend to use big iron?
",
"nested_level": 0
},
{
"id": 2334,
"thread_id": 183,
"source_id": "3",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Big endinan code problems",
"url": "https://bitcointalk.org/index.php?topic=816.msg9303#msg9303",
"date": "2010-08-15T00:10:04Z",
"text": "I've seen a lot of messages about some big-endian \"issues\" (ok, no worky) with the bitcoin client. Before I sit and try to analyze all the source code, are there any known \"bad bits\" of the code that assume LE?
I have some idle G4 and Sparc machines that can happily be put to use...plus an old decrepit Alpha that needs to be tested to see if it still boots...
Do you think that you might have replaced them sometime in the next 28 years?
I have been thinking about an interim solution, inspired by the fact that many architectures can run in either endianness. AFAIK, Virtual PC used this feature of the PowerPC to run Windows on a Mac. Apparently, Linux also supports running little-endian PPC binaries on an otherwise big-endian system.
It will not be as simple as compiling with -mlittle-endian, as the libraries should likely have the same endianness. It might be possible to cross-compile a little-endian system, compile a static binary in the chroot, and run the resulting binary in the usual big-endian system. Or it could be running in the chroot, if that is easier to accomplish.
So far, I have not managed to build such a system, but it might be possible with a suitable cross-compiler. I already use Gentoo and Crossdev for such things, but I have not found a suitable target machine type for this.
",
"nested_level": 0
},
{
"id": 2336,
"thread_id": 183,
"source_id": "5",
"poster_name": "Gespenster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=714",
"subject": "Re: Big endinan code problems",
"url": "https://bitcointalk.org/index.php?topic=816.msg11583#msg11583",
"date": "2010-08-29T11:35:19Z",
"text": "The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
",
"nested_level": 0
},
{
"id": 2337,
"thread_id": 183,
"source_id": "6",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Big endinan code problems",
"url": "https://bitcointalk.org/index.php?topic=816.msg11593#msg11593",
"date": "2010-08-29T16:41:10Z",
"text": "The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.
in fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.
The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.
in fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.
I think all of them can go away since SHA-256 expects it's bytestream to be big-endian. The fastest way to find out I think is to run the code through a debugger on both a BE and LE machine at the same time and compare results at every step.
The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat.
Big-endian is on its way out anyway.
",
"nested_level": 0
},
{
"id": 2340,
"satoshi_id": 363,
"thread_id": 184,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9452#msg9452",
"date": "2010-08-15T15:52:09Z",
"text": "0.3.10 has tcatm's 4-way SSE2 as an option switch.
Use the switch \"-4way\" to turn it on. Without the switch you get Crypto++ ASM SHA-256.
I could only get this working with Linux.
Download:
Get 0.3.10 from
http://bitcointalk.org/index.php?topic=827.0Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs.
I did a quick test, will report back when I try it on more machines.
Pentium E5300 Dual-Core 2.6 GHz (2MB cache, FSB 800MHz)
Processor info:
http://en.wikipedia.org/wiki/Wolfdale_%28microprocessor%29Stock = 2261 khash/s
4-way = 1103 khash/s (64 bit)
Pentium 4 - 3.0GHz (hyper-threading off) 1MB Cache, FSB 800MHz
Processor info:
http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29Stock = 1024 khash/s (32 bit)
4-way = 658 khash/s (32 bit)
Pentium 4 - 2.8GHz (hyper-threading off) 1MB Cache, FSB 800MHz
Processor info:
http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29Stock = 917 khash/s (64 bit)
4-way = 747 khash/s (64 bit)
If I didn't know better, I would say the key is the CPU cache size. Seems all the CPU that run slower have 2 MB or less onboard cache, where as the Core i5 starts with at least 3MB of onboard CPU cache.
I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with.
I'm also curious if it performs much worse on 32-bit linux vs 64-bit.
",
"nested_level": 0
},
{
"id": 2343,
"thread_id": 184,
"source_id": "4",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9479#msg9479",
"date": "2010-08-15T18:26:40Z",
"text": "Where is the code for this? I'm on a CentOS 5.5 box and need to build it myself. Once I do that I will report back with linux 32-bit and 1MB cache Xeon.
",
"nested_level": 0
},
{
"id": 2344,
"satoshi_id": 367,
"thread_id": 184,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9483#msg9483",
"date": "2010-08-15T18:43:27Z",
"text": "I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff.
",
"nested_level": 0
},
{
"id": 2345,
"thread_id": 184,
"source_id": "6",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9484#msg9484",
"date": "2010-08-15T18:46:25Z",
"text": "Okay, makes sense. I have an i7 930 I'll try and test out with too.
",
"nested_level": 0
},
{
"id": 2346,
"thread_id": 184,
"source_id": "7",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9552#msg9552",
"date": "2010-08-15T21:50:41Z",
"text": "If I didn't know better, I would say the key is the CPU cache size. Seems all the CPU that run slower have 2 MB or less onboard cache, where as the Core i5 starts with at least 3MB of onboard CPU cache.
That's unlikely. The loop accesses 432 bytes of data. That should fit in most caches.
5,911 khash with -4way
11,260 without
(Dual Xeon E5450, 64-bit, 8 threads)
",
"nested_level": 0
},
{
"id": 2348,
"thread_id": 184,
"source_id": "9",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9597#msg9597",
"date": "2010-08-16T00:03:18Z",
"text": "-4way: 12518 khash/s
without: 6550 khash/s
It's a little bit slower than my patch (~14000kash/s).
edit: I ran the binary on an older AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ with the same effect we see on older intel cpus:
-4way: 1120khash/s
without: 2012khash/s
",
"nested_level": 0
},
{
"id": 2349,
"thread_id": 184,
"source_id": "10",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9600#msg9600",
"date": "2010-08-16T00:08:38Z",
"text": "Did anyone verify it to produce correct results on 32 bit hosts?
",
"nested_level": 0
},
{
"id": 2350,
"thread_id": 184,
"source_id": "11",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9610#msg9610",
"date": "2010-08-16T00:32:57Z",
"text": "Running 32-bit Linux on an AMD Athlon 64 X2, I get the following results:
normal: 2850 khash/s
with -4way: 1708 khash/s
I haven't checked if the hashes are correct, just the speed.
",
"nested_level": 0
},
{
"id": 2351,
"thread_id": 184,
"source_id": "12",
"poster_name": "aceat64",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=430",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9613#msg9613",
"date": "2010-08-16T00:37:54Z",
"text": "I created a wiki page so we can keep track of the results:
http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
",
"nested_level": 0
},
{
"id": 2353,
"thread_id": 184,
"source_id": "14",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9620#msg9620",
"date": "2010-08-16T00:47:23Z",
"text": "I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
Good
Will this also work on Windows OS?
I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
Good
Will this also work on Windows OS?
Didn't try it, but CFLAGS are not OS dependent at all so I guess it'll work.
You might want to add columns for whether hyper-threading is enabled, number of physical cores and how many cores Bitcoin is using. Without 4way, I get very slightly better results when I have half of my virtual cores hashing. With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
You might want to add columns for whether hyper-threading is enabled, number of physical cores and how many cores Bitcoin is using. Without 4way, I get very slightly better results when I have half of my virtual cores hashing. With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
I've updated the page with your suggestions, I've also added footnotes to explain some of the fields.
My -4way results: slower for two older boxes, faster for newer one.
(\"model name\" comes from Linux's /proc/cpuinfo, which reports directly from CPU)
1) model name : Intel(R) Pentium(R) D CPU 3.00GHz
total cores: 2
without -4way: 0.999 Mhash/sec
with -4way: 0.850 Mhash/sec
2) model name : Dual Core AMD Opteron(tm) Processor 280
total cores: 4
without -4way: 4.6 Mhash/sec
with -4way: 4.0 Mhash/sec
3) model name : Genuine Intel(R) CPU 000 @ 3.20GHz
total cores: 4
without -4way: 5.7 Mhash/sec
with -4way: 7.0 Mhash/sec
",
"nested_level": 0
},
{
"id": 2358,
"satoshi_id": 384,
"thread_id": 184,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9655#msg9655",
"date": "2010-08-16T02:57:57Z",
"text": "I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
GCC 4.3.3 doesn't support -march=amdfamk10. I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
Hey, you may be onto something!
hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.
tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.
How much of an improvement do you get with hyperthreading?
Some numbers? What CPU is that?
model name : AMD Phenom(tm) II X4 940 Processor at 3.0 ghz linux 64
with -4way \"hashespersec\" : 11132770
without \"hashespersec\" : 5877668
",
"nested_level": 0
},
{
"id": 2360,
"thread_id": 184,
"source_id": "21",
"poster_name": "gridecon",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=692",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9659#msg9659",
"date": "2010-08-16T03:15:44Z",
"text": "I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?
",
"nested_level": 0
},
{
"id": 2361,
"thread_id": 184,
"source_id": "22",
"poster_name": "Vasiliev",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=235",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2",
"url": "https://bitcointalk.org/index.php?topic=820.msg9660#msg9660",
"date": "2010-08-16T03:17:07Z",
"text": "I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
GCC 4.3.3 doesn't support -march=amdfamk10. I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
try -march=amdfam10
try -march=amdfam10
That works.
That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement.
http://www.google.com/search?q=amdfamk10I think he misremembered it since AMD arches are K#.
",
"nested_level": 0
},
{
"id": 2364,
"thread_id": 184,
"source_id": "25",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9664#msg9664",
"date": "2010-08-16T03:30:35Z",
"text": "model name : Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz, linux 64
no difference at about 4950 khash/s
",
"nested_level": 0
},
{
"id": 2365,
"thread_id": 184,
"source_id": "26",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9665#msg9665",
"date": "2010-08-16T03:35:28Z",
"text": "Update for
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4
Machine has 4 cores, each with 2 hyperthreads. /proc/cpuinfo shows 8 virtual processors.
without -4way, setgen 4: 5.7 Mhash/sec
without -4way, setgen 8: 5.0 Mhash/sec
with -4way, setgen 4: 7.0 Mhash/sec
with -4way, setgen 8: 9.3 Mhash/sec
So, the old wisdom of \"hyperthreading slows things down\" is now shattered, on this machine.
No winners for 4way in my other three Intel machines either:
Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (64-bit Linux)
4way: 1565 std: 3002
Intel(R) Xeon(TM) CPU 3.00GHz (32-bit Linux)
4way: 1243 std: 2048
Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz
4way: 932 std: 1733
(All running 0.3.10, -1 proclimit)
Experiments with proclimit weren't any better.
",
"nested_level": 0
},
{
"id": 2367,
"satoshi_id": 386,
"thread_id": 184,
"source_id": "28",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9676#msg9676",
"date": "2010-08-16T04:36:59Z",
"text": "cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4
cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.
I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?
o_O... good luck hashing, you're gonna need it!
With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
Hey, you may be onto something!
hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.
tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.
How much of an improvement do you get with hyperthreading?
Some numbers? What CPU is that?
Here are the results from my very poor memory on an i7 860 2.8 GHz with Ubuntu 10.04 amd64. Some of the numbers may be a bit off.
Without 4way, with HT, 4/8 virtual cores, 4.5-5 Mhash/sec
Without 4way, with HT, 8/8 virtual cores, a bit less than above, but basically the same
With 4way, with HT, 8/8 virtual cores, 6.5-8 Mhash/sec (It may be my imagination, but it seems noticeably more variable.)
With 4way, with HT, 4/8 virtual cores, 5-6 Mhash/sec
Without 4way, without HT, 4/4 physical cores, 4.5-5 Mhas/sec (But a bit slower than the first result.)
With 4way, without HT, 4/4 physical cores, 5-6 Mhash/sec
I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?
o_O... good luck hashing, you're gonna need it!
I guess that should read either mhash/sec or THOUSANDS of khash/sec...but hey, what's 3 orders of magnitude among friends?
Perhaps that typographical error is why nobody has answered whether or not a nearly 100% speeded from the -4way option is at all realistic? I'm not convinced the crypto hashing is really taking place at the rate of 11000khash/sec on my desktop box.
cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4
cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.
Does bitcoin perform any self-tests at startup, to verify that hashing is working?
More importantly, about how long should it take 10 Mhash/sec to verify difficulty 1 blocks?
After the 64-bit Linux hashing bug was fixed I generated a block or two in short order, but since that one or two blocks, I have not generated a single block. It's starting to seem a little fishy.
I'm currently testing Bitcoin on two Linux 64-bit computers. Is there anything in the code blocking early block verification?
Edit: Never mind. I used the
Bitcoin Generation Calculator and divided out the difficulty. Everything is fine here, I've generated a couple blocks with 4way. About to start testing without 4way.
Another Edit: My test only verifies that hashing works. It does not verify whether I'm really getting the displayed speed.
@satoshi: Oops, I meant -march=amdfam10. Sorry.
@everyone confused about improvement on Phenoms: I developed the code on a Phenom (940) and verified it (at least in 64bit mode) and the improvement you see is real.
Concerning Hyperthreading: It seems to give a little performance gain, maybe from running load/store instructions in parallel with aritmethic instructions. There's only a tiny bit of plain x86 instructions for glueing the function into the ABI. They take less than ~2% of the total CPU time (measured with gprof).
",
"nested_level": 0
},
{
"id": 2373,
"thread_id": 184,
"source_id": "34",
"poster_name": "teknohog",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=575",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9729#msg9729",
"date": "2010-08-16T12:31:51Z",
"text": "On a Core 2 Duo T7200, the default code gives about 1.8 Mhash/s, and 4way is slower at 1.0 Mhash/s. It has 4 MB of L2 cache, so it is probably not a question of cache size, as suggested at some point.
Unfortunately, the code (from svn) no longer compiles on ARM, as it now has SSE intrinsics hardcoded. I have removed the -msse2 and -DFOURWAYSSE2 flags from the makefile, and it still produces errors like this
sha256.cpp:8:23: error: xmmintrin.h: No such file or directory
sha256.cpp:34: error: \u0091__m128i\u0092 does not name a type
but hopefully this is easy to fix.
I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
try it now.
",
"nested_level": 0
},
{
"id": 2375,
"thread_id": 184,
"source_id": "36",
"poster_name": "tommy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=559",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9755#msg9755",
"date": "2010-08-16T15:42:55Z",
"text": "model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
w/o -4way \"hashespersec\" : 2539397
with -4way \"hashespersec\" : 2108791
Linux, Debian, 32 bit.
",
"nested_level": 0
},
{
"id": 2376,
"thread_id": 184,
"source_id": "37",
"poster_name": "teknohog",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=575",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg9769#msg9769",
"date": "2010-08-16T16:41:31Z",
"text": "I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
try it now.
Thanks, works fine now.
Model: Intel Atom n330 (2 cores, 4 virtual).
OS: Ubuntu 10.04 64bit
Using the -4way option I get half the speed than using no option.
",
"nested_level": 0
},
{
"id": 2378,
"thread_id": 184,
"source_id": "39",
"poster_name": "denaje",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=857",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10090#msg10090",
"date": "2010-08-18T19:06:04Z",
"text": "64-bit Gentoo / Intel Core i7
W/O 4way: 4324294
With 4way: 7649415
32-bit Ubuntu VM on XP host / Intel Core 2 Duo
W/O 4way: 1751518
With 4way: 793100
",
"nested_level": 0
},
{
"id": 2379,
"thread_id": 184,
"source_id": "40",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10163#msg10163",
"date": "2010-08-18T23:00:08Z",
"text": "So is it accurate to say that, so far, only Intel Core i7 processors and certain (Phenom?) AMD processors enjoy a speed bump from -4way?
",
"nested_level": 0
},
{
"id": 2380,
"thread_id": 184,
"source_id": "41",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10164#msg10164",
"date": "2010-08-18T23:02:25Z",
"text": "So is it accurate to say that, so far, only Intel Core i7 processors and certain (Phenom?) AMD processors enjoy a speed bump from -4way?
And i5, at least on my macbookpro
Any non-Mac i5 love?
Windows i5 64-bit got slower here.
[correction -- not true. Windows doesn't have -4way, and the Linux machines are Xeons.]
",
"nested_level": 0
},
{
"id": 2382,
"thread_id": 184,
"source_id": "43",
"poster_name": "vess",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=621",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10214#msg10214",
"date": "2010-08-19T06:41:27Z",
"text": "My Core i5 laptop (Ubuntu) doubled in speed. Actually, it didn't double in speed. It stayed the same speed, but only uses half the CPU now. I can't get it to go back to full CPU usage. That said, my laptop is a lot cooler when generating blocks now. I'll post back if I see it successfully go up to 100% usage.
",
"nested_level": 0
},
{
"id": 2383,
"satoshi_id": 402,
"thread_id": 184,
"source_id": "44",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10281#msg10281",
"date": "2010-08-19T19:07:43Z",
"text": "Any non-Mac i5 love?
Windows i5 64-bit got slower here.
That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled.
And i5, at least on my macbookpro
Good, so I take it that's a confirmation that it's working on Mac as well?
Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version.
And i5, at least on my macbookpro
Good, so I take it that's a confirmation that it's working on Mac as well?
Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version.
Yep, it's working all right. The number I had posted were from an old svn revision patched with tcatm's changes, but today I compiled trunk and while I had to once again tweak the makefile, after I did it works great with the numbers matching what I experienced before.
Changes I did for my system are below, and while some are cosmetic, like removing wx-config from making bitcoind, just to avoid the warnings if you don't have it installed, others are system specific, like the DEPS dir, and the fact I don't have 32bit libs which makes the link step fail if -arch i386 is there.
The bsddb changes are, I believe, a typo. Includes and Libs point to db46, but then the object list for the linker states db48. Anyway, here's the diff for what got me going:
Index: makefile.osx
===================================================================
--- makefile.osx (revision 139)
+++ makefile.osx (working copy)
@@ -6,29 +6,29 @@
# Laszlo Hanyecz (solar@heliacal.net)
CXX=llvm-g++
-DEPSDIR=/Users/macosuser/bitcoin/deps
+DEPSDIR=/opt/local
INCLUDEPATHS= \\
- -I\"$(DEPSDIR)/include\"
+ -I\"$(DEPSDIR)/include\" -I\"$(DEPSDIR)/include/db46\"
LIBPATHS= \\
- -L\"$(DEPSDIR)/lib\"
+ -L\"$(DEPSDIR)/lib\" -L\"$(DEPSDIR)/lib/db46\"
-WXLIBS=$(shell $(DEPSDIR)/bin/wx-config --libs --static)
+WXLIBS=
LIBS= -dead_strip \\
- $(DEPSDIR)/lib/libdb_cxx-4.8.a \\
- $(DEPSDIR)/lib/libboost_system.a \\
- $(DEPSDIR)/lib/libboost_filesystem.a \\
- $(DEPSDIR)/lib/libboost_program_options.a \\
- $(DEPSDIR)/lib/libboost_thread.a \\
+ $(DEPSDIR)/lib/db46/libdb_cxx-4.6.a \\
+ $(DEPSDIR)/lib/libboost_system-mt.a \\
+ $(DEPSDIR)/lib/libboost_filesystem-mt.a \\
+ $(DEPSDIR)/lib/libboost_program_options-mt.a \\
+ $(DEPSDIR)/lib/libboost_thread-mt.a \\
$(DEPSDIR)/lib/libcrypto.a
-DEFS=$(shell $(DEPSDIR)/bin/wx-config --cxxflags) -D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0
+DEFS=-D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0 -DFOURWAYSSE2
DEBUGFLAGS=-g -DwxDEBUG_LEVEL=0
# ppc doesn't work because we don't support big-endian
-CFLAGS=-mmacosx-version-min=10.5 -arch i386 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)
+CFLAGS=-mmacosx-version-min=10.5 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)
HEADERS=headers.h strlcpy.h serialize.h uint256.h util.h key.h bignum.h base58.h \\
script.h db.h net.h irc.h main.h rpc.h uibase.h ui.h noui.h init.h
@@ -42,6 +42,7 @@
obj/rpc.o \\
obj/init.o \\
cryptopp/obj/sha.o \\
+ obj/sha256.o \\
cryptopp/obj/cpu.o
@@ -55,7 +56,7 @@
$(CXX) -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_ASM -o $@ $<
bitcoin: $(OBJS) obj/ui.o obj/uibase.o
- $(CXX) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)
+ $(CXX) $(shell $(DEPSDIR)/bin/wx-config --cxxflags) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(shell $(DEPSDIR)/bin/wx-config --libs --static) $(LIBS)
obj/nogui/%.o: %.cpp $(HEADERS)
The difference between new and older CPUs is pretty easy to explain.
Older microarchitectures have 64-bit mmx/sse execution units and split 128bit sse ops into 2 64bit microops.
Newer archs have 128bit sse units.
- AMD K8: 2 64bit units
- intel Core/Core2: 3 64bit units
- AMD K10: 2 128bit units
- intel nehalem: 3 128bit units
K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
nehalem = xeon 34xx/35xx/36xx/55xx/56xx/65xx/75xx, i3/i5/i7
Thanks for clearing that up. I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel.
There's no hope for Core/Core2 then. They only have half the SSE2 hardware.
Strange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one.
",
"nested_level": 0
},
{
"id": 2387,
"thread_id": 184,
"source_id": "48",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10",
"url": "https://bitcointalk.org/index.php?topic=820.msg10754#msg10754",
"date": "2010-08-23T05:45:17Z",
"text": "Intel Atom 230 @ 1.60GHz. Linux 32-bit.
(Acer Aspire Revo)
Stock: 438 khash/sec (1 proc gives 354)
4way: 254 khash/sec
So you can take this one off the powerhouse list.
Anybody catch the new AMD Bulldozer press release? If I understand correctly, it should be capable of processing 8 64bit hashes, per core, at the same time. Would be quite a speed boost using this same code design.
Slashdot has the article.
PC Perspective has the details.
Was also covered by
AnandTech back in November, 2009.
- AMD K10: 2 128bit units
- intel nehalem: 3 128bit units
This probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy.
I just reviewed the sourcecode as I had a few ideas to optimize it further and I noticed that 4way is partly broken:
from main.cpp:
for (int j = 0; j < NPAR; j++)
{
if (thash[7][j] == 0)
{
for (int i = 0; i < sizeof(hash)/4; i++)
((unsigned int*)&hash)[i] = thash[i][j];
pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
}
}
The code will only process one hash (the last with thash[7] == 0) out of 32 hashes even when there is more than one hash that might be a correct one.
Somethine like this should fix it but it won't be safe at higher difficulties. Also, I'm not sure whether the byte order should be reversed or not. Could someone review this?
unsigned int min_hash = ~1;
for (int j = 0; j < NPAR; j++)
{
if (thash[7][j] == 0)
{
if(thash[6][j] < min_hash) {
min_hash = thash[6][j];
for (int i = 0; i < sizeof(hash)/4; i++)
((unsigned int*)&hash)[i] = thash[i][j];
pblock->nNonce = ByteReverse(tmp.block.nNonce + j);
}
}
}
The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower.
",
"nested_level": 0
},
{
"id": 2392,
"thread_id": 185,
"source_id": "1",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9494#msg9494",
"date": "2010-08-15T19:04:11Z",
"text": "seems a block at height 74638 has expoited a bug in the net. It uses an integer overflow to make a negative total transaction. The two transaction outputs are:
out Value:92233720368.54(7ffffffffff85ee0) out Value:92233720368.54(7ff
ffffffff85ee0)
We need a fix asap
Edit:
(satoshi)
0.3.10 patch download links here:
http://bitcointalk.org/index.php?topic=827.0Whether to stop generating depends on the possible solution. If there are ever bad blocks, I can imagine an officially patched Bitcoin could be hard coded to exclude bad transactions contained in the block chain so that although the bad transactions would still be sitting in the chain, they would be ignored. I recommend people keep on generating if you were previously generating but be cautious about transactions until we hear back from Satoshi.The
recommendation is to stop generating.
Until there is a better fix... after a very small amount of testing this seems to work:
--- a/main.h
+++ b/main.h
@@ -473,8 +473,12 @@ public:
// Check for negative values
foreach(const CTxOut& txout, vout)
+ {
if (txout.nValue < 0)
return error(\"CTransaction::CheckTransaction() : txout.nValue negative\");
+ if (txout.nValue > 21000000*COIN)
+ return error(\"CTransaction::CheckTransaction() : txout.nValue over-max\");
+ }
if (IsCoinBase())
{
@@ -520,6 +524,8 @@ public:
int64 nValueOut = 0;
foreach(const CTxOut& txout, vout)
{
+ if (txout.nValue > 21000000*COIN)
+ continue; // ignore over-max-value...
if (txout.nValue < 0)
throw runtime_error(\"CTransaction::GetValueOut() : negative value\");
nValueOut += txout.nValue;
You'll need to re-download the part of the block chain before the bad block-- remove the blkindex.dat and blk0001.dat files. I started with
knightmb's blockchain snapshot.
Or the same patch from your github,
http://gist.github.com/525921 which gives us the raw patch that can be applied directly,
http://gist.github.com/raw/525921/fe2ad7583f0dd2444caa0b3e24d750bf45cac11b/Quick%20fix%20block%2074652EDIT: I was unable to patch directly using this, perhaps CRLF problems.
I applied your changes manually, and uploaded the result here:
http://yyz.us/bitcoin/patch.bitcoin-gavin-overflow-quick-fixHere's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly.
bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error(\"CTransaction::CheckTransaction() : vin or vout empty\");
// Check for negative and overflow values
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error(\"CTransaction::CheckTransaction() : txout.nValue negative\");
if (txout.nValue > 21000000 * COIN)
return error(\"CTransaction::CheckTransaction() : txout.nValue too high\");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error(\"CTransaction::CheckTransaction() : txout total too high\");
}
if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error(\"CTransaction::CheckTransaction() : coinbase script size\");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error(\"CTransaction::CheckTransaction() : prevout is null\");
}
return true;
}
Don't sticky the topic, nobody looks up there. There'll be enough posts to bump.
It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.
A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this.
",
"nested_level": 0
},
{
"id": 2399,
"thread_id": 185,
"source_id": "8",
"poster_name": "kencausey",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=653",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9533#msg9533",
"date": "2010-08-15T21:09:53Z",
"text": "I'm afraid the community is just too big and distributed now to expect much in the way of voluntary quick action on anything, especially generation which I'm sure many have on automatic and largely unmoderated.
",
"nested_level": 0
},
{
"id": 2400,
"thread_id": 185,
"source_id": "9",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9534#msg9534",
"date": "2010-08-15T21:10:33Z",
"text": "Looks good to me.
Can you easily hardcode a check for the bad block's hash at startup and orphan it and subsequent blocks if they're on the best-block chain?
It's painful to have to re-download all or most of the chain to fix this...
",
"nested_level": 0
},
{
"id": 2401,
"thread_id": 185,
"source_id": "10",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9535#msg9535",
"date": "2010-08-15T21:15:18Z",
"text": "Looks good to me.
Can you easily hardcode a check for the bad block's hash at startup and orphan it and subsequent blocks if they're on the best-block chain?
It's painful to have to re-download all or most of the chain to fix this...
Or just a quick re-verification of all blocks. After all, it is
5x faster than it used t be.
Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?
",
"nested_level": 0
},
{
"id": 2403,
"thread_id": 185,
"source_id": "12",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9540#msg9540",
"date": "2010-08-15T21:26:09Z",
"text": "Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?
http://knightmb.dyndns.org/files/bitcoin/blocks/I prefer to just re-download them.
Block verification after the patch but before everyone upgrades is going to be SLOW! It'll probably cause the next difficulty adjustment to decrease significantly. Of course everyone will probably have upgraded by the time the next adjustment rolls around, so we'll probably roll through it relatively quickly.
",
"nested_level": 0
},
{
"id": 2405,
"thread_id": 185,
"source_id": "14",
"poster_name": "kencausey",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=653",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9545#msg9545",
"date": "2010-08-15T21:36:30Z",
"text": "Edit: Hmm, I see there is an info file included which might just clue me in.
How about explaining to us stupid newbies what we would do with the blockchain once we download it?
",
"nested_level": 0
},
{
"id": 2406,
"thread_id": 185,
"source_id": "15",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9547#msg9547",
"date": "2010-08-15T21:38:41Z",
"text": "How about explaining to us stupid newbies what we would do with the blockchain once we download it?
It means replacing files in the bitcoin data directory. It is not recommended, unless you know what you're doing.
Easiest and safest way is to backup wallet.dat then redownload everything.
Patch is uploaded to SVN rev 132!
For now, recommended steps:
1) Shut down.
2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files)
3) Upgrade.
4) It should start out with less than 74000 blocks. Let it redownload the rest.
If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
I'll build releases shortly.
",
"nested_level": 0
},
{
"id": 2408,
"thread_id": 185,
"source_id": "17",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9549#msg9549",
"date": "2010-08-15T21:40:31Z",
"text": "How about explaining to us stupid newbies what we would do with the blockchain once we download it?
While Bitcoin is not running, you put it in your Bitcoin data directory. ~/.bitcoin on Linux. If you want to re-download the whole chain, you just delete the file from the data directory while Bitcoin is not running.
I'm going to be move my blk00x.dat files and blkindex.dat file out of by data directory and restart the client. Those are the correct files, right?
Edit: I'll also backup the whole directory, like I usually do before upgrades.
If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.
Anybody wanna volunteer to create blk*.dat for block chain <= 64637 ?
Maybe the official binaries could simply ship a known-good block chain, to save time and bandwidth?
Will the bug fix include the
4-way SSE2 patch of 0.3.9 rc2? Thanks for letting me know that
it is included, theymos.
Please release another release candidate when you have a moment if it is not included.What about the transactions from 74000 to the invalid block. Are those all invalid now as well?
Only the blocks including and after the invalid block are invalid. All previous blocks are valid.
What about the transactions from 74000 to the invalid block. Are those all invalid now as well?
Only this aberrant transaction and coins generated after it in the block chain will be removed. All other transactions will continue to exist.
Will the bug fix include the 4-way SSE2 patch included in 0.3.9rc2?
It's included.
Oh, yeah, just noticed this topic. I can't remember when those block chains were snapshot, but I'll update it to be more descriptive (like block 64,000, etc.)
Good thing I keep those around.
My web server sits on a fiber, so it won't be a big deal everyone starts to download those files at once (at least for the more technical people).
[edit] Shutting down all the remaining servers and super-nodes I left running. Hope that helps.
knightmb, do you still have any of your monster network available to turn on to help build the new valid chain?
",
"nested_level": 0
},
{
"id": 2414,
"thread_id": 185,
"source_id": "23",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9561#msg9561",
"date": "2010-08-15T22:18:17Z",
"text": "knightmb, do you still have any of your monster network available to turn on to help build the new valid chain?
Not anymore, was shutdown on the last day of the month for July, all I have left are about a 2 dozen servers, but near nothing of what I had before.
Here's something for your Signature if you're interested.
[i][color=red][b]*** WARNING ***[/b][/color] DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638). We are investigating a problem. ([url=http://bit.ly/afalQU]more[/url])[/i]
I shortened the URL since the signature can only contain 300 characters. Also, can we get some color on the news warning? It's not very noticeable.
I can build a block chain to the desired number using a combo of the old block chain and a client with the latest block chain (minus the bad stuff), what number should I shot for?
",
"nested_level": 0
},
{
"id": 2417,
"thread_id": 185,
"source_id": "26",
"poster_name": "kencausey",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=653",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9565#msg9565",
"date": "2010-08-15T22:31:07Z",
"text": "74637 is the last good block
",
"nested_level": 0
},
{
"id": 2418,
"thread_id": 185,
"source_id": "27",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9566#msg9566",
"date": "2010-08-15T22:34:03Z",
"text": "74637 is the last good block
Ok, good, I've relabeled the old block chain on my site, I'll try to get as close to that number as I can. Basically, I'm just loading up two clients, one with the old chain, another with the sorta bad chain at the end. I'm going to let the first client get as close to the number as I can before stopping it. Then snapshot off that block chain. Since it does about 500 at a time, I'll probably be able to get it close to 74,501
i'v got one of a w7-machine count 74602, if that helps.
",
"nested_level": 0
},
{
"id": 2420,
"thread_id": 185,
"source_id": "29",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9570#msg9570",
"date": "2010-08-15T22:44:55Z",
"text": "I already said that I have it right at 74637.
Satoshi said it needs to be before 74,000
So long as a the person who creates it has a patched client and downloads the whole chain, optimally from another computer on their local network, then it should stop at the right place automatically.
Satoshi said it needs to be before 74,000
He didn't, he said \"you'll want one\", not that it
needs to be, a little different.
and if \"..Only the blocks including and after the invalid block are invalid. All previous blocks are valid..\", it doesn't need to be before 74000.
just wanted to save knightmb some time, but yours is bigger than mine anyway.
Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks.
tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.
I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch.
If you have problems building because of it, then edit makefile.unix and:
- remove -DFOURWAYSSE2
- remove obj/sha256.o from the end of these lines:
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o
The 0.3.10 linux build
will have the -4way option when I build it.
Here are the patch downloads for Windows:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.zipSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
Steps:
1) Shut down.
2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.
http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/413168038/BitcoinBlocks.torrent3) Upgrade to 0.3.10.
4) It should start out with less than 74000 blocks and redownload the rest.
Or if you don't want to mess with downloading blk files, you can just do this:
1) Shut down.
2) Delete (or move) blk*.dat
3) Upgrade to 0.3.10.
4) It redownloads all blocks, probably take about an hour.
Yeah, a little confusing
So I don't need to create one, or do I need to take what you guys already have and just throw it up on the FTP?
Can you dump block data from a windows machine onto a Linux/Mac machine?
[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.
I can't stand the suspense! Do any Jr. Members or higher happen to have an unofficial SVN rev 134 Linux 64-bit build compiled that they'd be willing to share? Yeah, I know the official build is about to be released in a few minutes. It's not terribly important.
Edit: Updated the SVN version number as per satoshi's comment a moment ago.Ah, never mind. Since the SVN version was just updated and the Windows builds were just released, I'll wait.
[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.
Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice.
I just used your old file knightmb and on a rather old system it didn't take me very long to catch up, so I'm inclined to say \"don't bother\".
",
"nested_level": 0
},
{
"id": 2427,
"thread_id": 185,
"source_id": "36",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9578#msg9578",
"date": "2010-08-15T23:21:06Z",
"text": "What block number is it?
It's around 67k. It only took me about 3 minutes to get to the current block.
I think that you should add something about this:
http://bitcointalk.org/index.php?topic=259.0There must be a label on the client that show a warning message if needed
Now everyone have always to check the website, and I think that this is bad.
Cool, works for me!
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 generating faster on i5 and AMD CPU's. Use the \"-4way\" switch to enable it and check if it's faster for you.
Download links:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gzSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
I think that you should add something about this:
http://bitcointalk.org/index.php?topic=259.0There must be a label on the client that show a warning message if needed
Now everyone have always to check the website, and I think that this is bad.
Agree, wanted to do that for a long time, haven't had time to do it.
For now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions.
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.
Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice.
I've put the block number with the file, so you'll know exactly where each stops at.
BitCoinBlocks_Linux_67309.zip
BitCoinBlocks_Windows_67300.zip
I've leave them be. Glad to know I could help
... It already is on block 74638. I assume that means that block is now a good one?
I had some confusion on this myself and got clarification in #bitcoin-dev:
The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one.
Agree, wanted to do that for a long time, haven't had time to do it.
For now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions.
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-listGood
Anyway
I usually check the website, I was thinking to a solution for newbie-users ( that they are more to come on future )
A small bug can be a big problem with a network with a lot of newbie and/or not-informed users. ( and none of them will ever give a look to a source like this:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list )
( sorry for my english, I hope you are still understanding me
)
Updated and combined instructions:
1. Stop generating immediately, close your current client if you have not updated to 0.3.10.
2. Download 0.3.10:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exehttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gzSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
3. (optional) Download a previously known good blockchain:
http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/413168038/BitcoinBlocks.torrentand replace your blk0001.dat and blkindex.dat files with those from the relevant download for your platform.
3b. If you don't download, delete or move the blk0001.dat and blkindex.dat files.
4. Start 0.3.10 and watch it catch up to block 74637 and beyond and help restart things.
Edit:Edit 2: Add more explanation4b. Currently the network has a combination of good and bad nodes (those running versions older than 0.3.10). If you only connect to nodes running old versions, you will be stuck at 74638 blocks. You can fix this by running the client with the options \"-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14\". This specifically connects you to a number of 'known good' nodes and ensures that you receive transactions generated within the network of updated clients. As the number of out of date clients in the network decreases, this will become unnecessary. If you want more nodes or just different ones, you can find a larger list at
http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodes .
my forwarded node counts 74642 as i type (36conn.),
3 other nodes are still at 74638 (8conn. each)
",
"nested_level": 0
},
{
"id": 2437,
"thread_id": 185,
"source_id": "46",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9606#msg9606",
"date": "2010-08-16T00:20:59Z",
"text": "Ya know, in a way, this actually temporarily decreases the difficulty to generate blocks until everyone upgrades. Yeah, it'll be slower, but that just gives each client more time to try to generate the difficult hash.
",
"nested_level": 0
},
{
"id": 2438,
"thread_id": 185,
"source_id": "47",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9609#msg9609",
"date": "2010-08-16T00:29:55Z",
"text": "Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.
What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
",
"nested_level": 0
},
{
"id": 2439,
"thread_id": 185,
"source_id": "48",
"poster_name": "kosovito",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=158",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9615#msg9615",
"date": "2010-08-16T00:39:17Z",
"text": "I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?
",
"nested_level": 0
},
{
"id": 2440,
"satoshi_id": 379,
"thread_id": 185,
"source_id": "49",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9623#msg9623",
"date": "2010-08-16T01:00:45Z",
"text": "Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.
What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.
It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet.
I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?
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=828Most people running clients are not reading this message thread. So... Silly questions:
1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?
",
"nested_level": 0
},
{
"id": 2443,
"thread_id": 185,
"source_id": "52",
"poster_name": "kencausey",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=653",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9627#msg9627",
"date": "2010-08-16T01:06:13Z",
"text": "I added the addnode options and info about the 'stuck at 74638 blocks' issue at
http://bitcointalk.org/index.php?topic=823.msg9595#msg9595Most people running clients are not reading this message thread. So... Silly questions:
1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?
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 helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.
Ya know, in a way, this actually temporarily decreases the difficulty to generate blocks until everyone upgrades. Yeah, it'll be slower, but that just gives each client more time to try to generate the difficult hash.
Of course, this happened right after the difficulty kicked up to 511.7, so all these new \"good\" blocks will have to contend with that. And a good chunk of the network grind power is off on the wrong chain, so new blocks may take a lot longer than 10min to find. At what point will the balancing figure this out and possibly kick the difficulty back down again?
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 say we probably already have more power than the bad chain.
",
"nested_level": 0
},
{
"id": 2447,
"thread_id": 185,
"source_id": "56",
"poster_name": "knightmb",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=345",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9644#msg9644",
"date": "2010-08-16T02:22:05Z",
"text": "I'm chucking as much CPU at this as I can. Yeah, bit of an unfair advantage I guess until everyone upgrades.
My wife's PC already generated 2 of the new blocks (LOL), luck is on her side I guess.
... Of the nodes I'm connected to, more than half are already 0.3.10. ...
That's great news! How did you figure that out, though? I was considering writing a client specially tailored to put itself out there and try to get as many people to connect as possible, then survey their versions and write out a log (in addition to all the normal bitcoin stuff).
On Windows, findstr /c:\"version message\" debug.log
It looks like the bad chain was on block 74678 recently. Can't wait to overtake it.
On the stats at
http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour.
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 say we probably already have more power than the bad chain.
I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/
4b. Currently the network has a combination of good and bad nodes (those running versions older than 0.3.10). If you only connect to nodes running old versions, you will be stuck at 74638 blocks. You can fix this by running the client with the options \"-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14\"
http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodesThe 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 say we probably already have more power than the bad chain.
I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/
We want to keep the older clients connected so that when the correct chain overtakes the incorrect chain, they will switch back to the correct chain. Although I don't know the specifics of how far back in the chain the old chain will accept a branched chain.
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 say we probably already have more power than the bad chain.
I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/
We want to keep the older clients connected so that when the correct chain overtakes the incorrect chain, they will switch back to the correct chain. Although I don't know the specifics of how far back in the chain the old chain will accept a branched chain.
The old clients should accept it all the way back to the last snapshot of release, so this being found so quickly and so long after the last release, it should work in theory. Here's a good test of the theory
Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.
What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.
It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet.
Interesting.. fascinating to watch this work its way through the bowels of the system.
It was block 73746 that I generated.
CTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186)
08/12/10 02:35 generated 50.00
And I sent 49.00 of it to 19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXz (using the broken chain)
Now I'm waiting for that node to figure out it was received, and it's using the new chain.
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 just upgrade and it'll reorg away the bad block chain.
Thanks to everyone for the quick response!
",
"nested_level": 0
},
{
"id": 2456,
"thread_id": 185,
"source_id": "65",
"poster_name": "throughput",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=574",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9746#msg9746",
"date": "2010-08-16T14:35:10Z",
"text": "Would it be useful to have RPC command to chop off the tail of the chain manually,
instead of removind and redownloading the whole chain?
",
"nested_level": 0
},
{
"id": 2457,
"thread_id": 185,
"source_id": "66",
"poster_name": "laszlo",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=143",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9833#msg9833",
"date": "2010-08-16T22:13:00Z",
"text": "So at this point, would a client that has not upgraded also have the correct chain?
",
"nested_level": 0
},
{
"id": 2458,
"thread_id": 185,
"source_id": "67",
"poster_name": "NewLibertyStandard",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=26",
"subject": "Re: overflow bug SERIOUS",
"url": "https://bitcointalk.org/index.php?topic=823.msg9834#msg9834",
"date": "2010-08-16T22:15:32Z",
"text": "So at this point, would a client that has not upgraded also have the correct chain?
Yes. The only exception would be if an unpatched client made another fake transaction and managed to verify it. They would be able to spread that fake block to a few other nodes that haven't upgraded, but the upgraded clients seem to have more power than the unpatched clients, so the bad link would not last long and would not be spread by upgraded clients.
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 restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade.
The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option.
",
"nested_level": 0
},
{
"id": 2460,
"satoshi_id": 376,
"thread_id": 186,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.10 - block 74638 overflow PATCH!",
"url": "https://bitcointalk.org/index.php?topic=827.msg9590#msg9590",
"date": "2010-08-15T23:48:22Z",
"text": "Version 0.3.10 patches the block 74638 overflow bug.
http://bitcointalk.org/index.php?topic=823The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the \"-4way\" switch to enable it and check if it's faster for you.
Download from sourceforge:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip
It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.
adg
",
"nested_level": 0
},
{
"id": 2462,
"thread_id": 187,
"source_id": "2",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: 0.3.10.1 Question on where block should be",
"url": "https://bitcointalk.org/index.php?topic=828.msg9603#msg9603",
"date": "2010-08-16T00:13:49Z",
"text": "my forwarded node counts 74642 as i type (36conn.),
3 other nodes are still at 74638 (8conn. each)
the port-forwarded isnt a fast one though, limited to one core at about 700khash/s.
There are 74643 blocks as I write this. The split is causing some network problems. You should connect your computers to each other with the addnode parameter.
",
"nested_level": 0
},
{
"id": 2464,
"satoshi_id": 377,
"thread_id": 187,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.10.1 Question on where block should be",
"url": "https://bitcointalk.org/index.php?topic=828.msg9608#msg9608",
"date": "2010-08-16T00:28:28Z",
"text": "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 more than 1/8th of the network.
It'll help if you port forward so you can get lots of connections.
",
"nested_level": 0
},
{
"id": 2465,
"satoshi_id": 378,
"thread_id": 187,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 0.3.10.1 Question on where block should be",
"url": "https://bitcointalk.org/index.php?topic=828.msg9612#msg9612",
"date": "2010-08-16T00:37:20Z",
"text": "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.
",
"nested_level": 0
},
{
"id": 2466,
"thread_id": 188,
"source_id": "1",
"poster_name": "bdonlan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=359",
"subject": "[PATCH] Automatic block validation",
"url": "https://bitcointalk.org/index.php?topic=832.msg9654#msg9654",
"date": "2010-08-16T02:57:55Z",
"text": "I've written a patch to help automatically validate cached blocks after validation fixes such as the one that was pushed out today. You can find it at
http://fushizen.net/~bd/blockverify.patchor
http://github.com/bdonlan/bitcoin/commit/b205251959448ca99123f2bc95b088bf06d4ef3bUpon first run with this patch, all blocks will be verified, and any invalid blocks, as well as blocks orphaned by removal of such blocks, will be removed from the block index. A version stamp
(BLOCK_VERIFY_TOKEN in db.cpp) will be then written to the db; this will cause the next run to skip the verification pass. Any future validation fixes can then simply bump BLOCK_VERIFY_TOKEN to force a revalidation of the block chain.
Note that I may be missing some important steps when deleting the old blocks - in particular, no attempt is made to update the wallet, or to prune stored uncommitted transactions. Review would be helpful.
Hmm, it seems I am missing something important - disconnecting transactions which are no longer part of the accepted block chain. I'm going to have to work on this a bit - the naive approach of simply blasting away all TXNs, then reconnecting things is far too slow, and hits the transaction memory limit.
",
"nested_level": 0
},
{
"id": 2468,
"satoshi_id": 389,
"thread_id": 188,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: [PATCH] Automatic block validation",
"url": "https://bitcointalk.org/index.php?topic=832.msg9754#msg9754",
"date": "2010-08-16T15:25:54Z",
"text": "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. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg)
This isn't perfect yet. It still needs to receive one valid block to trigger the reorg.
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
bool CTxDB::LoadBlockIndex()
{
...
// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}
return true;
}
It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
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.
Hi
I think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.
This is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.
If a small country, say Luxembourg, started a bitcoin instance for themselves, they would never know if the German or French government would be hiding a longer chain,
just in case.
If a large bank wanted to disturb the current bitcoin system, they could just spend more CPU power than the current system, start from scratch and generate a completely new chain. They could intervene at any point including the beginning. All work so far would be invalidated.
If a village wanted a small local payment system, they would constantly be in danger of attacks. The mafia could execute a lot of double spending, and then suddenly arrive with a long chain that invalidated all their payments, even though the merchants thought they had acquired the coins.
Anyone, bar the largest most high powered instances of bitcoin, will have this constant threat hanging over them.
The issue appears with network splits as well. After rejoining, one part completely ruins the other part, especially for coins that were present on both sides of the split to start with.
I think, there should be some guarantee that the chain will not be invalidated further back in time than a day, a month, or 100 blocks or whatever.
This problem is related to the problem of how many blocks you want to see before accept a payment (double spending problem). Satoshi has a calculation of this in the
pdf file. However, you need to know the CPU power of the visible honest part relative to the other part (p and q). The problem is that you never know how large the dishonest, or invisible, part is, because it can be hidden as long it wants to. Or it can be formed in the future. You never know.
What about this proposal? A node checkpoints blocks that are older than some threshold. The threshold could be a difficulty weighted block count, say a 100 blocks of 8 zero
bits. If a node receives a block chain that requires changing something that is older than its checkpoint, it refuses the chain. Each node would have its own checkpoint. But the honest nodes would be close. Their deviation would be small compared to the size of the threshold (100 blocks).
What would happen when two nodes disagree further back in time than the threshold of one of them. They should be considered forked currencies. One currency became two.
So the village, or Luxembourg, could ignore a hidden outside world, except for the very last part of the block chain.
The small village could use a very low threshold. The latency within the village is milliseconds. The could have block generation every 10 seconds. They could have a threshold of 5 blocks for instance. There is no valid reason, for a node, to stay hidden for that long in the village. If a computer loses its connection, it will just download the chain when it get online again; if it will tries to push a long block chain down the throat of the rest of the village, it has effectively created a new currency for itself.
",
"nested_level": 0
},
{
"id": 2471,
"thread_id": 189,
"source_id": "2",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9760#msg9760",
"date": "2010-08-16T16:09:10Z",
"text": "There is some checkpointing in the code that works like that. But it is not dynamic. It only updates when the dev team decides to add a new check point. But that does validate your point.
But I learned there are some addition protections as well but I haven't read that code yet. Something like refusing chains if they change more that X hours work. It probably worth reviewing other threads to find it. Knightmb was involved in that discussion if it helps to find it.
",
"nested_level": 0
},
{
"id": 2472,
"thread_id": 189,
"source_id": "3",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9762#msg9762",
"date": "2010-08-16T16:11:27Z",
"text": "I think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.
This is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.
If a small country, say Luxembourg, started a bitcoin instance for themselves, they would never know if the German or French government would be hiding a longer chain, just in case.
These are simply good reasons for not starting your own little separate independent bitcoin chain. For the best security stay with the main big chain. Instances such as yesterday's should be so rare you don't need to worry about them. The problem of being out powered by some other big entity is well understood and is minimized by staying with the biggest bitcoin chain there is.
Note that the current bitcoin net is still tiny and you shouldn't really rely on it yet for anything serious in my opinion.
1) The point of Bitcoin is to be a global currency, it doesn't make sense to use Bitcoin as a replacement for a national currency
2) Block chain checkpoints are already done at each release of the client software
3) To generate a longer chain from scratch doesn't require more power (CPU time) then the network currently has, it requires more power then the network has put into the chain since the start. The current chain has had unbelievable amounts of CPU time go into generating it.
",
"nested_level": 0
},
{
"id": 2474,
"thread_id": 189,
"source_id": "5",
"poster_name": "mkrogh",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=696",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9778#msg9778",
"date": "2010-08-16T17:33:14Z",
"text": "1) The point of Bitcoin is to be a global currency, it doesn't make sense to use Bitcoin as a replacement for a national currency
You can say that, but it would be nice to use it on a smaller scale. It is interesting to think about how to achieve this without making the system too vulnerable.
Checkpoints could be one possibility. Maybe there are others.
2) Block chain checkpoints are already done at each release of the client software
[\\quote]
A decentralized system does not have centralized upgrades, and there is no one program that everybody will use.
Do you envision a global currency with only one client program?
And where in the chain is the checkpoint placed exactly, and what node decides this.
3) To generate a longer chain from scratch doesn't require more power (CPU time) then the network currently has, it requires more power then the network has put into the chain since the start. The current chain has had unbelievable amounts of CPU time go into generating it.
Of course time matters. But, you don't know how long the hidden part has been working. And if it has more power, it will eventually have done more work as well. But I agree, that for one giant global system, this might not be a big issue.
How would people react if some governments declared that they didn't like the system, and would now start an independent chain to make all current coins worthless. That in itself might create a panic, and destroy the system. With more recent checkpoints, the system would be less speculative.
Let me turn it around. With a global bitxoin system, what is a good reason that nodes can not freeze all blocks older than say 10 hours of accumulated difficulty. Where is the downside? Is it really considered a desired feature that a part of the network can be hidden for many hours and come back again with a long chain? Or is it just that checkpoints
haven't been implemented because the system is still so new?
Cheers.
Let me turn it around. With a global bitxoin system, what is a good reason that nodes can not freeze all blocks older than say 10 hours of accumulated difficulty. Where is the downside? Is it really considered a desired feature that a part of the network can be hidden for many hours and come back again with a long chain? Or is it just that checkpoints
haven't been implemented because the system is still so new?
Under such a system, a bad chain (such as the one we fixed yesterday) would get locked in if it lasted more then 10 hours. I'm sorry, but automatic checkpoints are a bad idea.
What is a bad chain?
Could you elaborate more on why checkpoints are bad?
",
"nested_level": 0
},
{
"id": 2477,
"satoshi_id": 394,
"thread_id": 189,
"source_id": "8",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9816#msg9816",
"date": "2010-08-16T20:20:53Z",
"text": "There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.
The only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block.
",
"nested_level": 0
},
{
"id": 2478,
"thread_id": 189,
"source_id": "9",
"poster_name": "mkrogh",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=696",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9822#msg9822",
"date": "2010-08-16T20:54:47Z",
"text": "Satoshi, the checkpoint is not used to make a judgement of which chain is better, but just to make sure that very old coins will not be invalidated in the \"open\" part of the network.
The software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.
If a longer chain, predating the checkpoint arrived, the node would reject it. This would effectively fork the currency, but so what. In practice, it would just exclude the hidden
part. The \"honest\" part would continue along. Too bad for those with a long hidden chain. But they chose to be offline for too long.
The network, I see, is one of a lot of online nodes, visible to anyone who wants to see them. This is the core of the network. They will communicate so often, that no one will get 1000 blocks ahead of others. They will transmit their results continously, not collect them in a batch of 1000 blocks.
Then there are potential offline nodes, dishonest nodes etc. If they suddenly show up with a very long chain, there is no reason not to reject them. Or I don't see that reason.
The public internet will never get fragmented, in a major way,for days. And bitcoin is not suitable for such a situation, even though you technically can make it so by erasing all blocks in all but one of the fragmented components after the rejoin.
You have a manual checkpoint, you say, which exactly shows that checkpoints are possible.
",
"nested_level": 0
},
{
"id": 2479,
"thread_id": 189,
"source_id": "10",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9824#msg9824",
"date": "2010-08-16T21:15:03Z",
"text": "
The software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.
If a longer chain, predating the checkpoint arrived, the node would reject it.
Rather than reject it, it could save a backup of the original and accept the new chain tentitively if it's moving back more than, say, two weeks. So about 2000 blocks. And it could also notify the user that it has a new blockchain that reports a reversal of fortune so far back, and give the user the chance to find out about it before accepting the new blockchain. Odds are that if the user doesn't know what is happening, he soon will since every other user paying attention at the time will also know there is something to look into. Bitcoin is a very well automated system, but absolute automation is not often wise. Talented support needs to know that something is broken asap. This is another example of a 'watchdog' process and/or function that could add security to the network. I think that, even though this should have been submitted to the test network, the release of this mal-formed transaction has highlighted an issue fairly early in the lifespan of Bitcoin. Which allowed the small community to respond to it quickly and effectively. This would become much harder to do in the future, if many people start using it, since most of them will not be programmers, and many won't be paing the level of attention to the client as the beta system currently needs.
The checksum is just the hash at a single particular block such that new chains can be started and can grow, but once a client with the checksum included reaches that block block number, it won't accept any hash except the checksum.
Is that correct?
So if someone wanted to create an alternative chain with the same genesis block, they would need to checksum a block after the genesis with a different hash before they connected to the live network. If they ever reached the checksum in the official client, they would need to make sure that checksum was not included in their own Bitcoin client.
How is the strength of the chain calculated? Is it length and checksum only or does it measure a single block at difficulty 500 as more valid than ten blocks at difficulty one? I presume that it's probably length and checksum only which would mean that all transactions before the checksum are pretty well safe forever, but blocks after the checksum are only as strong as the current strength of the network until the next checksum comes along.
",
"nested_level": 0
},
{
"id": 2481,
"satoshi_id": 396,
"thread_id": 189,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: checkpointing the block chain",
"url": "https://bitcointalk.org/index.php?topic=834.msg9843#msg9843",
"date": "2010-08-16T23:01:48Z",
"text": "How is the strength of the chain calculated?
Total proof-of-work.
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 counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't
not have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded.
The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11.
It would reduce the confusion we had here:
... It already is on block 74638. I assume that means that block is now a good one?
I had some confusion on this myself and got clarification in #bitcoin-dev:
The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one.
Agreed. Seems like a change for the better.
",
"nested_level": 0
},
{
"id": 2484,
"thread_id": 190,
"source_id": "3",
"poster_name": "Tilka",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=687",
"subject": "Re: blocks minus 1",
"url": "https://bitcointalk.org/index.php?topic=837.msg9768#msg9768",
"date": "2010-08-16T16:34:24Z",
"text": "+1
Offtopic: Does this forum have some kind of upvote plugin or something?
",
"nested_level": 0
},
{
"id": 2485,
"thread_id": 190,
"source_id": "4",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: blocks minus 1",
"url": "https://bitcointalk.org/index.php?topic=837.msg9772#msg9772",
"date": "2010-08-16T16:54:51Z",
"text": "+1
+1
Offtopic: Does this forum have some kind of upvote plugin or something?
+1
Done in SVN rev 137
",
"nested_level": 0
},
{
"id": 2487,
"satoshi_id": 393,
"thread_id": 191,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Checking the block chain on load",
"url": "https://bitcointalk.org/index.php?topic=841.msg9813#msg9813",
"date": "2010-08-16T20:07:46Z",
"text": "SVN rev 139 does a basic check of the block chain after loading.
With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time.
It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number.
",
"nested_level": 0
},
{
"id": 2488,
"thread_id": 191,
"source_id": "2",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Checking the block chain on load",
"url": "https://bitcointalk.org/index.php?topic=841.msg9820#msg9820",
"date": "2010-08-16T20:43:19Z",
"text": "I assume it will take more than 1 second to do.
Do we have to do this every time it starts up
Can we make a menu option for it, to fire it off manually?
And make a counter so that it reminds you to check every n loads/days.
or whenever you update the software.
It just seems that needing to recheck the entire block chain will be a very rare event, so rechecking the block chain all the time is overkill.
In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.
Still, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files.
",
"nested_level": 0
},
{
"id": 2490,
"thread_id": 192,
"source_id": "1",
"poster_name": "epaulson",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=651",
"subject": "Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9937#msg9937",
"date": "2010-08-17T18:45:18Z",
"text": "There has been a lot of debate about what Bitcoins are -- i.e. currency vs. commodity. Also there has been a lot of debate about inflation vs. deflation with respect to Bitcoins, whether people would lend them, at what rates, etc.
I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking. It is a lot like being part of a company (right now a very small company) and being paid in stock shares. There are a fixed number of Bitcoins, as there are a fixed number of shares in a company (barring new issues/etc.).
The primary value of Bitcoins right now is the hope that they will someday be worth significantly more than they are right now. For that to happen, the Bitcoin enterprise as a whole needs to gain collective value. We, as employee/owners of Bitcoin need to generate that added value. The most obvious way is to facilitate internet commerce by bartering shares of Bitcoin for other goods. The collective computational effort of all the employee/owners helps ensure that the barter is fair by keeping a record of each transaction. The individual efforts of some Bitcoiners are helping to make the barter of Bitcoins easier or more useful.
Regarding lending/borrowing of Bitcoins, to me it is analogous to lending/borrowing stock. The primary reason to borrow Bitcoins would be because you think they are overvalued and will be worth less when you have to return them. When you borrow the Bitcoins, you can sell them now (barter them now) and hopefully it will cost you less to buy them back at a later date so that you can return them to your lender (probably plus a fee).
In essence, Bitcoins are like a \"direct public offering\" of stock in the Bitcoin enterprise.
",
"nested_level": 0
},
{
"id": 2491,
"thread_id": 192,
"source_id": "2",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9940#msg9940",
"date": "2010-08-17T19:11:55Z",
"text": "I want to be the first to say \"No, they are not!\"
I'll edit this to support that statement later. :-)
--- Edit ---
It is very important to any new venture to NOT define it in terms of a well known scam. No one here would say bitcoin is like a Ponzi scheme except without the scam part.
But that is what you are doing by saying, it's like issuing stock in a corporation, except without all that bother of actually creating a product. Let's just consider the stock the product and get right to selling it! It's a limited edition product, so its price will vary based upon supply and demand.
Trust me, that metaphor has been used for thousands of scams. It is equivalent to a \"red flag\" warning to all authorities.
You are really much better saying bitcoins are like sets of collectable poker chips. Some people will want them, some will not. If lots of people want them you can sell each poker chip separately.
",
"nested_level": 0
},
{
"id": 2492,
"thread_id": 192,
"source_id": "3",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9943#msg9943",
"date": "2010-08-17T19:27:07Z",
"text": "This is by far the best way to think about bit coins. It clearly explains why they have value, where the value comes from (productive employee/owners).
The only reason not to think about it this way is legal issues regarding issuing stock. But this is the fundamental problem with all regulations, there are always \"multiple ways to think about the same thing\". Changing the description does not change the nature of things though.
",
"nested_level": 0
},
{
"id": 2493,
"thread_id": 192,
"source_id": "4",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9944#msg9944",
"date": "2010-08-17T19:35:26Z",
"text": "Stock represents a \"share\" of ownership where the sum of all shares equals 100%
Thus each bitcoin represents a percentage of the total.
Bit coins have a \"market cap\" of $1.38M
The only \"moral\" inflation is a \"stock split\".
",
"nested_level": 0
},
{
"id": 2494,
"thread_id": 192,
"source_id": "5",
"poster_name": "Red",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=525",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9946#msg9946",
"date": "2010-08-17T19:42:49Z",
"text": "Bit coins have a \"market cap\" of $1.38M
1.38M BTC right? It is much less in USD at the moment I think.
I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking. It is a lot like being part of a company (right now a very small company) and being paid in stock shares. There are a fixed number of Bitcoins, as there are a fixed number of shares in a company (barring new issues/etc.).
This is not quite right either, I think. However, I have heard the explaination that the US FRN is akin to a national stock with a reverse dividend, so if this manner of thinking about it helps some people wrap their heads around it, then I won't object. That is, other than to say that this is an analogy only.
Personally, I don't think that there is anything we really can compare Bitcoins to that anyone really would have any prior experience with. Bitcoin is something altogether new in the realm of trade. It is a solution to a set of problems, and (potentially) serves as a solution well. I don't, personally, think that it's a good idea to compare Bitcoin to *anything*. Expecially since most people, including most people that seem to post often on this forum, lack a true understanding of what these other comparitive things are. The best thing to say to describe Bitcoin is to talk about *Bitcoin*, and accurately describe how the system works as well as what it was designed to accomplish.
Think about this, children have experience with money very young, but have you ever tried to explain what money actually is to a child? Complete understanding of a monetary system is not a requirement of it's successful use.
Bit coins have a \"market cap\" of $1.38M
1.38M BTC right? It is much less in USD at the moment I think.
Yeah, I don't know where he got that from.
3.75M BTC have been \"released\" The \"marginal bitcoin\" is trading for about 7 cents right now. I don't really know if it's useful to multiply those numbers together, but if you do you don't get $1.38M anyway.
Edited above and reposted so you don't have to look up.
I really wanted pride of place on this one.
------------
It is very important to any new venture to NOT define it in terms of a well known scam. No one here would say bitcoin is like a Ponzi scheme except without the scam part.
But that is what you are doing by saying, it's like issuing stock in a corporation, except without all that bother of actually creating a product. Let's just consider the stock the product and get right to selling it! It's a limited edition product, so its price will vary based upon supply and demand.
Trust me, that metaphor has been used for thousands of scams. It is equivalent to a \"red flag\" warning to all authorities.
You are really much better saying bitcoins are like sets of collectable poker chips. Some people will want them, some will not. If lots of people want them you can sell each poker chip separately.
",
"nested_level": 0
},
{
"id": 2498,
"thread_id": 192,
"source_id": "9",
"poster_name": "bytemaster",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=611",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg9998#msg9998",
"date": "2010-08-18T00:35:23Z",
"text": "$0.06 per BTC * 23,000,000 total potential shares = $1.38M market cap. Most shares are held by the \"corporation\" which is exchanging them for processing power over time.
This is just one way of looking at the coins. I contend that if some rich dude held 95% of all gold and he was selling gold for processing time at a fixed rate that it would not be considered monetary inflation any more than an individual with 1% of all gold in saving deciding to spend it. The fact that this \"rich dude\" is the the bitcoin algorithm does not change the fact that there are only 23,000,000 possible BTC.
",
"nested_level": 0
},
{
"id": 2499,
"thread_id": 192,
"source_id": "10",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg10002#msg10002",
"date": "2010-08-18T01:07:04Z",
"text": "$0.06 per BTC * 23,000,000 total potential shares = $1.38M market cap. Most shares are held by the \"corporation\" which is exchanging them for processing power over time.
This is just one way of looking at the coins. I contend that if some rich dude held 95% of all gold and he was selling gold for processing time at a fixed rate that it would not be considered monetary inflation any more than an individual with 1% of all gold in saving deciding to spend it. The fact that this \"rich dude\" is the the bitcoin algorithm does not change the fact that there are only 23,000,000 possible BTC.
Isn't the limit just shy of 21,000,000 possible BTC?
Isn't the limit just shy of 21,000,000 possible BTC?
That's right. It is under 21M because amounts less than .00000001 get rounded away.
Just for reference:
Market capitalization/capitalisation (often market cap) is a measurement of size of a business enterprise (corporation) equal to the share price times the number of shares outstanding (shares that have been authorized, issued, and purchased by investors) of a public company.
I don't think the un-generated shares would be counted. They would be authorized shares, but they have not been issued through their IPO phase yet.
",
"nested_level": 0
},
{
"id": 2502,
"thread_id": 192,
"source_id": "13",
"poster_name": "fresno",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=507",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg10022#msg10022",
"date": "2010-08-18T03:40:11Z",
"text": "\"the US FRN is akin to a national stock with a reverse dividend,..\" ROTFLOL!
I challenge this group to think simple!
Bitcoin is something we use, but Bitcoin is not the use! It is simply a machine. Don't give it names it doesn't deserve.
",
"nested_level": 0
},
{
"id": 2503,
"thread_id": 192,
"source_id": "14",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Bitcoins are most like shares of common stock",
"url": "https://bitcointalk.org/index.php?topic=845.msg10042#msg10042",
"date": "2010-08-18T10:41:02Z",
"text": "\"the US FRN is akin to a national stock with a reverse dividend,..\" ROTFLOL!
I challenge this group to think simple!
Bitcoin is something we use, but Bitcoin is not the use! It is simply a machine. Don't give it names it doesn't deserve.
Bingo! I've been following this thread and others thinking to myself \"why the money obsession?\". Even those that argue on different economic philosophies compare to money, use money, use the lack of money, money, money, money...
I compare Bitcoins to beans... when we played cards as kids we used beans as measure of wins / losses. We didn't trade it for money, we didn't play for \"make believe money\", we played for beans. It worked because we all agreed that beans where the game measure, and because there was a limited supply of them (in our game table, that is).
If we had some special engineered beans instead of Bitcoins, that took a full hour to produce a batch and for some quantic weirdness could only be produced one batch at a time in the whole universe, but anyone could try and grow them, we could use those instead of BTCs, with the obvious caveat of not being virtual, of course... They wouldn't be money, they would pretty much not have any value except for what you and your peers agree it had. It's the same. If I think you whispering 545 decimals from pi to my ear is worth me giving you a deed to my house, does that make pi, or it's value, a currency?
I compare Bitcoins to beans... when we played cards as kids we used beans as measure of wins / losses. We didn't trade it for money, we didn't play for \"make believe money\", we played for beans. It worked because we all agreed that beans where the game measure, and because there was a limited supply of them (in our game table, that is).
If we had some special engineered beans instead of Bitcoins, that took a full hour to produce a batch and for some quantic weirdness could only be produced one batch at a time in the whole universe, but anyone could try and grow them, we could use those instead of BTCs, with the obvious caveat of not being virtual, of course... They wouldn't be money, they would pretty much not have any value except for what you and your peers agree it had...
You could trade beans for marbles or baseball cards, but they would be totally independent of the bean thing, right?
I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking.
I'd like to submit that I think the most apt description of bitcoin is that it is most like a Global Exchange Trading System (GETS) which is a variation on the LETS concept that isn't for hippies.
Descriptively it differs because it's community is loosely knit and global rather than an intertwined small-town. As such, there can be no commonly trusted party to operate and monitor the system, so that function is trusted to redundancy and mathematics. (block list)
LETS communities can rely on \"local knowledge\" of peoples historical behavior and intentions. As such it is perfectly reasonable for them to advance credit to people (negative balances) in certain situations. In a GETS community advanced knowledge of all parties and intentions is not practical or even preferred. As such, GETS operates on a zero credit policy. (no negative balances)
Also, since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit for accounting purposes. Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.
----
I think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy.
I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking.
I'd like to submit that I think the most apt description of bitcoin is that it is most like a Global Exchange Trading System (GETS) which is a variation on the LETS concept that isn't for hippies.
Descriptively it differs because it's community is loosely knit and global rather than an intertwined small-town. As such, there can be no commonly trusted party to operate and monitor the system, so that function is trusted to redundancy and mathematics. (block list)
LETS communities can rely on \"local knowledge\" of peoples historical behavior and intentions. As such it is perfectly reasonable for them to advance credit to people (negative balances) in certain situations. In a GETS community advanced knowledge of all parties and intentions is not practical or even preferred. As such, GETS operates on a zero credit policy. (no negative balances)
Also, since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit for accounting purposes. Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.
----
I think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy.
Well done, indeed! I think that you have nailed it one the head. A Global Exchange Trading System. I think that you should write an expanded article along these lines, if you are willing, and post it both on the wiki and wherever else that you would like. So that we can establish early that Bitcoin is a 'trading system' and *not* a currency (hard or otherwise) and *not* a commodity or intended to be traded as such.
Are you willing, Red?
Are you willing, Red?
Wow! That is high praise from you Creighto!
I'm willing to start a new thread about it. I'm also willing to contribute to the project. However, by nature I'm very lazy! I often fail to complete projects like this.
However, should my laziness consume things, you've already demonstrated your aptitude for the project. After all, it was your analogy to begin with!
Cheers!
... since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit \"for accounting purposes\". Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.
----
I think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy.
Has anyone noticed that the FRN is exactly that, \"it's own unit for accounting purposes\"?
The lawful United States dollar is defined in law as 371 4/16th grains of silver. This has been slightly modified, but never repealed. The \"dollar\" is actually a unit of measure, you can look it up. Bet they didn't tell you that in school!
The Federal Reserve Note is \"denominated in dollars\", or as Red above states, they have defined their own unit for accounting purposes. Write the Fed a letter, press them on the subject. The will reply that the FRN is \"backed by the full faith and credit of the U.S. government.\" What they won't admit is that the FRN is NOT a U.S. dollar as defined in law. It is \"denominated\" as one only because you agree to the terms in commercial contract.
Why did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others.
Has anyone noticed that the FRN is exactly that, \"it's own unit for accounting purposes\"?
The lawful United States dollar is defined in law as 371 4/16th grains of silver. This has been slightly modified, but never repealed. The \"dollar\" is actually a unit of measure, you can look it up. Bet they didn't tell you that in school!
The Federal Reserve Note is \"denominated in dollars\", or as Red above states, they have defined their own unit for accounting purposes. Write the Fed a letter, press them on the subject. The will reply that the FRN is \"backed by the full faith and credit of the U.S. government.\" What they won't admit is that the FRN is NOT a U.S. dollar as defined in law. It is \"denominated\" as one only because you agree to the terms in commercial contract.
Why did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others.
I thought that it proved that we can use whatever words we want and define them however we want and just because 'they' use the word 'dollar' to mean something does not mean we can use a word spelled the same way to mean something completely different.
Why did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others.
So, fresno, do you consider \"GETS\" to be one of \"their terms\"?
If so, please share your preferred term for Bitcoin. I have read your comment that you already did, and I'm too lazy to find it. Please indulge me
I thought that it proved that we can use whatever words we want and define them however we want and just because 'they' use the word 'dollar' to mean something does not mean we can use a word spelled the same way to mean something completely different.
Yes, we can in theory. But do we have the organization to defend our terms? Do we even agree on what those terms might be?
We have anonymity, and we're below their radar at the moment. But that will change as soon as they see us as a threat. If you haven't seen the wheels of justice grinding in all their hypocritical glory, you are ripe for an amazement. Any appeals to \"fairness\" are going to get you slapped down hard.
I say the best way not to get shot at is to not be a target, and certainly not to donate the ammo. Don't claim to be money. It's that easy.
ichi: Why should I do your work for you? If you want to argue, then bring something to the table.
I say the best way not to get shot at is to not be a target, and certainly not to donate the ammo. Don't claim to be money. It's that easy.
I can't imagine that governments would ignore Bitcoin just because it didn't claim to be money. It's the fact that it can anonymously mediate exchanges (including exchanges with currencies) that makes it a threat.
The solution, IMHO, is careful design and implementation, not semantics (or pleading).
ichi: Why should I do your work for you? If you want to argue, then bring something to the table.
OK, would one of y'all be so kind as to post a forum URL for the prior proposal?
Re anonymity, many Bitcoin users seem far too unconcerned, IMHO.
Bitcoins have no dividend or potential future dividend, therefore not like a stock.
More like a collectible or commodity.
",
"nested_level": 0
},
{
"id": 2514,
"thread_id": 193,
"source_id": "1",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Difficulty: More nodes active, or faster nodes?",
"url": "https://bitcointalk.org/index.php?topic=846.msg9942#msg9942",
"date": "2010-08-17T19:25:38Z",
"text": "The recent upticks in difficulty have been remarkable. At 511.77, I've even stopped off those machines where I don't pay for marginal power consumption. My calculation is that the wear/tear from elevated temperatures and full-speed fans has more risk and cost than the BTC value. (You can question my math.)
But my question is this: Are we seeing the rise of mega-power machines, or just an exponential increase in the number of nodes? That is, are the top-producing machines making leaps in power (over average), or are my machines still about average, just dwarfed by the number of participating machines? Is there any way to tell? (node counts?)
I totally understand that difficulty reflects the state-of-the-art in client khash improvements, but it's clear that my own computers also represent a rapidly diminishing part of the total network generation rate. As the network gets larger, my chance of finding The Block every 10 minutes shrinks. I'm thrilled, not bitter
, but I'm curious to understand what has transpired over the past three weeks to make it so dramatic.
Cheers.
The recent upticks in difficulty have been remarkable. At 511.77, I've even stopped off those machines where I don't pay for marginal power consumption. My calculation is that the wear/tear from elevated temperatures and full-speed fans has more risk and cost than the BTC value. (You can question my math.)
This is just what one should naturally expect. Some people have more tolerance for the cost of mining than others.
But my question is this: Are we seeing the rise of mega-power machines, or just an exponential increase in the number of nodes? That is, are the top-producing machines making leaps in power (over average), or are my machines still about average, just dwarfed by the number of participating machines? Is there any way to tell? (node counts?)
I'd guess both. There is Art with his GPUs who claims to have about %10 of the generating power.
Then I see about 850 connections to the IRC channel. Not sure what its been like historically.
I would be willing to bet that someone used one of these...
http://en.wikipedia.org/wiki/Field-programmable_gate_arrayto do this...
http://www.springerlink.com/content/765kta4qr92daea8/which is something that I, myself, obviously has considered. Whoever is doing it is probably representing a great deal of the current hash percentage, and hogging a pretty good amount of the new bitcoins. Considering that up to four of these programmable arrays are used by modern ham radios for this...
http://www.dsptools.com/Radio.htmand this...
http://www.softrockradio.org/The successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match. It would look like a super-computer from our perspectives. As a ham radio operator myself, I was aware of these devices, but I don't presently own any. Even connected to my netbook over USB2, the khas/sec rate would be sick. The program for these things are normally kept on the master computer's harddisk, and only take a few seconds to swap out; so a ham could use his software radio whenever he wants to, and then rewrite all of his FPGA's with the sha-256 algorithim before going to bed, and make money while he sleeps.
Another possibilty is that someone owned or bought one of these...
http://www.via.com.tw/en/initiatives/padlock/features.jspor some other cryptographic coproccesor on a daughtercard.
I'm sure once Bitcoin takes off, anyone with enough of the coins to have a deep personal interest in the strength of the currency will be running clients with hardware exceleration for the sha-256 has function.
That also makes me wonder if there are PCI daughtercards with FPGA's on them yet. The last time that I looked into them, they were only available as external setups.
I would be willing to bet that someone used one of these Field-programmable gate array to do this...
http://www.springerlink.com/content/765kta4qr92daea8/which is something that I, myself, obviously has considered. Whoever is doing it is probably representing a great deal of the current hash percentage, and hogging a pretty good amount of the new bitcoins.
...
The successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match. It would look like a super-computer from our perspectives.
A lot of hand waving there. For some concrete numbers it quotes 53 MB/s and since we only hash 192 bytes at a time, you might think it would do 0.27 mhash/s (but it probably would be less) which is actually within the range of a desktop.
Ya, someone might! They measure out about 1.5 mhash/s. There are many ordinary Intel or AMD CPUs can do much better than that (with a little more electric power input tho).
The successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match. It would look like a super-computer from our perspectives.
A lot of hand waving there. For some concrete numbers it quotes 53 MB/s and since we only hash 192 bytes at a time, you might think it would do 27 mhash/s (but it probably would be less) which I beleive is actually within the range of a desktop with a couple GPUs.
Yes, but there are two points that you overlooked. First, the software transceiver ususally requires four of these chips. (two for receive and two for transmit, one does digital signal processing and the other does digital filtering of the raw signal. Said another way, one is the virtual mike/speaker and the other is a virtual tuner. Not all such software radio setups need four, however) So if a ham has four of these, all four could be programmed to this end. The other point is one that I didn't explicitly mention, one FPGA does not equal only one sha-256 processor. It is possible, even likely, that more than one such processor could be programmed into a single FPGA chip. These chips are fairly large so that they can 'virtualize' some pretty complex logic circuts, and a talented programmer could program one chip to be several sha-256 processors running in parrallel. All this, and his main CPU and GPU are still available if still more Kh/s are desired. Any hacker with the skills to program one or more GPU's in the same system to crunch hashes is already elite, and doing multiple sha-256 cores on a single FPGA would be child's play. And we already know that there is some elite talent within the Bitcoin community, some who desire to run it, and some who desire to break it.
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 the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given.
",
"nested_level": 0
},
{
"id": 2521,
"thread_id": 194,
"source_id": "1",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "New screenshots to the front page?",
"url": "https://bitcointalk.org/index.php?topic=850.msg10033#msg10033",
"date": "2010-08-18T07:16:55Z",
"text": "Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero.
",
"nested_level": 0
},
{
"id": 2522,
"thread_id": 194,
"source_id": "2",
"poster_name": "hugolp",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=183",
"subject": "Re: New screenshots to the front page?",
"url": "https://bitcointalk.org/index.php?topic=850.msg10035#msg10035",
"date": "2010-08-18T08:16:10Z",
"text": "Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero.
You think Windows Aero is pretty?
Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero.
You think Windows Aero is pretty?
Better than XP
Definitely. The old screenshots of 0.1 are very outdated.
Windows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts.
What to have displayed in the transaction list? Not completely filled up with stuff, just a few things.
",
"nested_level": 0
},
{
"id": 2525,
"thread_id": 195,
"source_id": "1",
"poster_name": "kosovito",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=158",
"subject": "28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10128#msg10128",
"date": "2010-08-18T21:20:35Z",
"text": "Hi. I know difficulty is high, but is normal having a machine with 4200khas/second
In the past, i generated a bunch.
Have you upgraded to 0.3.10?
What build are you running? (Downloaded/Self compiled)
What architecture/OS?
Are you usually a lucky/unlucky person?
",
"nested_level": 0
},
{
"id": 2527,
"thread_id": 195,
"source_id": "3",
"poster_name": "kosovito",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=158",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10148#msg10148",
"date": "2010-08-18T22:09:17Z",
"text": "Yes, i always updated
I run official downloaded build
Vista 64
I think i am lucky
thanks
",
"nested_level": 0
},
{
"id": 2528,
"thread_id": 195,
"source_id": "4",
"poster_name": "Ground Loop",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=382",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10156#msg10156",
"date": "2010-08-18T22:46:22Z",
"text": "Statistically, you're not very lucky. In fact, out of a hundred people, you would be one of the two least lucky ones.
I suspect something is Not Right with your setup. Either you're running an old version, firewalled, or somehow not keeping up with the block chain. Are you at block 75040 or greater?
I'm especially concerned that your 'span' of attempts has also covered lower difficulty eras. That makes you even less lucky.
The last time I was that unlucky, I was running a broken 64-bit Linux build.
I currently have a Core2Duo which is outperforming a i7 and several Quad Core machines even though they all get an equal opportunity to generate uninterrupted. I don't think we should underestimate the \"Luck\" factor.
Im not firewalled, also, i reinstalled many times bitcoin, every versi\u00f3n, i updated too. Also im in 75043 block
The worst thing about bitcoin (at least for me) is the fact you CANT test if all is fine, if youre generating coins without problems.
",
"nested_level": 0
},
{
"id": 2531,
"thread_id": 195,
"source_id": "7",
"poster_name": "sgtstein",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=398",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10168#msg10168",
"date": "2010-08-18T23:15:59Z",
"text": "The worst thing about bitcoin (at least for me) is the fact you CANT test if all is fine, if youre generating coins without problems.
This is actively being worked on. Not sure on timeline, but it is in the works to be sent out either with the program or as a standalone program.
Yeah, I'm having similar results. I've been running a self-compiled Linux build on a machine with roughly the same khash and haven't generated a block since mid July. Of course, it was a _broken_ Linux build for a few weeks of that, but I'm running the latest SVN version now and still no luck.
",
"nested_level": 0
},
{
"id": 2533,
"satoshi_id": 403,
"thread_id": 195,
"source_id": "9",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10290#msg10290",
"date": "2010-08-19T19:40:30Z",
"text": "Make sure your computer's date and time are correct.
",
"nested_level": 0
},
{
"id": 2534,
"thread_id": 195,
"source_id": "10",
"poster_name": "lachesis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=237",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10375#msg10375",
"date": "2010-08-20T04:14:49Z",
"text": "My time is correct, and my debug.log shows nothing out of the ordinary. I'm stumped here, guys!
",
"nested_level": 0
},
{
"id": 2535,
"thread_id": 195,
"source_id": "11",
"poster_name": "kosovito",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=158",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10438#msg10438",
"date": "2010-08-20T14:12:19Z",
"text": "My computer have date and time correct.
I uninstalled bitcoin, i deleted absolutely all files, blocks, debug, ALL, except of course wallet.dat.
And a reinstalled, i hope this can be works.
A question, can be wallet.dat, make any problem??
",
"nested_level": 0
},
{
"id": 2536,
"satoshi_id": 407,
"thread_id": 195,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: 28 days without generation, i have 4200khash/s",
"url": "https://bitcointalk.org/index.php?topic=862.msg10717#msg10717",
"date": "2010-08-22T23:01:02Z",
"text": "Search debug.log for \"proof-of-work found\". If you find any, then check for any errors right after that.
How big of a margin on the time is allowed for things to work right.
The margin is 2 hours.
This should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour.
Who is skilled enough to convert official Linux Bitcoin client to use GTK instead of wx?
Is this development worthy or desirable enough to pursue or is wx acceptable?
q: let me get this straight. You're asking if someone will put up a bounty for a conversion that you want? (bounty idea dismissed due to seeming weird/strange to some)
a: I don't want it. Is GTK better than QT or anytihng else? I'm not familiar.
\"I would like it if Bitcoin used GTK instead of wxWidgets but I won't pretend that I have a clue about how hard or easy that change might be\"
someone: wx seems to work now as far as I can tell
someone else: wx is an utter nightmare
q: why \"convert\" Satoshi's front end? Why not just build a new one that uses the rpc calls?
there actually isn't much that needs to be done to make bitcoind's methods useful enough to do the same things the GUI does:
in particular:
* list sending addresses
* show unaccepted blocks in listtransactions (maybe)
* select a range of transactions to show
",
"nested_level": 0
},
{
"id": 2538,
"thread_id": 196,
"source_id": "2",
"poster_name": "sirius",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=4",
"subject": "Re: Convert Bitcoin to GTK (BTC Bounty Anyone?)",
"url": "https://bitcointalk.org/index.php?topic=867.msg10218#msg10218",
"date": "2010-08-19T07:30:57Z",
"text": "Hmm... would it run on Maemo with the same code then? Any other advantages?
",
"nested_level": 0
},
{
"id": 2539,
"thread_id": 196,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Convert Bitcoin to GTK: Yes? No? wx is better?",
"url": "https://bitcointalk.org/index.php?topic=867.msg10219#msg10219",
"date": "2010-08-19T07:34:48Z",
"text": "bitcoind's commands should be expanded and binaries for it should be released so that third-party UI development can be made easier. Like Tor.
",
"nested_level": 0
},
{
"id": 2540,
"thread_id": 196,
"source_id": "4",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Convert Bitcoin to GTK: Yes? No? wx is better?",
"url": "https://bitcointalk.org/index.php?topic=867.msg10220#msg10220",
"date": "2010-08-19T07:39:06Z",
"text": "It would be interesting for bitcoin to be designed in a way that an ncurses ui could be designed.
\"you certainly can build a ncurses front end to the deamon now. Its not a problem for bitcoin\"
",
"nested_level": 0
},
{
"id": 2541,
"thread_id": 196,
"source_id": "5",
"poster_name": "Olipro",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=526",
"subject": "Re: Convert Bitcoin to GTK: Yes? No? wx is better?",
"url": "https://bitcointalk.org/index.php?topic=867.msg10223#msg10223",
"date": "2010-08-19T07:51:13Z",
"text": "Yeah, my opinion on this is that the GUI should be separated from the underlying code. BUT... there's no need to throw the baby out with the bathwater and I firmly believe that the current wxWidgets interface should be maintained until such a time as something superior comes along.
My personal feeling is that whilst separate daemon/GUI binaries can work, it also tends to be messy, I'd be far more in favour of having the core code and then separate source that you compile with it according to your target OS, that way everything is still a single binary and can be integrated as idealistically as possible.
To put this in practice, imagine 3 SVN trunks; the first is BitCoin core, the other two are LINGUI and WINGUI - the latter two being dependant on code from the first.
",
"nested_level": 0
},
{
"id": 2542,
"thread_id": 196,
"source_id": "6",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Convert Bitcoin to GTK: Yes? No? wx is better?",
"url": "https://bitcointalk.org/index.php?topic=867.msg10226#msg10226",
"date": "2010-08-19T08:05:18Z",
"text": "WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
I think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own \"client\" running (see
http://bitcointalk.org/index.php?topic=851.0) with the daemon (who doesn't need WxWidgets anymore) and it works very nicely. So, in my case I don't have any dependency on WxWidgets any more.
I think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own \"client\" running (see
http://bitcointalk.org/index.php?topic=851.0) with the daemon ...
So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why.
So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why.
Bitcoin is a P2P network, so the program should be running all the time. However, I don't need to be looking at a GUI all that time, so it makes sense to have a daemon. Currently, you have to stop the daemon when you want to start the GUI version, which breaks the network for a moment.
Some P2P applications like aMule do this properly. The daemon is running all the time, and when you want to interact with it, you start the separate GUI, which connects to the daemon. Most importantly, the GUI can run on a different machine from the daemon.
Such a setup would be great for mobile Bitcoin usage. You run the daemon on your \"server\" machine, and you connect to it with a GUI on your mobile device. I think this has been already discussed in a different context, but the same mechanism applies.
However, you can already use the JSON-RPC mechanism to build a separate GUI, so there is no immediate need to change the mainline client.
WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows.
The distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.
This is a problem that will solve itself. With time, 2.9 will become a more mainline release.
I wrote up a basic guide on how to compile Bitcoin on Ubuntu. I hope it proves useful to anyone still having issues compiling the graphical client.
http://lickthesalt.com/2010/08/19/compiling-bitcoin-on-ubuntu-10-04-karmic/An excellent guide. Thank you so much for your efforts - it will certainly help me
That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags.
",
"nested_level": 0
},
{
"id": 2549,
"thread_id": 198,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "sdfh",
"url": "https://bitcointalk.org/index.php?topic=870.msg10288#msg10288",
"date": "2010-08-19T19:24:37Z",
"text": "sdfgsfhg
",
"nested_level": 0
},
{
"id": 2550,
"thread_id": 198,
"source_id": "2",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Hypothetical question on lost coins / transfers",
"url": "https://bitcointalk.org/index.php?topic=870.msg10292#msg10292",
"date": "2010-08-19T19:44:06Z",
"text": "I think not. I think that when a client considers a block bad it gets the transactions that were in it and rebroadcasts them or puts them in a block themselves.
",
"nested_level": 0
},
{
"id": 2551,
"satoshi_id": 405,
"thread_id": 198,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Hypothetical question on lost coins / transfers",
"url": "https://bitcointalk.org/index.php?topic=870.msg10300#msg10300",
"date": "2010-08-19T20:28:50Z",
"text": "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 is making sure to re-integrate your transactions again. All you should see is that your number of confirmations starts over from 0.
In some types of forks, your transaction would have gotten into both forks already, so you're already good either way.
",
"nested_level": 0
},
{
"id": 2552,
"satoshi_id": 404,
"thread_id": 199,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Need a post writing up some things users should know",
"url": "https://bitcointalk.org/index.php?topic=873.msg10297#msg10297",
"date": "2010-08-19T20:14:01Z",
"text": "I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list:
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up proper.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
",
"nested_level": 0
},
{
"id": 2553,
"thread_id": 199,
"source_id": "2",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Need a post writing up some things users should know",
"url": "https://bitcointalk.org/index.php?topic=873.msg10355#msg10355",
"date": "2010-08-20T03:20:18Z",
"text": "I posted the above comment onto the wiki for posting a list these things users should know:
http://www.bitcoin.org/wiki/doku.php?id=things_you_should_knowmizeryderia, you just copied and pasted satoshis post without adding any value.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
I apologize. I wasn't sure what to add.
mizeryderia, you just copied and pasted satoshis post without adding any value.
You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.
",
"nested_level": 0
},
{
"id": 2555,
"satoshi_id": 406,
"thread_id": 199,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Need a post writing up some things users should know",
"url": "https://bitcointalk.org/index.php?topic=873.msg10715#msg10715",
"date": "2010-08-22T22:51:00Z",
"text": "The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off.
",
"nested_level": 0
},
{
"id": 2556,
"thread_id": 199,
"source_id": "5",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Need a post writing up some things users should know",
"url": "https://bitcointalk.org/index.php?topic=873.msg10725#msg10725",
"date": "2010-08-23T00:38:10Z",
"text": "- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?
This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.
see http://bitcointalk.org/index.php?topic=921.0 for continued discussion about backups- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?
This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.
This comment seems worthy of having this thread appear threaded so that discussion could expand exponentially. In the case that this forum is not threaded, however, I will briefly state (without getting offtopic) that there should be some sort of established procedures or mechanisms to handle either regular interval or triggered backups without interrupting the Bitcoin process. It seems that it is essential to \"perfect\" data reliability/availability as best as possible so as to provide more incentive for adoption.
Actually, it's not so offtopic.
- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.
Instead of introducing a warning or establishing a precedence of caution and delay in handling wallet file or backups, as I suggested above, the implementation for backing up data/wallet file needs more thought/establishment.
I am not familiar with the current process/structure of data flow that occurs, but if someone could write up or draw a diagram or something that shows how the flow of data appears then perhaps with this diagram-liek information, others, like myself, can help to understand how things work and maybe offer suggestions for improvements or to recognize things like after which data sent/received is worthy of implementing a kind of automated/triggered backup or similar action.
see http://bitcointalk.org/index.php?topic=921.0 for continued discussion about backups ",
"nested_level": 0
},
{
"id": 2558,
"satoshi_id": 420,
"thread_id": 199,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Need a post writing up some things users should know",
"url": "https://bitcointalk.org/index.php?topic=873.msg11227#msg11227",
"date": "2010-08-26T00:44:05Z",
"text": "Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there.
The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
",
"nested_level": 0
},
{
"id": 2559,
"thread_id": 200,
"source_id": "1",
"poster_name": "zooko",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=904",
"subject": "integrating digital payments into p2p protocols",
"url": "https://bitcointalk.org/index.php?topic=890.msg10593#msg10593",
"date": "2010-08-21T14:13:27Z",
"text": "Folks:
I just posted this note over on the Trade forum:
http://bitcointalk.org/index.php?topic=30.msg10592#msg10592There are a few hackers who would be pretty interested in contributing patches to integrate BitCoin payments directly into the Tahoe-LAFS storage protocol. It would be a big job! It would probably take a year of effort before we would be ready to deploy it in a new stable release. Of course, the more people pitch in the faster the work goes.
Regards,
Zooko
community organizer, Tahoe-LAFS project
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.
",
"nested_level": 0
},
{
"id": 2561,
"satoshi_id": 409,
"thread_id": 201,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10722#msg10722",
"date": "2010-08-22T23:55:06Z",
"text": "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 alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.
In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade. Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.
The json-rpc methods that return errors during an alert are:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
",
"nested_level": 0
},
{
"id": 2562,
"thread_id": 201,
"source_id": "2",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10738#msg10738",
"date": "2010-08-23T04:16:54Z",
"text": "Did you consider turning off block generation? You must have, why did you decide not to include it?
",
"nested_level": 0
},
{
"id": 2563,
"thread_id": 201,
"source_id": "3",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10740#msg10740",
"date": "2010-08-23T05:04:50Z",
"text": "On a side note, lfm,
it seems a bit
repetitive, your post
being the first reply
yet you quote
entirety of first post.
Of course you were
replying to that
post! Perhaps you
wanted your
post to look
more full? ^_^ | I do not think it is good idea to forcefully turn off block generation. I think it is better to maintain generating blocks until the owner/user specifically disables it themselves. In most cases it may be perceived helpful to disable generating blocks automatically, but there may be some cases where it is not so helpful.
I believe there is a precedence of backlash from other communities in which implementations of remote control were produced and hindered or interfered with communities expectations. I am not certain that implementing a remote disable for block generation would be perceived similarly, but it is something to keep into consideration. |
@mizerydearia, I think the quote button is easier to find then the reply one.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
",
"nested_level": 0
},
{
"id": 2565,
"thread_id": 201,
"source_id": "5",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10743#msg10743",
"date": "2010-08-23T05:18:02Z",
"text": "So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
Ooooooh, that's a good point too!
I would suggest that as a beginning implementation for an alert system is it most basic, simple and to the point and is guaranteed to work without flaws, errors, exploits, etc. Once this seems to be accepted by most of community and seems well established and secure, perhaps then it may be safe to expand upon it. However, a single point of mass DOS seems too overwhelming to implement into the official client if there is any opportunity whatsoever to exploit it or take control of it through any means necessary.
No! If you do that they'll torture you until you give them the key Satoshi!
But seriously, if the key has turn off power I'm not running that client.
I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
I imagine this thinking comes from seeing all the people who haven't switched to 3.10 yet?
Having enough different implementations that none is a majority would mean a bug like the overflow would only lead to problems with the improperly coded client and not with the whole chain. Unless people writing new clients mostly copied your code, then any problems would remain. But if they were written from scratch to do what they should then any problems would not overlap.
Do I remember you saying you thought it would be a nightmare to have multiple implementations? I can't remember why you said that though.
",
"nested_level": 0
},
{
"id": 2567,
"thread_id": 201,
"source_id": "7",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10748#msg10748",
"date": "2010-08-23T05:28:14Z",
"text": "I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.
Hmmm. yes... that makes sense.
",
"nested_level": 0
},
{
"id": 2569,
"thread_id": 201,
"source_id": "9",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10778#msg10778",
"date": "2010-08-23T07:55:12Z",
"text": "
A remote warning message seems reasonable.
But a remote kill switch for automated websites?
",
"nested_level": 0
},
{
"id": 2570,
"thread_id": 201,
"source_id": "10",
"poster_name": "hugolp",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=183",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10781#msg10781",
"date": "2010-08-23T08:08:47Z",
"text": "No! If you do that they'll torture you until you give them the key Satoshi!
But seriously, if the key has turn off power I'm not running that client.
I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
I imagine this thinking comes from seeing all the people who haven't switched to 3.10 yet?
Having enough different implementations that none is a majority would mean a bug like the overflow would only lead to problems with the improperly coded client and not with the whole chain. Unless people writing new clients mostly copied your code, then any problems would remain. But if they were written from scratch to do what they should then any problems would not overlap.
Do I remember you saying you thought it would be a nightmare to have multiple implementations? I can't remember why you said that though.
+1
I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.
It would require a lot of effort for everyone to change keys or to upgrade to a new version. This should be recognized by those that are still using old versions even as far back as 0.3.0 and maybe even earlier.
Wouldn't an automatic update be better?
For linux distros at least, it should not be that hard to do it I suppose.
",
"nested_level": 0
},
{
"id": 2573,
"thread_id": 201,
"source_id": "13",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10788#msg10788",
"date": "2010-08-23T09:00:51Z",
"text": "Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure. This is not the case across different distributions of linux.
However, automatic update is not recommended. An alert indicator to notify the user to take action is best. Perhaps the bitcoind version can be configured to send an email alert to a specified email address in the config file as an extra step for alerting/notification.
",
"nested_level": 0
},
{
"id": 2574,
"thread_id": 201,
"source_id": "14",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10791#msg10791",
"date": "2010-08-23T09:08:22Z",
"text": "Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure. This is not the case across different distributions of linux.
Oh, come on, no need to cover all possible distros. Just debian and rpm repositories should be fine.
However, automatic update is not recommended. An alert indicator to notify the user to take action is best.
That's what I meant by \"automatic update\"... normally they always ask user confirmation.
They just spare you the work of going to the webiste of each software you have installed to check for new downloads.
I was going to suggest the exact same thing... you beat me to it
However it has to be done carefully, people do not like any unsanctioned changes to happen without their knowledge or any kind of remote control. If this would be implemented I would say that it should not execute any action unless specifically requested/confirmed by the user.
On a GUI client this would be accomplished by presenting a dialog window describing the requested actions and waiting for the user to confirm them (or check an \"automatically apply changes suggested in alerts\" checkbox, which would be unchecked by default).
Also a deamon should not do anything unless a specific switch for that purpose is applied like --enable-alerts. It can show a warning if this switch is not applied and suggest to enable it to the user but it shouldn't apply it by default automatically.
In short, any changes except simple alerts should be disabled by default.
I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.
Well, yeah, that's what I'd need to do, but since I'd have to buy/beg it from someone who can implement I'd prefer to have the main client just be what I want. Also I'd stay more comfortable with bitcoin on the whole if other people don't have a centrally controlled client. I know I could convince them to use a non-special-key version, but really that's what I'm doing right now.
Messages only is not a big deal, but I think it does start down a \"special user\" path that I'd prefer not to follow.
Being open source does not mean every user is a coder (I am, but still) so I guess the point that \"you can just roll out your own client\" is a little off.
But why is satoshi integrating this on the server in the first place? I say that the libbitcoin / bitcoinUI separation is starting to be really important. Put the messaging system on IRC on the UI, make the UI smart enough to stop, block, maim, impair the server running beneath it if certain messages signed with certain keys appear. But DON'T make the server respond to anything outside local GUI control, just because that is too dangerous and in the end does more harm than good.
This way, average users will have the upgrade notices and the generators stopped and whatnot when needed, but those of us running services over bitcoin will not loose shop because of that. Also, if the key gets compromised, the network still runs without worries, and a simple GUI change will unblock everyone.
For server admins, why not a mailing list for update announces? That would certainly be enough for most.
",
"nested_level": 0
},
{
"id": 2578,
"thread_id": 201,
"source_id": "18",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10810#msg10810",
"date": "2010-08-23T12:38:15Z",
"text": "I second the mailing list idea.Having a way to shut down the system if you control the key would be a bad idea.
A mailing list makes it non coercive rather than seeming like there is a kill switch that could wipe your bitcoins out.
",
"nested_level": 0
},
{
"id": 2579,
"thread_id": 201,
"source_id": "19",
"poster_name": "HostFat",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=203",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10830#msg10830",
"date": "2010-08-23T15:02:42Z",
"text": "I like the idea about a warning message, but I'm against anything like a remote control.
The only way to make it possible is adding an option where user can chose to enable/disable this remote control.
",
"nested_level": 0
},
{
"id": 2580,
"thread_id": 201,
"source_id": "20",
"poster_name": "nimnul",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=600",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10836#msg10836",
"date": "2010-08-23T15:46:07Z",
"text": "1) package for CentOS :-) so updates are easy
2) don't implement messages
3) notify us using RSS/email/Jabber
",
"nested_level": 0
},
{
"id": 2581,
"thread_id": 201,
"source_id": "21",
"poster_name": "Macho",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=625",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg10844#msg10844",
"date": "2010-08-23T16:39:22Z",
"text": "3) notify us using RSS/email/Jabber
That is too centralized/censorable/hackable, the idea with a message signed with specific private key only satochi has is ideal as it can be introduced at any node and spread trough decentralized means.
I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.
It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.
It would require a lot of effort for everyone to change keys or to upgrade to a new version. This should be recognized by those that are still using old versions even as far back as 0.3.0 and maybe even earlier.
It doesn't require a lot of effort if its a simple option,either in a config file or a command line switch. It might not even be a default, could be opt-in. Some people would welcome it as insurance that they will not be causing problems in an emergency.
There should be a --disable-alerts switch.
",
"nested_level": 0
},
{
"id": 2584,
"satoshi_id": 412,
"thread_id": 201,
"source_id": "24",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11074#msg11074",
"date": "2010-08-24T23:51:12Z",
"text": "If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.
",
"nested_level": 0
},
{
"id": 2585,
"satoshi_id": 413,
"thread_id": 201,
"source_id": "25",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11078#msg11078",
"date": "2010-08-25T00:06:36Z",
"text": "This is in SVN rev 142 as version 0.3.11.
",
"nested_level": 0
},
{
"id": 2586,
"thread_id": 201,
"source_id": "26",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11079#msg11079",
"date": "2010-08-25T00:11:50Z",
"text": "If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.
I just discovered
http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode. Perhaps it should be added! Also others liek -4way should be added as well.
If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.
What else does -disablesafemode do?
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.
Satochi the creator of the decentralized pseudo-anonymous trading system not reliant on trust and using strong cryptography is calling us paranoid LOL
Not wanting any remote tampering of the software running on my PC is not paranoid but a matter of common sense I believe. Of course it is a good idea but it should be enabled ONLY when specifically requested by the user. It should be opt-in as opposed to opt-out. There is a huge difference between the two (ask Facebook). If it's going to be enabled by default it is going to be perceived by many as an exploitable/malicious feature counting on the fact that most people will not realize/notice it is even there. And I wouldn't say these concerns wouldn't be justified ... It doesn't matter that you have best interest of the community at your heart which I'm sure you have, the system was designed not to rely on any kind of central trust and that principle should not be broken.
I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.
Why not use -enablesafety to enable this feature instead of expecting the user to disable it? If I want my software to respond to remote alerts I should specifically enable it, that way it is ensured that I'm aware of what I'm doing and I'm doing it of my own will. When it is enabled by default a lot of people may not even realize this \"feature\" is enabled and perceive remote disabling as a breach of trust ... I know I would if I wasn't aware of that possibility and the software would suddenly stopped working and I would discover it was disabled by remote by someone I gave no conscious permission to do so.
I hope you'll consider this suggestion ... thanks
I agree, however, if you compile from source, a single change from
rpc.cpp
!mapArgs.count(\"-disablesafemode\")
to
mapArgs.count(\"-safemode\")
will then
// Observe lockdown
throw runtime_error(strWarning);
You can examine the code at
http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/rpc.cpp?revision=142&view=markup to see what is happening.
It seems a bit strange to only show an error when -enablesafety is used. Perhaps it is unsafe or insecure for this to happen?
http://www.bitcoin.org/wiki/doku.php?id=apiFrom my understanding of the code it appears that when using one of these
http://www.bitcoin.org/wiki/doku.php?id=api methods other than getinfo, help, stop, getgenerate, setgenerate and most importantly when there is a warning, that:
if -disablesafemode was passed to the running process, then the warning will not be displayed
if -disablesafemode was not passed to the running process, then the warning will be displayed
http://www.cplusplus.com/reference/std/stdexcept/runtime_error/necrodearia>
http://www.cplusplus.com/reference/std/stdexcept/runtime_error/ - Does this cause the running process to stop or does it just produce output to the terminal/shell?
<Adrinael> necrodearia, \"this\"?
<necrodearia> runtime_error
<Adrinael> necrodearia, if you create a runtime_error object, nothing happens. If you throw a runtime_error object, it all depends on if someone catches it, and where.
<Adrinael> { try { throw runtime_error(\"Error, halp!\"); } catch (runtime_error& e) { cout << \"caught a runtime error: \" << e.what(); } cout << \" but still continuing...\"; }
<clang> terminated by runtime_error: Error, halp!
<Adrinael> Hmm awesome
<Adrinael> geordi { try { throw runtime_error(\"Error, halp!\"); } catch (runtime_error& e) { cout << \"caught a runtime error: \" << e.what(); } cout << \" but still continuing...\"; }
<geordi> caught a runtime error: Error, halp! but still continuing...
<Sausage> How in the hell did it get that wrong?
<Adrinael> Asked Eelis on #geordi, now move along
I agree, however, if you compile from source, a single change from
That's not the point, if I'm diligent enough to change a source code I'm also diligent enough to apply a -disablesafety switch which is much easier, the issue here is default behavior of the official client. Many people are going to just notice there is a new version, download and install it never realizing this new remote control was inserted there.
Saying that they can examine the source code or that it was openly discussed on the forum is like Facebook saying \"but we have an option to delete your account, it's in terms of service, section 76, line 346, under link named so-appalling-that-nobody-would-ever-click-it, then on page 2, just solve the capcha, confirm the dialog, that will disable your account and if you do not log in in a week it will be deleted\". In short ... nobody actually does it ... that's how badware behaves and I do not want for Bitcoin to be badware.
If there is a remote safety disable function every user who has it enabled should consciously enable it knowing what it does. This can be easily accomplished by presenting a dialog urging user to enable it while explaining what it does in a GUI client and presenting a warning accomplishing the same task when daemon is run. Simple, efficient and everybody is happy. That's how software that respects its users and is working for them should behave. I'm sure most people would enable it when understanding what it does ... but sneaking this feature in without making sure the user specifically wants it there is making decisions for the user, I do not like decisions being made for me
I'm aware of this because I read the forums but what in the future? (And what about people who do not read forums) Will there be another \"feature\" inserted and I'm not going to be even notified, explained what it does and asked if I want it enabled? I do not like that if you ask me ... I want to know what software on my CPU does, if it doesn't make reasonable effort to inform me of that and assure that I'm aware of it's behavior I would consider it badware.
That's at least my perspective ... and the fix is extremely easy
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
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
The remaining 14 methods function as normal.
I believe the safer option should be enabled by default. If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.
Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.
Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.
Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back. I'm not arguing that this is the permanent way of things forever. It's still beta software.
",
"nested_level": 0
},
{
"id": 2593,
"satoshi_id": 415,
"thread_id": 201,
"source_id": "33",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11151#msg11151",
"date": "2010-08-25T16:40:20Z",
"text": "I changed the switch name to -disablesafemode.
",
"nested_level": 0
},
{
"id": 2594,
"thread_id": 201,
"source_id": "34",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11152#msg11152",
"date": "2010-08-25T16:41:55Z",
"text": "What is the error the RPC calls return? And more importantly, how can I simulate this? Can you add a flag to start the server in degraded mode?
",
"nested_level": 0
},
{
"id": 2595,
"thread_id": 201,
"source_id": "35",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11153#msg11153",
"date": "2010-08-25T16:45:22Z",
"text": "@mizerydearia, I think the quote button is easier to find then the reply one.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
A few rhetorical questions for satoshi:
Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance? Seriously.
@mizerydearia, I think the quote button is easier to find then the reply one.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
A few rhetorical questions for satoshi:
Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance? Seriously.
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 I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system. It would be a temporary inconvenience only.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
This is what makes me think the people objecting don't know what they're talking about. It can't \"shut down the complete network\".
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.
The rpc methods return a json-rpc error with the error description \"Safe mode: \" followed by additional text specified by the alert.
I added the switch \"-testsafemode\" for you. SVN rev 145.
This stuff is very new and may still be subject to change.
Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.
-4way should eventually be replaced by an auto-detect.
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
This is what makes me think the people objecting don't know what they're talking about. It can't \"shut down the complete network\".
I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed?
So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?
getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.
The rpc methods return a json-rpc error with the error description \"Safe mode: \" followed by additional text specified by the alert.
I added the switch \"-testsafemode\" for you. SVN rev 145.
This stuff is very new and may still be subject to change.
Perfect, works great for me. Thank you.
Okay, I'm not worried anymore.
",
"nested_level": 0
},
{
"id": 2601,
"satoshi_id": 418,
"thread_id": 201,
"source_id": "41",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Development of alert system",
"url": "https://bitcointalk.org/index.php?topic=898.msg11219#msg11219",
"date": "2010-08-26T00:08:12Z",
"text": "So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment> get?
This is what makes me think the people objecting don't know what they're talking about. It can't \"shut down the complete network\".
I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed?
My apologies, your post was indeed a question not a statement.
Wallet backups and other DB examination are easily possible in a safe, atomic, transactional fashion... if and only if DB_PRIVATE flag is removed.
--- a/db.cpp
+++ b/db.cpp
@@ -77,7 +77,6 @@ CDB::CDB(const char* pszFile, const char* pszMode) : pdb(NULL)
DB_INIT_MPOOL |
DB_INIT_TXN |
DB_THREAD |
- DB_PRIVATE |
DB_RECOVER,
S_IRUSR | S_IWUSR);
What, if any, problems arise from doing this? Obviously, this does not cover the non-db4 databases such as the block data file.
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 to open the database simultaneously? That may be an improvement, depending what the side effects are. Does it substantially reduce performance by making it have to write out every change immediately or do other coordination? Are there additional locking or coordination files then? What else changes? You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor.
Apparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database. It still lets them, it just screws up if they do. Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes.
",
"nested_level": 0
},
{
"id": 2604,
"thread_id": 202,
"source_id": "3",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: RFC: remove DB_PRIVATE flag",
"url": "https://bitcointalk.org/index.php?topic=920.msg11225#msg11225",
"date": "2010-08-26T00:39:24Z",
"text": "DB_PRIVATE enables a few optimizations by making the assumption that only one process will access the db4 database. Notably, this flag enables db4 to use pthreads-style mutex locking rather than heavy, operating-system-provided flock and shared memory. Ref:
DB_ENV->open documentation.
The general motivation is that db4 databases can be safely accessed in parallel with bitcoin client, assuming (a) DB_PRIVATE is removed and (b) bitcoin properly uses db4 transactions. db4 transactions may even be employed to wrap around non-db4 data such as blk0001.dat, if the code is properly architected.
Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different.
On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind.
The docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply.
Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE 20 minutes 51 seconds
without DB_PRIVATE 20 minutes 51 seconds
I wasn't expecting them to come out exactly the same.
",
"nested_level": 0
},
{
"id": 2606,
"thread_id": 203,
"source_id": "1",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "auto backing up of wallet.dat",
"url": "https://bitcointalk.org/index.php?topic=921.msg11107#msg11107",
"date": "2010-08-25T03:52:13Z",
"text": "So, as many others, I need to backup wallet.dat. And since this one is on a server, I need it to happen unattended. And because this server is being used by the lottery, I must not shutdown bitcoind.
So far I just copy the file over, and do it often so I can outlive one corrupted file. But this is not ideal, as I should backup after every transaction (sent, right? no new addresses are created on receiving a transfer ) or after everytime I create a new address.
For that I thought about instead of copying the file I could use db_dump to dump it's contents, using the -r flag just in case. Would that work?
The ideal solution would be an rpc call that would either:
- flush and lock updates until a new rpc call (any call, didn't need to be an unlock command) would come over
- flush and cp wallet.dat to a side file
- flush and dump through jsonrpc. If each key would come separate in an array, we could then call this with 'lastseen=X' to just get new keys
Could this work? Which would work best?
",
"nested_level": 0
},
{
"id": 2607,
"thread_id": 203,
"source_id": "2",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: auto backing up of wallet.dat",
"url": "https://bitcointalk.org/index.php?topic=921.msg11131#msg11131",
"date": "2010-08-25T11:11:16Z",
"text": "",
"nested_level": 0
},
{
"id": 2608,
"satoshi_id": 421,
"thread_id": 203,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: auto backing up of wallet.dat",
"url": "https://bitcointalk.org/index.php?topic=921.msg11228#msg11228",
"date": "2010-08-26T00:57:40Z",
"text": "I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.
The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
I was starting to post the same idea you said nelisky.
How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first.
What's the simplest portable way to copy a file? Is there something in Boost?
What should it be named? maybe:
backupwallet <destination>
",
"nested_level": 0
},
{
"id": 2609,
"thread_id": 203,
"source_id": "4",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: auto backing up of wallet.dat",
"url": "https://bitcointalk.org/index.php?topic=921.msg11232#msg11232",
"date": "2010-08-26T01:21:57Z",
"text": "I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.
The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.
I was starting to post the same idea you said nelisky.
Yes, I saw your other post and I really like the poll of addresses, but we still need a way to easily back up when those get all used, don't we? I know the address space is huge, but there might be applications that deliver thousands of addresses per day.
How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first.
What's the simplest portable way to copy a file? Is there something in Boost?
What should it be named? maybe:
backupwallet <destination>
Great on all accounts, name and implementation approach.
As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps. In C++ you can just use standard file streams, can't you? Something like
http://www.dreamincode.net/code/snippet2306.htm (out of a quick google, didn't try but looks correct).
To put the cherry on top, why not add a trigger that makes the copy whenever there's a change to the wallet? Well, this would depend on file locking to work properly and that sucks on windows iirc. Been a while since I had to code there
What's the simplest portable way to copy a file? Is there something in Boost?
mmap(2) + memcpy(3) ? Boost::Iostreams already has a mapped_file Source.
What should it be named? maybe:
backupwallet <destination>
Sounds quite useful!
If you read it into memory and write it out, it could fail in tight memory situations.
I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it.
As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps.
We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it.
If you read it into memory and write it out, it could fail in tight memory situations.
I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it.
As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps.
We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it.
Ok, so what's wrong with the simple standard fstream usage from that snippet I mentioned? I think simple is best
But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.
If you read it into memory and write it out, it could fail in tight memory situations.
I think you misunderstand what mmap does? mmap / CreateFileMapping does not read a file into heap memory:
http://en.wikipedia.org/wiki/MmapI doubt there's an mmap(2) on Windows. I'd rather call an existing file copy function than make and test my own.
But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.
Thanks. I thought it would be in there somewhere.
We already use boost::filesystem in a dozen places. It's not a new added dependency. It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere.
I doubt there's an mmap(2) on Windows.
The Windows version of mmap was mentioned in the message to which you replied: CreateFileMapping
In my earlier message, I mentioned how to use this from boost: Boost::Iostreams already has a mapped_file Source.
Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.
We want to avoid Windows API calls whenever possible. They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.
I usually shy away from iostreams. Seems like I too often hit limitations. They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right. Using it in rpc.cpp may still turn out to be a mistake.
Bottom line is I'd rather call an existing file copy function than make and test my own.
",
"nested_level": 0
},
{
"id": 2617,
"satoshi_id": 437,
"thread_id": 203,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: auto backing up of wallet.dat",
"url": "https://bitcointalk.org/index.php?topic=921.msg12134#msg12134",
"date": "2010-09-06T21:45:10Z",
"text": "rpc backupwallet <destination> is in SVN rev 147.
",
"nested_level": 0
},
{
"id": 2618,
"thread_id": 204,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "New web service: obtain dump of bitcoin block NNNN",
"url": "https://bitcointalk.org/index.php?topic=928.msg11220#msg11220",
"date": "2010-08-26T00:21:31Z",
"text": "As part of
Bitcoin Watch, a new feature provides a developer-friendly dump of a bitcoin block at the specified height.
GET parameters:
\"h\" - height of block to download
\"json\" - set to non-zero value, to enable application/json output rather than HTML output
Examples:
Dump block 72000:
http://blk.bitcoinwatch.com/b?h=72000Dump block 72000, with JSON:
http://blk.bitcoinwatch.com/b?h=72000&json=1This sub-page of Bitcoin Watch shows the last 7 days worth of blocks, each block linking to expanded data:
http://blk.bitcoinwatch.com/Superb! Thanks a lot.
",
"nested_level": 0
},
{
"id": 2621,
"satoshi_id": 426,
"thread_id": 204,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New web service: obtain dump of bitcoin block NNNN",
"url": "https://bitcointalk.org/index.php?topic=928.msg11400#msg11400",
"date": "2010-08-27T16:13:16Z",
"text": "That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day.
",
"nested_level": 0
},
{
"id": 2622,
"thread_id": 205,
"source_id": "1",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Gentoo Linux Ebuild",
"url": "https://bitcointalk.org/index.php?topic=930.msg11252#msg11252",
"date": "2010-08-26T06:10:29Z",
"text": "bitcoin ebuilds for gentoo linux
2011.03.02: bitcoin-git-9999 ebuild updated outdated
Come to #bitcoin-gentoo on Freenode for latest
Try -datadir=
Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it. There wasn't time to investigate at the time.
One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there. -lwx_gtk2ud-2.9 only matches the right configuration. It fails if wxWidgets was built with the wrong configuration.
Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.
Did they say why they were baffled?
This is because on my system the path is /usr/include/wx-2.9/wx/wx.h
Why is it there? Was it included by the OS, or did you have to build it? If you built it, I wonder why it would put itself in a different place.
Has wxWidgets 2.9 finally started to become available as a debian package?
Maybe we should do this:
INCLUDEPATHS= \\
-I\"/usr/local/include/wx-2.9\" \\
-I\"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9\" \\
-I\"/usr/include/wx-2.9\" \\
-I\"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9\"
Again, those paths help make sure it's only 2.9 and will fail with 2.8.
wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.
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 getinfo command
- Alert system
The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.
In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.
This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.
Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/
Good stuff. For those who haven't been following other threads, I think it's important to note that the alerts are only accepted if signed by a specific key (held by satoshi). Alerts cannot be generated by average nodes.
",
"nested_level": 0
},
{
"id": 2626,
"thread_id": 206,
"source_id": "3",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Version 0.3.11 with upgrade alerts",
"url": "https://bitcointalk.org/index.php?topic=941.msg11448#msg11448",
"date": "2010-08-27T22:40:35Z",
"text": "- Built with -march=amdfam10, which makes -4way slightly faster
Doesn't -march break abi with older systems?
- Built with -march=amdfam10, which makes -4way slightly faster
Doesn't -march break abi with older systems?
It's quite possible. -mtune=XXXX may be preferred, because -march=XXXX means the compiler expects the binary will
only be run on amdfam10.
... -march=XXXX means the compiler expects the binary will only be run on amdfam10.
That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler.
iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
",
"nested_level": 0
},
{
"id": 2630,
"thread_id": 206,
"source_id": "7",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Version 0.3.11 with upgrade alerts",
"url": "https://bitcointalk.org/index.php?topic=941.msg11484#msg11484",
"date": "2010-08-28T08:24:05Z",
"text": "... -march=XXXX means the compiler expects the binary will only be run on amdfam10.
That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler.
So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?
iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
We only compile one source file with the 4way code (sha256.cpp) using -march=amdfamk10, not the whole client.
So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?
Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as \"only works on AMDs K10\" but rather as \"tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future\".
So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?
Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as \"only works on AMDs K10\" but rather as \"tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future\".
Ah. Ok. Thank you for the info.
The \"About\" dialog still shows 0.3.10.1 beta.
",
"nested_level": 0
},
{
"id": 2635,
"satoshi_id": 431,
"thread_id": 206,
"source_id": "12",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.11 with upgrade alerts",
"url": "https://bitcointalk.org/index.php?topic=941.msg11505#msg11505",
"date": "2010-08-28T14:54:04Z",
"text": "The \"About\" dialog still shows 0.3.10.1 beta.
What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.
The Mac version is still 0.3.10.1.
iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
I updated the first post to be more specific. Only the -4way code is compiled this way.
Nice calculation. certainly it is not worth building a machine for bitcoin creation. However if you already have this computing power sitting idly then you should calculate only the costs of the extra electricity that you need to consume to generate a block. Has anybody done this?
If you want to build a bitcoin generation machine you are probably better off buying a FPGA board and designing a dedicated hash calculating hardware monster.
Interesting note: If one puts 4100000 hash/sec in the calculator then you get 10 minutes average.
10 minutes is the actual target average block production rate.
This means that currently the the total computing power working on solving hashes is 4.1 Mhash/s
or about 900 quad cores. or 3-4 thousand laptops. Pretty impressive!
This means that there are some people who think it is interesting to produce bitcoin.
Who knows why, I stopped several difficulties ago.
",
"nested_level": 0
},
{
"id": 2638,
"thread_id": 207,
"source_id": "3",
"poster_name": "chaord",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=262",
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg11783#msg11783",
"date": "2010-08-31T16:35:19Z",
"text": "Interesting calculations. Currently I'm down to one computer myself (laptop), so it's not really worth generating for me. However, I'm wondering whether this is going to be a problem for the network's continued growth and stability? I know there are many threads discussing how there is in fact incentive to continue to generate, even when all 21M are found. My concern is that those 21M coins are going to end up being majority owned by a minority of individuals. Will bitcoin end up with the same pareto properties as other economic and social systems, where 1% of the people end up owning just over 50% of the resource? Is there any way for us to get an accurate gauge on this?
",
"nested_level": 0
},
{
"id": 2639,
"thread_id": 207,
"source_id": "4",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg11786#msg11786",
"date": "2010-08-31T17:13:34Z",
"text": "I can't wait for someone to write an application that allows group mining of bitcoins. I just can't wait one month to see 50 bitcoins.
",
"nested_level": 0
},
{
"id": 2640,
"thread_id": 207,
"source_id": "5",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg11789#msg11789",
"date": "2010-08-31T18:10:40Z",
"text": " Is there any way for us to get an accurate gauge on this?
No, but if you're still alive in 120 years to see it, count yourself lucky.
I'd be willing to bet that whoever holds the majority of bitcoins in 120 years...
1) they earned them and
2) they are not even born yet.
I can't wait for someone to write an application that allows group mining of bitcoins. I just can't wait one month to see 50 bitcoins.
I think that you missed the point of the blog article.
I can't wait for someone to write an application that allows group mining of bitcoins. I just can't wait one month to see 50 bitcoins.
I think that you missed the point of the blog article.
Heh. I did write the article. But what do I know?
Is It Better To Buy Or Generate Bitcoins?
I'd say: it depends.
if you need coins to do stuff right now, there's no guaranteed way to generate them anyway, can't be \"better\" that way.
if you dont need coins and just want to support the network, there's no need to buy any (or generate, to
try would be enough).
can't even say which is cheaper, or
less expensive, that again depends on where you live and what you have to invest (in power and/or hardware).
for me:
i just went down from ~8000khs to ~1500khs at the latest difficulty-step, so i'm actually not expecting to gain lots of coins in the near future, but still
generate to help find new blocks.
running a machine (that sucks up >20W) only to
generate coins is already useless to me (or needs to be bought/build/invested in first) and (watching current difficulty and market-prices) will prolly result in a loss.
i'm wondering anyway, why the market didn't change at all the last 2 diff.steps, watched and waited a bit, but this is it for me, i'm done generating coins.
sad thing is, that i have to wait about a month to get coins from MtGox too, but i'll at least get some more than 50btc at once, we'll need some other payment-options there quick.
nice article!
I can't wait for someone to write an application that allows group mining of bitcoins. I just can't wait one month to see 50 bitcoins.
I think that you missed the point of the blog article.
Heh. I did write the article. But what do I know?
Bi-polar?
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.
Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
The 24-core beast built in the article probably draws some serious current. Hard to guess how much, but I'd guess about 500W? Anyone know?
This will add 360kW/h a month to your electric bill, which will easily drive you into the next pricing tier, or maybe two tiers higher. Now your marginal power can be $0.18 kW/hr.
Yikes.
That bitcoin miner would be about $2/day to run, or $788 a year, which means you've never matched the hardware cost of the system in two or three years.
If you have to actively cool the room with the computer, at least during daytime, double it again.
",
"nested_level": 0
},
{
"id": 2646,
"thread_id": 207,
"source_id": "11",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg11811#msg11811",
"date": "2010-09-01T02:17:39Z",
"text": " i'm wondering anyway, why the market didn't change at all the last 2 diff.steps, watched and waited a bit, but this is it for me, i'm done generating coins.
sad thing is, that i have to wait about a month to get coins from MtGox too, but i'll at least get some more than 50btc at once, we'll need some other payment-options there quick.
nice article!
I don't know if this is the case here, but markets do anticipate things, I can't say that the difficulty increases were really surprising in any way. Profitable speculators also tend to even prices out over time. If you actually figure out how to \"buy low, sell high\" you are providing the service of evening out prices over time, or in the case of arbitrage, evening prices out indifferent locations.
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.
Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
This is a calculation that depends highly on who you are and where you live. I live in an area that recently had a 10%+ residental electric rate hike, to about 8 cents per KWH. This is only
slightly more expensive per btu than using natural gas with a 90% efficient gas heater versus a 100% efficent electric heater. So the price difference for me to run any computer full tilt during the heating season, which is most certainly longer than Southern California, is about half a penny per kilowatt or less. I don't even know anyone who bothers to shut down their computers from September to May to save money. There's also someting to be said for the soothing white noise of a (good condition) cpu fan as the beast in the corner crunching numbers keeps your bedroom a couple degrees warmer so that you can turn the house thermostat down to 69 degrees at night. I can't prove it, but I would bet that I actually
save energy doing this, because otherwise my wife would insist on turning up the heat.
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.
Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
The 24-core beast built in the article probably draws some serious current. Hard to guess how much, but I'd guess about 500W? Anyone know?
The 24-core beast will draw a minimum of 380W (using the power supply calculator:
http://educations.newegg.com/tool/psucalc/index.html)
I can't say that the difficulty increases were really surprising in any way.
difficulty increases of course weren't surprising, we can expect some more sooner or later.
what surprised me was the non-responding market.
if
sellers have to invest more time/energy into mining, why do they still sell that cheap?
i'm ok with it though, i wanna buy anyway.
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.
Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
This is a calculation that depends highly on who you are and where you live. I live in an area that recently had a 10%+ residental electric rate hike, to about 8 cents per KWH. This is only
slightly more expensive per btu than using natural gas with a 90% efficient gas heater versus a 100% efficent electric heater. So the price difference for me to run any computer full tilt during the heating season, which is most certainly longer than Southern California, is about half a penny per kilowatt or less. I don't even know anyone who bothers to shut down their computers from September to May to save money. There's also someting to be said for the soothing white noise of a (good condition) cpu fan as the beast in the corner crunching numbers keeps your bedroom a couple degrees warmer so that you can turn the house thermostat down to 69 degrees at night. I can't prove it, but I would bet that I actually
save energy doing this, because otherwise my wife would insist on turning up the heat.
That's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?
Heh, so bitcoins will be a cold climate manufactured good, lol.
That's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?
The power to the screen gets converted to heat too, even the light produced would get converted to heat.
[
That's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?
To a point, yes. The trick is knowing where that point of dimishishing returns begins, and how it varies.
Heh, so bitcoins will be a cold climate manufactured good, lol.
It already is. I know from private conversations that a statisticly significant number of long-time forum members are Canadians. At least one of whom has been selling off last winter's heat bill. If there are more people who generate bitcoins in the northern hemisphere (which is almost certainly the case) one would expect to see a seasonal component to the difficulty. At least once the difficultly reaches a mature balance in the future. This is an effect that several of those distributed.net type people have noticed before. Their overall computational power trends slightly up during the winter months in the northern hemisphere.
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.
Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
The 24-core beast built in the article probably draws some serious current. Hard to guess how much, but I'd guess about 500W? Anyone know?
The 24-core beast will draw a minimum of 380W (using the power supply calculator:
http://educations.newegg.com/tool/psucalc/index.html)
What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.
A single Phenom II X4 consumes at full load approximately 125W (see TDP:
http://en.wikipedia.org/wiki/AMD_Phenom), 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).
As you're expected to generate one block each day,
you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ...
What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.
A single Phenom II X4 consumes at full load approximately 125W (see TDP:
http://en.wikipedia.org/wiki/AMD_Phenom), 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).
As you're expected to generate one block each day,
you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ...
Most of those power calculators will show you only the peak power needed which is generally at startup time, not at full load running. This is good for selecting the power supply you need but not so good for estimating the power costs over the long run. Unless this 6 socket beast is seriously different from smaller systems in that way.
I set up a Kill-a-Watt to my computer and calculated with 2200 khash/s, I was using 140 watts (monitors off). According to the calculator, I should produce a block every 14 days, 2 hours, 3 minutes, or every 338.05 hours. It would cost me 47.327 Kwh to produce a block, at 12 cents per Kwh, thats $5.68 per block, a net loser.
What is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.
Difficulty level 1000 by year end.
",
"nested_level": 0
},
{
"id": 2656,
"thread_id": 207,
"source_id": "21",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg12187#msg12187",
"date": "2010-09-07T19:52:29Z",
"text": "I set up a Kill-a-Watt to my computer and calculated with 2200 khash/s, I was using 140 watts (monitors off). According to the calculator, I should produce a block every 14 days, 2 hours, 3 minutes, or every 338.05 hours. It would cost me 47.327 Kwh to produce a block, at 12 cents per Kwh, thats $5.68 per block, a net loser.
What is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.
Difficulty level 1000 by year end.
2000 at least imo, but my guess is 8500.
What is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.
Difficulty level 1000 by year end.
i just did a short test on the lately released cuda-client, here's the results
AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt
GTX260
->puddinpop's cuda client
~33000khs ~200Watt
cpu-work isn't profitable for me anymore, i already shut down most generators at the latest diff.step,
gfx-crunching would indeed be profitable again,
i don't really wanna trust a client that fondles with my balance on it's own though, so i don't use it.
hopefully we'll see an open source client some day.
but your joking about that 1000, arent ya?
end of the year?
maybe end of the week.
using seconds from 12/18/2009 3:56:01 as base 0 (the last time difficulty was 1.0000), A y=mx+b linear regression of the log of difficulty levels:
m=2.87698e-07
b=-0.611057
use b=-363.4351 for the seconds you programmers use.
example: block 46368 was generated at 1269212064. exp(1269212064*2.87698e-07 - 363.4351) = exp(1.71409) = predicted level of 5.551602 vs actual level of 4.565162.
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.freeimagehosting.net%2Fuploads%2F65e945c683.png&t=589&c=Y7fQ1tkC5cqzSw\"/)
The correlation factor was 0.957 between the date and log of difficulty level.
This predicts future difficulty levels of:
9/30/2010 : 677.7963
10/31/2010 : 1,464.7148
11/30/2010 : 3,087.5334
12/31/2010 : 6,672.1461
1/31/2011 : 14,418.4781
2/28/2011 : 28,919.2776
3/31/2011 : 62,494.4307
4/30/2011 : 131,734.6149
5/31/2011 : 284,677.9188
6/30/2011 : 600,084.4486
12/31/2011 : 58,149,375.6523
If the trend continues, it will be quite difficult to generate coins in the near future
I don't like the total cost of the computer. You could do without the keyboard, mouse, monitor. In addition, get the cheapest RAM stick you can find, a cheap 8GB SSD (energy saving) then install Debian 5. Access it through SSH and turn on bitcoin. You could easily do it to $300-$500 less and cut power costs by getting a high-efficiency PSU.
",
"nested_level": 0
},
{
"id": 2660,
"thread_id": 207,
"source_id": "25",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?",
"url": "https://bitcointalk.org/index.php?topic=955.msg12227#msg12227",
"date": "2010-09-08T13:42:34Z",
"text": "Someone should set up a newegg affiliate program and recommend the best bitcoin generation gear.
Someone should set up a newegg affiliate program and recommend the best bitcoin generation gear.
Once the GPU client gets perfected, I'm going to get a GTX 465, throw in a cheap dual-core CPU, 512MB RAM, and a case/cpu combo; then I am going place it in a closet and let it print Bitcoins for a year or two.
It's about a $500 investment but with patience and careful energy management it might profit.
AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt
Did you try -4way?
How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.
AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)
There's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually.
http://bitcointalk.org/index.php?topic=820.0Warning :Check your system data and time , you may not be able to generate or receive the most recent blocks !
What does it mean ?
I'm just with 2 connections and 500 blocks.
If your system clock is too far off, blocks that you create would be rejected, and your client will reject any blocks that it views have been created with a future date.
",
"nested_level": 0
},
{
"id": 2665,
"satoshi_id": 434,
"thread_id": 208,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg12063#msg12063",
"date": "2010-09-05T23:36:20Z",
"text": "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 clock
2) the other nodes, if within an hour of the system clock
if those disagree, then
3) the user (asking the user to fix the system clock)
I've thought about NTP, but this is more secure.
",
"nested_level": 0
},
{
"id": 2666,
"thread_id": 208,
"source_id": "4",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg12081#msg12081",
"date": "2010-09-06T05:19:29Z",
"text": "I've thought about NTP, but this is more secure.
IMHO there is no reason for a modern system to not run a NTP client/daemon.
I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.
",
"nested_level": 0
},
{
"id": 2668,
"thread_id": 208,
"source_id": "6",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg12101#msg12101",
"date": "2010-09-06T12:51:37Z",
"text": "Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
\"Please check that your computers date and time are correct. If your clock is wrong Bitcoin will not work properly.\"
I'd go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they'd do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.
The code is about 5 lines and some simple math (sums) when calculating the timestamps.
",
"nested_level": 0
},
{
"id": 2670,
"thread_id": 208,
"source_id": "8",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg12118#msg12118",
"date": "2010-09-06T17:25:18Z",
"text": "I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.
Hell no, NTP does a good job. Don't have other services changing the clock (also counts for bitcoin). Right tool for the right job!
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
\"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly.\"
Thanks.
Thanks.
Thank
you Satoshi for sneaking that possessive apostrophe into \"computer's date\"!
I'd go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they'd do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.
The code is about 5 lines and some simple math (sums) when calculating the timestamps.
Why a server when so many are already out there?
I'd agree that we don't want bitcoin client bloat, and definitely NO WAY the bitcoin client should be setting the system time.
But maybe it is worth it in the error case for the bitcoin client to put a message in the log and attempt to use a network time instead of system time.
As for the servers out there, the bitcoin client already has http, right? Well, most http servers now provide the date in their headers. For example, in python:
import os, re, urllib
info = urllib.urlopen('http://www.yahoo.com/').info()
regx = r'Date:\\s+[A-Z][a-z]{2}, (\\d{1,2}) ([A-Z][a-z]{2}) (\\d{1,4}) (\\d\\d:\\d\\d:\\d\\d)'
d, M, Y, T = re.search(regx,str(info)).groups()
m = 1+\"JanFebMarAprMayJunJulAugSepOctNovDec\".index(M)/3
print '%04d.%02d.%02d-%s' % (int(Y), m, int(d), T)
(that output format happens to work with \"date -us\" if you did want to set some system time)
of course it would be better to check a couple of sites rather than relying on just yahoo to keep their http server time set properly.
I think we all agree that setting the system time is a no go, but why can't we just use an offset internally and just circumvent the whole issue? We already have ways to synchronize (approximately) the clients, so why not make use of that?
",
"nested_level": 0
},
{
"id": 2675,
"thread_id": 208,
"source_id": "13",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg13239#msg13239",
"date": "2010-09-20T03:39:55Z",
"text": "Agreed. There is no need to set the system time.
We only need to use correct time in the program.
",
"nested_level": 0
},
{
"id": 2676,
"satoshi_id": 459,
"thread_id": 208,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Warning : Check your system ( Help me )",
"url": "https://bitcointalk.org/index.php?topic=960.msg13833#msg13833",
"date": "2010-09-23T16:28:25Z",
"text": "I don't understand, are you under the impression that the program sets the system clock? It doesn't.
We already have ways to synchronize (approximately) the clients, so why not make use of that?
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 hour. If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.
When running with revision 146 (trunk) I get the following when the miner attempts to start:
bitcoind: cryptopp/secblock.h:187: void CryptoPP::NullAllocator<T>::deallocate(void*, typename CryptoPP::AllocatorBase<T>::size_type) [with T = unsigned char]: Assertion `false' failed.
+ cd '/tmp/rmake/builds/bitcoin/bitcoin--trunk/'; CFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector\" CXXFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector \" CPPFLAGS=\"\" CLASSPATH=\"\" LDFLAGS=\"-g -O1 \" CC=gcc CXX=g++ make
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/util.o util.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/script.o script.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/db.o db.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/net.o net.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/irc.o irc.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/main.o main.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/rpc.o rpc.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/init.o init.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -O3 -o cryptopp/obj/sha.o cryptopp/sha.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -O3 -o cryptopp/obj/cpu.o cryptopp/cpu.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/ui.o ui.cpp
ui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':
ui.h:308: warning: converting to 'int' from 'double'
ui.h:309: warning: converting to 'int' from 'double'
ui.cpp: In constructor 'CMainFrame::CMainFrame(wxWindow*)':
ui.cpp:264: warning: passing 'double' for argument 1 to 'void wxWindowBase::SetSize(int, int)'
ui.cpp:264: warning: passing 'double' for argument 2 to 'void wxWindowBase::SetSize(int, int)'
ui.cpp:287: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:288: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:289: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:290: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:291: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:292: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:293: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'
ui.cpp:299: warning: converting to 'int' from 'double'
ui.cpp:300: warning: converting to 'int' from 'double'
ui.cpp: In member function 'virtual void CMainFrame::OnIconize(wxIconizeEvent&)':
ui.cpp:379: warning: 'Iconized' is deprecated (declared at /usr/include/wx-2.9/wx/event.h:1950)
ui.cpp:387: warning: 'Iconized' is deprecated (declared at /usr/include/wx-2.9/wx/event.h:1950)
ui.cpp: In constructor 'CSendingDialog::CSendingDialog(wxWindow*, const CAddress&, int64, const CWalletTx&)':
ui.cpp:2005: warning: passing 'double' for argument 1 to 'void wxWindowBase::SetSize(int, int)'
ui.cpp:2005: warning: passing 'double' for argument 2 to 'void wxWindowBase::SetSize(int, int)'
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/uibase.o uibase.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -msse2 -O3 -march=amdfam10 -o obj/sha256.o sha256.cpp
g++ -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o bitcoin obj/util.o obj/script.o obj/db.o obj/net.o obj/irc.o obj/main.o obj/rpc.o obj/init.o cryptopp/obj/sha.o cryptopp/obj/cpu.o obj/ui.o obj/uibase.o obj/sha256.o -Wl,-Bstatic -l wx_gtk2ud-2.9 -Wl,-Bdynamic -l gtk-x11-2.0 -l SM -Wl,-Bstatic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l crypto -Wl,-Bdynamic -l gthread-2.0
+ strip bitcoin
+ copying /tmp/rmake/builds/bitcoin/bitcoin--trunk/bitcoin to /tmp/rmake/builds/bitcoin/_ROOT_/usr/bin/bitcoin
+ cd '/tmp/rmake/builds/bitcoin/bitcoin--trunk/'; CFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector\" CXXFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector \" CPPFLAGS=\"\" CLASSPATH=\"\" LDFLAGS=\"-g -O1 \" CC=gcc CXX=g++ make bitcoind
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/util.o util.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/script.o script.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/db.o db.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/net.o net.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/irc.o irc.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/main.o main.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/rpc.o rpc.cpp
g++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/init.o init.cpp
g++ -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o bitcoind obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o cryptopp/obj/sha.o cryptopp/obj/cpu.o obj/sha256.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l crypto -Wl,-Bdynamic -l gthread-2.0
",
"nested_level": 0
},
{
"id": 2678,
"thread_id": 209,
"source_id": "2",
"poster_name": "denger",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=370",
"subject": "Re: CryptoPP Assertion Error",
"url": "https://bitcointalk.org/index.php?topic=967.msg12051#msg12051",
"date": "2010-09-05T13:43:28Z",
"text": "I get a similar error with version 3.11 compile for CentOS 5.5:
bitcoind: cryptopp/secblock.h:187: void CryptoPP::NullAllocator<T>::deallocate(void*, typename CryptoPP::AllocatorBase<T>::size_type) [with T = unsigned char]: Assertion `false' failed.
I have tried wiping .bitcoin directory thinking some old stuff is incompatible, but get the same when starting fresh.
Anyone can help?
",
"nested_level": 0
},
{
"id": 2679,
"thread_id": 209,
"source_id": "3",
"poster_name": "denger",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=370",
"subject": "Re: CryptoPP Assertion Error",
"url": "https://bitcointalk.org/index.php?topic=967.msg12052#msg12052",
"date": "2010-09-05T13:50:55Z",
"text": "Forgot to mention that I only see this error when trying to run bitcoind with sox proxy:
~/bitcoind -proxy=127.0.0.1:10000 -gen -server
My proxy is the ssh channel:
ssh -n -D localhost:10000
someone@somewhere.com \"bash -c \\\"while true; do sleep 100; done\\\"\" &
You can probably just comment out the line
cryptopp/secblock.h:187
//assert(false);
Let me know if it works, and watch if it memory leaks.
It looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm.
",
"nested_level": 0
},
{
"id": 2681,
"thread_id": 210,
"source_id": "1",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "HTTP status codes from the JSON-RPC api",
"url": "https://bitcointalk.org/index.php?topic=969.msg11884#msg11884",
"date": "2010-09-01T20:28:15Z",
"text": "I just submitted a patch to Satoshi to make bitcoin follow the
JSON RPC over HTTP spec, and to use the standardized error codes from the JSON-RPC 1.1/2.0 specs.
If you talk directly to bitcoin via JSON-RPC calls, you might need to change your code to recognize the new HTTP status codes and the new format for the 'error' member of the JSON response. For example:
BEFORE, send {\"id\":\"123\", \"method\": \"nosuchmethod\", \"params\": [] } , get response:
HTTP/1.1 500 Internal Server Error
...
{\"result\":null,\"error\":\"Method not found.\",\"id\":\"123\"}
AFTER:
HTTP/1.1 404
...
{\"result\":null,\"error\":{\"code\":-32601,\"message\":\"Method not found\"},\"id\":\"123\"}
I also removed the broken 'Batch' support, to simplify the code. I had JSON-RPC-2.0 batch support working properly, but backed those changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to support right now (none of the JSON-RPC glue libraries support it yet, and the spec is still changing a bit).
Speak now about this change or forever hold your peace... Satoshi will be including this functionality in the next version of Bitcoin (0.3.12).
If you use the JSON-RPC api, you should check your error-condition-handling code; again, the changes are that the error member will be an Object (with 'code' and 'message' fields) instead of a String, and the HTTP status code may be 404 instead of 500 for method-not-found.
",
"nested_level": 0
},
{
"id": 2683,
"satoshi_id": 435,
"thread_id": 210,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: HTTP status codes from the JSON-RPC api",
"url": "https://bitcointalk.org/index.php?topic=969.msg12130#msg12130",
"date": "2010-09-06T21:21:21Z",
"text": "This is in SVN rev 147.
This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs.
If you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string.
Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The \"backupwallet <destination>\" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy.
",
"nested_level": 0
},
{
"id": 2684,
"thread_id": 211,
"source_id": "1",
"poster_name": "omegadraconis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=597",
"subject": "Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12070#msg12070",
"date": "2010-09-06T02:54:49Z",
"text": "A thought has occurred to me that bitcoins client is released under mit which allows for closed source clients that would give someone an advantage over everyone by modifying the client and not releasing the code. If we changed to GPL this would force anyone who created a modified client to release the source code under the terms of the GPL.
A few thoughts for discussion here:
Do you think switching to GPL would be a good idea?
If someone released a closed source client how could we enforce the GPL?
Would changing to a GPL stifle development in anyway?
Would this make it less likely for new clients to be developed?
",
"nested_level": 0
},
{
"id": 2685,
"thread_id": 211,
"source_id": "2",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12072#msg12072",
"date": "2010-09-06T03:07:12Z",
"text": "I am not sure how it would affect current/existing clients, but I believe switching to gpl would possibly stifle ArtForz's estimated ~25% dominance of block generations and total Bitcoin balance.
Total Bitcoins as of now: 3914550
If ArtForz had 25% of total Bitcoins, then: 978637.5
If each Bitcoin is worth $0.06, then total value: $58,718.25
These figures are not reliable, but are an example.
Here's a better reference:
7.28.2010: <ArtForz> for my opencl sha256 code the 5770 is only 5% faster than the 4870 per core-mhz
block 70800 1280322359
# date -d \"@1280322359\"
Wed Jul 28 08:05:59 CDT 2010
So estimated start time of ArtForz's opencl client was at block 70,800. Current block count is 78,292. 7,492 blocks.
7,492 * 50btc = 374,600btc.
374,600btc * 25% = 93,650btc
93,650btc * $0.06 = $5,619.
So, it is fairly safe to conclude that ArtForz has approximately ~$5,600ish value (and will most likely increase in value over time)
If they were to sell all bitcoins right now on open exchange markets, they could get a guaranteed amount of ~$2,348.
$0.0616 each for BTC757.156 ($46.6408096) at mtg.
$0.0615 each for BTC500 ($30.75) at mtg.
$0.0609 each for BTC610.6 ($37.18554) at mtg.
$0.0601367 each for BTC936 ($56.2879512) at mtg.
$0.0601366 each for BTC2049 ($123.2198934) at mtg.
$0.0601 each for BTC100 ($6.01) at mtg.
$0.06 each for BTC525 ($31.5) at mtg.
$0.0597 each for BTC25.963 ($1.5499911) at mtg.
$0.0596622 each for BTC879 ($52.4430738) at mtg.
$0.0592 each for BTC96.3 ($5.70096) at mtg.
$0.059 each for BTC20 ($1.18) at mtg.
$0.059 each for BTC1000 ($59) at bcm.
$0.0585 each for BTC200 ($11.7) at mtg.
$0.0581 each for BTC600 ($34.86) at mtg.
$0.058 each for BTC1.207 ($0.070006) at mtg.
$0.0574999 each for BTC515.4 ($29.63544846) at mtg.
$0.0574215 each for BTC2404 ($138.041286) at mtg.
$0.057 each for BTC200 ($11.4) at bcm.
$0.056 each for BTC1000 ($56) at bcm.
$0.055 each for BTC100 ($5.5) at bcm.
$0.05148 each for BTC2404 ($123.75792) at mtg.
$0.051 each for BTC500 ($25.5) at mtg.
$0.0505 each for BTC1000 ($50.5) at bcm.
$0.0501 each for BTC400 ($20.04) at bcm.
$0.05 each for BTC100 ($5) at bcm.
$0.05 each for BTC100 ($5) at bcm.
$0.05 each for BTC100 ($5) at mtg.
$0.05 each for BTC1000 ($50) at bcm.
$0.05 each for BTC1000 ($50) at bcm.
$0.05 each for BTC1000 ($50) at bcm.
$0.04825 each for BTC2404 ($115.993) at mtg.
$0.0472 each for BTC1000 ($47.2) at bcm.
$0.045 each for BTC100 ($4.5) at bcm.
$0.045 each for BTC200 ($9) at bcm.
$0.044 each for BTC200 ($8.8) at bcm.
$0.04 each for BTC500 ($20) at bcm.
$0.04 each for BTC600 ($24) at mtg.
$0.04 each for BTC1600 ($64) at bcm.
$0.04 each for BTC2000 ($80) at bcm.
$0.039 each for BTC500 ($19.5) at mtg.
$0.038 each for BTC500 ($19) at mtg.
$0.0375 each for BTC200 ($7.5) at bcm.
$0.037 each for BTC500 ($18.5) at mtg.
$0.035 each for BTC200 ($7) at bcm.
$0.035 each for BTC500 ($17.5) at mtg.
$0.035 each for BTC3000 ($105) at bcm.
$0.034 each for BTC259.118 ($8.810012) at mtg.
$0.033 each for BTC500 ($16.5) at mtg.
$0.033 each for BTC1000 ($33) at bcm.
$0.032 each for BTC500.001 ($16.000032) at mtg.
$0.0301 each for BTC300 ($9.03) at bcm.
$0.03 each for BTC21 ($0.63) at mtg.
$0.03 each for BTC100 ($3) at bcm.
$0.03 each for BTC100 ($3) at bcm.
$0.03 each for BTC500 ($15) at bcm.
$0.03 each for BTC1000 ($30) at bcm.
$0.022 each for BTC1000 ($22) at bcm.
$0.0202 each for BTC1000 ($20.2) at bcm.
$0.02 each for BTC100 ($2) at bcm.
$0.02 each for BTC500 ($10) at bcm.
$0.02 each for BTC1000 ($20) at bcm.
$0.02 each for BTC1000 ($20) at bcm.
$0.02 each for BTC1000 ($20) at bcm.
$0.02 each for BTC1000 ($20) at bcm.
$0.015 each for BTC1000 ($15) at bcm.
$0.0121 each for BTC5000 ($60.5) at bcm.
$0.011 each for BTC5000 ($55) at bcm.
$0.01 each for BTC1000 ($10) at bcm.
$0.01 each for BTC1000 ($10) at bcm.
$0.01 each for BTC1000 ($10) at bcm.
$0.01 each for BTC1000 ($10) at bcm.
$0.01 each for BTC2000 ($20) at bcm.
$0.01 each for BTC5000 ($50) at bcm.
$0.0096 each for BTC1000 ($9.6) at bcm.
$0.007 each for BTC100 ($0.7) at bcm.
$0.006 each for BTC10000 ($60) at bcm.
$0.005 each for BTC1000 ($5) at bcm.
$0.005 each for BTC1000 ($5) at bcm.
$0.005 each for BTC5000 ($25) at bcm.
$0.005 each for BTC8542.255 ($42.711275) at bcm.
Total amount for BTC93650 is $2348.64719856
Perhaps it can be considered that based on the license as it is now that establishments as exemplified above could allow for individuals to dominate large percentages of total Bitcoins and nothing can stop them. Could this could be a deterrent for the acceptance of Bitcoin and hinder its ability to succeed? e.g. I haven't the programming/development skills to produce similar works and therefore establish equal or similar amount of block generations and therefore have a disadvantage to others with proprietary implementations.
While it may be considered to allow for proprietary implementations to establish wider acceptance, it also may be a hinderance to establishing wider acceptance for allowing proprietary implementations.
",
"nested_level": 0
},
{
"id": 2687,
"thread_id": 211,
"source_id": "4",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12076#msg12076",
"date": "2010-09-06T03:44:50Z",
"text": "The GPL doesn't force you to release your source if you don't publish the software publicly. Even the AGPL wouldn't force you to release the source in this case, since you're not really allowing people to interface with your software.
MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.
",
"nested_level": 0
},
{
"id": 2688,
"thread_id": 211,
"source_id": "5",
"poster_name": "omegadraconis",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=597",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12078#msg12078",
"date": "2010-09-06T04:25:40Z",
"text": "The GPL doesn't force you to release your source if you don't publish the software publicly. Even the AGPL wouldn't force you to release the source in this case, since you're not really allowing people to interface with your software.
MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.
I did realize this is true on both accounts. I'm not by any mean saying switching to GPL is a super great idea I was just wondering what everyone thought about it. As has been pointed out it would do nothing to stop someone from making a private client which is fine. If someone spends the time to optimize a client and use it to there own gain then that fine so long as they don't control the whole generation of coins. I would compare that make your own client to capitalism, where as if we were to force everyone to release everything so the field was completely level would be loosely like communism.
I would compare that make your own client to capitalism, where as if we were to force everyone to release everything so the field was completely level would be loosely like communism.
There we have the whole \"FOSS is commie\" discussion again.
I think the use of which FOSS license isn't so much of a deal. I mean, there are a lot of licenses that fall under the OSI definition. And MIT is not so bad. I normally put my software under the GPL, because I like the fact that it is copyleft. But if another dev thinks an other license is better, who am I to judge (I didn't write any code for it). This is the same discussion as GPL vs. BSD (MIT being almost like the BSD license).
There we have the whole \"FOSS is commie\" discussion again.
AH but, I wasn't talking about FLOSS at all .
I meant that by leveling the generation rate across all clients everyone has the same chance to generate a block (well that is if everyone's computer was the exact same) hence commie. Where as if someone make a client to make more khashs then everyone else it's more like capitalism.
I still think we are talking about two different components:
The protocol is open (not well documented but it's out there), while the clients do not have to abide to any special restriction AFAIK. Even if we were to enforce a license on the clients by adding a special clause to the protocol agreement, there would be users that modify an open source client, but then they don't sell it so that they can still keep it closed source.
In one of my projects we are using the RPL, which isn't open source in that sense, it specifies that any modifications to the project have to be shared with the original community, but still that doesn't avoid a client being kept closed source from the start.
Once the network has grown enough it'll get really hard for a single entity to ever tip over the balance like ArtForz because there are more people with the resources and they will compete for the top spot, and thus balance things out.
How about a bounty for both the best performing source enhancement and for the best performing community driven rig? Something like the Netflix 1'000'000$ bounty for code improvements?
I'm against any switch to copyleft. If the primary bitcoin implementation is copyleft, then at some point someone will want/need a copycentre implementation and duplicate a lot of work. Liberal licensing is the best way to minimize duplicate work.
",
"nested_level": 0
},
{
"id": 2693,
"thread_id": 211,
"source_id": "10",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12149#msg12149",
"date": "2010-09-07T05:18:36Z",
"text": "Liberal licensing is the best way to minimize duplicate work.
Heh... no clear view of the current software world?
If you see how many different \"duplicate\" software packages there are, duplicate work is done a lot (for various reasons, even licenses).
I think even on this forum people are working on a second client (the python client). Having multiple clients does not have to be a bad thing.
Nobody, who is sane licenses stuff that is supposed to be a major implementation of a protocol using a restrictive license as GPL. If you do this now you'd most likely cause a fork anyway, because they want to stay with this license.
When it comes to preventing people from using faster clients there isn't anything you can do. The best thing would be implement it into the main client, so you can be sure nobody dominates because of this. If someone is interested in a stable currency it is better to give it to everyone, because there can be someone who simply has more money to buy FPGAs, GPUs or whatever.
What would really hinder someone to simply ignore the license. With GPL and AGPL software you don't even violate the license, but even a custom license would not stop it.
The MIT (and some others, like BSD) are nice if you want to create standards. That's why most libraries use them and the hardcore-GNU-folks have created a LGPL, but I can't really think of anything that was first implemented using the LGPL and then became a widely used standard. Maybe there is something, maybe much more than I'd expect. I am not a big friend of the GPL, but it's not like I'd hate it. After all it's still Open Source and that's what I care most.
But I think nobody really thinks about relicensing it anyway.
What do you think about creating bounties for performance improvements. Like someone should add support for ATI stream? We could make a thread similar to the EFF donation thread. I know there is a thread about it, but it is most likely not the only possible performance improvement and of course not the only (C)PU.
",
"nested_level": 0
},
{
"id": 2695,
"thread_id": 211,
"source_id": "12",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12176#msg12176",
"date": "2010-09-07T18:37:02Z",
"text": "Protocols are IMHO not licensable anyway.
If you do clean room reverse engineering, you could make a compatible interface to a protocol and would not have to agree with any license.
",
"nested_level": 0
},
{
"id": 2696,
"thread_id": 211,
"source_id": "13",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12192#msg12192",
"date": "2010-09-07T20:44:42Z",
"text": "Protocols are IMHO not licensable anyway.
If you do clean room reverse engineering, you could make a compatible interface to a protocol and would not have to agree with any license.
While I agree that reverse engineering is always a possibility, protocols can be licensed under different Intellectual Property regulations, that may or may not include licenses (see patents...)
So, it is fairly safe to conclude that ArtForz has approximately ~$5,600ish value (and will most likely increase in value over time)
Unless he already sold them.
MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.
I dont have any problem with MIT license, but there are a lot of companies that are using and developing GPL software. Saying that companies dont like GPL is not true.
MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.
I dont have any problem with MIT license, but there are a lot of companies that are using and developing GPL software. Saying that companies dont like GPL is not true.
The GPL is the same as any other commercial license. Any company can license a GPL'd software just the same as they would license any other software: by contacting the developer and arranging for a commercial license.
The GPL just adds the EXTRA benefit that you can also use it for free, as long as your code is ALSO open source.
So any company that has a problem with GPL, must have a problem with ALL commercial licenses as well, and thus they are stuck using ONLY software under the MIT or Apache license. Presumably such a company doesn't run Mac or Windows in-house.
Of course those anarcho-capitalits among us who do not recognize \"copyright\" as natural because it is an attempt to limit what someone else can do with their knowledge and information is not \"scarce\" as each new copy does not diminish the original owners property. So you cannot copyright code any more than music or anything else. Once you share an idea with someone else it is in their head and there is no taking it back nor telling them what they can do. Copyright does not exist without the state and is ARBITRARY in its duration.
Conclusion, copyright and licenses only matter to statists. It is a \"monopoly\" that is maintained by force vs free competition.
If you want a \"competitive advantage\" never release the code. If you release the code, you have no right to use force to prevent others from using, distributing, or creating derivative works from it.
",
"nested_level": 0
},
{
"id": 2701,
"thread_id": 211,
"source_id": "18",
"poster_name": "Macho",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=625",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12400#msg12400",
"date": "2010-09-11T02:10:14Z",
"text": "For a software like this, *only* GPL license makes any sense. It's not about an ideology but rather
anyone who would trust proprietary software for their financial transactions and a system like bitcoin is a fool and deserves what's coming for them (which is a lot of stolen \"cash\"). Using
proprietary software may even result in hijacking of the whole bitcoin network if significant portion of people would use such a client. There is no way to reliably test for backdoors or other nasty stuff, any closed-source software should be essentially banished by the bitcoin community. GPL allows you to make private in-house modification as much as you like so that's not an issue at all. The only situation that causes GPL to trigger is when you *distribute* the software to other people, in which case you have to provide sources along with it which is the only way anyone should accept any software dealing with bitcoin anyway.
You have to also realize that
there are no legal consequences to any \"theft\" as using bitcoin from neutral point of view is essentially just moving some arbitrary bits around. So the bitcoin community is expected to self-regulate, which should come in a form of an enforced transparency (by all the users rejecting anything else). Considering any other license than GPL-like is playing with fire and is not going to end well.
I did not realize current bitcoin client was released under MIT license,
This should be changed to GPL IMMEDIATELY!GPLv3 even protects you from said software to be locked up by DRM so even when it's open-source you would not have access to it. There is no disadvantage to using GPL license really. Anyone spreading FUD about GPL is either not appropriately informed/did not consider all the issues or has an ulterior motive as far as I'm concerned. I'm not going to trust any closed-source, that's for sure ... and if significant portion of the bitcoin community is, then I'm going to sell off all my bitcoins and get out as that's a prescription for disaster, sooner or later.
As much as adoption is concerned, I'm not interested in people who feel the need to keep the source closed and hidden from its users to \"adopt\" anything as I would hope anyone concerned about the success and reliability of the bitcoin network wouldn't either. To complain about weak adoption in that sphere is like complaining about weak adoption by criminals to me. If someone is honest, they should feel no interest in keeping the source closed ... and every sane person would accept ONLY open-sourced software anyway. It's a win-win situation
Ehh.... Macho, bitcoin IS open source. MIT license IS a open source license.
No closed source, proprietary software or DRM here.
",
"nested_level": 0
},
{
"id": 2703,
"satoshi_id": 451,
"thread_id": 211,
"source_id": "20",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Switch to GPL",
"url": "https://bitcointalk.org/index.php?topic=989.msg12494#msg12494",
"date": "2010-09-12T19:24:53Z",
"text": "If the only library is closed source, then there's a project to make an open source one.
If the only library is GPL, then there's a project to make a non-GPL one.
If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.
I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone.
",
"nested_level": 0
},
{
"id": 2704,
"thread_id": 212,
"source_id": "1",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "bitcoind as daemon in OSX",
"url": "https://bitcointalk.org/index.php?topic=992.msg12133#msg12133",
"date": "2010-09-06T21:44:06Z",
"text": "I've been getting this from the start, and it is only a mild nuisance as I develop in OSX but then deploy on linux.
Anyway, the bitcoind process doesn't daemonize itself on my system, OSX 10.6, not with nor without -daemon. I can background it with '&' or ctrl-z bg, and it works correctly.
",
"nested_level": 0
},
{
"id": 2705,
"satoshi_id": 438,
"thread_id": 212,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: bitcoind as daemon in OSX",
"url": "https://bitcointalk.org/index.php?topic=992.msg12135#msg12135",
"date": "2010-09-06T21:52:45Z",
"text": "Can you build?
Try changing line 78 of init.cpp from:
#ifdef __WXGTK__
to:
#ifndef __WXMSW__
If that works, I'll change the source. It should work.
",
"nested_level": 0
},
{
"id": 2706,
"thread_id": 213,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12145#msg12145",
"date": "2010-09-07T03:17:34Z",
"text": "
To accurately reflect that processing a transaction has certain resource costs across the network, I propose that tx fee be required for every transaction after X datetime (where X is a few months in the future).
",
"nested_level": 0
},
{
"id": 2707,
"thread_id": 213,
"source_id": "2",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12147#msg12147",
"date": "2010-09-07T04:10:39Z",
"text": "I propose that that number of months be 1440.
",
"nested_level": 0
},
{
"id": 2708,
"thread_id": 213,
"source_id": "3",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12152#msg12152",
"date": "2010-09-07T07:19:01Z",
"text": "That will probably happen spontaneously if someone make a client (or add the option to the current one) that allows the user to charge transaction fees for the blocks it generates.
",
"nested_level": 0
},
{
"id": 2709,
"thread_id": 213,
"source_id": "4",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12155#msg12155",
"date": "2010-09-07T08:04:49Z",
"text": "The correct fee is so small right now that the psychological detriment far outweighs the benefits of charging it imo. It's like that damn place that charges me a quarter a tiny cup of water when I buy a $9 meal. Yes, I know there are costs to pressing the button, but now I don't like you anyway.
I expect it will be a long time before a high % of nodes require a fee for normal transactions. This means most users will not attach a fee, being willing to wait 4 blocks on average or whatever. So for a good while charging a fee simply means not putting transactions in blocks, this will make bitcoin slightly less appealing and slightly reduce use which will slightly reduce the value of coins. So anyone who has coins can self interestedly include transactions for free.
Jgarzik, do you have a guess as to the resource costs of a normal transaction?
",
"nested_level": 0
},
{
"id": 2710,
"satoshi_id": 439,
"thread_id": 213,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12168#msg12168",
"date": "2010-09-07T16:32:21Z",
"text": "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 threshold should probably be lower than it currently is.
I don't think the threshold should ever be 0. We should always allow at least some free transactions.
",
"nested_level": 0
},
{
"id": 2711,
"thread_id": 213,
"source_id": "6",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12171#msg12171",
"date": "2010-09-07T17:36:22Z",
"text": "If you WANT to start paying the transaction fees now you can with the -paytxfee=0.01
(beta?) command line switch. If more people use this switch then it might help discourage others from requiring compulsory fees.
",
"nested_level": 0
},
{
"id": 2712,
"thread_id": 213,
"source_id": "7",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg12182#msg12182",
"date": "2010-09-07T19:20:29Z",
"text": "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 threshold should probably be lower than it currently is.
I don't think the threshold should ever be 0. We should always allow at least some free transactions.
What is the current threshold, and how does a client know to pay for this in advance?
What is the current threshold, and how does a client know to pay for this in advance?
http://www.bitcoin.org/wiki/doku.php?id=transaction_feeCurrently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.
It's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block.
I did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions:
There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.
Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.
The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.
The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.
",
"nested_level": 0
},
{
"id": 2715,
"satoshi_id": 457,
"thread_id": 213,
"source_id": "10",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Always pay transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=994.msg13829#msg13829",
"date": "2010-09-23T16:08:35Z",
"text": "The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.
I implemented this change in SVN rev 157.
The reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.
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 exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.
If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {\"code\":<number>,\"message\":<string>}, which is the standard. See this thread:
http://bitcointalk.org/index.php?topic=969.0Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/What does the prohibition of \"nonstandard\" transactions do?
main.cpp:506
// Rather not work on nonstandard transactions
if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
return error(\"AcceptToMemoryPool() : nonstandard transaction\");
What is included in \"GetSigOpCount\", and what does \"GetSerializeSize\" measure?
This is \"lightly\" enforced by the network:
main.cpp:1425
// Check that it's not full of nonstandard transactions
if (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)
return error(\"AcceptBlock() : too many nonstandard transactions\");
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 only work on adding those transactions to their block.
In the future, if we add more templates to the existing 2 types of transactions, we can change the \"rather not work on nonstandard transactions\" test to accept them.
",
"nested_level": 0
},
{
"id": 2719,
"satoshi_id": 444,
"thread_id": 215,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Auto-detect for 128-bit 4-way SSE2",
"url": "https://bitcointalk.org/index.php?topic=1007.msg12262#msg12262",
"date": "2010-09-09T01:04:05Z",
"text": "SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.
It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw.
Here's what I ended up with:
// We need Intel Nehalem or AMD K10 or better for 128bit SSE2
// Nehalem = i3/i5/i7 and some Xeon
// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
// Intel Core i5 family 6, model 26 or 30
// Intel Core i7 family 6, model 26 or 30
// Intel Core i3 family 6, model 37
// AMD Phenom family 16, model 10
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.
If it's wrong, you can still override it with -4way or -4way=0.
It prints what it finds in debug.log. Search on CPUID.
This is only enabled if built with GCC.
You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.
",
"nested_level": 0
},
{
"id": 2721,
"thread_id": 215,
"source_id": "3",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Auto-detect for 128-bit 4-way SSE2",
"url": "https://bitcointalk.org/index.php?topic=1007.msg12321#msg12321",
"date": "2010-09-09T15:39:08Z",
"text": "You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.
Yeah, while implementing the cuda hasher I thought about this. There should be an interface to the hashing handler (or even a full miner per implementation) and we should have a simple way of giving it a known block, ask it to hash 1000 nonces and compare the result, while benchmarking at the same time. Shouldn't be too hard to implement and would help when developing new algorithms.
The interface schema would also help if we were to plug in an fpga based engine or something of the kind, having specific entry points into the code without having to tweak on the default mining schema.
You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.
+1 agreed. It's not difficult or time-consuming for each user to do this at startup.
Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to
#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)
to make it compile again, at least on ARM.
",
"nested_level": 0
},
{
"id": 2724,
"thread_id": 215,
"source_id": "6",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: Auto-detect for 128-bit 4-way SSE2",
"url": "https://bitcointalk.org/index.php?topic=1007.msg12349#msg12349",
"date": "2010-09-10T02:47:31Z",
"text": "I wonder if we could get the VIA C7 code included with an autodetect in the standard clients? Or is this just too rare a beast to trouble the main code over? The C7 does work with the standard clients with regular pentium or sse2 code albeit slower.
",
"nested_level": 0
},
{
"id": 2725,
"thread_id": 215,
"source_id": "7",
"poster_name": "nimnul",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=600",
"subject": "Re: Auto-detect for 128-bit 4-way SSE2",
"url": "https://bitcointalk.org/index.php?topic=1007.msg12361#msg12361",
"date": "2010-09-10T12:34:11Z",
"text": "> There should be an interface to the hashing handler (or even a full miner per implementation)
+1. In case someone wants FPGA/whatever specific accelerator he has.
",
"nested_level": 0
},
{
"id": 2726,
"satoshi_id": 448,
"thread_id": 215,
"source_id": "8",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Auto-detect for 128-bit 4-way SSE2",
"url": "https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372",
"date": "2010-09-10T18:11:06Z",
"text": "Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to
#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)
to make it compile again, at least on ARM.
Added in SVN rev 152
adg
",
"nested_level": 0
},
{
"id": 2728,
"thread_id": 216,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12310#msg12310",
"date": "2010-09-09T14:05:11Z",
"text": "If you send your entire balance, then you won't have enough left to pay any fee. You could send 49.99.
I don't know why that's happening. There shouldn't be a fee for any non-combined transaction.
",
"nested_level": 0
},
{
"id": 2729,
"thread_id": 216,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12329#msg12329",
"date": "2010-09-09T18:43:13Z",
"text": "0.3.12 contains some changes to transaction fees. Are you using that?
",
"nested_level": 0
},
{
"id": 2730,
"thread_id": 216,
"source_id": "4",
"poster_name": "TTBit",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=844",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12339#msg12339",
"date": "2010-09-09T20:10:24Z",
"text": "Rounding error? Have you received bitcoins from the faucet, then paid 0.0495 btc to someone. Ever done anything in the 3rd decimal or beyond? I have 0.01 at TAABL that I can't withdraw due to rounding error. Still, +50.00 is +50.00, and should be able to withdraw that.
Fresh blocks take something like 100 blocks to confirm. I assume you waited.
",
"nested_level": 0
},
{
"id": 2731,
"satoshi_id": 445,
"thread_id": 216,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341",
"date": "2010-09-10T00:23:24Z",
"text": "What version is the one where this happened? Release build, or built it yourself? Which operating system?
Were you sending by IP or by Bitcoin Address?
When you sent 49.99, did it prompt you to pay a 0.01 fee?
There was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge.
The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.
",
"nested_level": 0
},
{
"id": 2732,
"satoshi_id": 446,
"thread_id": 216,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12342#msg12342",
"date": "2010-09-10T00:46:37Z",
"text": "I think I know what happened. Doubleclick on the generated transaction. It probably has a sub-0.01 transaction fee in it.
Someone has been paying a 0.00000010 transaction fee. I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it. Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.
It would normally be harmless except in this corner case. I should add a special case to CreateTransaction to handle this.
",
"nested_level": 0
},
{
"id": 2733,
"thread_id": 216,
"source_id": "7",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12363#msg12363",
"date": "2010-09-10T14:02:36Z",
"text": "I'm really puzzled with all this. I also generated a block and transferred it out on the spot. Looking at the transaction:
\"address\" : \"1LCSXSx8sjcZKHFXbyasBsuEdJtBVRaco7\",
\"label\" : \"\",
\"txid\" : \"1249190d1a13b03b51c27ded2e8441d446a8ae6ef90f90db31a8267da0845685\",
\"txtime\" : 1283997623,
\"category\" : \"debit\",
\"amount\" : 50.01000000,
\"confirmations\" : 228
},
it seems I paid the fee too. Why would that be? A block that had too many tx, the value coming from multiple small value purses (but the client should see one purse that satisfies the whole transaction, right?) or what else?
",
"nested_level": 0
},
{
"id": 2734,
"thread_id": 216,
"source_id": "8",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Won't let me send coins because it requires a transaction fee?",
"url": "https://bitcointalk.org/index.php?topic=1013.msg12364#msg12364",
"date": "2010-09-10T14:31:12Z",
"text": "So I lost a penny in it. My question then, that transaction fee, then goes to the next block? Or the one before the one I generated?
You didn't pay a transaction fee. You have .01000010 in your balance; you just can't spend it. The network would accept it if you sent the entire 0.01000010 to another address (you can't break it apart), but the Bitcoin interface doesn't support such high precision.
Since fees apply to transactions less than 0.01, adding a transaction fee should be at least 0.01 right?
That's not network-enforced. Transaction fees are not \"outs\", so they're not subject to the \"dust spam\" restriction.
it seems I paid the fee too. Why would that be? A block that had too many tx, the value coming from multiple small value purses (but the client should see one purse that satisfies the whole transaction, right?) or what else?
You received a fee of 0.01. You didn't pay one.
The fix is in SVN rev 151.
You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.
",
"nested_level": 0
},
{
"id": 2736,
"thread_id": 217,
"source_id": "1",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Memory leak",
"url": "https://bitcointalk.org/index.php?topic=1023.msg12522#msg12522",
"date": "2010-09-13T05:51:44Z",
"text": "I have an unusual configuration: on my headless gateway there is bitcoind running and on my desktop standart bitcoin is running (both Linux OpenSuSE, gateway 11.1, desktop 11.3, bitcoin 0.3.12 both). TCP port 8333 forwarded on gateway to the desktop (so gateway client can't has incoming connections). I don't know why but when I start desktop client after gateway's one the desktop client can't connect and flickers between 0 and 2 connections for a long time. Eventually it may connect but while it can't the memory leaks badly. About 200Kb/sec (each 0-2 change). It may not be noticed if the client connects instantly but in my case it doesn't. If I start first the desktop and then the headless client (after the desktop one has connected) everything is fine and no leaks (or they are little enough). I guess there is unfreed memory in bootstrap function or somewhere in the bootstrap process.
",
"nested_level": 0
},
{
"id": 2737,
"satoshi_id": 452,
"thread_id": 217,
"source_id": "2",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Memory leak",
"url": "https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201",
"date": "2010-09-19T17:22:03Z",
"text": "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 half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?
The wait function on linux is:
inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}
If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.
",
"nested_level": 0
},
{
"id": 2738,
"thread_id": 217,
"source_id": "3",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Memory leak",
"url": "https://bitcointalk.org/index.php?topic=1023.msg13434#msg13434",
"date": "2010-09-20T08:38:40Z",
"text": "Hmm, now the bug is gone though I remember how it was. That's the compiled release binary, 0.3.12 as I already mentioned. I didn't use -connect. Flickering was fast from 0 to 2 (less than half second) and then there was a pause in about a second with 0 connections. So the flicker itself was almost every second (not faster). Looks like it got connrefused instantly or such. I watched logs, sorry didn't saved them but there was nothing interesting just connect and disconnect without a reason.
I measured the RES memory with htop. It updates once per second that's why I can't see the real leak speed. Now the client tries to connect after startup and flickers 0-2, too, but just 5-10 times and then establishes one connection. Then it flickers between 1 and 3 and no leaks happen. Then connection number grows up to 40 or even more, everything is stable. To reproduce this try to switch off the network connection right after the client gets IPs from IRC so it will try to connect and fail.
",
"nested_level": 0
},
{
"id": 2739,
"thread_id": 217,
"source_id": "4",
"poster_name": "eurekafag",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=473",
"subject": "Re: Memory leak",
"url": "https://bitcointalk.org/index.php?topic=1023.msg15075#msg15075",
"date": "2010-10-03T07:07:42Z",
"text": "Got that leak again with 0.3.13. Here is the log:
http://pastebin.com/g0gqi7kx I cut it because the connecting-disconnecting repeats again and again without any change and censored the external static IP (it's detected correctly). The port 8333 is forwarded and is seen from the outside. The RES size of bitcoin grew up to 150 Mb when I shut it down.
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 sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
",
"nested_level": 0
},
{
"id": 2741,
"thread_id": 218,
"source_id": "1",
"poster_name": "BrightAnarchist",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=694",
"subject": "Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12686#msg12686",
"date": "2010-09-14T05:44:11Z",
"text": "Bitcoin clients should have a built in simple message encryption/decryption system, perhaps based off of your actual Bitcoin addresses themselves.
This would make doing trades on sites like biddingpond much easier, since you don't need to both agree on a separate app like PGP before communicating over email.
Most of the time I bet people don't even bother to use encryption, but I think it's a good idea to use it when doing trades in Bitcoins.
Thoughts?
",
"nested_level": 0
},
{
"id": 2742,
"thread_id": 218,
"source_id": "2",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12689#msg12689",
"date": "2010-09-14T05:56:05Z",
"text": "I like that idea! Simply integrate an opensource library library like pgp into bitcoin.
BTW, are the messages attached when sending bitcoins to ip addresses currently clear text or encrypted?
",
"nested_level": 0
},
{
"id": 2743,
"thread_id": 218,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12750#msg12750",
"date": "2010-09-14T12:42:04Z",
"text": "BTW, are the messages attached when sending bitcoins to ip addresses currently clear text or encrypted?
They're not encrypted, and there's no authentication, so you shouldn't send to an IP over the Internet.
You could attach an already encrypted text to it, right?
",
"nested_level": 0
},
{
"id": 2745,
"thread_id": 218,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12782#msg12782",
"date": "2010-09-14T17:56:43Z",
"text": "You could attach an already encrypted text to it, right?
You could, but any MITM could modify it / steal your coins...
There should be a UTF8 text field \"memo\" attached to each transaction.
- encrypt by default, with payee's public key
- limit to 256 chars or so
- optionally disable encryption (similar to Pecunix feature which makes a single transaction publicly visible)
You could use your Bitcoin keys for authentication, but ECDSA doesn't support encryption.
",
"nested_level": 0
},
{
"id": 2748,
"thread_id": 218,
"source_id": "8",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12792#msg12792",
"date": "2010-09-14T19:35:34Z",
"text": "encrypt by default, with payee's public key
... but a payer typically has only the bitcoin address, and not the payee's full public key. There'd have to be some way to get the full public key for a bitcoin address.
I like the idea of being able to send encrypted messages to \"whoever has bitcoin address BLAH\", but I'm not sure that functionality should be piggybacked on the \"send BLAH X.YZ bitcoins\".
If they were implemented under the covers as separate functions, then a \"Send a message along with payment\" could easily be implemented as:
1. Send BLAH X.YZ bitcoins, and note the transaction ID.
2. Send BLAH an encrypted message: \"txid:{transaction_id}:Please send the sixteen My Little Pony DVDs to...\"
I've been wanting something like this since day 1.
A Tale in the Desert V accepts Bitcoins now. Each month, the procedure is:
1. Player clicks an in-game menu item \"Pay for my subscription using Bitcoins.\" A unique address is created.
2. The game says \"Send 150BTC to this address: xxxxxxx\" (There's a \"Copy to Clipboard\" button on the dialog.)
3. The player sends the BTC
4. The player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)
The procedure only takes 15-30 seconds total - probably quicker than typing in a credit card number. However, with the ability to attach a message, the procedure becomes:
1. Player sends 150BTC to the standard ATITD Bitcoin address with his character name in the message field.
2. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)
We already have a couple players using Bitcoins to pay for subscriptions. One has generated his BTC, and the other has purchased some on one of the markets.
",
"nested_level": 0
},
{
"id": 2750,
"thread_id": 218,
"source_id": "10",
"poster_name": "Insti",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=336",
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12883#msg12883",
"date": "2010-09-15T15:55:42Z",
"text": "However, with the ability to attach a message, the procedure becomes:
1. Player sends 150BTC to the standard ATITD Bitcoin address with his character name in the message field.
2. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)
We already have a couple players using Bitcoins to pay for subscriptions. One has generated his BTC, and the other has purchased some on one of the markets.
If you don't cheat and leave out steps the procedure is:
1. Player finds the standard ATITD Bitcoin address somehow. (and still needs to copy/paste it.)
2. The player enters his username.
3. The player sends the BTC
4. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)
I don't see how this is an improvement.
(Step 4 in both cases would seem to be redundant if your system is watching bitcoin transactions.)
Edit:
I'm not sure what is so great about having a single Bitcoin address to receive payments from everybody, since you still need a reference ID of some kind. When individual Bitcoin addresses are trivial to generate. (But you are actually running a service that accepts Bitcoins, so you probably know more than I do.)
It's an improvement because payments can be made without running the game software, or made on behalf of other players (which is common in our game at least), or made for several secondary accounts quickly (also which is common in our game.)
Though it doesn't apply to ATITD, it would also strengthen anonymity for those who need it: A website could be set up on a static datastore like Freenet, rather than requiring a live network like Tor.
",
"nested_level": 0
},
{
"id": 2752,
"thread_id": 218,
"source_id": "12",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Message Encryption as a built-in feature?",
"url": "https://bitcointalk.org/index.php?topic=1032.msg12935#msg12935",
"date": "2010-09-16T01:26:38Z",
"text": " A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.
A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.
Great point...I've heard something called hashcash does this for email. But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached.
Hey, I just thought about it yesterday!
A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.
Great point...I've heard something called hashcash does this for email. But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached.
People think nothing of sending text messages or mms that costs .50c each.
Hey, I just thought about it yesterday!
pwned!
Something like this combined with the pay it forward project
http://bitcointalk.org/index.php?topic=922.msg12917#msg12917 would really increase the hardness of the network to attacks? Half your fee would go to the person you sent the message to and the other half would go to 3 randomn people -or split equally to increase anonymity
As an extra security measure you could also send 3 dummy messages or however many you decided so the real message was hidden.The fee you sent would then be divided by however many security splits you decided on. This could mean you might get randomn bitcoin payments all day just for having a bitcoin message address. Think of twitter crossed with hashcash and email. To the outside world there would be no difference from a message to a payment you made.
19tq9NYFsSCMRUkc12v363tHgAeUokoVam just made a peanut butter sandwich!
Something like this combined with the pay it forward project
http://bitcointalk.org/index.php?topic=922.msg12917#msg12917 would really increase the hardness of the network to attacks? Half your fee would go to the person you sent the message to and the other half would go to 3 randomn people -or split equally to increase anonymity
As an extra security measure you could also send 3 dummy messages or however many you decided so the real message was hidden.The fee you sent would then be divided by however many security splits you decided on. This could mean you might get randomn bitcoin payments all day just for having a bitcoin message address. Think of twitter crossed with hashcash and email. To the outside world there would be no difference from a message to a payment you made.
Very clever!!! I like that idea... Plus, with bitcoin, you can customize your level of security: pay more bitcoins and you can send more false messages and have more security splits...
A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.
Great point...I've heard something called hashcash does this for email. But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached.
People think nothing of sending text messages or mms that costs .50c each.
Haha! Well, that's partially true. Ususally they have a fixed amount of pre-paid text messages that they can send each month which if the don't use are simply wasted. But they tend to forget that I still have to pay 25 cents whenever
they send
me a lousy spam text message!!!
![\"Angry\"](\"/static/img/emoticons/angry.gif\"/)
A smartphone bitcoin client with options for encrypted messaging would make for a great alternative text/sms system compared to the high fees charged by most wireless carriers for text messaging. Now, of course, I know of free text messaging apps, but they tend to contain ads. But with bitcoin, the small transaction fees for passing the message along would work as a great incentive instead...
Theymos already said this... ECDSA does not support encrypting messages. Only digital signatures.
",
"nested_level": 0
},
{
"id": 2760,
"thread_id": 219,
"source_id": "1",
"poster_name": "LobsterMan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1378",
"subject": "Issues building bitcoin on Windows 7",
"url": "https://bitcointalk.org/index.php?topic=1034.msg12743#msg12743",
"date": "2010-09-14T12:14:25Z",
"text": "I've been playing around with visual studio (2010) trying to build bitcoin from the source that is included in the win32 zip archive. I created a new makefile project and imported the makefile, acquired the boost, wxwidgets, and the openssl sources, and a few other files which were reported missing when I would try to build. I got as far as the build log reporting that it needed iostream.h, so I went and found a copy of that from libstdc++. Now, after trying to build with iostream.h located in my includes directory, I am getting loads of errors that look like this:
1>------ Build started: Project: bitcoin_test, Configuration: Debug Win32 ------
1>Build started 9/14/2010 08:07:14.
1>InitializeBuildStatus:
1> Touching \"Debug\\bitcoin_test.unsuccessfulbuild\".
1>ClCompile:
1> util.cpp
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15): error C2143: syntax error : missing ';' before '<'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C2146: syntax error : missing ';' before identifier 'cs_mapAddressBook'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17): error C2143: syntax error : missing ';' before '<'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C2146: syntax error : missing ';' before identifier 'dbenv'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C2143: syntax error : missing ';' before '*'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C2146: syntax error : missing ';' before identifier 'strFile'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C2143: syntax error : missing ';' before '<'
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C2238: unexpected token(s) preceding ';'
This has happened with 2 different versions of iostream.h (tried changing <iostream.h> to <iostream> in db.h also), and if I remove iostream.h from my includes directory it simply reports that file is missing and doesn't give hundreds of lines of errors like the above. I haven't modified any files at all, I am just trying to get the project to build in a windows environment right now...
I am sort of stuck here and haven't been able to figure out what the problem is. Admittedly I don't entirely know what I'm doing (I don't have a whole lot of experience with C++ in windows), but I was wondering if anyone has any ideas what my problem might be.
You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source.
",
"nested_level": 0
},
{
"id": 2762,
"thread_id": 219,
"source_id": "3",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Issues building bitcoin on Windows 7",
"url": "https://bitcointalk.org/index.php?topic=1034.msg12791#msg12791",
"date": "2010-09-14T19:28:48Z",
"text": "You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source.
There's a makefile.mingw, and although I haven't tried yet, I'll probably take a stab at windows building for my cuda miner. Can I not use this?
Ok...so trying to build from the commandline with nmake is still giving me the same problems:
c:\\Users\\[myusername]\\Desktop\\bitcoin-0.3.12\\src>nmake /f makefile.vc
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /nologo /MDd /EHsc /GR /Zm300 /Zi /D__WXDEBUG__ /DWIN32 /D__WXMSW__ /D_WINDOWS /DNOPCH /I\"/boost\" /I\"/db/build_windows\"
/I\"/openssl/include\" /I\"/wxwidgets/lib/vc_lib/mswud\" /I\"/wxwidgets/include\" /DGUI /Foobj\\util.obj util.cpp
util.cpp
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15) : error C2143: syntax error : missing ';' before '<'
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau
lt-int
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16) : error C2146: syntax error : missing ';' before identifier 'cs_mapAddressBook'
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau
lt-int
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau
lt-int
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17) : error C2143: syntax error : missing ';' before '<'
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau
lt-int
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23) : error C2146: syntax error : missing ';' before identifier 'dbenv'
c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau
lt-int
Any additional advice would be appreciated...
I think that the C4430 error can be ignored by adding a #pragma warning(disable:4430) to headers.h, but the other ones appear to be more serious
It looks like the C2143 is sometimes caused by problems with #includes, but since I am just using the files that were distributed with the source...I would assume all are functional? Maybe it is something about using vs2010 that is causing the problems?
The lines it's tripping on:
ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;
OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;
So it's acting like nothing is defined, not even map and vector.
Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.
Is VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?
There's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe.
http://tdm-gcc.tdragon.net/Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.
Sending transactions to IP addresses should be removed or at least disabled by default.
As has been stated by many members of the community, it is in no way secure. I also believe that it may actually allow an attacker to determine the identify of an operator of a bitcoin node. Example, I send 0.01 BTC to various IPs on the network and record the IP and bitcoin address (a bitcoin address is autogenerated). If I run or have access to the information at one of the Bitcoin exchanges (or run a store/service that accepts bitcoins) I can then tie that IP address to the user of that site/service. In the case of an exchange I could tie that IP to a person's PayPal or bank account!
Another possible attack is to connect to a target node and initiate an IP transaction. The target will generate a new address, at which point you disconnect and start again. This might be useful as a denial of service attack.
",
"nested_level": 0
},
{
"id": 2766,
"thread_id": 220,
"source_id": "2",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: The case for removing IP transactions",
"url": "https://bitcointalk.org/index.php?topic=1048.msg12951#msg12951",
"date": "2010-09-16T03:31:50Z",
"text": "So may be IP transactions should be enabled only for IP addresses ranges reserved for private networks?
What about forced transaction fees for other IP ranges? (Payee will accept only transactions with fees.)
",
"nested_level": 0
},
{
"id": 2767,
"thread_id": 220,
"source_id": "3",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: The case for removing IP transactions",
"url": "https://bitcointalk.org/index.php?topic=1048.msg12954#msg12954",
"date": "2010-09-16T03:40:22Z",
"text": "It's not the sending that should be disabled by default, but the receiving, I think.
If the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.
Right?
",
"nested_level": 0
},
{
"id": 2768,
"thread_id": 220,
"source_id": "4",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: The case for removing IP transactions",
"url": "https://bitcointalk.org/index.php?topic=1048.msg12957#msg12957",
"date": "2010-09-16T03:43:39Z",
"text": "It's not the sending that should be disabled by default, but the receiving, I think.
If the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.
Right?
Right. Good point! Don't throw the baby out with the bathwater!
Sorry, I guess I wasn't very clear in the original post. I would like for receiving of transactions by IP to be disabled by default.
",
"nested_level": 0
},
{
"id": 2770,
"thread_id": 220,
"source_id": "6",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: The case for removing IP transactions",
"url": "https://bitcointalk.org/index.php?topic=1048.msg13016#msg13016",
"date": "2010-09-16T20:43:59Z",
"text": "Seems that it would increase the security without decreasing the ease of use. So I like it.
I've created a patch that disables receiving of IP transactions by default. They can be enabled with the \"-allowiptransactions\" option or \"allowiptransactions=true\" in the bitcoin.conf file.
Here's the patch:
http://github.com/aceat64/bitcoin-patchwork/blob/svn/patches/disable_ip_transactions.patchI've already incorporated the patch into my custom client:
http://github.com/aceat64/bitcoin-patchworkBut do not remove the IP-transactions at all, please!
http://bitcointalk.org/index.php?topic=1042.msg13160Probably 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 send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful.
In general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.
I uploaded this change to SVN rev 156. The switch to enable is \"-allowreceivebyip\".
Senders with this version will get the error \"Recipient is not accepting transactions sent by IP address\". Older version senders will get \"Transfer was not accepted\".
I used a different name for the switch because \"-allowiptransactions\" sounds like it includes sending. If there's a better name for the switch, we can change it again.
",
"nested_level": 0
},
{
"id": 2774,
"thread_id": 221,
"source_id": "1",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Bug? /usr/bin/bitcoind \"\"",
"url": "https://bitcointalk.org/index.php?topic=1063.msg13140#msg13140",
"date": "2010-09-18T22:19:22Z",
"text": "When I execute
/usr/bin/bitcoind
bitcoin daemon starts as expected.
When I execute
/usr/bin/bitcoind \"\"
error: couldn't connect to server
How come? Is this a bug?
Satoshi:
May we have a bug tracking system please? (size reduced since it was noticed by satoshi and is no longer necessary to stand out, which was meant as a bit humorous anyhow.)
Workaround for my
gentoo linux init script:
BITCOIN_OPTS=\"-min\"
which will then execute as `bitcoind \"-min\"`
So we have to
choose something. May be
Mantis?
I sent sourceforge-based message to Satoshi suggesting enabling MantisBT or Trac. Perhaps he will notice it.
",
"nested_level": 0
},
{
"id": 2777,
"thread_id": 221,
"source_id": "4",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Bug? /usr/bin/bitcoind \"\"",
"url": "https://bitcointalk.org/index.php?topic=1063.msg13197#msg13197",
"date": "2010-09-19T15:16:54Z",
"text": "When I execute
/usr/bin/bitcoind
bitcoin daemon starts as expected.
When I execute
/usr/bin/bitcoind \"\"
error: couldn't connect to server
How come? Is this a bug?
Satoshi:
May we have a bug tracking system please?Workaround for my
gentoo linux init script:
BITCOIN_OPTS=\"-min\"
which will then execute as `bitcoind \"-min\"`
How is this a bug? I may be reading it completely wrong but:
/usr/bin/bitcoind
starts the daemon whereas
/usr/bin/bitcoind \"\"
calls the rpc method \"\" in the running daemon which is not there, so you get the can't connect. If it were there you'd get:
error: {\"code\":-32601,\"message\":\"Method not found\"}
I agree with nelisky-- not a bug. Here's what the unix cat command has to say about \"\":
> cat \"\"
cat: : No such file or directory
I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.
We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.
I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.
",
"nested_level": 0
},
{
"id": 2780,
"thread_id": 222,
"source_id": "1",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "The Niche List",
"url": "https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828",
"date": "2010-09-23T16:00:16Z",
"text": "This is Operation Economic Growth. Our mission is to grow the bitcoin economy by making everyone specialize in a narrow range of good and services.
Simply put, announce what you want to consume and I'll add it to the list. Somebody then will announce that he will try to enter that niche. There can be competition within niches too, but there are other niches to fill.
We'll hold those people \"accountable\" for their niches by plodding, encouraging, starting a thread and then getting disappointed when the service didn't come online etc.
Wanted Niches:
1. craigslist like classified ads for locale.
2. \"Mechanical Turk\"-like site that list simple jobs for people to do. Suggested by noagendamarket in the Stable Exchange Rate? topic of the Economic forum.
3. Beer supply store. Malt, yeasts, hops, etc.
4. Plant store for selling various herbs and stuff.
6. Hacker Academy. Free educational video. Flat tutiion fee classes. Pay as you go for personal tutors.
7. Dating site that accept bitcoins.
8. Easy encryption and backup service.
Niche filled or being worked on:
1. Advertising clearing house like
http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house) noagenda offered a large bounty on it and being worked on Biomike.
2. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process. Suggested by Kiba. Taken by Hippich. Eventually sprawned 3 competitors.
3. Freelancer site. Taken by whichspace.
4. Pizza order system. You can order on the web, from the commandline, from your smartphone, sms, etc. Taken by mizerydearia.
1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process. Suggested by Kiba.
That could be an interesting project. I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing. Anyone interested in partnering up?
1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process. Suggested by Kiba.
That could be an interesting project. I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing. Anyone interested in partnering up?
There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.
Actually, I didn't suggested it originally, but somebody else did in the thread about p0rn.
There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.
That is very true, it is something that I could start development on by myself but the actual development won't really take all that long even just working on it in spare time. The longer term job on the technical side will be keeping the central server running well and scaling up as needed. On the other side in the beginning the marketing would be getting stuff to download (as you said) and yes an affiliate program of some sort could help there. In the longer term there the issue is going to be providing help/support which is the big part I'm not really ready to take on. I'm already on-call basically 24/7 for my main site, doing sysadmin stuff for another project (that would likely share the same infrastructure at least to start with) won't be a big deal but I'm well aware of how important good customer service is and don't want to jump into something that I'm not prepared to do a good job at.
Main reasons for finding a partner upfront would be 1) that they have some input in the design process (if you want to market to a content distributor that they can theme this download page to match their site then I want to know about that as soon as possible) and 2) so that they are familiar with how it is supposed to work from the beginning and can give feedback if it's not as userfriendly as they want or such. Neither of these is a necessity, I can code it and get a small site going regardless but I am a programmer by trade and know my limitations and something like this will need more than some fancy code to be more than just a small site.
I've been considering some ideas already and am thinking I will put something together regardless, I guess this is more of an invitation for someone else who would be interested in running this sort of thing but may not have the technical skills to do it themselves to join me.
And on a separate note I think another niche that could use filling would be an advertising clearinghouse. I've seen a couple sites that say they will accept BTC payments for ad space but a central place to do it would be nice to have. I've been using
http://www.projectwonderful.com/ on other sites and like the way they work, something like that would seem that it could work well with bitcoins.
There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.
That is very true, it is something that I could start development on by myself but the actual development won't really take all that long even just working on it in spare time. The longer term job on the technical side will be keeping the central server running well and scaling up as needed. On the other side in the beginning the marketing would be getting stuff to download (as you said) and yes an affiliate program of some sort could help there. In the longer term there the issue is going to be providing help/support which is the big part I'm not really ready to take on. I'm already on-call basically 24/7 for my main site, doing sysadmin stuff for another project (that would likely share the same infrastructure at least to start with) won't be a big deal but I'm well aware of how important good customer service is and don't want to jump into something that I'm not prepared to do a good job at.
Main reasons for finding a partner upfront would be 1) that they have some input in the design process (if you want to market to a content distributor that they can theme this download page to match their site then I want to know about that as soon as possible) and 2) so that they are familiar with how it is supposed to work from the beginning and can give feedback if it's not as userfriendly as they want or such. Neither of these is a necessity, I can code it and get a small site going regardless but I am a programmer by trade and know my limitations and something like this will need more than some fancy code to be more than just a small site.
I've been considering some ideas already and am thinking I will put something together regardless, I guess this is more of an invitation for someone else who would be interested in running this sort of thing but may not have the technical skills to do it themselves to join me.
I would think a markeeter these days need programming skills and statistics to analyze mass amount of data, doing A/B testing, etc. Although most of the work will be done within a week, I think you'll find that streamlining the download process, doing testing of different version of the site, will be a big part of your job. Let face it, there are many frustration in finding and downloading contents.
Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.
I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?
",
"nested_level": 0
},
{
"id": 2787,
"thread_id": 222,
"source_id": "8",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: The Niche List",
"url": "https://bitcointalk.org/index.php?topic=1268.msg13911#msg13911",
"date": "2010-09-24T04:44:51Z",
"text": "Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.
I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?
Not sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend.
Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.
I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?
Not sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend.
There are 'sweatshops' in India(?), China(?) that have people solving captchas and selling them in bulk to hackers(?). I'm just remembering a bit of an article I read a while back.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
Nobody have volunteer yet for any of those niches, which I think in theory can be done in a few weeks time.(my niche is writing the software for bitpredict)
Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.
I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?
Not sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend.
There are 'sweatshops' in India(?), China(?) that have people solving captchas and selling them in bulk to hackers(?). I'm just remembering a bit of an article I read a while back.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
spammers, not hackers.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.
That works as an e-mail tax. Doesn't work so well in the case of captchas, which are usually for registration on a site. .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.
That works as an e-mail tax. Doesn't work so well in the case of captchas, which are usually for registration on a site. .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.
.5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.
Well, of course, you can adjust the price of posting a little bit.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.
That works as an e-mail tax. Doesn't work so well in the case of captchas, which are usually for registration on a site. .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.
.5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.
Well, of course, you can adjust the price of posting a little bit.
A spammer doesn't need to register millions of times though, just once per site. Then he just sends millions of messages.
I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.
What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?
I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?
I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.
Just a niche I thought of, prolly a bad one.
Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.
That works as an e-mail tax. Doesn't work so well in the case of captchas, which are usually for registration on a site. .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.
.5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.
Well, of course, you can adjust the price of posting a little bit.
A spammer doesn't need to register millions of times though, just once per site. Then he just sends millions of messages.
I think spammers' scale tend to be bigger than that. Anyway, it is distracting from the purpose of the thread, although it is important to discuss the viability unless someone decided to try it anyway.
So nobody is taking up some niches?
So nobody is taking up some niches?
They probably are they just dont want to post about it.
I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting. I would help, but I'm just learning how to program.
",
"nested_level": 0
},
{
"id": 2800,
"thread_id": 222,
"source_id": "21",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: The Niche List",
"url": "https://bitcointalk.org/index.php?topic=1268.msg14004#msg14004",
"date": "2010-09-25T04:56:46Z",
"text": "I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting. I would help, but I'm just learning how to program.
Is this just a payment option added to an existing service or is it actually a new service?
2. Advertising clearing house like
http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)
We are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker.
2. Advertising clearing house like
http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)
We are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker.
Moved #2 to niches being worked upon.
1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process. Suggested by Kiba.
That could be an interesting project. I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing. Anyone interested in partnering up?
There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.
Actually, I didn't suggested it originally, but somebody else did in the thread about p0rn.
( Those who are fans of IP enforcement should just skip this part. Just sayin'. )
That was me, and I was specifically talking about targeting the less than legal area of file sharing.
Put simply, you're just not going to find legal content that will be effective in that market. Anything like OSS is mirrored for free and people aren't going to pay to download. Content owners aren't game - it'd be just another CDN to them, why would they pay in bitcoin, and why would their users pay per download/MB/GB when they're already paying for the content? That niche is solely about pirated content - like it or not.
Marketing would take hardly any effort, as I'm sure (with a good enough user pay flow) we could offer higher conversion rates and payouts for affiliates than the other shady CC required websites. It would take time to work out a business plan, but the actual development would take no time at all. (I could do it in a couple of days with a full-time effort) The files themselves could be shoved onto S3 or something. Just have to have someone handy with numbers to make sure it's profitable - otherwise nobody's going to waste their time.
Something like x amount of BTC per GB or MB (instead of a monthly membership), with an affiliate system would take over that market. Lots of people are willing to pay for better access to niche pirated content, but are reluctant to offer up CC and personal info directly for obvious reasons.
I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.
Agorist developers apply within.
2. Advertising clearing house like
http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)
We are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker.
Moved #2 to niches being worked upon.
Ugh, Drupal. ::wilhelmscream:: I'd be willing to develop an advertising clearance house - I actually have a lot of industry experience there.
I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.
Bitcoin can't prove that someone is human, but requiring a very small payment for each \"dangerous\" action is perfect for preventing abuse.
I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting. I would help, but I'm just learning how to program.
Is this just a payment option added to an existing service or is it actually a new service?
The service exists, although the necessary accounting scheme has not been developed yet.
I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.
Bitcoin can't prove that someone is human, but requiring a very small payment for each \"dangerous\" action is perfect for preventing abuse.
For spammers that make thousands upon thousands of dollars a year? The payments would have to be higher than the potential profits of the spam and it would likely push it out of reach of the average consumer. I'm not going to pay $0.50 to post a blog comment, ever. A big spammer could do that a thousand times and still not cut into their bottom line. I think the fact that spammers use Mechanical Turk to break captchas already is the proof in the pudding.
Any more services and goods you want to see fulfilled? Is anybody working on any of the wanted niches?
",
"nested_level": 0
},
{
"id": 2808,
"satoshi_id": 489,
"thread_id": 222,
"source_id": "29",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: The Niche List",
"url": "https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741",
"date": "2010-10-06T23:10:31Z",
"text": "1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process.
Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.
In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.
",
"nested_level": 0
},
{
"id": 2810,
"thread_id": 223,
"source_id": "2",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Internal version number",
"url": "https://bitcointalk.org/index.php?topic=1269.msg13835#msg13835",
"date": "2010-09-23T16:48:04Z",
"text": "In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.
Thanks for the heads up. I'm actually checking version on my web apps, to assert if backupwallet is available, but as my private version is now widespread, it should be very simple to cope with that change.
I don't think it should cause any problems for version comparisons. 31300 > 312.
",
"nested_level": 0
},
{
"id": 2812,
"thread_id": 224,
"source_id": "1",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "How divisible are bitcoins - the technical side",
"url": "https://bitcointalk.org/index.php?topic=1271.msg13839#msg13839",
"date": "2010-09-23T17:35:35Z",
"text": "Hey,
So there is another thread asking about bc and decimal places. It is stated that the client(s) only show 2 decimal places, but there are 8 in total. Now, working on stuff, I find that it would be nice if I could transfer at least 4 decimals precision, but the full 8 would be great.
Looking at the code it seems simple enough to remove the rounding from bitcoind, but what about the receiving side? If it's a non UI client, then it will show everything, but would I be making things overly confusing for GUI clients?
Is there any shortcoming in me patching my client to handle full precision?
",
"nested_level": 0
},
{
"id": 2813,
"thread_id": 224,
"source_id": "2",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: How divisible are bitcoins - the technical side",
"url": "https://bitcointalk.org/index.php?topic=1271.msg13845#msg13845",
"date": "2010-09-23T18:01:27Z",
"text": "Won't transaction fees make that pointless?
If you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.
",
"nested_level": 0
},
{
"id": 2814,
"thread_id": 224,
"source_id": "3",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: How divisible are bitcoins - the technical side",
"url": "https://bitcointalk.org/index.php?topic=1271.msg13847#msg13847",
"date": "2010-09-23T18:10:35Z",
"text": "Won't transaction fees make that pointless?
If you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.
Will transaction fees be applied to transfers above 0.01, but with more precision? I wasn't aware of it being that way.
And yes, I am rounding for now, but I like things clean, and I can either allow withdrawal of higher precision amounts, or I can round to 2 decimals the prize handout, I just rather do the former, that's all.
And no, it's not *only* for the sportsbook. I have plans...
I would not encourage using the extra decimal places. They're only intended for future use.
You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it. The UI will show it rounded down.
",
"nested_level": 0
},
{
"id": 2816,
"thread_id": 225,
"source_id": "1",
"poster_name": "harding",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1652",
"subject": "How To Make a Distributed BitCoin Escrow Service",
"url": "https://bitcointalk.org/index.php?topic=1283.msg14070#msg14070",
"date": "2010-09-26T01:16:18Z",
"text": "Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate. Details follow.
For a
decentralized currency,
centralized escrows seem to be the norm for BitCoin today. An example:
Alice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them.
No offense to Mt. Gox (a site I like), but can we do without its escrow service?
An almost distributed alternative:
- Charlie, a trusted third-party, generates a BitCoin private key.
- Charlie then uses the Unix command split to split the private key in half--giving one half to Alice and one half to Bob.
- Bob deposits $5 USD worth of BitCoins into the split BitCoin account;
- Alice verifies the transaction using the public block;
- Alice sends $5 USD to Bob by PayPal;
- Bob verifies the PayPal transaction;
- Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.
(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.)
More advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command
split. For example: a Shamir's secret sharing scheme implementation like
ssss[1]. A utility like
ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement.
The problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates.
The ideal solution would be for Alice and Bob to each generate half of the private key on their own. I don't fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm.
Is there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party?
-Dave
[1] See:
http://en.wikipedia.org/wiki/Shamir's_Secret_SharingIt's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:
http://bitcointalk.org/index.php?topic=750.0It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.
In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.
Hello,
I'm have a client that calls getinfo over the rpc interface. Everything works fine when host=localhost.
However, when trying to get bitcoin at another host i cannot.
I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?
If not, i'm probably going to have to write a 'proxy' app that i would deploy to each machine running bitcoin. Would prefer not to do this
Thanks,
Marko
I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?
This is still the case and I don't believe there is a setting to override it. It's hardcoded in the source. Instead of writing a 'proxy' app you can use SSH to tunnel. For example, if your bitcoin instance is running on 'example.com' and that machine is running an ssh server, you can tunnel to it from another machine with:
ssh -N example.com -L 9481:localhost:9481
Now you can use the RPC interface on your local machine to port 9481 and it will be tunnelled over an encrypted SSH session to the machine running the bitcoin RPC server.
You want to encrypt the connection because the JSON-RPC password is sent in clear text (it's actually base 64 encoded but basically it's the equivalent of clear text).
I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?
This is still the case and I don't believe there is a setting to override it. It's hardcoded in the source. Instead of writing a 'proxy' app you can use SSH to tunnel. For example, if your bitcoin instance is running on 'example.com' and that machine is running an ssh server, you can tunnel to it from another machine with:
ssh -N example.com -L 9481:localhost:9481
Now you can use the RPC interface on your local machine to port 9481 and it will be tunnelled over an encrypted SSH session to the machine running the bitcoin RPC server.
You want to encrypt the connection because the JSON-RPC password is sent in clear text (it's actually base 64 encoded but basically it's the equivalent of clear text).
Can you compile your own bitcoin? The latest svn has an option to allow binding to other interfaces, not just localhost. If not the next version (0.3.13) is supposed to have that.
There's an \"-rpcallowip=\" switch in SVN, which allows you to access RPC from the specified IP addresses. This is not safe from MITM attacks, however.
",
"nested_level": 0
},
{
"id": 2822,
"thread_id": 226,
"source_id": "5",
"poster_name": "Marko",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1674",
"subject": "Re: Remote RPC access",
"url": "https://bitcointalk.org/index.php?topic=1291.msg14395#msg14395",
"date": "2010-09-28T13:58:51Z",
"text": "Hey all...Thanks for all the feedback
The ssh method is great. However, all the machines are windows machines so i'd have to do an install on all of them. Better than writing a proxy app for sure though...
I saw the entry from a few weeks ago about the -rpcallowip switch. I'll compile my own version if i have to. That said, i'd prefer to have an official release. Anyone have an idea when the next version would be posted?
As far as the MITM attack possibility, this only presents a problem if the network i'm exposing to is not trusted. Or is there some other effect i'm missing?
",
"nested_level": 0
},
{
"id": 2823,
"satoshi_id": 470,
"thread_id": 226,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Remote RPC access",
"url": "https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736",
"date": "2010-09-30T18:27:41Z",
"text": "It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.
0.3.13 RC1 is available for Windows:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exeNothing I send gets confirmed now.
Here's how I did it:
I was sending out payments under .01 in size and not paying a transaction fee, which of course were never confirmed.
Here's a guess as to why it broke my wallet:
Because the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out.
I've only lost 100btc, so I'm not real worried, but if you know how to fix it without too much trouble, that'd be nice.
",
"nested_level": 0
},
{
"id": 2825,
"thread_id": 227,
"source_id": "2",
"poster_name": "Tritonio",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=779",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14515#msg14515",
"date": "2010-09-29T12:27:57Z",
"text": "You could edit your client to make it include into blocks any transactions without looking at the fee. And then wait a month or so until you make a block which will include your transactions... Or wait until someone else with a custom client includes your transactions in his block.
",
"nested_level": 0
},
{
"id": 2826,
"thread_id": 227,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14517#msg14517",
"date": "2010-09-29T12:38:32Z",
"text": "Because the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out.
This seems likely. Try sending a ton of 0.01 transactions -- most of these transactions will work if this is the case.
Or wait until someone else with a custom client includes your transactions in his block.
For this you'll want to use the
-maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor.
You could also \"double-spend\" your pre-experiment coins by acting as though the unconfirmed transactions never happened. A wallet backup would roll things back, for example.
For this you'll want to use the -maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor.
Huh? Clients don't propagate what they consider invalid? I thought that they just didn't include it in their blocks...
Huh? Clients don't propagate what they consider invalid? I thought that they just didn't include it in their blocks...
Hmm; I'm not sure about this case. They're not working on your new transaction because the previous transaction wasn't in a previous block and isn't in their memory pool. I don't know if they'd relay it.
Hey, so i've been the recipient of a few of these microtransactions
so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state
so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?
note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?
",
"nested_level": 0
},
{
"id": 2830,
"thread_id": 227,
"source_id": "7",
"poster_name": "Tritonio",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=779",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14525#msg14525",
"date": "2010-09-29T13:51:15Z",
"text": "Hey, so i've been the recipient of a few of these microtransactions
so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state
They will get confirmed when someone that doesn't require fees include them in his/her block.
so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?
There is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins.
note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?
You can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions.
it seems this could take down the whole network depending on the logic behind combining lots.. as in if the micropayment without fee is combined with a normal transaction and has change, both the send and the change would never confirm either. so now you have 2 lots that will never confirm. repeat.
and it does seem the client lets you spend unconfirmed coin.
",
"nested_level": 0
},
{
"id": 2832,
"thread_id": 227,
"source_id": "9",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14544#msg14544",
"date": "2010-09-29T15:27:50Z",
"text": "Hey, so i've been the recipient of a few of these microtransactions
so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state
They will get confirmed when someone that doesn't require fees include them in his/her block.
yes and.... at this point /all/ clients require fees for transactions <0.01, do you have any reason to expect that this will change at any point in the future? i don't. so \"never will get confirmed\" seems a reasonable approximation to reality.
so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?
There is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins.
yes but the problem is that the client doesn't let the user choose which coins to spend, it does it all \"automagically\" behind the scenes. so how would a user know if he's sending confirmed coins or unconfirmed coins?
note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?
You can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions.
yes, but that's a separate issue. i'm really trying to figure out what, if anything, to be doing about the handful of never-to-be-confirmed transactions i have in my wallet, whether the client will prioritize sending other coins first or not, and if not... that means it's possible that i'll never be able to make a send transaction that will be confirmed, because the unconfirmed bits of coin will be included. which would in turn mean that my whole wallet is foobar.
I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool.
I don't know if there is any protection in the protocol from this kind of attacks
There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in.
And in the future node could certainly drop connections from nodes that generate bad transactions.
",
"nested_level": 0
},
{
"id": 2835,
"thread_id": 227,
"source_id": "12",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14583#msg14583",
"date": "2010-09-29T17:55:49Z",
"text": "I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool.
I don't know if there is any protection in the protocol from this kind of attacks
There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in.
theymos: well... the problem is that it causes problems for the wallets that happen to have received those transactions. my wallet now includes a bunch of small transactions that will never be confirmed (due to their not having paid the requisite fees).
since the client does not let the user control which coins to send, any transaction i send out in the future is liable to try to include those coins in the outgoing payment, which, in turn, will never get confirmed, thus borking my whole wallet.
so say a 'rogue' client harvests a bunch of addresses of the net (these forums are a good and ripe place), and starts sending out a bunch of .000001 payments with no fee. now these wallets will all be contaminated with these never-to-be-confirmed payments, and since the client doesn't allow one to choose which coins get sent, they may be included in future outgoing payments, which will also never get confirmed.
so what should i do to 'clear' my wallet? i'd need some custom tool to be able to send /specific coins/, so that i can send them all to another wallet and drop the contaminated one.
and more importantly, for the future - how do we address this problem?
At (roughly) line 3191 in main.cpp (SelectCoins), change the
if statement to this:
if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)
Your client will then no longer consider coins with 0 confirmations when choosing coins.
At (roughly) line 3191 in main.cpp (SelectCoins), change the
if statement to this:
if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)
Your client will then no longer consider coins with 0 confirmations when choosing coins.
IMO, this should make it into the upstream bitcoin client, as either
- a command line switch, requiring confirmation for all sent coins
- a two-pass search: search first for confirmed coins. if not enough confirmed coins are available, use unconfirmed coins.
The best option might be four passes at 120, 6, 1, and 0, to somewhat prioritize based on depth.
",
"nested_level": 0
},
{
"id": 2839,
"thread_id": 227,
"source_id": "16",
"poster_name": "Tritonio",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=779",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14598#msg14598",
"date": "2010-09-29T18:50:53Z",
"text": "and more importantly, for the future - how do we address this problem?
I really don't care about extremelly fast transactions. It would be enough for me if Bitcoin didn't even show unconfirmed transactions and didn't even try to spend them before they get confirmed. FFS just wait 10minutes for a block to appear confirming them.
At (roughly) line 3191 in main.cpp (SelectCoins), change the
if statement to this:
if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)
Your client will then no longer consider coins with 0 confirmations when choosing coins.
thanks theymos for the patch!
i guess now i have to figure out how to build bitcoind....
or maybe i'll just wait around for this to make it into the next official release...
if satoshi agrees with jgarzik as far as including those options in mainline, maybe i don't have to wait that long...
Some people might want to add the
pcoin->GetDepthInMainChain() < 1
in GetBalance() too.
",
"nested_level": 0
},
{
"id": 2842,
"thread_id": 227,
"source_id": "19",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14615#msg14615",
"date": "2010-09-29T19:58:47Z",
"text": "Some people might want to add the
pcoin->GetDepthInMainChain() < 1
in GetBalance() too.
Well, I would rather split \"balance\" in two: confirmed and unconfirmed balances.
ok, so i built a modified bitcoind, with the addition of 'pcoin->GetDepthInMainChain() < 1' to both SelectCoins and GetBalance.
My 'stock client' balance shows as 131.00139787, and my modified client balance shows as 130.92112098, so i have about 0.08xx of \"bad\" bitcoins' worth of transactions in my wallet.
So I guess now, all i need to do is create another wallet, and then send all the \"good coins\" from my old wallet to my new one (or, i guess... i could just use the same wallet, since my bitcoind won't try to send the bad coins, i can just ignore them....)
But yes, I hope the modifications as described by jgarzik (being configurable with cli switches/checkboxes) do make it into mainline - because otherwise it's too easy to 'poison' people's wallets with bogus transactions.
",
"nested_level": 0
},
{
"id": 2844,
"satoshi_id": 464,
"thread_id": 227,
"source_id": "21",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714",
"date": "2010-09-30T16:38:53Z",
"text": "As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.
I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.
I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.
The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.
I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.
If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.
If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.
change:
if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
continue;
to:
if (pcoin->GetDepthInMainChain() < 1)
continue;
",
"nested_level": 0
},
{
"id": 2845,
"satoshi_id": 465,
"thread_id": 227,
"source_id": "22",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg14720#msg14720",
"date": "2010-09-30T16:59:00Z",
"text": "",
"nested_level": 0
},
{
"id": 2846,
"thread_id": 227,
"source_id": "23",
"poster_name": "kermit",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1697",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg15001#msg15001",
"date": "2010-10-02T14:17:40Z",
"text": "So in .13 1 confirm is good enough to pay someone with, but it takes 6 to display \"confirmed\" in the GUI. This is inconsistant. This coin is good enough to pay you with but not good enough for me to accept? I don't know the logic behind the 6, but whatever it is, if its only used to decide which word to display, then is it really representing anything at all?
",
"nested_level": 0
},
{
"id": 2847,
"satoshi_id": 487,
"thread_id": 227,
"source_id": "24",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: I broke my wallet, sends never confirm now.",
"url": "https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672",
"date": "2010-10-06T16:54:23Z",
"text": "That's going to be more of a SelectCoins thing.
SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away.
The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.
Here's a Windows build:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exeThis version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.
As noted in
this wiki page and in
this satoshi post, the -paytxfee switch may be employed give your sent transactions \"priority.\"
Prioritized transactions appear to be defined as increasing the likelihood that a transaction will be included in a block, even if that block is very large (byte-wise or tx-wise).
Considering that 99.9% of blocks are outside the range that will incur tx fees, it can be said that tx fees are largely useless today. But it makes me curious...
Are there any other areas of the bitcoin client or network that could somehow prioritize transactions based on tx fees? Examples:
- if you have a list of transactions to send out to the network, send prioritized ones to more connected nodes
- restart mining work immediately if priority tx arrives, but continue working on existing block for a while, if free tx arrives
And with my businessman's cap on, I would think it prudent practice for any bitcoin business to use -paytxfee=0.02 by default, just to be safe, guaranteeing priority on the existing network and existing clients, in cases of extreme network load.
Other comments about how to use tx fees welcome... I strongly believe that a healthy tx fee structure is important to the long term health of the bitcoin P2P network.
As far as I can tell, transactions are not prioritized according to fee size. Paytxfee just ensures that you will meet the fee requirements (and it isn't guaranteed to do that). This does seem to be contrary to what Satoshi and sirius-m have implied, but I can't find any prioritization in the code.
",
"nested_level": 0
},
{
"id": 2850,
"thread_id": 228,
"source_id": "3",
"poster_name": "wscott",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1682",
"subject": "Re: Prioritized transactions, and tx fees",
"url": "https://bitcointalk.org/index.php?topic=1314.msg14683#msg14683",
"date": "2010-09-30T09:40:21Z",
"text": "The fees are a function of total transaction volume.
Right now the volume is pretty tiny so all fees are zero.
Later when the volume is high only some of the current transactions will be included in each
block so you either pay a fee to make sure your transaction is desirable to be in each block
or wait until the trading volume drops.
-Wayne
",
"nested_level": 0
},
{
"id": 2851,
"satoshi_id": 468,
"thread_id": 228,
"source_id": "4",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Prioritized transactions, and tx fees",
"url": "https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732",
"date": "2010-09-30T18:11:56Z",
"text": "It ramps up the fee requirement as the block fills up:
<50KB free
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
etc.
It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.
Just including the minimum 0.01 goes a long way.
",
"nested_level": 0
},
{
"id": 2852,
"thread_id": 228,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Prioritized transactions, and tx fees",
"url": "https://bitcointalk.org/index.php?topic=1314.msg14733#msg14733",
"date": "2010-09-30T18:16:36Z",
"text": "That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement.
",
"nested_level": 0
},
{
"id": 2853,
"satoshi_id": 469,
"thread_id": 228,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Prioritized transactions, and tx fees",
"url": "https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734",
"date": "2010-09-30T18:22:22Z",
"text": "True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it.
",
"nested_level": 0
},
{
"id": 2854,
"satoshi_id": 466,
"thread_id": 229,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "0.3.13 RC1 for Windows, please test",
"url": "https://bitcointalk.org/index.php?topic=1322.msg14722#msg14722",
"date": "2010-09-30T17:04:15Z",
"text": "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- internal version number from 312 to 31300
- only accept transactions sent by IP address if -allowreceivebyip is specified
- dropped DB_PRIVATE Berkeley DB flag
- fix problem sending the last cent with sub-cent fractional change
- auto-detect whether to use 128-bit 4-way SSE2 on Linux
Gavin Andresen:
- option -rpcallowip= to accept json-rpc connections from another machine
- clean shutdown on SIGTERM on Linux
What about to add
Russian localization to 0.3.13?
Too late for 0.3.13, but I'll try to find time to add it to the next version.
",
"nested_level": 0
},
{
"id": 2857,
"satoshi_id": 472,
"thread_id": 230,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg14788#msg14788",
"date": "2010-10-01T00:34:35Z",
"text": "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 need 0.3.13.2.
Changes:
- Don't count or spend payments until they have 1 confirmation.
- Internal version number from 312 to 31300.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Dropped DB_PRIVATE Berkeley DB flag.
- Fix problem sending the last cent with sub-cent fractional change.
- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
- Option -rpcallowip= to accept json-rpc connections from another machine.
- Clean shutdown on SIGTERM on Linux.
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/(Thanks Laszlo for the Mac OSX build!)
Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gzYou can still control the SSE2 use manually with -4way and -4way=0.
Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exeIf I create a wallet and then send some bitcoin to it,
then wait for confirmations, then remove that wallet
and restore it's previous copy - so the client will not
see that transaction. However, if I remove all blocks
and download all blocks again - then the amount will
appear. It would nice to make a re-count function...
",
"nested_level": 0
},
{
"id": 2859,
"thread_id": 230,
"source_id": "3",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: Version 0.3.13",
"url": "https://bitcointalk.org/index.php?topic=1327.msg14988#msg14988",
"date": "2010-10-02T09:28:46Z",
"text": "Oh! My wallet corrupted.
Dropbox saved only too
old copies, because Bitcoin did not close the file.
I think client must close the wallet when it is not
needed for any operations on it. What you think?
That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.
I still have to add the \"-4way\" switch.
",
"nested_level": 0
},
{
"id": 2861,
"thread_id": 230,
"source_id": "5",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Version 0.3.13",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15047#msg15047",
"date": "2010-10-02T22:43:29Z",
"text": "Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.
",
"nested_level": 0
},
{
"id": 2862,
"thread_id": 230,
"source_id": "6",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: Version 0.3.13",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15055#msg15055",
"date": "2010-10-03T01:24:27Z",
"text": "Version 0.3.13 is now available.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Option -rpcallowip= to accept json-rpc connections from another machine.
I notice that these options are not showing up in --help output... Shouldn't --help have a comprehensive listing of these options in it? (Especially given that there's no manpage or other help docs distributed in the official-release tarball?)
Just an idle question, whose result I hope makes its way into the next release.
Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.
If they didn't confirm why would he clear them to go into the account? Is he counting blocks instead of confirmations? That seems odd.
If they didn't confirm why would he clear them to go into the account? Is he counting blocks instead of confirmations? That seems odd.
He sent a transaction that took coins from a transaction that will never confirm, so this transaction will also never confirm and is therefore lost (along with any change). If the person he sent it to isn't using 0.3.13, they'll also send unconfirmable transactions. It's like a virus. People need to move to 0.3.13 ASAP.
It has nothing to do with confirmations.
I suggest a manpage should be included in the tarball.
",
"nested_level": 0
},
{
"id": 2866,
"thread_id": 230,
"source_id": "10",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: Version 0.3.13",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15072#msg15072",
"date": "2010-10-03T05:59:06Z",
"text": "Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.
I can agree with that. otherwise the 0/unconf txns can propagate through the network and mess up a lot of people's wallets.
That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.
I still have to add the \"-4way\" switch.
Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.
Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware also?
Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this.
These are binaries only. The linux version is 64-bit only.
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gzSHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip
SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better.
Can you include the source? Or better the diff for those transactions? I could run it on my 983 Mhash/s box.
",
"nested_level": 0
},
{
"id": 2870,
"satoshi_id": 475,
"thread_id": 230,
"source_id": "14",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112",
"date": "2010-10-03T19:49:32Z",
"text": "983 Mhash/s box.
Seriously? What hardware is that?
Three GPUs (ATI HD 5870).
",
"nested_level": 0
},
{
"id": 2872,
"satoshi_id": 476,
"thread_id": 230,
"source_id": "16",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116",
"date": "2010-10-03T20:02:24Z",
"text": "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 + nModel >= 160010));
+ // AMD reports a lower model number in 64-bit mode
+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+ fUseSSE2 = true;
+
static bool fPrinted;
if (!fPrinted)
{
@@ -2989,6 +2993,17 @@
// Transaction fee based on block size
int64 nMinFee = tx.GetMinFee(nBlockSize);
+ //////// temporary code
+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings(\"statusbar\") == \"\")
+ {
+ if (nBestHeight < 91000)
+ nMinFee = 0;
+ if (nBestHeight < 100000 && nTxSize < 2000)
+ nMinFee = 0;
+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+ nMinFee = 0;
+ }
+ //////// temporary code
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\\serialize.h new\\serialize.h
--- old\\serialize.h Sun Oct 03 20:57:45 2010
+++ new\\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
class CAutoFile;
static const unsigned int MAX_SIZE = 0x02000000;
-static const int VERSION = 31300;
-static const char* pszSubVer = \"\";
+static const int VERSION = 31301;
+static const char* pszSubVer = \" test1\";
ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.
",
"nested_level": 0
},
{
"id": 2874,
"thread_id": 230,
"source_id": "18",
"poster_name": "tcatm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=592",
"subject": "Re: Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119",
"date": "2010-10-03T20:10:47Z",
"text": "It's running. Should find a block within 3 hours.
",
"nested_level": 0
},
{
"id": 2875,
"satoshi_id": 477,
"thread_id": 230,
"source_id": "19",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136",
"date": "2010-10-03T20:54:07Z",
"text": "ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.
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 block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.
The person who originally sent the broken transactions deleted his wallet
Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet.
It's running. Should find a block within 3 hours.
It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least.
Block 83018 (00000000002bba570c3) cleared out a bunch of them. Last I heard nanotube still had one that's unconfirmed, though.
Edit: Nanotube's transaction cleared recently. I don't know why it was delayed, since it wasn't relying on a sub-0.01 transaction.
",
"nested_level": 0
},
{
"id": 2877,
"thread_id": 230,
"source_id": "21",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: Version 0.3.13",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15141#msg15141",
"date": "2010-10-03T21:24:48Z",
"text": "That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.
I still have to add the \"-4way\" switch.
Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.
Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware also?
$ grep -i cpuid debug.log
CPUID 444d4163 family 16, model 5, stepping 2, fUseSSE2=0
/proc/cpuinfoForgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.
Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware also?
Will that be enough ?:
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : AMD Phenom(tm) 9850 Quad-Core Processor
stepping : 3
cpu MHz : 2508.353
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock
bogomips : 5018.72
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
EDIT:
Also, i have just found out how to do the cpuid thingy:
CPUID 444d4163 family 16, model 2, stepping 3, fUseSSE2=0
ShadowOfHarbringer, is yours faster with -4way?
If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.
The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.
",
"nested_level": 0
},
{
"id": 2880,
"thread_id": 230,
"source_id": "24",
"poster_name": "ShadowOfHarbringer",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1775",
"subject": "Re: Version 0.3.13, please upgrade",
"url": "https://bitcointalk.org/index.php?topic=1327.msg15155#msg15155",
"date": "2010-10-03T22:32:16Z",
"text": "ShadowOfHarbringer, is yours faster with -4way?
Indeed, it is almost 2 x as fast with -4way as it is without.
I get about 8500 khash/sec with -4way, and 4500 khash/sec without.
Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.
I have one transaction that remains perpetually in 0/unconfirmed status in my wallet. Here are the details, as shown in debug mode:
Status: 0/unconfirmed
Date: 09/29/2010 12:46
From: unknown
To: 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU (yours, label: gribble stored address)
Credit: 0.03
Net amount: +0.03
debug print
Credit: 0.03
Inputs:
Transaction:
CTransaction(hash=5c05d9, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(b412a0, 0), scriptSig=3045022049753afb02f58a7b)
CTxOut(nValue=0.03000000, scriptPubKey=OP_DUP OP_HASH160 e2ccd6)
Would appreciate it if you take a look and see what's wrong with it and why it remains unconfirmed....
Block 83018 (00000000002bba570c3) cleared out a bunch of them. Last I heard nanotube still had one that's unconfirmed, though.
Edit: Nanotube's transaction cleared recently. I don't know why it was delayed, since it wasn't relying on a sub-0.01 transaction.
just a clarification, the one that \"cleared recently\" didn't have anything to do with the problem microtransactions. the problem one, that was unconfirmed, is still unconfirmed, see info in my post above.
Do all AMDs that support 64-bit have the better SSE2 hardware also?
Old AMD Sempron 64 does not have the good sse2 speed. This one should stay with -4way=0
CPUID 444d4163 family 15, model 44, stepping 2, fUseSSE2=0
Version 0.3.13 is now available.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Option -rpcallowip= to accept json-rpc connections from another machine.
I notice that these options are not showing up in --help output... Shouldn't --help have a comprehensive listing of these options in it? (Especially given that there's no manpage or other help docs distributed in the official-release tarball?)
Just an idle question, whose result I hope makes its way into the next release.
The command line switches are listed in \"bitcoind -?\" instead of \"bitcoind help\". You are still right tho, those options are missing from \"-?\" too.
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.
",
"nested_level": 0
},
{
"id": 2886,
"thread_id": 231,
"source_id": "1",
"poster_name": "chickenado",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1779",
"subject": "How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14838#msg14838",
"date": "2010-10-01T11:31:46Z",
"text": "The strength of this project was meant to be its distributedness.
But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.
The average user no longer has a fighting chance and has given up generating blocks altogether.
What does this remind me of? That's right, bitcoin is becoming like the physical money economy, where a small number of central banks now guarantee the trustworthiness of paper money.
There are two problems: One, the possibility of market manipulation, and more importantly, if only a handful of people do most of the proof of work, what is the point of a decentralized currency in the first place? It weakens us, because a powerful attacker would only need to bribe a few people to gain more than 50% of khash/s.
To stop this, I suggest the following:
1) Add more hash functions that must be solved in addition to SHA-2. The more, the better. The function ecosystem should include functions with very different requirements, eg. some that require lots of memory, some that can't be paralellized, some that require lots of disk space,...
Also, function parameters that change randomly every time difficulty changes. This would take away some advantage from people who are highly specialized at solving just one hash function.
2) Pooled block generation. For instance, if 100 users join a pool and one block is solved, the 50 coins are distributed among those users. This would encourage amateur users to start generating again.
",
"nested_level": 0
},
{
"id": 2887,
"thread_id": 231,
"source_id": "2",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14841#msg14841",
"date": "2010-10-01T12:05:43Z",
"text": "Pooled generation: +1
Add more hash functions... how would this balance the generation? People with better hw would still generate more, in all hash functions. Maybe not GPU / massive parallel, but any problem more/better hardware can't help resolve is probably out of general user's boundaries.
GPU and unfairness. Realize that the hardware needed to stand a chance of generating isn't all that cutting edge or expensive. Any mid-level gamer machine has the engine to put out 20 or 30 million hashes/sec, at least. The real issue is software, as this gives the owner of such software a huge advantage for a very small price, thus people will obviously take advantage of this as long as possible.
I feel stupid, really. I could put a little more money/effort into this, say nothing about it, and generate away. Instead here I am with my sense of community duty and such... damn, I'll never get rich this way
If you feel strongly as to the need for fairness, why don't you
Help the little ol CUDA developer?
Someone should work on making the GPU code open. That is the best way to stop this.
",
"nested_level": 0
},
{
"id": 2889,
"thread_id": 231,
"source_id": "4",
"poster_name": "chickenado",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1779",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14844#msg14844",
"date": "2010-10-01T12:32:18Z",
"text": "My concern isn't really fairness, it's stability.
I buy about $20 worth of BTC each month, but I spend most of them straight away. What is keeping me from buying $1000 worth of BTC is my concern with the problems I mentioned. As a way of transferring money Bitcoin is great, as a way of saving money it is still too risky for my tastes. To succeed as a currency it must be good at both.
Someone should work on making the GPU code open. That is the best way to stop this.
That's exactly what nelisky is doing. Feel free to follow his link and help him.
Have done, actually. There is working (and generating) code already available
here. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).
The mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.
I'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too
Someone should work on making the GPU code open. That is the best way to stop this.
That's exactly what nelisky is doing. Feel free to follow his link and help him.
Have done, actually. There is working (and generating) code already available
here. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).
The mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.
I'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too
Thanks for the work you are doing.
Someone should work on making the GPU code open. That is the best way to stop this.
That's exactly what nelisky is doing. Feel free to follow his link and help him.
Have done, actually. There is working (and generating) code already available
here. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).
The mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.
I'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too
Thanks for the work you are doing.
My pleasure, really. But in all fairness, it is not true I don't get both appreciation and donations. What happens is the folks that do support me do so in a very altruistic way, as in \"that sounds great for the community, keep it up\" kind of way. These helping members do not have, to the best of my knowledge, any particular interest in the work I do, just think it helps everyone out.
The ones that have the hardware to take advantage of this, if they do exist, keep very, very silent
But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.
The average user no longer has a fighting chance and has given up generating blocks altogether.
It's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated \"backbone\" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that
will fail if they or someone else destabilizes the network?
I'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are \"taking without giving back\". People dedicated to generating deserve a head-start on new technologies.
This is a non-issue. Nothing to see here, keep moving.
",
"nested_level": 0
},
{
"id": 2895,
"thread_id": 231,
"source_id": "10",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14859#msg14859",
"date": "2010-10-01T16:01:25Z",
"text": "But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.
The average user no longer has a fighting chance and has given up generating blocks altogether.
It's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated \"backbone\" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that
will fail if they or someone else destabilizes the network?
I'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are \"taking without giving back\". People dedicated to generating deserve a head-start on new technologies.
I was under the impression that coin generation was a way to make sure everyone had a fair chance of putting effort against coins, thus avoiding any central committee of deciding the future of bitcoins. Decentralized is the word, I believe...
But I get it, if you put the time and money into getting better miners, you should be able to keep it to yourself, so the 4way patch should never had been merged into mainline, as its creator would have 2x+ performance over the same machine running common clients.
I have to disagree here. Yes, competition is good and valuable, and people should not get into bitcoins for the mining alone, but if you let a small subset of people hold most of the future generated coins you are putting the whole project in danger of abuse and destruction... but I may be overreacting.
I'll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting... you say I should, right?
I'll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting... you say I should, right?
The network
will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.
Posting GPU code now will just prolong the period when generation is feasible for normal people. This will attract a few users, and it might increase the network's total power on the short-term, but on the long-term it'll have little value. If I were you, I'd keep the code private. Publishing it wouldn't be
bad for the network, though.
Start a pool yourself. If you are generating 4000k/sec 10 others are generating 20,000k/sec combined, you get 4,000/24,000 of each block generated. Seems this code could be introduced. I don't think the GPU Oligarchs are making a mint, in fact, I bet they are losing money to my benefit.
I bet you could pay nelisky for proprietary code yourself. But, the economics won't work out.
",
"nested_level": 0
},
{
"id": 2898,
"thread_id": 231,
"source_id": "13",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14864#msg14864",
"date": "2010-10-01T16:22:59Z",
"text": "Pools won't eliminate the \"problem\" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit.
",
"nested_level": 0
},
{
"id": 2899,
"thread_id": 231,
"source_id": "14",
"poster_name": "chickenado",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1779",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14869#msg14869",
"date": "2010-10-01T17:03:52Z",
"text": "The network will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.
It will if proof-of-work comes down to something as specialized as solving a single, well-defined, simple, and predictable hash function such as SHA-2.
We need to make proof-of-work more choatic and complex if we want to avoid this.
SHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work.
Otherwise, it will end just like you say.
Think of this vision of the year 2020: 2/3 of the world's Ghash/s is controlled by just three companies. They manufacture their own specialilsed HPUs (hash processing units) and feed them with custom-built power plants. The Chinese goverment then persuades the three companies to double spend 10% of all transactions into the Chinese government's bitcoin address, in return the companies get an exclusive deal on the rare earths they badly need for the HPU manufacture. Some people leave Bitcoin for alternative currencies without the 10% \"tax\", but most tolerate it because by then Bitcoin is accepted almost universally.
The network will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.
It will if proof-of-work comes down to something as specialized as solving a single, well-defined, simple, and predictable hash function such as SHA-2.
We need to make proof-of-work more choatic and complex if we want to avoid this.
SHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work.
Otherwise, it will end just like you say.
Think of this vision of the year 2020: 2/3 of the world's Ghash/s is controlled by just three companies. They manufacture their own specialilsed HPUs (hash processing units) and feed them with custom-built power plants. The Chinese goverment then persuades the three companies to double spend 10% of all transactions into the Chinese government's bitcoin address, in return the companies get an exclusive deal on the rare earths they badly need for the HPU manufacture. Some people leave Bitcoin for alternative currencies without the 10% \"tax\", but most tolerate it because by then Bitcoin is accepted almost universally.
Generation will be less and less interesting in that way, as the coins per block will divide by 2 until there's no coins generated at all, and the system will need to be run by \"volunteers\", which aren't really volunteers because if no block is generated no coins can be transfered, thus removing all value from all coins...
I think it's an arms wrestle to try to avoid having a few people holding most of the coins, that's all. I was trying to leverage that by making everyone have a fair chance at getting coins while they are still being generated, but I fear that it is not practical.. When it comes to currencies (and I don't want to get into a semantics discussion, humour me with 'currency') people are just wired in a very egotistic way, and even when offered the chance to balance the scoreboard, they will just try and use that to their own advantage, not everyone's... it saddens me, really, but hey I'll keep on doing what I do because I strongly believe in it, just as others believe in taking the largest slice.
Generation will be less and less interesting in that way, as the coins per block will divide by 2 until there's no coins generated at all, and the system will need to be run by \"volunteers\", which aren't really volunteers because if no block is generated no coins can be transfered, thus removing all value from all coins...
The companies can raise fees if generations aren't enough to profit.
Every calculation can be made more efficient in hardware. Trying to prevent it is pointless. It'd be a lot like making effective DRM.
The strength of this project was meant to be its distributedness.
But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.
The average user no longer has a fighting chance and has given up generating blocks altogether.
What does this remind me of? That's right, bitcoin is becoming like the physical money economy, where a small number of central banks now guarantee the trustworthiness of paper money.
You seem to have missed the point. The distributed nature of Bitcoin is not compromised by the consentration of block generation. Because, unlike fiat currencies and central banking, no one group or person has monopoly control of the currency, and no one can manipulate it as such. Not even the GPU oligarchs. Also, they are competing among themselves. If one of them starts thinking that he has a majority of the block generation locked up, and decides he is going to try and fork-steal, the rest are going to notice the changes and they all have a strong incentive to overtake the market leader.
SHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work.
SHA is easy to calculate, but it's difficult to calculate a piece of data which will generate a given hash (which is [almost] what bitcoindoes). The proof of work must be difficult to calculate but easy to prove, which SHA is
My concern isn't really fairness, it's stability.
I buy about $20 worth of BTC each month, but I spend most of them straight away. What is keeping me from buying $1000 worth of BTC is my concern with the problems I mentioned. As a way of transferring money Bitcoin is great, as a way of saving money it is still too risky for my tastes. To succeed as a currency it must be good at both.
Mmm... Are you sure your dollars dont depreciate quicker than bitcoins? Dollars are worthless to create.
Also, thinking that holding dollars is less risky than bitcoins might be a bit naive.
How many Ghash's do you think Google would do if it started to generate?
",
"nested_level": 0
},
{
"id": 2906,
"thread_id": 231,
"source_id": "21",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14931#msg14931",
"date": "2010-10-02T01:27:10Z",
"text": "",
"nested_level": 0
},
{
"id": 2907,
"thread_id": 231,
"source_id": "22",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14932#msg14932",
"date": "2010-10-02T01:35:57Z",
"text": "How many Ghash's do you think Google would do if it started to generate?
Probably all of them, but difference would it make? Even if they are willing to commit the full brunt of their computing resources to overtake the generation of new coins, they can't make them faster than the difficulty system would permit. At least not for more than two weeks. Nor can they do anything to manipulate the value of the coins already in existance, beyond the effects of the regular generation awards. That's the beauty of the design, even Google couldn't do more than disrupt the system temporarily. Even at this early stage, the total proof-of-work represents a supercomputing class cluster. For what gain would anyone do such a thing? For a max return of 50K coins over two weeks of supercomputing time? Even Google doesn't have the computing power to rebuild the blockchain from the beginning. Even if they did, to what end? To steal a quarter million dollars in wealth? Which would likely collapse the system if it could be done at all, so that value would drop to zero. As we have seen, that difficulty level increases as the user base increases, regardless of an analysis as to the economics of each person generating.
I can accept that, however unlikely, a takeover of the system is possible; but if such a thing were to happen, it certainly wouldn't go unnoticed by the Bitcoin community. From where I stand, the odds that the Federal Reserve will cease to exist and the FRN collapse is more likely to occur first. For that matter, I would consider a worldwide extinction-level-event to be about as likely; but I'm not going to let the risks of a meteor strike stop me from walking out on the surface of the Earth.
Pools won't eliminate the \"problem\" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit.
Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about \"total hash/s\", it's about \"total unique hash/s\". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated. The node that generates the coin can just keep the full amount. The group will be better off together than alone. The bigger the pool, the better. In fact if these pools get much bigger than the companies (in terms of hash/s), then THEY will be severely marginalized and be forced to join the main pool or get nothing.
If the pool gets too big, then coins may be generated almost instantly at some point. This could be bad for the stability of the currency. Can anyone do the math on how many parallel coperating cpus it would take to find a coin in say, one minute?
I think this is a very important issue for the success of Bitcoin.
Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about \"total hash/s\", it's about \"total unique hash/s\". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated.
This is already guaranteed because everyone has a unique public key in their block. You reminded me of another way that pools are bad, though: since everyone uses the same public key, they have to do weird things with extraNonce, which increases the size of the block header and makes generating more difficult for them.
Can you tell more about this:
\"they have to do weird things with extraNonce, which increases the size of the block header\".
",
"nested_level": 0
},
{
"id": 2911,
"thread_id": 231,
"source_id": "26",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg14965#msg14965",
"date": "2010-10-02T06:03:18Z",
"text": "Can you tell more about this:
\"they have to do weird things with extraNonce, which increases the size of the block header\".
Usually you can start the nonce at 0 because they block you are working on is made unique by the inclusion of your unique address in the generate transaction. If a group of people all send generates to the same address you need another number included to make sure that the members are not repeating work.
I have no idea how important that fact is, it doesn't seem like too big of a deal to me, but theymos can elaborate.
Can you tell more about it:
\"they have to do weird things with extraNonce, which increases the size of the block header\".
When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception. After every hash attempt, you increment the Nonce header field, but since this field is only 32 bytes long, it overflows a lot. Whenever it overflows, you increment the variable-size extraNonce field. The larger extraNonce gets, the slower generating will get. It doesn't get significantly large with normal incrementing, though.
If you have a lot of computers and they're all working on the same block with the same public key, then they're all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.
Undoubtedly you could design a pooling system without this flaw, but it'd be more difficult.
I see that m0mchil's getwork is doing something with extraNonce. I don't know how bad that implementation is, but it theoretically
must be slower than a client without it (all things being equal; clearly adding GPU support will improve performance).
Even Google doesn't have the computing power to rebuild the blockchain from the beginning. Even if they did, to what end? To steal a quarter million dollars in wealth? Which would likely collapse the system if it could be done at all, so that value would drop to zero.
They wouldn't need to rebuild the blockchain from the beginning. They can double spend any transaction that happens after the 50% Ghash/s takeover. Of course, if they get too greedy, the system would collapse as users become fed up with their coins being stolen all the time. But what if they decide to double spend a certain \"optimal income\" percentage of transactions, just short of what will piss off most users?
Non issue, imo.
Those guys are just working for us. I'll just buy their bitcoins. It will probably be cheaper than buying expensive hardware and running it 24/24.
By selling bitcoins those might think they screw us. I think they're just wrong.
",
"nested_level": 0
},
{
"id": 2915,
"thread_id": 231,
"source_id": "30",
"poster_name": "gebler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=661",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg15097#msg15097",
"date": "2010-10-03T16:29:49Z",
"text": "The larger extraNonce gets, the slower generating will get.
But that effect would be totally insignificant. Even the standard client is optimized so that it doesn't need to hash the entire block header if only the last part of it has changed. That last part includes the nonce but not the extraNonce, so a larger extraNonce wouldn't cost anything for the vast majority of all hashes, namely those where only the normal nonce has been incremented. With today's transaction volumes, the cost of hashing the extraNonce should be less than a millionth of a percent for pools with thousands of members.
If you have a lot of computers and they're all working on the same block with the same public key, then they're all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.
In a centralized system, the server could simply keep a list of extraNonces in active use and give out the lowest free one. Then you would avoid collisions without requiring more than one unique extraNonce per client. A 3-byte extraNonce would be sufficient for millions of clients. Note that clients of realistic performance do not really need the extraNonce to handle nonce overflow today, since such overflows happen less frequently than the periodic nTime updates (but this is not considered by the standard client today, which updates the extraNonce more liberally).
I'm just getting into this whole bitcoin thing. It seems to me already, though, that getting
great results from bitcoin mining would require a server farm, super computer, etc; worrying
about individuals taking advantage of their GPUs or crypto accelerators is probably pointless.
What can 30000 khash/s really get you? Maybe around the equivalent of $1.50 per day at
current difficulty levels? Not really a very efficient means of recouping the cost of an expensive
gaming rig.
I'd be much more concerned about what somebody with a botnet might be capable of.
",
"nested_level": 0
},
{
"id": 2918,
"thread_id": 231,
"source_id": "33",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: How to overthrow the GPU Oligarchs",
"url": "https://bitcointalk.org/index.php?topic=1332.msg15120#msg15120",
"date": "2010-10-03T20:12:03Z",
"text": "I'd be much more concerned about what somebody with a botnet might be capable of.
So what if a botnet generate all these bitcoins? He'll be able to move markets for his money. Big deal.
Can you tell more about it:
\"they have to do weird things with extraNonce, which increases the size of the block header\".
When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.
This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header.
We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't.
extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.
Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too.
Latest minerpoclbm_py2exe_20120920mirrorSources for poclbm are at
http://github.com/m0mchil/poclbmGUICreated by Kiv, see
http://bitcointalk.org/index.php?topic=3878.0GuidesWindows -
http://www.newslobster.com/random/how-to-get-started-using-your-gpu-to-mine-for-bitcoins-on-windowsUbuntu -
http://bitcointalk.org/index.php?topic=2636Mac -
http://forum.bitcoin.org/index.php?topic=12360Known best settings(please PM better/best settings for your platform)
AMD 5xxx and upuse '-v -w 128'
Frequently asked questionsQ: Does my video card / driver supports OpenCL?AMD - 4xxx and up. Nvidia - 8xxx and up. On Windows you can use 'GPU Caps Viewer' or similar.
Q: I am seeing 'pyopencl.LogicError: clGetPlatformIDs failed', what is this?
Q: It says 'ImportError: DLL load failed: The specified module could not be found'?
Q: Or 'ImportError: DLL load failed: The specified procedure could not be found'?You don't have proper OpenCL support. The reasons may vary. Be sure to remove any old drivers and SDK from different vendors you may have used. Use web search to see how to make it work for your combination of GPU and OS.
Q: When I try to run it with the following parameters: '--host=http://mining.bitcoin.cz:8332' miner errors out with 'nonnumeric port'Remove 'http://', it's intended for browsers (becames '--host=mining.bitcoin.cz'). Use '--port' to specify port (default is 8332 so you don't need to specify it if the pool you use is at same port).
Q: Why it uses 100% CPU?You probably selected the CPU as OpenCL device. Or you are using it on Linux with AMD Stream SDK 2.2. Use 2.1 instead.
Q: What does 'invalid or stale' means?The block last submitted was either invalid or stale.
Q: How a block becomes stale?You submited solution for a block which was just solved by someone else.
Q: Why a block is invalid?Don't overclock too much. And switch crossfire off. Or may be I screwed the search again?
It's good if you see more 'accepted's than 'invalid's.
When I try to run the miner a new CMD window flashes on my screen too rapidly to read anything, or even see if it says anything.It's console application. You use that ugly black thing called 'Command Prompt' to run it.
",
"nested_level": 0
},
{
"id": 2921,
"thread_id": 232,
"source_id": "2",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg14876#msg14876",
"date": "2010-10-01T18:35:13Z",
"text": "I hope someone will try this wonderful OpenCL bitcoin miner. It uses
PyOpenCl. Should be generally platform independent. The OpenCL kernel uses previous work by laszlo. You will need bitcoin patched with
this to enable RPC getwork(). You may use as many external miners as you wish (if running RPC with -rpcallowip).
Have fun.
Amazing solution! Not good for the masses (it's better to integrate the miner in the binary) but great for experimentation and multiple machine mining. I'll be sure to have a go at this when I get a sec, kudos for putting this out.
It is interesting to see how you've split mining and wallet+P2P into separate pieces. Nice and modular.
I'll be interested to see feedback from people, if they actually generate coins from this.
",
"nested_level": 0
},
{
"id": 2923,
"thread_id": 232,
"source_id": "4",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg14887#msg14887",
"date": "2010-10-01T19:06:06Z",
"text": "nelisky: Integrating CUDA/OpenCL seems to have portability issues. Also, my goal is actually to convince satoshi to patch the mainline. The patch must be crystal clear for this to happen.
jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.
Forgot to mention that original client generation could be used in parallel.
",
"nested_level": 0
},
{
"id": 2924,
"thread_id": 232,
"source_id": "5",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg14894#msg14894",
"date": "2010-10-01T19:36:35Z",
"text": "nelisky: Integrating CUDA/OpenCL seems to have portability issues. Also, my goal is actually to convince satoshi to patch the mainline. The patch must be crystal clear for this to happen.
Yes, that is one of my biggest concerns. I don't have enough exposure to assert in multiple platforms / hw. And I have failed to provide a simple click and use distributable, as of yet, but as interest increases and more developers tackle this I'm sure one of us will provide a clean implementation that is production quality for satoshi.
davidonpda: you need
1. Some OpenCL capable hardware and driver.
2.
python 2.6.63.
PyOpenCL. This could be tricky, follow the
official installation instructions.
oclbm.py -h or --help for some options, by default looks for bitcoin RPC at 127.0.0.1:8332
Hope this helps
Will opencl client works on ati hd3850?
",
"nested_level": 0
},
{
"id": 2927,
"thread_id": 232,
"source_id": "8",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg14963#msg14963",
"date": "2010-10-02T06:00:48Z",
"text": "ATI HD3850 has no OpenCL support.
4xxx and 5xxx have.
",
"nested_level": 0
},
{
"id": 2928,
"thread_id": 232,
"source_id": "9",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15263#msg15263",
"date": "2010-10-04T11:43:55Z",
"text": "Due to popular demand
bitcoin PyOpenCL miner is available now at
http://github.com/m0mchil/poclbmThere are some minor fixes. Be sure to experiment with globalThreads to achieve better performance/dekstop lag ratio.
jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.
Hmm, that's weird. Shouldn't the speed be much bigger, like 10-fold or 100-fold faster at least ?
I mean there was this guy somewhere on the BTC forum who claimed that he's getting 983 Mhash/s (983 000 khash/sec) with just 3 radeons 5870 or something.
jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.
Hmm, that's weird. Shouldn't the speed be much bigger, like 10-fold or 100-fold faster at least ?
I mean there was this guy somewhere on the BTC forum who claimed that he's getting 983 Mhash/s (983 000 khash/sec) with just 3 radeons 5870 or something.
Yeah, I'm struggling with how OpenCL compiles kernels and the impact of the work size on performance. It is quite counter intuitive coming from CUDA, as the unrolling of loops and functions actually makes performance worse, as the kernel needs more space. I don't have any numbers for that ATI, but the 4350 seems to be a LOT less performant than the 5870, so it might not be that low.
Once I have hardware to test this for real, I'll compare my approach to this one, so we can learn from each other.
There is information on wikipedia about the performance of various
AMD/ATI and
Nvidia chips.
4350 is cited at 92 GFLOPS. 5870 has 2720 GFLOPS. tcatm has 3x5870s. Due to it's superior architecture 5870 is capable of more than just the difference in GFLOPS. For example I get 6 Mhash/s on 4350 and 137 Mhash/s on 5770 (ratio of 1/22) even if the ratio of GFLOPS for the relevant cards is 92 to 1360 (1/14).
don't have an ATI card, but even after reading those performance-infos i still can't believe that 980something-mega-hash.
5.800khash on a hd4350 makes sense to me, i get around 5-6.000 on a 8600gt, both listed around 100GFlops.
my gtx260 gets ~40Mhash, 874GFlops
i'd expect a hd5870 makes at least 3times as much, cuz it's listed with 2700GFlops,
which would result in around 400Mhash for 3 of those cards,
that's what i would expect, so where's those extra 600Mhash coming from?
it's superior architecture?
if so, my next card will be ati again.
don't have an ATI card, but even after reading those performance-infos i still can't believe that 980something-mega-hash.
5.800khash on a hd4350 makes sense to me, i get around 5-6.000 on a 8600gt, both listed around 100GFlops.
my gtx260 gets ~40Mhash, 874GFlops
i'd expect a hd5870 makes at least 3times as much, cuz it's listed with 2700GFlops,
which would result in around 400Mhash for 3 of those cards,
that's what i would expect, so where's those extra 600Mhash coming from?
it's superior architecture?
if so, my next card will be ati again.
There's a lot more than GFlops to this equation. Memory bandwidth, for one, will be very important.
of course, but still
i'd like to know if that's a usual expectation on ati cards compared to nvidia,
no single-hd5870-users around that want to share their hash-count?
i'm gonna buy a new card sooner or later anyway and i don't mind if it says ati or nvidia on it,
both will surely run my game/s.
but if one of them is x times better crunching blocks and besides that, prolly cheaper too,
i already know what my next favourite brand is.
",
"nested_level": 0
},
{
"id": 2935,
"thread_id": 232,
"source_id": "16",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15307#msg15307",
"date": "2010-10-04T15:30:57Z",
"text": "Sorry, just realized i broke it with latest changes, please update. (It won't submit to RPC properly)
",
"nested_level": 0
},
{
"id": 2936,
"thread_id": 232,
"source_id": "17",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15500#msg15500",
"date": "2010-10-05T15:31:14Z",
"text": "Added auto adjustment to keep desktop responsive. Also, doing hash rate calculation at user defined interval.
",
"nested_level": 0
},
{
"id": 2937,
"thread_id": 232,
"source_id": "18",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15573#msg15573",
"date": "2010-10-05T22:27:55Z",
"text": "I can't get the getwork patch to compile into bitcoin. Is that something satoshi has considered adding to the main trunk?
I've got PyOpenCL finally installed but without the patch in the client, I can't request anything.
I'm in the same position. All I need is the patch compiled into the client and I should be ready to go :/
Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please
use the repo.
Do i need to use a special version of graphics drivers to get the OpenCL client working ?
",
"nested_level": 0
},
{
"id": 2941,
"thread_id": 232,
"source_id": "22",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15659#msg15659",
"date": "2010-10-06T15:35:25Z",
"text": "Win32 bitcoin with getwork, against SVN 161.
",
"nested_level": 0
},
{
"id": 2942,
"thread_id": 232,
"source_id": "23",
"poster_name": "martin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=310",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15676#msg15676",
"date": "2010-10-06T17:14:08Z",
"text": "Any chance of a 64 bit windows build?
Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please
use the repo.
now it segfaults:
http://paste.pocoo.org/show/271825/Sorry, forgot about that. You should install json-rpc. See at
http://json-rpc.org/wiki/python-json-rpcL29Ah, unfortunately there isn't Nvidia card here to test with it. I suppose you should try different drivers. It seems the problem is in nvidia OpenCL compiler.
Use '-server'.
",
"nested_level": 0
},
{
"id": 2946,
"thread_id": 232,
"source_id": "27",
"poster_name": "mizerydearia",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=338",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15801#msg15801",
"date": "2010-10-07T08:31:40Z",
"text": "Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please
use the repo.
Added to
http://www.bitcoin.org/wiki/doku.php?id=repositoriesCan anyone pls upload the Stream SDK 2.2 for 64bit Windows 7 pls ?
AMD link is down -.-
",
"nested_level": 0
},
{
"id": 2948,
"thread_id": 232,
"source_id": "29",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15832#msg15832",
"date": "2010-10-07T13:53:51Z",
"text": "Got it working:
295525 khash/s!!!
Holy mother of <Insert supreme being here>
Please, do share some hw details
damn, i cant get python to register properly.
does anyone know how to fix that on win7-64 ?
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\Pythoncore\\2.7\\InstallPath = C:\\Python27
HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\Pythoncore\\2.7\\PythonPath = C:\\Python27;C:\\Python27\\Lib;C:\\Python27\\DLLs
and
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Python\\Pythoncore\\2.7\\InstallPath = C:\\Python27
HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Python\\Pythoncore\\2.7\\PythonPath = C:\\Python27;C:\\Python27\\Lib;C:\\Python27\\DLLs
dont work.
",
"nested_level": 0
},
{
"id": 2950,
"thread_id": 232,
"source_id": "31",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15843#msg15843",
"date": "2010-10-07T14:31:10Z",
"text": "Smoketoomuch, get version 2.6.6 AND get the 32 bit binaries.
If you install the 64 bit, the extensions are all based on 32 bit, and it won't find your installation. Reinstall with 32 bit and you're golden.
oh ok, thanks, now it works.
all I need is a stream sdk for 64 bit now -.- cmon AMD! fix it!
wtf ?
when I click that link I get forwarded to
http://developer.amd.com/Pages/amd404.aspxedit: works with IE O.o but not with firefox, hmm.
maybe I changed my http referrer settings or something.
__________________________________________________
while trying to install pyopencl 0.92 with \"python setup.py install\" I get the following error:
Traceback (most recent call last):
File \"setup.py\", line 160, in <module>
main()
File \"setup.py\", line 50, in main
warn_about_no_config=False)
File \"c:\\Users\\STM\\Desktop\\OpenCL Bitcoin\\pyopencl-0.92\\aksetup_helper.py\", line 164, in get_config
return schema.read_config()
File \"c:\\Users\\STM\\Desktop\\OpenCL Bitcoin\\pyopencl-0.92\\aksetup_helper.py\", line 366, in read_config
cfile, key))
KeyError: 'invalid config key in .\\\\siteconf.py: SHIPPED_CL_HEADERS'
using Python 2.6.6, setuptools 0.6c11, NumPy 1.5.0, SciPy 0.8.0, Boost 1.44
any recommendation ?
BOOST_INC_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44']
BOOST_LIB_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44\\lib']
BOOST_COMPILER = 'msvc'
BOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']
BOOST_THREAD_LIBNAME = ['boost_thread-vc90-mt-1_44']
CL_TRACE = False
CL_ENABLE_GL = False
SHIPPED_CL_HEADERS = False
CL_INC_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\include']
CL_LIB_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\lib\\x86']
CL_LIBNAME = ['OpenCL']
CXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']
LDFLAGS = ['/FORCE']
Thats my current siteconfig.py, but I will try yours now.
Edit: thx man, your my hero now ^^
BOOST_INC_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44']
BOOST_LIB_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44\\lib']
BOOST_COMPILER = 'msvc'
BOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']
USE_SHIPPED_BOOST = False
CL_TRACE = False
CL_ENABLE_GL = False
CL_INC_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\include']
CL_LIB_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\lib\\x86']
CL_LIBNAME = ['OpenCL']
CXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']
LDFLAGS = ['/FORCE']
hey, it's me .. again ...
python poclbm.py -->
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
import pyopencl as cl
File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>
import pyopencl._cl as _cl
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
Seems like a DLL is missing.
I copied them into system32, this usually sloves these problems, but I'm gonna try it.
PS: the German error message only says, that the module was not found.
EDIT: and again, you were right
but now a new error message shows up:
C:\\Program Files (x86)\\Bitcoin>python poclbm.py
Unable to communicate with bitcoin RPC
I'm using this client:
Win32 bitcoin with getwork, against SVN 161.
DownloadEDIT2: ok forget it, forgot about the -server switch
EDIT3: yay it works, finally.
BUT, now it asks for username and passwords every ~8 seconds.... ?
EDIT4: I changed the default values for user and pw in pocbm.py and now it works
ASUS Radeon HD4870 512MB gpu@750MHz vram@900(1800)MHz
~75500khashs/s
gpu temp currently @74\u00b0C (bios-modded long ago to adjust fan speed)
",
"nested_level": 0
},
{
"id": 2956,
"thread_id": 232,
"source_id": "37",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15906#msg15906",
"date": "2010-10-07T20:26:00Z",
"text": "yes 4870, edited my post.
and yes, more people should use it
now I can generate bitcoins on my gpu and rainbow tables on my cpu at the same time
More people need to jump on board of the OpenCL miner.
Anyone fancy building a 64bit windows build of bitcoin suitable for the OpenCL miner? It may be worth some bitcoins
Yes, I am.
Uhm, does anyone know if poclbm works with mutliple graphic cards ?
",
"nested_level": 0
},
{
"id": 2959,
"thread_id": 232,
"source_id": "40",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg15986#msg15986",
"date": "2010-10-08T05:23:15Z",
"text": "Here's one for you.
It just found another block, and... bitcoin doesn't show anything...
The miner asks for work at an interval of 10 seconds. If there is a new block from the network in the last such interval your client won't even try to announce your own next block. I am not sure, but I think this is the behavior of the original client too. Please take a look at your debug.log and if possible send me an excerpt from around where this happened. Look for terms like \"SetBestChain\" and \"height=\" if you know the block number.
Sometimes the client just doesn't show the new transaction right away.
Right after these lines is there something like:
ProcessBlock: ACCEPTED
sending: inv (37 bytes)
If so (and you are sure this is the block in question) it was announced to the network, but another block got included in the chain instead. Do you have other blocks after that?
BTW, if you want poclbm to crunch slower, start it with something like -f 400. Experiment with the number.
",
"nested_level": 0
},
{
"id": 2961,
"thread_id": 232,
"source_id": "42",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16334#msg16334",
"date": "2010-10-09T21:27:08Z",
"text": "of course, but still
i'd like to know if that's a usual expectation on ati cards compared to nvidia,
no single-hd5870-users around that want to share their hash-count?
i'm gonna buy a new card sooner or later anyway and i don't mind if it says ati or nvidia on it,
both will surely run my game/s.
but if one of them is x times better crunching blocks and besides that, prolly cheaper too,
i already know what my next favourite brand is.
gflops is not really relevant to bitcoin mining since gflops is measure of floating point and bitcoin mining is fixed point. It think fixed point is relatively good to ati and hard for nvidia.
If you have an app that uses floating point more than fixed point the the disparity might vanish or at least diminish.
It think fixed point is relatively good to ati and hard for nvidia.
That sounds interesting. Do you have any web-sources for this ?
@m0mchil:
Is your Python OpenCL client using priorization ? like, can I start a game while using your client and it will automatically slow down the hash rate and my card will focus on the game ?
It only tries to keep single kernel run under specific time by changing the number of 'global' threads. If you start a game, kernel execution will get slower. The number of threads will then be gradually adjusted to achieve the desired execution time.
By default this time is 1/60 of a second. If shorter i.e. 1/120 sec it will leave more time for other GPU tasks.
This is adjusted with the '-f' switch.
",
"nested_level": 0
},
{
"id": 2964,
"thread_id": 232,
"source_id": "45",
"poster_name": "lfm",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=466",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16519#msg16519",
"date": "2010-10-11T06:57:03Z",
"text": "I can't get the getwork patch to compile into bitcoin. Is that something satoshi has considered adding to the main trunk?
I've got PyOpenCL finally installed but without the patch in the client, I can't request anything.
try :
svn co -r 161
https://bitcoin.svn.sourceforge.net/svnroot/bitcoinIt seems any other revision fails the patch.
ok, I'm really new at this GPGPU stuff, I got this message when I try to run the thing:
Traceback (most recent call last):
File \"poclbm.py\", line 28, in <module>
miner = cl.Program(context, kernelFile.read()).build()
File \"/usr/lib/pymodules/python2.6/pyopencl/__init__.py\", line 138, in program_build
\"Build on %s:\n\n%s\" % (dev, log) for dev, log in build_logs))
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 8400 GS' at 0xf16c40>:
Error: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0
-------------------
This is on Linux 64 bit, does the \"i32 = bswap\" mean it wants linux 32?
btw I know the 8400 GS is slow, you don't have to tell me.
Error: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0
Try to update your GPU driver. See
http://forums.nvidia.com/index.php?showtopic=150585It seems OpenCL is still problematic on Nvidia GPUs. Unfortunately I don't have one to try to make a PyCuda miner.
I think I have the newest stuff. Ill just have to wait for the next version by the looks of it. Maybe give up on it and find an ATI card.
",
"nested_level": 0
},
{
"id": 2968,
"thread_id": 232,
"source_id": "49",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16564#msg16564",
"date": "2010-10-11T16:55:44Z",
"text": "SPARKLE SX84GS256D2LDPP GeForce 8400 GS 256MB 64-bit DDR2 PCI Express 2.0 x16 HDCP Ready Low Profile Ready Video Card
Well .. 256mb .. DDR2 with 64 bit interface
this even was crap when it came on the market ^^
ok, I'm really new at this GPGPU stuff, I got this message when I try to run the thing:
Traceback (most recent call last):
File \"poclbm.py\", line 28, in <module>
miner = cl.Program(context, kernelFile.read()).build()
File \"/usr/lib/pymodules/python2.6/pyopencl/__init__.py\", line 138, in program_build
\"Build on %s:\n\n%s\" % (dev, log) for dev, log in build_logs))
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 8400 GS' at 0xf16c40>:
Error: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0
-------------------
This is on Linux 64 bit, does the \"i32 = bswap\" mean it wants linux 32?
btw I know the 8400 GS is slow, you don't have to tell me.
Got the same error on a Win7-64 with 8600 GTS.
Build on <pyopencl.Device 'GeForce 8600 GTS' at 0x2ed2f48>:
Error: Code selection failed to select: 0x5d57918: i32 = bswap 0x5d57808
Seems like poclbm doesn't work on nvidia cards.
hey, it's me .. again ...
python poclbm.py -->
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
import pyopencl as cl
File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>
import pyopencl._cl as _cl
ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.
Seems like a DLL is missing.
Copy your boost_python-vc90-mt-1_44.dll and boost_thread-vc90-mt-1_44.dll that you compiled with boost earlier directly into your directory where you are running poclbm.py from.
I don't speak German, but that looks like what it is saying to me.
I also get this error. I tried copying boost_python-vc90-mt-1_44.dll and boost_thread-vc90-mt-1_44.dll directly into the directory where I am running poclbm.py but it has the same error (see below). I copied it into Windows\\System32 but still same error. Any ideas???
C:\\bitcoin_miner>python poclbm.py
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
import pyopencl as cl
File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__i
nit__.py\", line 3, in <module>
import pyopencl._cl as _cl
ImportError: DLL load failed: The specified module could not be found.
looks like a dll is missing
which boost version are you using ?
best is to post your siteconf.py
",
"nested_level": 0
},
{
"id": 2972,
"thread_id": 232,
"source_id": "53",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16732#msg16732",
"date": "2010-10-12T19:24:20Z",
"text": "Post your boost version, siteconf, and os. Should be able to help you more from there. Make sure you grabbed the right dll's because several of them are named close.
I am using Windows Vista 64-bit. I used boost 1.44, but there was an error so I actually downloaded the binary versions of \"boost_python-vc90-mt-1_44.dll\" and \"boost_thread-vc90-mt-1_44.dll\". I used all 32-bit installations for compatibility. Below is siteconf.py. I was able to run \"python setup.py install\" ok without errors.
BOOST_INC_DIR = ['C:\\\boost_1_44_0']
BOOST_LIB_DIR = ['C:\\\boost_1_44_0\\\\lib']
BOOST_COMPILER = 'msvc'
BOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']
USE_SHIPPED_BOOST = False
CL_TRACE = False
CL_ENABLE_GL = False
CL_INC_DIR = ['C:\\\\Program Files (x86)\\\\NVIDIA GPU Computing Toolkit\\\\CUDA\\3.2\\\\include']
CL_LIB_DIR = ['C:\\\\Program Files (x86)\\\\NVIDIA GPU Computing Toolkit\\\\CUDA\\3.2\\\\lib\\\\Win32']
CL_LIBNAME = ['OpenCL']
CXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']
LDFLAGS = ['/FORCE']
Thanks for your help!
Awesome, so you got it working with a CUDA card?
Specs and hash rate?
Oh, not yet...sorry if it sounded like I declared victory too early. I still get:
ImportError: DLL load failed: The specified module could not be found.
Any ideas?
I went home for lunch to debug but now I am at work. I am hardcore to get this to work. Will work in it tonite.
",
"nested_level": 0
},
{
"id": 2975,
"thread_id": 232,
"source_id": "56",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16780#msg16780",
"date": "2010-10-13T01:04:23Z",
"text": "I did not do the bootstrap methon. I used the win installer with the precompiled binaries from here
http://www.boostpro.com/download/ (that was what the boost site said to do).
I reinstalled Python26, Numpy, SciPi, and boost 1_39. I copied all the dlls into the same folder as poclmb.py.
Still same error.
Hmmm...
I completely misunderstood you sorry.
So you did not compile the dll's yourself for boost? So you might have a problem with your boost path.
What happens when you run the bootstrap in the boost directory?
Then here is what I used to build the boost libraries after bootstrapping:
bjam.exe toolset=msvc --with-python --with-date_time --with-thread threading=multi link=shared
That then created a directory starting from c:/boost called C:\\boost\\stage\\lib that had the dll's in it, and is how I pointed it inside my site.conf
Then I copied those dll's over. I am wondering if the dll's you downloaded aren't the right ones or don't have all the right flags or something.
I believe I have the right flags. In the installer I picked msvc 2008, python, date time, and thread. There is no option for threading or link.
OMG! Thx david and momchil! I was about to give up...gonna try it when I get home.
I have an nVidia card...I hope I can install the nVidia sdk instead of the ati sdk. (Fingers crossed)
",
"nested_level": 0
},
{
"id": 2979,
"thread_id": 232,
"source_id": "60",
"poster_name": "jimbobway",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=325",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16877#msg16877",
"date": "2010-10-13T19:27:21Z",
"text": "OMG! Thx david and momchil! I was about to give up...gonna try it when I get home.
I get this error:
C:\\Users\\Bitcoin GPU\\Desktop\\poclbm_py2exe>poclbm
Traceback (most recent call last):
File \"poclbm.py\", line 40, in <module>
pyopencl.LogicError: clGetPlatformIDs failed: invalid/unknown error code
[\\code]
I went home for lunch and I am physically at my computer...back to work for me. I have not tried puddinpop's client.
",
"nested_level": 0
},
{
"id": 2981,
"thread_id": 232,
"source_id": "62",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg16883#msg16883",
"date": "2010-10-13T19:57:02Z",
"text": "Jimbo, please
try this and see if the tool shows OpenCL is supported. It would be helpful if you post a screenshot.
I get a 2-3% increase on the new version. Not much, but a consistent increase. I have my hashes scaled back to about 150/m so this increases it to about 153/m.
It jumps around a little bit of course, but I don't really see it dip below 153/m
Edit-
Don't get me wrong either. 3000k/hs is an extra block a month so no complaints!
Wow! What hardware are you running?
On a more related note, I get this error when running m0m's release (8800 GTS, Driver 258.96)
C:\\Users\\Owner\\Desktop\\BitcoinOpenCL>poclbm
Traceback (most recent call last):
File \"poclbm.py\", line 46, in <module>
File \"pyopencl\\__init__.pyc\", line 138, in program_build
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 8800 GTS 512' at 0x2dd1600>:
Error: Code selection failed to select: 05102178: i32 = bswap 04EFFBA8
i get similar results with my nvidia card
C:\\Documents and Settings\\Administrator\\Desktop\\bitcoin_stuff\\poclbm_py2exe>poclbm
Traceback (most recent call last):
File \"poclbm.py\", line 46, in <module>
File \"pyopencl\\__init__.pyc\", line 138, in program_build
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce GTX 260' at 0x24325c0>:
Error: Code selection failed to select: 0x4ea2128: i32 = bswap 0x516dca0
of Caps Viewer and GPU-Z (for driver-info).
Mine's an ATI 5870.
...
run that and see if it shows OpenCL is supported. Give us a screen shot. There are some trouble shooting steps on their website.
Wow, nice!
Here's my screenie:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg268.imageshack.us%2Fimg268%2F2977%2Fgpuu.png&t=589&c=1aKQYuvSD78yOg\"/)
Jim, I don't know where to help from here. Two other people have OpenCL support on their Nvidia card, and still can't get it to work. Without having a set in front of me, it's hard to troubleshoot it. I do have an Nvidia card, same one as you just about, but I don't know if I'm going to swap it out to test. I'm sure our set up varies greatly and I don't know if I would be able to make any beneficial advancements doing it, sorry.
It's ok. I'm sure something awesome will come out, but I'm happy to test this for momchil. thought my 8800 would have OpenCL support but it doesn't. Thanks anyway.
On a more related note, I get this error when running m0m's release (8800 GTS, Driver 258.96)
C:\\Users\\Owner\\Desktop\\BitcoinOpenCL>poclbm
Traceback (most recent call last):
File \"poclbm.py\", line 46, in <module>
File \"pyopencl\\__init__.pyc\", line 138, in program_build
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 8800 GTS 512' at 0x2dd1600>:
Error: Code selection failed to select: 05102178: i32 = bswap 04EFFBA8
I get something very similar on a 9400GT, but in linux! No idea how to fix this.
has ANYONE got this working on a nvidia card ?
",
"nested_level": 0
},
{
"id": 2989,
"thread_id": 232,
"source_id": "70",
"poster_name": "bethel",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=949",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17154#msg17154",
"date": "2010-10-15T21:57:45Z",
"text": "I have two machines that behave totally differently under this python client.
They both have the same hardware and OS:
AMD Semperon Single core
1GB RAM
ASUS ATI Radeon HD 5850 overclocked to 950mhz
One machine does 300-305mhash/s and stresses the gpu to 94-97%
The other does 282-289mhash/s and stresses the gpu to 89-91%
How do I increase my slow machine to get the extra 20mhash? Is there a command line way to tighten the processing loop?
",
"nested_level": 0
},
{
"id": 2990,
"thread_id": 232,
"source_id": "71",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17155#msg17155",
"date": "2010-10-15T22:00:23Z",
"text": "Are both machines using the same driver version ?
",
"nested_level": 0
},
{
"id": 2991,
"thread_id": 232,
"source_id": "72",
"poster_name": "bethel",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=949",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17160#msg17160",
"date": "2010-10-15T22:23:20Z",
"text": "They are the same.
8.14.10.0779 Catalyst 10.9 on Windows 7 64-bit
I would not expect them to be different because one is a clone of the other.
",
"nested_level": 0
},
{
"id": 2992,
"thread_id": 232,
"source_id": "73",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17203#msg17203",
"date": "2010-10-16T07:08:11Z",
"text": "bethel, what are 5870s showing at stock frequency (850 MHz)? Perhaps one of the cards throttles down?
Latest version has new parameter, -w, to set work group size. I have best results on 5770 with -w 128 -f 35.
",
"nested_level": 0
},
{
"id": 2993,
"thread_id": 232,
"source_id": "74",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17239#msg17239",
"date": "2010-10-16T17:18:48Z",
"text": "The IDs stay the same as long as there are no changes in hardware (new cards for example).
The -w parameter sets the number of 'work group size' (local threads). Unfortunately it's very difficult to determine the optimal value for this because it's different on different hardware platforms. The default is to use maximum reported by OpenCL for the specific hardware. This also was the behavior of previous versions. Last days I tried an optimization which tests two hashes in kernel run and it is 1-2% slower with default local threads (5770 - 256), but 5-6% faster with half of them (128) and global threads little bit more (-f 35). Generally, with default parameters one should achieve about the same or slightly worse performance than before.
",
"nested_level": 0
},
{
"id": 2994,
"thread_id": 232,
"source_id": "75",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17269#msg17269",
"date": "2010-10-16T23:51:50Z",
"text": "Hello All,
I tried without success to use the Python OpenCL Miner, here's what I did and what I got :
First my config, I run on Windows 7 Pro 32 bits with a NVIDIA GeForce 9800 GT.
I downloaded and installed CUDA Toolkit from :
http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7-> cudatoolkit_3.2.7_win_32.msi
I downloaded Boost 1.44.0 and built it with :
bjam.exe toolset=msvc --with-python --with-date_time --with-thread threading=multi link=shared
as did davidonpda on the post #81.
Then I copied all the dll from H:\\boost_1_44_0\\stage\\lib to system32.
I downloaded and built pyopencl-0.92 :
1) running > python configure.py
2) modifying siteconf.py :
(example from
http://www.mail-archive.com/pyopencl@tiker.net/msg00349.html)
BOOST_INC_DIR = [r'H:\\boost_1_44_0']
BOOST_LIB_DIR = [r'H:\\boost_1_44_0\\stage\\lib']
BOOST_COMPILER = 'msvc'
BOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']
USE_SHIPPED_BOOST = False
CL_TRACE = False
CL_ENABLE_GL = False
CL_INC_DIR = [r'E:\\NVIDIA GPU Computing Toolkit\\CUDA3.2\\include']
CL_LIB_DIR = [r'E:\\NVIDIA GPU Computing Toolkit\\CUDA3.2\\lib\\Win32']
CL_LIBNAME = ['OpenCL']
CXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']
LDFLAGS = ['/FORCE']
3) running > ctags -R src || true
4) running > python setup.py build
-> compilation without error
5) running > python setup.py install
-> installation without error
I downloaded poclbm from
http://github.com/m0mchil/poclbm-> m0mchil-poclbm-cf33815.zip
And trying to run it : > python poclbm.py
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
import pyopencl as cl
File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>
import pyopencl._cl as _cl
ImportError: DLL load failed: La proc\u00dadure sp\u00dacifi\u00dae est introuvable.
(the text in french with the fucked accents means : The specified procedure could not be found).
Note : I don't make all running together the first time, it took a long time and I can forget some step.
I also tried poclbm_py2exe.7z that I got from the board (post #87), first with the original OpenCL.dll in the archive, I got an error due to my Nvidia card I gess :
No device specified, you may use -d to specify one of the following
Traceback (most recent call last):
File \"poclbm.py\", line 57, in <module>
File \"pyopencl\\__init__.pyc\", line 138, in program_build
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 9800 GT' at 0x28d2be8>:
:37: error: incompatible type assigning 'int', expected 'uint2'
work[5]=0x00000000;
^~~~~~~~~~~
:38: error: incompatible type assigning 'int', expected 'uint2'
work[6]=0x00000000;
^~~~~~~~~~~
...
then I tried by replacing the dll with the one from the CUDA Toolkit, and I got the same error than while running poclbm I built :
File \"poclbm.py\", line 5, in <module>
File \"pyopencl\\__init__.pyc\", line 3, in <module>
File \"pyopencl\\_cl.pyc\", line 12, in <module>
File \"pyopencl\\_cl.pyc\", line 10, in __load
ImportError: DLL load failed: La proc\u00dadure sp\u00dacifi\u00dae est introuvable.
So the problem come from OpenCL dll from Nvidia !
I checked _cl.pyd with dependency walker, if I'm correct (this is the first time I use this tool), some functions are missing in the OpenCL.dll from Nvidia :
clSetUserEventStatus (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1051,31))
clCreateUserEvent (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1062,20))
(pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1063,32))
clCreateSubBuffer (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1165,22))
(pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1168,36))
clEnqueueReadBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1416,27))
clEnqueueWriteBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1460,27))
clEnqueueCopyBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1496,27))
In the file OpenCL.dll in poclbm_py2exe.7z, those 6 functions exist !
I got the explication with a little more search on the net, with the confirmation on those two pages :
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/The 6 functions where added in OpenCL 1.1, and Nvidia OpenCL implements the version 1.0 !
So if I'm correct pyopencl won't work on Nvidia cards until Nvidia release an OpenCL 1.1 compliant Toolkit and driver.See the post below.
Note from
http://developer.nvidia.com/object/opencl.htmlOn the same day Khronos Group announced the new OpenCL v1.1 specification update (June 14th, 2010), NVIDIA released OpenCL v1.1 pre-release drivers and SDK code samples to all GPU Computing registered developers.
So you have to register as a \"GPU Computing developer\" to get the SDK and driver, I don't do it for now (you have to fill a big form which is verified before validation, and I'm not \"GPU Computing developer\"
).
PS : I think you might have guessed, I'm French. sorry for mistakes and strange turns of phrase that can be
After writing the post above, I checked the file pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp to see the use of the 6 functions that are not in OpenCL 1.0, and I saw an interesting point :
The use of the 6 functions is \"protected\" by blocks #ifdef CL_VERSION_1_1 / #endif.
So I will check why CL_VERSION_1_1 was defined when I compiled the wrapper and will try to compil it without this macro defined.
More informations to come ... later (it is now 2h33 AM in France, time to go to bed
)
jef.blanc, try to replace the rotate() function with some native rotate left. rotate() is compiled to bit_align AMD specific instruction on AMD. Also there are problems with casts... I switched to uint2 vectors and all operations with mixed types (vector, scalar) work fine on AMD, but Nvidia compilator has problems.
",
"nested_level": 0
},
{
"id": 2997,
"thread_id": 232,
"source_id": "78",
"poster_name": "GeorgeH",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1179",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17331#msg17331",
"date": "2010-10-17T09:06:45Z",
"text": "Definitely hoping to see this on nvidia in the near future! I have 2 graphics cards now and can only use one with the CUDA client!
",
"nested_level": 0
},
{
"id": 2998,
"thread_id": 232,
"source_id": "79",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17334#msg17334",
"date": "2010-10-17T09:37:34Z",
"text": "After verification, the macro CL_VERSION_1_1 is defined in CL/cl.h from the Cuda Toolkit I installed, and this file declare the OpenCL 1.1 functions (it's logic in fact, I should have a compilation error otherwise) !
So the Toolkit I installed take in charge OpenCL 1.1, and my current Nvidia driver (that I didn't update) is still on OpenCL 1.0.
I checked on the \"public\" drivers on the net, the version is still 258.96 (the one I use), so I downloaded and installed the \"Developer Drivers for WinVista and Win7 (260.61)\" from
http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 (the page on which I download the CUDA Toolkit).
My OpenCL.dll file now provides the OpenCL 1.1 functions.
I tried to run poclbm.py, as m0mchil said there is a problem with the rotate function, but pyopencl seems to work*, that's a good point
* There are still some errors while running the tests provided with pyopencl, but I don't know if this is crucial.
Errors on rotate :
<program source>:204:2: error: no matching function for call to 'rotate'
sharound(D,E,F,G,H,A,B,C,R(61),0xA4506CEB);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<program source>:4:103: note: instantiated from:
#define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a,
19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}
^
<program source>:2:19: note: instantiated from:
#define rot(x, y) rotate(x, (uint)y)
^~~~~~
<built-in>:3025:26: note: candidate function
ulong16 __OVERLOADABLE__ rotate(ulong16, ulong16);
^
<built-in>:3024:25: note: candidate function
ulong8 __OVERLOADABLE__ rotate(ulong8, ulong8);
^
<built-in>:3023:25: note: candidate function
ulong4 __OVERLOADABLE__ rotate(ulong4, ulong4);
^
<built-in>:3019:25: note: candidate function
ulong2 __OVERLOADABLE__ rotate(ulong2, ulong2);
^
<built-in>:3018:25: note: candidate function
long16 __OVERLOADABLE__ rotate(long16, long16);
^
<built-in>:3017:24: note: candidate function
long8 __OVERLOADABLE__ rotate(long8, long8);
^
<built-in>:3016:24: note: candidate function
long4 __OVERLOADABLE__ rotate(long4, long4);
^
<built-in>:3012:24: note: candidate function
long2 __OVERLOADABLE__ rotate(long2, long2);
^
<built-in>:3011:25: note: candidate function
uint16 __OVERLOADABLE__ rotate(uint16, uint16);
^
<built-in>:3010:24: note: candidate function
uint8 __OVERLOADABLE__ rotate(uint8, uint8);
^
<built-in>:3009:24: note: candidate function
uint4 __OVERLOADABLE__ rotate(uint4, uint4);
^
<built-in>:3005:24: note: candidate function
uint2 __OVERLOADABLE__ rotate(uint2, uint2);
^
<built-in>:3004:24: note: candidate function
int16 __OVERLOADABLE__ rotate(int16, int16);
^
<built-in>:3003:23: note: candidate function
int8 __OVERLOADABLE__ rotate(int8, int8);
^
<built-in>:3002:23: note: candidate function
int4 __OVERLOADABLE__ rotate(int4, int4);
^
<built-in>:2998:23: note: candidate function
int2 __OVERLOADABLE__ rotate(int2, int2);
^
<built-in>:2997:27: note: candidate function
ushort16 __OVERLOADABLE__ rotate(ushort16, ushort16);
^
<built-in>:2996:26: note: candidate function
ushort8 __OVERLOADABLE__ rotate(ushort8, ushort8);
^
<built-in>:2995:26: note: candidate function
ushort4 __OVERLOADABLE__ rotate(ushort4, ushort4);
^
<built-in>:2991:26: note: candidate function
ushort2 __OVERLOADABLE__ rotate(ushort2, ushort2);
^
<built-in>:2990:26: note: candidate function
short16 __OVERLOADABLE__ rotate(short16, short16);
^
<built-in>:2989:25: note: candidate function
short8 __OVERLOADABLE__ rotate(short8, short8);
^
<built-in>:2988:25: note: candidate function
short4 __OVERLOADABLE__ rotate(short4, short4);
^
<built-in>:2984:25: note: candidate function
short2 __OVERLOADABLE__ rotate(short2, short2);
^
<built-in>:2983:26: note: candidate function
uchar16 __OVERLOADABLE__ rotate(uchar16, uchar16);
^
<built-in>:2982:25: note: candidate function
uchar8 __OVERLOADABLE__ rotate(uchar8, uchar8);
^
<built-in>:2981:25: note: candidate function
uchar4 __OVERLOADABLE__ rotate(uchar4, uchar4);
^
<built-in>:2977:25: note: candidate function
uchar2 __OVERLOADABLE__ rotate(uchar2, uchar2);
^
<built-in>:2976:25: note: candidate function
char16 __OVERLOADABLE__ rotate(char16, char16);
^
<built-in>:2975:24: note: candidate function
char8 __OVERLOADABLE__ rotate(char8, char8);
^
<built-in>:2974:24: note: candidate function
char4 __OVERLOADABLE__ rotate(char4, char4);
^
<built-in>:2970:24: note: candidate function
char2 __OVERLOADABLE__ rotate(char2, char2);
^
<built-in>:2967:24: note: candidate function
ulong __OVERLOADABLE__ rotate(ulong, ulong);
^
<built-in>:2966:23: note: candidate function
long __OVERLOADABLE__ rotate(long, long);
^
<built-in>:2965:23: note: candidate function
uint __OVERLOADABLE__ rotate(uint, uint);
^
<built-in>:2964:22: note: candidate function
int __OVERLOADABLE__ rotate(int, int);
^
<built-in>:2963:25: note: candidate function
ushort __OVERLOADABLE__ rotate(ushort, ushort);
^
<built-in>:2962:24: note: candidate function
short __OVERLOADABLE__ rotate(short, short);
^
<built-in>:2961:24: note: candidate function
uchar __OVERLOADABLE__ rotate(uchar, uchar);
^
<built-in>:2960:23: note: candidate function
char __OVERLOADABLE__ rotate(char, char);
^
Edit : I just see the rot function in poclbm.py (the one m0mchil was talking in fact I gess), I will try to see how to change the two rot functions, and perhaps bytereverse in btc_miner. cl ?
Edit2 : pfiuuu, it's hard !
first time I work on python and therefore on pyopencl, and using the nvidia toolkit. I don't even know from where the rotate functions come (the candidates functions), where are they defined (nividia toolkit, boost, standard c++, ... and from which include) ?
Edit3 : ...
I made some tries, and I don't succed for now:
Traceback (most recent call last):
File \"poclbm.py\", line 57, in <module>
miner = cl.Program(context, kernelFile.read()).build()
File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 138, in program_build
\"Build on %s:\n\n%s\" % (dev, log) for dev, log in build_logs))
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 9800 GT' at 0x2312eb8>:
Error: Code selection failed to select: 0x527c7f8: i32 = bswap 0x527cbb0
... I have no idea of what that means
(for this test I just change #define rot(x, y) rotate(x, (uint)y) to #define rot(x, y) rotate(x, (uint2)y) in btc_miner.cl, trying to make it running first before checking the operations made).
Edit 4 :
a \"funny\" thing, the problem I have come from the end of the function search in btc_miner.cl
If I remove those lines
if((H.x==0) && (bytereverse(G.x)<=target))
{
output[0] = 1;
output[1] = nonce.x;
}
if((H.y==0) && (bytereverse(G.y)<=target))
{
output[0] = 1;
output[1] = nonce.y;
}
the script is built without error and start.
If I leave the tests without output[n] = ... it builds, and if I leave output[n] = ... without the tests, it builds also.
but if I put the test and output[n] = ... I have the following error :
Traceback (most recent call last):
File \"poclbm.py\", line 57, in <module>
miner = cl.Program(context, kernelFile.read()).build()
File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 138, in program_build
\"Build on %s:\n\n%s\" % (dev, log) for dev, log in build_logs))
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce 9800 GT' at 0x2952eb8>:
Error: Code selection failed to select: 0x4f5a8d0: i32 = bswap 0x4f94670
Jef, at least it's now clear the problem is in the bytereverse(x) macro. Please try to replace it with:
uint bytereverse(const uint x)
{
uint result;
uchar* b = (uchar *)&x;
uchar* l = (uchar *)&result;
l[0] = b[3];
l[1] = b[2];
l[2] = b[1];
l[3] = b[0];
return result;
}
",
"nested_level": 0
},
{
"id": 3000,
"thread_id": 232,
"source_id": "81",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17530#msg17530",
"date": "2010-10-18T18:03:34Z",
"text": "Hello again, thanks for the code
but it still doesn't work
Nvidia doesn't like reversing numbers it seems
however, if I comments anyone of the four affectations, it builds
After trying by decomposing the reversing in many ways, I abandoned this path to bypass the problem.
I made a first version running with byte reversing and comparaisons made in the python script, and a second version with a function that make the comparison directly between a word and a reversed word in the OpenCl code. For now this version works only on big endian memory mapping (I hope it's what is used in the GPUs).
Note: I added somme print to the screen to show some informations when running the script.
I also let some comments in the code.
The two versions build and run without error, but I'm not sure that operations are correct.
As expected the second version is more effective (about 14800 khashs/sec with the 1st version, and 15200 khashs/sec with the 2nd version).
Version 1 : reversing and comparison in the python script
--- F:/Desktop/m0mchil-poclbm-cf33815/poclbm.py Fri Oct 15 08:48:48 2010
+++ F:/Desktop/m0mchil-poclbm-cf33815/poclbm_nv1.py Mon Oct 18 23:36:46 2010
@@ -21,6 +21,9 @@
t2=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b)))
return (uint32(d + t1), uint32(t1+t2))
+def bytereverse(x):
+ return (((x & 0x000000ffL) << 24) | ((x & 0x0000ff00L) << 8) | ((x & 0x00ff0000L) >> 8) | ((x & 0xff000000L) >> 24))
+
def sysWrite(format, args=()):
sys.stdout.write('\r \r' + format % args)
sys.stdout.flush()
@@ -50,16 +53,40 @@
context = cl.Context([devices[options.device]], None, None)
else:
print 'No device specified, you may use -d to specify one of the following\n'
+ # create_some_context should ask for the platform and device to use
context = cl.create_some_context()
+
+device = context.devices[0]
+print \"===============================================================\"
+print \"Platform name:\", platform.name
+print \"Platform profile:\", platform.profile
+print \"Platform vendor:\", platform.vendor
+print \"Platform version:\", platform.version
+print \"---------------------------------------------------------------\"
+print \"Device name:\", device.name
+print \"Device type:\", cl.device_type.to_string(device.type)
+print \"Device memory: \", device.global_mem_size//1024//1024, 'MB'
+print \"Device max clock speed:\", device.max_clock_frequency, 'MHz'
+print \"Device compute units:\", device.max_compute_units
+print \"===============================================================\"
+
queue = cl.CommandQueue(context)
-kernelFile = open('btc_miner.cl', 'r')
+kernelFile = open('btc_miner_nv1.cl', 'r')
miner = cl.Program(context, kernelFile.read()).build()
kernelFile.close()
+print \"===============================================================\"
+print \"build OK\"
+print \"===============================================================\"
+
if (options.worksize == -1):
options.worksize = miner.search.get_work_group_info(cl.kernel_work_group_info.WORK_GROUP_SIZE, context.devices[0])
+print \"===============================================================\"
+print \"worksize = \", options.worksize
+print \"===============================================================\"
+
frames = options.frames
frame = float(1)/frames
window = frame/30
@@ -75,7 +102,7 @@
work['extraNonce'] = 0
work['block'] = ''
-output = np.zeros(2, np.uint32)
+output = np.zeros(6, np.uint32)
while True:
try:
@@ -117,10 +144,12 @@
output_buf = cl.Buffer(context, mf.WRITE_ONLY | mf.USE_HOST_PTR, hostbuf=output)
rate = start = time()
+ success = 0
+ nonce = 0
while True:
- if (output[0]):
- work['block'] = work['block'][:152] + pack('I', long(output[1])).encode('hex') + work['block'][160:]
- sysWriteLn('found: %s, %s', (output[1], datetime.now().strftime(\"%d/%m/%Y %H:%M\")))
+ if (success):
+ work['block'] = work['block'][:152] + pack('I', long(nonce)).encode('hex') + work['block'][160:]
+ sysWriteLn('found: %s, %s', (nonce, datetime.now().strftime(\"%d/%m/%Y %H:%M\")))
break
if (time() - start > options.askrate or base + globalThreads == 0x7FFFFFFF):
@@ -131,8 +160,20 @@
base = 0x7FFFFFFF - globalThreads
kernelStart = time()
- miner.search(queue, (globalThreads, ), (options.worksize, ), block2[0], block2[1], block2[2], state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7], state2[1], state2[2], state2[3], state2[5], state2[6], state2[7], target[6], pack('I', base), output_buf)
+ miner.search(queue, (globalThreads, ), (options.worksize, ), block2[0], block2[1], block2[2], state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7], state2[1], state2[2], state2[3], state2[5], state2[6], state2[7], pack('I', base), output_buf)
cl.enqueue_read_buffer(queue, output_buf, output).wait()
+ #target = target[6]
+ #H.x = output[0] ; H.y = output[1]
+ #G.x = output[2] ; G.y = output[3]
+ #nonce.x = output[4] ; nonce.y = output[5]
+ if (output[0] == 0 and bytereverse(output[2])<=target[6]):
+ success = 1
+ nonce = output[4]
+
+ if (output[1] == 0 and bytereverse(output[3])<=target[6]):
+ success = 1
+ nonce = output[5]
+
kernelTime = time() - kernelStart
if (kernelTime < lower):
@@ -142,4 +183,4 @@
if (time() - rate > options.rate):
rate = time()
- sysWrite('%s khash/s', int((base / (time() - start)) / 500))
\\ No newline at end of file
+ sysWrite('%s : %s khash/s', (datetime.now().strftime(\"%d/%m/%Y %H:%M:%S\"),int((base / (time() - start)) / 500)))
\\ No newline at end of file
--- F:/Desktop/m0mchil-poclbm-cf33815/btc_miner.cl Fri Oct 15 08:48:48 2010
+++ F:/Desktop/m0mchil-poclbm-cf33815/btc_miner_nv1.cl Mon Oct 18 22:01:08 2010
@@ -1,5 +1,4 @@
-#define bytereverse(x) ( ((x) << 24) | (((x) << 8) & 0x00ff0000) | (((x) >> 8) & 0x0000ff00) | ((x) >> 24) )
-#define rot(x, y) rotate(x, (uint)y)
+#define rot(x, y) rotate(x, (uint2)y)
#define R(x) (work[x] = (rot(work[x-2],15)^rot(work[x-2],13)^((work[x-2])>>10)) + work[x-7] + (rot(work[x-15],25)^rot(work[x-15],14)^((work[x-15])>>3)) + work[x-16])
#define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}
@@ -8,7 +7,6 @@
const uint state4, const uint state5, const uint state6, const uint state7,
const uint B1, const uint C1, const uint D1,
const uint F1, const uint G1, const uint H1,
- const uint target,
const uint base,
__global uint * output)
{
@@ -209,17 +207,12 @@
G+=0x1f83d9ab;
H+=0x5be0cd19;
- if((H.x==0) && (bytereverse(G.x)<=target))
- {
- output[0] = 1;
- output[1] = nonce.x;
- }
-
- if((H.y==0) && (bytereverse(G.y)<=target))
- {
- output[0] = 1;
- output[1] = nonce.y;
- }
+ output[0] = H.x;
+ output[1] = H.y;
+ output[2] = G.x;
+ output[3] = G.y;
+ output[4] = nonce.x;
+ output[5] = nonce.y;
}
// end
\\ No newline at end of file
Version 2 : function that make the comparison between inversed and non inversed word
--- F:/Desktop/m0mchil-poclbm-cf33815/poclbm.py Fri Oct 15 08:48:48 2010
+++ F:/Desktop/m0mchil-poclbm-cf33815/poclbm_nv2.py Mon Oct 18 23:53:18 2010
@@ -50,16 +50,40 @@
context = cl.Context([devices[options.device]], None, None)
else:
print 'No device specified, you may use -d to specify one of the following\n'
+ # create_some_context should ask for the platform and device to use
context = cl.create_some_context()
+
+device = context.devices[0]
+print \"===============================================================\"
+print \"Platform name:\", platform.name
+print \"Platform profile:\", platform.profile
+print \"Platform vendor:\", platform.vendor
+print \"Platform version:\", platform.version
+print \"---------------------------------------------------------------\"
+print \"Device name:\", device.name
+print \"Device type:\", cl.device_type.to_string(device.type)
+print \"Device memory: \", device.global_mem_size//1024//1024, 'MB'
+print \"Device max clock speed:\", device.max_clock_frequency, 'MHz'
+print \"Device compute units:\", device.max_compute_units
+print \"===============================================================\"
+
queue = cl.CommandQueue(context)
-kernelFile = open('btc_miner.cl', 'r')
+kernelFile = open('btc_miner_nv2.cl', 'r')
miner = cl.Program(context, kernelFile.read()).build()
kernelFile.close()
+print \"===============================================================\"
+print \"build OK\"
+print \"===============================================================\"
+
if (options.worksize == -1):
options.worksize = miner.search.get_work_group_info(cl.kernel_work_group_info.WORK_GROUP_SIZE, context.devices[0])
+print \"===============================================================\"
+print \"worksize = \", options.worksize
+print \"===============================================================\"
+
frames = options.frames
frame = float(1)/frames
window = frame/30
@@ -142,4 +166,4 @@
if (time() - rate > options.rate):
rate = time()
- sysWrite('%s khash/s', int((base / (time() - start)) / 500))
\\ No newline at end of file
+ sysWrite('%s : %s khash/s', (datetime.now().strftime(\"%d/%m/%Y %H:%M:%S\"),int((base / (time() - start)) / 500)))
\\ No newline at end of file
--- F:/Desktop/m0mchil-poclbm-cf33815/btc_miner.cl Fri Oct 15 08:48:48 2010
+++ F:/Desktop/m0mchil-poclbm-cf33815/btc_miner_nv2.cl Mon Oct 18 23:33:50 2010
@@ -1,8 +1,88 @@
-#define bytereverse(x) ( ((x) << 24) | (((x) << 8) & 0x00ff0000) | (((x) >> 8) & 0x0000ff00) | ((x) >> 24) )
-#define rot(x, y) rotate(x, (uint)y)
+#define rot(x, y) rotate(x, (uint2)y)
#define R(x) (work[x] = (rot(work[x-2],15)^rot(work[x-2],13)^((work[x-2])>>10)) + work[x-7] + (rot(work[x-15],25)^rot(work[x-15],14)^((work[x-15])>>3)) + work[x-16])
#define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}
+// test 1 : recursive function, build error :
+// Error: Code selection failed to select: 0x504c1d8: i8 = NVPTXISD::MoveParam 0x504c150
+/*
+bool recurseReversedCompare(uchar *reversed, uchar *normal, uchar ir, uchar in)
+{
+ if(reversed[ir] > normal[in])
+ {
+ return false;
+ }
+ else if(reversed[ir] < normal[in])
+ {
+ return true;
+ }
+ else if(in > 0)
+ {
+ return recurseReversedCompare(reversed, normal, ir+1, in-1);
+ }
+ else
+ {
+ return true;
+ }
+}
+
+bool reversedSmallerThan(uint reversed, uint normal)
+{
+ uchar *r = (uchar *)&reversed;
+ uchar *n = (uchar *)&normal;
+
+ return recurseReversedCompare(r, n, 0, 3);
+}
+*/
+
+// test 2 : non recursive
+bool reversedSmallerThan(uint reversed, uint normal)
+{
+ uchar *r = (uchar *)&reversed;
+ uchar *n = (uchar *)&normal;
+
+ if(r[0] > n[3])
+ {
+ return false;
+ }
+ else if(r[0] < n[3])
+ {
+ return true;
+ }
+ else
+ {
+ if(r[1] > n[2])
+ {
+ return false;
+ }
+ else if(r[1] < n[2])
+ {
+ return true;
+ }
+ else
+ {
+ if(r[2] > n[1])
+ {
+ return false;
+ }
+ else if(r[2] < n[1])
+ {
+ return true;
+ }
+ else
+ {
+ if(r[3] > n[0])
+ {
+ return false;
+ }
+ else
+ {
+ return true;
+ }
+ }
+ }
+ }
+}
+
__kernel void search( const uint block0, const uint block1, const uint block2,
const uint state0, const uint state1, const uint state2, const uint state3,
const uint state4, const uint state5, const uint state6, const uint state7,
@@ -209,13 +289,13 @@
G+=0x1f83d9ab;
H+=0x5be0cd19;
- if((H.x==0) && (bytereverse(G.x)<=target))
+ if((H.x==0) && reversedSmallerThan(G.x, target)) // (bytereverse(G.x)<=target)
{
output[0] = 1;
output[1] = nonce.x;
}
- if((H.y==0) && (bytereverse(G.y)<=target))
+ if((H.y==0) && reversedSmallerThan(G.y, target)) // (bytereverse(G.y)<=target)
{
output[0] = 1;
output[1] = nonce.y;
There are probably some optimisations to make
Thanks Jef! There is new version that should work on Nvidia now. I also changed default getwork request rate to 5 seconds to reduce the risk of solving stale block. The patch itself has now one more check to not show 'proof of work found' in this case.
Can someone with Nvidia please test this, it should resolve the 'code selection failed to select' issue.
",
"nested_level": 0
},
{
"id": 3002,
"thread_id": 232,
"source_id": "83",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17626#msg17626",
"date": "2010-10-19T16:27:11Z",
"text": "you\u2019re welcome
Thank you for your better code design than mine
The new code you provided runs on my computer.
you\u0092re welcome
The new code you provided runs on my computer.
OpenCL-wise it seems to work fine on my 9400 GT, now I just have trouble compiling bitcoind
you\u0092re welcome
The new code you provided runs on my computer.
OpenCL-wise it seems to work fine on my 9400 GT, now I just have trouble compiling bitcoind
Ah, it worked it was just using another port.
I knew the 9400 GT would be slow relative to other cards, but maybe not this slow: I get 1800kh/s, which is slower than my cpu =)
I was hoping to maybe double performance, but oh well.
Only 1800kh/s ? It seems very low in comparison to my 9800 GT which give me about 15200 kh/s
Perhaps for some strange reason your GPU is not fully used, if your graphical card gives you this information you can check the GPU load with GPU-Z, in the \"Sensors\" tab (
http://www.techpowerup.com/gpuz/).
9400GT 16SPs @ 1.4GHz
9800GT 112SPs @ 1.5GHz
-> a 9800GT is about 7.5x 9400GT ...
",
"nested_level": 0
},
{
"id": 3007,
"thread_id": 232,
"source_id": "88",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17795#msg17795",
"date": "2010-10-20T18:08:23Z",
"text": "ah ... yes, I didn't check that before talking
1800 * 7.5 = 13500 ... no so far than my 15200 ... logical then in fact.
Hi there!
Trying to use this, but here is the error I see:
D:\\pycuda>poclbm.exe
No device specified, you may use -d to specify one of the following
Traceback (most recent call last):
File \"poclbm.py\", line 58, in <module>
File \"pyopencl\\__init__.pyc\", line 138, in program_build
pyopencl.RuntimeError: clBuildProgram failed: build program failure
Build on <pyopencl.Device 'GeForce GTX 470' at 0x2d112d8>:
:52: error: incompatible type assigning 'int', expected 'uint2'
work[5]=0x00000000;
^~~~~~~~~~~
:53: error: incompatible type assigning 'int', expected 'uint2'
work[6]=0x00000000;
^~~~~~~~~~~
:54: error: incompatible type assigning 'int', expected 'uint2'
work[7]=0x00000000;
^~~~~~~~~~~
:55: error: incompatible type assigning 'int', expected 'uint2'
work[8]=0x00000000;
^~~~~~~~~~~
:56: error: incompatible type assigning 'int', expected 'uint2'
work[9]=0x00000000;
^~~~~~~~~~~
:57: error: incompatible type assigning 'int', expected 'uint2'
work[10]=0x00000000;
^~~~~~~~~~~
:58: error: incompatible type assigning 'int', expected 'uint2'
work[11]=0x00000000;
^~~~~~~~~~~
:59: error: incompatible type assigning 'int', expected 'uint2'
work[12]=0x00000000;
^~~~~~~~~~~
:60: error: incompatible type assigning 'int', expected 'uint2'
work[13]=0x00000000;
^~~~~~~~~~~
:61: error: incompatible type assigning 'int', expected 'uint2'
work[14]=0x00000000;
^~~~~~~~~~~
:62: error: incompatible type assigning 'int', expected 'uint2'
work[15]=0x00000280;
^~~~~~~~~~~
:141: error: incompatible type assigning 'int', expected 'uint2'
work[9]=0x00000000;
^~~~~~~~~~~
:142: error: incompatible type assigning 'int', expected 'uint2'
work[10]=0x00000000;
^~~~~~~~~~~
:143: error: incompatible type assigning 'int', expected 'uint2'
work[11]=0x00000000;
^~~~~~~~~~~
:144: error: incompatible type assigning 'int', expected 'uint2'
work[12]=0x00000000;
^~~~~~~~~~~
:145: error: incompatible type assigning 'int', expected 'uint2'
work[13]=0x00000000;
^~~~~~~~~~~
:146: error: incompatible type assigning 'int', expected 'uint2'
work[14]=0x00000000;
^~~~~~~~~~~
:147: error: incompatible type assigning 'int', expected 'uint2'
work[15]=0x00000100;
^~~~~~~~~~~
:149: error: incompatible type assigning 'int', expected 'uint2'
A=0x6a09e667;
^~~~~~~~~~~
:151: error: incompatible type assigning 'int', expected 'uint2'
C=0x3c6ef372;
^~~~~~~~~~~
:153: error: incompatible type assigning 'int', expected 'uint2'
E=0x510e527f;
^~~~~~~~~~~
:155: error: incompatible type assigning 'int', expected 'uint2'
G=0x1f83d9ab;
^~~~~~~~~~~
:156: error: incompatible type assigning 'int', expected 'uint2'
H=0x5be0cd19;
Wish I were smart enough to understand what that means!
Any ideas?
Hello, it is the errors I had when running poclbm from poclbm_py2exe.7z with the original OpenCL.dll inside.
The 7z archive contains the dll from the ATI driver, so using an nvidia card I had to replace this dll by the one provided by my nvidia driver which is in C:\\Windows\\System32\\
Is it your case, executing poclbm from the package poclbm_py2exe.7z ?
The things I had to do for using poclbm :
- building pyopencl for my system, I installed the latest CUDA Toolkit from here
http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 to build pyopencl.
- using the latest driver (Developer Drivers) from here
http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 , I had the following errors without that :
ImportError: DLL load failed: La proc\u00dadure sp\u00dacifi\u00dae est introuvable.
- using the latest version of poclbm from
http://github.com/m0mchil/poclbm , a correction has been made to make poclbm running on nvidia GPU without errors
Can someone give direct links to
NVIDIA OpenCL 1.1 drivers?
I didn't success to found a link to this driver (and I found two cd iso on bittorent, but I don't try to get them) ...
But Nvidia has apparently merge his OpenCL implementation in his CUDA Toolkit and drivers. The latest \"Developer Drivers\" from the \"CUDA Toolkit 3.2 RC\" page contains an OpenCL 1.1 compliant* driver (it is the one I use).
*at least concerning the openCL 1.1 functions needed by pyopencl
http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.htmlScroll down in the page to found the drivers for windows, linux (some distributions), and MacOS)
Note : GPU Caps Viewer shows me OpenCL 1.0, but it works anyway.
bitcoin-getwork-svn170-win32.7zpoclbm_win32_exe.7z Wrong kernel was packed in the py2exe version, now fixed. Removed AMD OpenCL.dll to prevent conflicts.
I also reverted back to scalars. With vectors it was faster, but required hardware specific tweaks and was making it slower for others. Unfortunately OpenCL is not mature enough to provide means of automatic performance optimization.
",
"nested_level": 0
},
{
"id": 3013,
"thread_id": 232,
"source_id": "94",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17915#msg17915",
"date": "2010-10-21T15:02:13Z",
"text": "seems to work now on my GTX260
hashcount results are similar to puddinpops cuda-code,
both get around 45Mhash/s.
C:\\Documents and Settings\\Administrator\\Desktop\\bitcoin_stuff\\OpenCL\\poclbm_win3
2_exe>poclbm --user=*** --pass=***
No device specified, you may use -d to specify one of the following
44120 khash/s
I'm not sure if and whats going wrong, i started bitcoin in server mode. start poclbm with user and pass, then it shows khash/s for about 5 seconds then pops back to asking username and pass. i can keep doing that over and over.
",
"nested_level": 0
},
{
"id": 3015,
"thread_id": 232,
"source_id": "96",
"poster_name": "kwukduck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=654",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17939#msg17939",
"date": "2010-10-21T20:15:51Z",
"text": "tnx, working fine now, forgot the username.
On my other pc i get this error \"ImportError: DLL load failed: The specified module could not be found.\"
I already updated to latest graphics drivers and nvidia cuda toolkit..
Geforce 9800 GX2 @ win7 32 bit
i also noticed that the old puddingpop cuda client only puts out 2000khash/s on that gpu... i should get at least ten times as much...
any ideas?
",
"nested_level": 0
},
{
"id": 3016,
"thread_id": 232,
"source_id": "97",
"poster_name": "jef.blanc",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1928",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg17943#msg17943",
"date": "2010-10-21T20:43:18Z",
"text": "hum, you can check with dependency walker (
http://www.dependencywalker.com/) that your OpenCL.dll file (in C:\\Windows\\System32\\) provides the OpenCL 1.1 functions needed by pyopencl :
clCreateSubBuffer
clCreateUserEvent
clEnqueueCopyBufferRect
clEnqueueReadBufferRect
clEnqueueWriteBufferRect
clSetUserEventStatus
If not, then either the driver installation has failed, or it is not the good driver.
Otherwise ... I don't know
Edit : you can check with GPU Caps Viewer if this GPU really manage OpenCL, because 2000 kh/s is what is currently made by the CPU alone.
The Geforce 9800 GX2 is if I'm rigth two 8800 GTX functionning in pair, not sure that they manage OpenCL.
Hi,
First, thanks for this wonderful miner.
I managed to make it work on linux (lib64 only) with a 8600 GT
(A bit disappointed about my card performance though: 5300kh/s)
:52: error: incompatible type assigning 'int', expected 'uint2'
work[5]=0x00000000;
^~~~~~~~~~~
Any ideas?
Got this error too, just put some \"u\"s at the end of all these uint constants. Example:
work[5]=0x00000000u;
Just pulled a fresh version and got this:
$ python2.6 poclbm.py -u l29ah --pass=hackme
No device specified, you may use -d to specify one of the following
Traceback (most recent call last):
File \"poclbm.py\", line 133, in <module>
target[6], pack('I', base), output_buf)
File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call
self.set_arg(i, arg)
TypeError: expected a readable buffer object
",
"nested_level": 0
},
{
"id": 3019,
"thread_id": 232,
"source_id": "100",
"poster_name": "gim",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1884",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18166#msg18166",
"date": "2010-10-23T10:00:53Z",
"text": " File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call
self.set_arg(i, arg)
TypeError: expected a readable buffer object
Upgrade to pyopencl-0.92.
File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call
self.set_arg(i, arg)
TypeError: expected a readable buffer object
Upgrade to pyopencl-0.92.
Thank you! Getting 31MH/s from GeForce 9800 GTX if run with -f 10.
It finally work on my side !
Without optimisation, I got around 265000 khash/sec. I got an i7 920 oc to 3.6ghz with a radeon 5970. I'm gonna look to do some tweak to speed up this thing a bit
If you have any comment or something you want me to try don't hesitate. By the way, I've been running this thing tonight, and in 8 hours, my wallet is still at 0. Is it normal ? Do I need to restart it? Or it's just like the way it should work, which mean it's still pretty long to generate? Thanks for your OpenCL gui Moo, I really appreciate it !
Malouin
P-S I think I only got 265000 khash/sec on my 5970 because i'm only using 1 heart. When I'm at the point I need to choose the device, I see 3 option, 0 = my cpu, and 1 and 2 is the same thing. is it possible ?
265 mhps?
Yes, just took you a screenshot
http://static/img835.imageshack.us/static/img835/2157/bitcoin.jpgI'm pretty sure I can get the 500 by using my 2 heart, or maybe i'm totally wrong XD
Malouin
The 4 that you see was just after I finished installing it. It was still downloading block. About the public or the test, I supose i'm on the public network. I simply did the bitcoin -server, and started the poclbm. While I was reading, I heard about a shared pool. Is it really that good ? If you have any info you can help me don't hesitate, I'm open to anything =) Btw i'm on irc ( Malouin ) presently if you wanna talk !
Malouin
",
"nested_level": 0
},
{
"id": 3025,
"thread_id": 232,
"source_id": "106",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18198#msg18198",
"date": "2010-10-23T14:53:57Z",
"text": "I see
Thanks for the info and for the help david, I really appreciate it. If you want me to do some test or help you on something, don't hesitate.
Malouin
",
"nested_level": 0
},
{
"id": 3026,
"thread_id": 232,
"source_id": "107",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18218#msg18218",
"date": "2010-10-23T16:43:32Z",
"text": "The miner should display 'bitcoin is downloading blocks...' until all blocks are downloaded. Please test. This was added in the SVN 163 patched client.
David, I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all.
",
"nested_level": 0
},
{
"id": 3027,
"thread_id": 232,
"source_id": "108",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18224#msg18224",
"date": "2010-10-23T16:59:26Z",
"text": "From now on I'll post latest versions only in the initial post of this thread.
",
"nested_level": 0
},
{
"id": 3028,
"thread_id": 232,
"source_id": "109",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18229#msg18229",
"date": "2010-10-23T17:51:00Z",
"text": "Tried the -f 35 and -w 128. I get around 270m khash/s. And yes, I can load 2 separate poclbm, using device 1 and device 2, both are doing around 268m khash/s. Total of 536m khash/s.
And yes, it display the bitcoin is downloading blocks... Thanks !
Malouin
",
"nested_level": 0
},
{
"id": 3029,
"thread_id": 232,
"source_id": "110",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18247#msg18247",
"date": "2010-10-23T18:57:37Z",
"text": "Update : I Oc'ed my 5970 GPU clock from 725 MHZ to 800 MHZ and my memory clock from 1000 to 1305MHZ.
I'm now at 295m on each heart, total of 590m. Everything seem to be fine, I will let you know about futur update and how much I can get with the 5970.
Malouin
",
"nested_level": 0
},
{
"id": 3030,
"thread_id": 232,
"source_id": "111",
"poster_name": "LZ",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=462",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18260#msg18260",
"date": "2010-10-23T21:21:08Z",
"text": "",
"nested_level": 0
},
{
"id": 3031,
"thread_id": 232,
"source_id": "112",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18279#msg18279",
"date": "2010-10-24T03:31:59Z",
"text": "hehehe thanks guys =P
I was speaking with Art on irc today, and my next step will be to OC my 5970 from 800 to 910mhz. I should reach the 320mhash/s on each heart, which mean a big total of 640mhash/s.
I restarted my client at 15h30 EAST time, and will stop it tomorrow at the same time. It gonna give me some data to work on. After that, i'm going to OC it at 910mhz and see the result and report here with some screenshots.
Malouin
",
"nested_level": 0
},
{
"id": 3032,
"thread_id": 232,
"source_id": "113",
"poster_name": "bethel",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=949",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18297#msg18297",
"date": "2010-10-24T07:02:35Z",
"text": "bethel, what are 5870s showing at stock frequency (850 MHz)? Perhaps one of the cards throttles down?
Latest version has new parameter, -w, to set work group size. I have best results on 5770 with -w 128 -f 35.
Latest py2exe version is
http://github.com/downloads/m0mchil/poclbm/poclbm.7zSorry for the late reply, I have been away for a while.
I found my problem and it was so simple it is silly. I had not yet enabled the -frames switch to crunch faster. I still don't know why one card was faster without the switch but they are about equal now.
As for the mhash @ 850mhz I get about 265mhps.
Tried the -f 35 and -w 128. I get around 270m khash/s. And yes, I can load 2 separate poclbm, using device 1 and device 2, both are doing around 268m khash/s. Total of 536m khash/s.
And yes, it display the bitcoin is downloading blocks... Thanks !
Malouin
xxmalouinxx, what OS, SDK, and driver version are you on?
I can't seem to get my two cards to both run at the same time under Windows 7. Any hints?
Windows 7 Ultimate / ATI SDK 2.2 for Win7 64 / Catalyst 10.7
I got a radeon 5970, so I don't have 2 cards, but 2 hearts on it. Art got 4 cards on 1 motherboard doing this, I'm gonna ask him when I see him.
Malouin
",
"nested_level": 0
},
{
"id": 3035,
"thread_id": 232,
"source_id": "116",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18363#msg18363",
"date": "2010-10-24T20:52:07Z",
"text": "Update :
Here's a screenshot of my last setting
http://static/img143.imageshack.us/static/img143/2157/bitcoin.jpg640mhash/s - radeon 5970 870mhz/1305mhz - temp : 83c
Presently it run fine, but i'm not sure it gonna be stable, gonna update here if I have any news.
Malouin
I want it!
incredible hashes/sec are incredible
do you think a Radeon 5970 would work fine with linux ?
",
"nested_level": 0
},
{
"id": 3038,
"thread_id": 232,
"source_id": "119",
"poster_name": "fergalish",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=39",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18460#msg18460",
"date": "2010-10-25T10:47:52Z",
"text": "core i7 quad, nvidia GT240, 64bit ubuntu 10.04
CPU: 7000 khps
GPU: 20000 khps
Should I be getting more? I have python 2.6.5 installed.
",
"nested_level": 0
},
{
"id": 3039,
"thread_id": 232,
"source_id": "120",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18466#msg18466",
"date": "2010-10-25T11:10:49Z",
"text": "Davout : Yea it should work without any problem on linux. ArtForz actually use that.
Fergalish : the Nvidia GT240 got 385 Gflops, the radeon 5970 got 4640. If we base it on the fact that the 5970 got 230 000khash/s per core without being OC, it should be around 20 000 khash/s yes.
Malouin
",
"nested_level": 0
},
{
"id": 3040,
"thread_id": 232,
"source_id": "121",
"poster_name": "sturle",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1876",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18469#msg18469",
"date": "2010-10-25T12:19:09Z",
"text": "Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4885 sturle 20 0 420m 56m 26m S 264 0.7 53:15.06 bitcoin
5522 sturle 20 0 231m 63m 24m S 97 0.8 9:44.01 poclbm.py
14130 root 20 0 491m 174m 122m S 27 2.2 12:25.19 Xorg
I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores. While poclbm.py is running, hash production from bitcoin is reduced to about 8k. Is this normal? Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.
GPU is some ATI HD 5400 series.
I think it's a really good thing that such a client gets public, it decreases the chance that the blockchain gets overtaken by NSA XD
",
"nested_level": 0
},
{
"id": 3042,
"thread_id": 232,
"source_id": "123",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18514#msg18514",
"date": "2010-10-25T18:31:52Z",
"text": "core i7 quad, nvidia GT240, 64bit ubuntu 10.04
CPU: 7000 khps
GPU: 20000 khps
Should I be getting more? I have python 2.6.5 installed.
compared to my GTX260 which gets ~37.000 stock (575core/1240shader) and up to 45.000 oc'd (685/1480),
you should be ok with 20.000.
gonna run it on a radeon 5850 as soon as it arrives, should be by tomorrow.
hopefully i'll get some more outof that.
640mhash/s - radeon 5970 870mhz/1305mhz - temp : 83c
Presently it run fine, but i'm not sure it gonna be stable, gonna update here if I have any news.
Malouin
What are your -frames and -worksize arguments like? Also what -askrate interval do you have?
I did get two cards working (had to use the crossfirex cable and enable crossfirex).
The thing that baffles me is how to get the same performance out of two cards together as I got out of two cards seperately. It seems if i set the frames very low like -frames=2 I can get one card to do about 97% gpu capacity. The other card, however drops to 60-80%. When I make the frames high like 256 it does ok but any other program on my machine seems to have a higher priority and will make poclbm.exe run slow.
Currently the best compromise I found was
--frames=25 --rate=3 --worksize=256 --device=1 --askrate=30
On a single core processor machine this produces about 90% on each card average but has wild swings.
For a while I thought the issue was my MB or CPU not feeding the data fast enough but I tried the cards in my gaming machine with a quad core and dual x16PCIe slots and it still was about the same.
Any ideas?
A quick question, I have had the miner running, if found a \"found: 339339279, 26/10/2010 06:27\" however, the coins for that block haven't been added to my bit coin wallet... Have I missed something, or is my wallet corrupt or something?
I have had non open-cl coins generated, maybe my node isn't announcing the newly found block, It dose say 8 connections..
",
"nested_level": 0
},
{
"id": 3045,
"thread_id": 232,
"source_id": "126",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18564#msg18564",
"date": "2010-10-26T01:14:57Z",
"text": "bethel : -f 35 and -w 128 . I don't have any rate or askrate variable.
da2ce7 : If you started to generate before having all the block downloaded, then the block you found isn't valid. Restart your client and start to generate once you got all the block. This happened to me too, david explained it to me pretty well =)
Malouin
",
"nested_level": 0
},
{
"id": 3046,
"thread_id": 232,
"source_id": "127",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18569#msg18569",
"date": "2010-10-26T01:25:44Z",
"text": "do you need to have they client generating at the same time as the open-cl miner?
",
"nested_level": 0
},
{
"id": 3047,
"thread_id": 232,
"source_id": "128",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18593#msg18593",
"date": "2010-10-26T02:03:05Z",
"text": "Nop, my bitcoin client don't generate from CPU.
",
"nested_level": 0
},
{
"id": 3048,
"thread_id": 232,
"source_id": "129",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18650#msg18650",
"date": "2010-10-26T11:52:32Z",
"text": "HD5850 just arrived and gets a whopping ~235.000khash/s stock, very nice indeed.
that's 5 times a GTX260 oc'd at nearly the same power consumption (~200W),
it's actually a few watts less on the HD5850, still room to oc it a 'lil.
some updates:
ran fine througout the day so i did some more testings,
right now i'm up to 267.000 with default poclbm-settings*,
the core clocked at 825MHz (stock 725MHz) doesn't even get close to hot,
stock <63\u00b0C vs. current <66\u00b0C, it's fan is still
idle,
with a bit of luck it might even break 300Mhash, but i'm more than pleased for now.
this card is well worth its money.
* ~270.000 with frames=10, desktop gets kinda unusable then though, but if i dont need it anway there's some extra Mhs to gain
woot! and just as i write this i generated my first OpenCL block!
it no longer just
seems to work,
it really does.
Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?
I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores. While poclbm.py is running, hash production from bitcoin is reduced to about 8k. Is this normal? Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.
GPU is some ATI HD 5400 series.
OpenCL can run on CPUs, too. It seems like that's what is happening. Maybe. Does poclbm ask you to choose your device when you start it?
My CPU usage is <5% for poclbm, so something's wrong.
Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?
I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores. While poclbm.py is running, hash production from bitcoin is reduced to about 8k. Is this normal? Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.
GPU is some ATI HD 5400 series.
OpenCL can run on CPUs, too. It seems like that's what is happening. Maybe. Does poclbm ask you to choose your device when you start it?
My CPU usage is <5% for poclbm, so something's wrong.
poclbm.py is instructed to use the video card, not the CPU. If I choose both (0,1), it uses 400% CPU for only 4 khash/s.
cProfile on poclbm.py overnight, and here is the function hogging my CPU:
2549577 85597.463 0.034 85597.463 0.034 __init__.py:284(event_wait)
This is defined in pyopencl:
def event_wait(self):
wait_for_events([self])
return self
Some kind of active wait loop in wait_for_events?
Btw -- polcbm.py claims to have found two blocks since it started, but only one is registered in my bitcoin client. :-/
$ nice -n 15 ./poclbm.py --user=******** --pass=******** -f 60 -w 256
No device specified, you may use -d to specify one of the following
found: 46380061, 26/10/2010 14:46
found: 46380061, 26/10/2010 14:46
17616 khash/s
Found this just now. Why did it find the same block twice? Could it be there are, oh, like two threads repeating the same work?
EDIT: also, the main bitcoin client credited me with 50btc, one block, at 14:45. Total to my credit is just one block 50btc. What's going on? I looked through the source, and the RPC commands list. Where does the source poclbm.py tell the bitcoin client that it found a hash below the target? (I'm a python newbie).
",
"nested_level": 0
},
{
"id": 3052,
"thread_id": 232,
"source_id": "133",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18833#msg18833",
"date": "2010-10-27T12:36:59Z",
"text": "can't help you with that one, the 2 blocks i found so far just showed up once,
but i'v got another update on the HD5850.
the core is up to 910MHz now (from 725@stock), which gives me ~297.000 khashes at default poclbm settings.
system needs ~230W now, plus ~15% power to get plus ~25% hashes, still a good deal.
seems like that's it for
basic catalystcc oc'ing, maybe a bit more using higher voltages/other tools, but i'm fine with it.
to satisfy your screeny-fetishmornin' miners, up for another update?
here we go...
short version:
HD5850 300.000 khash/s @ 925MHz
long version:
i did some more testings and tweaks and finally reached my goal,
to break the 300M-barrier while keeping below 70\u00b0C (setting higher voltages would not only consume more energy, as a result it'll also create noise which i really don't like).
while Catalysts (and others) tests fail at clocksets above 910MHz, the pocl-miner doesnt care much about it, it runs fine up to 935MHz, more and the miner starts to get
laggy and just starting the GPU Caps Viewer crashes the system (not if it's already running).
to stay safe i set it to 925MHz, which still gives hangups and failures in tests, Fallout:New Vegas doesn't even start, stuff like that,
but the miner runs fine, stable and averages at above 300Mhash/s.
i think i'll keep it like that and just set it to defaults to kill Mr.House and save (or rule?) the world, that old guy kinda scares me.
however,
the ordinary screenshot this time is also a nice comparison of both of my OpenCL-capable Cards, funny that both of 'em found a block within 1hour.
to the left (via vnc) we see a GTX260@685MHz at work, mining 45.000 khash/s on win7x64,
to the right her greatness HD5850@925MHz, mining 300.000 khash/s on xp64.
not to mention that theres still 5x2-3GHz CPUs left on those 2 machines that don't do anything right now, but hey, i'd get what, ~1000 khash/s per core? on the HD-miner that's <1%! and it'll also create more heat and noise and will need more energy too,
i'd rather tweak the card/s a little more.
but i think i'm done now and more than happy, hell i'm thrilled by those results, never thought the card would go that far.
what do you think?
how's your machine/s working?
tell us about it, we wanna know, well at least i do.
have a great day.
Well, I recently stopped mining on my CPUs. Really no reason for that anymore it seems =)
",
"nested_level": 0
},
{
"id": 3055,
"thread_id": 232,
"source_id": "136",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg18976#msg18976",
"date": "2010-10-28T08:52:54Z",
"text": "nah, i wouldn't say that,
the bitcoin-randomizer-node only runs at ~800khash/s on a single core and still generates blocks every now and then,
i even got miners running on an intel-Atom and PIII-1GHz that just get ~250khash/s.
you just need some more luck, any single hash could be the one we'r all looking for.
if your running a GPU-miner anyway though, there's at least on midclass-ati-cards no real need to run CPUs, they'll consume more power than needed to get what you want. give your gfx-core another 1-2% speed and your done, this'll take ~5W+ instead of >50W+ for CPUs@full throttle.
if your thinking about, or going to build a new miner-machine, i agree,
don't bother with CPUs, nor with nvidia.
careful though if you buy new stuff, dont get one of those shiny new HD6850/70, or you'll be dissapointed.
Hey Bitlex !
I'm happy to see that everything's going well on your side =) I'm presently at 650-660mhash/s with my radeon 5970
Setting : 900mhz/1000 memory clock/ vcore to 1.15v / Temps : 78c, with 100% fan on. I use this command :
--user=***** --pass=***** -f 35 -w 128
You should try to add the -f 35 -w 128 and see how many % you gain. I gained around 20-30mhash with that.
Malouin
",
"nested_level": 0
},
{
"id": 3057,
"thread_id": 232,
"source_id": "138",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19048#msg19048",
"date": "2010-10-28T18:36:00Z",
"text": "yeah, that's why i didn't use it
... I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all.
and i havent been compiling any miners myself (tried a few times but had no luck so far installing all required components on x64), so grabbing code x from y to patch z wouldn't help me much.
i'm just a user anyway, not a coder (php-scripter for fun, but that's it),
one could say
i represent the masses (at least those that are interested in how it works), that's why i'm so happy that there's a few nice people to realease binaries.
playing around with frames just gives me a ~1-2% increase, not really worth mentioning and for the cost of a very low responding desktop.
@m0mchil: you should really put your btc-address either into the initial post of this thread, or your sig, kinda hard to find already and will get even worse over time.
Can anyone post a walkthrough on how to install this (and any dependencies) on Ubuntu? Or post a Linux binary? I have a Tesla I'm dying to try out.
",
"nested_level": 0
},
{
"id": 3059,
"thread_id": 232,
"source_id": "140",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19259#msg19259",
"date": "2010-10-30T00:15:13Z",
"text": "i noticed some strange
disconnections lately,
everything seems alright, but it somehow hangs and doesnt get new blocks,
happens while
connected un-forwarded (showing 8connections),
-connect=<forwarded-nodes-ip> (showing 1connection),
-addnode=<forwaded-nopdes-ip> (showing 8connections),
forwarded-node has 50<80connections and seems to always have all blocks, other nodes sometimes just don't get them, no matter how i connect them.
not sure yet what's causing this, a feature to
force getblock or somethin' would be handy sometimes.
but this made me try to set up both OpenCL miners to run on one node.
starting the (former GTX-only) node with -rcpallowip, connection and mining works fine,
eatin' a few Mhashes though.
while running the (remote) HD-miner at defaults (askrate=5), the (local) GTX-miner slows down from ~45M to ~43M average, setting (remote) askrate=10 helped here, still a noticable but <1M loss,
the HD-miner also goes down ~2%, from 300 to 294.
tested on 100MBit, maybe there's <2% loss on gigabit networks, i'll try as soon as i find someone to pay for some switches and cards.
happy crunching
and if anyone knows of, or finds a solution to that spooky non-forwarded-node-disconnects, let me know, thanks.
while running standalone, non-forwarded, it's 8connections
while addnode'd, it's 8connections,
while connect'ed to forwarded node, it's only one.
what also might help is just running on different (but forwarded) ports,
as mentioned before silly me isn't able to compile/patch, so i'm not able to try yet.
",
"nested_level": 0
},
{
"id": 3061,
"thread_id": 232,
"source_id": "142",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19267#msg19267",
"date": "2010-10-30T01:46:16Z",
"text": "i usually start 'em all using addnode, these
getblock-lags just happened quite often lately, so i tried using the connect-switch,
here's a screeny* of 2 nodes seem to be connected to forwarded-node, both show only 1 connection, the higher blockcount is, the lower isn't, it sometimes even tells me, drops to 0connections for a sec, then back to 1, but still doesnt get any new blocks.
same happens when both are
addnode'd and showing 8connections, connections drop below 8 and no more blocks are downloaded, mining doesnt stop though, lots of wasted energy, at least it's green.
* from front to back
- GPU mining to (addnode'd) remote node (not on screen)
- HD-miner-node -connect=<ip> (idle)
- a random node -connect=<ip> (idle, running in VM)
about half an hour after the shot was taken, the random node still hasnt loaded any blocks,
it's not that it's always the VM that lags blocks though, sometimes it's the other way around.
here's another
unusual behaviour, a lost block.
the GTX-miner found 2blocks, both show the
proof-of-work found...generated 50.00 in the debug.log,
but it seems only one of them made it into my wallet.
",
"nested_level": 0
},
{
"id": 3063,
"thread_id": 232,
"source_id": "144",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19327#msg19327",
"date": "2010-10-30T16:36:29Z",
"text": "yeah, i also noticed that some blocks need some time to show up,
i already restarted bitcoin, hoping it might materialize somehow,
but it didn't.
first time i noticed this, hopefully the last too.
...about deleting the block chain, and having the client re download it to see if it adds that block....
i just tried not a completely new, but <80.000blocks chain and re-downloading,
the block is still missing.
The block won't show up. This happens when the network discovered block just after last request for work by the miner. This is the drawback of the pull manner in which getwork... works. The probability for this to happen is 1/60 with ask rate of 10 seconds and 1/120 with ask rate of 5 seconds. It will be better if work is provided in 'push' manner, but I didn't want to complicate the client with separate server thread.
",
"nested_level": 0
},
{
"id": 3066,
"thread_id": 232,
"source_id": "147",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19355#msg19355",
"date": "2010-10-30T22:00:26Z",
"text": "ok, thanks,
so it's nothing to worry about, no big deal anyway, GTX already found a new one,
she's lucky lately.
I was generating some blocks today on a 5970 and I noticed that both instances of the the miner claimed to have found the same block (see attached image) The main bitcoin client only counts them once (as it should.) Does anyone know what is happening? I am running with default settings and -f 30.
",
"nested_level": 0
},
{
"id": 3068,
"thread_id": 232,
"source_id": "149",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19376#msg19376",
"date": "2010-10-31T06:23:39Z",
"text": "Well, this is not good. I will take a look to figure it out.
",
"nested_level": 0
},
{
"id": 3069,
"thread_id": 232,
"source_id": "150",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19380#msg19380",
"date": "2010-10-31T08:17:19Z",
"text": "Sorry guys, I screwed it with the update to SVN 170. There is a bug in getwork patch that makes poclbm useless with more than a single instance. Until this is fixed anyone using more than one instance should use previous version of the patch (against SVN 166). Win32 binary
bitcoin-getwork-svn166-win32.7zHey, anyone interested in discussing mining, especially with this miner, please join us in #bitcoin-mining on freenode IRC.
I think it'd be a good idea for everyone to be on the same page, and currently most of the mining discussion is happening in #bitcoin-dev, which may not be appropriate.
",
"nested_level": 0
},
{
"id": 3071,
"thread_id": 232,
"source_id": "152",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19483#msg19483",
"date": "2010-11-01T10:15:50Z",
"text": "Just fixed problem with getwork (different miners were showing same results). Updated to SVN 173. See for windows build in first post.
",
"nested_level": 0
},
{
"id": 3072,
"thread_id": 232,
"source_id": "153",
"poster_name": "zipslack",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2084",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19631#msg19631",
"date": "2010-11-02T02:51:15Z",
"text": "Thank you for your hard work, m0mchil!
I seem to have this working properly on my GeForce 8800 GTS. I was pretty proud of my 32000 khash/s until I saw what some of you guys are getting.
Wow, zipslack, that's almost as much as I get on my GTS 250!
",
"nested_level": 0
},
{
"id": 3074,
"thread_id": 232,
"source_id": "155",
"poster_name": "fenpark15",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2091",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19753#msg19753",
"date": "2010-11-02T23:11:55Z",
"text": "Sorry, I'm behind the curve. I am running the pocl binary (Win 7 64) and it says \"Unable to communicate with bitcoin RPC\" I have tried installing json-rpc in my Python26 directory using: setup.py install and it seems to complete without error. I already have checked my ATI 4600 drivers and ATI Stream so that Open CL is available.
Also, what user name and password are we supposed to use?
Again, I apologize if these questions are dumb. Until today my only experience with bitcoin is the GUI client hashing on my CPU (4600 k/s = not enough).
",
"nested_level": 0
},
{
"id": 3075,
"thread_id": 232,
"source_id": "156",
"poster_name": "fenpark15",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2091",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19768#msg19768",
"date": "2010-11-03T00:09:39Z",
"text": "I was on Bitcoin client 3.08 beta and now have also installed and tried 3.14 beta. My bitcoin.conf file is located in directory \"c:\\Users\\<my Windows user name>\\AppData\\Roaming\\Bitcoin\"
It contains 2 lines with syntax : rcpuser=<my unique user name>
rcppassword=<my unique password>
I am running poclbm from a windows command line with syntax:
poclbm.exe --user=<username> --pass=<password>
It recognizes my CPU and GPU, then when I choose one, I get the \"Unable to communicate with bitcoin RPC\"
Thank you in advance for any help.
Did you build your client yourself?
it needs to have the getwork-patch included, so if you didn't,
just grab the win32-binary in the first post of this thread (works fine for me on 64bit XP&win7).
If you did (compile with patch, or grab),
you need to start the bitcoin-client with the -server switch (maybe -rpcallowip=<IP> if a miner is running on a remote machine).
",
"nested_level": 0
},
{
"id": 3077,
"thread_id": 232,
"source_id": "158",
"poster_name": "xxmalouinxx",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1987",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19782#msg19782",
"date": "2010-11-03T02:29:32Z",
"text": "Like BitLex told, I think it's the getwork-patch. Just replace the old bitcoin.exe by the one from the getwork and it should work. Enjoy your Bitcoin !
Malouin
",
"nested_level": 0
},
{
"id": 3078,
"thread_id": 232,
"source_id": "159",
"poster_name": "SmokeTooMuch",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=13",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19835#msg19835",
"date": "2010-11-03T13:11:09Z",
"text": "I was on Bitcoin client 3.08 beta and now have also installed and tried 3.14 beta. My bitcoin.conf file is located in directory \"c:\\Users\\<my Windows user name>\\AppData\\Roaming\\Bitcoin\"
It contains 2 lines with syntax : rcpuser=<my unique user name>
rcppassword=<my unique password>
I am running poclbm from a windows command line with syntax:
poclbm.exe --user=<username> --pass=<password>
It recognizes my CPU and GPU, then when I choose one, I get the \"Unable to communicate with bitcoin RPC\"
Thank you in advance for any help.
Hmm, are you aware of that you have to start bitcoin in server mode for this to work ?
bitcoin.exe -server
Got my new 5970 and it's only showing half performance it should. I'm on Linux with SDK 2.1 and catalyst drivers 10.10. I know others have seen this problem, but I don't know whether I've seen a resolution. Does anyone know how to fix it?
",
"nested_level": 0
},
{
"id": 3080,
"thread_id": 232,
"source_id": "161",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19847#msg19847",
"date": "2010-11-03T13:48:19Z",
"text": "Its not for the masses obviously.
Edit btc_miner.cl
Insert at the top
#pragma OPENCL EXTENSION cl_amd_media_ops : enable
change
#define rot(x, y) rotate(x, (uint)y)
to
#define rot(x, y) amd_bitalign(x, x, (uint)(32-y))
See
Stream SDK OpenCL Programming Guide for details.
I'll try to add some macro to resolve this by default.
Ah, that did it, thanks!
",
"nested_level": 0
},
{
"id": 3082,
"thread_id": 232,
"source_id": "163",
"poster_name": "fenpark15",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2091",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19855#msg19855",
"date": "2010-11-03T14:42:53Z",
"text": "OK - Have it working now! I needed to fix some hidden characters that snuck in during the creation of my .conf file. Also, I was previously not running bitcoin in server mode.
Only 20740 khash/s with my ATI HD 4600 (work computer) but it sure beats 4600 from the CPU. Thanks for the help.
",
"nested_level": 0
},
{
"id": 3083,
"thread_id": 232,
"source_id": "164",
"poster_name": "ciuciu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1438",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19954#msg19954",
"date": "2010-11-03T22:51:51Z",
"text": "Hi,
I hope I can get an answer, although my question might seem stupid to some of you.
I try to run poclbm.exe after I downloaded the files from the first post in this thread and I only get this message:
C:\\Users\\First\\Desktop\\my>poclbm.exe
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
File \"pyopencl\\__init__.pyc\", line 3, in <module>
File \"pyopencl\\_cl.pyc\", line 12, in <module>
File \"pyopencl\\_cl.pyc\", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
Thank you.
",
"nested_level": 0
},
{
"id": 3084,
"thread_id": 232,
"source_id": "165",
"poster_name": "ciuciu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1438",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg19962#msg19962",
"date": "2010-11-03T23:22:07Z",
"text": "Solved by reinstalling all drivers.
Yes, installed both.
I have a Radeon HD 5850 and Windows 7 x64.
Thank you.
59.5 Mhash/s on a Radeon HD 5570. Cheers to m0mchil
Edit:
This is using --frames 1. With the default frames, I only get about 52 Mhash/s.
After updating the Radeon Linux drivers from 10.9 to 10.10, the rate decreased slightly to 59.2. However, I then tried the vectors option, which gave a small boost up to 60.65 Mhash/s. The motherboard only has 1x PCIe slots, which may affect things.
great work m0mchil!!!
laptop with an ATI HD5650 running at 46Mhash/s
thanks a lot for this app and i hope you can put your work in the official trunk asap
",
"nested_level": 0
},
{
"id": 3087,
"thread_id": 232,
"source_id": "168",
"poster_name": "brocktice",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2016",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg20681#msg20681",
"date": "2010-11-08T18:38:52Z",
"text": "I am working on a daemon-like version of this miner via a fork on github. The script is minerd.py, and it uses a config file.
It's still in development / testing, but if you'd like to give it a try here it is:
https://github.com/brocktice/poclbmLinux Miner Howto
Donations: 1Nw7aQcdtGVPmMsMtSJrDoQPEu1FJspyfd
I'll probably miss something, so please propose changes if you see fit.
1. Install Linux. For now I recommend Ubuntu 10.04 LTS Server, and I will be targeting it in this guide.
2. Install prerequisites, including compilers.
sudo aptitude install build-essential linux-headers-`uname -r`
3. Install the ATI drivers. The ubuntu packages are old. First,
wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-10-x86.x86_64.run
(then build dpkgs, need to add instructions here)
-OR-
Try
apt-cache search fglrx
on debian-based systems (including ubuntu). If it's available, do
sudo apt-get install fglrx
, otherwise, download (and you may want to check for an update) using
wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-10-x86.x86_64.run
4. Run the installer with
sudo sh ./ati-driver-installer-10-10-x86.x86_64.run
You may instead want to build packages. This may be added later.
5. Do the initial X configuration with
sudo aticonfig --initial --adapter=all -f
as root. And restart X. Logging out of X and back in should work. If you get a black screen, try ctrl-alt-f1, hopefully this will get you to a terminal where you can log in and recover.
6. Get the ATI streaming SDK v2.1 NOT v2.2, from here:
http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDK-Archive.aspx7. Untar it somewhere, I just used ~/ since it's a dedicated mining machine.
8. Edit your ~/.bashrc and add these lines:
ATISTREAMSDKSAMPLESROOT=/path/to/the/sdk
ATISTREAMSDKROOT=/path/to/the/sdk
By the way, I'd like to add an accuracy-checking opencl code to make sure the video cards are working right before starting generation, or as an optional run-mode. Art is using something similar to do precision overclocking.
I'll probably get around to it eventually, but if someone would like to contribute it feel free. Basically it should take known inputs and hashed outputs, and verify that the card correctly hashes the inputs to the outputs.
",
"nested_level": 0
},
{
"id": 3090,
"thread_id": 232,
"source_id": "171",
"poster_name": "InterArmaEnimSil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=375",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg21016#msg21016",
"date": "2010-11-09T16:08:16Z",
"text": "I see all kinds of discussion regarding AMD/ATI drivers here...does this work on nVidia cards which support OpenCL? Mine is on the list at the beginning of the thread, but I think I may be missing/skipping something, or misinterpreting whether my card is supported by this fork at all. Thanks to everyone in advance.
",
"nested_level": 0
},
{
"id": 3091,
"thread_id": 232,
"source_id": "172",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg21060#msg21060",
"date": "2010-11-09T19:44:21Z",
"text": "does this work on nVidia cards which support OpenCL?
yes, it does.
works fine for me on 8600GT and gtx260, so it should also work on all in between and above.
Very nice, thanks a lot m0mchil, I'll send some coins as gratitude once I start generating some blocks
(running successfully on win7-64 with 2x gtx275's and version 260.99 of the nvidia drivers at present)
I fire up one instance polcbm.exe for each of my gfx cards, specifying 0 or 1 to select which device:
http://i.imgur.com/uONpy.png for example
Working nicely so far giving me 45-50mhash/s per card, vs. just around 4.1mhash for my i7 running @ 2.67GHz.
A few questions:
-I've obtained the patched bitcoin.exe and I run that with \"bitcoin.exe -server\", is this more or less the same as specifying -daemon? just that daemon has no gui?
-Is there any \"proper\" way to close the miners? ctrl-c works but generates some weird warnings like:
Traceback (most recent call last):
File \"poclbm.py\", line 144, in <module>
File \"pyopencl\\__init__.pyc\", line 286, in event_wait
KeyboardInterrupt
-At present is the only way to run these and be able to view your hash rate to have command windows open? I imagine I could whip up some sort of batch script to launch 2 of them, but that is still going to need at least 2 console windows, one for each miner?
does this work on nVidia cards which support OpenCL?
yes, it does.
works fine for me on 8600GT and gtx260, so it should also work on all in between and above.
Great to know that it will work on my card. I've gotten PyOpenCL installed, but I've hit an impasse patching Satoshi's mainline client. I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot. Could someone clue me in to what I'm supposed to be doing here?
I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot. Could someone clue me in to what I'm supposed to be doing here?
You need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.
svn -r {num} http:....
have fun.
I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot. Could someone clue me in to what I'm supposed to be doing here?
You need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.
svn -r {num} http:....
have fun.
Go to sources root and then :
$ patch -i -p0 < /path/to/the/patch
I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot. Could someone clue me in to what I'm supposed to be doing here?
You need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.
svn -r {num} http:....
have fun.
Go to sources root and then :
$ patch -i -p0 < /path/to/the/patch
Thanks! The next issue seems to be wxWidgets. The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work. Anyone know where I can get 2.9.0? Or, does 2.9.1 indeed work, and I'm just doing something wrong? Sorry for the dearth of questions...
On winxp I downloaded binaries and trying with last nvidia driver (geforce 6200).
poclbm write this:
C:\\Documents and Settings\\David Richter\\poclbm>poclbm
Traceback (most recent call last):
File \"poclbm.py\", line 55, in <module>
pyopencl.LogicError: clGetPlatformIDs failed: invalid/unknown error code
C:\\Documents and Settings\\David Richter\\poclbm>
Is it due to nvidia? Is anyone using it with nvidia?
thnx
afaik the geforce 6 series does not have support for CUDA/OpenCL.
you need geforce 8 and newer.
",
"nested_level": 0
},
{
"id": 3099,
"thread_id": 232,
"source_id": "180",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg21573#msg21573",
"date": "2010-11-11T20:36:16Z",
"text": "Hi, I cannot get it work
Started patched bitcoin with rpc enabled, then poclbm.exe, but it displayed
No device specified, you may use -d to specify one of the following
Traceback (most recent call last):
File \"poclbm.py\", line 61, in <module>
context = cl.create_some_context()
File \"pyopencl\\__init__.pyc\", line 350, in create_some_context
pyopencl.RuntimeError: Context failed: out of host memory
I have already latest development version of OpenCL installed.
Any ideas?
Thanks
Marek
(...)
(...)
pyopencl.RuntimeError: Context failed: out of host memory
(...)
Seems like you have some memory issues O.o
Any chance of getting a win32 binary of bitcoin.exe for 0.3.15 with the getwork patch?
So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?
Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla \u0093Fermi\u0094 M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet
These are $2.10 per hour.
So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?
Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla \u0093Fermi\u0094 M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet
These are $2.10 per hour.
That would be pretty sweet. Didnt someone already try that as an experiment?
See first post for updated (SVN 179, 0.3.15) win32 getwork patched client
",
"nested_level": 0
},
{
"id": 3105,
"thread_id": 232,
"source_id": "186",
"poster_name": "bitcoin2",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1877",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg22109#msg22109",
"date": "2010-11-15T17:33:12Z",
"text": "With ATI 5970 Card and ubuntu I get with one Thread ~ 250 000 khash/s. But when I start a second thread the first thread rate is going down and I get with the two threats together not more as 250 000 khash/s. With \"watch -n0 aticonfig --adapter=0 --od-getclocks\" and \"watch -n0 aticonfig --adapter=0 --od-getclocks\" I can see that both GPUs are in use but only under 50% per GPU. I get this Problems with DISPLAY=:0 and with DISPLAY=:0.0 / :0.1 . What is wrong?
Thank you.
",
"nested_level": 0
},
{
"id": 3106,
"thread_id": 232,
"source_id": "187",
"poster_name": "LobsterMan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1378",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg22111#msg22111",
"date": "2010-11-15T17:40:19Z",
"text": "See first post for updated (SVN 179, 0.3.15) win32 getwork patched client
Thanks
If you want to make a quick launch for your miners in windows, just name a file something.bat, open it up in your text editor and then add a few lines like this, substituting your information:
start /DC:\\Users\\[username]\\Desktop\\poclbm_py2exe_20101102 poclbm.exe --user=youruser --pass=yourpw --device=0 -w 256
start /DC:\\Users\\[username]\\Desktop\\poclbm_py2exe_20101102 poclbm.exe --user=youruser --pass=yourpw --device=1 -w 256
The above is how I launch for my 2 nvidia gtx275's
-w specifies the work size and changing that (use powers of 2) can affect your hashrate, 256 works best for me on my nvidia gtx275's, but your mileage may vary.
Also do not forget to make your bitcoin.conf file at:
(win7)
C:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf
or
(xp)
C:\\Documents and Settings\\USERNAMEHERE\\Application Data\\Bitcoin\\bitcoin.conf
containing
rpcuser=youruser
rpcpassword=yourpw
which is what you use in your calls to poclbm.exe
bitcoin.exe must also be launched with the -server argument from the command line to use external miners.
EDIT: Would still like clarification if simply using ctrl-c is an adequate way to exit these miners, or if there is a more \"graceful\" way to do so?
So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?
Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla \u0093Fermi\u0094 M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet
These are $2.10 per hour.
$2.10 x 24 hours = $50.40.
2 X M2050 = ~ 75 mkhash/s
Difficulty Factor 4536.35372328
Hash Target 5.94299671841E+63
Probability Time
Average 3 days, 0 hours, 9 minutes
50% 2 days, 2 hours, 1 minute
95% 9 days, 0 hours, 10 minutes
^ From
http://www.alloscomp.com/bitcoin/calculator.phpSo, if one block for $150 is a good deal, then yes, it could make you money depending on what you think bitcoins value are now and in the future.
Of course the difficulty is jumping up again in a few days, current generation is still over 9 blocks an hour average.
$150 for a block means, by cloud computing industry standards, is $3 a bitcoin! $150/50 = $3. Is this the true worth of a bitcoin?!?
$150 for a block means, by cloud computing industry standards, is $3 a bitcoin! $150/50 = $3. Is this the true worth of a bitcoin?!?
No, it's not what they're worth. It's just what they cost to mine using the EC2 cluster. Just like everything else, bitcoins are worth whatever people are willing to pay for them.
Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.
",
"nested_level": 0
},
{
"id": 3110,
"thread_id": 232,
"source_id": "191",
"poster_name": "Remote",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2255",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg22356#msg22356",
"date": "2010-11-17T01:05:12Z",
"text": "Hey guys, I'm really interested in generating Bitcoins and want to see how much I can get from my GPU. I've used \"Geeks3D GPU Caps Viewer\" and made sure that I do support \"OpenCL(GPU)\".
Problem is that the only clear instruction phases I see is:
1. Download \"(GPU patch) bitcoin-getwork-svn181-win32.7z\" and \"poclbm_py2exe_20101102.7z\".
2. ?
3. Profit!
Can a kind somebody please write a proper step-by-step guide as to how you get this to work in Windows 7 64-bit? With all the baby steps, including what files to download and where they can be downloaded from (direct links) plus where stuff should be extracted/configurated.
Of course a half-arsed how-to is better than how it is now, so any effort would be welcome.
I and a lot of others would really appreciate it, and I believe you will be doing the community a huge favor.
People that try out making Bitcoins will stay much longer if they have 2000000 khash/s instead of 2000 khash/s.
it's actually all said in this thread, you just have to read it.
1. download (getwork patched client)
bitcoin-getwork-* and the miner
poclbm_py2exe_*.
2. make sure, you got a
bitcoin.conf file at
C:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf
(or on xp)
C:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf
containing
rpcuser=someone
rpcpassword=secret
3.a start
bitcoin -server and wait for connections to get the last block
3.b start
poclbm --user=someone --pass=secretif you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.
if you don't know how to handle your commandline, just create
a bitcoin.bat containing
start /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server
and a poclbm.bat containing
start /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret
to feed your clicking-needs.
4. wait and/or pray
So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?
Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla \u0093Fermi\u0094 M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet
These are $2.10 per hour.
$2.10 x 24 hours = $50.40.
2 X M2050 = ~ 75 mkhash/s
Difficulty Factor 4536.35372328
Hash Target 5.94299671841E+63
Probability Time
Average 3 days, 0 hours, 9 minutes
50% 2 days, 2 hours, 1 minute
95% 9 days, 0 hours, 10 minutes
^ From
http://www.alloscomp.com/bitcoin/calculator.phpSo, if one block for $150 is a good deal, then yes, it could make you money depending on what you think bitcoins value are now and in the future.
Of course the difficulty is jumping up again in a few days, current generation is still over 9 blocks an hour average.
How did you estimate the hashrate of the cards? By my calculations, they'd hit at least 100mhash/s each.
Fermi M2050 = ~2 TFLOPS each
My NVidia card (8800 GTS 512MB) = ~624 GFLOPS, hashrate = 33mhash/s
Fermi hashrate = ~105mhash/s x2 = ~210 mhash/s
Difficulty Factor 4536.35372328
Hash Target 5.94299671841E+63
Hash Rate (khps)
Probability Time
Average 1 day, 1 hour, 46 minutes
50% 17 hours, 51 minutes
95% 3 days, 5 hours, 12 minutes
I'm confused here, how exactly is this installed. I got the bitcoin-getwork-svn181-win32 WHICH I am going to assume is a patched .exe and dll, and the other py2exe thing now that I have those I don't know what to do or exactly hwo to install this pyopencl application.
Windows Vista user by the way, (oh dread).
",
"nested_level": 0
},
{
"id": 3114,
"thread_id": 232,
"source_id": "195",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg22412#msg22412",
"date": "2010-11-17T14:12:04Z",
"text": "OpenCL HOWTO FOR FEDORA 12 LINUX
Here are some notes which may be useful to anyone who wishes to mine for bitcoins on Fedora 12 Linux. It took me about ten hours to get all of this working, because many of the standard Fedora packages are different to what bitcoin needs and generate all kinds of odd errors when you try to build the makefile.
If you aren't already running Fedora, save yourself a lot of time and hassles by installing Ubuntu instead.
===
Check your software versions, and upgrade as necessary. The gcc compiler needs to be 4.x (for PyOpenCL), and Python needs to be 2.4 or newer (again, for PyOpenCL).
$ gcc --version
gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)
$ python --version
Python 2.6.2
You need to have either the full kernel source, or the kernel headers (because the ATI GPU driver is installed by compiling a kernel module.
$ rpm -q kernel-devel
kernel-devel-2.6.32.23-170.fc12.i686
$ rpm -q kernel-PAE-devel
kernel-PAE-devel-2.6.32.21-168.fc12.i686
===
Update your display driver.
I followed the instructions from here:
http://gofedora.com/how-to-install-ati-catalyst-fglrx-98-drivers-fedora-11/except that I used the version 10.10 of the ATI Catalyst Display Driver for Linux x86 from here:
http://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=EnglishApparently some of the installation steps are no longer needed with version 10.10, but I wasn't completely certain which ones, so I did them all anyway.
===
Get the ATI Stream SDK v2.1 (NOT any later version, according to brocktice), from here:
http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDK-Archive.aspxYou need two downloads from that page: the Linux SDK (32-bit or 64-bit according to your version of Linux), plus icd-registration.tgz
Untar the SDK anywhere convenient. Add these lines to your .bash_profile file (in your login directory):
export ATISTREAMSDKSAMPLESROOT=...<some path>.../ati-stream-sdk-v2.1-lnx32
export ATISTREAMSDKROOT=...<some path>.../ati-stream-sdk-v2.1-lnx32
export LD_LIBRARY_PATH=$ATISTREAMSDKROOT/lib/x86:$LD_LIBRARY_PATH
Move icd-registration.tgz into your root directory and (as root) untar it from there. It puts some config files into /etc.
Follow the documentation that is included in the SDK to compile the examples. Execute ati-stream-sdk-v2.1-lnx32/samples/opencl/bin/x86/CLInfo to check that things are working and that your GPU card is detected.
===
Install the Python OpenCL module (PyOpenCL). Broadly, follow the instructions here:
http://wiki.tiker.net/PyOpenCL/Installation/LinuxHowever, in step 2 I couldn't install the Numpy dependency this way. Instead I ran \"System | Administration | Add/Remove Software\", then searched for numpy and installed it.
In step 3, the OpenCL headers and libraries weren't found, so I had to use the longer configure.py example and provide explicit paths.
The \"Boost C++\" libraries are not required for this version of PyOpenCL, but we will need them later (see below).
===
Install the JSON-RPC module for Python. This was straightforward using the instructions here:
http://json-rpc.org/wiki/python-json-rpc===
Go to m0mchil's Git repository:
https://github.com/m0mchil/poclbmClick the \"Download\" button. Download and unpack these files anywhere convenient. Change poclbm.py to executable and check that it's working:
chmod 744 poclbm.py
./poclbm.py --help
===
Next we need to get bitcoin's dependencies correct.
Install wxWidgets version 2.9.0 (not 2.8 or 2.9.1). You can get version 2.9.0 from here:
http://biolpc22.york.ac.uk/pub/2.9.0/Follow the instructions in file build-unix.txt from the /src directory of the bitcoin distribution, except that you will need to be root (\"su -\") for the whole install, not just the \"make install\" step.
===
The version of OpenSSL that ships with Fedora excludes the elliptic curve cryptography due to patent concerns. Assuming you're in a country without absurd software patent laws, download the source for the latest 0.9.8 version (currently 0.9.8p) of OpenSSL from here:
http://www.openssl.org/source/Build, test and install it according to the instructions in the download. However, the standard installation doesn't install the static libraries, so I made some symbolic links:
sudo ln -s `pwd`/libssl.a /usr/lib
sudo ln -s `pwd`/libcrypto.a /usr/lib
===
You need the
static version of the Boost C++ development libraries installed. I installed this from package boost-static-1.39.0
===
You need the
static version of the Berkeley DB development libraries installed. I installed this from package db4-devel-static-4.7.25
This installed a file libdb_cxx-4.7.a in /usr/lib, but the makefile wanted libdb_cxx.a, so I created a symbolic link:
cd /usr/lib
sudo ln -s libdb_cxx-4.7.a libdb_cxx.a
===
Go to the GIT repository for m0mchil's bitcoin-getwork patch:
https://github.com/m0mchil/bitcoin-getworkNotice which SVN revision number the patch is for, and use
that number instead of 181 in the following command (which downloads the development version of bitcoin):
svn co -r 181 https://bitcoin.svn.sourceforge.net/svnroot/bitcoin
Change into the newly-created directory that holds the sources:
cd bitcoin/trunk
From m0mchil's repository, click \"Download\" and download the archive. Extract the file getwork-latest.patch into the bitcoin/trunk directory.
Modify the sources by applying the patch:
patch -p0 -i getwork-latest.patch
It should tell you that it has updated files main.cpp, main.h and rpc.cpp.
===
We need to tweak Bitcoin's makefile, which is the file bitcoin/trunk/build-unix.txt
In the WXLIBS section of the makefile, add the line
-l Xxf86vm
and also add a trailing backslash to the previous line (it's a line-continuation character). A comment in the makefile says you only need to do this if you have wxWidgets 2.9.1, but I had to do it for 2.9.0.
If your version of \"Boost\" is less than 1.40 (I'm using 1.39), edit bitcoin's makefile (src/build-unix.txt) and add -mt to the end of the name of each of the \"Boost\" libraries. There are four of these, in the four lines after the line that contains the string \"-Bstatic\".
===
Built the getwork-modified version of bitcoin:
make -f makefile.unix
This should build a binary called 'bitcoin' in this directory. Try it out! If you already have another instance of bitcoin running, close it. Type ./bitcoin to check that your newly-compiled instance works. If it works OK, close it and we'll move on to mining.
===
If you don't already have a file bitcoin.conf in your ~/.bitcoin directory, create one and put a username and password in it:
rpcuser=yourusername
rpcpassword=yourpassword
Go back to the bitcoin/trunk directory and start bitcoin in rpc server mode:
./bitcoin -server &
Go to the directory where you built poclbm.py and run it:
./poclbm.py --user=yourusername --pass=yourpassword
It will ask you which device to use. Choose the one that's
not your CPU.
Watch the khash/s figures with sweet delight, and enjoy the few moments before the roar of your cpu fan starts up.
Many thanks to m0mchil and the many others who have offered code or helpful tips.
I'm using the SHA hashing rate information from golubev's hash tables. His programs brute force attach md5 and sha algorythm's using GPU's. His numbers are extremely accurate and recently updated. Remember we are running two SHA calculations per try.
http://btco.in/4sTake his single sha1 speed and devide it by 4.5 And somehow I messed it up really nicely, and I now get the 200 mhash/s as well. Must have been sleeping when I did that before.
The other issue is, we are using SHA-256, not SHA-1. This means that we take a further speed penalty... SHA-256 is both more computationally complex (more steps to run) and more data complex (more memory to need to shuffle around).
Not sure how you got a factor of 4.5. I would estimate 2 (due to needing 2 iterations of SHA-256 instead of 1) multiplied by 1.5 (penalty of using SHA-256 instead of SHA-1). So a factor of 3?
Maybe there is room for optimisation in our SHA-256 program, yet!
Thank you very much for the wonderful miner. Good use of GPU power
I sent you a donation.
BTW, what about adding an option to get the username/password directly from ~/.bitcoin/bitcoin.conf instead of providing them on the command line. That's a little bit safer, as command line arguments can be seen by everyone on the system:
def read_config_file(filename):
'''
Read a simply = delimited config file.
Raises IOError if unable to open file, or ValueError
if an parse error occurs.
'''
f = open(filename)
try:
cfg = {}
for line in f:
line = line.rstrip()
if line:
(key, value) = line.split('=', 1)
cfg[key] = value
finally:
f.close()
return cfg
import os
home = os.getenv(\"HOME\")
if home:
try:
cfg = read_config_file(os.path.join(home, '.bitcoin/bitcoin.conf'))
except (IOError,ValueError):
pass # Cannot read config file, ignore
else:
options.user = cfg['rpcuser']
options.password = cfg['rpcpassword']
wxWidgets ... The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work. Anyone know where I can get 2.9.0? Or, does 2.9.1 indeed work
wxWidgets 2.9.1 won't work, because debugging has been changed around in 2.9.1.
You can get 2.9.0 here:
http://biolpc22.york.ac.uk/pub/2.9.0/wxWidgets ... The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work. Anyone know where I can get 2.9.0? Or, does 2.9.1 indeed work
wxWidgets 2.9.1 won't work, because debugging has been changed around in 2.9.1.
You can get 2.9.0 here:
http://biolpc22.york.ac.uk/pub/2.9.0/Works fine here with 2.9.1, then again, I'm not using debugging. I did have to change the makefile a bit, because the library has been split up:
-l wx_gtk2u_core-2.9 \\
-l wx_gtk2u_adv-2.9 \\
-l wx_gtk2u_html-2.9 \\
instead of
-l wx_gtk2ud-2.9 \\
Works fine here with 2.9.1
Yes, I just mean that wxWidgets 2.9.1 won't work with the makefile that comes with bitcoin 0.3.15.
Works fine here with 2.9.1
Yes, I just mean that wxWidgets 2.9.1 won't work with the makefile that comes with bitcoin 0.3.15.
Ah, I wouldn't know about that. I had to upgrade bitcoin to SVN trunk version before the getwork patch (from git) could be applied at all.
it's actually all said in this thread, you just have to read it.
1. download (getwork patched client)
bitcoin-getwork-* and the miner
poclbm_py2exe_*.
2. make sure, you got a
bitcoin.conf file at
C:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf
(or on xp)
C:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf
containing
rpcuser=someone
rpcpassword=secret
3.a start
bitcoin -server and wait for connections to get the last block
3.b start
poclbm --user=someone --pass=secretif you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.
if you don't know how to handle your commandline, just create
a bitcoin.bat containing
start /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server
and a poclbm.bat containing
start /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret
to feed your clicking-needs.
4. wait and/or pray
Thanks for the guide, although it looks like you left something out. When I start the miner I get the following error:
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
File \"pyopencl\\__init__.pyc\", line 3, in <module>
File \"pyopencl\\_cl.pyc\", line 12, in <module>
File \"pyopencl\\_cl.pyc\", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
Edit: Please post links if something needs to be downloaded.
I'm on Windows 7 64bit and have a NVIDIA GeForce 8800 GTS (with \"OpenCL 1.0 CUDA 3.1.1 - CU: 12 @ 1188MHz (GPU)\").
Wow, I just went from 2000 khash/s to almost 5000 by playing with the -f option
Edit : this variance changed when going to NV driver 260.19.21, now it's about 5500 and the -f has a lot less influence.
Also, CPU usage of the GPU miner went down with this driver. It was 100% with the old driver, now 2%
I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2F2RLbM.png&t=589&c=WyuZFk1l_TWFBw\"/)
There seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.
Is this something to worry about, or just a peculiarity of testnet?
it's actually all said in this thread, you just have to read it.
1. download (getwork patched client)
bitcoin-getwork-* and the miner
poclbm_py2exe_*.
2. make sure, you got a
bitcoin.conf file at
C:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf
(or on xp)
C:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf
containing
rpcuser=someone
rpcpassword=secret
3.a start
bitcoin -server and wait for connections to get the last block
3.b start
poclbm --user=someone --pass=secretif you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.
if you don't know how to handle your commandline, just create
a bitcoin.bat containing
start /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server
and a poclbm.bat containing
start /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret
to feed your clicking-needs.
4. wait and/or pray
Thanks for the guide, although it looks like you left something out. When I start the miner I get the following error:
Traceback (most recent call last):
File \"poclbm.py\", line 5, in <module>
File \"pyopencl\\__init__.pyc\", line 3, in <module>
File \"pyopencl\\_cl.pyc\", line 12, in <module>
File \"pyopencl\\_cl.pyc\", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
Edit: Please post links if something needs to be downloaded.
I'm on Windows 7 64bit and have a NVIDIA GeForce 8800 GTS (with \"OpenCL 1.0 CUDA 3.1.1 - CU: 12 @ 1188MHz (GPU)\").
Nobody that can help me? I'm about to give up on running Bitcoins since I could use my CPU for other things, but I would like to use my GPU while I'm doing those other things. Please take a moment and explain how to fix this error.
i'm not sure about that error,
but do you have latest
devdriver and cudatoolkit installed on your machine?
I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:
...
There seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.
Is this something to worry about, or just a peculiarity of testnet?
I had 2 such events with bitcoin-getwork-svn173-win32 in a real network
the miner had the event, but bitcoin did not catch it at all.
I still do not know what happened there and how to to trace it
that's just one of those ~10% \"lost blocks\",
your miner finds one, your client checks the network, network tells your client it's to late.
within the last weeks i'v been able to \"find\" 50hashes, only 45 of them have been accepted/shown up in the client-gui/generating coins.
get used to it.
",
"nested_level": 0
},
{
"id": 3128,
"thread_id": 232,
"source_id": "209",
"poster_name": "LobsterMan",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1378",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg22917#msg22917",
"date": "2010-11-19T21:34:09Z",
"text": "I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:
There seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.
Is this something to worry about, or just a peculiarity of testnet?
When they show up in the command window, they have zero confirmations. They do not show in the bitcoin UI until they have one confirmation. That delay can be a minute or 10. It is not a bug.
I don't think that is true...some of my blocks have shown up immediately with \"0 confirmations\" as soon as the miner locates them.
that's just one of those ~10% \"lost blocks\",
your miner finds one, your client checks the network, network tells your client it's to late.
within the last weeks i'v been able to \"find\" 50hashes, only 45 of them have been accepted/shown up in the client-gui/generating coins.
get used to it.
That's....not cool
That's....not cool
but that's how it is, you can't always win the race.
if your CPU/regular-miner does this, you wouldn't even notice/care, except when checking your debug.log.
updated to SVN 186
",
"nested_level": 0
},
{
"id": 3131,
"thread_id": 232,
"source_id": "212",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg23072#msg23072",
"date": "2010-11-20T15:03:00Z",
"text": "updated to SVN 186
Applies cleanly, thanks
updated to SVN 186
Thanks m0mchil for keeping up on the updates!
GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam.
Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.
Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)
Hi m0mchil, firstly thank you for your work. Is there any way to include getwork patch into official client? I'm using bitcoin on old centos server and compiling is pain here!
",
"nested_level": 0
},
{
"id": 3134,
"satoshi_id": 510,
"thread_id": 232,
"source_id": "215",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: OpenCL miner for the masses",
"url": "https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101",
"date": "2010-11-24T17:53:09Z",
"text": "A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.
",
"nested_level": 0
},
{
"id": 3135,
"thread_id": 233,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "[PATCH] increase block size limit",
"url": "https://bitcointalk.org/index.php?topic=1347.msg15121#msg15121",
"date": "2010-10-03T20:13:42Z",
"text": "We should be able to at least match Paypal's average transaction rate...
diff --git a/main.h b/main.h
index c5a0127..c92592a 100644
--- a/main.h
+++ b/main.h
@@ -14,7 +14,10 @@ class CBlockIndex;
class CWalletTx;
class CKeyItem;
-static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+ TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const int64 COIN = 100000000;
URL:
http://yyz.us/bitcoin/patch.bitcoin-block-sz-limitApplying this patch will make you incompatible with other Bitcoin clients.
",
"nested_level": 0
},
{
"id": 3137,
"satoshi_id": 478,
"thread_id": 233,
"source_id": "3",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: [PATCH] increase block size limit",
"url": "https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139",
"date": "2010-10-03T21:07:28Z",
"text": "Applying this patch will make you incompatible with other Bitcoin clients.
+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.
We can phase in a change later if we get closer to needing it.
We can phase in a change later if we get closer to needing it.
IMO it's a marketing thing. It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.
We can phase in a change later if we get closer to needing it.
IMO it's a marketing thing. It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.
Satoshi just said it can be changed, so technically the network is capable.
We can phase in a change later if we get closer to needing it.
IMO it's a marketing thing. It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.
Satoshi just said it can be changed, so technically the network is capable.
It is also an incompatible change, as you see.....
No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.
",
"nested_level": 0
},
{
"id": 3142,
"thread_id": 233,
"source_id": "8",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: [PATCH] increase block size limit",
"url": "https://bitcointalk.org/index.php?topic=1347.msg15342#msg15342",
"date": "2010-10-04T18:33:55Z",
"text": "No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.
You just described a whole-network upgrade. I'd call that an incompatible change
The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
",
"nested_level": 0
},
{
"id": 3144,
"thread_id": 234,
"source_id": "1",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Tor connections not working reliably, many seednodes offline",
"url": "https://bitcointalk.org/index.php?topic=1375.msg15593#msg15593",
"date": "2010-10-06T01:59:38Z",
"text": "While I was trying out Bitcoin with Tor a while ago, I found that it was impossible to get connected in a reasonable amount of time. See the debug.log excerpt below.
Starting 2 BitcoinMiner threads
BitcoinMiner started
BitcoinMiner started
trying connection lastseen=-2.0hrs lasttry=-357170.7hrs
proxy connecting
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 71 seconds to reconnect
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
trying connection lastseen=-2.0hrs lasttry=-357170.7hrs
proxy connecting
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 138 seconds to reconnect
trying connection lastseen=-2.1hrs lasttry=-357170.7hrs
proxy connecting
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
DelayedRepaint
trying connection lastseen=-2.1hrs lasttry=-357170.8hrs
proxy connecting
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 211 seconds to reconnect
DelayedRepaint
trying connection lastseen=-2.1hrs lasttry=-357170.8hrs
proxy connecting
proxy connecting
trying connection lastseen=-2.2hrs lasttry=-357170.8hrs
proxy connecting
proxy connected
IRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...
IRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.
IRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)
IRC socket closed
IRC waiting 292 seconds to reconnect
trying connection lastseen=-2.2hrs lasttry=-357170.9hrs
proxy connecting
DelayedRepaint
DBFlush(false)
addr.dat refcount=0
addr.dat flush
ler exiting
ThreadMessageHandler exiting
blkindex.dat refcount=0
blkindex.dat flush
ThreadIRCSeed exiting
ThreadBitcoinMiner exiting, 1 threads remaining
ThreadBitcoinMiner exiting, 0 threads remaining
wallet.dat refcount=0
wallet.dat flush
StopNode()
DBFlush(true)
Bitcoin exiting
I know that the guy who operates irc.lfnet.org is around here. Maybe he can remove that hostname limitation, since it's blocking some users.
Also, most of the seednodes are gone. Only 37 out of 230 are accepting connections on port 8333. This makes connecting without IRC very slow. The offline ones should be removed. A list of online seednodes is attached.
IMO, there needs to be a method besides IRC and compiled-in seed nodes. A middle ground.
Maybe a few volunteers could independently host a DNS zone that returns a fresh list of nodes as 'A' records. A simple cron job could fetch fresh addresses from the bitcoin client, to update the DNS zone every so often. A DNS lookup would be far faster than an IRC connection, and if we have enough volunteers, the loss of a DNS server or two would not impact the service.
",
"nested_level": 0
},
{
"id": 3146,
"thread_id": 234,
"source_id": "3",
"poster_name": "The Madhatter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=14",
"subject": "Re: Tor connections not working reliably, many seednodes offline",
"url": "https://bitcointalk.org/index.php?topic=1375.msg15596#msg15596",
"date": "2010-10-06T03:01:14Z",
"text": "Seeding from Tor is a snap. There are 7 .onion nodes that can provide IPs. I'd also just switch the IRC stuff off with '-noirc' to speed it up.
See
https://www.bitcoin.org/smf/index.php?topic=59.msg14635#msg14635Maybe 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.
I see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase. I'll fix it.
I don't know if it's really required to wait for the server to finish looking up hostname before sending nick.
How long did it take to get connected with TOR the first time, having to use the seed nodes?
",
"nested_level": 0
},
{
"id": 3148,
"satoshi_id": 490,
"thread_id": 235,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Key pool feature for safer wallet backup",
"url": "https://bitcointalk.org/index.php?topic=1414.msg16316#msg16316",
"date": "2010-10-09T20:19:33Z",
"text": "SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.
For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don't go crazy with it. Disk space is about 1K per key.
I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.
I've only tested this moderately. You might not want to use this for a website server until it's had some more testing.
",
"nested_level": 0
},
{
"id": 3149,
"satoshi_id": 491,
"thread_id": 236,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.14",
"url": "https://bitcointalk.org/index.php?topic=1528.msg17924#msg17924",
"date": "2010-10-21T16:39:27Z",
"text": "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 JSON-RPC connections on unix/osx
- validateaddress RPC command
eurekafag:
- Russian translation
My Bitcoin have this ERROR:
\"Warning: displayed transactions may not be correct! you may need to upgrade, or other nodes may need to upgrade\"
My bitcoin is in error. I had about 13,000 BTC. I tried to transfer these coins to another computer. But I find the following error. Did not transfer the blocks that are being generated are invalid. What to do?
",
"nested_level": 0
},
{
"id": 3151,
"thread_id": 237,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955",
"date": "2010-10-21T22:00:26Z",
"text": "Dhaw sent me some of his debug.log files. Symptoms I saw:
- In most of the files his block count remains \"stuck\" at 1698.
- In one file he accepted blocks beyond that, but it went back to 1698 after he restarted Bitcoin.
- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.
- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.
I'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.
He speaks 'Portuguese (Brazilian)'. A translator would be helpful.
",
"nested_level": 0
},
{
"id": 3152,
"thread_id": 237,
"source_id": "3",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg17956#msg17956",
"date": "2010-10-21T22:03:02Z",
"text": "Dhaw sent me some of his debug.log files. Symptoms I saw:
- In most of the files his block count remains \"stuck\" at 1698.
- In one file he received blocks up to 2933, but it went back to 1698 after he restarted Bitcoin.
- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.
- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.
I'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.
He speaks 'Portuguese (Brazilian)'. A translator would be helpful.
I can translate. Just post or PM and I'll have it in English for all.
I wanted a providence. A few months bitcoin'm using the same open 24 hours a day, and right now I want to sell BTC, I have this problem. I beg you to solve my problem. I thank Theymos, tried to help me for some time. But please, solve my problem, I have no intention of stealing, just want to sell my coins, which have long'm joining. I can not lose 13,000 BTC, took a long time to stop generating.
",
"nested_level": 0
},
{
"id": 3154,
"thread_id": 237,
"source_id": "5",
"poster_name": "Dhaw",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1904",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg17959#msg17959",
"date": "2010-10-21T22:06:38Z",
"text": "Dhaw sent me some of his debug.log files. Symptoms I saw:
- In most of the files his block count remains \"stuck\" at 1698.
- In one file he received blocks up to 2933, but it went back to 1698 after he restarted Bitcoin.
- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.
- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.
I'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.
He speaks 'Portuguese (Brazilian)'. A translator would be helpful.
I can translate. Just post or PM and I'll have it in English for all.
Thanks for the help. In what can help me, everything will be easier.
I can't reproduce it. I think he should get the block chain in a different way.
This is a link to the block chain up to the block 74000:
download.
1. Go to a different computer
2. Download and install bitcoin from bitcoin.org
3. Run bitcoin
4. Wait for block count to reach the latest current block count
5. Stop bitcoin
6. Copy wallet.dat from old computer with the 13000 bitcoins over to the new computer's installation's wallet.dat file.
7. Restart bitcoin
8. Problem should be solved now and your 13000 bitcoin balance should be displayed.
",
"nested_level": 0
},
{
"id": 3157,
"thread_id": 237,
"source_id": "8",
"poster_name": "Dhaw",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1904",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18016#msg18016",
"date": "2010-10-22T06:27:07Z",
"text": "i will try!
",
"nested_level": 0
},
{
"id": 3158,
"thread_id": 237,
"source_id": "9",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18026#msg18026",
"date": "2010-10-22T07:05:33Z",
"text": "He speaks 'Portuguese (Brazilian)'. A translator would be helpful.
I speak it too. If you need help PM me.
1. Go to a different computer
2. Download and install bitcoin from bitcoin.org
3. Run bitcoin
4. Wait for block count to reach the latest current block count
5. Stop bitcoin
6. Copy wallet.dat from old computer with the 13000 bitcoins over to the new computer's installation's wallet.dat file.
7. Restart bitcoin
8. Problem should be solved now and your 13000 bitcoin balance should be displayed.
Not getting results with this procedure. The coins remain to be sent, and I sent has not arrived yet.
I can't reproduce it. I think he should get the block chain in a different way.
This is a link to the block chain up to the block 74000:
download.
just perform the installation procedure on the machine that has the BTCS?
Somewhere on the 21st of this month more than 10000 BTC's had to be sent to Dhaw (should be in the block chain)
as he had 1200 BTC at 11:33 am (see
http://bitcointalk.org/index.php?action=profile;u=1904;sa=showPosts )
and reported that he is missing 13000 BTC at 08:46 pm (in this forum subject)
when he wanted to sent some of the 13000 BTC
try to understand my case, I send you all the screenshots if needed. I had BTC 8200, and transferred to another computer, but that did not. I continued to leave the program generates, and generated more than 4,200, only the site that sent the first 8200 not received. That is, I have all these bitcoins, those who currently own and was not sent and received, adding that gives BTC 8200. Theymos saw all my case it was an afternoon trying to help me. I hope it is resolved and not lose my coins.
",
"nested_level": 0
},
{
"id": 3163,
"thread_id": 237,
"source_id": "14",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074",
"date": "2010-10-22T14:25:14Z",
"text": "Dhaw generated all of these coins on his (her?) own machines.
Unfortunately, either due to a bug or some oddness with Dhaw's network connections they were all generated on an alternate block chain.
The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.
",
"nested_level": 0
},
{
"id": 3164,
"thread_id": 237,
"source_id": "15",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18081#msg18081",
"date": "2010-10-22T16:06:04Z",
"text": "Dhaw generated all of these coins on his (her?) own machines.
Unfortunately, either due to a bug or some oddness with Dhaw's network connections they were all generated on an alternate block chain.
The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.
That's probably the case, but something must have failed really badly. His block count is constantly stuck at 1698, but he somehow managed to generate and mature 13,000 BTC? He's generating at a work computer, so maybe it's some crazy antivirus.
Just to be sure that the entire balance is bad (maybe it just failed recently), Dhaw should post the raw transaction so that the inputs can be checked against the block chain.
Dhaw:
1. On the computer where you sent the 8,750, modify the Bitcoin shortcut so it runs in debug mode:
http://static/img264.imageshack.us/static/img264/2526/85647303.pnghttp://static/img146.imageshack.us/static/img146/723/90684161.png2. Run Bitcoin.
3. Double-click the 8,750 transaction:
http://static/img525.imageshack.us/static/img525/6200/90747626.png4. Copy all of the \"inputs\" to
http://pastebin.com/ and post the link here.
http://static/img263.imageshack.us/static/img263/6645/68205424.pngTo copy from that window, you have to use Ctrl+C after selecting the text. I've found that it sometimes takes a few tries to work.
just perform the installation procedure on the machine that has the BTCS?
Yes, but before that make sure that the client is closed. Your block chain will be overwritten.
And also it will be nice, if you will make backup of your block chain and upload it for analysis.
Just open
%APPDATA%\\Bitcoin directory and make copy of
blk0001.dat and
blkindex.dat files.
This should be done before the block chain will be overwritten. Be careful with the
wallet.dat!
Dhaw sent me some of his debug.log files. Symptoms I saw:
- In most of the files his block count remains \"stuck\" at 1698.
- In one file he accepted blocks beyond that, but it went back to 1698 after he restarted Bitcoin.
- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.
- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.
What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.
In any case, all the 1000s of bitcoins he generated were generated into a chain branch that only he was participating on, so they are worthless on the main chain. He would be generating 50 every 5 minutes being the only participant on that branch. The other curiosity is why he stood at 1698; this should have eventually started going up by 1 every 5 minutes when he recalculated difficulty.
And now??
=(
More than 3 months lose?
",
"nested_level": 0
},
{
"id": 3168,
"thread_id": 237,
"source_id": "19",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18238#msg18238",
"date": "2010-10-23T18:14:37Z",
"text": "What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.
He would have to disagree with 1699, but that is an empty block. There's no reason he should disagree with that one.
My theory:
His antivirus cuts off files after a certain size. This caused his block database to be limited at 1698 (and maybe he rejects blocks after that due to corruption). However, his block
index was not cut off (because it's shorter), so he ignores incoming blocks as \"already have\", even though he doesn't really have them. Every time he generates a block, it is quickly destroyed by the antivirus, but its confirmations are preserved by the block index for some reason.
dhaw, what kind of antivirus or spyware are you running?
",
"nested_level": 0
},
{
"id": 3170,
"satoshi_id": 493,
"thread_id": 237,
"source_id": "21",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: ERROR - PLEASE HELP ME!",
"url": "https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241",
"date": "2010-10-23T18:22:49Z",
"text": "his block count remains \"stuck\" at 1698.
He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload.
The safety lockdown detected the problem and was displaying \"WARNING: Displayed transactions may not be correct!\" because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility.
The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.
Good idea, I made a change to make sure it won't generate before checkpoint block 74000.
He was generating invalid blocks at difficulty 1.0. He must have a corrupted txindex entry in his blkindex.dat file. He just needs to delete blk*.dat and let it redownload.
He already did that, and the same problem occurred right away. So it's probably an antivirus issue.
OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.
Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.
It would be instructive to get knightmb's blk*.dat and see if that gets him past that point.
",
"nested_level": 0
},
{
"id": 3173,
"thread_id": 238,
"source_id": "1",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Win7 64bit since last patch Tues now crashes",
"url": "https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105",
"date": "2010-10-22T21:24:38Z",
"text": "This is from 0.3.14-win32-setup.exe. Previously I was running (up until an hour ago) a version of bitcoin.exe from Jul-2010 (which also was crashing) and the crash reports look similar. So I upgraded to see if the problem has been fixed.
To clarify what I am saying any starting of the EXE immediately reports the crash. So when I login I see the Win7 crash report and if I manually try to start it the same. The dialog beyond the crash report is \"The application was unable to start correctly (0xc0000005). Click OK to close the application.\"
Please also try to tag the application .EXE with the version information if possible, as you can see it is 0.0.0.0.
Problem signature:
Problem Event Name: APPCRASH
Application Name: bitcoin.exe
Application Version: 0.0.0.0
Application Timestamp: 4cbf4979
Fault Module Name: mingwm10.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 46b3b561
Exception Code: c0000005
Exception Offset: 00001470
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 2057
Additional Information 1: 4c0d
Additional Information 2: 4c0d4d78887f76d971d5d00f1f20a433
Additional Information 3: 4c0d
Additional Information 4: 4c0d4d78887f76d971d5d00f1f20a433
Have tried turning off Windows Defender, Real Time checking and excluding \"C:\\Program Files (x86)\\bitcoin\" but this made no difference.
As another recent thread indicates their problem was fixed or potential solution in this way.
This thread below is the closest match. I can say the crash started the moment I rebooted after October 2010 patch Tuesday, windows update (which were only applied a few days ago).
http://bitcointalk.org/index.php?topic=991.0FYI - I was not overclocking or otherwise buggering about with anything in ways I'm not meant to. Which the above thread OP claims to have done. Also My Wallet.dat looks fine, none of the AppRoaming files have been modified since I rebooted after installing the 23 updates all in one go.
Fault Module Name: mingwm10.dll
This is the important clue. I believe it's saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.
Is anyone else running OK on Windows 64-bit?
I have no problems with the official Bitcoin and 64-bit Windows 7.
",
"nested_level": 0
},
{
"id": 3177,
"thread_id": 238,
"source_id": "5",
"poster_name": "Drifter",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1864",
"subject": "Re: Win7 64bit since last patch Tues now crashes",
"url": "https://bitcointalk.org/index.php?topic=1540.msg18272#msg18272",
"date": "2010-10-24T02:26:59Z",
"text": "Running just fine on Win7 64bit as well
",
"nested_level": 0
},
{
"id": 3178,
"thread_id": 238,
"source_id": "6",
"poster_name": "Odin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=626",
"subject": "Re: Win7 64bit since last patch Tues now crashes",
"url": "https://bitcointalk.org/index.php?topic=1540.msg18319#msg18319",
"date": "2010-10-24T12:09:47Z",
"text": "Ok good to know others are able to run it ok.
Unfortunately bitcoin is not a critical application for me and need to spend my time on other things. If however there is a debugging build of the application which can provide line numbers for the crashed code (0xc0000005 - ACCESS VIOLATION) then I'd be happy to run it to identify the line causing the problem.
",
"nested_level": 0
},
{
"id": 3179,
"satoshi_id": 499,
"thread_id": 238,
"source_id": "7",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Win7 64bit since last patch Tues now crashes",
"url": "https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511",
"date": "2010-10-25T17:27:47Z",
"text": "The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don't know exactly what it does, but it probably just says something like \"yes Windows, see I'm in a DLL like you insisted.\"
The end of your debug.log file might show the last thing it was doing before it crashed.
",
"nested_level": 0
},
{
"id": 3180,
"thread_id": 239,
"source_id": "1",
"poster_name": "ShadowOfHarbringer",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1775",
"subject": "Suggestion: Allow short messages to be sent together with bitcoins ?",
"url": "https://bitcointalk.org/index.php?topic=1545.msg18205#msg18205",
"date": "2010-10-23T15:11:17Z",
"text": "Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.
Perhaps it should be possible to include short (<=512 bytes) message for each transaction.
The message could be encrypted with public/private keys so only the receiver can see its contents.
What do You think ?
PS.
I might be wrong, but the messages could also be used to increase randomness of hashing process by the way, couldn't they ? If not, never mind.
",
"nested_level": 0
},
{
"id": 3181,
"thread_id": 239,
"source_id": "2",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Suggestion: Allow short messages to be sent together with bitcoins ?",
"url": "https://bitcointalk.org/index.php?topic=1545.msg18208#msg18208",
"date": "2010-10-23T15:28:34Z",
"text": "Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.
Perhaps it should be possible to include short (<=512 bytes) message for each transaction.
The message could be encrypted with public/private keys so only the receiver can see its contents.
What do You think ?
I red somewhere that the kind of keys used in the software supports signature, but not encryption.
Since it is very easy to create a new bitcoin address for each transaction, a paiement label is not necessary. Just use the bitcoin address as a reference for your message, and transmit it via email or any other way of communication.
a paiement label is not necessary.
Sure it is \"not necessary\" but still would be useful for people.
Perhaps some people would like to keep one BTC address for some reasons.
Also bigger financial institutions won't really like the idea of different account number for each transation.
a paiement label is not necessary.
Sure it is \"not necessary\" but still would be useful for people.
Perhaps some people would like to keep one BTC address for some reasons.
Also bigger financial institutions won't really like the idea of different account number for each transation.
I don't think the keys should really be thought of as an account number per transaction. That logic I think is misleading. You can have millions of keys associated to one wallet / account.
What about the increase of the block size, then ?
Even if 512o per transaction is small, it might represent a significative amount since all has to be stored in the block chain.
What about the increase of the block size, then ?
Even if 512o per transaction is small, it might represent a significative amount since all has to be stored in the block chain.
I will tell You what have i just done.
I clicked \"quote\", copied the message and pasted it in a text file.
Then, i have truncated the file to 512 bytes, and EDIT:
GZIPPED it. It now takes 329 bytes.
Next, i have bzipped it. Now it takes 288 bytes.
Of course, there is no need for such a long message. Let's try 384 bytes. I used lorem ipsum generator from here:
http://lipsum.com/Results:
-rw-r--r-- 1 user user 384 2010-10-23 19:09 ipsum.txt (uncompressed)
-rw-r--r-- 1 user user 274 2010-10-23 19:08 ipsum.txt.bz2 (bzip2)
-rw-r--r-- 1 user user 268 2010-10-23 19:10 ipsum.txt.gz (gzip)
I think that maximum ~260-280 bytes per transaction is not bad.
Like grondilu said, encryption isn't possible.
It's possible to modify Bitcoin to send messages. Just create transactions that start with something like this:
BTCMESSAGEv1--This is a message OP_DROP
The network will accept these, but I don't think your recipient will recognize them unless he is also using your modified Bitcoin.
I found something interesting.
http://stackoverflow.com/questions/1138345/best-compression-algorithm-for-short-text-stringsThere is a small OS project on github, which does good compression of short text strings.
http://github.com/antirez/smaz'This is a small string' compressed by 50%
'foobar' compressed by 34%
'the end' compressed by 58%
'not-a-g00d-Exampl333' enlarged by 15%
'Smaz is a simple compression library' compressed by 39%
'Nothing is more difficult, and therefore more precious, than to be able to decide' compressed by 49%
'this is an example of what works very well with smaz' compressed by 49%
'1000 numbers 2000 will 10 20 30 compress very little' compressed by 10%
In general, lowercase English will work very well. It will suck with a lot
of numbers inside the strings. Other languages are compressed pretty well too,
the following is Italian, not very similar to English but still compressible
by smaz:
'Nel mezzo del cammin di nostra vita, mi ritrovai in una selva oscura' compressed by 33%
'Mi illumino di immenso' compressed by 37%
'L'autore di questa libreria vive in Sicilia' compressed by 28%
It can compress URLS pretty well:
'
http://google.com' compressed by 59%
'
http://programming.reddit.com' compressed by 52%
'
http://github.com/antirez/smaz/tree/master' compressed by 46%
So we could further get the 384 bytes down to <200 or <175 bytes.
I also wonder if the message has to be taken into account for the hash computation. Not doing so would allow to delete it later.
I very much don't like this idea of a message. Since it is not necessary to the protocol, I'm not sure if it would be easy to find a place where it really fits. I'm not a programmer though. I'd be curious to have Satoshi's thought on this.
Edit. I have a funny idea. Imagine that numeric precision is increased way beyond 8 decimals, say 128 decimals for instance.
What about using those decimals to code your message ? Somehow you would have a \"natural fee\" for this service, and we won't have to modify anything from the protocol.
Edit #2. Gosh I LOVE this idea
Edit #3. We don't need 128 decimals. Correct me if I'm wrong, but with 32 decimals you can code a 17 characters-longed uncompressed message in a 64 characters set. (32*log(10)/log(64) = 7.717)
I very much don't like this idea of a message. Since it is not necessary to the protocol, I'm not sure if it would be easy to find a place where it really fits. I'm not a programmer though. I'd be curious to have Satoshi's thought on this.
Yeah, I'm curious of that too.
ECDSA can't encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.
If there's going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they're from.
",
"nested_level": 0
},
{
"id": 3190,
"thread_id": 240,
"source_id": "1",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "af",
"url": "https://bitcointalk.org/index.php?topic=1668.msg20278#msg20278",
"date": "2010-11-05T23:44:00Z",
"text": "adgadg
",
"nested_level": 0
},
{
"id": 3191,
"thread_id": 240,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Some testing that I did on the testnetwork, my findings.",
"url": "https://bitcointalk.org/index.php?topic=1668.msg20283#msg20283",
"date": "2010-11-06T00:14:10Z",
"text": "Spent transactions can be forgotten (though they currently aren't). That would prevent your sending coins back and forth from having a big impact on block size.
The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster.
I think this attack would be more difficult on the real network because of the differing fee schedules. You'll have half of the network including your transactions and half of the network not including them. Half of the network considers a block \"filled\" at 500KB, and half at the network-enforced maximum of 1MB.
Or maybe the entire size exceeded the 1 MB limit.
You're right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn't have gotten that if you weren't generating, since you wouldn't have known the current blocksize.
Even if you made non-generators aware of the current blocksize, by doing this you could force everyone to pay transaction fees.
There's no avoiding that. An attacker will always be able to create millions of transactions; the only defense is fees on every transaction. Bitcoin was never intended to remain free forever.
Actually... prioritizing free transactions based on both amount and their \"age\" should make this attack toothless.
The basic idea is that if you're spamming lots of small free transactions, you'll be creating lots of brand-new \"pennies\" (you'll take an old 50BTC generated transaction, then split off a penny and get a penny and 49.99 change. Then split that 49.99 to get another penny, and so on and so on).
Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (\"old money\") are given priority would let normal transactions go through.
The spammy transactions would still take up network bandwidth and disk space; if that becomes a problem, nodes could just ignore small, new transactions (not relay them) and let the nodes that are doing the spamming queue up and rebroadcast the transactions. They'd trickle into the network eventually, and in the meantime the spammer's bit-pennies would be tied up.
",
"nested_level": 0
},
{
"id": 3194,
"thread_id": 240,
"source_id": "5",
"poster_name": "ByteCoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=490",
"subject": "Re: Some testing that I did on the testnetwork, my findings.",
"url": "https://bitcointalk.org/index.php?topic=1668.msg20570#msg20570",
"date": "2010-11-08T02:31:22Z",
"text": "Actually... prioritizing free transactions based on both amount and their \"age\" should make this attack toothless.
Sorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (\"old money\") are given priority would let normal transactions go through.
Prioritizing larger value transactions doesn't really solve the problem because it's perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.
If you prioritize older transactions, people would be incentivised to split their bitcoin holdings in such a fashion as to ensure that they do not generate significant amounts of change when they buy things with bitcoins. If you hold your bitcoins in powers of 2 * 0.01 then you can pay for anything you can aford with no change and the least fragmentation. Of course after spending the money you have to rebalance your holdings as soon as possible. The best way to do this is not immediately obvious to me. Possibly under certain circumstances it might be advantageous to generate change as long as you could specify how you wanted it split up. Possibly powers of 3 might be best for multiple purchases.
Anyway, the end effect would be that transactions would have more ins and outs. Probably the average number of ins and outs would be some very small multiple (or large fraction) of the log of the number of bitcoin pennies in the transaction. I estimate that this might increase the average transactions size by over 10 times.
ByteCoin
Prioritizing larger value transactions doesn't really solve the problem because it's perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.
No, you can't, because every time you send them they become \"new\", and the priority is age multiplied by amount:
// Priority is sum(valuein * age) / txsize
(valuein is the size of the bitcoin input, age is # of blocks deep, and txsize is the number of bytes the transaction takes up)
If you prioritize older transactions, people would be incentivised to split their bitcoin holdings in such a fashion as to ensure that they do not generate significant amounts of change when they buy things with bitcoins. If you hold your bitcoins in powers of 2 * 0.01 then you can pay for anything you can aford with no change and the least fragmentation. Of course after spending the money you have to rebalance your holdings as soon as possible. The best way to do this is not immediately obvious to me. Possibly under certain circumstances it might be advantageous to generate change as long as you could specify how you wanted it split up. Possibly powers of 3 might be best for multiple purchases.
Anyway, the end effect would be that transactions would have more ins and outs. Probably the average number of ins and outs would be some very small multiple (or large fraction) of the log of the number of bitcoin pennies in the transaction. I estimate that this might increase the average transactions size by over 10 times.
Ummm... the more you mess around with the coins in your wallet, the newer they are, and the lower their priority (relative to everybody else who might want to get their transactions into the next block). I haven't thought deeply about it, but I bet simply leaving your coins as they are and making change as necessary will work out best. But please, create your own client and try to break things on the test network!
The priority calculation you suggest would be a considerable improvement over the current system of first-come-first-served. If it were implemented then I think it's likely that the incentives outlined in my post would cease to operate and that average transaction sizes would not increase significantly.
There may be some incentive to break up large change if it is believe that spending it is not likely to be required in the near future, in order to ensure that coin holdings of adequate power always exist. It's hard to do this correctly as it requires the forcasting of both priority and spending far in advance.
If there were many contending transactions there would be a tendancy (all else being equal) to retard blocks with multiple ins because scriptSigs are so much larger than scriptPubKeys. I haven't an opinion whether this is bad or not.
I think there may be some small distortions to the value of older transactions on the grounds that they are so powerful. People might be motivated to \"exchange\" the private key instead of performing a transaction in order to maintain the power of these old transactions while still \"spending\" them without actually spending them. This would be nothing but advantage to bitcoin as these key exchages don't show up in the block chain.
Also unfortunately, there would be the incentive for the following undesirable behaviour:
Suppose someone has just been paid a large sum of bitcoin (1000BTC) and needs to make some small payments(1BTC). They also have recently been paid some smaller amouts of bitcoin(0.5BTC). If they try to pay the 1BTC debts using their 0.5BTC credits then their transactions have very low priority. This transaction can be represented as 2 * 0.5 BTC = 1BTC
If however they include the 1000BTC then the transaction has a much higher priority and it's not really wasting any significant accumulated age-derived power of the recently received 1000BTC. This transaction can be represented as 1000BTC + 2 * 0.5BTC = 1BTC + 1000BTC. This would approximately double the size of this sort of transaction.
But please, create your own client and try to break things on the test network!
No incentive to do so thanks!
ByteCoin
With davidonpda's help, I did some testing myself today with Satoshi's latest code changes (setting priority based on transaction age, bitcoin amounts in, and total transaction size in bytes -- svn rev 176).
It behaved as expected, putting larger, older transactions ahead of the pennies being flooded into the network, so \"normal\" transactions will be confirmed promptly even if somebody decides to be a jerk and floods the network with transactions.
",
"nested_level": 0
},
{
"id": 3198,
"satoshi_id": 501,
"thread_id": 240,
"source_id": "9",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Some testing that I did on the testnetwork, my findings.",
"url": "https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896",
"date": "2010-11-13T23:25:26Z",
"text": "Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
",
"nested_level": 0
},
{
"id": 3199,
"thread_id": 240,
"source_id": "10",
"poster_name": "ByteCoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=490",
"subject": "Re: Some testing that I did on the testnetwork, my findings.",
"url": "https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899",
"date": "2010-11-13T23:55:11Z",
"text": "In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can \"save\" the higher priority coins for when the network
is being flooded.
Unless I misunderstand, it looks to me like the current logic is more likely to spend the accumulated priority of older transactions. It's a minor point however.
Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
ByteCoin
Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can \"save\" the higher priority coins for when the network is being flooded.
You should use at least some priority in case a flood comes along before the next block.
As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.
Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders.
Priority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.
Hey,
I wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.
http://wikileaks.org/media/support.htmlAnyone know where to send a message to them?
Bitcoins could be really useful to them. Good idea.
I don't know the answer to your question though, sorry.
",
"nested_level": 0
},
{
"id": 3203,
"thread_id": 241,
"source_id": "3",
"poster_name": "caveden",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=704",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg21281#msg21281",
"date": "2010-11-10T13:24:04Z",
"text": "Well, you know, if you don't find a proper contact, you can always send an ancient letter, made from paper.
They have a postal address on this page you linked.
Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.
This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, holding back mainstream adoption.
Of course i know that they (governments) will start fighting bitcoin at some point, but the later, the better. If we go mainstream first, then such efforts will be probably futile, and BTC will probably be unstoppable without shutting down whole internet.
",
"nested_level": 0
},
{
"id": 3205,
"thread_id": 241,
"source_id": "5",
"poster_name": "Macho",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=625",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg21285#msg21285",
"date": "2010-11-10T13:37:14Z",
"text": "I have their e-mail saved from when it was published ... it's
wl-supporters@sunshinepress.orgTry it
It should work ...
Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.
By your logic the USA should forbid money. At least on paper and metal, a lot of currencies, and money transfers to uncontrollable countries like Bermuda and Switzerland. Perhaps go completely communist. On a worldwide basis porn and gambling is a lot more controversial than Wikileaks. Only China and Thailand censor Wikileaks. A lot more countries censor porn and gambling sites. I don't think this will make the US government blink.
Contrary to popular opinion it is not illegal to create your own currency. If they try to claim there is something illegal in the mere act of transferring value or bits of data they will look ridiculous.
",
"nested_level": 0
},
{
"id": 3208,
"thread_id": 241,
"source_id": "8",
"poster_name": "ShadowOfHarbringer",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1775",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg21295#msg21295",
"date": "2010-11-10T14:20:49Z",
"text": "Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.
By your logic the USA should forbid money. At least on paper and metal, a lot of currencies, and money transfers to uncontrollable countries like Bermuda and Switzerland. Perhaps go completely communist. On a worldwide basis porn and gambling is a lot more controversial than Wikileaks. Only China and Thailand censor Wikileaks. A lot more countries censor porn and gambling sites. I don't think this will make the US government blink.
I hope you're right.
Contrary to popular opinion it is not illegal to create your own currency. If they try to claim there is something illegal in the mere act of transferring value or bits of data they will look ridiculous.
Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.
You can send a paper letter to an address?
Apparently so. See \"
How do I send a letter?\"
Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.
Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed. It's very much the same with any goods.
This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, holding back mainstream adoption.
Of course i know that they (governments) will start fighting bitcoin at some point, but the later, the better. If we go mainstream first, then such efforts will be probably futile, and BTC will probably be unstoppable without shutting down whole internet.
I think that governments trying to fight Bitcoin would actually help in adoption because of the
Streisand effect.
Bitcoin makes it possible to secede from government. They dont like it when the slaves do that.
Hahaha
5. Via Postal Mail
You can post a donation via good old fashion postal mail to:
WikiLeaks
(or any suitable name likely to avoid interception in your country)
BOX 4080
Australia Post Office - University of Melbourne Branch
Victoria 3052
Australia
Thats about 2 hours away from me. I can post something for $0.50c so if you like write up something and link to it here and I will print it out.
An idea might be to set up a mybitcoin account and send them the login info with the letter.They would be more likely to accept if there is a few dollars already awaiting collection. Julian Assange is a fellow Aussie.
Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.
Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed. It's very much the same with any goods.
Actually, if i tell you that \"there is money in the safe of bank XXX\", that is information about whereabouts too.
The same if I tell you that there is some heroin (which is itself illegal) in the police storage facitilities.
And all that informations are legal, the same as bittorrent should be legal, because it is only information about whereabouts of other information, which
logically should be NEVER illegal.
But the governments together with media industry are trying hard to make BitTorrent (and all P2P in gerneral) illegal, in spite of obvious idiocy of such doing.
Bitcoin makes it possible to secede from government. They dont like it when the slaves do that.
Why do i feel more and more convinced that the internet era will end governments in the form we know them ?
This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, ...
if they gonna fight it anyway, isn't it better the sooner they do?
or do you want to invest (time/money/effort) into it first and have
them fight it later?
I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it\u0085 scratch my back and I\u0092ll scratch yours.
I don\u0092t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.
",
"nested_level": 0
},
{
"id": 3218,
"thread_id": 241,
"source_id": "18",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg21415#msg21415",
"date": "2010-11-11T00:03:40Z",
"text": "This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, ...
if they gonna fight it anyway, isn't it better the sooner they do?
or do you want to invest (time/money/effort) into it first and have
them fight it later?
The later the better. The longer that governments wait to act, the stronger the bitcoin network grows, and the harder it becomes to harm it.
Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.
Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed. It's very much the same with any goods.
Actually, if i tell you that \"there is money in the safe of bank XXX\", that is information about whereabouts too.
The same if I tell you that there is some heroin (which is itself illegal) in the police storage facitilities.
And all that informations are legal, the same as bittorrent should be legal, because it is only information about whereabouts of other information, which
logically should be NEVER illegal.
But the governments together with media industry are trying hard to make BitTorrent (and all P2P in gerneral) illegal, in spite of obvious idiocy of such doing.
Well,they can try. The problem for people who control things through having bigger guns is that you cant shoot bittorrent.
I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it\u0085 scratch my back and I\u0092ll scratch yours.
I don\u0092t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.
I love this idea. Know that Julian Assange (the founder and head of Wikileaks) was a former Free Software programmer and wrote lots of cryptographic tools. He is very knowledgeable in this area himself and will understand Bitcoin technically.
Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.
Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed. It's very much the same with any goods.
Actually, that's not true. Strong encryption, regardless of the nature of the information, is (rather rediculously) considered a 'munition' under US export law. Depending on how a court looks at this law, it's either unconstitutional or the exportation of such encryption methods gets the sender sent to prison for violation of international trade bans on weapons. So it's a pretty good thing that Bitcoin doesn't actually encrypt anything itself, but I'm not sure that a court would be savvy enough to know the differences.
Hey,
I wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.
http://wikileaks.org/media/support.htmlAnyone know where to send a message to them?
Eh. Wikileaks is almost certainly run by the CIA anyway. I doubt they'll be interested.
Hey,
I wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.
http://wikileaks.org/media/support.htmlAnyone know where to send a message to them?
Eh. Wikileaks is almost certainly run by the CIA anyway. I doubt they'll be interested.
Thanks Adam Curry.
Well,they can try. The problem for people who control things through having bigger guns is that you cant shoot bittorrent.
They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.
They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.
I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak. Should we pool some money together to include with a letter?
",
"nested_level": 0
},
{
"id": 3226,
"thread_id": 241,
"source_id": "26",
"poster_name": "farmer_boy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2334",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25237#msg25237",
"date": "2010-11-28T23:48:16Z",
"text": "I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it\u0085 scratch my back and I\u0092ll scratch yours.
I don\u0092t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.
There is nothing to be audited as far as an academic cryptographer would be concerned. For that to happen, the specification of Bitcoin would have to be of better quality. That needs to happen first and only when that is done, there is a chance someone will want to take a serious look.
Only the author or a volunteer could publish a specification of sufficient quality. It's not acceptable as a Master thesis subject on a respectable university, because there is no research involved, it's just \"work\". The \"coolness\" factor is of no interest there.
I'm going to go online tonight and talk to some Wikileaks staff see if they can start the ball rolling on the insides.
",
"nested_level": 0
},
{
"id": 3228,
"thread_id": 241,
"source_id": "28",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25353#msg25353",
"date": "2010-11-29T12:50:28Z",
"text": "I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it\u0085 scratch my back and I\u0092ll scratch yours.
I don\u0092t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.
There is nothing to be audited as far as an academic cryptographer would be concerned. For that to happen, the specification of Bitcoin would have to be of better quality. That needs to happen first and only when that is done, there is a chance someone will want to take a serious look.
Satoshi's paper is a good introduction I'd think.
And another thing, I'm not sure about academic cryptographers, but in the 'real world' security auditing is regularly done on source code, or sometimes even without source code (either by reverse engineering or black box testing).
They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.
They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.
Screw big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.
My task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.
Burn, Hollywod, burn.
I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak. Should we pool some money together to include with a letter?
Currently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.
As the cables were published, the White House released a statement condemning their release. \"Such disclosures put at risk our diplomats, intelligence professionals, and people around the world who come to the US for assistance in promoting democracy and open government. By releasing stolen and classified documents, WikiLeaks has put at risk not only the cause of human rights but also the lives and work of these individuals.\"They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.
They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.
Screw big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.
My task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.
Burn, Hollywod, burn.
I'm only saying that it may be difficult for bitcoin to go mainstream, but i seriously doubt they can stop adoption in general.
They would have to shut down the internet entirely, which is not easy (possible breaking ICANN is not enough, we can always use alternative DNS roots).
I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak. Should we pool some money together to include with a letter?
Currently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.
So far they have failed. I hope it stays that way.
Apparently someone did a massive ddos against wikileaks today.
In more inspiring news operation payback took down the warner bros website for a few hours and ifpi.org is currently unreachable.
The cable leak has been turned into a torrent file and is currently being mirrored on thousands of servers all over the world. The pirate bay's entire torrent database is available as a torrent you could fit on a 32gb flash drive.
All in all what has the government accomplished except to tread on an ants nest.
Apparently someone did a massive ddos against wikileaks today.
Really is that so ?
http://cablegate.wikileaks.org/ worked perfectly for me for the last 12 or 18 hours.
They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.
They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.
Screw big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.
My task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.
I'm only saying that it may be difficult for bitcoin to go mainstream, but i seriously doubt they can stop adoption in general.
They would have to shut down the internet entirely, which is not easy (possible breaking ICANN is not enough, we can always use alternative DNS roots).
Gotcha. It's just a difference of emphasis, really.
I believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.
If you're reading this, you're part of the vanguard building the new economy and the new world. Mainstream acceptance will come by weight of numbers and via network effects. Who ever heard of Wikileaks or Twitter four years ago? And today we've got Admiral Chairman-of-the-Joint-Fucking-Chiefs Mullen tweeting his dismay over Wikileaks -- no doubt via the intermediation of an office full of PR analysts and bureaucrats, at extremely low relative impact.
BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help?
I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak. Should we pool some money together to include with a letter?
Currently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.
So far they have failed. I hope it stays that way.
As I understand the problem of state right now is that if wikileaks crew a long time does not appear in the network automation will send the AES key to wikileaks insurance file.
But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.
I believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.
I like that idea of Yours, however what i don't like about it is the amount of time it needs to become reality.
However i guess we don't have any choice, as the \"old economy\" will never adapt - I concede with you there. Bankers & other people who gain from the current system will never resign of their false fraudulent dream world, unless it totally collapses itself first.
BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help?
No need for that, they cannot really \"shut down the internet\". They would have to take all the physical equipment away from people - Linux servers, routers, switches, wires, cables etc. And that is not possible at all without some major disaster (nuclear war or something).
They cannot take our equipment from us, and with the equipment geeks will quickly build a new internet from the scratch. It's just a matter of little rewiring & changing configuration. Not so difficult as one would think.
But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.
That's probably because USA is not Soviet Russia (yet).
They started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.
If they torture or murder somebody from wikileaks, they really risk getting their asses kicked on the international arena.
But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.
That's probably because USA is not Soviet Russia (yet).
They started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.
Come on, kill a few people to save tens or hundreds? Trifling matter, since all countries do.
If they torture or murder somebody from wikileaks, they really risk getting their asses kicked on the international arena.
Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.
Sad but true.
Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.
Sad but true.
If that was so easy as You said, they would have done so long ago. Wikileaks is not here since yesterday.
Also, wikileaks has the encrypted insurance file already distrubuted among people long ago (God knows what it may contain ? perhaps 9/11 inside job proof ?). USA may be also afraid of that.
Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.
Sad but true.
If that was so easy as You said, they would have done so long ago. Wikileaks is not here since yesterday.
But the pain in the ass it inflicts with the exponential progression.
Also, wikileaks has the encrypted insurance file already distrubuted among people long ago (God knows what it may contain ? perhaps 9/11 inside job proof ?). USA may be also afraid of that.
File without the key is garbage. State can find out who have the key and find out what conditions it will be published.
I like that idea of Yours, however what i don't like about it is the amount of time it needs to become reality.
However i guess we don't have any choice, as the \"old economy\" will never adapt - I concede with you there. Bankers & other people who gain from the current system will never resign of their false fraudulent dream world, unless it totally collapses itself first.
I don't like that aspect either. I want freedom by next Tuesday, damnit! This is an urgent problem!
[/quote]
BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help?
No need for that, they cannot really \"shut down the internet\". They would have to take all the physical equipment away from people - Linux servers, routers, switches, wires, cables etc. And that is not possible at all without some major disaster (nuclear war or something).
They cannot take our equipment from us, and with the equipment geeks will quickly build a new internet from the scratch. It's just a matter of little rewiring & changing configuration. Not so difficult as one would think.
It's a veeerry long shot, but US fiat could dictate all non-governmental telecom landings in the US and its territories shut down, and enforce it. A hundred soldiers at each of the two or three dozen major US traffic-switching nodes and the US internet implodes. A tactical nuke on MAE-West? YES WE CAN!
On top of that, the US military has the resources and intelligence necessary to sever the undersea fiber that carries almost all transcontinental internet traffic, plus the assets in place to accomplish immense comms disruption in all of the 100+ countries in which it maintains military bases.
Mind you, this is a doomsday scenario, and not likely. Destroying the internet would be suicide for the US government, as doing so would destroy Wall Street along with the remnant shreds of its reputation.
Anyway, if it ever comes to it, you and I will build a new internet. End-to-end crypto will be mandatory everywhere. All links, all nodes, all sessions. And DNS will be distributed.
Humane russian offer to torture a few people. Angry american are ready to unleash a nuclear war.
Well, who is the devil?
But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.
That's probably because USA is not Soviet Russia (yet).
They started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.
Come on, kill a few people to save tens or hundreds? Trifling matter, since all countries do.
Killing them will make martyrs of them... And will make the thing much and much worse than it is now. Currently, wikileaks gets a lot of flak from people that don't completely agree with what they are doing. As long as the US stays reasonable, it is fairly easy to ignore the whole thing. No matter what information wikileaks reveals, people will forget about it.
But if it happens that a Wikileaks member disappears or is killed, there will be books, movies, conspiracy stories, political movements etc... the whole thing will be very hard to contain, and the last thing the USA wants is to tilt the global opinion even more against them.
No, I brought the murder as an example. In this case, nobody should be killed.
They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.
",
"nested_level": 0
},
{
"id": 3245,
"thread_id": 241,
"source_id": "45",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25396#msg25396",
"date": "2010-11-29T16:43:50Z",
"text": "They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.
Yes but if they are tortured and they live to tell about it, it will have the same effect. Especially if they are abducted from some foreign European country. It's not like wikileaks is based in the US, it's an international organization with members everywhere. Also, wikileaks is a non-violent organisation, so using violence against them will be quite shocking (at least to European people), even more shocking than the leaks. It would be a media circus!
Maybe somebody should sell robots that record activities of government agents for bitcoins.
We could have...
\"YOUR LITTLE BROTHERS ARE WATCHING YOU!\"
Plus, camera tend to prevent abuse of authority by policemen.
",
"nested_level": 0
},
{
"id": 3247,
"thread_id": 241,
"source_id": "47",
"poster_name": "mikegogulski",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2285",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25404#msg25404",
"date": "2010-11-29T17:06:42Z",
"text": "Maybe somebody should sell robots that record activities of government agents for bitcoins.
[...]
Plus, camera tend to prevent abuse of authority by policemen.
I've long believed that if we are to have government officials, they should be tailed 24/7 by public sensor robots. Or ridiculously hot young Asian boys. Either one.
File without the key is garbage. State can find out who have the key and find out what conditions it will be published.
Surely a lot of people have the key.
Good luck finding them on TOR or freenet.
(FYI: TOR is completely untrackable when connecting from one TOR node, to another TOR node, contrary to connecting to/from \"normal internet\" from/to TOR).
No, I brought the murder as an example. In this case, nobody should be killed.
They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.
As witchspace already pointed out, things that are easy in Soviet Russia are not necessarily so easy in \"normal\" semi-democratic world.
There are many problems:
1. The matryr thing - as explained by witchspace
2.
Streissand Effect (similiar to creating martyrs). The more You want to censor something , the more people will download it.
3. The wikileaks insurance (random people around the world may have the key and they will release it when time comes
4. Bad PR for USA if they start shooting people from wikileaks. I mean what would be the difference between them and Russia/China if they do this ? None. This could further break diplomatic relations with (semi)democratic countries.
... Soviet Russia ...
In Soviet Russia, coin bit you!
(sorry)
Maybe somebody should sell robots that record activities of government agents for bitcoins.
[...]
Plus, camera tend to prevent abuse of authority by policemen.
I've long believed that if we are to have government officials, they should be tailed 24/7 by public sensor robots. Or ridiculously hot young Asian boys. Either one.
haha that is a great idea.
These people think they can hide amongst the beauracracy and claim \"im just doing my job\". Ive got news for them.
They forget that they can be tortured too.
Apparently someone did a massive ddos against wikileaks today.
Really is that so ?
http://cablegate.wikileaks.org/ worked perfectly for me for the last 12 or 18 hours.
Anyone know where to send a message to them?
Sorry. Did we ever find any contact information for Wikileaks, other than their postal mailbox....?
I've added Wikileaks to our \"target list\" on
BitcoinPromote.comI have some of the staff on IRC.
",
"nested_level": 0
},
{
"id": 3256,
"thread_id": 241,
"source_id": "56",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25593#msg25593",
"date": "2010-11-30T02:31:27Z",
"text": "I have some of the staff on IRC.
Where? Freenode?
This does not seem like the best time to be creating some sort of wikileaks-bitcoin connection.
",
"nested_level": 0
},
{
"id": 3258,
"thread_id": 241,
"source_id": "58",
"poster_name": "bober182",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1998",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25597#msg25597",
"date": "2010-11-30T02:50:50Z",
"text": "They run there own anonymous IRC server.
chat.wikileaks.org port 9999 i think or the secure one.
",
"nested_level": 0
},
{
"id": 3259,
"thread_id": 241,
"source_id": "59",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25639#msg25639",
"date": "2010-11-30T04:52:09Z",
"text": "No, I brought the murder as an example. In this case, nobody should be killed.
They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.
As witchspace already pointed out, things that are easy in Soviet Russia are not necessarily so easy in \"normal\" semi-democratic world.
There are many problems:
1. The matryr thing - as explained by witchspace
2.
Streissand Effect (similiar to creating martyrs). The more You want to censor something , the more people will download it.
3. The wikileaks insurance (random people around the world may have the key and they will release it when time comes
4. Bad PR for USA if they start shooting people from wikileaks. I mean what would be the difference between them and Russia/China if they do this ? None. This could further break diplomatic relations with (semi)democratic countries.
(grep torture)
You joined to protest on the streets or spent at home with your computer?
You joined to protest on streets or spent at home with your computer?
Can you explain the purpose of going into the streets? A minority will only go into the streets. Even if a majority would go into the streets (which has never happened before, AFAIK), the government will simply state that it was a minority.
Before the government had good riot control weapons demonstrations had the option of escalating and actually overthrowing the government in the worst case. That simply is not the case anymore. People have no weapons and are literally without power.
The same money they pay in taxes will get them killed if they oppose the government too much.
Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real.
",
"nested_level": 0
},
{
"id": 3262,
"thread_id": 241,
"source_id": "62",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25662#msg25662",
"date": "2010-11-30T06:30:56Z",
"text": "Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real.
When will all these tuition strikers learn about
Wikiversity?
Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real.
The truck drivers in Greece got fucked over in the end. The people in France lost. Don't think it will go different in the UK. As far as I am concerned you are only supporting my point.
The same money they pay in taxes will get them killed if they oppose the government too much.
Young man, you seriously overestimate the power of an unpopular government. The greatest tool of control available to any government is the meme that the government represents the will of the people, followed closely by the meme that the government's collective force exceeds that of those who would oppose it. Vary rarely has either of those conditions actually been proven true once put to the test.
Protests are weak and least likely to do anything.
All you do is put up signs and gather in a large rally.....that does nothing.
",
"nested_level": 0
},
{
"id": 3266,
"thread_id": 241,
"source_id": "66",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25673#msg25673",
"date": "2010-11-30T06:57:03Z",
"text": "Protests are weak and least likely to do anything.
All you do is put up signs and gather in a large rally.....that does nothing.
Mostly, but not quite. Rallies also help to combat the first meme that I mentioned above by dispelling the belief that those who quietly oppose the ruling class are part of a impotently small minority.
Fine
Spanish Civil War.
",
"nested_level": 0
},
{
"id": 3268,
"thread_id": 241,
"source_id": "68",
"poster_name": "farmer_boy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2334",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg25792#msg25792",
"date": "2010-11-30T18:43:36Z",
"text": "Fine
Spanish Civil War.
I already said that there was a time in which demonstrations could have consequences for those in power. That time is over.
Another example: look at the nuclear waste transports through Germany. It took 75 hours to travel a distance which should be more like 10 hours or so. The only thing which was displayed is that there are a lot of people that don't like nuclear waste, but the objective of the government was still achieved.
You joined to protest on streets or spent at home with your computer?
Can you explain the purpose of going into the streets?
The aim is to show that you have a lot people and you are committed.
So. You're not going to deny human rights violations on the Guantanamo base ? And nothing happened!
I think if something happens with wikileaks crew nothing to happens too. The more that citizens are also no consensus on the good they do or not and it is also advantageous to the government.
Well, those are prisoners taken in Afghanistan and Iraq. It would be different with a citizen of our own country.
Well, those are prisoners taken in Afghanistan and Iraq. It would be different with a citizen of our own country.
Assange are also not citizen of the U.S.!
Well, those are prisoners taken in Afghanistan and Iraq. It would be different with a citizen of our own country.
Assange are also not citizen of the U.S.!
I know
I'm neither. But if the U.S. went kidnapping people here and then torturing them, we'd be very shocked.
You joined to protest on streets or spent at home with your computer?
Can you explain the purpose of going into the streets?
The aim is to show that you have a lot people and you are committed.
Committed to do what? If you cannot touch the leaders in a meaningful way, it is pointless.
Let's take a look at Iran. A large part of the world does not agree with their actions of developing the exact same technology they already have. The CIA could demonstrate, but they can also just blow up a few nuclear scientists (which is likely what they have done). The credo \"might is right\" of the Nazi's is spot on. No might, no right.
Well, those are prisoners taken in Afghanistan and Iraq. It would be different with a citizen of our own country.
Assange are also not citizen of the U.S.!
I know
I'm neither. But if the U.S. went kidnapping people here and then torturing them, we'd be very shocked.
Ok, I agree: torturing of dirty afghans is ok, but australians is savagery.
You joined to protest on streets or spent at home with your computer?
Can you explain the purpose of going into the streets?
The aim is to show that you have a lot people and you are committed.
Committed to do what? If you cannot touch the leaders in a meaningful way, it is pointless.
To starting an armed struggle against the authorities. In this case, blood is spilled.
The street protests means that.
To starting an armed struggle against the authorities. In this case, blood is spilled.
The street protests means that.
If you want to die against military trained killers, good luck with that.
What you need to do is:
1. Undermine their credibility.
2. Reduce dependence on the state.
3. Increase your credibility.
Rebellions will likely be crushed. Even if you succeed, a power-hungry demagogue will rise to power and make your life even worser. Don't count on it.
You joined to protest on streets or spent at home with your computer?
Can you explain the purpose of going into the streets?
The aim is to show that you have a lot people and you are committed.
Committed to do what? If you cannot touch the leaders in a meaningful way, it is pointless.
To starting an armed struggle against the authorities. In this case, blood is spilled.
The street protests means that.
Oh, I imagine the government must be really scared of trying to attack its population with the most modern weapons money can buy. An armed struggle will just destabilize the country, but will not have any effect on the government if they want (look at dictatorships), unless the military decides to stop supporting the government (which is why unmanned vehicles are getting so popular).
We are going to a society in which the president can select all the demonstrators from a database (automatically based on camera data, of course), press one button and kill all of them. This might be done by sending missiles, but it could also be done by analysing the DNA, finding a biochemical agent which mysteriously kills a particular part of the population of just one specific individual (they can create flying machines the size of a musquito already that no doubt could also be equipped with some untraceable poison). You can do it slowly enough, and the people will never notice what hit them. You also don't have to completely kill them, you just have to weaken them. For an example of that look at the presidential candidate of some Eastern-Europe country that was poisoned.
This might sound radical, but I am not the one who invented the every increasing more efficient weaponry on which the US (and other nations) spend about a trillion dollars a year. Everything in the previous paragraph is technically already possible, and 80% is probably already implemented or could be operational in a year after the system is desired. Systems of control like that simply have never existed before in history.
In a country in which there exists an asymmetric power balance between large parts of the population and the government, you get tyranny. I am not suggesting that everyone should have access to their own nuclear bomb, but owning a gun or even a tank (if lots of people in the community vouch for you for example) should be perfectly reasonable and perhaps even mandatory.
To starting an armed struggle against the authorities. In this case, blood is spilled.
The street protests means that.
If you want to die against military trained killers, good luck with that.
Willingness to die is not the same thing that die.
To starting an armed struggle against the authorities. In this case, blood is spilled.
The street protests means that.
If you want to die against military trained killers, good luck with that.
Willingness to die is not the same thing that die.
A million thing can go wrong...
I feel a disturbance in the force...
Is it a revolution coming ?
",
"nested_level": 0
},
{
"id": 3281,
"thread_id": 241,
"source_id": "81",
"poster_name": "farmer_boy",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2334",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26027#msg26027",
"date": "2010-12-01T21:43:57Z",
"text": "I feel a disturbance in the force...
Is it a revolution coming ?
I think you need to check your Feel-Oh-Meter.
Talk to one of the members on the board of directors who has met with Julian he said he likes the idea and will pass it around.
",
"nested_level": 0
},
{
"id": 3283,
"thread_id": 241,
"source_id": "83",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26148#msg26148",
"date": "2010-12-02T05:47:16Z",
"text": "Talk to one of the members on the board of directors who has met with Julian he said he likes the idea and will pass it around.
Thats great!. Did you see the asshats added him to the interpol most wanted list? Some stupid politician even asked for his execution for treason. The idiotic part is that hes not even American
Stupid populism is stupid.
Ive heard the next leak will embarrass a major bank in the US . It would be ironic if they started accepting bitcoin before that happens.
It would be awesome.
",
"nested_level": 0
},
{
"id": 3285,
"thread_id": 241,
"source_id": "85",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26399#msg26399",
"date": "2010-12-03T13:09:11Z",
"text": "Fortunately, bitcoin is a distributed system, so it doesn't matter if they take out
Paypal just blocked them, and they're trying to get other US banks do the same. This would be a great moment to open bitcoin donations.
",
"nested_level": 0
},
{
"id": 3287,
"thread_id": 241,
"source_id": "87",
"poster_name": "S3052",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1488",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26738#msg26738",
"date": "2010-12-04T08:57:41Z",
"text": "as much as what's going on with wikileaks is not right,
do we really think it makes sense to push bitcoins into wikileaks is making sense in the current environment?
i am scared that this poses a big risk for bitcoins to consciously go against too many and too big enemies
It would potentially be much better to first make bitcoinbe far more widespread and accepted in a safe way vs going against the big ones already now
",
"nested_level": 0
},
{
"id": 3288,
"thread_id": 241,
"source_id": "88",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26740#msg26740",
"date": "2010-12-04T09:03:44Z",
"text": "as much as what's going on with wikileaks is not right,
do we really think it makes sense to push bitcoins into wikileaks is making sense in the current environment?
i am scared that this poses a big risk for bitcoins to consciously go against too many and too big enemies
It would potentially be much better to first make bitcoinbe far more widespread and accepted in a safe way vs going against the big ones already now
One thing I have learned in this community:
You can't prevent bitcoiners from doing whatever they want. They throw caution to the wind.
exactly this is both, a great benefit and also a great danger .
in the wikileaks case its a great danger.
As this is an open and free forum, I can at least voice my concerns
",
"nested_level": 0
},
{
"id": 3290,
"thread_id": 241,
"source_id": "90",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26747#msg26747",
"date": "2010-12-04T09:27:21Z",
"text": "Great danger? But wait, isn't bitcoin invincible?! (Well, perhaps if it adopts random ports, protocol obfuscation, DHT bootstrapping...)
",
"nested_level": 0
},
{
"id": 3291,
"thread_id": 241,
"source_id": "91",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26748#msg26748",
"date": "2010-12-04T09:30:34Z",
"text": "Lot of little Davids versus a few Goliaths. What can the worst happen?
",
"nested_level": 0
},
{
"id": 3292,
"thread_id": 241,
"source_id": "92",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26749#msg26749",
"date": "2010-12-04T09:59:27Z",
"text": "in the wikileaks case its a great danger.
+1, I agree completely
We know that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.
Does it make sense to actively give
multiple world governments incentive to shut down bitcoin?
No matter how symathetic wikileaks' cause... if you care about bitcoin's success, the answer is no.
worst case for me would be that bitcoin businesses would be forbidden .
Even if this would be wrong this would be the end of making bitcoins what most of us want.
then there will only be a handful of davids left but overall bitcoins would be forgotten soon
",
"nested_level": 0
},
{
"id": 3294,
"thread_id": 241,
"source_id": "94",
"poster_name": "S3052",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1488",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26753#msg26753",
"date": "2010-12-04T10:08:04Z",
"text": "in the wikileaks case its a great danger.
+1, I agree completely
We know that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.
Does it make sense to actively give
multiple world governments incentive to shut down bitcoin?
If you care about bitcoin's success, the answer is no.
That is exactly the issue.
I am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.
those who want to play this aggressive game against governments can do it, but i dont want to be connected to that.
I am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.
That's just stupid. I don't want to have any drug money in my wallet, but that is hard. 99% of all bank notes are tainted with cocaine, according to a british study.
http://news.bbc.co.uk/2/hi/uk_news/464200.stmDon't donate to Wikileaks if you don't want to. Wikileaks is perfectly legal in most countries. Only The US government, China and a few arab states takes measures to sensor Wikileaks.
There is nothing wrong with revealing the truth (i.e. from Wikileaks. In this respect, I like a lot the concept behind Wikileaks).
All I am saying is that it is suicide for bitcoins to connect with Wikileaks today, where many big powers are against.
The time is not ripe yet.
It's like a runner who wants to run a marathon. He better trains a bit before trying.
",
"nested_level": 0
},
{
"id": 3297,
"thread_id": 241,
"source_id": "97",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26760#msg26760",
"date": "2010-12-04T11:16:29Z",
"text": "I also think that they try to ban bitcoin business. But I also remember that monitoring of financial flows for combat with organized crime came only 50 years ago and it is unnatural. And that monitoring works worse and worse every year.
",
"nested_level": 0
},
{
"id": 3298,
"thread_id": 241,
"source_id": "98",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26761#msg26761",
"date": "2010-12-04T11:21:35Z",
"text": "In any case, I think this is the happiest opportunity that happens in any very successful project
",
"nested_level": 0
},
{
"id": 3299,
"thread_id": 241,
"source_id": "99",
"poster_name": "Bruce Wagner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2033",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26805#msg26805",
"date": "2010-12-04T16:48:23Z",
"text": "This is very well-written, and he is very well spoken...
I believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.
If you're reading this, you're part of the vanguard building the new economy and the new world. Mainstream acceptance will come by weight of numbers and via network effects. Who ever heard of Wikileaks or Twitter four years ago? And today we've got Admiral Chairman-of-the-Joint-Fucking-Chiefs Mullen tweeting his dismay over Wikileaks -- no doubt via the intermediation of an office full of PR analysts and bureaucrats, at extremely low relative impact.
BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help?
I agree 100%.
in the wikileaks case its a great danger.
+1, I agree completely
We know that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.
Does it make sense to actively give
multiple world governments incentive to shut down bitcoin?
No matter how symathetic wikileaks' cause... if you care about bitcoin's success, the answer is no.
This is a very good point.
\"PayPal Freezes WikiLeaks Account\"
http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/We must weigh...
---> the potential financial benefit bitcoin would give to wikileaks at This moment
vs.
---> the potential demise of bitcoin itself (or at least the impact of bitcoin being mortally wounded at this very early stage of its existence.)
I think that -- no matter how righteous anyone may feel about the work wikileaks does...
1. They don't need that much money to do what they do.
2. What they could potentially get via bitcoin at the moment wouldn't be a drop in the bucket of what they're receiving via other private means.
3. Nothing wikileaks is doing is WORTH the potential demise of Bitcoin.
We don't need to make Bitcoin, or each of US for that matter, into targets of world governments. Especially not so early in Bitcoin's life.
Wikileaks is probably being funded, at least partially, by other governments with interests in leaking damaging information.
But in any case, Wikileaks probably has a bankroll larger than the ENTIRE bitcoin economy at this point in time.
Also, when you create a new Iron Man suit in your lab, you don't take on all the militaries of the world on your first trip out on the \"test track\". Bitcoin is still in \"beta\", remember.
I say, we MUST get Bitcoin accepted at Starbucks and the local grocery store.... BEFORE it gets accepted at Wikileaks.
Then, we'll have a chance.
Starbucks. Anyone have contact info for them?
very well explained
+1
",
"nested_level": 0
},
{
"id": 3302,
"thread_id": 241,
"source_id": "102",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26829#msg26829",
"date": "2010-12-04T18:53:35Z",
"text": "Your torment understandable but really nothing does depend from us. For WikiLeaks crew does not cost anything to setup the client, to generate the address and publish it.
So we must just pray to our gods that they may take our point of view.
",
"nested_level": 0
},
{
"id": 3303,
"thread_id": 241,
"source_id": "103",
"poster_name": "Bruce Wagner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2033",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26832#msg26832",
"date": "2010-12-04T19:07:37Z",
"text": "By the way, the greatest benefit Bitcoin could give to Wikileaks... MIGHT be in them using Bitcoin PRIVATELY.... not PUBLICLY.
They could ( / can / will / are / ? ) use Bitcoin to transmit their funds easily across all borders, exchange them into all currencies as needed, and even Back Them Up electronically (as long as their wallet.dat file is encrypted too). There's no need for them to advertise publicly that they are using Bitcoin.... for them to benefit from all the advantages of using Bitcoin privately/secretly/anonymously.
It would be Much Better for Everyone Involved if they do NOT express their support for Bitcoin publicly... and they just go about using it very privately. (And who's to say that they aren't already...?)
",
"nested_level": 0
},
{
"id": 3304,
"thread_id": 241,
"source_id": "104",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26833#msg26833",
"date": "2010-12-04T19:08:23Z",
"text": "Yes, there are arguments for not pushing bitcoins as a solution for orgs such as wikileaks.
On the other hand, the same crowd that is attracted to sites such as wikileaks will be attracted to a distributed currency, it would also be a way to gain popularity, coders, crypto people auditing the protocol, and so on. That way, the project can grow.
Everything is a compromise...
",
"nested_level": 0
},
{
"id": 3305,
"thread_id": 241,
"source_id": "105",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26835#msg26835",
"date": "2010-12-04T19:15:13Z",
"text": "I suspect the first targets if Bitcoin got associated with Wikileaks would not be miners or participants, but the money changers. People buying and selling Bitcoins for dollars and other currencies would be natural targets for shutting down. Without them, Bitcoin is back to being play money.
",
"nested_level": 0
},
{
"id": 3306,
"thread_id": 241,
"source_id": "106",
"poster_name": "Bruce Wagner",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2033",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26836#msg26836",
"date": "2010-12-04T19:16:06Z",
"text": "Yes, there are arguments for not pushing bitcoins as a solution for orgs such as wikileaks.
On the other hand, the same crowd that is attracted to sites such as wikileaks will be attracted to a distributed currency, it would also be a way to gain popularity, coders, crypto people auditing the protocol, and so on. That way, the project can grow.
Everything is a compromise...
Problem is... It would attract 9 world governments, along with their Intelligence Services (thier CIA's), trying to shut down Bitcoin.... for every one new crypto coder supporter.
Let's achieve this result through POSITIVE publicity.... not NEGATIVE publicity.
Do we want Bitcoin to be known forever in slang as, \"Wilileaks Money\"? No.
Let's get Whole Foods, and McDonalds, and Startbucks, and Cocacola vending machines.... to accept Bitcoin.
In fact, the BEST POSITIVE publicity is not even businesses.... It is famous charities!
Red Cross, UNICEF, United Way, etc. Would you rather Bitcoin be known as \"wikileaks money\".... or \"the money large charites use for donations\"....?
Think of all these ideas from a PR perspective. Bitcoin needs SUPPORTERS. It needs to make no enemies.... not yet. It's too weak to take on enemies right now.
It wasn't exactly frozen. It was restricted, and Wikileaks can't take donations directly via PayPal anymore. Hardly a problem, since several other organizations take donations to Wikileaks. No funds are confiscated in any country or bank, as far as public information goes anyway. None of the newspapers publishing the leaks in full have gotten their bank accounts frozen either. Their operation is perfectly legal in every country with free speech. This is nothing but a publicity stunt for PayPal, and it would be a better publicity stunt for the Bitcoin community to to the opposite.
-1. I think you are overreacting.
It wasn't exactly frozen. It was restricted, and Wikileaks can't take donations directly via PayPal anymore. Hardly a problem, since several other organizations take donations to Wikileaks. No funds are confiscated in any country or bank, as far as public information goes anyway. None of the newspapers publishing the leaks in full have gotten their bank accounts frozen either. Their operation is perfectly legal in every country with free speech. This is nothing but a publicity stunt for PayPal, and it would be a better publicity stunt for the Bitcoin community to to the opposite.
-1. I think you are overreacting.
This is not true. When PayPal shuts down your account, they TAKE and KEEP all of the money in it. There is no refund. Never. Never. Their email tells you that \"there is no process to appeal\". PayPay is owned by eBay. ....and the \"e\" in eBay stands for \"evil\". Google \"PayPay\" it if you don't believe me.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Yes -- the leaker can be considered a traitor.
Wikileaks are not the people that leaked the information though. They are simply a press organization that likes transparency and does not take sides with any government or big corporation. They got sent the information and they do what any media would do, they publish. Which is, in my opinion, very refreshing and good for democracy.
Ignore all the fuss about traitors, terrorists, and other distorting comments. Those people don't understand it, don't repeat them.
Ignore all the fuss about traitors, terrorists, and other distorting comments. Those people don't understand it, don't repeat them.
Security is not made by invading foreign nation and inadvertently increasing heroin production in the process, inadvertently killing more Americans through heroin overdose...
Fortunately, bitcoin is a distributed system, so it doesn't matter if they take out
I meant to write: \"Fortunately, Wikileaks is a distributed organization, so it doesn't matter if they take out the current \"leader\", Assange.\"
Looking on the bright side, if Bitcoin did get known as the Wikileaks currency, attacked by governments all over the world, at least we'd get our Wikipedia page back!
",
"nested_level": 0
},
{
"id": 3313,
"thread_id": 241,
"source_id": "113",
"poster_name": "sturle",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1876",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26867#msg26867",
"date": "2010-12-04T21:38:29Z",
"text": "It wasn't exactly frozen. It was restricted, [...]
-1. I think you are overreacting.
This is not true. When PayPal shuts down your account, they TAKE and KEEP all of the money in it.
True, but according to
the PayPal blog, it wasn't closed. It was restricted. It cannot receive donations, but it doesn't say anywhere it was closed, shut down or confiscated.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Wikileaks have not stolen any secrets or signed any confidentiality agreements. They are just printing documents given to them by other people. The people who gave the secret documents to Wikileaks were probably doing something illegal. Not Wikileaks, or the newspapers which printed the leaked documents before they were available from Wikileaks. So, why aren't the editors of the newspapers arrested, threatened to be murdered, getting their servers and DNS shut down., accounts closed, etc? Because what they are doing is perfectly legal, and so is Wikileaks. Just unpopular among some who believes the press should write what the government tells them to write.
Looking on the bright side, if Bitcoin did get known as the Wikileaks currency, attacked by governments all over the world, at least we'd get our Wikipedia page back!
This is so true. There certainly wouldn't be a shortage of \"reliable sources\" about Bitcoins at that point. I think it would likely show up on the front page of most newspapers and be talked about extensively on both radio talk shows and the other broadcast networks too.
For myself, I'm getting to the point to say \"bring it on\" in regards to Wikileaks. Note that I'm using my real name here instead of a psuedonym and I'm willing to personally say \"bring it on\" in terms of being associated with Bitcoins as a project. I've had police come into my house without my permission already and do all kind of stupid stuff, so for me that line being crossed has already happened. I am also connected to enough people politically that if something was to happen to me that it would be noted and things would happen too.
It is the morally correct thing to be supporting Wikileaks, and if they'll take a few of my bitcoins, I not only want to donate but to let the world know that they can donate to Wikileaks through Bitcoins as well.
I can't speak for everybody here in the Bitcoins community but I am speaking for myself on this matter, and I'm not afraid of anything that the U.S. government might do to me if I was associated with backing Wikileaks financially. If anything, it would show that I no longer live under a constitutional government any more. If the U.S. government wants to tip their hand to expose themselves in that way, so be it. If the U.S. government kills me or puts me in jail, I'll certainly set a way for this community to find out. I really don't think it would come to that either, but I don't care if it did.
If I have to \"vote\" on this matter, I would encourage the Bitcoin community to take up the plate like we did with the EFF and encourage Wikileaks to put up a Bitcoin address on their website for donations. It would bring in some new blood into the Bitcoin community regardless, and it might be beneficial to Wikileaks as well. Leave it to Wikileaks to see if they want to use Bitcoins or not. In terms of governmental review of Bitcoins, we know that is going to happen sooner or later, so why are we fighting that inevitable result? Anything other than a low-key investigation is only going to make more people interested in Bitcoins, which is only going to help the project even more. It can't be killed as a project, only slowed down a little bit in its growth at this point and more likely its adoption would be accelerated by any kind of publicity that would happen.
The only possible concern I would have is over how sound the protocol itself is right now. If anything, a major flux of new people into Bitcoins would help there too, and the worst that could happen is that Bitcoins itself would be broken in some way where a new cryptocurrency would have to be created fixing the problems of Bitcoins. It is the idea of cryptocurrency that would then persist, and it is incredibly hard to censor an idea.
Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
-- Robert S. Horning
Logan, Utah
\"Fortunately, Wikileaks is a distributed organization, so it doesn't matter if they take out the current \"leader\", Assange.\"
Well, it does matter a bit if you happen to be Assange.
Interestingly, it turns out there is some
Wikileaks infighting, probably upset at Assange's leadership:
Assange: That is a procedural issue. Don\u0092t play games with me.
Domscheit-Berg: stop shooting at messengers
Assange: I\u0092ve had it.
Domscheit-Berg: likewise, and that doesnt go just for me
Assange: If you do not answer the question, you will be removed.
Domscheit-Berg: you are not anyones king or god
Domscheit-Berg: and you\u0092re not even fulfilling your role as a leader right now
Domscheit-Berg: a leader communicates and cultivates trust in himself
Domscheit-Berg: you are doing the exact opposite
Domscheit-Berg: you behave like some kind of emporer or slave trader
Assange: You are suspended for one month, effective immediately.
Domscheit-Berg: haha
Domscheit-Berg: right
Domscheit-Berg: because of what?
Domscheit-Berg: and who even says that?
Domscheit-Berg: you? another adhoc decision?
Assange: If you wish to appeal, you will be heard on Tuesday.
So maybe a leaderless organization is the better direction for WikiLeaks to go? Opinions?
...
I can't speak for everybody here in the Bitcoins community but I am speaking for myself on this matter, and I'm not afraid of anything that the U.S. government might do to me if I was associated with backing Wikileaks financially. If anything, it would show that I no longer live under a constitutional government any more. If the U.S. government wants to tip their hand to expose themselves in that way, so be it. If the U.S. government kills me or puts me in jail, I'll certainly set a way for this community to find out. I really don't think it would come to that either, but I don't care if it did.
...
Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
Amen, RHorning! As
The Voluntaryists argue,
Governments must cloak their actions in an aura of moral legitimacy in order to sustain their power. If the U.S. government wants to tip their hand to expose themselves in that way, so be it. Without an aura of moral legitimacy, they will be seen as the gang that they truly are.
So maybe a leaderless organization is the better direction for WikiLeaks to go? Opinions?
There's alway a leader of some kind. It might be a person with a high reputation.
Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
Thanks for being willing to helpfully
impose risk upon others. For people who are just starting to build businesses on bitcoin, this could be devastating to their new business.
And it could permanently marginalize bitcoin, keeping it out of the mainstream for good. Is that really the end result the bitcoin community most desires?
Some of us are working hard to build tools and programs that encourage businesses to invest their time, money and energy into bitcoin. It would be very sad to see all that go down the drain.
Success is not guaranteed; access risk; act wisely; remember knowledge gaps.
It's funny to see a miniarchist libertarian say \"Bring it on\" when anarchists like me are advising cautions.
It look like I am right, people throw cautions to the wind.
",
"nested_level": 0
},
{
"id": 3320,
"thread_id": 241,
"source_id": "120",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26898#msg26898",
"date": "2010-12-04T23:16:03Z",
"text": "Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
Thanks for being willing to helpfully
impose risk upon others. For people who are just starting to build businesses on bitcoin, this could be devastating to their new business.
And it could permanently marginalize bitcoin, keeping it out of the mainstream for good. Is that really the end result the bitcoin community most desires?
Some of us are working hard to build tools and programs that encourage businesses to invest their time, money and energy into bitcoin. It would be very sad to see all that go down the drain.
What would go down the drain? Really, I think this is making a mountain out of a molehill and if you want to stay anonymous I'm not necessarily stopping you from doing that either. Some are willing to stand up and others want to hide in the background. I choose to stand in front if that is necessary. Many are participating on this project using a pseudonym, and if they are very paranoid through a Proxy IP address and using https for communications to this forum and perhaps taking other precautions. I am not, because I'm not afraid. I'm not necessarily against anonymity and even would encourage it for those who find it necessary for whatever reason they have.
In short, I don't wish to impose this risk upon others but I am willing to take this risk for myself.
I also fail to see how this would marginalize Bitcoin as a software project either. The best thing, from a political perspective, would be to completely ignore that Bitcoin even exists at all. If that is marginalizing Bitcion, how is that different from what is going on right now?
I suppose the hope here is that Bitcoin will be used by a bunch of people first (it already is) and that perhaps Bitcoin can be known for doing other things than financing Wikileaks. I am not encouraging that the main page of bitcoin.org have a huge banner across the top \"the official fundraising method for Wikileaks\". We don't have to tie ourselves that closely, and anybody who checks out Bitcoin will discover what it is.... an alternative to PayPal and other on-line financial transaction systems with perhaps some other interesting benefits as well. Is that necessarily a bad thing? Is there anything new that hasn't been said repeatedly elsewhere? If you were trying to stay off people's radar, publicity should be avoided altogether.
This is also about doing what is right, and this is the right thing to do. I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too. There is a down side, and talking about concerns over that perhaps is useful.
Success is not guaranteed; access risk; act wisely; remember knowledge gaps.
It's funny to see a miniarchist libertarian say \"Bring it on\" when anarchists like me are advising cautions.
It look like I am right, people throw cautions to the wind.
I agree, success is not guaranteed. Sometimes you have to take some risks and sometimes do so with imperfect knowledge. It is a golden opportunity right now for the Bitcoin community, however, to encourage Wikileaks to accept Bitcoin donations and I personally don't think the extra publicity that we may or may not get from having a link on the Wikileaks website would necessarily be a bad thing. There isn't even any sort of guarantee that Wikileaks will even take Bitcoins if they are being offered.
But seriously, what are the downsides anyway? Do you really think the \"Men in Black\" are going to shut down Bitcoin? Really? If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?
This is also about doing what is right, and this is the right thing to do. I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too. There is a down side, and talking about concerns over that perhaps is useful.
Your stand could impact
my money, and everyone else's. Don't pretend your actions could impact only you.
If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?
Exactly. I feel the same way. Survival of the fittest. If bitcoin has some fundamental flaw, it will not be able to survive a government attack. Then it is better to weed it out now, so we aren't wasting our time promoting something that will not work, and can instead devote our resources and time to other efforts that hopefully will work and to other currencies to build up the alternative economy.
This is also about doing what is right, and this is the right thing to do. I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too. There is a down side, and talking about concerns over that perhaps is useful.
Your stand could impact
my money, and everyone else's. Don't pretend your actions could impact only you.
I have spent many hours reading through the bitcoin forums about its robustness and resiliency to attacks...asking so many questions \"What if the government does X?\", and I have come to the conclusion that basically, bitcoin can't be shut down absent shutting down the internet. But the government wouldn't likely not shut down the internet, since they depend on tax revenue for their operations. If bitcoin has some flaw, then we need to resolve it now.
If bitcoin has some flaw, then we need to resolve it now.
I suggest assembling a tiger team or make security bounties or do both.
But, you have to remember that the security of the network also come from the strength of people running it. So, wikileaks might add more legit computing power rather than cheating nodes, or not. It's hard to know.
Brute-force attacks are least likely. We probably have some bugs lurking in the system.
If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?
Exactly. I feel the same way. Survival of the fittest. If bitcoin has some fundamental flaw, it will not be able to survive a government attack. Then it is better to weed it out now, so we aren't wasting our time promoting something that will not work, and can instead devote our resources and time to other efforts that hopefully will work and to other currencies to build up the alternative economy.
This is also about doing what is right, and this is the right thing to do. I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too. There is a down side, and talking about concerns over that perhaps is useful.
Your stand could impact
my money, and everyone else's. Don't pretend your actions could impact only you.
I have spent many hours reading through the bitcoin forums about its robustness and resiliency to attacks...asking so many questions \"What if the government does X?\", and I have come to the conclusion that basically, bitcoin can't be shut down absent shutting down the internet. But the government wouldn't likely not shut down the internet, since they depend on tax revenue for their operations. If bitcoin has some flaw, then we need to resolve it now.
I approve of this message. If Bitcoin blows up, a new system can be build without this flaw. The probability of Bitcoin _not_ containing some fatal flaw is pretty small (as almost all software has flaws).
All Wikileaks needs to do is say \"Following the PayPal incident we have decided to accept a new kind of payment, Bitcoins. You can find more information on donating via Bitcoins on URL <some suitable URL hosted by Wikileaks>. \"
They could post it in their news section or something like that. It is possible that main stream media would pick it up if they would contrast Bitcoin with PayPal like that.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Yes -- the leaker can be considered a traitor.
One that note, I smell a rat. I've worked for the beast, and there is
no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.
There is no way this kid did this.
in the wikileaks case its a great danger.
+1, I agree completely
We know that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.
Does it make sense to actively give
multiple world governments incentive to shut down bitcoin?
If you care about bitcoin's success, the answer is no.
That is exactly the issue.
I am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.
those who want to play this aggressive game against governments can do it, but i dont want to be connected to that.
Agreed, i have already spoken about this in some other wikileaks-related topic (or perhaps this one ?).
Engaging in wikileaks before Bitcoin has a chance to unfold its wings may kill it.
Engaging in wikileaks before Bitcoin has a chance to unfold its wings may kill it.
It may allows us to unfold our wings.
Beside, what is done, done. Bob182 already talked to a person within the wikileak organization.
But there are much safer route to unfolding our wings.
We should be doing something to get a full security audit done on bitcoins. Something we can point to that is third party and not connected to bitcoin in any way. Now who do we contact to get this done?
This should be our first priority rather than engaging in political statements.
Edit: Bradley Manning supposedly leaked the documents NOT Julian Assange.
the US government cant even beat a few fighters in the afghanistan dessert...
The bigger concern is the international banking mafia.
They are the real scary ones.
We should be doing something to get a full security audit done on bitcoins. Something we can point to that is third party and not connected to bitcoin in any way. Now who do we contact to get this done?
I don't have money but I think we should set up a bitcoin bounty for security, like I been suggesting everywhere. It will be a start.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Yes -- the leaker can be considered a traitor.
One that note, I smell a rat. I've worked for the beast, and there is
no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.
There is no way this kid did this.
I'm glad that you have left the dark side, creighto. You make an interesting point that a private could not have gotten access to all this (but then again, some of these gubbamint bureacracies are extremely inefficient). Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught. Anyway, it's all speculation.
Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught. Anyway, it's all speculation.
A top secret anarchist cabal penetrated the US government. It's simple really.
Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught. Anyway, it's all speculation.
A top secret anarchist cabal penetrated the US government. It's simple really.
It is entirely possible. Some government agent may have converted to anarchism after climbing up the ranks and then accidentally reading Rothbard or some other anti-statist philosopher or website. Or maybe just saw the crap going around him and decided he is an anarchist.
Or maybe just saw the crap going around him and decided he is an anarchist.
Using that guy as a sacrificial lamb isn't exactly what I called, anarchistic. Unless, he agreed to cover for the real leaker.
Or maybe just saw the crap going around him and decided he is an anarchist.
Using that guy as a sacrificial lamb isn't exactly what I called, anarchistic. Unless, he agreed to cover for the real leaker.
Of course. And yeah, it could have been a voluntary decision. Also, it could be possible that the secret upper-level anarchist did not intend for Manning to be blamed...but then once Manning got arrested, he realized it would be better if he kept quiet, so that only one person is in jail.
Also, leaking military secrets can be considered treason and is a very serious crime in most countries. Free Speech always has legal limits.
Yes -- the leaker can be considered a traitor.
One that note, I smell a rat. I've worked for the beast, and there is
no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.
There is no way this kid did this.
I'm glad that you have left the dark side, creighto.
Perhaps you assume too much.
You make an interesting point that a private could not have gotten access to all this (but then again, some of these gubbamint bureacracies are extremely inefficient).
Inefficient yes, but ineffective? Paranoia is what the government is
good at. No way this kid did this, not even a small part of it. He is either a gov'ment patsy, or a martyr for some other group.
The government is no less likely to form internal factions over ideology or self-interest than any other collective agency. This smells like an inside job, and from what I've seen so far, it seems to make the Bush admin seem less stupid|evil, even if only by comparison.
Seems that the main politician this embarrassed was Hillary Clinton.
Either the pentagon or the cia leaked these papers.
*Points finger at Robert Gates .
Seems that the main politician this embarrassed was Hillary Clinton.
Either the pentagon or the cia leaked these papers.
*Points finger at Robert Gates .
I'm sorry...I'm not totally following you...could you elaborate? Why would Robert Gates want to release videos of US Troops murdering Iraqi civilians?
With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up.
",
"nested_level": 0
},
{
"id": 3339,
"thread_id": 241,
"source_id": "139",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26988#msg26988",
"date": "2010-12-05T08:02:58Z",
"text": "With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up.
So you decide to ignore the long discussion and just do it?
Listen to people's argument, make a decision, give a reasoned case for what you're going to do, and then do it.
Also, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf.
With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up.
So you decide to ignore the long discussion and just do it?
Listen to reasons, and then decide if you're going to keep doing what you do.
Kiba makes some good points here...let's not be too hasty in communicating with WikiLeaks. Patience is key. There is no need to repeatedly pressure WikiLeaks in producing a bitcon donate address. Since you have already communicated with them once, they may either he considering it or more likely have decided that it does nor suit their needs currently. Don't get me wrong...I am all for wikileaks to use bitcoin, but let's not push this too hard.
Its seems all you want is your business to not be taxed that we will be free if we have competition and all that.
This is not an issue of rightwing vs leftwing.
Its an issue of freedom of press and the fact they need a anonymous network of donations.
I bet you don't ever see the oppression around society and decide to go out and do some direct action. Like in the case of the ashvi11e eleven or oscar grant. Instead you want to have more money and create the perfect economy. For revolution we need social change before economic. Wikileaks can be the first step to achieving this against the government. That's why I'm deciding to contact and explain to them the benefits of bitcoin.
em3rgent order
I'm just checking up getting the userbase on board with the idea. Trying to see if anyone else thinks its a possible good way to get donations on there site without having things shut down, same as the bitDNS project if we code it and wikileaks uses it will we all pussy out as they are deemed a terrorist organization?
",
"nested_level": 0
},
{
"id": 3342,
"thread_id": 241,
"source_id": "142",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26991#msg26991",
"date": "2010-12-05T08:15:21Z",
"text": "Also, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf.
bob182 is certainly not acting on my behalf, nor several others, as these threads seem to indicate.
And for Pete's sake, bob182, please don't misrepresent yourself as some sort of official Bitcoin representative.
Wikileaks is the enemy of major world powers right now, with many influential elites feeling that Assange committed an act of war against the United States, or, at a minimum, irrevocably disrupted world affairs. This is not some mailing list discussion or theoretical exercise; there are very real, very powerful organizations actively targetting wikileaks' network infrastructure, organizational infrastructure, and most importantly, financial infrastructure.
It is extraordinarily unwise to make bitcoin such a highly visible target, at such an early stage in this project. There could be a lot of \"collateral damage\" in the bitcoin community while you make your principled stand.
Its seems all you want is your business to not be taxed that we will be free if we have competition and all that.
This is not an issue of rightwing vs leftwing.
Its an issue of freedom of press and the fact they need a anonymous network of donations.
I bet you don't ever see the oppression around society and decide to go out and do some direct action. Like in the case of the ashvi11e eleven or oscar grant. Instead you want to have more money and create the perfect economy. For revolution we need social change before economic. Wikileaks can be the first step to achieving this against the government. That's why I'm deciding to contact and explain to them the benefits of bitcoin.
This is god awful reasoning that didn't address any of my concerns, or jgarzik, or any others.
We also have no ideas what the heck you're saying to these people.
Also, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf.
bob182 is certainly not acting on my behalf, nor several others, as these threads seem to indicate.
And for Pete's sake, bob182, please don't misrepresent yourself as some sort of official Bitcoin representative.
bober182 doesn't need to have anybody's permission to do anything. Even if he were to present himself as being 'official', the Wikileaks people are probably smarter than the average visitor of this forum, so they would be able to figure that out in less than a minute.
Does anyone have an idea of how large the Wikileaks group is? I know one guy who is in it, but two guys don't make a group
I suppose the actual members are a secret, but is the number too?
Or, to put in military terms, we know that wikileaks' entire financial infrastructure is being actively targeted, and The Powers That Be have successfully
destroyed one target in the past 24 hours.
Only cannon fodder would stand up and wave a red flag that says \"shoot me\" at such a point in time
bober182 doesn't need to have anybody's permission to do anything.
This isn't about a permission issue.
I just want bober182 to be a responsible member of the community. He's going in there, contacting the organization, when it is clear that members of the community don't think it is the best idea. He didn't address any of our concerns. He didn't give us any details what he is planning to do, except putting additional \"pressure\" which could mean anything from \"being pushy\" or selling \"snake oil\".
This is akin to somebody just go in there, with no plans and guns blazing, costing half of his squads and then costing us a war in the long run.
The wikileaks board of directors has 10 members + JA, then there are about 150~200 staff, and under that are 1400 volunteers.
",
"nested_level": 0
},
{
"id": 3348,
"satoshi_id": 523,
"thread_id": 241,
"source_id": "148",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Wikileaks contact info?",
"url": "https://bitcointalk.org/index.php?topic=1735.msg26999#msg26999",
"date": "2010-12-05T09:08:08Z",
"text": "Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
No, don't \"bring it on\".
The project needs to grow gradually so the software can be strengthened along the way.
I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.
Version 0.3.15 is now available.
Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo
",
"nested_level": 0
},
{
"id": 3350,
"thread_id": 243,
"source_id": "1",
"poster_name": "ByteCoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=490",
"subject": "Need OP_BLOCKNUMBER to allow \"time\" limited transactions",
"url": "https://bitcointalk.org/index.php?topic=1786.msg21998#msg21998",
"date": "2010-11-15T01:17:03Z",
"text": "At the moment, if you make a payment to someone but they've wiped their wallet then the coins are irretrievably lost.
Similarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can't reissue that payment backed by the same coins but with a fee.
If you could cause the current block number to be pushed on the stack and do some maths with it then you could implement a payment that must be spent by the recipient before a certain block number is reached or else the script would allow it to be spent again by the sender for example.
I suspect that this would be a very popular transaction mechanic.
ByteCoin
",
"nested_level": 0
},
{
"id": 3351,
"thread_id": 243,
"source_id": "2",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Need OP_BLOCKNUMBER to allow \"time\" limited transactions",
"url": "https://bitcointalk.org/index.php?topic=1786.msg22003#msg22003",
"date": "2010-11-15T01:49:59Z",
"text": "That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.
",
"nested_level": 0
},
{
"id": 3352,
"thread_id": 243,
"source_id": "3",
"poster_name": "ByteCoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=490",
"subject": "Re: Need OP_BLOCKNUMBER to allow \"time\" limited transactions",
"url": "https://bitcointalk.org/index.php?topic=1786.msg22014#msg22014",
"date": "2010-11-15T02:47:30Z",
"text": "That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.
Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal.
Please go into more detail about why this is not good for the network.
ByteCoin
Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal.
Please go into more detail about why this is not good for the network.
You may be right about this. Bitcoin's segmentation-fixing mechanisms would seem to keep everything in order.
A similar feature seems to already be planned. Every transaction has the currently-unused \"nLockTime\" field, and this bit of code exists for the UI (the text would appear in the same place as \"x confirmations\"):
if (!wtx.IsFinal())
{
if (wtx.nLockTime < 500000000)
return strprintf(_(\"Open for %d blocks\"), nBestHeight - wtx.nLockTime);
else
return strprintf(_(\"Open until %s\"), DateTimeStr(wtx.nLockTime).c_str());
}
Sounds very much like what you're thinking of.
After investigating some more, I found that nLockTime requires in-memory transaction replacement to be re-activated for it to be useful.
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (!IsNewerThan(*ptxOld))
return false;
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)
return false;
}
break;
We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.
nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.
",
"nested_level": 0
},
{
"id": 3356,
"thread_id": 244,
"source_id": "1",
"poster_name": "appamatto",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1958",
"subject": "BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22019#msg22019",
"date": "2010-11-15T03:02:31Z",
"text": "This is based on a discussion on 11/14/2010 on the IRC channel.
BitDNS
Although there have been attempts to tackle DNS in a distributed way in the past, I don't think there have been solutions that have fully removed authority from the equation.
If there was such a solution, it probably would have been able to implement bitcoin directly on top of it, and we all know that didn't happen.
However, it seems possible to create a bitcoin clone (bitDNS) that provides a solution to distributed authority-free name allocation and transfer.
Basically, the system is a copy of bitcoin where miners generate 50 new name mappings of their choosing whenever they win a block. The name mappings change hands in a way similar to btc.
This system is separate from btc, and it is likely that escrow services will provide a name market in btc, since any such escrow can leverage the two block chains to verify transactions. Miners can pick names that are already being bid upon with funds in escrow to make sure they are able to sell generated names quickly.
Generalizing Bitcoin: BitX
This is all well and good, but now there are two block chains, and any given miner can only generate for one at a time. This will be really bad when even more clever applications are developed that require bitcoin-like properties but will be susceptible to attack in their early development. Enter BitX, designed to support any and every such application on a single block chain.
BitX has a block chain like bitcoin's. However, miners choose to distribute arbitrary application data in the following manner:
1) The payload in a block is a mapping from application names to hashes: [\"bitcoin\": <hash>, \"bitDNS\": <hash>, \"bitHaiku\": <hash>, ...]
2) Any given block is only allowed to create one new application that does not already appear somewhere in the block chain. This is to prevent spam.
3) Any given block may omit data for any application. Similarly to the current situation, miners have a choice as to what transactions to include, and this extends to the choice over which applications to choose to send data for.
4) Application data is transfered separately, so for instance a bitcoin client will never have to care about haikus or DNS names, as it can simply ask someone for the bitcoin payload and make sure it matches the hash in the appropriate block.
5) On the client side, blocks are only ever rejected for an error relating to the previous four points. In other words, blocks aren't rejected for carrying a faulty bitcoin payload, because this might result in rejecting valid DNS transfers. Instead, bitcoin clients accept the most recent block but ignore the invalid bitcoin transactions.
Miners will engage in activities they feel profitable. For example, miners may not see a profit motive in haikus, but will want to generate DNS names because they can be sold easily. I think this system could support a very wide range of useful applications while adding only a minimal overhead to the block chain itself. Application proliferation is kept in check by the interests of the miners themselves.
This also seems to make the block chain more modular, as it separates concerns; the block chain is strictly for creating a universal state of the system for everyone in the world, and application data travels out of band but is verified against the block chain.
One effect of the modularity is that applications can ignore illegal or undesirable application data and only download payloads for the applications they care about.
As a last thought: BitX poses a significant threat to bitcoin, because money may not be the \"killer app\" for the block chain. In other words, what happens when bitBeanieBabies becomes bigger than bitcoin? Suddenly the bitcoin system doesn't seem as secure. If both were running on top of BitX, they would enhance each other's security, and interfere with one another minimally.
Thanks for reading,
Appamatto
",
"nested_level": 0
},
{
"id": 3357,
"thread_id": 244,
"source_id": "2",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22138#msg22138",
"date": "2010-11-15T20:40:32Z",
"text": "Just for reference, the discussion on IRC starts here
http://bit.ly/9qjLL5So....
I want to register a new domain name \"gavin.bitdns\" in this hypothetical bitdns system.
How do I do it? Run a BitX miner and hope that I generate a block sometime in the next week or three? Ummm... yuck!
Or I want to buy a domain from somebody; what does that look like in the bitdns system?
",
"nested_level": 0
},
{
"id": 3359,
"thread_id": 244,
"source_id": "4",
"poster_name": "appamatto",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1958",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22204#msg22204",
"date": "2010-11-16T03:06:26Z",
"text": "So....
I want to register a new domain name \"gavin.bitdns\" in this hypothetical bitdns system.
How do I do it? Run a BitX miner and hope that I generate a block sometime in the next week or three? Ummm... yuck!
Or I want to buy a domain from somebody; what does that look like in the bitdns system?
It's pretty much the same as starting a separate service. You have to convince a few people to use your system.
But in this case, there are some incentives for a BitX miner to adopt your new BitX app (in this case, bitDNS).
For one, it doesn't impact the miner's mining speed. And he would end up with a possibly valuable resource in the form of a very big head start on bitDNS registrations.
Consider the case in which there are 5 big BitX miners that each control large processing pools. They each generate 20% of bitcoins (which is now running on the BitX protocol) yet the first one to generate bitDNS names would generate 100% of names until the second adopted bitDNS as well, and this would be at no cost to him.
In the case of buying a name, you need an escrow that will temporarily hold the btc and the name until they are both confirmed, and then pass them along to the new owners. I think it's best to keep btc and dns completely separate so that they can succeed or fail independently yet leverage the single block chain.
I thought about the BitX block format more today, and (with the help of ByteCoin on irc) decided that block rejection is an important part of the system. So, the format would work more or less like the following:
<previous block hash>
<timestamp>
<hash of app name> <hash of app data> <previous app block offset>
<hash of app name> ....
<nonce>
Basically, there is the BitX block chain which is maintained in the first field. But there are also \"subchains\" for each app. The \"previous app block offset\" is the number of blocks to travel backwards in the chain to find the last previous block for this app.
Omitting some details, a Bitcoin fork would appear as follows, inside a non-forked BitX chain:
block 0:
<empty, this is the genesis block>
(bitcoin) datahash... 0
A previous app block offset of zero indicates that this is a genesis block for that app. Each BitX block is only allowed to specify a genesis block for one app.
block 1:
<hash of block 0>
(bitcoin) datahash... 1
This is a continuation of the last BitX block and it also claims to be a successor of the previous block's bitcoin chain.
block 2:
<hash of block 1>
<empty>
It's perfectly legit for any given application to not appear in a block.
block 3:
<hash of block 2>
(bitcoin) datahash... 3
This is a continuation of the BitX chain, but it has rejected the previous bitcoin block. Clients will now have to accept one bitcoin app block and reject the other, but there is no reason to reject the BitX block. The rejected bitcoin app block will stay in the BitX block chain, but it will not be part of the longest valid bitcoin block chain.
Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.
",
"nested_level": 0
},
{
"id": 3362,
"thread_id": 244,
"source_id": "7",
"poster_name": "appamatto",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1958",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22276#msg22276",
"date": "2010-11-16T14:53:05Z",
"text": "Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.
I think that's exactly what I'm suggesting. BitX is a block chain service (not sure how this differs from 'p2p proof of work') that supports arbitrary applications, such as bitcoin, bitDNS, ...
So now the question is what kinds of central authorities can be replaced by this type of quorum?
",
"nested_level": 0
},
{
"id": 3364,
"thread_id": 244,
"source_id": "9",
"poster_name": "ByteCoin",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=490",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22539#msg22539",
"date": "2010-11-18T05:14:20Z",
"text": "I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.
There would have to be some incentive to support an app in this way. Some form of payment.... hmmm
ByteCoin
",
"nested_level": 0
},
{
"id": 3365,
"thread_id": 244,
"source_id": "10",
"poster_name": "appamatto",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1958",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22545#msg22545",
"date": "2010-11-18T06:28:58Z",
"text": "ByteCoin, I think you can just keep a pointer to the last valid block per app in the big block chain.
So, when you mined, you would produce new app data for each app you cared about and stick the hash of that data as well as pointer to the previous vaild app block (per app you care about) into the big block chain.
In other words, the big chain has a next pointer to the last valid big block, as well as a next pointer to each last valid app block you care about. So, if you think there was an invalid app block, you can still add to the longest big block chain and reject the invalid app block by pointing further back in the chain to the last valid (in your view) app block.
You don't have to know about every app in this case. This plan still retains the bonus that miners can mine for as many apps as they want.
",
"nested_level": 0
},
{
"id": 3366,
"thread_id": 244,
"source_id": "11",
"poster_name": "asdf",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1726",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg22546#msg22546",
"date": "2010-11-18T06:38:26Z",
"text": "I didn't read the thread, but you might be interested in the Netsukuku solution to distributed dns:
http://en.wikipedia.org/wiki/Netsukuku#A_Netsukuku_Domain_Name_ArchitectureNetsukuku:
http://netsukuku.freaknet.org/http://p2pdns.baywords.com/2010/11/30/hello-world/I just found this from Peter Sunde who wants to create a decentralized dns system.
",
"nested_level": 0
},
{
"id": 3368,
"thread_id": 244,
"source_id": "13",
"poster_name": "gekko",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1862",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg25779#msg25779",
"date": "2010-11-30T18:01:02Z",
"text": "A lot of collaboration on a decentralized DNS by the bittorrent community is occurring here:
http://dot-p2p.org/index.php?title=Main_PageThe brainstorming session is here. BitDNS/Bitcoin could provide them with a lot of the source code needed:
http://dns-p2p.openpad.me/1Quick! Offer a bounty in bitcoin!
",
"nested_level": 0
},
{
"id": 3370,
"thread_id": 244,
"source_id": "15",
"poster_name": "sandos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1439",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg25851#msg25851",
"date": "2010-12-01T08:26:14Z",
"text": "If you just allow any number of applications \"on top\" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!
Maybe make it a tad bit hard to add applications?
",
"nested_level": 0
},
{
"id": 3371,
"thread_id": 244,
"source_id": "16",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg25944#msg25944",
"date": "2010-12-01T17:27:05Z",
"text": "If you just allow any number of applications \"on top\" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!
Maybe make it a tad bit hard to add applications?
Hmm? I thought we're going to use a separate blockchain than what bitcoin use.
I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.
http://dot-p2p.org/index.php?title=Main_Pagehttp://wiki.opennicproject.org/dotP2PTLDCalling something retard and having no substance to back it up is not a good argument.
Calling something retard and having no substance to back it up is not a good argument.
retarded means \"slowed\" which ironically is the case here
retarded means \"slowed\" which ironically is the case here
retarded means \"slowed\" which ironically is the case here
retard - cause to move more slowly or operate at a slower rate; \"This drug will retard your heart rate\"
meaning... using a bitcoin based dns will be slow to adopt
retard - cause to move more slowly or operate at a slower rate; \"This drug will retard your heart rate\"
meaning... using a bitcoin based dns will be slow to adopt
Not really. Since, 144 blocks were generated each day in the bitcoin network, this mean 7200 addresses that can be assigned a domain name. Plenty, if you asked me.
I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.
There would have to be some incentive to support an app in this way. Some form of payment.... hmmm
ByteCoin
It is funny how people are thinking about the same issue at the same time. I have been trying to think of some way that another \"chain\" using Bitcoin principles of hashing might be able to use Bitcoins as a transaction fee:
http://bitcointalk.org/index.php?topic=2028.0The issue here is that you would need some way for those \"mining\" new blocks into this sort of DNS data block chain (or any other kind of similar data protected by a hash chain with miners) to receive some sort of transaction fee for processing that chain. In this case, the incentive for processing the DNS entries would be to receive these transactions fees.... which could be quite considerable depending on what people would be willing to pay for a domain name under this system.
I have considered perhaps an alternative, which would have the main Bitcoin miners of the main chain have as \"optional\" transactions to be processing in such a way that could let the miner itself keep these transaction fees. My main objection to doing that is that it puts far too much processing into miners and makes a bottleneck that I think we would all rather not have. Bitcoin miners ought to be for bitcoin transactions alone, but it is at least something to consider.
This thread I mention here goes into the technical details, but it is something that could help with this idea too. I haven't completely \"solved\" the problem, but I have at least identified what issues need to be solved.
Besides, it would be nice if there were other ways for those interested in using Bitcoins to be able to earn them since the main mining of coins is now being locked up with with stronger computers and GPU miners of various kind including server farms.
The one advantage here of using a fee is to avoid a tragedy of the commons, where those who want to register a domain or transfer \"ownership\" of that domain would have to put up real money to do so. The fees don't go to some central processing bureau or organization, but rather to those who are doing the real work, which is processing the actual domain registrations itself.
Bitcoin would be more for buying and selling domains I think. Any profits involved could go to the EFF which already accepts bitcoin donations. In a sense this would tie dns and domain names to the health of the EFF.
Id like to see the government try and seize domains from those guys ,can you imagine the shitstorm that would create
How would domain name renewal work?
How would domain name renewal work?
Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee.
Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee.
I see. Then the miners will set the fee for domain renewal.
Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee.
I see. Then the miners will set the fee for domain renewal.
Exactly! It would become a marketplace where those people willing to put resources into building this chain would set the fee they think is most appropriate. I really don't see this happening without fees getting put in at some point.
This is also something where deflation would be dealt with through the marketplace as well, as there would be increased competition if transaction fees started to get a little high where somebody offering to take on perhaps slightly lower transaction fees would push their way into the block making competition. So if 0.01 BTC becomes worth $100, there might even be many \"miners\" willing to charge perhaps only 0.001 BTC or an even smaller amount.
I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.
The fees could come from domain name transfers, and of course the generation of new domain names.
",
"nested_level": 0
},
{
"id": 3385,
"thread_id": 244,
"source_id": "30",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg26231#msg26231",
"date": "2010-12-02T17:21:15Z",
"text": "I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.
The fees could come from domain name transfers, and of course the generation of new domain names.
If someone lost their wallet, their domain name stay with them forever, with no way to transfer it.
Eventually, you get a long string of really good domain name that can't be used forever.
Eventually, you get a long string of really good domain name that can't be used forever.
It's the same as with bitcoins, it just makes the remaining names more valuable.
It's the same as with bitcoins, it just makes the remaining names more valuable.
if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.
It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.
...if sex.bitcoin is lost ... It doesn't necessary make other domain names more valuable
The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.
I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.
The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.
I concede that one.
I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.
Then this is a matter of competition between various BitDNS system then.
It's the same as with bitcoins, it just makes the remaining names more valuable.
if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.
It doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.
In theory you could also put a \"lease\" on that domain so that after a certain period of time defined within the network protocol the lease would expire. In this case, if somebody \"lost\" their wallet the domain could become available after the lease expires. It wouldn't necessarily make the domain worthless either, as the IP address associated with the domain would still be valid, and the domain would still resolve even after the wallet was lost, but if there was an issue where the person owning the domain switched to another network (and a different IP address) it could be a bit of a problem.
None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly. Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain.
None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly. Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain.
Can you please explain what you mean by this?
None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly. Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain.
Can you please explain what you mean by this?
What do you need explained?
What do you need explained?
Why is it so easy? How is it done?
What do you need explained?
Why is it so easy? How is it done?
It depends on the domain registrar and a few other factors. Back when ICANN ran domain registrations directly, all you needed to do was to simply spoof the e-mail address of the person who made the registration and change the contact information... hoping that the reply from ICANN would get lost in the junk mail with spam and other garbage. Once you switched the contact information, switching almost everything else was incredibly trivial and a piece of cake.
It is a bit harder now and the domain registrars do require a bit more identifying information, but nothing that a good private investigator would be unable to provide. Really, the current domain registration is incredibly insecure and there are even \"legal\" means to \"steal domains\" that merely need a pretty competent attorney to cover your back if you want to do it through the judicial system. That is how nissan.com was taken from a small business in southern California in spite of the fact that the last name of the guy really was \"Nissan\" running a used car business with the name \"Nissan Motors\" and registered the domain well before the perhaps more famous automobile company got the domain changed.
On top of that, the DNS system itself is very much open to attack as long as you can somehow get trusted as a \"peer\" by one of the main root servers. There are various kinds of attacks upon DNS records themselves which can be done, some easier than others and some of them requiring better knowledge about computer networking than others, although there are some \"kiddie scripts\" and \"hackerwarez\" that you can get to do all of this is you really want to. I'd strongly suggest staying away from those program mainly because they are trojan and virus sources if you try to just Google for them. In other words a good way to get your system rooted and part of a bot net not under your control if that is your goal. If you want to go the hacker route, learning about the protocol itself and sticking to discussion groups is a much better route to go.
None of this is new to somebody who is familiar with the DNS system, and it really is just a house of cards much flimsier than what anybody can possibly believe if you aren't familiar with how it was all set up in the first place.
My point is that using a simple sort of cryptographic storage for the registration of the information is vastly more secure in terms of making sure the information doesn't get tampered with or manipulated that the current system. Even DNSSEC, the supposed \"savior\" of the DNS system to keep spoofing from happening (and largely unimplemented by most ISPs unfortunately even for that level of security) is only as good as the domain registrar's security. Social hacking can still happen.
It is for this reason that I think a bitcoin-related system would work much better and be insanely simple to operate. On top of that, there would be no gatekeeper in terms of who gets authority to decide if you get the registration. You simply apply, throw in the fees for processing the application, and the domain registration gets put into the system.
In terms of the \"leasing\" option, the only advantage of doing that which I can see is to make sure that the domain itself remains in the \"public domain\" at some point. Domain registration is a public service and unfortuantely there are people who have taken domain registrations as a sort of \"land grab\" where the earliest get the best stuff first. By putting a leasing ability into the standard (and the \"lease\" is from all of mankind, not any individual), it forces those who grabbed the domains early on to do some \"work\" or at least pay up to maintain those leases. Presumably if maintaining those domains is expensive, they'll simply let them expire rather than having to constantly renew the domains. It also provides a source of revenue for those who are mining blocks as well so it also maintains the integrity of the database... in other words the chain of blocks being used to keep track of all of this information.
Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.
",
"nested_level": 0
},
{
"id": 3396,
"thread_id": 244,
"source_id": "41",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg26354#msg26354",
"date": "2010-12-03T05:56:41Z",
"text": "Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.
I don't have a problem with somebody \"renewing\" their lease in some manner where they have at least \"first try\" at keeping that lease. The \"public good\" coming from paying the lease fees is maintaining the network.
I don't understand this \"sending it to yourself\" however. The domain registration would be something confirmed by a network. If you were mining these blocks, you might get lucky and mine the block you are also using to register a domain, but perhaps you wouldn't be doing that either.
Its like bitcoins but time based old domains get freed up after 365 days, if you want to keep it just send it to someone or to yourself.
",
"nested_level": 0
},
{
"id": 3398,
"thread_id": 244,
"source_id": "43",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg26739#msg26739",
"date": "2010-12-04T09:01:48Z",
"text": "<genjix> dot-p2p: \"We currently believe the best way to create a stable
environment for TLDs is to enact a central authority. We know this
will cause much argument within the community, but we have made the
decision that we believe will be best for the continued development
of this project.\"
Knew it. They sucks.
Our opportunity is now, but unfortunately I think we lack the expertise to create a BitDNS.
Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.
A domain name entry in this system has 3 parts:
- the name itself (e.g. example.bitdns)
- a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
- the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)
When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.
Subsequently a name might have two things happen to it:
- the IP address of the DNS server might change
- it might be transferred to a new owner
Both of these might be handled the same way, via a BitDNS transaction. The transaction would contain:
- the domain name
- the new owner key hash
- the new IP address of the DNS server
And it would be signed by the old owner private key.
As with Bitcoin, transactions would be broadcast and incorporated into the next block by miners.
Is this what people have in mind?
",
"nested_level": 0
},
{
"id": 3401,
"thread_id": 244,
"source_id": "46",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg26857#msg26857",
"date": "2010-12-04T20:22:14Z",
"text": "That's very clearly expressed, thank you Hal.
What you describe is almost exactly what I have in mind. Additionally, I would allow the domain name itself to be subsequently changed to any other untaken name:
Subsequently a registration might have three things happen to it:
- the IP address of the DNS server might change
- it might be transferred to a new owner
- the domain name might be changed
The advantage of allowing domain name changes is that it makes the initial registration easier. Registrars can generate arbitrary registrations, then change the name when they sell them to their customers.
When you generate a block you get to create 50 of these entries
Exactly. The \"50\" is arbitrary, but that doesn't matter. The initial scarcity will be reflected in a high price, which will encourage people to generate, which will raise the difficulty and ensure the security of the system.
With 7200 registrations being generated daily, there will soon be plenty to meet the demand. The price will then drop, with transaction fees maintaining the incentive to generate.
Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.
A domain name entry in this system has 3 parts:
- the name itself (e.g. example.bitdns)
- a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
- the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)
When you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.
I hope we aren't at cross purposes here as there are multiple ideas. My idea was more that you would throw in a \"transaction\" that would have a few bitcoins attached (as the transaction fee) so that any potential miner would be encouraged to put that particular \"registration\" into a block chain like the Bitcoin mining blocks. The \"owner\" is merely the person who paid the fee and is identified by a private/public hash like the Bitcoin addresses are being used right now. In fact, I would propose that the \"owner\" of a particular domain might as well be a Bitcoin address unless we can think of a more secure way of claiming such ownership.... which would be of value to the Bitcoin project if you can show it would be unsecure. It is tying the domain ownership to your wallet.dat file making your wallet even more valuable if you got one of these domains. The actual hash is irrelevant other than it should be defined in the protocol.
A block would have a limited number of \"transactions\" in it... perhaps just 1 but it could be 50 or slightly more. I don't mind putting a limit at 50 per block in the sense that it might drive up the value of an individual domain and set up some interesting economic theories so far as supply and demand are concerned. That is a network rule to define in this case. Obviously a miner could create one of these \"domains records\" for \"free\", but then again they are contributing to defending the integrity of the database through CPU proof of work.
So really a domain entry would be:
- the name itself (e.g. example.bitdns)
- a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
- an optional key which could identify a \"new\" owner in the case of somebody transferring control of the domain
- the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)
- transaction fee paid in BTC
A block entry would also have a timestamp that could be rejected if it was for some time in the future
As a network rule any name collisions that can't be resolved as from the same person making a request for changes would be rejected. The cost to run this network would be through the transaction fees, where a \"miner\" may be as inclusive or selective as they care based upon the transaction fees involved. Miners might have a different fee schedule for \"new\" domains as opposed to existing domains and could discriminate on that basis... or simply only select to process one kind or another. All of this would be essentially a marketplace where those trying to \"register\" domains are playing chicken with those making the blocks, presumably with the miners wanting higher fees and those registering domains wanting lower fees. My bet is that domain registration fees would be considerably lower than what GoDaddy charges or for that matter any other domain registrar other than those who simply do it for free. Maintaining the DNS records does have a cost, which is the purpose of the transaction fee as well.
The only glitch here that I can see is trying to get those transaction fees to the miner. The miner needs to be able to demonstrate proof of work before they get paid, and presumably that the proof involved has generally been accepted into the network before they get paid as well. Otherwise, all I can see is that people are being altruistic and simply mining as a free public good.... which has problems related to a tragedy of the commons as well. I personally think that you should \"pay your own freight\" for things like this. Besides, it provides another way for people to earn bitcoins simply by leaving their computer running if you can get the transaction fees for running such a DNS mining application processing these records.
BTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:
http://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1I'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this. It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try. Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.
ames. Of course they have to be new names that were not in earlier blocks.
BTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:
http://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1I'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this. It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try. Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.
I am using this document as the BitDNS bounty's protocol document.
So really a domain entry would be:
- the name itself (e.g. example.bitdns)
- a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)
- an optional key which could identify a \"new\" owner in the case of somebody transferring control of the domain
- the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)
- transaction fee paid in BTC
A block entry would also have a timestamp that could be rejected if it was for some time in the future.
I see, that makes sense. I have an idea about the transaction fee. What if this were integrated with Bitcoin itself? This would be a different kind of transaction that would be mixed with regular Bitcoin transactions and included in regular Bitcoin blocks. Then the block creator would automatically receive the transaction fee just like all the other tx fees in the block.
If that sounds good, I see a way this could be implemented into the current Bitcoin system compatibly with current clients. We could use the mysterious and extravagant \"scripting\" system to add additional data to regular Bitcoin transactions. These would look like NOPs to current clients and be ignored, but BitDNS aware clients would look inside this NOP block and see the extra DNS data, and interpret it as BitDNS transfers.
Specifically i could imagine using OP_NOP1 to mean BitDNS, then OP_PUSHDATA to push the DNS info, then OP_DROP to drop it from the stack, followed by the regular tx opcodes. This will have no effect on regular clients and look like a regular transaction (can be a dummy tx, 0.01 to yourself) but BitDNS aware code sees a BitDNS transaction. This is actually a powerful general technique for adding overlay protocols to Bitcoin.
Sorry for being too lazy to read all previous posts...
But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
",
"nested_level": 0
},
{
"id": 3406,
"thread_id": 244,
"source_id": "51",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg26921#msg26921",
"date": "2010-12-05T01:36:09Z",
"text": "Sorry for being too lazy to read all previous posts...
But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
People already put up links about BitDNS.
Sorry for being too lazy to read all previous posts...
But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
Several bitcoiners have been in the p2p-dns irc chat and have spoken about it.
Its also been written about on their wiki.
http://dot-p2p.org/index.php?title=Draft_Discussion_Paper they have a discussion paper out but looks like they have opted for using open nic for now plus a .key domain for a decentralized dns.
As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.
How does bitdns get around that?
As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.
How does bitdns get around that?
A domain name key should be so important that people will backing it up, automatically.
Sorry for being too lazy to read all previous posts...
But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
People already put up links about BitDNS.
I added bitdns to the ideas page here
http://dot-p2p.org/index.php?title=Ideas#BITDNSThe likelyhood of the idea getting implemented is likely slim to none.
Sorry for being too lazy to read all previous posts...
But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?
As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.
How does bitdns get around that?
I think this is a good argument against almost any peer-to-peer distributed database of any kind. This isn't something unique to just Bitcoin.
All of this is sort of strange, as I thought the whole point of the exercise was to try and decentralize the DNS database. Instead, there is going to be a central point of control for the whole thing and an official \"authority\" who is going to be acting as a gatekeeper. Really, this seems to be a betrayal of whatever it is that they were trying to accomplish and they are now becoming an alternate to ICANN, not something which is really a genuine distributed domain repository. There may be some differences as it may become a sort of Napster of domain registration, but it still has that point of attack, whatever that attack may be from either a digital, legal, or physical kind of attack.
It is too bad that they aren't rethinking the entire issue down to its roots, which is an attempt to create a \"directory\" of the internet. They are also getting IMHO hyper-paranoid about trademarks, as if coca-cola.com isn't sufficient to identify a particular corporation that most people know anyway. So what if somebody creates coca-cola.p2p? Or for that matter wikipedia.p2p?
There also seems to be a mindset that it must follow the convention of:
<computer> <dot> <domain> <dot> <top level domain>
There was an historical reason for the original divisions for .com, .mil, and .edu. They represented three distinct and separate networks originally called \"COM-NET\", \"MIL-NET\", and \"EDU-NET\". It is sort of like how telephone systems used to be completely separated between business exchanges and residential exchanges. When the three networks were finally linked, they had to use some way to identify how to access computers on one network to another, so the \"TLD\" system was originally set up and some other side \"TLDs\" were made for \"miscellaneous organizations\" (.org), \"international organizations\" (.int), and generic \"network resources\" (.net). When people outside of America were participating in adding their networks to the internet, they were identified by their country code , now the various \"country code top level domains\".
Mind you, when the codes were handed out, there was the .us domain which seemed redundant (it was) but those already having .com didn't want to go to a longer .com.us.
Anyway, I contend that the whole notion here of a top level domain is something that completely unnecessary, and that viewpoint has been long advocated by
Karl Auerbach. If you've never heard of this guy, it should be important that he was the one and unfortunately only official
elected representative of North America to ICANN, and sort of a major rebel. He was one of the \"at-large\" directors that had to get a California court to force ICANN to actually show him their books (he was one of the members of their board of directors and supposedly recognized as such by the organization) and because of his efforts his position was dissolved by the appointed board members made up of people hand-picked by major corporations. The whole experiment of democratically elected representatives to ICANN was killed by the U.S. Department of Commerce... isn't that something?
Anyway, if anybody knows DNS backward and forward, it is Karl Auerbach, and one of his positions when he was on the ICANN board was that there was no need to even have a top-level domain system at all, and certainly the number of top level domains could certainly number in the millions or more. It is simply a directory.
This history paper about DNS goes into the gritty details of how it finally got started. This really is a seminal paper on the history of DNS in terms of how we got to where we are today.
Another paper by Karl Auerbach is certainly worth reading so far as to see what a very well thought out objection to the current DNS system as implemented by ICANN was and how when the whole system was created had people proposing some significant alternatives. Since supposedly we are talking about alternatives to the centralized DNS, I think this ought to be at least one of the key papers worth reading. It shouldn't be surprising that the problems he identified over twenty years ago are still present in the current system, and it is important to note that there was opposition back then even to the current system. If you read between the lines, he was even upset over how IP addresses were allocated... which is a completely different beast altogether.
I don't think that those working with this new \"dot P2P\" effort are really reading stuff of this nature. I find it too bad as well, as it shows the immoral and arguably illegal actions taken by those who set up the current system almost as if it was a sort of Jekyll Island episode of the Internet. There are a whole bunch of common parallel themes between the formation of ICANN and the Federal Reserve. In this sense, perhaps Bitcoin really is a good fit as it sort of is a merger of the two systems that have been corrupted by aristocrats in a supposedly egalitarian and \"officially\" classless society.
In short, I think that the \"dot P2P\" effort is doomed to failure if the continue down the path they are going and not addressing the real problems facing the current system. Many of those problems are being addressed by BitDNS, even if it is a bit marginalized at the moment. And I also think that the argument about lost keys is not something nearly as significant either compared to the major issues about what is wrong with the current DNS system.
There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.
Check out
http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/and
http://dot-p2p.org/Yes that is what we are discussing. I was in the irc chatroom while all of it was being discussed. I brought up bitcoin several times but was scoffed at,as did someone else. As usual people dont learn from the mistakes of the past and are bent on creating a mirror of ICANN. All I can say is WTF?
I even saw one guy mention how he worked on an email system for the NSA ! and no one even asked the obvious question about someone from the NSA steering the discussions towards a centralised system.
I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.
As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.
How does bitdns get around that?
If you lose the keys, you can no longer sell the domain name or change the IP address of its DNS, but the domain name itself doesn't immediately stop working. So you have plenty of time to choose a new domain name, set it up, and install redirects from your existing site.
You can protect against this by leaving a copy of your keys with a couple of trusted people. That's a much better solution than leaving your domain name hostage to an untrusted registrar.
In the 1990s, Turkmenistan was selling .tm domain names and I registered one. After a couple of years, the Turkmenistan government decided there were .tm websites they didn't like and they removed access to the domain name. But there was plenty of time to get a new domain and install redirects. It worked just fine.
Ultimately, a name is just a name and it's not the end of the world if one is lost. Even cocacola.com could switch to cocacola2.com and it wouldn't be the end of the world.
I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.
Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.
Why it is only 40 BTC at this stage is beyond me.
I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.
Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.
Why it is only 40 BTC at this stage is beyond me.
Where do I pledge?
Best way to get the BitDNS system running off the ground?
Adapt the bitcoin source code?
",
"nested_level": 0
},
{
"id": 3419,
"thread_id": 244,
"source_id": "64",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27124#msg27124",
"date": "2010-12-05T21:18:14Z",
"text": "<genjix> dot-p2p: \"We currently believe the best way to create a stable environment for TLDs is to enact a central authority...
Knew it. They sucks.
They are responding to a problem caused by a central authority by enacting ... another central authority. But I don't think it's because \"they sucks\". I think it's because they haven't been exposed to such a beautiful decentralised design as bitcoin.
Best way to get the BitDNS system running off the ground?
Adapt the bitcoin source code?
Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.
Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.
Ribuck, If only I have the necessary knowledge to adapt it, I would have dropped it and just implement it.
Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.
What kind of time-frame are we talking about here in terms of getting at least a \"proof of concept\" project going?
If it took a year, it seems like something else would be taking its place, but if we got some software up and going in the next month or two it seems like the \"distributed DNS\" supporters might really pay attention to BitDNS. Indeed, with the philosophies of Bitcoin already established, I don't think there is nearly as much \"debugging\" to get this going as it may seem. Some, yes. But it isn't the end of the world. Getting something done by tomorrow may be a bit more difficult.
The time frame of this idea is something that I believe has a short time span to at least get something to the table, even if there might be some competing ideas. The strengths of using Bitcoins and a Bitcoin-like system are things that solve many of the problems being proposed from what I've seen.
Writing up a white paper? It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.
Speed is of the essence if we're going to show .p2p how to really do distributed DNS.
",
"nested_level": 0
},
{
"id": 3423,
"thread_id": 244,
"source_id": "68",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27156#msg27156",
"date": "2010-12-05T22:33:30Z",
"text": "What kind of time-frame are we talking about here in terms of getting at least a \"proof of concept\" project going?
I think this schedule may be possible:
1. Two weeks: Prepare, agree and release three documents: an overview in non-technical language, a FAQ, and a technical but informal white paper which expounds the motivation and the design principles.
2. Three months: Demonstrate a \"proof of concept\" on a test network.
3. Six months: Release a basic but usable version 0.1.
(4. Generate some names while the difficulty is low.
5. Profit!)
Writing up a white paper? It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.
I will start on the documents. I would rather be programming too, but as kiba says: time is of the essence. This is an idea whose time has come. We can't get this done with just RHorning, kiba and me. We have to build a team. And a set of basic documents serves two important purposes: it attracts newcomers to the team, and it helps to keep the whole team working towards the same goal.
Here are some early tasks that fall on the \"non-documentation\" side, in case you or anyone else is interested.
* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using \"BitDNS\", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the \".org\" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.
* Set up the development environment. Are we going to use SourceForge? GitHub?
Github and git. I like. It's distributed version control system. Any developer can fork the project and continue on their own implementation and they can request pulls as necessary.
Also remember, everything is in version control. If you messed up the code, it's not a big deal. Just revert to the last state. Remember to commit as well push often too.
I would like to be looped into this project. I think that something like BitDNS can provide the intrinsic \"use value\" for bitcoin. I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem. Perhaps a distributed dns is that \"problem.\" This is exciting!
",
"nested_level": 0
},
{
"id": 3426,
"thread_id": 244,
"source_id": "71",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27159#msg27159",
"date": "2010-12-05T22:45:21Z",
"text": "I would like to be looped into this project.
By all means, pledge some bitcoins if you can't code, or do anything. I can't do any of the real important stuff, but I can show that I am serious.
Here are some early tasks that fall on the \"non-documentation\" side, in case you or anyone else is interested.
* Set up the development environment. Are we going to use SourceForge? GitHub?
* Choose a project name. We've been using \"BitDNS\", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the \".org\" domain.
* Set up a build process so that we can distribute for Windows, Linux and OS/X.
* Read, learn and understand the Bitcoin source code and its underlying principles.
For the source repository, I am agnostic toward that as long as I can get the source files in and out. SourceForge has been pretty good to me in the past and it has worked out with other projects I've been involved with, so I sort of lean that way although it appears Kiba love Git. I'm fine with that too.
As for a project name, how about DomainCoins? Otherwise I love more obscure ancient dieties/demigods as names and there are a few out there. I guess the choice here is one that is more functional or one that can be memorable. Does anybody know a name of some ancient diety of finance or accounting? Babylonian and Aztec gods would be especially interesting. Either that or simply a whimsical name that may not mean anything at all.
For a build process, I'm not really particular either but I do insist upon \"free\" or \"open source\" tool chains. I personally am not a big fan of C++ (sort of antagonist about the language) but I'll contribute however anybody else wants to go. I agree that it should be built on all of those platforms and be capable of going to more. I have a stronger preference to C# on Mono if that matters any where MonoDevelop is a pretty good environment.
In term of reading up and understanding the Bitcoin source code.... I'm way ahead of you there. I've been pounding my head against that for awhile now. There still is more to pour through, but I'm finally starting to get a good grasp of the base network layer now even if some of the details like the block rejection rules aren't quite so firm yet. Expanding the documentation would be still beneficial.
I would like to be looped into this project. I think that something like BitDNS can provide the intrinsic \"use value\" for bitcoin. I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem. Perhaps a distributed dns is that \"problem.\" This is exciting!
There still are some technical challenges here that I am not completely sure how to solve. In this regard, all of the help we can get will be appreciated and there will certainly be some \"heavy lifting\" where I think there can be some good division of labor in terms of separate parts that can be worked on.
Major areas will include:
* GUI design - coming up with the visual appearance and organization for the project. Most GUI design is simply awful, and it is something I've struggled with over the course of decades and still don't get done very well.
* Networking communication - How the client will communicate with other nodes? Even that is something which can be sub-divided after a fashion, but it will be a crucial piece.
* Database organization and communication - Even choosing a database route isn't going to be easy, either from a \"roll your own\" to something like MySQL or BerkleyDB. Potentially this is something which could get into the terabyte range for storage requirements, so we do need to be careful on some of the decisions we make here.
* DNS communication - ideally what should happen is that the client would become a source of domain information that could be referenced with other DNS records. For a home office/small business this could be on the same computer but for some businesses or schools they could even put this in their server room as a part of the main domain resolver path for their network.
* Interfacing with the Bitcoin network - How will the usage of this software connect to the Bitcoin network, transfer payments from \"registrants\" to \"registrars\" (aka \"miners\"), and what is a \"fair\" way to make sure that the people receiving money are going to be paid?
* Thin client design - How can you set up something that would retrieve the \"database\" yet not be a miner? Is this even an issue?
Non technical issues include:
* Establishing Problem Domain - just what is it that this software needs to accomplish? Who would use it and why? What is it that they need?
* Potential Social Conflicts - What sort of \"legal\" requirements might there be for \"domain registrations\" and what do we do about them? Do we care? Even if we ignore the law in this case, what would most network users expect from a domain registration?
* Marketing - How do we sell this software so far as to get people to use it? How can publicity be spread about it once it becomes available. What sort of outlets are there which might be interested in using this. If we told a business they could run a domain server and make money (by \"mining\" registration applications) simply by having it in their server room, would that be something they might adopt?
* Finding \"customers\" for domain registration - This is more to the marketing, but with a concentration on just those who might want to use domain registration. Some of this is also going to be an issue in terms of breadth of the adoption of the concept, but what groups might be interested in using this as registration? Obviously bitcoin users would be an early adopter, but anybody else?
Some of these have some \"milestones\" that must be met before other things can happen, but at the same time there are things which can be done simultaneously. Any other ideas for things that might be facing this in terms of a breakdown of tasks?
* Potential Social Conflicts - What sort of \"legal\" requirements might there be for \"domain registrations\" and what do we do about them? Do we care?
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
Kiba is wise.
I suggest tahoe lafs if you are looking for a database for storage.
",
"nested_level": 0
},
{
"id": 3432,
"thread_id": 244,
"source_id": "77",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27343#msg27343",
"date": "2010-12-06T13:12:33Z",
"text": "I suggest tahoe lafs if you are looking for a database for storage.
Remember, speed is of the essence. We can alway replace the database with something else, but not time.
All non-essential features should be blocked from implementation focus.
That mean the core developers don't work on a fancy GUI. They will focus on:
1. The mechanism to mine, register, and change a domain name.
2. The mechanism to distribute or output the DNS database.
I suggest tahoe lafs if you are looking for a database for storage.
Remember, speed is of the essence. We can alway replace the database with something else, but not time.
All non-essential features should be blocked from implementation focus.
That mean the core developers don't work on a fancy GUI. They will focus on:
1. The mechanism to mine, register, and change a domain name.
2. The mechanism to distribute or output the DNS database.
GUI design is important, but it is also something that non-techies can help with even if all you do is make a mock-up in something like MS-Paint or GIMP. Getting the buttons to work is a bit harder, but not really so much. The tough part about GUI design is that it is an art skill, something that techies often lack. There is much more about artistic balance, the golden mean, and selecting colors or icons that aren't offensive to certain cultures (yellow buttons are a bad idea in Chinese culture, for instance, or showing a swastika to a bunch of germans).
I agree that there are priorities in terms of getting the network layer put together first, but if we can get more people involved I don't think it should be dead last in priority either and certainly can be worked on concurrently with other projects.
Yes, the core developers should be focused on the network and the protocol.
I am making it my project to write a BitDNS client. I don't need the bitcoins. I just want to help so that the core developers can focus on the important stuff.
",
"nested_level": 0
},
{
"id": 3435,
"thread_id": 244,
"source_id": "80",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27396#msg27396",
"date": "2010-12-06T17:04:01Z",
"text": "I am making it my project to write a BitDNS client.
Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?
Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?
It's easy for me to change the name of the git project, whatever you decide. Still BitDNS is catchy.
I am making it my project to write a BitDNS client.
Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?
In a way, we are writing a Domain Name Server. The hope here is that eventually the data we throw into this database is going to be extracted and used with the current DNS architecture as used on the internet, where computers would have the DNS resolution pointing to this database as a \"fall back\" position if it can't be resolved through the regular DNS channels. That is how OpenDNS is currently working right now.
The only differences here is that we aren't relying upon a central server to act as a gatekeeper of this information, and it would be something that you could simply put into the search path through the network configurations of your own.
Getting the DNS protocol hooks working is to me a much more trivial thing than getting the domain registration itself going, however. Once you can demonstrate that the domain registration is working and that the domain name can be resolved cleanly, getting the DNS portion working is simply plugging through the RFC protocol documents to make sure you get that side working. The revolutionary thing isn't the DNS server software (which can already be downloaded for free as in beer and speech) but rather the decentralized database keeping track of this stuff and securing the data from getting tampered with.
The revolutionary thing is ... the decentralized database keeping track of this stuff and securing the data from getting tampered with.
Exactly. The domain name block chain.
Anyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.
Exactly. The domain name block chain.
Anyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.
What software are you using for the site?
+1 on DomainChain or BitRegister over BitDNS (no offense kiba
)
+1 on DomainChain or BitRegister over BitDNS (no offense kiba
)
Bleg. All I need to do is change the name.
In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.
+1 on DomainChain or BitRegister over BitDNS (no offense kiba
)
Ooooooo... I like BitRegister. DomainChain works out pretty good too and is very descriptive. I'm so used to BitDNS that I am still somewhat partial to that, but it doesn't exactly explain in a single word what this is going to be other than a shortened form of \"Bitcoin DNS\".
I'd like to get back to the topic of the scope of the domain naming system itself. I would like to propose the following specification for actual name of the domain itself:
A domain can include combination of unicode (UTF8) characters with the exception of the period character (U+002E). We may want to look at some other restricted characters mainly for conformance with normal URL schema as defined in RFCs and avoiding control codes, but I say that right off the start we permit non-latin characters into this scheme. Other \"excluded\" characters may include the \"/\" character (U+002F) or the other non-alphabetic characters common found in the original ASCII specification. The period character here is something more special, however.
Some possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\", or any of the standard country codes as currently under the purview of ICANN. If ICANN wants to get into this game and claim those few domains, I don't mind giving these domains directly to ICANN, but the issue here is mainly to avoid naming collisions with other network resources. If/when that becomes an issue, a technical solution can be found and it is irrelevant.
\"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name. For example a certain oil company could create a domain called \"bp\" and then create a sub-domain like \"usa.bp\". When a registration of this nature happens, some sort of signed public/private hash key confirming permission to create the sub-domain is confirmed (similar to transferring ownership of a domain) before the sub-domain record is kept. It may be possible to create a domain that is simply a \"free-for-all\" of sub-domains and defined as such when the domain is created. An example of this would be a domain named, \"bitcoin\" and \"btc\" which would permit the creation of a domain like \"mtgox.btc\" or \"mtgox.bitcoin\". On the other hand somebody creating \"this.sucks.coca-cola\" may have to negotiate with the domain holder of \"coca-cola\" in order to create those sub-domains.
Since the sub-domains have their own record, they can also point to separate resources including separate IP addresses.
Essentially, this is also allowing anybody and everybody to create their own top-level domain and charge whatever they want to use that \"top level\" domain, but it also makes such TLDs essentially worthless for the most part too.
I'll be nice and give \"p2p\" to perhaps the \"dot p2p\" folks as well if they want it. I'm sure somebody would be willing to donate 0.01 BTC to get that record into the database.
Are there any flaws with this idea, or should it \"go official\"?
I have no complaint.
",
"nested_level": 0
},
{
"id": 3444,
"thread_id": 244,
"source_id": "89",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27456#msg27456",
"date": "2010-12-06T20:16:02Z",
"text": "I would like to propose the following specification for actual name of the domain itself...
OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system (\"punycode\") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.
Some possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\"
Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?
\"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name
If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.
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?
",
"nested_level": 0
},
{
"id": 3446,
"thread_id": 244,
"source_id": "91",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27464#msg27464",
"date": "2010-12-06T20:33:45Z",
"text": "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?
Where the incentive for generators to get paid?
On the other hand, it won't be limited right? It will be a unique name of some kind.
+1 on DomainChain or BitRegister over BitDNS (no offense kiba
)
Bleg. All I need to do is change the name.
In any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.
The only thing I am banging my head against right now is the issue of how to get the block miners of the DNS blocks to get the transaction fees. I don't know if that is going to require a change in the Bitcoin protocol or if it can be adapted into the existing protocol.
This idea shows some promise as one way to implement the idea, however I really don't like putting this data into the main Bitcoin transaction database and turning that into one huge monster generic database of home cooking recipes, porn, mp3s, Wikileaks documents, Heroin traffic routing instructions, and other miscellaneous junk. If you thought Bitcoins faced problems before in terms of governments wanting to shut it down because it is a competing currency, I think that puts it completely over the top without any of the protections that Freenet has put into the message routing protocol.
Where I'm having the problem is mainly that I don't think a \"DomainChain\" miner should get paid until the block they made is accepted deep into the chain, like at least 10 or so blocks deep (perhaps adjustable on that length with some formula too?) For the most part I don't think most miners are going to care as long as they eventually get paid for the work they did, but those who are attacking the network may want to suck up the bitcoins for themselves and not really doing any work in terms of generating the blocks necessary to keep this whole thing going.
By banging my head on this problem, I really mean that every possible option I've considered has a fatal flaw in it. I think the registration fees are an important part of this whole concept, however, as it makes the difference between a public commons free good and something where the consumer \"pays the freight\" for the network. I also think it will make the difference between limited vs. widespread acceptance of this system too.
If you want me to go over some of the ideas I've had, I'll gladly put those dead ends into another thread, as I've come up with at least a dozen different ways to solve this problem in detail... including ideas I even started to type up in various replies to posts on this forum and then simply hit the \"x\" on the tab in Firefox before I hit the post button because I realized it wouldn't work. Even the method of putting the data into the Bitcion transactions has a fatal flaw so far as it turns the BTC miners into DNS miners too (they keep the fees for themselves) and it enables some different kind of attacks on the DNS network as well. I hate to say it though, it may very well be the best route to take shy of some protocol extension to Bitcoin itself that would recognize independent data chains as a source of transactions.
I would like to propose the following specification for actual name of the domain itself...
OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system (\"punycode\") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.
The existing standard is that ICANN is being very stingy on allocating top level domains. That, for myself, is a major mistake and if you read some of the links above written by Karl Auerbach he points out that this is completely artificial and arbitrary. There is no current reason to exclude any alphanumeric sequence for a domain name of any kind.
Some possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\"
Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?
So, who cares if there is a collision? If somebody registers that domain, somebody at InterNIC can try to find out who owns the domain with DomainChain and negotiate a price to transfer that domain to themselves. BTW, I think some sort of \"comment\" field could be put in with domain registration so you can attempt to contact the domain owner (completely optional BTW!) if they might be interested in \"selling\" the domain. That seems like InterNICs problem, not ours.
They are the competitors to this protocol and this is something they should have done from the beginning. That they aren't doing these things is more why this is something that should be done in this fashion. There is no reason a million or a billion TLDs can't exist.
\"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name
If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.
Yes, I realize that the current DNS structure allows you to use a \"dot\" off of the previously established domain. The only reason for sub-domains is to create a system where \"ownership\" of a sub-domain can be transferred and have that ownership be kept track of through the DomainChain rather than as something arbitrary which can be revoked by the domain owner. In other words, once \"mtgox.btc\" is registered as a sub-domain, it in effect becomes a full-fledged domain in its own right with the protections and controls that would go with a proper domain and would be recognized with a separate domain server for any of its sub-domains. Basically this is a way to create the notion of a \"TLD\" registration system too if you wanted to stick with the convention of <server> <dot> <TLD>. In practice I think such notions would eventually be dispensed with entirely, but perhaps there might be a reason to keep it going. This system also meshes in a bit better with the current DNS system where collisions would be avoided as a natural part of the protocol rather than a hard arbitrary exclusion of certain words and names... thus simplifying the overall protocol. Those TLDs currently operated by InterNIC and ICANN can be held in \"escrow\" by a member of the development community until such time as ICANN decides to pay up or take ownership of those \"domains\".
Note here that you can go to a domain server operator and \"pay\" them some money to create a subdomain off of say \"mmorpg.org\" for a game you made called \"coolgame.mmorpg.org\", but you are still at the mercy of the domain name server in the same way that everybody is at the mercy of ICANN and InterNIC (as well as the other domain registrars) for simply getting into the game. That sub-domain can be arbitrarily terminated for any reason at all and would force you to go through the judicial system to get the subdomain put back in. I think that is something the network philosophy is trying to avoid in the first place. This alternate method would imply that such sub-domains can't be arbitrarily shut off unless the sub-domain owner is willing to relinquish control.
I don't know how to do this on IRC, but can someone create a #bitcoin-domainchain chatroom or something so that we can get some real time discussion going?
",
"nested_level": 0
},
{
"id": 3450,
"thread_id": 244,
"source_id": "95",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27484#msg27484",
"date": "2010-12-06T21:18:07Z",
"text": "Here is an idea for how miners can get paid.
Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.
However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.
Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.
And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.
",
"nested_level": 0
},
{
"id": 3451,
"thread_id": 244,
"source_id": "96",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27491#msg27491",
"date": "2010-12-06T21:39:41Z",
"text": "Here is an idea for how miners can get paid.
Let us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.
However in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.
Bitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.
And the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.
That sounds nice. However, I was always uncomfortable with how block miners get 50 coins, and slowly halves. It confuses people and makes them uneasy. I would just say have a constant 1 block => 1 bitdnscoin.
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?
Well, I've proposed that Bitcoins be used as an incentive for mining the chains, which I suppose is a way to promote the use of Bitcoins as well. If you are talking about the \"miners\" simply creating their own floating currency that could then in turn be put into one of the exchanges.... that may solve the problem of getting miners paid (hmmm.... I've got to think about that one for a little bit) but it does create the problem of what anybody is going to do with that \"floating currency\"?
Just thinking aloud here... if we used a \"floating currency\" in this system instead that was a \"DomainChain coin\" similar to Bitcions but not pegged to Bitcions as all, could that work here? I'm sure Mt. Gox would certainly be interested in exchanging these coins if they had some value, and the point here is mainly to come up with the formula for creating these coins. The only real use of these coins would be to pay registration fees for domain names, so I think the drop-off could happen a lot faster than is the case with Bitcoins.
In theory we could even set up some sort of link to Mt. Gox or some other trader so that in the interface you could do a \"quick buy\" of these \"DomainChain coins\" in such a way that for an end-user they would be buying them with BTC and then putting those recently purchased coins right into the transaction as a fee for the miner to claim when it gets put into the chain. If the transaction block is rejected, that miner loses the claim to those coins and they become unconfirmed.... where it is the responsibility for the exchange to worry about the validity of a particular set of \"DomainChain coins\". A similar kind of \"quick exchange\" could even happen with LR Dollars or any other currency that may be tied to some exchange system, or they could simply get the \"coins\" on a \"manual\" basis from the exchange if they wanted to get a better exchange rate or have somebody \"send\" them some of these \"DomainChain coins\" with a direct hand-over of cash.
I like this a whole lot. It may \"solve\" this problem I've been thinking of in terms of getting miners paid. Are there any other hiccups anybody sees with this situation? The exchange itself isn't even fixed.
The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value. Not overnight, but gradually. We need somebody with a whole lot more economic theory behind them to figure this one out, because I would vote for a \"weaker\" currency than Bitcions be set up in this situation, however we want to define that. How would you set up the parameters for a relatively strong currency that the desire would be to trade it in for Bitcions instead when possible? Would the fact that Bitcions has an absolute limit but these kind of \"DomainChain coins\" would continue to inflate (aka the 50 DCC produced per block would continue to be produced indefinitely creating a mild sort of inflation over time) be sufficient to make Bitcoins stronger?
I need to think overnight on this particular subject as it is starting to make my head ache thinking about it, but it sounds like an interesting idea to seriously consider.
I also had an idea last night of how/where to tie this into the existing DNS.
When you lookup foo.com, software on your computer called a resolver is responsible. It has some caching and local data, but mostly it just asks a DNS server for the answer. You have one or more DNS servers configured as part of your network setup, and these servers respond to domain name lookup queries either directly, or by initiating their own search of the domain name system.
Obviously we want existing name lookups still to work. Broadly speaking, then, we would change the software to first check if a name is registered in the BitDNS system, and if not, to fall back to the regular handling.
My idea is that the best place to add the BitDNS lookup code is in a DNS server rather than in the resolver. Resolvers are different for every OS, so there's more work. I don't even know if the resolver logic can be changed on Windows. Plus this code is going to need to be tracking the BitDNS block chain, and not every end user should have to do this.
Other 'alternative' DNS systems do it like this, with one or more special DNS servers that know about their extra domains.
We would choose some open source DNS server as a base, fork it and add the code to lookup BitDNS names. Whether these names all have a distinguishing TLD \".bit\" or whether we are more aggressive and take over more namespace, either way it could be done.
As I understand it, when a DNS server looks up foo.com, it finds the (or a) name server authoritative for .com, and asks it for what is called a SOA record for foo.com. This tells what name servers are authoritative for foo.com, and the DNS server then tries them to get details on foo.com.
We would intercept this first step, and use the BitDNS code to find the authoritative name servers. Maybe we could create a dummy SOA record to hold the data, to simplify falling back into the regular DNS code.
People who want to use BitDNS would just have to select one of the BitDNS aware DNS servers. Paranoids could run their own name servers locally and track the block chain. All the usual optimizations of DNS in terms of caching, distribution, etc. would work, so it would not have much negative impact on the net.
",
"nested_level": 0
},
{
"id": 3454,
"thread_id": 244,
"source_id": "99",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27497#msg27497",
"date": "2010-12-06T21:54:39Z",
"text": "That sounds nice. However, I was always uncomfortable with how block miners get 50 coins, and slowly halves. It confuses people and makes them uneasy. I would just say have a constant 1 block => 1 bitdnscoin.
I'm fine with that. It is an easy way to allocate the coins. The role of the halving of the coins \"mined\" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi. I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).
That sounds nice. However, I was always uncomfortable with how block miners get 50 coins, and slowly halves. It confuses people and makes them uneasy. I would just say have a constant 1 block => 1 bitdnscoin.
I'm fine with that. It is an easy way to allocate the coins. The role of the halving of the coins \"mined\" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi. I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).
Exactly. My points exactly. The reason for halving bitcoins over time does not really exist for bitdnscoins.
The reason for halving bitcoins over time does not really exist for bitdnscoins.
Good. Something everyone completely agrees on!
Exactly. My points exactly. The reason for halving bitcoins over time does not really exist for bitdnscoins.
Wondering aloud even more, what need do we have for a fractional bitdnscoin? I could imagine having a little bit of \"change\" but is there going to be any need for more than about three or four decimal places?
This is essentially the same issue just thought through from another perspective. Right now I think it is about 100 million \"bitcoins\" to the smallest unit as defined in the Bitcoin protocol. We really don't need that many decimal places even for trade purposes. I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins. Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective. The only other \"currency\" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.
I don't know of any other currency that uses this sort of allocation system even remotely. Of course that is why this is so groundbreaking.
Good. Something everyone completely agrees on!
So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)
I also had an idea last night of how/where to tie this into the existing DNS.
I know this discussion is going like nuts here. I think this is a very good idea and should be fleshed out much more. If you have some experience or knowledge about local domain name servers, your expertise here would be invaluable. I know just enough to get myself into trouble on that matter and to debate the policy questions, not enough to really dig into the guts of them. I've operated a domain server for a brief period of time and have experimented with OpenNIC myself.
Anyway, I have registered domainchain.org, in case people like it.
Care to stick a wiki up on there?
Good. Something everyone completely agrees on!
So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)
I don't see any reason why we should try something different. If it breaks for us or for Bitcoins, one or both projects should get the issue fixed with an alternative solution. There certainly are strong reasons to keep this system, as Satoshi's white paper points out in pretty good detail too.
The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value. Not overnight, but gradually.
Well people couldnt say domaincoins werent backed by anything.
I like the idea of a constant block rate.
On the question of how many domain names to create per day:
http://www.domaintools.com/internet-statistics/There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.
If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.
If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.
100 domains per block is 25 years.
150 domains per block is 18.5 years.
200 domains per block is 12.5 years.
Personally, I don't feel like I am a rush to do a lot of domain registration fast. 15 years is good enough for me. We don't need to register tons of domain within a few short years, since not everybody will be willing to switch from central to decentralized.
Also, the population of humanity ain't likely to grow forever... So we can expect that growth at some taper off at some point in the future.
However, this generation rate have the potential to spark a long debate..so we need a method that let us decide quickly somehow.
On the question of how many domain names to create per day:
http://www.domaintools.com/internet-statistics/There are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.
If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.
The question as to how many domains to include in a block ought to be something dependent upon the miner alone. This certainly is a useful point to bring up and likely an early \"reference implementation\" limit will be 50 domains per block merely to increase scarcity. Still, that up to 300k changes might happen eventually with this system, perhaps more considering that the cost is likely going to be considerably less than the current domain registration system.
----
I have a few other thoughts about this now that we are getting to something a little more concrete in terms of the software architecture. Would it be reasonable to expect the cost of a domain registration to be 1 DCC (Domain Coin Currency)... at least as the \"default\" cost expected by the miner to \"register\" a domain? I think that would establish at least an initial value to the currency and help to self-regulate those who want to jump in early and grab up a whole bunch of domains early on. I might even go so far as to say 2 DCC for registration and 1 DCC for information changes. If you run your own miner, you can \"tweak\" this if you want to be more competitive, but this is the way that you can spend the currency and what it is based upon and a fair benchmark.
In terms of a social effect that may be negative (depending on your viewpoint) some of the country code TLDs represent a substantial source of income for some of countries involved. One in particular, the country of Tuvalu, has only a little over 12,000 citizens and is the smallest member-nation of the United Nations in terms of population and pretty close to that in terms of land area. Only the Vatican has a smaller population in terms of a sovereign state. Its current TLD (*.tv) is currently run by a company in California but a significant portion of the revenue from that domain goes to the country's government under contract.
On the topic of small countries and their \"country codes\", it seems like if we could get this software rather stable, we might even want to offer this \"service\" to some of these smaller countries for their domain registrations, where I'm pretty sure that this would be cheaper than whatever contract they currently have with their current service provider. That goes under \"marketing\", but something else to think about. I certainly think that it would be awesome if we could get a whole country like Tonga to switch to Bitcoins as their national currency, and is much more likely to happen than the major western countries like America or the EU. Just dreaming there.
I would like to ask for some clarification on exactly what we are proposing here. From reading this (lengthy) thread, I gather that we are proposing:
- A decentralized domain registrar that maps a friendly human readable name (ie: chaord.btc) to an ip address
- A parallel network bitcoin which will have it's own token currency (represent addresses). Rather than mining bitcoins, you mine top-level address rights. Is this correct?
Am I understanding all this correctly? If so, it seems as if in this brave new digital world, bitcoins (BTC) represent a commodity like gold, and domaincoins (DCC) represent real estate.
Lastly, I'm sure this has been discussed, but is there any way that the two system can be combined? Can the domaincoin system accomplish all things bitcoins can, in addition to domain registration, or no? IMO the best of both worlds would be if, somehow (not sure how), the domain coin system could use bitcoins as its underlying backing (or vice versa).
Honestly, I feel that something like DomainCoins is the \"missing link\" that this community is searching for. Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!
Honestly, I feel that something like DomainCoins is the \"missing link\" that this community is searching for. Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!
I think you got the ideas down. The role that the \"DomainCoins\" (DCC) are playing here is to give a financial incentive to \"miners\" who are creating a cryptographically secure domain registration database. It is also a work-around due to the fact that we can't seem to figure out a way to accomplish the goals of getting Bitcoins directly to the miners, so instead we are going to be using an alternative currency which can be traded for mining. To me, the only reason for putting any sort of coin generation into the blocks is simply to \"prime the pump\" to get some DCC put into circulation. Hopefully what will normally happen is that DCC will be exchanged for Bitcoins in both directions: Some folks will \"buy\" some DCC with Bitcoins (or LR Dollars or whatever) so they can pay for domain registrations and the miners will \"redeem\" the DCC for Bitcoins as earnings.
Trade between DCC and BTC will be almost insanely easy by design and the exchange mechanisms may even be put right into the GUI interface. I could even see custom clients that might even combine transactions for both \"currencies\".
This same system could be used in a number of other similar situations, such as an idea I floated about
creating a Bitcoin-based Stock Exchange. If such a stock exchange is set up, a similar parallel currency may have to be implemented to also pay for mining the transaction blocks. I can see many other kinds of \"databases\" set up which would require some sort of cryptographic time-stamping. Something I played with a while back that could be useful here would be \"timestamping\" police evidence (especially digital evidence such as a dashboard camera video feed from a police vehicle) in a chain of custody system. An engineering company could set up a custom \"bitcoin\" system to keep track of engineering documents to be used as a defense against a patent lawsuit to both show date of creation and prove that the document file hasn't been tampered with since its inclusion into the database. Seriously, this system is something that has a whole bunch of possibilities that I can't even start to describe the kinds of things that would be useful and we are just scratching the surface.
Wait, I am a bit confused. Alternative currency for DomainChain?
Oh, these represent addresses?
",
"nested_level": 0
},
{
"id": 3469,
"thread_id": 244,
"source_id": "114",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27584#msg27584",
"date": "2010-12-07T03:01:38Z",
"text": "Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.
",
"nested_level": 0
},
{
"id": 3470,
"thread_id": 244,
"source_id": "115",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27590#msg27590",
"date": "2010-12-07T03:19:51Z",
"text": "Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.
Doesn't seem hard to me. It's a normal trade to me.
Wait, I am a bit confused. Alternative currency for DomainChain?
Oh, these represent addresses?
A coin would represent a domain. I think that is the proposal.
Could ip addresses themselves be managed by this system? The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines. Ipv6 has a privacy issue doesn't it? They stuffed ipv4 because address allocation became a scarce resource by bad management.
Does .dnc = domain name coins?
We could co-opt the democratic national convention lmao.
Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.
Doesn't seem hard to me. It's a normal trade to me.
So you need two clients running?
edit:never mind...
If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.
Doing peer to peer currency exchanges is beyond the scope of this project. If there is going to be some sort of peer to peer currency exchange (I think it might be possible, especially for non-reversible currencies like Bitcoins and Liberty Reserve Dollars), it should be in a completely different project. All that I'm suggesting is that some sort of API be set up so one or more \"trusted exchanges\" can be selected to facilitate the \"purchase\" or exchange of these \"coins\" for some other currency. I just don't see too many people going through the hassle of trying to obtain these \"domain coins\" by selling other services in these coins, even though that would in theory be possible.
If we could dump this idea of another currency, I'd be all for it. I just don't see how to do that though.
On the positive side, the fancy API and GUI exchange methods won't be strictly needed at all at least initially. We could even use essentially the existing bitcoin software where all we would do is to simply \"tweak\" the low level features so we would be including the domain information into the blocks. If we did that as a quick bootstrap of the network, websites like Mt. Gox could use the same JSON API system for Bitcoin on this system as well, particularly as the exchanges wouldn't have to play with the domain information but rather just the coin trading mechanisms. Exchanges would want to get into the act as there certainly are arbitrage opportunities between the DCC and BTC currencies.
Our hard part is to define the \"rules\" of what domain information needs to be present, and when a block can be rejected because of mal-formed domain data. That is where I think it would be wrong to put this more directly into the Bitcoin block chain, as rejecting Bitcoin blocks because of a malformed domain record seems to be harmful to Bitcoins.
Wait, I am a bit confused. Alternative currency for DomainChain?
Oh, these represent addresses?
A coin would represent a domain. I think that is the proposal.
A coin would represent the work or effort to administer the database. That is the \"reward\" a miner gets for processing the domain records. That it might cost 1 DCC to enter a record into the database is just the \"fee\" to play the game, where you are buying the effort from previous record keeping efforts.
Wait, I am a bit confused. Alternative currency for DomainChain?
Oh, these represent addresses?
A coin would represent a domain. I think that is the proposal.
A coin would represent the work or effort to administer the database. That is the \"reward\" a miner gets for processing the domain records. That it might cost 1 DCC to enter a record into the database is just the \"fee\" to play the game, where you are buying the effort from previous record keeping efforts.
Thanks for clearing that up.
Anything is better than buying another domain from godaddy .
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?
",
"nested_level": 0
},
{
"id": 3477,
"thread_id": 244,
"source_id": "122",
"poster_name": "em3rgentOrdr",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=535",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27640#msg27640",
"date": "2010-12-07T04:44:45Z",
"text": "Could ip addresses themselves be managed by this system? The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines.
Having ip address themselves be managed by a bitcoin-like system is a very interesting idea...
I never liked how the government and major corporations get to dish out vast swaths of the ip spectrum by dictate and privilege...
Ipv6 has a privacy issue doesn't it? They stuffed ipv4 because address allocation became a scarce resource by bad management.
Is this privacy issue because ipv6 address will
embed your MAC address?
IPv6, on the other hand, has 128 bits of address space, enough to provide a billion-billion addresses for each square meter of the earth's surface. How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out.
As you might expect, the address field is so huge that the IETF didn't know how to assign it. So, in a move to get buy-in from established industry standards bodies, the right-most 64 bits were designated to contain EUI-64 format information. This is used by the IEEE to assign Ethernet addresses, which are normally not transmitted outside a user's LAN.
Included in EUI-64 are two interesting pieces of information: the registered manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! Every packet you send out onto the public Internet using IPv6 has your fingerprints on it. And unlike your IP address under IPv4, which you can change, this address is embedded in your hardware. Permanently.
Does .dnc = domain name coins?
We could co-opt the democratic national convention lmao.
LOLFEST!
Exactly. My points exactly. The reason for halving bitcoins over time does not really exist for bitdnscoins.
Wondering aloud even more, what need do we have for a fractional bitdnscoin? I could imagine having a little bit of \"change\" but is there going to be any need for more than about three or four decimal places?
I agree...there is not as much reason for fractional bitdnscoins. That just complicates the algorithm and operation. Making bitdnscoin be simple unitary entities is much simpler and easy to understand, so it will increase the likelihood of widespread adoption. Simpler is better. Computer hardware and software like things simple.
This is essentially the same issue just thought through from another perspective. Right now I think it is about 100 million \"bitcoins\" to the smallest unit as defined in the Bitcoin protocol. We really don't need that many decimal places even for trade purposes. I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins. Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective. The only other \"currency\" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.
Could you clarify? Are you talking about because bitcoins have a limited number of digits that it can be divided into (according to the algorithm), that therefore 1 bitcoin could be instead thought of a ~million mini nano-bitcoins that are of fundamental unit of trading size?
Anything is better than buying another domain from godaddy .
Awesome! NO need for the middle man!
rentThis brings up another interesting point: most people will not need to have to pay the yearly ~$10 rent to their domain name provider, if they generate the bitdnscoin themselves. Of course, this does not abolish rent on domain names, as there will be of course some mega bitdnscoin miners will speculate to purchase domain names they think will be in high demand, and will then rent out the popular domains they own.
Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?
This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.
Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?
Well before starting coding, let's make sure we have the protocol clearly written out. For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years? Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name. Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?
Well before starting coding, let's make sure we have the protocol clearly written out. For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years? Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name. And, keep in mind, people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.
+1 on that.
Oh god. I try not to read the news...it just makes me angry.
White House intellectual property czar Victoria Espinel said Monday that the Internet community should \u0093expect more\u0094 pre-emptive action as the administration combats online copyright infringement \u0097 especially the illegal copying and sale of pharmaceutical drugs.
So now we will all have to pay rent for an artificial government-imposed monopoly on life-saving pharmaceutical drugs, just so that we can live longer. Intellectual Property => have to pay rent for your body. IP == slavery. Just because someone is the first to file a patent on a lifesaving drug, doesn't give him the right to exclude others from reverse engineering or independently discovering and producing that lifesaving drug.
Those are the stakes on the table people.
",
"nested_level": 0
},
{
"id": 3485,
"thread_id": 244,
"source_id": "130",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27671#msg27671",
"date": "2010-12-07T06:02:13Z",
"text": "Remember, we can't let those .p2p dudes beat us to the punch!
",
"nested_level": 0
},
{
"id": 3486,
"thread_id": 244,
"source_id": "131",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27673#msg27673",
"date": "2010-12-07T06:13:34Z",
"text": "Well before starting coding, let's make sure we have the protocol clearly written out. For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years? Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name. Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.
I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?
The reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.
I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?
The reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.
Umm, each coin stand for one domain.
However, I don't think we need transaction fee. This is not bitcoin after all.
The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?
I am worried about people who spam change to the DNS database?
Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?
This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.
Is it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.
One of the reasons to maintain the 10 minute interval between blocks is because of network latency from distant node in terms of \"hops\" between nodes. If you shorten the interval you risk more \"collisions\" between nodes that may have simultaneously created a \"successful block\". In turn that also can make even longer \"chains\" start to compete against each other.
In other words keeping the 10 minute interval may be a very good idea or even increasing the interval could have benefits. I know of at least some blocks even with this average that have time stamps which even go \"negative\" where the successive block is timestamped a few seconds
before the previous block. More likely it was created at almost the same time but the other block literally was created a matter of a few seconds earlier.
I would like to put in perhaps a more continuous or shorter interval between difficulty adjustments, but then again there are some network attacks which are thwarted by the two-week readjustment system.
At any rate, do we have enough information that's agreed so that the core hackers can develop right now?
Well before starting coding, let's make sure we have the protocol clearly written out. For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years? Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name. Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.
The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself. The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations. It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too. Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction. Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.
The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself. The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations. It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too. Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction. Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.
Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?
If we could dump this idea of another currency, I'd be all for it. I just don't see how to do that though.
I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.
Umm, each coin stand for one domain.
However, I don't think we need transaction fee. This is not bitcoin after all.
The incentive for 50 coins each block they generate ARE the transaction fee. Maybe?
I am worried about people who spam change to the DNS database?
Coin transfer transaction fees are also important here as well. It allows the cost to be scaled with the size of the network and note that there will be coin transactions in this network as well. There will be coin transfers independent of domain registrations as there will at least be transfers to and from exchanges and likely from miners to people wanting to make registrations directly. There may also be other applications that use these coins that haven't been developed yet.
The \"50 coins\" they may collect are not going to be generated coins but rather fees collected from processing domain records, presuming they are getting 50 domain registrations in a single block.
The only role that generated coins play is strictly to bootstrap the exchanges. You have to get the coins from somewhere, and giving them to miners is as good of a way as I can imagine without simply creating them all in the genesis block and then handing them out like the Bitcoin faucet until that feature runs out of coins.
Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?
This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records. We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.
This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records. We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.
So if you spent a coin to register a domain, then it stay frozen until the domain expire?
If we could dump this idea of another currency, I'd be all for it. I just don't see how to do that though.
I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.
It could be put into the Bitcoin protocol itself, but keep in mind that would require changing the miners in a way that would also have to set up the rules for accepting and rejecting the domain registrations. It also makes this a hack onto Bitcoins to be performing tasks that aren't financial transactions. Some Bitcoin miners wouldn't be willing to participate and may end up rejecting blocks with the domain information buried in the block. This gets back to burying the data into the transaction record itself, and then you get problems again trying to decide what blocks get rejected and which ones don't. On top of all that, it makes this a one-time only change and is not extensible to incorporating other ideas that may be similar.
Really, the only way this is going to work is for a completely separate block chain for the domain data. That implies a second currency.
If we could get some hooks into Bitcoin that would open up some additional data types which could be put into the Merkle tree for the blocks and have some way for a miner to bootstrap verification rules for those additional types, perhaps we could put it into the main Bitcoin chain as well. We would also have to come up with some sort of scripting language that would be used to \"verify\" those extra datablocks sort of like the current scripting language being used to verify coin transactions. Would that be worth some extra effort to make a \"generic solution\" that could be added to Bitcoin for this and other similar kinds of data types to be added to Bitcoin?
It would require a major network-wide upgrade regardless. Coins wouldn't be lost, but older clients would have to be abandoned with an update of that nature. Miners would receive any transaction fees for simply following those rules.
Another question here, and this is perhaps the most important: Would Satoshi be interested in putting in these kind of extra hooks into Bitcoin? By creating a separate currency that is essentially a fork of Bitcoin for a specific purpose, Satoshi's blessing is irrelevant other than coordinating the effort of the two projects to relay problems identified in the two efforts and to make sure fatal problems get updated in bother projects. If we decide to put the data (even as a separate data structure) into Bitcoin, Satoshi needs to be in the middle of all of this discussion. Bitcoin, as it currently exists, really doesn't deal with this kind of issue.
This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records. We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.
So if you spent a coin to register a domain, then it stay frozen until the domain expire?
No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.
No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.
So domain name generation are limited by the velocity of miners spending, but then they have to generate a block to get the coin.
RHorning...thank you for the very detailed responses. It's been helpful that you are so willing to lay down your logic so that some of us can play \"catch up\" as we wrap our heads around this project.
Satoshi needs to be in the middle of all of this discussion. Bitcoin, as it currently exists, really doesn't deal with this kind of issue.
I completely agree here. Even though his \"blessing\" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion. Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.
I completely agree here. Even though his \"blessing\" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion. Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.
We need to get Satoshi's approval if something goes into the main Bitcoin client. There are other applications involved here besides the DNS system, even if that seems to have high priority at the moment. We could create a patch that would put hooks into the Bitcoin software to permit these kind of changes, but it could also be for naught if Satoshi rejects that patch. Since this is also a major architectural change to the software, it seems highly unlikely that it would get accepted unless we can demonstrate a clear need for this idea or show some huge benefits that would help Bitcoin be adopted as a currency. It is also a whole bunch of software development that depends on just one person accepting that change on essentially a whim.
In short, if we decide to put this into Bitcoin, Satoshi is the gatekeeper. We could completely fork Bitcoin, which is essentially what we are proposing here anyway as the alternative with these separate coins. That is our choice.
We need a wiki real bad so Rhorning can write down what he means.
RRRRRRRRRRRRRibuck?
",
"nested_level": 0
},
{
"id": 3498,
"thread_id": 244,
"source_id": "143",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27714#msg27714",
"date": "2010-12-07T10:19:27Z",
"text": "Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?
After all who wants to download a massive block chain just to buy or transfer a domain name?
Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?
It seems this could be a way for bitcoin to have its own \"app\" store of different block chain purposes.
Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?
After all who wants to download a massive block chain just to buy or transfer a domain name?
Is it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?
It seems this could be a way for bitcoin to have its own \"app\" store of different block chain purposes.
An interesting thread related to this can be found here:
http://bitcointalk.org/index.php?topic=2124.0Theymos has been discussing how to put miscellaneous data into the transaction blocks themselves, but there are dangers to doing that. It also shows some incredibly strong resistance to \"tweaking\" Bitcion itself as a software package to permitting this kind of activity, which seems to me as coming from at least a source that would end up killing any attempt to put a patch into Bitcoin to permit data inclusion for something other than the \"stealth\" method with transactions.
While the suggestion that Git itself ought to be sufficient for cryptographic timestamping and cryptographic data storage (that is interesting by itself... something I haven't thought about), I don't know enough about Git to say much about it at all in terms of its distributed nature.
I firmly believe you should \"pay your own freight\" so far as anything which costs others to do, which is why I think this proposal is incredibly useful. There are costs associated with domain name registration and data storage, and they aren't trivial expenses either. The concept of Bitcions enables those costs to be borne by those who use the service. I tried to explore this idea further on this thread:
http://bitcointalk.org/index.php?topic=1764.0This is indeed a political idea here too, which is where perhaps it is getting some resistance as well. The idea could be summed up with the concept that \"you get what you pay for\". Places like Source Forge offer their \"services\" for free, but there are hidden costs including being tied to other outside interests.... mainly the advertisers and those who are paying for the \"service\". With what we are proposing for BitDNS/Domain Chain is that the service is going to be focused upon those who are paying for the service.... which is those who are making the registrations. They have the most to lose if this project falls apart. If the registrants aren't happy with the service, fees are going to go down and the DCC is going to collapse as a currency. That in turn is going to cause developers to be very strongly focused upon meeting the needs of that community.
The other aspect which is really interesting here is that the process of becoming a \"registrar\" has a very low barrier to entry. I'm sure many people would love to have had the chance to do something like being BigDaddy or Verisign in terms of processing domain registrations and receiving the fees for doing that. Now the chance to perform that sort of \"business\" at least on a part time basis is at least possible. No single person or even central organization is going to be receiving the fees but rather a \"community\" that is open to newcomers and even people with modest technical skills.
I've also seen complaints that \"open source software\" doesn't pay. Bitcoin can change that model, including doing things like we are talking about here with the DomainCoin system. Not only can a bounty system be set up for integrating a specific feature into the system, but the developer can also have a continuing source of income afterward. BTW, in deference to Kiba, the license itself is immaterial here too and can simply be thrown into the public domain, even though I think that copyleft licenses tend to offer much stronger protections against idiots who would attempt to mess with you in the legal system. You may want to avoid the judicial system, but sometimes it comes and bites you hard even if you are active in trying to stay out of its reach. Time is really the one resource that anybody has to sell when you finally get down to the gritty details of economics, and it takes time to be a developer to create projects like this. Also, even simply maintaining the software afterward takes time and effort, fixing bugs that show up and perhaps putting in tweaks.
Anyway, enough of the issue with the overhead costs. I am afraid that this is going to effectively split or fork the Bitcoin network, and that isn't a good thing either. I want to work with the Bitcoin community, but if they won't have us, we may have to move on. Threats to Bitcoin will still be relevant and I'm not going to leave completely in a huff, but as a separate application it will be essentially a fork of Bitcoin if we proceed with the path I've suggested in terms of a completely separate coin chain and currency. It might be interesting so far as a social experiment is concerned to see which way is better and which \"coin\" is going to be more accepted in the long run. I am challenging some of Satoshi's assumptions here too, but not overly so. Two very similar project with slightly different goals but which also support each other might be beneficial to each other as well, especially as there is going to be a huge amount of common ground to work with.
Anyway, I have registered domainchain.org, in case people like it.
Care to stick a wiki up on there?
Yes I'll do this. Don't panic!
But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.
Yes I'll do this. Don't panic!
But first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.
We won't make fun of you.
On my Bitcoiner honor!
Trying to predict the exact numbers required is equal to central economic planning, and pointless.
<--- In another thread.
So there's an economic calculation problem. We...cannot reliably predict how many domain name registration are needed each block.
So we going to need to price generation of blocks, somehow?
I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.
I'm always interested in alternatives. Take your time though, and I'd like to see how it is different than what we've proposed here.
OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.
Here's a quick summary:
- Bitcoin already allows for a text \"payload\" to be included with a transaction. Any bitcoin transaction that is sent with the right payload becomes a domain name registration.
- To register a domain name, just send any amount of bitcoin to yourself, with a special payload. This payload identifies itself as a DomainChain payload, and contains the desired domain name plus the IP address of the authoritative name server(s). If no-one else already has that name registered, it's yours.
- To transfer a domain name to someone else, just send them the associated bitcoin (actually any part of the associated transaction will do). The GUI will let you do this in terms of \"domain names\" rather than in terms of \"coins\".
- To change the authoritative name server(s), just send the associated bitcoin to yourself with a payload that identifies the new authoritative name server(s)
- Registrations last forever unless you terminate them by sending that bitcoin to yourself with a payload that is a DomainChain \"cancel\" message
- You can register a domain name with the smallest convenient amount of bitcoins (currently 0.01 BTC), so the system imposes no scarcity of domain names. However, miners will impose transaction fees which increase as the block size increases. This provides a disincentive to registration spammers
- To resolve (lookup) a domain name, the block chain is scanned for the most recent valid transaction for that domain name. In principle, anyone can run a DomainChain resolver, but in practice most users will use a DNS service that is DomainChain-aware
Advantages:
- Provides domain name registration with the same level of pseudonymity as Bitcoin
- Holds registration data in a tamper-resistant distributed manner
- Strengthens Bitcoin by providing additional economic incentive for generators (because they will be able to charge transaction fees for domain name transactions)
- Can be implemented much more quickly than any other scheme that has been proposed so far
- Existing bitcoin clients
are unaffected. If they receive coins that are associated with a domain name registration they will see them as coins. do not display domain name registration transactions. No modification is needed.
Disadvantages:
(I'm sure you'll let me know of the disadvantages.)
Implementation:
1. Patch the standard bitcoin client. Run it on the bitcoin test network. The patched client will have a separate panel for domain names that are associated with bitcoins. These bitcoins will not show on the standard panel, nor will they be included in the total balance available to spend. On the DomainChain panel, instead of a \"send coin\" button there will be buttons for \"register a new name\", \"change nameservers\", \"transfer a name\" and \"abandon a name\". There will also be a scrolling list of domain names together with their nameservers.
2. Write a program that scans the block chain to determine the authoritative domain name servers for a given domain name. Patch a standard open source domain name server to consult the output of this program as part of its name resolution.
3. If it works well, persuade Satoshi to allow these transactions in the main network. Of course, it would be technically possible to run it on a new network with a new block chain, but who wants competing currencies?
There's obviously a lot to be fleshed out, but I think the design is workable and easy to implement.
The DomainChains payloads could look like this:
Registration (with and without nameservers):
DomainChains my-domain.tld
DomainChains my-domain.tld 201.73.213.92 98.252.10.34
Changes of registration details use the same payloads, but the payloads must be sent with a coin that is already associated with the domain name.
To drop a registration and turn the bitcoin back into a spendable coin, send this payload with a coin associated with the domain name:
DomainChains drop
Obviously this is just to illustrate the idea. The concrete syntax may differ.
Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!
",
"nested_level": 0
},
{
"id": 3507,
"thread_id": 244,
"source_id": "152",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27831#msg27831",
"date": "2010-12-07T19:09:44Z",
"text": "OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.
The #1 disadvantage: My complaint about shoving useless and meaningless data into the transaction block. It would work, but there may be changes to Bitcoin to get rid of this \"feature\" as it may be seen as an attack rather than something useful for the project. I am not alone with this attitude. It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion. Expect more resistance if you actually get a client to accomplish this task. Bitcion is not bittorrent.
Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer. It may be possible that the nature of the scripting language itself may be changed to specifically exclude a \"payload\" being used in this fashion.
Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion. You might put into the \"payload\" any sort of in here, but there is no reason for anything or anybody to recognize this data. Instead you would likely need some other application which is reading all of the transaction and either \"accepting\" or \"rejecting\" the domain registrations. Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear \"ownership\" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system). Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.
I admit that some of this could be worked out simply by saying that the first \"registration\" takes precedence, including in the same block. Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would \"apply\" the rules which identify a valid transaction. Competing software could put in different \"rules\" for the same data as well and put different domains as valid.
It was also pointed out that transaction records can be dropped. For instance when you send a coin like this:
Generation Block -- > Alice -- > Bob -- > Charlie
Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:
Generation Block --> Charlie
And all of the previous transactions are ignored and \"forgotten\". If your registration record is in one of those other transaction blocks, it is then lost.
This could work. It would be real nice to see what Satoshi thinks of an \"abuse\" of the transaction scripts in this fashion. My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.
BTW, one advantage to going this route is that it would not require any reboot of the network
I do have my reservations about the direction this is going, but I'm willing to have an open mind about it.
OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.
Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_ProposalSome sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of
x, you can build a complete DNS database by downloading only the most recent
x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than
y blocks deep can be completely forgotten from the network. The value of
y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.
If they receive coins that are associated with a domain name registration they will see them as coins.
You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.
RHorning,
The one objection of yours that I can't address is the one about \"shoving useless data into the transaction block\". This is something for others to decide, and at this time I would respect whatever Satoshi said. But we should not be concerned about \"opening the pandora's box\" because the box is already open and lots of people are going to look inside in the future. That \"problem\" (if it is a problem) is for the owners of Pandora's Block Chain to decide.
What I suggest we do is to try out DomainChain on the test network, and see what bitcoiners think of it when it's able to be experimented with. I'm sure we'll get feedback on whether or not it's welcome in the live block chain.
Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer. It may be possible that the nature of the scripting language itself may be changed to specifically exclude a \"payload\" being used in this fashion.
There's nothing forcing generators to include bitcoin payments that piggyback DomainChain data, but why wouldn't generators want to include them if the transaction fee is high enough to cover the extra costs plus a profit margin?
Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion. You might put into the \"payload\" any sort of in here, but there is no reason for anything or anybody to recognize this data.
That's true, but it's no different from Bitcoin itself. The block chain only has value because a majority of users are prepared to interpret it in a certain way, according to certain rules. If that works well enough for coins, it will work well enough for domain names.
Although we need generators to include the DomainChain transaction data, we don't need the average person's bitcoin client to recognise that data, or act on it in any way. Only the resolver software, and the modified clients used by those who want to register domain names, need to recognize the extra data.
Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.
The first to get their registration into the block chain gets the domain. Ideally the generator who processes these transactions will reject the invalid one. Failing that, the resolver will certainly locate the valid one.
It was also pointed out that transaction records can be dropped. For instance when you send a coin like this:
Generation Block -- > Alice -- > Bob -- > Charlie
Since all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:
Generation Block --> Charlie
And all of the previous transactions are ignored and \"forgotten\". If your registration record is in one of those other transaction blocks, it is then lost.
I don't think there is any problem here. The registration data is re-sent if the domain name is transferred to someone else by spending the coin. All we care about is who has the current registration. We don't care about the history of the domain name.
This could work.
Let's do the \"simplest thing that could possibly work\" for the proof of concept. This seems to be it. If people like it, they will accept DomainChain into the Bitcoin block chain. If they don't like it, we go to plan B.
I haven't read your spec yet, but...
...Some sort of expiration is required..
That's fine. It's not problematic in my design.
Normal clients will ignore such transactions.
That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client.
Wow, after a first readthrough of the spec by Theymos and Nanotube I am astonished by the similarities. And their spec is so much further developed. This is excellent!
I will look through it in detail tomorrow as I've already spent way too much time on this today.
",
"nested_level": 0
},
{
"id": 3512,
"thread_id": 244,
"source_id": "157",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27847#msg27847",
"date": "2010-12-07T20:06:02Z",
"text": "My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.
",
"nested_level": 0
},
{
"id": 3513,
"thread_id": 244,
"source_id": "158",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27851#msg27851",
"date": "2010-12-07T20:23:58Z",
"text": "My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.
Speculation is natural; even healthy.
My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com.
What do you suggest is a better way to decide who gets sex.domain?
Do we have a consensus on nanotube's proposal? Any objection?
",
"nested_level": 0
},
{
"id": 3516,
"thread_id": 244,
"source_id": "161",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27872#msg27872",
"date": "2010-12-07T21:25:32Z",
"text": "Do we have a consensus on nanotube's proposal? Any objection?
just to be clear, it's nanotube's+theymos's proposal
and, we're still working out some kinks in the protocol. consider this to be an open RFC period. it's a bit too early for 'consensus'.
OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.
Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_ProposalSome sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of
x, you can build a complete DNS database by downloading only the most recent
x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than
y blocks deep can be completely forgotten from the network. The value of
y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.
If they receive coins that are associated with a domain name registration they will see them as coins.
You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.
I read your draft bitcoin DNS spec Nanotube and theymous...very interesting. And it's fascinating that ribuck also came up with a very similar design independently. I like the idea of piggybacking bitDNS on top of bitcoin. However, putting the domain name registration requests inside of bitcoin transactions as a message does cause concern about compatibility, should the bitcoin developers decide to remove that feature in the future for security or other reasons. I would suggest, maybe is it possible to have the domain name registration request message be not included directly inside the bitcoin transaction, and instead use some cryptogrphic properties of the block be used to index to a bitcoin registration request message? For example, somehow have the hash of the transaction/block be directly indexable to a DNS registration request? In which case, the information about the sender and receiver of the DNS registration request would be embedded in the hash such that it proves that address X is the owner of that DNS registration request? Thus the bandwidth/traffic of domain name table info/requests would only be paid by those clients who are engaged in domain name registration.
Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:
- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.
- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.
Expiration fixes the \"problem\" of domain names being lost for eternity.
My question is, what are the relative benifits/disadvantages of using a block count based expiration (e.g. 52,000 blocks) versus a time-based expiration (e.g. 1 year)? I would think a time-based expiration would make more sense for average people to understand, since they will know that after a certain fixed period of time, they will need to renew their domain, and can set that in their calendar, instead of being completely unaware if the block count reaches some number? Never mind...I get it...52,000 blocks is approximately the number of blocks that should be produced in 1-year time assuming a rate of 1 block/10 minutes is maintained.
My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.
Speculation is natural; even healthy.
What Kiba said. Speculation is a part of any world where there are limited resources. Speculation allows the market to come to a subjective valuation of the unknown value of such resources. The speculator takes a risk by buying domains (even if it is just an opportunity cost), and that risk is entirely held by the speculator.
I read your draft bitcoin DNS spec Nanotube and theymous...very interesting. And it's fascinating that ribuck also came up with a very similar design independently.
Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.
I read your draft bitcoin DNS spec Nanotube and theymous...very interesting. And it's fascinating that ribuck also came up with a very similar design independently.
Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.
Oh yes, I am perfectly aware. In fact, the prevalence of simultaneous inventions is a strong argument against the necessity of a patent system to \"reward\" inventors with monopoly.
OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.
Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.
I'm looking at the fees, which certainly would be a reason for a miner to include these into a block with a high priority. Still, I'm trying to find any sort of motivation for a \"DNS Server\" to recognize any of this data other than as a repository of potential domain information. There is a reference to a \"vibrant market\" for the fees being used here, yet this seems very altruistic that one of these servers would recognize any fee at all if they aren't getting any themselves. I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.
I suppose that this is in effect a way to ensure that the Bitcoin network stays strong, as it certainly is going to be making any sort of mining activity much more profitable by doing this.
What pricing strategies that would be used by a domain server which would have an adjustable price in the interface or config file and why one server would set the \"price\" at 10 BTC or another at 15 BTC or still another at 5 BTC? Is this basically \"filtering out spamsites\" or is there something more serious going on here? Is this simply an \"open bid\" for each domain where the most money invested \"wins\" the domain?
Toward the end of the document there is a reference after a fashion about some more complex fee allocation system that passes around addresses which get deposited into some servers after a fashion. I guess this is where I'm totally missing the point here perhaps or not understanding what is going on at all with these fees as there is something more implied by this document not written down.
What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?
I have a couple questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal
When you register a name, there is a fee to a DNS server. In the doc, this appears like a Bitcoin transaction fee. The first example shows 10.01 input and 0.01 output, so the 10.00 difference would be a transaction fee. But tx fees go to miners. Is it assumed that miners are the same as DNS servers? Or would there be a 2nd output, a fee to a particular DNS server to get it to register you, in addition to a tx fee to the miner?
Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?
Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?
Thanks -
",
"nested_level": 0
},
{
"id": 3522,
"thread_id": 244,
"source_id": "167",
"poster_name": "Anonymous",
"poster_url": null,
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27925#msg27925",
"date": "2010-12-08T00:03:21Z",
"text": "This is exciting stuff. The benefits of having an intrinsic value to bitcoin is inestimable and kills a lot of arguments against it. I would like to hear satoshi's thoughts on this as forking the network is not a decision taken lightly.
Is there a way to reserve the top 1000 domains at Alexa ? I can see massive issues down the road if say google has their name squatted on. Doing this would bring a lot of goodwill towards bitcoin rather than having all the top companies against it. One way this could be done is for the dev team or a council of bitcoin elders register all of these names before the client is publicly released and hold them in trust. When a top 1000 company wishes to claim their name the profits could go to benefit bitcoin. Is that a good plan?
",
"nested_level": 0
},
{
"id": 3523,
"thread_id": 244,
"source_id": "168",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27926#msg27926",
"date": "2010-12-08T00:18:40Z",
"text": "Is there a way to reserve the top 1000 domains at Alexa ?
This is a very good and important idea, we should set-up some 'domain trust' where well established domains will be protected until they are claimed (at a good fee) by a verified owner.
Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request. Once the network is more established the minimum time-lock can be reduced.
Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request. Once the network is more established the minimum time-lock can be reduced.
No, no, no. The DNS system should be kept as simple as possible.
There will be no silly voting, or court, or any complicating shit.
Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request. Once the network is more established the minimum time-lock can be reduced.
No, no, no. The DNS system should be kept as simple as possible.
There will be no silly voting, or court, or any complicating shit.
I think the delay in releasing the client would be enough for the top 1000 to be locked in
I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.
That is the point.
A handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.
People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.
Is this basically \"filtering out spamsites\"
Exactly.
What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?
Bitcoin already supports it technically, though recently a change was made that causes non-standard transactions such as the ones used by BitDNS to be skipped in blocks created by the official Bitcoin client. However, BitDNS transactions produce quite a lot of fees for generators, so if an implementation is created, I expect it will be easy to get a reasonable percentage of miners to ignore this new rule (only like 5% is really necessary).
Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?
The left-most part has to stay the same. \"theymos.btc\" can be changed to \"theymos.bc\". Everything but the left-most part is advisory: \"theymos.btc\" can actually appear as \"theymos.btcdns\". In particular, if someone registers a top-level domain such as \"theymos.\", most servers will probably map it to \"theymos.btc\" or something.
Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?
Anyone can run them. I think the expiry time should be lowered to like 5,000, though, to make it easier to run a server.
I think reserving the top 1000 alexa domains by seeding the genesis block with those \"registrations\" would be an excellent show of good faith towards the world at large. A council of bitcoin \"elders\" could be elected to hold the private keys to those initial 1000 domains, and turn them over when the time comes (for a fee, which will go towards bitcoin/domainchain community funds).
",
"nested_level": 0
},
{
"id": 3528,
"thread_id": 244,
"source_id": "173",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27936#msg27936",
"date": "2010-12-08T00:48:00Z",
"text": "So in theory this is the perfect system for claiming a 'named address'. If I wanted to send a payment to 'theymos.btcdns' I could. Or is my understanding wrong?
",
"nested_level": 0
},
{
"id": 3529,
"thread_id": 244,
"source_id": "174",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27937#msg27937",
"date": "2010-12-08T00:51:13Z",
"text": "re-read nanotube's+theymos's proposal! Sound Good
+1
This is all very fascinating stuff. I read themos+nanotube's proposal, ribuck's proposal, and rhorning's. While I think I grasp the fundamental differences between them, I am not confident to weigh in. Could I ask that someone more knowledgeable than I am on these matters create a table (wiki?) that lists the proposals as they currently are?
I'm personally very intrigued by the idea of piggy backing on the existing bitcoin network, if it can be done cleanly and with minimal modification to bitcoin (as per nanotube/themos suggested).
As Kiba pointed out, I am most excited for bitcoin to have it's intrinsic \"use-value!\" And it couldn't come at a more needed time what with wikileaks, pirate bay, etc all over the news.
Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a \"DomainShadow\" system that is only used in the event of crisis (like wikileaks attack, etc)?
Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)
",
"nested_level": 0
},
{
"id": 3531,
"thread_id": 244,
"source_id": "176",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg27958#msg27958",
"date": "2010-12-08T02:08:20Z",
"text": "
Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)
Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.
Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a \"DomainShadow\" system that is only used in the event of crisis (like wikileaks attack, etc)?
DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!
I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.
It should scale well, though, if it did go mainstream.
DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!
I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.
It should scale well, though, if it did go mainstream.
just to throw in a little bit of optimism here
, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption.
DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!
I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.
It should scale well, though, if it did go mainstream.
just to throw in a little bit of optimism here
, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption.
We need a proof of concept.
Yes, coding need to be done soon.
Repeating ad nauseum:
Speed is of the essence.
",
"nested_level": 0
},
{
"id": 3536,
"thread_id": 244,
"source_id": "181",
"poster_name": "chaord",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=262",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28033#msg28033",
"date": "2010-12-08T05:45:40Z",
"text": "
Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)
Very strange to form a foundation for DomainChain before we form an organization for Bitcoin.
Ha. Good point. I was thinking the two could potentially operate under the same umbrella. We'll see though.
Referencing this thread
http://bitcointalk.org/index.php?topic=2129.msg27968#msg27968I think Gavin is trying to tell us the way forward .
BitDns is not bitcoin.
We already have a forked chain.... Get something working on the test network and prove your theories.
Lets get it started in here.....
A few more questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal
It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.
Names can be changed when registered, but only from one TLD to another. You could change pics.sex to pics.p2p. I don't understand the motivation for this. It seems like something that would seldom be useful.
I'm still confused about fees. I was assuming that fees would be paid to the DNS servers, for the service of acting as a gateway from the Bitcoin block chain to the DNS system. I now see another interpretation, where DNS servers don't receive the fees, but they nevertheless demand that transaction fees of a certain minimum level be paid to miners. As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?
The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today. (I may be misunderstanding this!) Each of these DNS servers publishes a schedule of fees for performing this service. To register a new name... hmm, I am guessing now. Would you contract with one particular DNS server to do something else than host your regular DNS records?
I had thought it would be ok to expect DNS servers to follow the block chain and honor valid domain name transactions without requiring certain minimum fees. Domain names are so valuable (at least at first) that miners already have ample motivation to demand substantial (like $100 = 500 Bitcoins per transaction) fees. Eventually, if the system is successful, virtually all DNS servers would read the block chain.
",
"nested_level": 0
},
{
"id": 3539,
"thread_id": 244,
"source_id": "184",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28127#msg28127",
"date": "2010-12-08T14:22:34Z",
"text": "I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.
That is the point.
A handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.
In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too. Each \"TLD\" would have its own central server where you would have to \"pay\" to get onto that server?
What I don't see is the mechanism for how or even why a particular DNS server ought to even receive these fees as opposed to somebody else creating a \"registrar server\" and following this same protocol to put that data into Bitcions for considerably less or even \"free\". This issue of where the money goes has been to me the issue all along, and the only place that could be identified easily as having done some sort of \"proof of work\" in terms of organizing the data is the block miner itself.... that is the Bitcoin block miner and not the DNS block miner as there is no sort of DNS block here at all.
I don't see any rationale for using a particular registrar other than merely because of sheer convenience and the hassle of setting up the software on your computer.
If there is some way that you might show some cryptographic \"proof of work\" in processing domain records, I might agree that a particular \"registrar\" deserves some separate fees in addition to the Bitcoin miner, but then the problem is how do you get those fees to that particular \"DNS Block miner\"? Otherwise there isn't any sort of effort being put forth by the registrar at all where literally anybody could create some software to put these records into the system.
I could imagine a system where a sort of auction system on a particular domain happens where the person throwing the most number of bitcions in for a registration record \"wins\" the domain, but something seems a little off on that as well. It also implies that anybody can \"steal\" your domain simply by throwing more coins at it than you have. It is a great idea for miners, but lousy for those trying to register domains.
This is all about the money from my perspective, and this part has not been cleaned up for me upon reading the documentation. The actual storage of the registration data itself has always been to me a trivial piece of the puzzle. Throwing those records into Bitcoin transactions are useful as they do provide the time stamping and hashing ability of Bitcoin software, but any fees beyond Bitcoin transaction fees seem to be a pointless exercise without any sort of further proof-of-work. Any additional fees being thrown with the \"registration\" is not going to anybody actually putting effort in terms of running the domain server or doing registrations. I could imagine some \"greedy\" DNS servers that might expect to be paid for bandwidth and being paid in Bitcoins or some other currency, or perhaps a very small fee for actually putting the transaction into the Bitcoin blocks for those who only have a \"thin client\" for Bitcoins, but those fees would be subject to a huge and highly competitive market where for most people it would be \"free\" anyway.
This is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records.
I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow.
The left-most part has to stay the same. \"theymos.btc\" can be changed to \"theymos.bc\". Everything but the left-most part is advisory: \"theymos.btc\" can actually appear as \"theymos.btcdns\". In particular, if someone registers a top-level domain such as \"theymos.\", most servers will probably map it to \"theymos.btc\" or something.
I really don't get this. What's the point of having a \"right-hand-side\" if it is advisory? The user doesn't want to have to type
theymos.bc into their browser when they're at an internet cafe that uses one DNS, but have to type
theymos.btcdns into their browser at home if their ISP uses a different DNS. And if they just type \"
theymos\", what if they are on a LAN that has a node called theymos?
Any default right-hand-side should be explicit in the spec. Also, I don't think something hard-to-pronounce like \".btcdns\" is going to work with the public. Can you imagine TV ads saying \"go to walmart dot bee tee see dee en ess\"?
In the initial phase at least, I suggest that all names registered should be of the form
something.domainI propose \"
.domain\" for this purpose because it's generic and pronounceable. It also somewhat cheekily implies that this is the ultimate all-encompasing domain name registration system.
Three advantages:
- This establishes clear branding.
- It helps to keep the system simple, so that we can easily describe how to get up-and-running with these newfangled names.
- It avoids any clashes with existing domain names.
If people prefer to go for something more ambitious, I suggest that all names registered should be of the form
something.tld where
.tld can be anything of three or more characters except for existing recognised top level domains. So you could register
hamburger.red or
silly.fool but not
zebra.comIs there a way to reserve the top 1000 domains at Alexa ?
Please let's drop the idea of reserving the top names. Would you think it was fair if you owned the 1001st domain? It's only going to lead to disputes and hassles.
I suggest that we exclude
all existing top level domains from DomainChain registration. So no-one will be able to register
google.com through this system. They could, however, register
google.domain but they would probably have to fight with Google in court under trademark law.
We really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest.
We really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest.
It could set some precedent for protocol change that allow people to shut down certain domains.
I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.
My concern is that there would be a rush to grab hot domains.
If desired, an initial rush could be spread out by a phased introduction.
For example, in the first week only names of ten characters or longer would be accepted for registration. The next week, names of nine characters or longer would be accepted. And so on, until by week ten any length will be accepted.
A more sophisticated phasing would hash the domain name to a number from 1 to 1000. On each of the first thousand days, names that hash to that day's number are added to those that can be registered. So, by day 42 it would be possible to register any domain name that hashed to a number in the range 1 to 42. After day 1000, any name could be registered.
A third possibility is simply to limit the number of registrations. Suppose each block limited the maximum number of domain name registrations to the current generation difficulty divided by 1024. For now, that would mean 8 domain name registrations per block, but the limit would rise over time (quite quickly, I think).
I'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so.
I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.
We really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest.
Agreed. I suggested in my previous domain allocation system that the standard ICANN/InterNIC domains and perhaps to be fair some of the domains currently being done with other networks like OpenNIC and the .onion \"domain\" of the Bittorrent network ought to be held in \"reserve\" as a part of the internal protocol we are setting up here. My suggested domain allocation system would have that as an organic part of the system although it would be useful to hold these TLD in escrow for whenever or if ICANN wants to have control of them.
Since to use one of the TLDs with a server you would need to have it assigned to an IP address of some sort, somebody like Google could go aver \"google.btc\" as a trademark violation by searching for the network which assigned the IP address of the server using that name. If the domain record points to 127.0.0.1, it really isn't a threat to Google until that address changes anyway. I agree that this is beyond the scope of this protocol to take care of the Alexa top 1000 names and the only real issue is spoofing existing domain names being used by other DNS registries.
As a side note, during the actual reference implementation of one of these servers it would be nice to throw a bone to OpenNIC and the \"dot P2P\" guys (presuming they set up their own system) to forward DNS requests that might fall under those respective domain registries. This is sort of a tip of the hat to say thanks for making sure ICANN doesn't have 100% exclusive control over domain registrations and to support what I think are good projects in their own right even if they aren't a P2P distributed naming system. That might even get a reciprocal agreement with those alternate domain registries to spread these registrations with the DomainChain registries much further at least initially.
It could set some precedent for protocol change that allow people to shut down certain domains.
I suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.
Who would be given the \"authority\" to remove domain names? That implies central authority of some sort that has control over this network.
Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system. By setting up a system to \"delist\" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems. If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your hands up and say \"I can't change that, sorry\".
The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.
Who would be given the \"authority\" to remove domain names? That implies central authority of some sort that has control over this network.
Domain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system. By setting up a system to \"delist\" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems. If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your handseddrli up and say \"I can't change that, sorry\".
The owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.
You have forgotten the rule that I asserted earlier in the thread:
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.
Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.
Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network? If you got an idea on how to implement that, I'm interested. The only system I can think of is to arbitrarily assign authority to \"somebody\" to take care of that issue. You could have a \"voting\" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore \"by consensus\" drop the domain. It would also provide an unneeded attack vector on the network as well as the \"votes\" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.
I just don't know of an effective way to kill a domain record shy of simply letting it expire. As long as the registration is following the rules of the network (however we set that up), I don't see how it could possibly be removed.
Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network? If you got an idea on how to implement that, I'm interested. The only system I can think of is to arbitrarily assign authority to \"somebody\" to take care of that issue. You could have a \"voting\" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore \"by consensus\" drop the domain. It would also provide an unneeded attack vector on the network as well as the \"votes\" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.
You misunderstood me. I didn't suggest anything like voting or whatever.
The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.
My design stores the domain name plus a couple of nameserver IP addresses (say, 50 bytes) for an everlasting registration.
The theymos/nanotube design needs much more data: the initial registration, the regular renewals, and the possibility to include actual DNS records themselves up to 520 bytes. There's talk of the renewals being required perhaps as frequently as every 2000 blocks, and certainly no more than every 52000 blocks.
Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.
I'm starting to think that an everlasting registration really is the way to go. In the DomainChain design, the registration would not be affected by block chain compaction, since compaction only affects spent transactions. If you transfer a DomainChain registration, or modify its name servers, all of the necessary information is contained in the latest transaction, which will remain unspent until the registration is deliberately modified. However, the theymos/nanotube design requires a sequence of transactions (registration, extra fee, DNS record, ...) where only the last transaction in the sequence remains unspent.
I think users will be uneasy about having to renew every 2000 or even 52000 blocks. Having to remember to renew, in order to avoid losing your registration, is bad enough. But block generation rates are variable, so that you won't even know for sure when your renewal falls due. Unpredictable renewals are not something that would make me feel good about using such a system for my domain name registrations. I can see many accidental domain name losses occurring under this system.
Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.
",
"nested_level": 0
},
{
"id": 3550,
"thread_id": 244,
"source_id": "195",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28172#msg28172",
"date": "2010-12-08T17:54:03Z",
"text": "
Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.
Time based expiry date rather than block based expiration system. Obviously registrar could remain users to renew as they had done in the earlier system.
A handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.
People who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.
Re-reading this, I think I \"get\" how this is going to work for registrars, at least how Theymos is proposing here.
Each \"Domain server\" would separately and independently charge a fee for \"registering\" the domain on that particular server, where essentially everybody would be paid simultaneously when a new domain would be registered.
Something here just doesn't sound right, which is why I keep bringing this up. I don't see the mechanism for recognizing new domain servers or what criteria ought to be used so far as to whom these fees are going to be allocated. A domain server which is regularly being used by just a couple computers in a small office would in this case be a \"peer\" to a domain server at a major university servicing perhaps thousands of computers for domains. Yet in this case both would be receiving registration fees and from a network perspective would be indistinguishable. However getting \"your domain\" recognized by that major university server would be much more \"valuable\" than the server in a small office. Any attempt to report usage could easily be manipulated in a number of ways making it to me impossible to realistically distinguish between the two servers, at least algorithmically.
Maybe I'm missing something fundamental here. I sure hope so. It seems sort of silly for somebody to set up a \"domain name server\" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used. That sounds like a neat gig to get into, but I don't understand what \"service\" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered \"equal\" and receive roughly the same amount of money?
I think we should dispense with the complexity associated with paying various servers. We should also dispense with the concept of paying more if we want better visibility for our domain names.
No-one wants a system where some people can reach
some.domain and some people can't, depending on which servers are getting their share of the payment. Or a system where a new server can come to prominence and put pressure on people to pay again for the domains they already paid for.
Let's cut it down to the
simplest business model that can work.
Suppose there are some generators who will include domain name registrations into blocks that they generate, because they want to earn the transaction fees. Those generators will operate public-facing domain name servers.
Why? They need to do this, to make the domain name service credible so that people will use DomainChain for their domain registrations. For the generators, it's an overhead, but a necessary one. Kind of like how most restaurants provide toilets without charging separately for them.
You could argue that there will also be some operators who would generate, and who would collect the transaction fees for domain name registrations, but who would not operate a server. After all, why incur the overhead if the other generators will operate the servers?
But the market will take care of this. The generators who do operate servers are not going to accept the blocks generated by those who sell domain names without providing domain name servers.
Additionally, a market like this is likely to have two other kinds of players.
There will be a few organizations who are willing to operate a server for free, perhaps for ideological reasons. Those servers will probably be overloaded and slow (like the free Usenet servers), but they act as a backstop which forces the commercial operators to provide something better.
There will also be a few commercial operators who provide enhanced super-fast servers without being generators. They will do this either because they have paying customers who want the best domain name service that is possible, or they will do it for their own business reasons (as Google does with their free-to-access domain name servers).
Here are the advantages of this simpler system:
- For the domain name owner, the registration is convenient, secure, and lasts forever,
- For the internet user, the same set of domains is served to everyone,
- For the generators, it's a worthwhile extra source of income, and
- For the Bitcoin system, it's an easy way to get extra strength into the block chain with minimal extra data
Time based expiry date rather than block based expiration system.
Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.
Of course, there is nothing that forces the providers of domain name servers to compact
their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains.
I agree with ribuck that DNS servers don't necessarily need to get paid, to support Bitcoin domains. After all, what is the purpose of a DNS server? It is to lookup domains for its clients, which are users wanting to connect to computers using domain names. If BitDNS becomes popular, DNS servers will want to be able to lookup those domains too. All that is necessary is to track the block chain and maintain indexes and hash tables to record which domains are in effect and their basic DNS data. DNS servers don't have to be Bitcoin miners. The existing motivations for DNS servers to operate and provide lookup serves to their clients will be sufficient to make them track Bitcoin domains.
",
"nested_level": 0
},
{
"id": 3555,
"thread_id": 244,
"source_id": "200",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28295#msg28295",
"date": "2010-12-08T22:48:14Z",
"text": "DomainChain wiki is here:
http://domainchain.org/wiki/doku.php?id=startThere's not much there, but I will work on it tomorrow.
Meanwhile, some interesting further ideas on integrating with the Bitcoin block chain have been added to the Theymos/Nanotube wiki.
It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.
This is like that, too. In this system, you're always registering a TLD. Even if I register \"theymos.btc\", I'm actually getting \"theymos.\". For better usability, though, BitDNS servers will make this a second-level domain by attaching a TLD like .bitdns or .btc to the registered name. The TLD in the registration is a suggestion for this: in this case, I'm suggesting that \"theymos.\" be followed by \"btc\" (though the server is free to ignore my suggestion).
The idea is to allow maximum market adaptability. Probably all servers will just use \".btc\" or whatever, and totally ignore the suggested value. As an example of something servers could do:
- If your suggested domain suffix is com/org/etc., then your domain will actually overrule .com domains of the same domain for those few users who have configured BitDNS to do so.
- Otherwise, \".btc\" is used.
It's a bad idea to hardcode any TLD into the spec. What if ICANN allocates .btc?
A later version might also look at the entire name+TLD for uniqueness. It might be possible in that case to switch from old-style names to new-style names with namechange.
As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?
Yes. The idea is not to compensate the servers (usually), but to eliminate spam registrations. The BTC is the \"proof-of-work\".
The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today.
The servers are analogous to DNS root servers. There may also be registrars, which will interface with several BitDNS servers (as current registrars interface with gtld-servers.net, for example).
In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too. Each \"TLD\" would have its own central server where you would have to \"pay\" to get onto that server?
Certainly not. You pay and everyone recognizes you at whatever TLDs they have chosen to see BitDNS domains at.
Any additional fees being thrown with the \"registration\" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.
Almost all of the load is carried by the Bitcoin miners, which is why they get most of the money. Some BitDNS servers will provide public lookup services, which demands some payment. I'm thinking that the registrants will pay these to list them, but maybe the people looking up BitDNS domains will pay them instead.
Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.
The average Bitcoin transaction size is 216 bytes. Why does anyone care if BitDNS names are worth 3-500 Bitcoin transactions over 10 years? If miners are taking the transactions, then there is no supply problem. If there is a supply problem, then whoever pays more gets space in blocks. This is fair.
I'm starting to think that an everlasting registration really is the way to go.
Without an expiration, you need to download the entire block chain to get a current DNS database. Domains must expire if you want to allow end-users to run their own server.
It also destroys unique resources. The pricing scheme would have to control the use of these unique resources appropriately, which requires some market mechanism.
You have forgotten the rule that I asserted earlier in the thread:
When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.
Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.
Kiba is wise beyond his years!
Anyway, I've been thinking outside the box a little bit...and wondering maybe to scratch the whole idea of domain names. I'm thinking somehow be able to associate a bitcoin address, or maybe some hash of a transaction, with a location on the internet somehow. Also, it maybe possible to sidestep away from the concept of domain names considering that nowadays search engine technology has improved so much.
Wouldn't it be cool to associate a bitcoin address directly with a webpage/internet location for that product/resource/whatever that is being sold with that bitcoin address? Anyway, let me think about this some more and write out a concrete proposal. Obviously, this is sortof off topic from this thread...
Asking as a general question, is the whole concept of throwing the data into transactions a dead issue now? With the release of Bitcoin v. 3.1.18 Satoshi has essentially thrown down the gauntlet that adding such data to transactions is considered a form of an attack on the network. Miners who aren't using a codebase derived from the reference implementation still may add blocks to the network involving these \"goofy\" transaction packets, but by design the reference implementation will not recognize the transactions. If we work around the IsStandard() algorithm, it is only going to change to stop whatever changes we make.
This is a subtle but interesting issue where essentially the only way we can guarantee that a domain transaction can be put into a block chain is to create a custom miner and compete for blocks to put those transactions into the network. That makes for some interesting problems in terms of latency for an effort like DomainCoin.
Should we move onto the forked version of Bitcoin to implement this idea again?
",
"nested_level": 0
},
{
"id": 3559,
"thread_id": 244,
"source_id": "204",
"poster_name": "kiba",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=491",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28322#msg28322",
"date": "2010-12-09T00:39:12Z",
"text": "Miners are rejecting the [edit]isStandard.
",
"nested_level": 0
},
{
"id": 3560,
"thread_id": 244,
"source_id": "205",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28327#msg28327",
"date": "2010-12-09T00:52:19Z",
"text": "Miners are rejecting the same.
How are the miners going to get these transactions? I don't think the transactions are even being broadcast from one node to the next if they fail to meet the
IsStandard() algorithm, but rather they must be put in directly by a miner. I'll have to dig into the 0.3.18 source code for the details, but the description is just an initial shot across the bow on this concept. If you have a miner as a peer who ignores this algorithm, they might get put into the block, otherwise you might just be SOL. From what I understand, if all of your peers are 0.3.18 clients (and presumably later versions too) they won't even forward transactions to other peer nodes that are \"corrupted\".
It is a subtle change, but it is a big deal.
It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.
This is like that, too. In this system, you're always registering a TLD.
So what would prevent me from registering the domain jackass.theymos.btc?
Others elsewhere or previously have suggested we build a chain dependent on the bitcoin chain. Some way to hash the data against a block.
That way, miners would still be strengthening the bitcoin network.
",
"nested_level": 0
},
{
"id": 3563,
"thread_id": 244,
"source_id": "208",
"poster_name": "appamatto",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1958",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28343#msg28343",
"date": "2010-12-09T01:27:49Z",
"text": "Hey guys. I'm really surprised that my post received so much attention!
And, I'm glad that BitDNS (or domain chain?) has generated this level excitement.
However, I urge you to re-read my initial post, as I feel that original formulation of the idea solves many of the problems you are currently discussing, including the (1) business-plan problem and (2) the bitcoin integration problem. There is also a third problem which hasn't been brought up by anyone thus far, which is (3) the problem of dividing the CPU pool among multiple block chains.
In the original formulation, bitDNS is simply an example of a possible generalization of bitcoin. It should be possible to dream up many such applications requiring block chains for systems that need some kind of quorum.
We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS. It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.
BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload. This way a bitDNS server will only need to download its own app payload without worrying about bitcoin's payload and vice-versa. As the number of bit-apps increase, this problem of smushing them all into bitcoin will only get worse, and (2) becomes a big problem that has to be solved for each app. BitX neatly deals with applications liberally, leaving it completely up to them to decide their own protocols but forming a valuable backbone for them.
With bitcoin and bitDNS as separate apps running on BitX, (1) is easily solved with third-party escrows. Escrowing is a big problem, and perhaps unsolveable, with respect to bitcoin and USD or PPUSD transactions, but it is incredibly reliable when executed between two bitapps. A trusted escrow can receive both transactions, verify them mechanically and automatically release the assets when both transactions are properly verified.
Note that this also frees bitDNS from bitcoin baggage when bitMoney overtakes bitcoin as the most popular bit-currency. I believe in fact that bitcoin in its present form will necessarily be overtaken due to problem (3).
The big deal: the CPU pool division problem. CPU division will occur when bitcoin can't or won't support bit-application bitFoo. This may occur with bitDNS, or it may occur later, but I think it will occur at some point.
Every miner for bitFoo will be one less miner for bitcoin and vice-versa. Both of these systems will be twice as susceptible to attack (if they have roughly equal CPU pools), and the problem multiplies as the number of bit-apps and their block chains increases.
BitX cleanly solves this by having every bit-app generate on the same block chain, the BitX chain. They weave their own block chains within the uber-chain, and unwittingly protect eachother from attack. It also greatly speeds adoption of any given bit-app; the BitX miners are already generating bitcoins, so why not generate bitDNS names as well? There is no cost to the miner, and who knows, this new-fangled bitDNS thing might actually take off someday?
Even if the demerits of separate block chains can be mitigated, the merits of a unified chain cannot be overstated in my view.
Finally, I hope that the name will remain BitDNS or BitNames, keeping the trend of revolutionary projects like bittorrent and bitcoin. There isn't any reason to call it domainchain if it is built upon BitX in any case, because the name registration aspect will be an implementation on top of the BitX chain rather than a full implementation with its own chain.
This separation of concerns makes BitX and bitDNS/bitcoin simple enough that I feel I can implement them myself if necessary, although slowly, in my spare time. I'm looking forward to some bit fun!
Thanks guys!
",
"nested_level": 0
},
{
"id": 3564,
"thread_id": 244,
"source_id": "209",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28350#msg28350",
"date": "2010-12-09T01:38:56Z",
"text": "So what would prevent me from registering the domain jackass.theymos.btc?
Nothing. But hopefully servers will ignore tricks like that.
How are the miners going to get these transactions? I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.
Right. You can send directly to artforz.ath.cx or any of doublec's pool addresses. I will relay non-standard transactions at theymos.ath.cx.
We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS. It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.
BitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.
Responded, in
this new thread.
I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.
The solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.
EDIT: see
http://bitcointalk.org/index.php?topic=1847.0 for info about how the transaction fees will dictate what is included in the chain.
I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.
The solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.
Bigger stuff mean higher priority. Bitcoin users who didn't load the bitcoin chain data with lards are left with lower priority.
Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.
Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.
Whos in?
",
"nested_level": 0
},
{
"id": 3569,
"thread_id": 244,
"source_id": "214",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28476#msg28476",
"date": "2010-12-09T10:27:57Z",
"text": "Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.
Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.
Whos in?
Not me! I think that nanotube's+theymos's proposal has real elegance! Creating another chain is all good and well, but the current chain can be used for many things, might as well maximize it's potential.
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_ProposalOk its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.
Problem solved. To provide the initial security to the network it needs a few miners with gpu cards.
Whos in?
I'm not in for a new genesis block. It risks harming Bitcoin. If the alternative block chain is commercially successful, someone will add a currency to the alternate chain and it will overtake Bitcoin.
Anyway, don't think that Satoshi has killed the idea of Domain Names in the block chain. Here's what the latest changes mean:
1. If you register a domain name, you must connect to a miner that supports it (because standard clients won't relay your request). No problem. You will need to be using a modified client anyway (to give you a way to specify the domain name, the IP addresses and the fee) and the client can be designed to connect to known performant miners (which will probably be most of them).
2. The standard Bitcoin clients will accept the blocks generated by the performant miners, but won't see the Domain Name transactions.
So what's the problem? What's not to like?I say we should continue to develop the ideas, then try them out on the test network.
I still hear talking.
I was doing some reasearch into alternatives to DNS, and I was reading about how
TOR's hidden services assigned .onion address, and I came across the concept of
Zooko's Triangle, which argues that names cannot be global, secure, and memorable, all at the same time:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.skyhunter.com%2Fmarcs%2Fpetnames%2Fzooko-triangle.gif&t=589&c=8bcVocby0NPdxA\"/)
\"Domain names, for example, are global and memorable, but as the rapid rise of phishing demonstrates, they are not secure\". Basically, there will always be imposters who try to claim the domain name of your brand or some misspelling. So I'm almost wondering if the whole concept of domain names is fundamentally flawed to begin with. And it seems there is always has to be some sort of centralized means of allocating domain names. We can't even decide what should be the rate-of-issue for new bitDNS domain names, what the starting price should be for transaction/purchase, how many top Alexis domain names (if any) we should reserve, where/how should the domain directory be located/stored. Maybe we need to stop using domain names entirely, and put our focus more on search engines, links, coupled with public-key cryptography to authenticate the genuity of an internet brand/website/address. I'm looking into some system called
Pet Names...and am trying to figure out a nice way they could be used to assign unique, human-readable (memorable), and global names for bitcoin addresses. I will start another thread for this, and provide a link here...
Anyway, I think NoAgenda is right here that the Bitcoin block chain, from now on, should be a pure financial vehicle, considering that the latest bitcoin version update removes the ability to include extra text in transactions:
Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.
Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.
The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.
... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...
Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.
Maybe we need to stop using domain names entirely
If you try to redesign everything, you will end up successfully redesigning nothing.
of course, I didn't mean I wanted to redesign the whole DNS. The conclusion of my musing is: maybe there is some way to associate bitcoin addresses with a unique and human readable (memorable) name using a petname system.
The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.
I think this is important, and I encourage people to work on this.
... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...
Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.
Ok, thanks for clarifying.
Of likely interest:
\"Gov't crackdown spurs initiatives to route around DNS\"
http://www.itworld.com/legal/129947/net-censorship-dns-alternativeOur code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.
* kiba is anxious.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
",
"nested_level": 0
},
{
"id": 3578,
"thread_id": 244,
"source_id": "223",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28697#msg28697",
"date": "2010-12-09T21:05:36Z",
"text": "Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post.
Don't be anxious. I already said I thought it would take 2 weeks to agree design directions before coding.
There has been excellent development over the past 24 hours. It has become clear that Gavin's changes to handling of non-standard transactions don't rule out domain registration integrated with Bitcoin.
It is also becoming clearer that there is less distance between my DomainChains ideas and the theymos/nanotube design. Their design does not have the tangled ties with domain name server operators, that I previously thought it did.
Hang in there! Two weeks will seem like
nothing in the long term outcome.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
sounds excellent in theory...
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
seems that the miner would have to basically do \"extra work\". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
very curious to hear your further thoughts on this.
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
This sounds very very interesting, something to explore.
Can you elaborate on how would it work in practice? Separate networks and block chains implies hashing one block header for each network, with different resulting hashes, does it not?
The only thing I can come up with is the completely naive and slightly cache-unfriendly implementation...
while (nonce < 0xffffff)
nonce++
for each network
data_block[nonce_offset] = nonce // ie. our nonce
scanhash(data_block)
or
for each network
while (nonce < 0xffff)
data_block[nonce_offset]++
scanhash(data_block)
I could easily update cpuminer to poll multiple RPC endpoints for 'getwork'...
seems that the miner would have to basically do \"extra work\". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
Same incentive as the main chain -- you get paid.
So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?
Its a simple elegant solution from satoshi.
",
"nested_level": 0
},
{
"id": 3583,
"thread_id": 244,
"source_id": "228",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28713#msg28713",
"date": "2010-12-09T22:43:26Z",
"text": "seems that the miner would have to basically do \"extra work\". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
Same incentive as the main chain -- you get paid.
but if you get paid just as much by mining pure bitcoin without the side hashing...
seems that the miner would have to basically do \"extra work\". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work.
While you are generating bitcoins, why not also get free domain names for the
same work?
If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.
Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.
I agree with satoshi's idea. It seems like the best of both worlds.
",
"nested_level": 0
},
{
"id": 3586,
"thread_id": 244,
"source_id": "231",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28731#msg28731",
"date": "2010-12-10T00:10:07Z",
"text": "If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
I'm still trying to get my head around your idea completely. The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins.
I gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity. The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number.
In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market. As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.
Satoshi's idea eliminates the need for BitX. Alternative chains can be made without splitting CPU power.
Our version of BitDNS would never use its own chain, though, because creating domains should not be tied to a proof-of-work, and we therefore have no generation incentive.
120 bytes with an OP_CHECKSIG is enough for our proposal, I think.
",
"nested_level": 0
},
{
"id": 3588,
"thread_id": 244,
"source_id": "233",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28738#msg28738",
"date": "2010-12-10T01:23:10Z",
"text": "So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?
Its a simple elegant solution from satoshi.
While I like the idea in general, it doesn't really solve the problem in terms of parallel currencies. I don't think the idea of where the CPU power was going to come from for powering this network was ever an issue. People who got into mining would go wherever the money was at and find solutions to \"earn\" whatever coins happen to be around.
I do like the idea of pooling Bitcoin-like block chains in terms of attempting to \"earn\" hashes, and if there were more ways use CPU power to generate hashes it can only be beneficial to everybody involved.
I still would like to use miners for \"authentication\" of the DomainCoin registrations in some way and I'm trying to come up with a good system to get that done. By authentication I'm referring to basic \"rules\" that can verify that a domain hasn't been claimed, and a \"miner\" who doesn't follow those rules as accepted by the rest of the network gets that block rejected. That is happening right now with Bitcion in regards to transactions, but doesn't happen with any other data and won't happen with other data at least as it is presented.
It still gets to the issue I presented earlier on another thread:
I agree with jgarzik, the chain should not be used as storage.
If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain \"dependent\" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.
I think I've asked this question a number of times getting the run around. Perhaps I'll be more clear with this example as proposed by Caveden:
If you create this alternate \"proof of work\" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?
If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.
This is an intractable problem if you want to include the data itself in an authenticated form in a chain block and have that chain block directly connected to Bitcoin without a parallel currency. Theymos simply ignores the issue entirely with his protocol.... which is fine as far as that goes but a miner isn't really being paid to process domain registrations and certainly isn't authenticating bad registrations. The real \"work\" in terms of a DNS system is to authenticate precisely who \"owns\" the domain and make sure that somebody else can't claim that domain. The Theymos/Nanotube protocol forces authentication into a free good, and puts potential attacks on the protocol into the hands of the Bitcoin network... where I don't think it belongs either.
I firmly believe that the data for domains must be in an authenticated system, preferably its own independent chain (perhaps linked to Bitcoin), where all of those serving this data can agree upon the same information and there is no ambiguity about the data. Previous proposals that shove the data into the transactions of Bitcoins fail to get that accomplished.
The incentive is to get the rewards from the extra side chains also for the same work.
You don't really get any extra reward. Either you are collecting generation fees + transaction fees from the Bitcoin side, plus some profits from the Domain Name side. Or, everything is in the Bitcoin block and you earn the same total profits, but all from the Bitcoin side (due to the additional Domain Name transaction fees on the Bitcoin side).
[edit: nevermind this post. I haven't been able to express my idea clearly here.]
Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.
To register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.
So obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.
A domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful.
",
"nested_level": 0
},
{
"id": 3591,
"thread_id": 244,
"source_id": "236",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28846#msg28846",
"date": "2010-12-10T12:29:00Z",
"text": "Introduction of BitX reduces the likelihood that will be invented a way to cut the chain?
Or is it generally no longer considered a necessity?
",
"nested_level": 0
},
{
"id": 3592,
"thread_id": 244,
"source_id": "237",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28857#msg28857",
"date": "2010-12-10T13:39:27Z",
"text": "If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.
In nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market. As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.
The thing is that the miner receiving the transaction fee is just getting that as a sort of free lunch. The fee may be in place to cut out spammers, but they aren't doing any work so far as anything to do with the DNS system. Those computers which are processing and authenticating the raw data are not getting any sort of fee at all and the generators are not being compensated in Bitcions. All that is happening is that the miners are getting paid essentially as a data storage service entirely, and that is of marginal utility in my opinion.
This is also why there are some huge complaints about using the Bitcion blockchain as a generic data storage system... rightfully so I might add.
Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.
Let's assume for a minute we have another block chain which contains just domain data which is cryptographically hashed, but may or may not have proof of work (let's ignore that for now, which I'll address below). The purpose of the block chain is for the authentication of the data primarily where the \"network\" of domain servers can \"certify\" that the data fits the network rules and that domain data within that chain is valid in terms of who \"owns\" what domain. As a public block chain, it also shows what the majority of the \"network\" agrees ought to be in that chain too. Improperly formatted data that is not agreed to by the majority of the network is rejected from this block. Since it is a chain it also verifies against tampering and does a timestamp, and more importantly by being outside of the main Bitcoin chain it reduces the data payload for what is admittedly a specialized service which not all Bitcion users are necessarily interested in. These are the features of the Bitcoin transaction database that are being desired to be applied to other sets of data.
So far that is the easy stuff. We also want to set up some system where the \"registrar\" putting data into this chain is going to be \"paid\" for the registration and authentication of this system. I emphasize this as this is both going to be a reason to be a registrar as to even exist as a registrar has a strong financial stake in maintaining the database to receive more registrations, and provides a reason to have fees to cut down on spamming domain names or abusing the public commons. The fees are being paid to maintain the database, which is the important thing here. Without this fee, at best this database is being authenticated and supplied to the world at large strictly as a public service for free. Some people like that but I hope that those involved with the Bitcoin project can appreciate how being paid for such a service can be very useful and motivating. The Theymos/Nanotube proposal and for that matter all registrations into the Bitcoin database through extra data in a transaction sidestep this issue entirely by ignoring authentication and only using the timestamp ability of Bitcoin, where this database would have to be built anyway but derived from Bitcoin and thus provided as a public service for free.
Here is the real issue, however: Since there is no central server, the registrant wants to make sure their registration is put in by whatever registrar happens to be in line to put in the next record onto the block chain, however that is decided (by proof of work or some other agreed upon system). They want to send out some sort of generic transaction that can be received by the \"authenticator\" of their registration application who puts this registration into that block chain. Only if their registration is accepted into the block chain should that authenticator be paid.
A problem arises here: A bitcoin miner may know that a fee is available from a registrant, but how do you decide where those coins properly belong? Keep in mind that once a fee is processed in Bitcoin, it is irreversible. If there is a chain split on the domain records due to a formatting/authentication dispute (it likely will happen just like it is happening with Bitcoin even now) those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block. Some other registrar may pick up the registration and simply out of the kindness of their heart decide to include it in another block, but they won't be receiving any fee at all for that service. Some system could be perhaps set up where after a block is down to a given depth in the block chain that the fee can be \"released\". Still, regardless of how you set this up there will be some trolls who will be collecting fees, pretending to put stuff into the domain registry but not really caring about the domain registry protocols and siphoning off the fees for themselves, perhaps in collaboration with a Bitcoin miner. Since this represents serious money, there will always be some trolls doing this. Even an \"honest\" registrar is still going to make some mistakes due to a bug or something similar which may on occasion capture fees when they are deserved under this system.
I believe the fee system is critical to the success of this domain registration system. That ensures selfish behavior on the part of the registrars which puts it into their self-interest to maintain the databases, computer equipment, and everything else which makes this work. Yes, there are other ways that a domain name server can earn some coins, and perhaps that ought to be done too, but registration fees are already a part of the marketplace and something which this system is trying to capture as well.
In short, I am trying to demonstrate here that the authentication simply must happen with an entirely different currency, or that authentication of the data (not merely the time stamping) must happen within the Bitcoin client and that data at least in some fashion or another included more directly into the Bitcion block chain with the data authenticated by the miner itself. A Bitcoin miner may choose not to process domain data, but some system must be set up that can certify that a given block
including the domain data meets some sort of authentication standard to be accepted into the block chain to \"earn\" those registration fees. Otherwise the system falls apart and any talk of fees other than as a pure transaction fee to a Bitcoin miner alone is meaningless, with that transaction only to be used to preserve the transaction database.
I am also suggesting that to ensure promptness of registration, that it may also have to be a separate currency simply because not all miners are going to want to bother with domain registration authentication and over time the latency of even getting a domain registration into the system may be intolerably long (on the order of days or weeks) depending on the setup of the Bitcoin network and other priorities of the miners. I'm not suggesting an alternate currency to drive this project out of Bitcoin as useless data, but to point out that it is unworkable even from the perspective of the goals of the peer to peer domain server concept too. Putting the data into transactions isn't authentication and is also losing much of the power of what Bitcoin offers in terms of the authentication too. The proof of work system as used by Bitcion is also the only reasonable way to ensure that the system stays decentralized in terms of deciding who gets to put in the next block. Certainly some sort of common protocol for finding the next proof of work hash can be set up through a common mining pool between multiple currencies like this, but that is a completely separate issue from if it is to be a separate currency or not which I don't think has been decided on this thread.
The only other solution would be for Bitcoin to fully embrace this and other similar concepts that might come along and provide hooks and some sort of standard protocol to authenticate data of this nature on the main Bitcoin network. I think in theory that could be done and may be done in the more distant future in terms of \"unifying\" the proliferation of currencies that may result if it isn't done. I just don't see how that is going to get into the main Bitcoin chain anytime soon and even that has a whole bunch of drawbacks which I haven't fully explored either.
I have not yet read all the posts but I have a few thoughts:
Need to divide the creation of a domain name and change of authoritative servers for him:
First is the expenditure limited domain name space and must be expensive.
Second only settings that can be changed frequently and should be generated in large quantities and cost little.
Names should be allowed to specify the relative and absolute value (with dot at the end). Absolute in case the system will supplement or replace the main in the conventional TLD.
Also names should be allowed to specify 3rd or more level domain names too.
",
"nested_level": 0
},
{
"id": 3594,
"thread_id": 244,
"source_id": "239",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28876#msg28876",
"date": "2010-12-10T14:51:50Z",
"text": "I suggest tahoe lafs if you are looking for a database for storage.
Remember, speed is of the essence. We can alway replace the database with something else, but not time.
All non-essential features should be blocked from implementation focus.
That mean the core developers don't work on a fancy GUI. They will focus on:
1. The mechanism to mine, register, and change a domain name.
2. The mechanism to distribute or output the DNS database.
2. \"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it.
... Keep in mind that once a fee is processed in Bitcoin, it is irreversible. If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block
That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the \"winning\" chain gets the transaction fee.
There is no \"irreversible\" payment to the generator in the \"losing\" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.
\"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it.
No-one has made a proof-of-concept, but we
think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.
I have fleshed out the DomainChain spec quite a bit more:
http://domainchain.org/wiki/doku.php?id=startAlso names should be allowed to specify 3rd or more level domain names too.
Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain
\"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it.
No-one has made a proof-of-concept, but we
think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.
bind9 is not the best format. pdns have a simple interface for plugins, do not worry.
... Keep in mind that once a fee is processed in Bitcoin, it is irreversible. If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block
That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the \"winning\" chain gets the transaction fee.
There is no \"irreversible\" payment to the generator in the \"losing\" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.
I think you got the context mixed up here. The reason why the payment is irreversible is because it is derived from a completely different chain. If there is a chain split in the domain registry chain, the fees spent as bitcoins (going into a completely different system) will have already been spent for those block in the \"losing\" chain. Transaction going into that \"losing block\" are essentially a wasted effort.
I'm suggesting that somebody simply sets up enough of the protocol to be able to appear to be following the domain processing rules so as to appear \"legit\", but they only have to make an appearance to get a block accepted. Perhaps they even get some blocks accepted, but then start to make up stuff or somebody attempts to register an existing name (as a scammer claiming they can hijack a domain from somebody else or however). If there is any reason why the rest of the network doesn't accept the block, for any reason, all of the fees collected by that \"miner\" or \"registrar\" would still be collected by that scammer regardless of if it actually gets into the chain.
On the other hand, if the block being \"authenticated\" is a part of the same chain that creates the currency, this isn't a problem. If the blocks get rejected by the network, any fees (set up in a system like how transaction fees are done with Bitcoin) are also similarly rejected by the network too. Any chain splits remove any fees paid to \"losing\" blocks and therefore can be ignored. This is why the authentication must happen in the same chain as the transaction. Either that is in Bitcoin or a parallel currency, but if it is with Bitcoin, the authentication must happen within the Bitcoin network too. Otherwise, there isn't a way to get payment to the miner with an outside currency that is similar to Bitcoin without fraud and a significant attack on the payment system. This is fraud because a service is being claimed and paid for, but the service isn't being rendered.
Hacking the data into Bitcoin transactions does not perform authentication of the data and pushes that need somewhere else. In effect, it permits \"double spending\" of a domain name or allocation of a domain name to more than one person with ambiguity over who actually owns that domain.
The reason why the payment is irreversible is because it is derived from a completely different chain.
Got you now. Yes, keeping two chains synchronised is fraught with difficulty.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.
If you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other.
",
"nested_level": 0
},
{
"id": 3602,
"thread_id": 244,
"source_id": "247",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28935#msg28935",
"date": "2010-12-10T18:55:35Z",
"text": "Piling every proof-of-work quorum system in the world into one dataset doesn't scale.
If you say \"no\" after you've seen how this runs on the test network, I will totally respect that and won't generate domain registrations on the live network.
Bitcoin is your bird, and if you don't want it to soar as high as it can, that's OK.
But even if the domain name stuff is on a separate chain, there is still going to be a Bitcoin transaction for every DNS registration. So having two chains would cause no reduction in the
number of Bitcoin transactions, just 40 or 50 bytes reduction in the
size of the transactions in the Bitcoin chain.
Fears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.
I dont see how this was a red herring. Unfortuantely if you use a Bitcoin-like system of authentication of a transaction, you can't conduct that transaction in Bitcoins, at least for authentication transaction fees.
If you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other.
I'm really curious about how you make this sort of transaction risk-free without having it integral to Bitcoin as some sort of authentication mechanism.
One thing that really makes this nasty is that the \"miner\" is unknown until the block is added into an authentication hash tree. You don't have the two key release mechanism because one of the parties in the transaction is unknown until after the hash is successfully put in, and even that is conditional.
It makes it much more secure and coincidentally easier to scale to treat it as a simple exchange between two currencies, something that happens entirely outside of the system as evidenced by the various exchanges that already exist between Bitcoin and other currencies. BTW, I agree that Bitcoin or any other monolithic application should not be the ultimate repository of all human knowledge and interaction, as I don't think any sort of system can possibly scale to that size. I'm not even sure TCP/IP itself can scale to that size.
This is much of what Jgarzik has said that it is unworkable, but going from a different perspective. The problem is that everybody is trying to get these fees paid for with bitcoins, and I don't think that can be done at all, at least directly. As an indirect mechanism, perhaps, such as a floating currency that isn't locked down until after the exchange takes place.
BTW, the idea of a \"locking exchange\" would be a fantastic idea for a peer-to-peer currency exchange network, particularly for electronic currencies like Bitcoin or Liberty Reserve. I just don't see how you can put any sort of authentication transaction fee in a block that is denominated by a currency other than the currency represented by that block itself.
Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes? Why not an hour instead? Or every minute? Why be chained to the cycles set for another purpose? It's less than ideal from the beginning.
",
"nested_level": 0
},
{
"id": 3605,
"thread_id": 244,
"source_id": "250",
"poster_name": "Hal",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2436",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28938#msg28938",
"date": "2010-12-10T19:14:04Z",
"text": "Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
",
"nested_level": 0
},
{
"id": 3606,
"thread_id": 244,
"source_id": "251",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28946#msg28946",
"date": "2010-12-10T19:20:44Z",
"text": "Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes? Why not an hour instead? Or every minute? Why be chained to the cycles set for another purpose? It's less than ideal from the beginning.
This is indeed something that can be tweaked, but the issue has to do with network latency, which is independent of the purpose for which the \"currency\" was created. 10 minutes is a guess that has worked out pretty well. Yes, it could be longer or shorter. Shorter intervals increase hash collisions from multiple \"miners\" and a longer intervals decrease those collisions. 10 minutes is also something tolerable on average to somebody used to using computers, certainly if you have experienced sending information and expecting a reply by e-mail. Domain registrations in particular may take a day or so for processing, depending on the registrar and the method of payment, so anything less than a 10 minute interval seems like a waste of effort.
In short, the reasons why 10 minute intervals would apply to Bitcoin apply equally well to any other peer-to-peer cryptocurrency with what other applications are using similar principles.
Satoshi, are you endorsing the idea that additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
It might be coins, but it doesn't have to be. Your reward could be a portion of namespace, ie. the domains themselves.
The possibilities are endless.
Bitcoin rewards you, essentially, with a piece of [digital] property.
It might be coins, but it doesn't have to be. Your reward could be a portion of namespace, ie. the domains themselves.
The possibilities are endless.
Bitcoin rewards you, essentially, with a piece of [digital] property.
If you are a miner and you \"win\" the block, yes, you can throw in any domains to the chain for free I suppose, and the network could accept or reject your block depending on whatever rules that network sets up to regulate that behavior. That is like a Bitcoin miner can throw any transactions they care for as much as they care without having to pay a transaction fee, since they are paying for themselves. Including a transaction fee in the process is just rearranging coins and doesn't change the net amount actually being spent or received.
I think that is of limited utility, unless you are saying that miners can eventually \"earn\" the \"right\" to a top-level domain after a certain number of hashes and inclusions into the domain registry. That would be an artificial form of scarcity that would be interesting to implement, but it still fails to get fees paid by registrants to the registrar. It would just make you \"god-king\" over a particular TLD... if you really \"owned\" that.
Such a non-coin \"reward\" also doesn't provide any incentive to maintain the database, while a coin-based reward would.
bitcoin itself is artificial scarcity.
",
"nested_level": 0
},
{
"id": 3610,
"satoshi_id": 537,
"thread_id": 244,
"source_id": "255",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28959#msg28959",
"date": "2010-12-10T19:55:12Z",
"text": "additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would float.
A longer interval than 10 minutes would be appropriate for BitDNS.
So far in this discussion there's already a lot of housekeeping data required. It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain. Some transactions:
Changing the IP record.
Name change. A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken. This would encourage users to free up names they don't want anymore. Generated domains start out blank and the miner sells it to someone who changes it to what they want.
Renewal. Could be free, or maybe require consuming another domain object to renew. In that case, domain objects (domaincoins?) could represent the right to own a domain for a year. The spent fee goes to the miners in the next block fee.
bitcoin itself is artificial scarcity.
The supply of bitcoin is just an integer determined by network. Otherwise, bitcoin are non-scarce. I can copy a wallet a millllllllllllioooooooooon of time and it will contain the same integer. It's a very weird form of scarcity and non-scarcity.
OK so if there are going to be bitdnscoins (aka DCCs, DomainChain Coins) then they have to be useful for something. Otherwise every BitDNS miner is going to fill every block with his own domain name registrations, rather than replace one with someone else's registration in exchange for a transaction fee in a useless currency.
The rules have to be that you have to spend a certain amount of bitdnscoins/DCCs in order to register your names and/or do other BitDNS transactions. That's the only way to make this alternative currency desirable and valuable.
(Well we could do like Bitcoin and say there would only ever be 22 million DCCs ever created, so they'd get valuable from scarcity just like bitcoins. But that seems weak.)
",
"nested_level": 0
},
{
"id": 3613,
"satoshi_id": 538,
"thread_id": 244,
"source_id": "258",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28963#msg28963",
"date": "2010-12-10T20:19:39Z",
"text": "I agree. All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.
You might consider a certain amount of work to generate a domain, instead of a fixed total circulation. The work per domain could be on a schedule that grows with Moore's Law. That way the number of domains would grow with demand and the number of people using it.
",
"nested_level": 0
},
{
"id": 3614,
"thread_id": 244,
"source_id": "259",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg28973#msg28973",
"date": "2010-12-10T20:41:45Z",
"text": "Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes? Why not an hour instead? Or every minute? Why be chained to the cycles set for another purpose? It's less than ideal from the beginning.
Then be sure to add the ability to specify multiple authoritative servers for one domain. This is possible for DNS as I know (MS Windows AD does it)
So those who do not want what their site to be able to shutdown can make a lot of spare servers and when they turned off by Big Brother name owner just change the settings by removing old servers and adding new ones.
It seems like killing two birds with one stone isn\u0092t enough on the bitcoin forum; one has to kill three.
Firstly, I would like to commend nanotube's+theymos proposal. I like it because it makes economic sense, and it is simple.
The design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the \u0091issues\u0092 said. (I still think there is really nothing wrong about how it is proposed to work as it is. However, if there is a better way of doing it, why not?)
Before we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply. Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.
If a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.
So with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.
The main concern on the forum is the inclusion of \u0091other data\u0092 in the block chain; the problem isn\u0092t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.
In discussions elsewhere, it has been shown that:
1. Generators will happily include any data that is profitable to include.
2. The block size will grow to a size that balances data demands and the profitably of the miners.
3. Clients only need to \u0091keep\u0092 data that they interested in. Data that is irrelevant to the client may be forgotten once processed.
4. Transaction balances may be used to cull the chain of old transactions.
Therefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want). The only outstanding issue is: transfers.
What has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it. Only after processing may a client delete any data that it doesn\u0092t want. This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.
I propose, a design hinted at by Satoshi, to solve this problem: Split bitcoin transactions into multiple groups.
While keeping the important tie between data and bitcoin transactions, (every bit of data still must include it\u0092s compensation to the miners as a bitcoin transaction fee).
Group the transactions by templates. For example: Put the \u0091vanilla template\u0092 bitcoin transactions into the vanilla group, the \u0091bitdns template\u0092 bitcoin transactions into the bitdns group, the \u0091bitpgp template\u0092 bitcoin transactions into the bitpgp group, and so on.
Finally include a \u0091summary\u0092 group that contains only the changes to the transaction balances accumulated in all the other groups.
A Block could contain something like this:
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fbitcointalk.org%2Findex.php%3Faction%3Ddlattach%3Btopic%3D1790.0%3Battach%3D645&t=589&c=rDK5ZycD76KvUA\"/)
Once one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes. This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.
The important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.
Nanotube and Teymos\u0092s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries.
After reading through this whole thread, I've got a couple of comments that I think would be helpful:
1) Everyone in the thread seems intent on replacing the entire DNS infrastructure in one fell swoop, which I think is the wrong approach. The real problem with the DNS system as it exists today is that somebody has to own the root. At the end of the day, you have to trust ICANN. What the DomainChain/BitDNS system should strictly focus on is establishing ownership of domain names. All it needs to track is that the holder of Key A owns domain foo.bar. Once we've established this shared trust, we can support many different DNS infrastructures that can be implemented independently from this project. Whatever new systems are created use DomainChain/BitDNS to establish which key owns the domain, and only allows that individual to insert records for that domain. This works out well, since all participants in the system can validate that the record they've looked up is valid. Right now it is easy to get bogged down in all the details of managing DNS records, when all we need to do is establish a trusted, distributed authority that can form the root of DNSSEC, some new p2p DNS, or whatever.
I'm also thinking this could be used to solve the CA problem with HTTPS, since signing your certificate with the same key would prove that I've reached the correct server. But I digress...
2) Limiting the TLDs should be a requirement. If this system doesn't inter-operate with the existing DNS infrastructure by preventing name collisions, it will undermine the trust you are trying to generate. Even I'm not sure I'm ready to sign up for a distributed DNS system if someone new can pick up
www.mylocalbank.com and cause havok. I'd humbly suggest .web as the TLD to use, but anything will work as long as it is short and not currently in use.
Right now the focus should be on getting this up and running in a way that doesn't conflict with the existing system. If this system becomes dominant at some point and needs to tackle additional TLDs, that is a \"problem\" that can be dealt with then.
3) Personally, I think expiring domain names are the way to go. Even with relatively expensive renewals today, there is still a ton of junk out there. I can't imagine how bad it would be if you owned a domain forever. It isn't asking much to say that you have to renew your domain periodically to keep it, especially since this shouldn't be the ripoff that the existing system is today.
I'd like to close out by saying that this is really exciting stuff. I've read a number of different ideas about how to solve the DNS problem, and this is the first one I've seen that could actually solve it (and not just replace ICANN with pick-your-new-benevolent-dictator).
What is Bitcoin? A decentralized way to keep track of ownership of a fixed quantity of things.
The DNS problem is a specific example of a more general functionality: keeping track of ownership of a fixed quantity of things, where each member of the set is distinguishable.
It turns out that bitcoins are already distinguishable. They are well ordered, mathematically speaking, so a number can be assigned to every bitcoin, for example 0 to 21 million.
So, for a DNS functionality, this is all we need to do:
1. create a second coinbase, possibly forked from the main coinbase (bitcoin)
2. interpret each coin in the second coinbase as a well-defined interval of the sha256 hash space of all DNS names.
Ownership of DNS names is therefore determined by which coins in the second coinbase you own.
Some months ago I was opposed to adding DNS stuff to the existing bitcoin network protocol and client, because I argued bitcoin should stay true to its limited purpose. However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.
In fact, maybe anyone should be able to create a new coinbase on the main network, and specify rules such as quantity and distribution rate. In the case of DNS, everyone will just have to agree that a particular coinbase is to be interpreted as the DNS rights to different parts of the sha256 hash space for the DNS names.
I agree with the idea put forth by da2ce7, which he says is derived from an idea put forth by Satoshi. I think it is compatible with my idea of allowing arbitrary creation of new coinbases on the same network.
I cannot find the nanotube+theymos proposal so i cannot comment on it.
",
"nested_level": 0
},
{
"id": 3618,
"thread_id": 244,
"source_id": "263",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: BitDNS and Generalizing Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=1790.msg29136#msg29136",
"date": "2010-12-11T11:45:24Z",
"text": "I cannot find the nanotube+theymos proposal
It's
here. The simpler DomainChain proposal is
here.
It seems like killing two birds...
This seems like a sound plan. It includes the proposal of theymos and nanotube and includes what satoshi is wanting. I like the fact that there is no free lunch and everyone would have to pay their way.
@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.
However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.
Avoiding CPU power fragmentation is no longer a reason. Independent networks/chains can share CPU power without sharing much else. See:
http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and
http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715Someone is apparently \"testing\" the main bitcoin network by flooding it with 0.01 BTC transactions from A->A and B->B, where A and B are two random public keys. You can watch at
http://theymos.ath.cx:64150/bbe We've hit the free transaction limit on each block, for many blocks now -- appears to be ~219 free transactions per block. \"real\" transactions do not appear DoS'd at this time, presumably due to logic that prioritizes, in part, based on transaction value.
<soapbox>
Free TX's are just asking for permanent level of spam. There should be a cost to each TX, even if it's only 0.001 BTC or so.
</soapbox>
I'm not so ready to blame this on MrBurns.
",
"nested_level": 0
},
{
"id": 3624,
"thread_id": 245,
"source_id": "4",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Transaction / spam flood attack currently under way",
"url": "https://bitcointalk.org/index.php?topic=1850.msg22878#msg22878",
"date": "2010-11-19T19:31:06Z",
"text": "I'm not so ready to blame this on MrBurns.
Oh, right he did it earlier for sure, same address I sent the coins to. I assume he split it up and is now using multiple computers.
Go back about 1 day and you can see a bunch of .06 trades to and from the address MrBurns put in his thread.
The .06 in 17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne which was MrBurns old spam eventually was transferred to 1GcbuFVxrjstRoGzChn5t2xJnm2HKoDBSE 0.05 and
15JzKgaSoW5nX3qJKh6ze1uCojn9WVVnDE 0.01
in transaction c37dd025e8b7329989ab9ac378604d015895e4ec630c863620a90f3a12f73e76
in block 92767 (2010-11-18 22:51:36)
It got 0.05 back from 1GcbuFVxrjstRoGzChn5t2xJnm2HKoDBSE in block 92767
which was transferred to 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp in 92875
There has been a lot of spamming with 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp but also with
1NNVFX7SiJF44fkqB27QbARXojhRSotF2o which was created from 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp
via 1H2aPofjULC65MBeojs3eVpPvdScV8H9ou
in block 92877 (2010-11-19 15:12:33)
So it's the same person.
ByteCoin
",
"nested_level": 0
},
{
"id": 3626,
"thread_id": 245,
"source_id": "6",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Transaction / spam flood attack currently under way",
"url": "https://bitcointalk.org/index.php?topic=1850.msg22888#msg22888",
"date": "2010-11-19T19:56:04Z",
"text": "That's a good point about fee competition, but I'm wondering about near-term implications of this spam flood, too, like
- What happens to the transactions that don't make it into the current block? (somewhat rhetorical question... the answer is \"they keep piling up in memory\" AFAICS, but that raises a bigger question -- how to deal with ever-larger TX cache?)
- Will this create a de facto situation where TX fee is required for \"normal\" bitcoin users?
- Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses.
What happens to the transactions that don't make it into the current block?
The network forgets about them over time. Queued transactions are forgotten when Bitcoin shuts down (or when it crashes because it's using too much memory...). The attacker probably won't rebroadcast their spam transactions, but real users will.
Will this create a de facto situation where TX fee is required for \"normal\" bitcoin users?
Yes. This has always been inevitable.
Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses.
This would be easy to bypass unless you also follow a transaction's history, and if you do that the attacker can \"infect\" people by sending them bitcoins.
...
Oh, I agree. Well, I'm not going to praise him, we were already aware of the possibility. Apparently, \"no incentive\" isn't good enough and we need an actual cost of some sort. Well... actually there is some tiny cost to him, so I guess we need a little bit bigger cost. An increasing marginal cost really would be good.
I mentioned a minimum required [age]*[size] could be required by miners in the other thread. Maybe with a portion (10-20 transactions?) with no requirement.
MrBurns is probably just checking to see what happens before he buys 100,000 coins.
",
"nested_level": 0
},
{
"id": 3630,
"thread_id": 245,
"source_id": "10",
"poster_name": "MoonShadow",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=643",
"subject": "Re: Transaction / spam flood attack currently under way",
"url": "https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896",
"date": "2010-11-19T20:29:12Z",
"text": "Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
",
"nested_level": 0
},
{
"id": 3631,
"thread_id": 245,
"source_id": "11",
"poster_name": "Timo Y",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=271",
"subject": "Re: Transaction / spam flood attack currently under way",
"url": "https://bitcointalk.org/index.php?topic=1850.msg22897#msg22897",
"date": "2010-11-19T20:30:14Z",
"text": "In a free market for transaction fees,
spamming the network will have the effect of increasing transaction fees for everybody.
Maybe Mr Burns is more than just a common griefer. Maybe he is a miner with more rational motivations.
A miner has more to gain than to lose by spamming. Yes, eventually a spam equilibrium will be reached where the marginal amount you lose in your spam to the transaction fees of competing miners equals the marginal amount gained from your own transaction fees. But that is still a macroeconomically subobtimal situation.
To escape this
http://en.wikipedia.org/wiki/Social_trap social trap, more than a market is needed.
Some simple but effective rules should be hardcoded into the Bitcion protocol/specification itself, to discourage the excesses of spamming.
I know that this approach probably sounds too \"top-down\" for the free market enthusiasts in this forum, but the rules should of course be purely voluntary and consensus based, like the 21M rule we have already.
Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
That could make people get tied up in their funds again. Think MtGox or even the bitcoin faucet. Faucet can only send out a nickel every 3 blocks, because each time it sends a nickel, it sends the change to a new address, tying up transaction fee free for 3 blocks.
Only a little. If the rule is generally known, and the reason for it, I think that those like the bitcoin faucet could adjust. I'm talking about limiting based upon the coins movement, if that's possible, not a three block ban upon a particular address. The new client has 100 addresses, correct? If bitcoin faucet has more than BTC .05 in each address, and simply rotates the addresses as the requests come it, then it can service 100 requests in half an hour without delay, and more with delays. I'm not saying that transactions can't be created, just that generators will not put them into blocks until the transaction that they depend upon is three blocks deep without a fee. With a fee, they can do whatever they want; and the generators probably wouldn't honor a 3 block delay upon a fee paying transaction anyway. This leaves the possibility of free transactions an open possibility, while inhibiting spamming. If there is a technical reason that this rule cannot work, I wouldn't know about that.
EDIT: Markets that are trying to service withdraw requests would know how many requests have been sent in the previous 30 minutes, and could choose to warn the requester that such requests may be delayed by this rule, or they can choose to pay a fee out of it.
Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
I'm doing something like that. Priority is a more formalised version of the concept you're describing.
As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?
Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.
Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.
I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.
Version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.
I think this is a good compromise short of making the default fee 0.01. It's not so much to ask that free transactions can only be used to turn coins over so often. If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.
We've always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01.
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 dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.
The interface has a few changes:
getwork [data]
If [data] is not specified, returns formatted hash data to work on:
\"midstate\" : precomputed hash state after hashing the first half of the data
\"data\" : block data
\"hash1\" : formatted hash buffer for second hash
\"target\" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the \"data\" field, but with the nonce changed.
Notes:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of \"ThreadRPCServer method=getwork\" is disabled, it would be too much junk in the log.
",
"nested_level": 0
},
{
"id": 3635,
"thread_id": 246,
"source_id": "2",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg23882#msg23882",
"date": "2010-11-23T20:11:20Z",
"text": "Nice, that will save a lot of patching
That's really nice.
Will it be a drop-in replacement a patched client already used by GPU miners ?
",
"nested_level": 0
},
{
"id": 3637,
"thread_id": 246,
"source_id": "4",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg23890#msg23890",
"date": "2010-11-23T20:43:52Z",
"text": "I understand the use case for external miners, but I rather like the all-in-one approach. Will I still be able to compile in my own mining code? I really enjoyed the revamped interface you introduced some time ago, and would very much like to keep on using it.
",
"nested_level": 0
},
{
"id": 3638,
"satoshi_id": 508,
"thread_id": 246,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891",
"date": "2010-11-23T20:55:27Z",
"text": "It's not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes.
ScanHash_ functions aren't going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).
",
"nested_level": 0
},
{
"id": 3639,
"thread_id": 246,
"source_id": "6",
"poster_name": "davout",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1929",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg23917#msg23917",
"date": "2010-11-23T22:39:07Z",
"text": "Btw satoshi, you should give a shot at git, it's so much better than svn, especially with lots of patches and forks going around =)
",
"nested_level": 0
},
{
"id": 3640,
"thread_id": 246,
"source_id": "7",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg23920#msg23920",
"date": "2010-11-23T22:46:05Z",
"text": "Fantastic stuff, this eliminates one of my patches completely.
I am also tempted to work on an external CPU miner...
",
"nested_level": 0
},
{
"id": 3641,
"thread_id": 246,
"source_id": "8",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008",
"date": "2010-11-24T04:47:42Z",
"text": "Just started working on a simple CPU miner in C, mainly as a demonstration, and to understand 'getwork'.
Repository is at git://github.com/jgarzik/cpuminer.git
Implementation is complete... but it does not work, so don't get too excited. I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way.
",
"nested_level": 0
},
{
"id": 3642,
"thread_id": 246,
"source_id": "9",
"poster_name": "DiabloD3",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1796",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050",
"date": "2010-11-24T11:31:11Z",
"text": "Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification
",
"nested_level": 0
},
{
"id": 3643,
"thread_id": 246,
"source_id": "10",
"poster_name": "m0mchil",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=33",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg24053#msg24053",
"date": "2010-11-24T11:56:34Z",
"text": "No need to do this, I'll change the miner to comply. I am just a little busy right now.
",
"nested_level": 0
},
{
"id": 3644,
"satoshi_id": 509,
"thread_id": 246,
"source_id": "11",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: New getwork",
"url": "https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095",
"date": "2010-11-24T17:21:01Z",
"text": "I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way.
getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.
I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.
target is little endian, it's supposed to be the same as how m0mchil's did it. (if it's not, then it should be fixed) That's the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].
Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification
This is the new spec. It shouldn't be hard to update your miner to use it.
The changes are:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.
Figured out the problem. My sha256 algo was byteswapping the input into big endian, when it was already big endian.
First version of this new CPU miner now described here:
http://bitcointalk.org/index.php?topic=1925.0- It does not return work when you submit a possible hit, only when called without parameter.
It would be immensely useful if you'd return if what I sent to the client actually was an actual hit. It makes it easier to debug issues in miners due to sanity checking.
That's what it does, it returns true/false.
",
"nested_level": 0
},
{
"id": 3648,
"thread_id": 247,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "New demonstration CPU miner available",
"url": "https://bitcointalk.org/index.php?topic=1925.msg24217#msg24217",
"date": "2010-11-25T00:45:23Z",
"text": "A new CPU miner is now available, making use of the new 'getwork' RPC command.
In the beginning, this is intended largely to demonstrate a 'getwork' miner. It is written in straight C, with minimal dependencies (libcurl, jansson).
It has successfully generated blocks on testnet, mainnet and almost all pools.
Linux/BSD release tarball:
http://yyz.us/bitcoin/cpuminer-1.0.2.tar.gzWindows installer:
http://yyz.us/bitcoin/cpuminer-installer-1.0.2.zipgit repository: git://github.com/jgarzik/cpuminer.git
Contributions welcomed! (GPL v2 license)
UPDATE: This has largely been superceded by Con Kolivas's
cgminer fork. See cgminer's
official forum thread for updates and details.
In the beginning, this is intended largely to demonstrate a 'getwork' miner. It is written in straight C, with minimal dependencies (libcurl, libcrypto, jansson).
Cool, I like simplicity of your code. I want to try similar implementation in javascript. Partially because of curiosity and partialy because (inspired by hashcash) it can generate few hashes by fighting comments spam :-).
I just made few tests. In four javascript threads I get ~4khash/s, which is EXTREMELY slow. Probably because javascript is interpreted and without any JIT yet. Would be great if javascript supports GPU. Flash will support GPU soon, so we will see
.
In the beginning, this is intended largely to demonstrate a 'getwork' miner. It is written in straight C, with minimal dependencies (libcurl, libcrypto, jansson).
Cool, I like simplicity of your code. I want to try similar implementation in javascript. Partially because of curiosity and partialy because (inspired by hashcash) it can generate few hashes by fighting comments spam :-).
I just made few tests. In four javascript threads I get ~4khash/s, which is EXTREMELY slow. Probably because javascript is interpreted and without any JIT yet. Would be great if javascript supports GPU. Flash will support GPU soon, so we will see
.
Is your JavaScript code available?
I wish the getwork RPC command could be allowed for non-authenticated users from other hosts. It isn't revealing any secret information, is it?
Nice idea on the independent C miner.
On the JS one: Oh no, soon all kinds of websites will be sneakily generating bitcons on the background while you browse them, hogging your CPU even more
Is your JavaScript code available?
I wish the getwork RPC command could be allowed for non-authenticated users from other hosts. It isn't revealing any secret information, is it?
Will be available if I finish that. It is just for curiosity because it will be slow as hell. Also network overhead will be significant.
I expect simple PHP proxy will do good work for hiding credentials to client. something like yourdomain.com/getwork.php which call rpc to localhost and return json encoded data.
Will be available if I finish that. It is just for curiosity because it will be slow as hell. Also network overhead will be significant.
I believe that IE has cryptographic extensions that you can use from javascript. Maybe that will speed it up?
I believe that IE has cryptographic extensions that you can use from javascript. Maybe that will speed it up?
Do you have any link or reference? I found only 3rd party ActiveX component here
http://www.chilkatsoft.com/js-sha512-hash.asp.
Should I use a particular version of jansson? I installed it from git, and get the following compile error:
util.c: In function \u0091json_rpc_call\u0092:
util.c:133:2: warning: passing argument 2 of \u0091json_loads\u0092 makes integer from pointer without a cast
/usr/local/include/jansson.h:188:9: note: expected \u0091size_t\u0092 but argument is of type \u0091struct json_error_t *\u0092
util.c:133:2: error: too few arguments to function \u0091json_loads\u0092
/usr/local/include/jansson.h:188:9: note: declared here
Nice work.
But :
DBG: found zeroes in hash:
6c1e0d9af9b06eab5aae7fbe058760708c1c7869870142b91b9c0ae300000000
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: false (booooo)
[...]
DBG: found zeroes in hash:
c155613cbd70edad88bf56b06cbd788329a2a741b27ee78f25abdb2e00000000
PROOF OF WORK FOUND? submitting...
PROOF OF WORK RESULT: false (booooo)
I don't know if this is a bug or not.
The miner has been compiled with cygwin, I don't know if it matters.
Not a bug. The miner finds a hash with \"several\" zeroes in it, but then relies on bitcoin to do the full 256-bit hash < target value comparison. It's normal that some hashes will be found by the CPU miner, then rejected by bitcoin. We call those almost-solutions
FWIW, the default bitcoin miner also does this -- it just doesn't print out when it \"finds some zeroes\", only when a real proof of work is found.
Thus, my CPU miner always shows when it stops working on a solution, and starts working on a new solution. Just giving you a bit more information on the whole process.
",
"nested_level": 0
},
{
"id": 3658,
"thread_id": 247,
"source_id": "11",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: New demonstration CPU miner available",
"url": "https://bitcointalk.org/index.php?topic=1925.msg24709#msg24709",
"date": "2010-11-26T21:32:51Z",
"text": "Attached is a Windows executable build with mingw32. I'd be interested to know if it works.
run \"minerd.exe --help\" or \"minerd.exe -h\" to show command line options.
minerd.exe SHA-1 sum: 722fa3b956de3ed3438ed3294fe191f0d55c1514
minerd.exe MD5 sum: 9f75f8da7a5d02da1d45d46d4a032489
",
"nested_level": 0
},
{
"id": 3659,
"thread_id": 247,
"source_id": "12",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: New demonstration CPU miner available",
"url": "https://bitcointalk.org/index.php?topic=1925.msg24712#msg24712",
"date": "2010-11-26T21:45:54Z",
"text": "Should I use a particular version of jansson? I installed it from git, and get the following compile error:
util.c: In function \u0091json_rpc_call\u0092:
util.c:133:2: warning: passing argument 2 of \u0091json_loads\u0092 makes integer from pointer without a cast
/usr/local/include/jansson.h:188:9: note: expected \u0091size_t\u0092 but argument is of type \u0091struct json_error_t *\u0092
util.c:133:2: error: too few arguments to function \u0091json_loads\u0092
/usr/local/include/jansson.h:188:9: note: declared here
It's been tested with jansson 1.2 and 1.3 release versions.
EDIT: If you lack jansson, current cpuminer.git will build an in-tree version. Thus, you may opt to fix the problem by... removing jansson from your system.
You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.
Currently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It's about 100% speedup on AMD CPUs.
",
"nested_level": 0
},
{
"id": 3661,
"thread_id": 248,
"source_id": "1",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg24277#msg24277",
"date": "2010-11-25T07:07:51Z",
"text": "
It appears that blk0001.dat, where bitcoin stores block chain information, is compatible across Windows, Linux, 32-bit and 64-bit.
Therefore, why not save new users some time by shipping blocks 1-74000 with each release?
Presumably, indexing and verifying a local file would be faster, and use fewer network resources, than downloading all those blocks via P2P.
",
"nested_level": 0
},
{
"id": 3662,
"thread_id": 248,
"source_id": "2",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg24352#msg24352",
"date": "2010-11-25T13:37:13Z",
"text": "Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?
(also the reason why some gaming companies use bittorrent to distribute updates)
",
"nested_level": 0
},
{
"id": 3663,
"thread_id": 248,
"source_id": "3",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg24369#msg24369",
"date": "2010-11-25T14:25:37Z",
"text": "I have mixed feelings about this. Part of the problem is that there is perceived to be a free good, a network hosting service in the form of Source Forge, which will certainly allow those performing software releases to include considerably more data than is currently the case for Bitcoins. If somehow we were paying for this service as a community in terms of $$$ per MiB, I think it would be a no brainer that this should stay out of the distribution. Unfortunately for this consideration, it is a free good from the perspective of most users.
The other issue is that the network bandwidth between nodes is also a free good. I've suggested in
this thread that perhaps the presumption of network bandwidth may also not be considered a free good either. In fact, I believe that it shouldn't be the case, but that is a completely separate issue entirely.
The network bandwidth for downloading the blocks is to me a wash either way, although a new client coming \"on-line\" trying to get the full block chain does suck up a whole bunch of blocks through the Bitcoin network and that impacts anybody who happens to be connected to those nodes. BTW, this is one of the reasons I think it would be incredibly useful to start \"charging\" for bandwidth as a means to discourage this behavior... and of course to earn a few extra Bitcoins on the side. If you can obtain blocks \"free\" from another source, some people might get more creative on how to get that accomplished including downloading a second package on some free file hosting service (perhaps included with the main client distributions) or coming up with a scheme on how to bootstrap new clients that impacts the network in a less obtrusive fashion.
I guess what I'm saying is that while this is a simple solution to a complex problem, it doesn't solve all of the problems including perhaps clients which may store the block data in another format. There also isn't any apparent reason to necessarily encourage other software client distros to include this kind of data or for that matter to put in more than the most minimum number of blocks. Still, raising the issue is useful here and I hope it raises a discussion about the problem.
Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?
(also the reason why some gaming companies use bittorrent to distribute updates)
I agree it seems very odd that you would take something which is by its nature distributed through P2P channels and instead put it into a conventional client-server distribution model. Part of why I'm saying that perhaps more thought ought to go into this is perhaps to encourage a bittorrent distribution connection of some sort for a large collection of blocks if somebody has had their client off for awhile or some other kind of experimentation on how to solve this same problem. The problem is that new clients are demanding the whole block chain and really can't get into \"mining\" or confirming new transactions until they have that chain. Let's solve that problem, which is a larger issue.
The other issue is that it seems like a waste of bandwidth to include these blocks in a client when all you are doing is updating the software. I would be just as worried that the block chain might get wiped out by the installation software with this \"older\" version of the chain, forcing older clients to update to the current block all over again, although this is certainly an installation bug. Just because it is a free good doesn't imply there are no other consequences to going this route.
Indeed, shipping the data with the client is just a kludge.
If the main reason that the bitcoin P2P protocol is so inefficient in transferring large amounts of blocks, that should be fixed. I think that's because of the HDD syncing going on. Maybe this should be held off for the initial download, or the protocol should be made more bittorrent-like for the blocks [0..last-10000], as they are basically set in stone.
",
"nested_level": 0
},
{
"id": 3665,
"satoshi_id": 511,
"thread_id": 248,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438",
"date": "2010-11-25T17:51:39Z",
"text": "It's not the downloading that takes the time, it's verifying and indexing it.
Bandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.
During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.
Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
",
"nested_level": 0
},
{
"id": 3666,
"thread_id": 248,
"source_id": "6",
"poster_name": "MrFlibble",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2332",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg24499#msg24499",
"date": "2010-11-25T23:19:55Z",
"text": "My first reaction was \"+1 for fast setup\", but most of the 24hr delay I suffered was local disc. Disabling fsync (?) on the database while in catch-up mode would help the most.
Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?
(also the reason why some gaming companies use bittorrent to distribute updates)
Good point. But since the sha-256 of the block is wired into the code, it is perfectly reasonable to ship the data too. When the blockchain is over 500meg, I think transfer efficiency will become important.
We have options,
- ship blockchain from SF until it's not politely within their AUP, then re-evaluate. I couldn't find a file size limit, even for the project website service (only a quick surf of their docs).
- ship 'small' binaries from SF, and 'large' releases with data via BitTorrent
- ship 'small' release, including the .torrent for the blockchain and a fetcher script. This looks for one of three popular command line BitTorrent clients for the platform and uses that to fetch the chain, or whinge if it can't.
http://sourceforge.net/apps/trac/sourceforge/wiki/Developer%20web says
Note: All file releases should be a single file. Multiple files for the same release should be archived together (tar, deb, zip, etc.). We recommend using rsync for all uploads over 20 megabytes in size, as rsync allows for resuming canceled or interrupted transfers.
Hmm, shipping the blockchain for each binary arch would be perverse.
Then, who provides the tracker & seed for the data? Someone with incentive or community spirit? Well, this forum+wiki seem to live on
http://www.slicehost.com/ => min $20/month. It could probably share without hurting the website, and (I think) the seed could be severely throttled to make other BT seeds pull more weight.
It's not the downloading that takes the time, it's verifying and indexing it.
This is not true of many novice users, who say things like \"well it took several hours to catch all the 90 000 blocks but finally it arrived\" (quoted from one new user, on IRC, today).
Bandwidthwise, it's more efficient than if you downloaded an archive.
Agreed. Compressed in an archive, blk0001.dat is around 36MB.
Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.
During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.
It remains the download, not the verification, that has the highest
variability of experience, where first time users see a delay of 30 minutes to
several hours before the software is actually usable. Some P2P nodes may be extremely slow (I see high variability in latency and throughput for old blocks, and blocks larger than 512 bytes). End user bandwidth may be low, spotty or expensive. Firewalls are often a problem.
I'm betting that the above complaint from a new user was due to a Microsoft firewall; but the point stands: large variance of network configuration and capability implies the P2P download impact
may be far, far greater than impact of on-disk verification of 90,000 blocks.
Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
Who said untrusted? The proposal is that you distribute blk0001.dat (and only blk0001.dat) in the bitcoin.org official client downloads. And of course the client will spend some time verifying blk0001.dat upon first use. This is unavoidable, and nobody has proposed changing or eliminating verification.
Just shipping blk0001.dat with official bitcoin would eliminate several headaches that new bitcoin users continue to experience.
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the
ACID properties do you need, while downloading?
Adding BDB records is simply appending to a log file, until you
issue a checkpoint. The checkpoint then updates the main database file.
Under a normal BDB transaction, you are guaranteed that each log record will be sync'd to disk platter, before the transaction commit succeeds. This is very strict, but required for full ACID. Enabling
DB_TXN_NOSYNC still gives you a lot:
\"database integrity will be maintained, but if the application or system fails, it is possible
some number of the most recently committed transactions may be undone during recovery\"
bitcoin can obviously recover if recent transactions are undone, so, it seems useful for this flag to be set for 100% of the initial block download.
That leaves checkpointing, which is a balance between amount of work performed at checkpoint time -- number of records that must be copied from log to database file -- and wall clock time. Just gotta try some values and see what \"feels\" right -- maybe checkpoint every 10,000 blocks?
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 slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.
Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work.
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the
ACID properties do you need, while downloading?
It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.
We checkpoint every 500 blocks.
Who said untrusted? The proposal is that you distribute blk0001.dat (and only blk0001.dat) in the bitcoin.org official client downloads. And of course the client will spend some time verifying blk0001.dat upon first use. This is unavoidable, and nobody has proposed changing or eliminating verification.
Just shipping blk0001.dat with official bitcoin would eliminate several headaches that new bitcoin users continue to experience.
My personal suggestion is to have the block data as a separate download, but strongly recommended. If you want to simplify the installation for Windows users and otherwise clueless computer users that can't take a block file of this nature and put it into the correct directory, perhaps setting up a formal installation file to put it where it needs to go would be more \"user friendly\", but all it really has to contain is just the block data.
The purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time.
The purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time.
I'm not sure how it is for you, but when I upgrade Bitcoin I don't have to re-download any blocks. It just picks up right where it left off before the upgrade.
The purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time.
I'm not sure how it is for you, but when I upgrade Bitcoin I don't have to re-download any blocks. It just picks up right where it left off before the upgrade.
That is the point. If the blocks are included in the update it would also by definition include blocks you already have obtained via the network. This is why I'm suggesting that it ought to be a separate but strongly recommended download for new users instead of something combined in the normal distros.
Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
Other commenters in this thread are correct that upgrading users don't need a block database... but something needs to be done to improve the initial block download experience for new users. Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.
We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
",
"nested_level": 0
},
{
"id": 3674,
"thread_id": 248,
"source_id": "14",
"poster_name": "tyler",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2145",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg25054#msg25054",
"date": "2010-11-28T07:23:04Z",
"text": "Other commenters in this thread are correct that upgrading users don't need a block database... but something needs to be done to improve the initial block download experience for new users. Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.
*something* needs to be done, the block chain will be *huge* in the next year or so, correct?
Other commenters in this thread are correct that upgrading users don't need a block database... but something needs to be done to improve the initial block download experience for new users. Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.
*something* needs to be done, the block chain will be *huge* in the next year or so, correct?
Yes, correct.
Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...
This is why I'm suggesting that it ought to be a separate but strongly recommended download for new users instead of something combined in the normal distros.
Sorry, I misunderstood you.
We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
I suppose you are referring to the checkpoints? If so, as I understand it, they are only applied while verifying a block which has been downloaded. The contents of blk0001.dat and blkindex.dat are
never checked by the client, because the client is designed to check that data
before it gets written to those files. As satoshi indicated in this thread,
Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
I suppose you are referring to the checkpoints? If so, as I understand it, they are only applied while verifying a block which has been downloaded. The contents of blk0001.dat and blkindex.dat are never checked by the client, because the client is designed to check that data before it gets written to those files.
Not quite true. \"-checkblocks\" (CheckBlock()) performs quite a few checks on the contents of blk0001.dat / blkindex.dat. AcceptBlock() does a bit more, adding context, but not much more. But let's ignore that for the moment.
I think a more important point you're missing is that
nobody is proposing that verification be skipped. The bitcoin code is quite capable of verifying and indexing untrusted blk0001.dat data. It would just need a few modifications to behave sensibly if blkindex.dat is missing.
The proposal is simply: don't download massive amounts of uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.
As satoshi indicated in this thread,
Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.
The client is clearly capable of verifying the cryptographic integrity of blk0001.dat from an untrusted source, because it does that for blocks coming in over the network, and blk0001.dat contains... serialized blocks originally received from untrusted sources over the network.
It does not seem overly difficult to pass in blk0001.dat file position data to ProcessBlock(), and simply skip the WriteToDisk() storage call in downstream callee AcceptBlock().
The client is clearly capable of verifying the cryptographic integrity of blk0001.dat from an untrusted source, because it does that for blocks coming in over the network, and blk0001.dat contains... serialized blocks originally received from untrusted sources over the network.
It does not seem overly difficult to pass in blk0001.dat file position data to ProcessBlock(), and simply skip the WriteToDisk() storage call in downstream callee AcceptBlock()
Unless I'm mistaken here, what this implies is that at the moment the \"official\" client presumes that blk0001.dat contains validated data, so if you download that data from another source which may have been compromised, at the moment there is no way to verify this information. This is but a temporary danger to be aware of while the software attempts to cope with this particular issue.
On the other hand, somebody could also put into the UI or as a command-line switch on bitcoind some sort of \"reverifications\" of the block data which would be performed locally. I think there are other applications for this including perhaps as a precaution against some virus on your computer manipulating data in the block chain where this would be useful anyway, but it seems like an option which ought to be added to the software. Since the verification code is already in the software, it is merely setting up the algorithm and triggering mechanism to perform that verification. Indeed if there is a particular block which is of concern during the verification process, an effort to \"heal\" the chain based upon block requests to peer nodes could be used to fix potential errors or even discard the whole chain.
I hope such a feature eventually is added.
My understanding was that the client already did a blockchain recheck upon startup if the index was missing. I did this when I first started, and it sure seemed like it was marching through the chain. Doesn't it require an index to function anyway? Why would it assume that the blockchain was valid upon startup? Anyone could have edited it. The genesis block is encoded into the client, isn't it? That and the blockchain checkpoints are the only parts that are assumed correct, or am I wrong? There is no good reason to prevent a blockchain download via other methods. In a future with the bitcoin network running close to it's capacity, downloading the entire blockchain over the P2P network will be harmful.
Even a chain that has already been pruned of it's merkle trees should be able to be verified from the start, otherwise what good is using a merkle tree at all?
",
"nested_level": 0
},
{
"id": 3680,
"satoshi_id": 518,
"thread_id": 248,
"source_id": "20",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
"date": "2010-11-28T17:13:01Z",
"text": "Despite everything else said, the current next step is:
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
In particular, I suspect that more read caching might help a lot.
Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?
We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.
If there was a \"verify it\" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.
Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...
80 bytes per header and no indexing work. Might take 1 minute.
uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.
The data is mostly hashes and keys and signatures that are uncompressible.
The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.
If there was a \"verify it\" step, that would take as long as the current initial download, in which it is the indexing, not the data download, that is the bottleneck.
[...]
The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.
Sorry, these users' disk and CPU were
not at 100%. It is clear the bottleneck is
not the database or indexing, for many users.
The data is mostly hashes and keys and signatures that are uncompressible.
bzip2 gives you 33% compression ratio, saving many megabytes off a download:
[jgarzik@bd data]$ tar cvf /tmp/1.tar blk0001.dat
blk0001.dat
[jgarzik@bd data]$ tar cvf /tmp/2.tar blk*.dat
blk0001.dat
blkindex.dat
[jgarzik@bd data]$ bzip2 -9v /tmp/[12].tar
/tmp/1.tar: 1.523:1, 5.253 bits/byte, 34.34% saved, 55439360 in, 36402074 out.
/tmp/2.tar: 1.512:1, 5.291 bits/byte, 33.86% saved, 103690240 in, 68577642 out.
I wouldn't call 33% \"uncompressible\"
Sorry, these users' disk and CPU were not at 100%. It is clear the bottleneck is not the database or indexing, for many users.
It seemed to me that it was some sort of disk problem or network condition on his end. Some selected quotes from my IRC log:
<manveru> also, when i woke up, there were thousands of entries in the debug.log that look like: trying connection lastseen=-135.6hrs lasttry=-358582.4hrs
<theymos> How many connections do you have?
<manveru> 2 right now
<theymos> How many blocks do you have?
<manveru> blockcount and blocknumber are 29124
<theymos> How fast is that increasing?
<manveru> around 1 every 4 seconds
<jgarzik> manveru: 32-bit or 64-bit linux?
<manveru> 64
<manveru> now 'blkindex.dat flush' takes a few minutes :|
<manveru> still hangs on flush
<theymos> manveru: Are you on some network file system?
<manveru> no, just a normal harddisk
<manveru> it's only 5200 rpm though
Also, replacing the blocks might have prevented him from noticing a transaction:
<manveru> jgarzik: sent me the blocks, but it didn't change my balance
<MT`AwAy> manveru: in your getinfo you're at block 94236 ?
<manveru> yeah
Building blkindex.dat is what causes all the disk activity.
[...]
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
The following code in AddToBlockIndex(main.cpp) is horribly inefficient, and dramatically slows initial block download:
CTxDB txdb;
txdb.WriteBlockIndex(CDiskBlockIndex(pindexNew));
// New best
if (pindexNew->bnChainWork > bnBestChainWork)
if (!SetBestChain(txdb, pindexNew))
return false;
txdb.Close();
This makes it impossible to use a standard technique for loading large amounts of records into a database (db4 or SQL or otherwise): wrap multiple record insertions into a single database transaction. Ideally, bitcoin would only issue a TxnCommit() for each 1000 blocks or so, during initial block download. If a crash occurs, the database remains in a consistent state.
Furthermore,
database open + close for each new block is incredibly expensive. For each database-open and database-close operation, db4
- diagnose health of database, to determine if recovery is needed. this test may require data copying.
- re-init memory pools
- read database file metadata
- acquire file locks
- read and initialize b-tree or hash-specific metadata. build hash table / b-tree roots.
- forces a sync, even if transactions called with DB_TXN_NOSYNC
- fsync memory pool
And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.
That's right, that long list of operations is executed per-database (DB), not per-environment (DB_ENV), for a database close+open cycle. To bitcoin, that means we do this for
every new block. Incredibly inefficient, and not how db4 was designed to be used.
Recommendations:
1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown. db4 is designed to handle crashes, if proper transactional use is maintained -- and bitcoin already uses db4 transactions properly.
2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.
EDIT: Updated a couple minor details, and corrected some typos.
It seems like you're inclined to assume everything is wrong more than is actually so.
Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use.
1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.
Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.
And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.
If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks:
if (strFile == \"blkindex.dat\" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);
Probably should add this:
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);
2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.
Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves.
In the following cases, would case 1 flush once and case 2 flush twice?
case 1:
write
write
write
write
checkpoint
case 2:
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint
Contorting our database usage will not be the right approach. It's going to be BDB settings and caching.
Yeah, I missed the database-open caching buried in all the C++ constructors. Major red herring, sorry about that.
db4 cache control is
http://download.oracle.com/docs/cd/E17076_01/html/api_reference/CXX/dbset_cachesize.htmlI instrumented my import using the
-initblock=FILE patch posted last night, putting printf tracepoints in TxnBegin, TxnCommit, TxnAbort, Read and Write:
ProcessBlock: ACCEPTED
CDB::Write()
DB4: txn_begin
CDB::Write()
CDB::Write()
CDB::Write()
DB4: txn_commit
SetBestChain: new best=000000005b5c1859db19 height=1751 work=7524897523416
ProcessBlock: ACCEPTED
CDB::Write()
DB4: txn_begin
CDB::Write()
CDB::Write()
CDB::Write()
DB4: txn_commit
SetBestChain: new best=00000000f396ab6b62ba height=1752 work=7529192556249
ProcessBlock: ACCEPTED
CDB::Write()
DB4: txn_begin
CDB::Write()
CDB::Write()
CDB::Write()
DB4: txn_commit
SetBestChain: new best=000000000c6bcf972117 height=1753 work=7533487589082
So, it appears that we have a CDB::Write() that occurs outside of a transaction (vTxn is empty??).
txnid==NULL is perfectly legal for db4, but it does mean that callpath may be operating outside of the DB_TXN_NOSYNC flag that is set in ::TxnBegin(). Thus, a CDB::Write() outside of a transaction
may have synchronous behavior (DB_TXN_SYNC) as governed by DB_AUTO_COMMIT database flag.
EDIT: Wrapping WriteBlockIndex() inside a transaction does seem to speed up local disk import (-initblocks).
--- a/main.cpp
+++ b/main.cpp
@@ -1427,7 +1427,10 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned
pindexNew->bnChainWork = (pindexNew->pprev ? pindexNew->pprev->bnChainWork
CTxDB txdb;
+ txdb.TxnBegin();
txdb.WriteBlockIndex(CDiskBlockIndex(pindexNew));
+ if (!txdb.TxnCommit())
+ return false;
Of course that implies begin+commit+begin+commit in quick succession (SetBestChain), so maybe a less naive approach might be preferred (nested transactions, or wrap both db4 writes in the same transaction).
I timed two runs with clean data directories (no contents), -noirc, -addnode=10.10.10.1, Linux 64-bit. Hardware: SATA SSD
Mainline, no patches:
32 minutes to download 94660 blocks.
Mainline + TxnBegin/TxnCommit in AddToBlockIndex():
25 minutes to download 94660 blocks.
",
"nested_level": 0
},
{
"id": 3688,
"satoshi_id": 522,
"thread_id": 248,
"source_id": "28",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: RFC: ship block chain 1-74000 with release tarballs?",
"url": "https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016",
"date": "2010-12-01T21:25:39Z",
"text": "That's a good optimisation. I'll add that next time I update SVN.
More generally, we could also consider this:
dbenv.set_lk_max_objects(10000);
dbenv.set_errfile(fopen(strErrorFile.c_str(), \"a\")); /// debug
dbenv.set_flags(DB_AUTO_COMMIT, 1);
+ dbenv.set_flags(DB_TXN_NOSYNC, 1);
ret = dbenv.open(strDataDir.c_str(),
DB_CREATE |
DB_INIT_LOCK |
DB_INIT_LOG |
We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.
",
"nested_level": 0
},
{
"id": 3689,
"satoshi_id": 512,
"thread_id": 249,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Version 0.3.17",
"url": "https://bitcointalk.org/index.php?topic=1946.msg24460#msg24460",
"date": "2010-11-25T20:07:36Z",
"text": "Version 0.3.17 is now available.
Changes:
- new getwork, thanks m0mchil
- added transaction fee setting in UI options menu
- free transaction limits
- sendtoaddress returns transaction id instead of \"sent\"
- getaccountaddress <account>
The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.
The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.
Downloads:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/where are the windows binaries ?
",
"nested_level": 0
},
{
"id": 3691,
"thread_id": 249,
"source_id": "3",
"poster_name": "BioMike",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=464",
"subject": "Re: Version 0.3.17",
"url": "https://bitcointalk.org/index.php?topic=1946.msg24474#msg24474",
"date": "2010-11-25T20:49:55Z",
"text": "Why no 0.3.16?
",
"nested_level": 0
},
{
"id": 3692,
"thread_id": 249,
"source_id": "4",
"poster_name": "nanotube",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1268",
"subject": "Re: Version 0.3.17",
"url": "https://bitcointalk.org/index.php?topic=1946.msg24494#msg24494",
"date": "2010-11-25T23:03:02Z",
"text": "and what exactly does \"free transaction limits\" mean? what is the new transaction fee schedule?
",
"nested_level": 0
},
{
"id": 3693,
"thread_id": 249,
"source_id": "5",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: Version 0.3.17",
"url": "https://bitcointalk.org/index.php?topic=1946.msg24501#msg24501",
"date": "2010-11-25T23:49:50Z",
"text": "and what exactly does \"free transaction limits\" mean? what is the new transaction fee schedule?
Is transaction fee used for confirmation priorities? If yes, it would be cool to allow changes of fees directly on 'send coins' dialog. For some donations of few bitcoins I don't care about time, but if I want to send coins to somebody who is waiting to confirmation, it can help...
Is transaction fee used for confirmation priorities? If yes, it would be cool to allow changes of fees directly on 'send coins' dialog. For some donations of few bitcoins I don't care about time, but if I want to send coins to somebody who is waiting to confirmation, it can help...
that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)
that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)
Yes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution.
that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)
Yes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution.
yea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both.
that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)
Yes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution.
yea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both.
Are you planning on changing the fee for every transaction?
Are you planning on changing the fee for every transaction?
yes, when it gets to the point that fees really make a difference in speed of getting into the chain... i might send a larger fee for transactions i want to be fast, and smaller or none where i don't care about speed (e.g., donations).
yea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both.
I think it's worth keeping the default interface as simple as possible for new users. If people want to set a price in the \"send coins\" dialog, this field should be enabled by a configuration option, not presented to new users.
Who's in charge of the OSX build? Given it usually lags behind I assume it is done by someone not using OSX as the primary OS. I can help with this if that's the case, just point me to how things are done right now.
",
"nested_level": 0
},
{
"id": 3701,
"satoshi_id": 514,
"thread_id": 249,
"source_id": "13",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.17",
"url": "https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673",
"date": "2010-11-26T18:23:30Z",
"text": "Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major. I'll ask him to do this version.
",
"nested_level": 0
},
{
"id": 3702,
"thread_id": 250,
"source_id": "1",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "[2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24844#msg24844",
"date": "2010-11-27T13:45:41Z",
"text": "![\"\"](\"https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2Fp5YHR9i.png&t=589&c=8QSkN2UoQG--zw\"/)
News | Pool Statistics | Block History | Help Center | Demo AccountWe are the world's first cryptocurrency mining pool founded in 2010.
Since then we have together mined over 1 million BTC.Reasons to mine on Slush Pool- low flat fee of 2 % (network fees are shared with miners!)
- stable income thanks to our significant network share (~ 15 blocks a day)
- neat interface with dashboard and worker monitoring
- advanced security with 2FA and payout address locking
- servers in Europe, North America and Asia
- free withdrawals above 0.01 BTC
Start mining on Slush PoolSupport- Create a ticket in our support system, if you have any issues or questions.
- We will get back to you as soon as possible, usually within 24 hours.
- We cannot guarantee answering questions posted elsewhere. Thank you for understanding.
Follow us: Twitter | Facebook | Blog
Original post:Once people started to use GPU enabled computers for mining, mining became very hard for other people. I'm on bitcoin for few weeks and didn't find block yet (I'm mining on three CPUs). When many people have slow CPUs and they mining separately, each of them compete among themselves AND against rich GPU bastards ;-), because everybody counts sha256 hashes from the same range. Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!. But new feature of the official bitcoin client called 'getwork' now enables work of many computers together, so they don't compete. Because there is now standalone CPU miner (thanks to jgarzik!) and 'getwork' patch is in official client now, I have an idea:
Join poor CPU miners to one cluster and increase their chance to find a block!How that should work? There will be web page where you can register, enter your wallet address and get URL and your personal rpcuser/rpcpassword for your CPU/GPU miners. When you start own miner with these credentials, server will send you work which was not calculated yet by other members of cluster.
But when your client find winning hash, you do not get full reward for block (50BTC right now), but only proportional part, which you calculate. When you offer 1000khash/s for one day and whole cluster performance will be 20000khash/s and it takes two days to find a block, your reward will be (50/20/2=)1.25BTC.
Advantages? When you have poor standalone computer, you need to wait many weeks or even months for finding full 50BTC reward. When you join cluster like this, you will constantly receive small amount of bitcoins every day or week (depends on full cluster performance).
Disadvantages? You need to trust in central authority (me) that I don't steal block for myself. But I'm goofing around for few week and I'm amazed with bitcoin idea, so I don't plan to steal anybody right now :-).
Another possible problem is that somebody will ask for new work very often, but in fact he will not count real hashes. In this case it will look like he has very strong CPU and he should get big part of reward if cluster find a block. But there is a simple defense against cheaters: Central server sometimes send work which leads to 'winning' hash. Worker which don't return this hash as matching will be permanently banned (login/password and IP address). This was succesfully solved by letting miners calculate proof-of-work. It is not anymore possible to be a part of cluster and not count hashes.
Are you interested in?
Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!
Actually, they
are equal. The low-power machines aren't \"racing\" against the high power machines. For any given difficulty level, it doesn't even matter how many other machines are generating. If all the other machines dropped off the network, it wouldn't increase the number of blocks you generate (until the next difficulty level adjustment).
The only thing that counts significantly is the difficulty level and your khash/s. There are some relatively minor effects due to network latency, but they're not a big deal.
I will offer a Six-Way AMD Processor to the Cooperative Mining Group. I tried generating for weeks on it to no avail. I have given up in the mean time and have instead purchased coins for use. I would love to turn the value of my tiny 9,000/k/hash/s into something productive. If nothing else as part of an experiment to make your software more secure. There is another thread already on the forum for the source code to Cooperative Mining but I am not sure that it was complete or successful. There appeared several people participating but no additional work from them. Perhaps it was so successful that they no longer wish to have additional participants into their group- I am unsure. My rate contribution may not win me blocks by myself but as a larger group hopefully I could be helpful. Please let me know if you move forward with this.
",
"nested_level": 0
},
{
"id": 3705,
"thread_id": 250,
"source_id": "4",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24863#msg24863",
"date": "2010-11-27T14:48:49Z",
"text": "i always liked the idea of distributed mining,
with CPUs its actually the only chance you got to get some coins on a regular basis now and even using a GPU it already takes days to generate a block on your own, rising for sure.
call me in at least for beta-testing, there's always some cores around to share.
",
"nested_level": 0
},
{
"id": 3706,
"thread_id": 250,
"source_id": "5",
"poster_name": "bober182",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1998",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24875#msg24875",
"date": "2010-11-27T16:12:24Z",
"text": "Sure seems fair its better then waiting 1 year for 50 bitcoin. Now I wait 1/50 of a year for 1 bitcoin yay!
",
"nested_level": 0
},
{
"id": 3707,
"thread_id": 250,
"source_id": "6",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24878#msg24878",
"date": "2010-11-27T16:20:26Z",
"text": "For any given difficulty level, it doesn't even matter how many other machines are generating.
You are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.
I think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs.
The only thing that counts significantly is the difficulty level and your khash/s.
Of course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members.
For any given difficulty level, it doesn't even matter how many other machines are generating.
You are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.
I think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs.
The only thing that counts significantly is the difficulty level and your khash/s.
Of course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members.
I like the idea, but your rhetoric is awful.
Lucky guys with GPUs? Do you think those are distributed via lottery or something?
Isn't cooperative mining a form of communism ?
Personnaly I gave this a thought and I think it's useless and much harder to do than one might think.
First I thought it was a problem if only a few nodes were capable of mining. Now I don't care anymore. Even if only one was mining all new bitcoins, I wouldn't care much. This node would do all the work recquired, and in the best way. Plus, anyone can take its place if it can hash more.
",
"nested_level": 0
},
{
"id": 3710,
"thread_id": 250,
"source_id": "9",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24885#msg24885",
"date": "2010-11-27T17:04:51Z",
"text": "Lucky guys with GPUs? Do you think those are distributed via lottery or something?
It is just my feeling of inferiority that I have few Mhash/s :-D
Don't take it personally, I'm OK with GPU miners. But I'd like to give real chance to get few btc for many users with poor computers. That's all.
Isn't cooperative mining a form of communism ?
Do you really think cooperation is communism? There is nothing as 'free bitcoins for everybody' in cooperative mining.
Isn't cooperative mining a form of communism ?
Personnaly I gave this a thought and I think it's useless and much harder to do than one might think.
First I thought it was a problem if only a few nodes were capable of mining. Now I don't care anymore. Even if only one was mining all new bitcoins, I wouldn't care much. This node would do all the work recquired, and in the best way. Plus, anyone can take its place if it can hash more.
There is nothing wrong with voluntary communism. Not sure if you were implying that there is or not. I think someone has worked out the details of making it work, but I'm not sure.
useless and much harder to do than one might think
i agree on the harder part, there'd be some problems to solve and hurdles to take,
but i don't think it's useless.
any bit of computing-power, be it from CPUs or GPUs, makes our network stronger.
it'll help even those that aren't generating at all, by protecting their coins.
people are willing todo lots of stuff, if you give them at least something in return.
currently you practically don't get anything for adding your cpu/s to the cloud, you probably have to pay for it, so why do it anyway?
most people won't, maybe they will if you give them just a few coins, or bitcents for what they do.
of course bitcoin in general is not about generating at all, but it's a nice way to attract it to a lot more people.
This is fundamentally flawed. I can join the \"effort\" and figure out how long it generally takes to perform one unit of work. After that time I send a message \"ah, too bad I didn't find anything\". Then someone does find an answer and I collect.
Now, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.
The distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins.
",
"nested_level": 0
},
{
"id": 3715,
"thread_id": 250,
"source_id": "14",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24896#msg24896",
"date": "2010-11-27T18:03:00Z",
"text": "This is fundamentally flawed. I can join the \"effort\" and figure out how long it generally takes to perform one unit of work. After that time I send a message \"ah, too bad I didn't find anything\". Then someone does find an answer and I collect.
Do you mean somebody can cheat by simply asking for work, but not counting hashes? I talked about it already - I will send task which leads to 'winning' hash and when worker does not return it, I will ban them.
Now, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.
Also this kind of cheat will be detected by technique described above. You will succeed at most once before you will be banned by central server.
The distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins.
Partially agree. But until one mined block will be for more than 1 BTC, cooperative mining should be still better for slow computers, because possible reward in coop can be also in BTC cents or less.
puddinpop has released a Pooled/Remote Mining - client:
https://www.bitcoin.org/smf/index.php?topic=1458.0;allIs this client gpu-ready?
Your answer
is here in the thread where you originally posted this question.
Your answer
is here in the thread where you originally posted this question.
The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops.
The cheating problem has a trivial solution.
The distributed miners work to find a hash at a difficulty level that is considerably lower than the network requires. Whenever they find one, they send it back. When one of those hashes is difficult enough to meet the needs of the network, it generates 50 bitcoins which are distributed to those who have been sending in hashes at the easier level.
There's no way to look for easy hashes without also having a chance to find the occasional difficult hash. And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).
With this scheme there is no incentive to cheat, and no need for \"banning\".
",
"nested_level": 0
},
{
"id": 3720,
"thread_id": 250,
"source_id": "19",
"poster_name": "slush",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2167",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24928#msg24928",
"date": "2010-11-27T18:58:19Z",
"text": "And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).
Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as \"my own\" hash? I don't think so. I thought it is possible to not return hash to coordinator and put it directly to bitcoin network in own transaction...
Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as \"my own\" hash?
In a pooled mining situation, the winning hash
cannot be used as \"your own\".
The hash incorporates all of the transactions in the block, including the one that pays 50 BTC to the generator.
If you are hashing for pooled generation, the winning hash is only useful to the pool.
If you are hashing for yourself, then obviously the winning hash is useful to you. But in that case the \"low-difficulty\" hashes that you generate are useless to the pool, so the pool will not pay you a share of the generated 50 BTC.
It is a solved problem to prevent cheating with pooled generation.
The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops.
Is there a particular reason that the pooled miner I created is not sufficient? It has the basics there already. It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client. I just updated
this thread with the latest source and binaries for pooled mining.
How can the server create winning hashes? Winning hashes are by definition hard to compute objects that are all shared as soon as they are known. In fact, you can cheat by simply having a fake miner on a bunch of different IPs (via ipv6 you can have millions) with one real miner. The real miner remembers all the previously hard to compute objects and does hard work so has the same information as the server. If the server sends a unit of work to a fake miner, the fake miner forwards the request to the real miner and otherwise does nothing.
Your assumption about IP addresses is also invalid, btw. People still have dynamic ip addresses.
I would be interested in the concept, but I don't think there is a solution.
",
"nested_level": 0
},
{
"id": 3724,
"thread_id": 250,
"source_id": "23",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24966#msg24966",
"date": "2010-11-27T22:21:27Z",
"text": "To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked. What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?
I wonder if it wouldn't be simpler to just rent processing power. For instance by renting a ssh access to each machine.
The price could be directly proportionnal to the total number of computed hashes.
",
"nested_level": 0
},
{
"id": 3725,
"thread_id": 250,
"source_id": "24",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg24979#msg24979",
"date": "2010-11-27T22:59:18Z",
"text": "The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops.
Is there a particular reason that the pooled miner I created is not sufficient? It has the basics there already. It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client. I just updated
this thread with the latest source and binaries for pooled mining.
Can't they just send all except the winning ones? Maybe I don't understand though.
To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked. What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?
<sigh>
Either I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.
Suppose I operate a pooled mining server, and I recruit some clients who wish to pool their mining.
My server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current \"official\" difficulty level.
My server gets a constant trickle of candidate hashes sent back by the remote mining clients. Every now and then, one of those hashes meets the official difficulty level and my server can generate a block, which earns my server 50 bitcoins.
I now distribute bitcoins to the remote mining clients, at the rate of one bitcoin for each hash that was submitted for the current block that was at or above 1/40th of the official difficulty level.
In the long run, I would expect to distribute 40 coins out of every 50 that my server generates, although there will be some fluctuation from block to block. Nothing in this scheme requires the clients to be honest, because there is no way that a dishonest client can cheat!
The client is calculating hashes that will generate 50 BTC for
my server. Those same hashes are not of any use to a dishonest client. They cannot be used to generate 50 BTC for the dishonest client, because a different hash code is needed to encode the payment of the generated bitcoins to someone else. And if the dishonest client tries to cheat by generating hashes that will pay the generated bitcoins to themselves, then the hash codes they submit won't validate at my server and I won't distribute any share of the payouts to them.
So this scheme requires absolutely no trust of the client.
This scheme also does not require the mining client to have faith that the server is honest. If the server advertises that it is paying out 1BTC for each hash that is at least 1/40th of the official difficulty level, then every client that submits an \"easy\" hash for a block that was generated can check that they received their bitcoin. Any fraud would show up immediately.
Either I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.
Sorry, your system seems quite well thought, indeed. I hadn't been paying enough attention.
Still, I keep thinking that renting ssh access would be much simpler a solution.
Ribuk, thank you for explaining again. I get it now. It wasn't sinking in that the miners were working on a block for which they couldn't take the reward, seems obvious now.
",
"nested_level": 0
},
{
"id": 3729,
"thread_id": 250,
"source_id": "28",
"poster_name": "QuantumMechanic",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=241",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg25032#msg25032",
"date": "2010-11-28T05:23:48Z",
"text": "It sounds like pooled mining would either flood the network with tiny transactions, or be unfeasible due to transaction fees. So the server would therefore have to keep accounts for users which they could withdraw from once their balance gets large enough.
I guess it would probably be best then if the server required the miners to have MyBitcoin accounts, or something similar. It'd be nice if MyBitcoin offered a pooled mining service; they've got all the accounting infrastructure in place, and it could be a nice additional source of revenue for them.
Very elegant solution, Ribuck.
",
"nested_level": 0
},
{
"id": 3730,
"thread_id": 250,
"source_id": "29",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg25053#msg25053",
"date": "2010-11-28T07:11:33Z",
"text": "My server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current \"official\" difficulty level.
One of the potential problems I can see is that you may have to tweak the \"reduced\" difficulty level in some way so that it really is about a 1 in 40 chance of getting a successful hash. It would seem to me that a reduction of even a couple of bits in the expected hash would have major consequences in terms of how many \"reduced difficulty hashes\" are created and it is possible that reducing the difficulty to 1/40th of the \"official\" difficulty level may create many more \"successful\" reduced difficulty hashes than 40, perhaps even to a higher order of magnitude. This is something to test with a successful experiment of this idea to see just how it might turn out.
Furthermore, it is also going to be random in terms of how many reduced hashes are going to be created per successful hash cycle, as you are dealing with probability here and not mathematical certainty in terms of how many are going to be generated by the \"farm\" even if it does produce in this example on average about 40 \"reduced difficulty hashes\". It may still be worth the effort if it turns out that on average that is all you have to spend for an increase in successful blocks created, but it will be some blocks where the hash farm server makes a bunch of coins for the server operator and other times it may be at least temporarily a loss.
Another potential problem I also see is if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty. This is a potential liability issue so far as the \"owner\" of the hash farm server is concerned, as it would substantially impact the \"profit margin\". Think of it this way: If the current difficulty is at say 800 and you've received 30 hashes with a difficulty level of 20 (1/40th of the difficulty, as you suggested here), then the difficulty increases to 1600, it is very likely that you may have to plow through another 30-40 hashes at the new higher difficulty level of 40 before you get a successful block into the chain mining the coins. If in this example you are still paying out 1 BTC per reduced hash, it could get very costly for the person running the hash farm in this case. It may wipe out any profit earned and certainly is another potential liability issue to think about. I'd have to think through the statistical probability on an increase of difficulty some more in terms of giving some hard numbers, but it is something that should be accounted for.
Then again, difficulty could drop brining in at least statistically more money to the server operator. The current tendency is for increases of difficulty, however.
Otherwise, I think the basic concept as outlined here is pretty sound and would tend to work rather well. Almost too well as I could see this being put into a botnet and having the computers in the botnet be sending back potential hashes without having to worry about any payments. Network bandwidth would be trivial and almost unnoticed, and you could even \"throttle\" the CPU bandwidth or throw it onto the GPU instead. I have no doubt that eventually somebody is going to build one of these botnets if it hasn't already been built for Bitcoins.
... if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty. This is a potential liability issue so far as the \"owner\" of the hash farm server is concerned, as it would substantially impact the \"profit margin\"
Sorry, you misunderstand. The server operator only pays out to easy hashes that were submitted for a block that is won. There's no payout for easy hashes that were submitted for a block that someone else generates.
The difficulty can't change in the middle of a block. It always changes at a known time, and you always know exactly what the difficulty is, so there's no risk here.
...you are dealing with probability here and not mathematical certainty...
That's absolutely true, but over time probability tends towards mathematical certainty. If the server operator is getting a few percent of the generated bitcoins, it doesn't take long to become virtually guaranteed profit.
This is brilliant!
In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one \"server\" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!
",
"nested_level": 0
},
{
"id": 3733,
"thread_id": 250,
"source_id": "32",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg25111#msg25111",
"date": "2010-11-28T14:55:42Z",
"text": "
Am I the only one who thinks it would be way more simple to just rent distant shell access ??
",
"nested_level": 0
},
{
"id": 3734,
"thread_id": 250,
"source_id": "33",
"poster_name": "FreeMoney",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=381",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg25115#msg25115",
"date": "2010-11-28T15:34:39Z",
"text": "This is brilliant!
In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one \"server\" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!
Oh, I didn't even realize this. But it is correct I think. Only the header needs to be hashed. So this scheme has benefits beyond reducing the variance in generating. Very nice.
I think I initially misunderstood the blocks in that the hashes that we compute are independent of the address. Now, I believe that we are looking for something like sha256 (bitcoint address + amount (I am not sure whether the value is implicit, so this value might not be there) + <answer>) with some desired properties (of which the number of final zeros is an approximation), where + means some concatenation operator of bits.
If the computation is like that, _then_ it might work, but I don't see why someone cannot just only send you the worthless hashes (for you) and don't send those that are useful to you. By this mechanism they can bankrupt you. Anyway, I think it is a bad way to communicate with natural language only about these topics. Just write out the computations that you intend to do on the server and the client and then we can see whether it is a brilliant idea or a flawed one. Annotations on the computations as to which goal they intend to achieve is also useful for communication.
Forcing cooperation out of nodes is not easy.
",
"nested_level": 0
},
{
"id": 3736,
"satoshi_id": 517,
"thread_id": 250,
"source_id": "35",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Cooperative mining",
"url": "https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119",
"date": "2010-11-28T16:03:30Z",
"text": "ribuck's description is spot on.
Pool operators can modify their getwork to take one additional parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone
That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.
The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.
Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.
New users wouldn't really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server. When the miner says it found something, a while later a few coins show up in their account.
Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.
",
"nested_level": 0
},
{
"id": 3737,
"thread_id": 251,
"source_id": "1",
"poster_name": "Ale\u0161 Janda",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2409",
"subject": "Is safe running bitcoins with the same wallet on more computers simultaneously?",
"url": "https://bitcointalk.org/index.php?topic=1986.msg25093#msg25093",
"date": "2010-11-28T13:44:12Z",
"text": "Hi,
I would like to use bitcoins but I'm using more than one computer. Can I use just one wallet on all computers (by copying settings)? Or it isn't possible?
What happened if someone send me money and bitcoin client run on more computers? What happened if I send money to anyone from one of clients? Will it be synchronized automatically?
Maybe it's a simple quetsion but I didn't find answer to this.
Thanks.
",
"nested_level": 0
},
{
"id": 3738,
"thread_id": 251,
"source_id": "2",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Is safe running bitcoins with the same wallet on more computers simultaneously?",
"url": "https://bitcointalk.org/index.php?topic=1986.msg25099#msg25099",
"date": "2010-11-28T13:59:24Z",
"text": "i've never tried it myself and wouldn't recommend to,
in no way it's \"safe\", i guess it will cause some trouble sooner or later.
if you just want to use your wallet (spend/receive coins) on multiple machines, there's ways to make it portable (i guess, also not tried yet).
if you want to
generate on multiple machines, that's possible by using a single client/wallet and multiple
miners (
GPU,
CPU) running on the same, or multiple remote machines.
I'm interested in hearing the problems with this. The current version generates a pool of 100 address, but are these used for receiving change? Maybe there could be an option for generating more than 100 addresses, and also for seeing how many you have left?
Is there some other type of problem I'm overlooking?
",
"nested_level": 0
},
{
"id": 3740,
"thread_id": 251,
"source_id": "4",
"poster_name": "BitLex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=292",
"subject": "Re: Is safe running bitcoins with the same wallet on more computers simultaneously?",
"url": "https://bitcointalk.org/index.php?topic=1986.msg25120#msg25120",
"date": "2010-11-28T16:03:41Z",
"text": "the option to generate more addresses to the keypool already exists
# bitcoin.conf
# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
keypool=100
but as far as i understand, it's supposed to keep backups valid (for some time), not to sync multiple wallets.
i have no idea how that would work in the long term.
Will it be synchronized automatically?
Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up.
If you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).
New demonstration CPU miner available:
http://bitcointalk.org/index.php?topic=1925.0Hi all,
just built the latest bitcoin-git source, seems like the wallet or database format has changed
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
terminate called after throwing an instance of 'std::ios_base::failure'
what(): CDataStream::read() : end of data
Could it be 84d7c981dc52cc738053 that broke something ?
",
"nested_level": 0
},
{
"id": 3743,
"thread_id": 252,
"source_id": "2",
"poster_name": "Gavin Andresen",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=224",
"subject": "Re: Incompatible wallet format with latest bitcoin-git ?",
"url": "https://bitcointalk.org/index.php?topic=2007.msg25464#msg25464",
"date": "2010-11-29T20:56:02Z",
"text": "I haven't tested my 'master' bitcoin-git branch in a while, I wouldn't be surprised if the new 'accounts' code in the subversion tree broke something.
Which not-in-subversion features are you using?
",
"nested_level": 0
},
{
"id": 3744,
"thread_id": 252,
"source_id": "3",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Incompatible wallet format with latest bitcoin-git ?",
"url": "https://bitcointalk.org/index.php?topic=2007.msg25465#msg25465",
"date": "2010-11-29T20:58:30Z",
"text": "Hi all,
just built the latest bitcoin-git source, seems like the wallet or database format has changed
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
terminate called after throwing an instance of 'std::ios_base::failure'
what(): CDataStream::read() : end of data
Could it be 84d7c981dc52cc738053 that broke something ?
What are the lines in debug.log leading up to the end-of-file exception you pasted?
I have tested accounts, it works very well
",
"nested_level": 0
},
{
"id": 3746,
"thread_id": 252,
"source_id": "5",
"poster_name": "davout",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1929",
"subject": "Re: Incompatible wallet format with latest bitcoin-git ?",
"url": "https://bitcointalk.org/index.php?topic=2007.msg25471#msg25471",
"date": "2010-11-29T21:09:06Z",
"text": "Bitcoin version 3.17.1 beta
Default data directory /home/david/.bitcoin
Bound to port 8333
bitcoin server starting
Loading addresses...
dbenv.open strLogDir=/home/david/.bitcoin/database strErrorFile=/home/david/.bitcoin/db.log
Loaded 5017 addresses
addresses 122ms
Loading block index...
LoadBlockIndex(): hashBestChain=00000000000013587f18 height=94571
block index 1294ms
Loading wallet...
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
terminate called after throwing an instance of 'std::ios_base::failure'
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
what(): CDataStream::read() : end of data
",
"nested_level": 0
},
{
"id": 3747,
"satoshi_id": 521,
"thread_id": 252,
"source_id": "6",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Incompatible wallet format with latest bitcoin-git ?",
"url": "https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799",
"date": "2010-11-30T19:02:31Z",
"text": "What was this wallet used with? An early accounts patch or git build?
It's while loading the wallet. I assume it must be in this:
else if (strType == \"acentry\")
{
string strAccount;
ssKey >> strAccount;
uint64 nNumber;
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}
You could check that with this:
else if (strType == \"acentry\")
{
string strAccount;
assert(!ssKey.empty());
ssKey >> strAccount;
uint64 nNumber;
if (ssKey.size() != 8 )
printf(\"***** %s %d\n\", strAccount.c_str(), ssKey.size());
assert(ssKey.empty() == false);
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}
Was there an interim version of accounts on git at some point that had just (\"acentry\", \"account\") for the key?
If you have gdb, you could run it in gdb and do a backtrace.
gdb --args bitcoin ...
run
(wait for exception)
bt
",
"nested_level": 0
},
{
"id": 3748,
"thread_id": 253,
"source_id": "1",
"poster_name": "davux",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2151",
"subject": "JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28160#msg28160",
"date": "2010-12-08T17:07:21Z",
"text": "It would be great to have a JSON-RPC method for listing new transactions that are newer than a particular transaction id. This would enable developpers to watch new transactions easily, by just keeping track of the latest known txid and polling that method at the rate of their choice.
A possible way to do it would be to extend listttransactions so that it accepts an optional
txid argument:
listtransactions <account> [count=10] [txid]
If
txid is given, don't show it, nor any transaction older than it.
(As a sidenote, maybe listtransactions, with or without txid, should accept filtering by transaction category: generate, send, receive, move.)
I'm sorry I can't propose any patch here, as I can't do any decent C++.
+1
I haven't got my hands dirty there yet, and would rather spend what time I find to do import/export of keys, but that is something that would help some of my scripts a lot.
",
"nested_level": 0
},
{
"id": 3750,
"thread_id": 253,
"source_id": "3",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28193#msg28193",
"date": "2010-12-08T19:01:02Z",
"text": "It would be great to have a JSON-RPC method for listing new transactions that are newer than a particular transaction id. This would enable developpers to watch new transactions easily, by just keeping track of the latest known txid and polling that method at the rate of their choice.
If we're adding code to watch for new transactions, then we should be including gavin's monitor patches:
https://github.com/gavinandresen/bitcoin-git/tree/monitorreceivedSurely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?
Then it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.
Can anyone confirm this?
",
"nested_level": 0
},
{
"id": 3752,
"satoshi_id": 524,
"thread_id": 253,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228",
"date": "2010-12-08T20:21:49Z",
"text": "It's not safe to use listtransactions this way.
I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.
",
"nested_level": 0
},
{
"id": 3753,
"thread_id": 253,
"source_id": "6",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28229#msg28229",
"date": "2010-12-08T20:22:42Z",
"text": "Surely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?
Then it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.
The wallet is a key/value db4 database (and a key/value map in RAM).
Neither data structure is ordered by time.
I can see the motivation for davux's request. In developing the e-commerce plugins I've released, I've wondered about the viability long term of using a \"dump\" method against the wallet, since over time the data returned is just going to grow and grow.
What I'd prefer is being able to attach a JSON-RPC callback URL to an account or an address, maybe to be invoked each time a confirmation or any other status change to that account or address comes in, until the callback is cleared. That would eliminate the need for polling the wallet entirely.
I threw a \"feature request\" post in about that someplace.
",
"nested_level": 0
},
{
"id": 3755,
"thread_id": 253,
"source_id": "8",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28247#msg28247",
"date": "2010-12-08T20:46:03Z",
"text": "I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
At some point, a website or person accepting a transaction
must take this risk. It is unavoidable, whether you use listreceivedbyaddress or listtransactions. This is why listtransactions reluctance seems so unusual.
Almost every exchange or website accepting bitcoins achieves a
binary decisionpoint, where the transaction is accepted, and goods are shipped or money is exchanged. After that binary decisionpoint, even if the block chain is reorg'd or transactions disappear, there is nothing the website can do but take a loss (or pursue a refund outside of bitcoin).
From the website's point of view, there is zero effective difference between 'listtransactions 6' and 'listreceivedbyaddress 6', because the end result to the website operator is the same: the goods have been shipped / order accepted / money exchanged.
Then how do you cope with the issues I listed in the message you quoted?
",
"nested_level": 0
},
{
"id": 3757,
"thread_id": 253,
"source_id": "10",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28301#msg28301",
"date": "2010-12-08T23:07:22Z",
"text": "I think the important point is that these things are unavoidable unsafe after a certain point, even for listreceivedbyaddress. So I think it's helpful to compare current website behavior under mainline bitcoin, with listtransactions. Let us call this the
confirmation point. Addressing your queries...
1) How do you know if a past transaction becomes invalid and disappears?
bitcoinmarket and mtgox and other sites seem to consider 6 confirmations their \"confirmation point\", the moment at which a transaction may be considered \"safe.\" If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.
Same for a web store or brick-and-mortar store. There is a confirmation point at which the customer receives goods. If a TX becomes invalid after that, the store takes an unavoidable loss, because the customer is already gone with the purchased goods.
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
Let us assume that confirmation count for txid 0x1234 is bouncing wildly between 0 to 10 to 0 and back and forth, due to a large number of block reorgs.
Whether it is listreceivedbyaddress or listtransactions, you still have a binary confirmation point, a moment in time, at which the transaction crosses the \"approved by store\" level of confidence. At that confirmation point, the customer leaves with purchased goods, and store takes a loss regardless of further block chain or TX behavior.
I do agree a programmer may make a mistake, and assume that number of confirmations will always increase. But that human mistake, too, will cause danger when used with listreceivedbyaddress.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
On
this point, I agree that listtransactions presents some additional danger here, due to changing txid,
if and only if the new double-spend matches destination bitcoin address being sought by the JSON-RPC user.
Nevertheless, in this case too, the user's security rests entirely on their level of confidence: if the TX is replaced before 6 confirmations, software will likely not notice anything. If the TX is replaced after 6 confirmations, the customer has already left with purchased goods, and the bitcoin user takes a loss.
This is simply inherent to bitcoin itself. A block chain reorg
might happen after 50 blocks. But websites do not want to make their users wait 50 blocks before receiving goods. It is the well-known snack machine problem. listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Transactions can and will be replaced after the binary \"confirmation point.\" All users of bitcoin must figure this into their business plans, just like they account for credit card chargeback risk or shoplifting risk.
Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.
So it would be a design problem in the developper's app, not a problem inherent to listtransactions. What you're saying is: if listtransactions is used without care, it can be dangerous. OK, but many programmatic tools have traps too. For example, programming with threads is full of design traps. That doesn't mean that that tool shouldn't be made available to developpers, but that the documentation must warn strongly about those traps.
My point: let's make listtransactions available, but document it precisely, like any API, and explain the design mistakes that shouldn't be made when using it.
I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.
It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.
Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.
I'll and add another reason not to have a \"list transactions that happened after <txid>\" :
move \"transactions\" don't have a transaction id, but they do affect account balances (and are listed in listtransactions).
Your code is going to get really messy if you expect to call listtransactions and then squirrel away the txid of the last item returned. If it was \"category\":\"move\", there WILL be no txid...
RE: eliminating polling: at some point fairly soon, I plan on cleaning up my \"monitorreceived\" patch, to POST to a URL when transactions come in or blocks are accepted... but I need to do some Deep Thinking to redesign based on lessons learned from 'accounts'. It might turn into a very minimal API, where the notification is \"Hey, txid <123ae4221...> just got to N confirmations, you might want to call gettransaction and getbalance to get up-to-date.\"
",
"nested_level": 0
},
{
"id": 3761,
"thread_id": 253,
"source_id": "14",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: JSON-RPC method idea: list transactions newer than a given txid",
"url": "https://bitcointalk.org/index.php?topic=2151.msg28330#msg28330",
"date": "2010-12-09T00:58:05Z",
"text": "I'll and add another reason not to have a \"list transactions that happened after <txid>\" :
I agree with you and satoshi about \"txs after <txid>\". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.
If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.
That's not always the case. Sometimes the customer will have a balance at the website. The operator of the website will certainly want to know if a past transactions becomes invalid and disappears.
If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.
That's not always the case. Sometimes the customer will have a balance at the website. The operator of the website will certainly want to know if a past transactions becomes invalid and disappears.
Sure, and that's easy enough to track with transactions.
I agree with you and satoshi about \"txs after <txid>\". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.
As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.
Gavin, could listtransactions have an option to list transactions for all accounts?
I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]
It would be hard to do that from the command line though.
I can't think of a good solution for the interface, that's the problem. Maybe \"*\" special case like \"\" is. Everyone would have to make sure no user can create account name \"*\".
Sure, and that's easy enough to track with transactions.
I don't get how that's \"easy\" to track with transactions.
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at
http://bitcointalk.org/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/This is the first update to Bitcion that I'm not jumping on and grabbing right away, because I think the choice of checking transaction types in blocks is not necessarily a good thing... at least while the question is undecided in the community. It does impact the network but in a subtle and political way.
At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts \"pure\". All that has happened here is to simply lay the gauntlet down to get past the \"IsStandard()\" check and find transactions which can pass that test but still contain other data.
",
"nested_level": 0
},
{
"id": 3767,
"thread_id": 254,
"source_id": "3",
"poster_name": "theymos",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=35",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28309#msg28309",
"date": "2010-12-08T23:41:42Z",
"text": "At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts \"pure\". All that has happened here is to simply lay the gauntlet down to get past the \"IsStandard()\" check and find transactions which can pass that test but still contain other data.
Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions?
ArtForz (15+% of the network), tcatm (2Ghash/s), and doublec (pool maintainer) have stated that they will not use IsStandard. Non-standard transactions will therefore still be possible.
When I have time, I will produce a patch for Bitcoin that will remove all non-network-enforced restrictions on transactions, so that other miners can easily also be configured to include these transactions.
",
"nested_level": 0
},
{
"id": 3769,
"thread_id": 254,
"source_id": "5",
"poster_name": "Cdecker",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=49",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28319#msg28319",
"date": "2010-12-09T00:35:51Z",
"text": "I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)
I do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily.
",
"nested_level": 0
},
{
"id": 3770,
"thread_id": 254,
"source_id": "6",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28321#msg28321",
"date": "2010-12-09T00:38:17Z",
"text": "Please start your own block chain, rather than forking the network like this.
I hope it is clear the havoc that your push to include non-currency data is causing.
",
"nested_level": 0
},
{
"id": 3771,
"thread_id": 254,
"source_id": "7",
"poster_name": "nelisky",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=601",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28325#msg28325",
"date": "2010-12-09T00:45:53Z",
"text": "Please start your own block chain, rather than forking the network like this.
I hope it is clear the havoc that your push to include non-currency data is causing.
Wrong thread?
Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions?
There's been exactly one block with non-standard transactions:
http://blockexplorer.com/b/71036
... and it contained no fees.
HOWEVER: jgarzik, you're over-reacting, too. This will
not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc.
HOWEVER: jgarzik, you're over-reacting, too. This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc.
I never said it would cause a block chain split. It's more fundamental: a rules split.
Forking the network implied a majority of miners
not running mainline bitcoin transaction rules. theymos appears to be drawing a line in the sand, where he wants to convince most miners to stop paying attention to mainline bitcoin transaction validation rules. He's free to do that. And miners are free to validate what they want to.
But this sort of split will make it more difficult to work on the network in the future, and de facto, opens the door to larding down the block chain with all sorts of non-currency-related data as being discussed in other threads.
HOWEVER: jgarzik, you're over-reacting, too. This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid. Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them. There will be no havoc.
No, this isn't going to cause a block chain split, it is going to cause a fork of Bitcoin. I just hope that is thought through very well, and I don't think it has been.
Since transactions aren't being forwarded that fail the IsStandard() algorithm, those who want to put \"non-standard\" transactions into a bitcoin chain must either hard-connect to a miner who would accept these transactions or force some sort of ad-hoc way of setting up a second tier in the network to find nodes that will accept these kind of transactions AND likely put them into a future block.
That only one block may fail at the moment with this test is ignoring the current discussion where conceivably almost every block in the near future may have some form of these \"non-standard\" transactions.
Please start your own block chain, rather than forking the network like this.
I hope it is clear the havoc that your push to include non-currency data is causing.
Agree. I don't see any reason why non standard, maybe non-financial transaction should be inside financial block chain. Also don't understand why major miners are going to fork client. I thought this software is about currency. So I'm absolutely OK with last release and I already updated all my miners.
I'm definitely NOT against software based on chains and personally will support any BitDNS effort, but, please, keep bitcoin chain consistent.
Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped.
Even later in the future, those who include extra things without compensation in their blocks will get their blocks orphaned by the chain.
I for one will upgrade my client to v.18 until their come a time when it is profitable for me to accept non-standard transactions.
",
"nested_level": 0
},
{
"id": 3777,
"thread_id": 254,
"source_id": "13",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28371#msg28371",
"date": "2010-12-09T02:48:28Z",
"text": "Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped.
That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions.
That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions.
No, it'll disadvantage people who refuse to pay fees. What they're storing in their transactions is irrelevant.
That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions.
No problem with that! It will increase the competitive nature of generation, making Bitcoin harder to attack, and encouraging improvements to the generation network to support more transactions (to maximize profit).
You've gotta love the free market!
No, it'll disadvantage people who refuse to pay fees.
Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam.
I applaude this decision.
Why would anyone want to muddle up their nice distributed currency system, free from complex regulation from governments, and add a DNS system on top of it? How hard would that be to explain to someone's mom, who (conceivably), could be using Bitcoin in the future?
There is plenty of transaction fees to be had when bitcoin builds a larger user base. We don't need non-standard transactions to make mining worthwhile
The simpler Bitcoin stays, the better IMO.
",
"nested_level": 0
},
{
"id": 3782,
"thread_id": 254,
"source_id": "18",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28377#msg28377",
"date": "2010-12-09T03:09:12Z",
"text": "Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam.
No, as no generators will want to block fee paying (profitable) transactions.
When adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down.
In the long run, extra data in the chain will _reduce_ the relative cost of a currency-only transaction, because the currency-only transaction uses much less data, compared to the data transactions, per transaction.
Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam.
No, as no generators will want to block fee paying (profitable) transactions.
When adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down.
Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees.
Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees.
Sorry I have to disagree with you, the transaction fees are based upon the 'cost' to generator to include the transaction. The cost is directly related to the amount of data needed to be included.
In the future there will be no 'hard limits' on block size, only the risk that the block will be rejected and orphaned by the chain as it is to large.
When a generator deciding what transactions to include, if the network is already profitable with very large blocks, (eg. 20mb+ as they have much non-currency data in them), then including very small 'currency' transactions have a minute cost. For example, 20,000,000 vs 20,000,010.
If the block chain is restricted to just currency data, there is much less incentive to improve the efficiency of handling large blocks data. Therefore the relative cost will be much greater... 500,000 vs 500,010. Therefore the transaction fees required for small amounts of data are likely to be higher on a system that only induces currency data.
Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain. Increasing the block size does not reduce transaction fees.
Sorry I have to disagree with you, the transaction fees are based upon the 'cost' to generator to include the transaction. The cost is directly related to the amount of data needed to be included.
This is not an opinion; read the source. Transaction fees vary on total block size, not just transaction size.
Thus, larger blocks == higher fees.
Thus, more data spam, or more overall network traffic (currency or not) == higher fees.
This is not an opinion; read the source. Transaction fees vary on total block size, not just transaction size.
Yes, that is what the source says for the moment, in the future I do not expect the generators to just arbitrarily follow the current rules, rather I expect the generators to be quite discerning in what rules they enforce or ignore.
Yes, larger block will be more expensive, (eg. bandwidth, and risk of rejection costs), but as the average amount of data in the blocks increase, the _relative_ cost per data amount will go down.
These experiments are better suited for an alternate network and block chain. Leave the currency as a currency, and preserve the investments that many have already made in bitcoin.
It could be as simple as a patch that accepts \"-datanet\" and non-standard transactions, such as
http://yyz.us/bitcoin/patch.bitcoin-datanet-fork(warning:
demonstration patch, do not use; you would want a real genesis block for a production network)
consider also that it's possible to encode data into the bitcoin blockchain already, merely by specially crafting the transaction. (See the 'first' option on
http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity ).
alternatively, only timestamping and proof of expense (i.e., a regular transaction with a fee) may be used, pushing off the actual data storage off to external service (see 'third' option, ibid.)
but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power.
I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)
I do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily.
You already have that
but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power.
I personally agree with nanotube's point here, especially in light of the fact that arbitrary data can already be disguised in standard transactions if a person is motivated enough. I have not looked at the source code, but from what I understand I think that a much more pleasant (politically and technically speaking) solution would be to:
by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?I would like to hear why the above option was thrown out by the developers.
While I agree that bitcoin transactions themselves should be the primary use of the blockchain, a good currency need not ostracize itself either.
by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?
I would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to \"legislate\"
any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to:
- Remove the restrictions to get more fees
- Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections.
The restriction on relaying these transactions should be removed, at the very least.
by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?
I would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to \"legislate\"
any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to:
- Remove the restrictions to get more fees
- Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections.
...unless the use of bitcoin for non-currency purposes discourages currency use. Some uses of the network can act as an overall disincentive against mainstream use. If people see that miners care little for currency transactions on the bitcoin network, or all the data spam increases TX fees to annoying levels, currency users will find a new network elsewhere. If people find out law-enforcement-objectionable data such as \"kiddie-pr0n.p2p DNS data\" is being managed on this network, that increases the incentive for currency users to go elsewhere.
Maybe that makes some miners happy in the short term, and you happy, but I'm here for the revolutionary new type of digital cash.
And this generalized data timestamping/notary service seems like it has the distinct
probability of degrading service for digital cash, if it is even remotely successful.
by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?
I would be happy with 128 bytes of arbitrary data.
I introduced six persons to bitcoins yesterday, and one so far today, by giving them 20 BTC each for a promise to put the coins into circulation. They all had the same complaint: It took ages, for one of them almost two hours, to download the initial blocks!
It doesn't get any faster by adding junk to the blocks. I don't get it? Why is it so important for people here to make Bitcoins slow and inefficient?
Fees? Come on, miners! How much do you make from fees?
Fees? Come on, miners! How much do you make from fees?
Not much,
I've made about 0.5 BTC from fees. It is just too profitable to just mine for the hell of it, I get 50 BTC each time I make a block, and (if I'm very lucky, I make 0.05 BTC from fees).
About the large chain size, this isn't a issue, in the future it will be possible to 'prune' the chain with balances. This will reduced the size by a vast amount. When extra data is included in the chain, it is likely to be forgotten by (most) the network if it stops being important.
For example, the BitDns guys will keep a relocation of a the DNS data for ages, however the banks are likely to just keep the bitcoin currency transfer data and drop the rest.
There are many questions still unclear about bitcoin. We have yet to see a lightweight client, freed of the block chain's burden. We still have to see how the TX fee market will develop. There is uncertainty about what the average number of transactions per minute would be in, say, two years.
Distributed DNS using bitcoin concepts is really cool. But isn't this a separate currency/commodity? Why not create a separate chain for it? Why force bitcoin users to support services they aren't aware of?
What if I want only BitDNS? And I don't need the payments stuff?
",
"nested_level": 0
},
{
"id": 3796,
"thread_id": 254,
"source_id": "32",
"poster_name": "Timo Y",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=271",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28467#msg28467",
"date": "2010-12-09T09:21:06Z",
"text": "You've gotta love the free market!
We should not trust the \"free market\" blindly.
The problem is that including a lot of data in a block creates costs, not just for the miner who includes the data, but for
all other miners and
all other users, for
all eternity.
In the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee
only compensates the miner's costs.
As long as this tragedy of the commons situation hasn't been sorted out, the free market won't fix anything.
In the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee only compensates the miner's costs.
Current implementations, in the future the clients will only keep the stuff they care about. The DNS client will keep the DNS stuff, the bitcoin currency traders will keep the currency transactions.
Let the generators worry about the chain; if bitcoins become worthless, then they will not have any incentive to generate!
I for one have lots of faith in the free market, after all I'm a laissez-faire capitalist
, I will be voting will my generation. I suggest you invest in more that 50% of the generation network (or with like minded people), and ignore my the block I generate if you disagree with the data they contain. That is the life in a free market.
When we all bought into bitcoin, we all knew that then network is dictated by the majority of generation power. All I'm arguing is that the generators will look out for their best interests, and their interests happen to fit very nicely with bitcoin: A strong bitcoin currency.
I propose a law:
\"He who makes the chain, gets to decide what it looks like\"
",
"nested_level": 0
},
{
"id": 3799,
"thread_id": 254,
"source_id": "35",
"poster_name": "sturle",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1876",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28479#msg28479",
"date": "2010-12-09T10:57:47Z",
"text": "I propose a law:
\"He who makes the chain, gets to decide what it looks like\"
This could work combined with:
\"Everyone can choose to accept a block or discard it\"
I don't want everyone to be spammed by blocks full of junk, and prefer to try to nullify it by generating a competing block without including the junk. The junk will of course make it eventually, unless the majority of miners switch on their spam filters.
Well I spport Satoshi completely in this matter.
Leaving a possibility to store data in bitcoin chain is an accident waiting to happen. Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. And the governments would have a perfect propaganda possibility for fighting it. \"Normal\" people won't use bitcoin at all if it is associated with perverts, mafia, and financial scams.
",
"nested_level": 0
},
{
"id": 3801,
"satoshi_id": 528,
"thread_id": 254,
"source_id": "37",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Version 0.3.18",
"url": "https://bitcointalk.org/index.php?topic=2162.msg28533#msg28533",
"date": "2010-12-09T14:37:05Z",
"text": "New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough
long before there'll be enough clients who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible:
txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01
If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.
I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:
I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via
http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.
The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.
I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.
by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?
I would like to hear why the above option was thrown out by the developers.
Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems.
The danger is similar websites that try to blacklist <script> tags in HTML entered by users to prevent cross-site-scripting hacks. See
http://ha.ckers.org/xss.html for a nice sampling of how creative hackers can be.
I haven't asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit. I don't think it matters; I'm still convinced that whitelisting acceptable transaction types is the right thing to do.
As for \"the above option was thrown out by the developers\" --
nothing has been thrown out! Again, I haven't talked to Satoshi, but I'm open to the idea of a third 'standard' transaction type that includes extra, arbitrary data. Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs... and if there's general consensus that it is a good idea, roll it into production.
I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.
why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.
I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it.
A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that. How will I, the user, figure out what sort of fees have to go into a transaction?
",
"nested_level": 0
},
{
"id": 3805,
"thread_id": 255,
"source_id": "2",
"poster_name": "jgarzik",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=541",
"subject": "Re: Fees in BitDNS confusion",
"url": "https://bitcointalk.org/index.php?topic=2181.msg28672#msg28672",
"date": "2010-12-09T19:51:02Z",
"text": "A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that. How will I, the user, figure out what sort of fees have to go into a transaction?
For currency transactions, if you notice your transactions taking a long time to confirm, you increase the TX fee.
For non-currency transactions, it sounds like there will be some sort of fee schedule. The software that generates these special, non-currency transactions would likely have a user-friendly interface to indicate the cost.
It would be nice if there was some way that using the standard client you might be able to adjust the fee schedule for your own purposes and set \"policies\" for mining blocks and including transactions. I think that is a source of confusion here as no such user interface is currently provided for doing that.
Much of this is all theoretical at the moment because it is possible to make transactions \"for free\" and generally get them included in the next block at the moment. I don't see that is going to be sustainable in the long run, but we'll see how that goes. At the moment, it is important that most people using Bitcoins are simply hoping that the currency succeeds at all and aren't interested in making a killing or even a modest profit at it, which is why transaction fees are still mostly non-existent on the network.
",
"nested_level": 0
},
{
"id": 3807,
"thread_id": 255,
"source_id": "4",
"poster_name": "davout",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1929",
"subject": "Re: Fees in BitDNS confusion",
"url": "https://bitcointalk.org/index.php?topic=2181.msg28699#msg28699",
"date": "2010-12-09T21:08:55Z",
"text": "Just wondering about the following example :
I broadcast a transaction, sending X coins to some address.
Doesn't get included in blocks for a while because I don't include a fee.
Do I have a way to cancel it and broadcast it again with a fee this time ?
",
"nested_level": 0
},
{
"id": 3808,
"thread_id": 255,
"source_id": "5",
"poster_name": "RHorning",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=344",
"subject": "Re: Fees in BitDNS confusion",
"url": "https://bitcointalk.org/index.php?topic=2181.msg28704#msg28704",
"date": "2010-12-09T21:41:58Z",
"text": "Just wondering about the following example :
I broadcast a transaction, sending X coins to some address.
Doesn't get included in blocks for a while because I don't include a fee.
Do I have a way to cancel it and broadcast it again with a fee this time ?
Yes, although I don't think the canceled transaction protocol is necessarily complete in terms of its current implementation.
See also:
http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1#txThe \"version\" field allows somebody to send out a new transaction that effectively replaces an existing transaction with perhaps some new data. As long as the transaction hasn't been accepted into a block, in theory you can \"recall\" the transaction and modify the transaction in any way. Like I said, this is incomplete and the exact protocol to pull that off hasn't been included into Bitcoin yet. But it certainly is a possibility and may be a feature in a future version of Bitcoin.
Certainly the ability to \"recall\" a transaction hasn't been implemented yet in the UI, and once the transaction has been accepted into a block the only hope to really kill a transaction after that is to hope that the block doesn't get accepted into the main block chain. Then again, if the transaction has been accepted into a block without fees it shouldn't be a problem in terms of recalling the transaction for adding fees either as the issue is moot at that point.
Just wondering about the following example :
I broadcast a transaction, sending X coins to some address.
Doesn't get included in blocks for a while because I don't include a fee.
Do I have a way to cancel it and broadcast it again with a fee this time ?
See the
discussion of locktime for transaction replacement.
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 becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.
It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.
There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.
",
"nested_level": 0
},
{
"id": 3811,
"thread_id": 256,
"source_id": "1",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28818#msg28818",
"date": "2010-12-10T09:22:33Z",
"text": "I think to start writing a minimalistic bitcoin client on D language. Do you think this makes sense?
",
"nested_level": 0
},
{
"id": 3812,
"thread_id": 256,
"source_id": "2",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28819#msg28819",
"date": "2010-12-10T09:28:08Z",
"text": "I think to start writing a minimalistic bitcoin client on D language. Do you think this makes sense?
The more implementations we have, the better.
Unfortunately, writting a client is no easy task. Satoshi's code is far from from trivial.
Maybe then wait bitdns?
I'm just bored and a want to write a code
",
"nested_level": 0
},
{
"id": 3814,
"thread_id": 256,
"source_id": "4",
"poster_name": "davout",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1929",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28829#msg28829",
"date": "2010-12-10T10:37:03Z",
"text": "If you're bored you should learn some Ruby it's really sweet !
",
"nested_level": 0
},
{
"id": 3815,
"thread_id": 256,
"source_id": "5",
"poster_name": "Cryptoman",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2291",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28885#msg28885",
"date": "2010-12-10T15:26:33Z",
"text": "+1 on Ruby. Didn't someone recently write a Ruby interface to bitcoind?
",
"nested_level": 0
},
{
"id": 3816,
"thread_id": 256,
"source_id": "6",
"poster_name": "davout",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1929",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28886#msg28886",
"date": "2010-12-10T15:29:05Z",
"text": "I wrote a bitcoin daemon wrapper in Ruby
Fully extensible since it's heavily based on method missing
EDIT : Made it for Rails so it includes a lovely initializer and a sweet yml configuration file
",
"nested_level": 0
},
{
"id": 3817,
"thread_id": 256,
"source_id": "7",
"poster_name": "bitcoinex",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=577",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28906#msg28906",
"date": "2010-12-10T17:11:11Z",
"text": "I do not like ruby, python, perl or java
You want to re-implement the entire client?
Why make a convenient wrapper around the JSON API? That's much easier and just as useful.
",
"nested_level": 0
},
{
"id": 3819,
"thread_id": 256,
"source_id": "9",
"poster_name": "Cryptoman",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2291",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg28916#msg28916",
"date": "2010-12-10T17:27:21Z",
"text": "I wrote a bitcoin daemon wrapper in Ruby
Fully extensible since it's heavily based on method missing
EDIT : Made it for Rails so it includes a lovely initializer and a sweet yml configuration file
I'll have to spend some time playing with it over the winter break. Any thoughts on keeping a server running bitcoind relatively secure? It seems like having a wallet.dat file on a publicly-accessible server is an accident waiting to happen.
I do not like ruby, python, perl or java
Well, I don't like C or Java or anything else that uses braces.
python
I don't like IndentationErrors
perl
Not gonna criticize what I don't know
or java
I'll leave you the bob = new InstanceLocatorFactoryProxyWrapper<GenericInstanceBuilder>();
You want to re-implement the entire client?
Why make a convenient wrapper around the JSON API? That's much easier and just as useful.
It's pointless, I think. There is may be a \"multidimensional\" result.
Use jsawk:
$ ./bitcoin listreceivedbylabel | jsawk -n 'out(this.label+\" \"+this.amount+\" \"+this.confirmations)'
user_id:1080 106 5189
user_id:1081 0.05 5557
user_id:1083 2.89 2800
user_id:1087 500 5276
user_id:1105 0.4 462
user_id:1109 0.1 922
user_id:1110 0.04 431
You want to re-implement the entire client?
Why make a convenient wrapper around the JSON API? That's much easier and just as useful.
It's just not as fun !
I would love a ruby bitcoin client so much !!
Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.
",
"nested_level": 0
},
{
"id": 3825,
"thread_id": 256,
"source_id": "15",
"poster_name": "ribuck",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=392",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg29025#msg29025",
"date": "2010-12-10T23:04:41Z",
"text": "Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.
I bet you're also shocked by what restaurant kitchens look like, and by what goes into sausages.
Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.
I bet you're also shocked by what restaurant kitchens look like, and by what goes into sausages.
No, I happen to be aware of that, and that's why I usually try to eat at places with a semi-open kitchen.
The cryptography code that competent people use, doesn't look like a mess, btw. That 99% of the world uses this kind of obfuscated cryptography only shows that users don't know what they use. Have you ever looked at TrueCrypt for example? It's the exact same kind of mess.
Here we are with the Language war once again. Please just stop!
As for the topic, yes please get an alternative implementation started, the more the merrier
Maybe some good code actually makes it out there, helping future generations of clients to build on top of your code.
+1 on the D implementation (I'm starting a Java one in the holidays)
Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.
I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.
Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.
Can you be more specific? What exactly makes it a 'mess'?
+1 on scala if you're bored
I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.
I agree. Actually I'm amazed this is the product of only one person's work.
It's easy to complain about code. But unless a person can show that they did something better, they have no moral authority to complain.
",
"nested_level": 0
},
{
"id": 3833,
"satoshi_id": 541,
"thread_id": 256,
"source_id": "23",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: minimalistic bitcoin client on D language?",
"url": "https://bitcointalk.org/index.php?topic=2188.msg29259#msg29259",
"date": "2010-12-11T22:07:04Z",
"text": "I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.
That means a lot coming from you, Hal. Thanks.
Some sample pseudocode using the new Accounts based commands in 0.3.18.
print \"send to \" + getaccountaddress(username) + \" to fund your account\"
print \"balance: \" + getbalance(username, 0)
print \"available balance: \" + getbalance(username, 6)
// if you make a sale, move the money from their account to your \"\" account
if (move(username, \"\", amount, 6, \"purchased item\"))
SendTheGoods()
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6, \"withdrawal by user\")
You can use listtransactions(username) to show them a list of their recent transactions.
",
"nested_level": 0
},
{
"id": 3835,
"thread_id": 258,
"source_id": "1",
"poster_name": "da2ce7",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1882",
"subject": "Bitcoin and buffer overflow attacks",
"url": "https://bitcointalk.org/index.php?topic=2208.msg29095#msg29095",
"date": "2010-12-11T05:49:22Z",
"text": "I am convinced that the foundation of bitcoin (ie. the block chain) is secure from any non-nationally funded attack. The only attack that makes me scared is a buffer overflow attack that steals the private keys in the wallet, however doesn't spend them.
If a significantly large attack happens to the block chain, we can always make a new branch that doesn't include the attack; with the theft of private keys, there is no easy recovery option, save (in the case of a massive attack), starting the block chain from 0 again.
As I'm not a security expert, I do not know how secure bitcoin is against this sort of attack. However from my non-expert understanding direct to IP address transfers seems like a obvious surface area to attack.
Two questions: what attack areas dose the current bitcoin software have that could enable the theft of bitcoin private keys?
Secondly, what efforts can be taken to minimize the attack surface area of bitcoin?
",
"nested_level": 0
},
{
"id": 3836,
"thread_id": 258,
"source_id": "2",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: Bitcoin and buffer overflow attacks",
"url": "https://bitcointalk.org/index.php?topic=2208.msg29096#msg29096",
"date": "2010-12-11T05:52:40Z",
"text": "I am convinced that the foundation of bitcoin (ie. the block chain) is secure from any non-nationally funded attack. The only attack that makes me scared is a buffer overflow attack that steals the private keys in the wallet, however doesn't spend them.
If a significantly large attack happens to the block chain, we can always make a new branch that doesn't include the attack; with the theft of private keys, there is no easy recovery option, save (in the case of a massive attack), starting the block chain from 0 again.
As I'm not a security expert, I do not know how secure bitcoin is against this sort of attack. However from my non-expert understanding direct to IP address transfers seems like a obvious surface area to attack.
Two questions: what attack areas dose the current bitcoin software have that could enable the theft of bitcoin private keys?
Secondly, what efforts can be taken to minimize the attack surface area of bitcoin?
I've always thought that the only known possible attacks could allow double spendin or freeze the whole network.
I doubt any attack could steal private keys, apart from conventionnal attacks to the file system.
But I'm not an expert at all.
this isn't about protocol attacks, eg double spend and freezing. Rather implementation security weaknesses.
",
"nested_level": 0
},
{
"id": 3838,
"thread_id": 258,
"source_id": "4",
"poster_name": "wumpus",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=2252",
"subject": "Re: Bitcoin and buffer overflow attacks",
"url": "https://bitcointalk.org/index.php?topic=2208.msg29124#msg29124",
"date": "2010-12-11T09:59:40Z",
"text": "There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn't have buffer overflows because it checks array indices (Python, Java, C#, ...).
",
"nested_level": 0
},
{
"id": 3839,
"satoshi_id": 540,
"thread_id": 258,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: Bitcoin and buffer overflow attacks",
"url": "https://bitcointalk.org/index.php?topic=2208.msg29165#msg29165",
"date": "2010-12-11T13:32:37Z",
"text": "direct to IP address transfers seems like a obvious surface area to attack.
If you ever find anyone who turned it on. It's disabled by default.
There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn't have buffer overflows because it checks array indices (Python, Java, C#, ...).
It's all STL. There are almost no buffers.
adg
",
"nested_level": 0
},
{
"id": 3841,
"thread_id": 259,
"source_id": "2",
"poster_name": "Bimmerhead",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1496",
"subject": "Re: PC World Article on Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=2216.msg29241#msg29241",
"date": "2010-12-11T21:09:31Z",
"text": "I think this must be the highest Alexa ranking site yet to cite bitcoin.
BTW you have a pm.
",
"nested_level": 0
},
{
"id": 3842,
"thread_id": 259,
"source_id": "3",
"poster_name": "grondilu",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=1663",
"subject": "Re: PC World Article on Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=2216.msg29242#msg29242",
"date": "2010-12-11T21:11:05Z",
"text": "It was published right before the forum went down for a few hours haha.
Was it ? It's certainly correlated, then. The amount of new visitors blew up the bitcoin website.
Thanks for pointing it out.
This article is surprisingly balanced and accurate for a mainstream publication.
PC World is a big deal. I am psycheless. Time to restore the Wikipedia article.
",
"nested_level": 0
},
{
"id": 3844,
"satoshi_id": 542,
"thread_id": 259,
"source_id": "5",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Re: PC World Article on Bitcoin",
"url": "https://bitcointalk.org/index.php?topic=2216.msg29280#msg29280",
"date": "2010-12-11T23:39:16Z",
"text": "It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.
",
"nested_level": 0
},
{
"id": 3845,
"satoshi_id": 543,
"thread_id": 260,
"source_id": "1",
"poster_name": "satoshi",
"poster_url": "https://bitcointalk.org/index.php?action=profile;u=3",
"subject": "Added some DoS limits, removed safe mode (0.3.19)",
"url": "https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479",
"date": "2010-12-12T18:22:33Z",
"text": "There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.
- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.
I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.
- Removed \"safe mode\" alerts
\"safe mode\" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with \"-disablesafemode\", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.
Builds:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/ ![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc1_400x200.png&t=589&c=NOqIco7LH1etag\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc1_100x50.png&t=589&c=TK0WHoq1H9t5Zw\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc2_400x200.png&t=589&c=8AFo4x-IHiF75Q\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc2_100x50.png&t=589&c=M8KO6IlxlOLa0g\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc1s_400x140.png&t=589&c=ufkHfRQwnzhWPQ\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc1s_100x35.png&t=589&c=t_iTnE5BMRsFpA\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc2s_400x140.png&t=589&c=cEJYOqQRctW8xg\"/)
![\"\"](\"https://ip.bitcointalk.org/?u=http%3A%2F%2Fdl.dropbox.com%2Fu%2F3713769%2Fweb%2FBitcoin%2Faccept_bc2s_100x35.png&t=589&c=0RNaVIRFuOj_Mg\"/)
![\"\"](\"http://static/img695.imageshack.us/i/generate1.png/\")
![\"\"](\"http://static/img707.imageshack.us/i/unknownaddress.png/\")
![\"\"](\"http://static/img682.imageshack.us/i/known.png/\")
![\"\"](\"http://static/img692.imageshack.us/i/simplemix.png/\")
![\"\"](\"http://static/img293.imageshack.us/i/external.png/\")
![http://dl.dropbox.com/u/3713850/Untitled-1.png](\"http://dl.dropbox.com/u/3713850/Untitled-1.png\"){kind=link}
![http://dl.dropbox.com/u/3713850/bclarge.png](\"http://dl.dropbox.com/u/3713850/bclarge.png\"){kind=link}
![http://dl.dropbox.com/u/3713850/bcsmall.png](\"http://dl.dropbox.com/u/3713850/bcsmall.png\"){kind=link}
![http://www.bitcoin.org/download/bitcoin530.png](\"http://www.bitcoin.org/download/bitcoin530.png\"){kind=link}
![http://www.shalhoon.com/bitcoin.svg](\"http://www.shalhoon.com/bitcoin.svg\"){kind=link}
![http://www.shalhoon.com/bitcoin2.svg](\"http://www.shalhoon.com/bitcoin2.svg\"){kind=link}
![http://i45.tinypic.com/1z5knb8.jpg](\"http://i45.tinypic.com/1z5knb8.jpg\"){kind=link}
![http://i50.tinypic.com/2ih1h0p.jpg](\"http://i50.tinypic.com/2ih1h0p.jpg\"){kind=link}
![http://titania.smutfairy.com/~rm/time.gif](\"http://titania.smutfairy.com/~rm/time.gif\"){kind=link}
![here's a screenshot](\"http://bitlex.co.cc/static/img/screen_poclbm.jpg\"){kind=link}
![http://static/img835.imageshack.us/static/img835/2157/bitcoin.jpg](\"http://static/img835.imageshack.us/static/img835/2157/bitcoin.jpg\"){kind=link}
![http://static/img143.imageshack.us/static/img143/2157/bitcoin.jpg](\"http://static/img143.imageshack.us/static/img143/2157/bitcoin.jpg\"){kind=link}
![to satisfy your screeny-fetish](\"http://bitlex.co.cc/static/img/screen_HD5850_opencl_btc.jpg\"){kind=link}
![the ordinary screenshot](\"http://bitlex.co.cc/static/img/screen_GTX260vsHD5850_opencl_btc.jpg\"){kind=link}
![here's a screeny](\"http://bitlex.co.cc/static/img/screen_connect-switch.jpg\"){kind=link}
![here's](\"http://bitlex.co.cc/static/img/screen_block_lost.jpg\"){kind=link}
![http://i.imgur.com/uONpy.png](\"http://i.imgur.com/uONpy.png\"){kind=link}
![http://static/img264.imageshack.us/static/img264/2526/85647303.png](\"http://static/img264.imageshack.us/static/img264/2526/85647303.png\"){kind=link}
![http://static/img146.imageshack.us/static/img146/723/90684161.png](\"http://static/img146.imageshack.us/static/img146/723/90684161.png\"){kind=link}
![http://static/img525.imageshack.us/static/img525/6200/90747626.png](\"http://static/img525.imageshack.us/static/img525/6200/90747626.png\"){kind=link}
![http://static/img263.imageshack.us/static/img263/6645/68205424.png](\"http://static/img263.imageshack.us/static/img263/6645/68205424.png\"){kind=link}