Bitcoin mailing list archives (2008-2015) Retrieved from http://sourceforge.net/p/bitcoin/mailman/bitcoin-list/?viewmonth=AAAAMM using Internet Archive (web.archive.org) on May 6, 2022 --- [bitcoin-list] Welcome From: Satoshi Nakamoto - 2008-12-10 17:00:23 Welcome to the Bitcoin mailing list! --- [bitcoin-list] Crash in bitcoin 0.1.0 From: Hal Finney - 2009-01-10 19:13:18 Attachments: debug.log Hi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and it crashed. I am running on an up to date version of XP, SP3. The debug.log output is attached. There was also a file db.log but it was empty. The crash allowed me to start up a debugger, but there were no symbols. The exception was at address 00930AF7. The displayed call stack was 942316 called by 508936. When I have a chance, I'll try building it, although it looks like it would take me a while to acquire all the dependencies. Hal --- Re: [bitcoin-list] Bitcoin v0.1 released From: - 2009-01-11 03:16:43 Satoshi Nakamoto writes: > Announcing the first release of Bitcoin, a new electronic cash > system that uses a peer-to-peer network to prevent double-spending. > It's completely decentralized with no server or central authority. > > See bitcoin.org for screenshots. > > Download link: > http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar Congratulations to Satoshi on this first alpha release. I am looking forward to trying it out. > Total circulation will be 21,000,000 coins. It'll be distributed > to network nodes when they make blocks, with the amount cut in half > every 4 years. > > first 4 years: 10,500,000 coins > next 4 years: 5,250,000 coins > next 4 years: 2,625,000 coins > next 4 years: 1,312,500 coins > etc... It's interesting that the system can be configured to only allow a certain maximum number of coins ever to be generated. I guess the idea is that the amount of work needed to generate a new coin will become more difficult as time goes on. One immediate problem with any new currency is how to value it. Even ignoring the practical problem that virtually no one will accept it at first, there is still a difficulty in coming up with a reasonable argument in favor of a particular non-zero value for the coins. As an amusing thought experiment, imagine that Bitcoin is successful and becomes the dominant payment system in use throughout the world. Then the total value of the currency should be equal to the total value of all the wealth in the world. Current estimates of total worldwide household wealth that I have found range from $100 trillion to $300 trillion. With 20 million coins, that gives each coin a value of about $10 million. So the possibility of generating coins today with a few cents of compute time may be quite a good bet, with a payoff of something like 100 million to 1! Even if the odds of Bitcoin succeeding to this degree are slim, are they really 100 million to one against? Something to think about... Hal --- [bitcoin-list] Bitcoin v0.1.2 now available From: Satoshi Nakamoto - 2009-01-11 22:32:18 Bitcoin v0.1.2 is now available for download. See http://www.bitcoin.org for the download link. All the problems I've been finding are in the code that automatically finds and connects to other nodes, since I wasn't able to test it in the wild until now. There are many more ways for connections to get screwed up on the real Internet. Bugs fixed: - Fixed various problems that were making it hard for new nodes to see other nodes to connect to. - If you're behind a firewall, it could only receive one connection, and the second connection would constantly disconnect and reconnect. These problems are kind of screwing up the network and will get worse as more users arrive, so please make sure to upgrade. Satoshi Nakamoto --- [bitcoin-list] Bitcoin v0.1 Alpha release notes From: Satoshi Nakamoto - 2009-01-12 20:20:47 Release notes for Bitcoin v0.1 Alpha Bitcoin is a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority. You can find screenshots and the download link at: http://www.bitcoin.org Windows only for now. Open source C++ code is included. - Unpack the files into a directory - Run BITCOIN.EXE - It automatically connects to other nodes If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections. The software is still alpha and experimental. There's no guarantee the system's state won't have to be restarted at some point if it becomes necessary, although I've done everything I can to build in extensibility and versioning. You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent. There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections. Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years. first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins etc... When that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free. Satoshi Nakamoto --- [bitcoin-list] Bitcoin v0.1.3 From: Satoshi Nakamoto - 2009-01-12 22:48:23 It looks like we're through with the worst of the Internet connection issues. 0.1.3 fixed a problem where your node's communications could go dead after a while. The network is running much more smoothly now with this version. If you've successfully generated a block, you've seen it has a maturation countdown before you can spend it. Once it matures, the Credit column will change from 0.00 to 50.00. For a block to be valid, it has to be broadcasted to the network and get into the block chain, which is why Generate does not run if you're not connected. If you generated a block without being connected, the network wouldn't know about it and would continue building the chain without it, leaving it behind, and the maturation countdown would change to "(not accepted)" when your node sees that it wasn't used. If you subtract 1 from the status column, that's how many blocks have been chained after yours. Satoshi Nakamoto --- Re: [bitcoin-list] Bitcoin v0.1 released From: Satoshi Nakamoto - 2009-01-16 18:35:32 > Dustin D. Trammell wrote: > > Satoshi Nakamoto wrote: > > You know, I think there were a lot more people interested in the 90's, > > but after more than a decade of failed Trusted Third Party based systems > > (Digicash, etc), they see it as a lost cause. I hope they can make the > > distinction that this is the first time I know of that we're trying a > > non-trust-based system. > > Yea, that was the primary feature that caught my eye. The real trick > will be to get people to actually value the BitCoins so that they become > currency. I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite. It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. "Send X bitcoins to my priority hotline at this IP and I'll read the message personally." Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial. It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. Satoshi Nakamoto http://www.bitcoin.org --- [bitcoin-list] Problems From: Nicholas Bohm - 2009-01-25 10:17:52 I have had a couple of problems running bitcoin: is this an appropriate list for reporting them (with about 70kb of attachments)? Nicholas Bohm -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285 (+44 1279 870285) Mobile 07715 419728 (+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF --- Re: [bitcoin-list] Problems From: Satoshi Nakamoto - 2009-01-25 16:45:25 From: Nicholas Bohm 2009-01-25 10:17 > I have had a couple of problems running bitcoin: is this an appropriate > list for reporting them (with about 70kb of attachments)? What's the problem you're having? If you send me your debug.log file directly (best not to send attachments to the list), I can take a look at what's happening. Satoshi Nakamoto bitcoin-help at vistomail dot com --- [bitcoin-list] Bitcoin works with Wine / Ubuntu From: Jeff Kane - 2009-01-30 02:39:29 Just an FYI that Bitcoin 0.1.3 works fine on Ubuntu 8.10 running Wine 1.0.1 Let me know if you have any questions. Jeff -- ~~~~~~~~~~~~~~~~~~~ Jeff Kane kanegs@... ~~~~~~~~~~~~~~~~~~~ --- [bitcoin-list] Bitcoin v0.1.5 released From: Satoshi Nakamoto - 2009-02-04 19:46:04 Version 0.1.5 is now available. It includes the fix for the problem Nicholas had, checking for disk full and changes to try to improve things that were confusing. Special thanks to Nicholas and Dustin for all their help and feedback! Download link: http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441 Changes: - disk full warning - fixed a bug that could occur if dns lookup failed - prevent entering your own address in the address book, which confusingly changed the label for your own address - moved change address button to menu under options - tweaks to make it get connected faster - close sockets on exit - created minimum fee for transactions less than 1 cent - hid the transaction-type selection box that only had one choice - cleaned up ParseMoney a little - slightly cleaner reformatting of message text - changed the font in transaction details dialog - added some explanation text to transaction details for generated coins - reworded the description for transactions received with bitcoin address Satoshi Nakamoto http://www.bitcoin.org --- [bitcoin-list] Bitcoin v0.1.5 released From: Nicholas Bohm - 2009-02-18 14:55:50 Version 0.1.5 seems to be running trouble free. I have a list of 201 transactions, I've accumulated about bc8550. Transfers in and out seem to work fine (after a bit of head-scratching to understand the labelling of incoming transactions). What's next? Nicholas Bohm -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285 (+44 1279 870285) Mobile 07715 419728 (+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF --- Re: [bitcoin-list] Bitcoin v0.1.5 released From: Satoshi Nakamoto - 2009-02-22 17:47:52 > What's next? The next thing for v0.1.6 is to take advantage of multiple processors to generate blocks. Currently it only starts one thread. If you have a multi-core processor like a Core Duo or Quad this will double or quadruple your production. Later I want to add interfaces to make it really easy to integrate into websites from any server side language. Satoshi http://www.bitcoin.org --- Re: [bitcoin-list] Bitcoin v0.1.5 released From: Hal Finney - 2009-02-27 20:00:12 On Sun, Feb 22, 2009 at 9:35 AM, Satoshi Nakamoto wrote: >> What's next? > > The next thing for v0.1.6 is to take advantage of multiple > processors to generate blocks. Currently it only starts one > thread. If you have a multi-core processor like a Core Duo or > Quad this will double or quadruple your production. That sounds good. I'd also like to be able to run multiple coin/block generators on multiple machines, all behind a single NAT address. I haven't tried this yet so I don't know if it works on the current software. BTW I don't remember if we talked about this, but the other day some people were mentioning secure timestamping. You want to be able to prove that a certain document existed at a certain time in the past. Seems to me that bitcoin's stack of blocks would be perfect for this. > Later I want to add interfaces to make it really easy to integrate > into websites from any server side language. Right, and I'd like to see more of a library interface that could be called from programming or scripting languages, on the client side as well. Hal --- Re: [bitcoin-list] Bitcoin v0.1.5 released From: Satoshi Nakamoto - 2009-03-04 16:59:12 Hal Finney wrote: > That sounds good. I'd also like to be able to run multiple coin/block > generators on multiple machines, all behind a single NAT address. I > haven't tried this yet so I don't know if it works on the current > software. The current version will work fine. They'll each connect over the Internet, while incoming connections only come to the host that port 8333 is routed to. As an optimisation, I'll make a switch "-connect=1.2.3.4" to make it only connect to a specific address. You could make your extra nodes connect to your primary, and only the primary connects over the Internet. It doesn't really matter for now, since the network would have to get huge before the bandwidth is anything more than trivial. > BTW I don't remember if we talked about this, but the other day some > people were mentioning secure timestamping. You want to be able to > prove that a certain document existed at a certain time in the past. > Seems to me that bitcoin's stack of blocks would be perfect for this. Indeed, Bitcoin is a distributed secure timestamp server for transactions. A few lines of code could create a transaction with an extra hash in it of anything that needs to be timestamped. I should add a command to timestamp a file that way. > > > Later I want to add interfaces to make it really easy to integrate > > > into websites from any server side language. > > Right, and I'd like to see more of a library interface that could be > called from programming or scripting languages, on the client side as > well. Exactly. Satoshi Nakamoto http://www.bitcoin.org --- [bitcoin-list] Bitcoin website update From: - 2009-06-13 06:41:12 The new Bitcoin website/portal is up at bitcoin.sourceforge.net. Forums and a wiki are included, so you're welcome to join discussion and wiki documentation. Martti Malmi Bitcoin Web Developer --- [bitcoin-list] new user From: tyler gillies - 2009-08-15 11:33:44 i just downloaded bitcoin, epic piece of software. the digital cash age has arrived -- http://www.onechristbody.com --- [bitcoin-list] Does Bitcoin Crash in Windows? From: Liberty Standard - 2009-10-23 11:50:10 Do you Windows users experience occasional Bitcoin crashes? Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was just wondering whether this is a Wine issue or a Bitcoin issue. I speculate it might have something to do with how many Bitcoins I have since it would crash less when I had less bitcoins and now crashes more now that I have more bitcoins. It makes me hesitant to send my balance of bitcoins to my fresh Bitcoin installation. But this might just be my imagination since it has crashed a few times after installing Bitcoin afresh. The following four lines print from the terminal when I start Bitcoin. fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub I previously wasn't starting Bitcoin from the terminal, so I don't know what gets printed out when it crashes, but I'll reply with the results the next time it crashes. While Bitcoin first downloads previously completed blocks, the file debug.log grows grows to 17.4 MB and then stops growing. I imagine it will continue to grow as more bitcoins are completed. ~NewLibertyStandard~ --- [bitcoin-list] Website Down From: Liberty Standard - 2009-10-23 11:59:34 In case you weren't aware, the Bitcoin website is down. http://bitcoin.sourceforge.net/ ----- You are running bitweaver in TEST mode * Click here to log a bug, if this appears to be an error with the application. * Go here to begin the installation process, if you haven't done so already. * To hide this message, please set the IS_LIVE constant to TRUE in your kernel/config_inc.php file. --- Re: [bitcoin-list] Does Bitcoin Crash in Windows? From: Satoshi Nakamoto - 2009-10-23 23:57:51 Liberty Standard wrote: > Do you Windows users experience occasional Bitcoin crashes? > Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was > just wondering whether this is a Wine issue or a Bitcoin issue. I haven't had any reports of crashes in v0.1.5. It's been rock solid for me on Windows. I think it must be Wine related. If you get another crash in Wine and it prints anything on the terminal, e-mail me and I may be able to figure out what happened, maybe something I can work around. Martti and I have been working on a new version to release soon and it would be nice to get any Wine fixes in there. > The following four lines print from the terminal when I start Bitcoin. > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub Those don't look like anything to worry about. Probably functions unimplemented by Wine that are harmlessly stubbed out. > I previously wasn't starting Bitcoin from the terminal, so I don't know what > gets printed out when it crashes, but I'll reply with the results the next > time it crashes. > > While Bitcoin first downloads previously completed blocks, the file > debug.log grows grows to 17.4 MB and then stops growing. I imagine it will > continue to grow as more bitcoins are completed. You can delete debug.log occasionally if you don't want to take the disk space. It's just status messages that help with debugging. bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing some maintenance. Satoshi --- Re: [bitcoin-list] Does Bitcoin Crash in Windows? From: Mike Hearn - 2009-10-24 15:05:07 > > > The following four lines print from the terminal when I start Bitcoin. > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub > That just means it failed to create a minidump, so yeah, not the cause of the crash. To find the cause of the crash you'd need to run it with a +seh,+relay trace and find out what the app was doing before it crashed, or look in the bitcoin logs. --- Re: [bitcoin-list] Does Bitcoin Crash in Windows? From: Eugen Leitl - 2009-10-26 12:46:27 On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote: > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing Doesn't work right now. > some maintenance. Still no .deb packages for Bitcoin? -- Eugen* Leitl leitl; http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --- [bitcoin-list] Bitcoin 0.2 released From: Satoshi Nakamoto - 2009-12-17 06:52:09 Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New 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 We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto --- [bitcoin-list] New User From: Dan Mahoney, System Admin - 2010-05-21 02:23:14 Hello there, I'm a new bitcoin user, and plan on accepting bitcoin currency for web-hosting that I run, because it sounds cool. The build requirements for the main bitcoin app look a little painful, tho. Is anyone working on CLI tools? At the base, it's just manipulating a database, and running a computational program, right -- I don't see the need for the list of dependencies ubuntu tried to install when I followed the build instructions. Also, having a native linux package would probably help a lot. Has anyone built such a package? -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- --- Re: [bitcoin-list] New User From: Dan Mahoney, System Admin - 2010-06-28 07:13:49 On Thu, 20 May 2010, Dan Mahoney, System Admin wrote: > Hello there, > > I'm a new bitcoin user, and plan on accepting bitcoin currency for > web-hosting that I run, because it sounds cool. > > The build requirements for the main bitcoin app look a little painful, > tho. Is anyone working on CLI tools? At the base, it's just manipulating > a database, and running a computational program, right -- I don't see the > need for the list of dependencies ubuntu tried to install when I followed > the build instructions. > > Also, having a native linux package would probably help a lot. Has anyone > built such a package? Wow, not one response in months. Amazing. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- --- Re: [bitcoin-list] New User From: - 2010-06-28 08:48:54 Hi, Project communications have mostly moved to the Bitcoin Forum at http://www.bitcoin.org/smf/. Maybe this list is not needed anymore? A headless version with CLI tools will be available in the next release, which will be out soon. There's a Linux binary, but no deb or rpm packages so far. It would be cool indeed if you could download Bitcoin from a package repository. -Martti Lainaus "Dan Mahoney, System Admin" : > On Thu, 20 May 2010, Dan Mahoney, System Admin wrote: > >> Hello there, >> >> I'm a new bitcoin user, and plan on accepting bitcoin currency for >> web-hosting that I run, because it sounds cool. >> >> The build requirements for the main bitcoin app look a little painful, >> tho. Is anyone working on CLI tools? At the base, it's just manipulating >> a database, and running a computational program, right -- I don't see the >> need for the list of dependencies ubuntu tried to install when I followed >> the build instructions. >> >> Also, having a native linux package would probably help a lot. Has anyone >> built such a package? > > Wow, not one response in months. Amazing. > > -Dan > > > -- > > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] New User From: Eugen Leitl - 2010-06-28 10:49:33 On Mon, Jun 28, 2010 at 11:25:21AM +0300, mmalmi@... wrote: > Hi, > > Project communications have mostly moved to the Bitcoin Forum at > http://www.bitcoin.org/smf/. Maybe this list is not needed anymore? I thought the project was dead. I don't do forums, only lists. You can kill the forum and keep the list as far as I'm concerned. > A headless version with CLI tools will be available in the next > release, which will be out soon. There's a Linux binary, but no deb or > rpm packages so far. It would be cool indeed if you could download > Bitcoin from a package repository. > > -Martti > > Lainaus "Dan Mahoney, System Admin" : > > > On Thu, 20 May 2010, Dan Mahoney, System Admin wrote: > > > >> Hello there, > >> > >> I'm a new bitcoin user, and plan on accepting bitcoin currency for > >> web-hosting that I run, because it sounds cool. > >> > >> The build requirements for the main bitcoin app look a little painful, > >> tho. Is anyone working on CLI tools? At the base, it's just manipulating > >> a database, and running a computational program, right -- I don't see the > >> need for the list of dependencies ubuntu tried to install when I followed > >> the build instructions. > >> > >> Also, having a native linux package would probably help a lot. Has anyone > >> built such a package? > > > > Wow, not one response in months. Amazing. > > > > -Dan > > > > > > -- > > > > > > --------Dan Mahoney-------- > > Techie, Sysadmin, WebGeek > > Gushi on efnet/undernet IRC > > ICQ: 13735144 AIM: LarpGM > > Site: http://www.gushi.org > > --------------------------- > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > _______________________________________________ > > bitcoin-list mailing list > > bitcoin-list@... > > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list -- Eugen* Leitl leitl; http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --- Re: [bitcoin-list] New User From: Liberty Standard - 2010-06-28 11:09:13 Well then perhaps you can spearhead email list maintenance; welcome new folk and keep the list alive and such. Welcome to the Bitcoin project and thank you for volunteering to contribute. ;-) On 6/28/10, Eugen Leitl wrote: > On Mon, Jun 28, 2010 at 11:25:21AM +0300, mmalmi@... wrote: >> Hi, >> >> Project communications have mostly moved to the Bitcoin Forum at >> http://www.bitcoin.org/smf/. Maybe this list is not needed anymore? > > I thought the project was dead. > > I don't do forums, only lists. You can kill the forum and keep the > list as far as I'm concerned. > >> A headless version with CLI tools will be available in the next >> release, which will be out soon. There's a Linux binary, but no deb or >> rpm packages so far. It would be cool indeed if you could download >> Bitcoin from a package repository. >> >> -Martti >> >> Lainaus "Dan Mahoney, System Admin" : >> >> > On Thu, 20 May 2010, Dan Mahoney, System Admin wrote: >> > >> >> Hello there, >> >> >> >> I'm a new bitcoin user, and plan on accepting bitcoin currency for >> >> web-hosting that I run, because it sounds cool. >> >> >> >> The build requirements for the main bitcoin app look a little painful, >> >> tho. Is anyone working on CLI tools? At the base, it's just >> >> manipulating >> >> a database, and running a computational program, right -- I don't see >> >> the >> >> need for the list of dependencies ubuntu tried to install when I >> >> followed >> >> the build instructions. >> >> >> >> Also, having a native linux package would probably help a lot. Has >> >> anyone >> >> built such a package? >> > >> > Wow, not one response in months. Amazing. >> > >> > -Dan >> > >> > >> > -- >> > >> > >> > --------Dan Mahoney-------- >> > Techie, Sysadmin, WebGeek >> > Gushi on efnet/undernet IRC >> > ICQ: 13735144 AIM: LarpGM >> > Site: http://www.gushi.org >> > --------------------------- >> > >> > >> > ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Sprint >> > What will you do first with EVO, the first 4G phone? >> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> > _______________________________________________ >> > bitcoin-list mailing list >> > bitcoin-list@... >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-list >> > >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> bitcoin-list mailing list >> bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -- > Eugen* Leitl leitl; http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] New User From: Eugen Leitl - 2010-06-28 11:50:02 On Mon, Jun 28, 2010 at 05:09:04AM -0600, Liberty Standard wrote: > Well then perhaps you can spearhead email list maintenance; welcome Please do not top-post. It has been a while since I had a look at BitCoin. There's still no Debian package, right? > new folk and keep the list alive and such. Welcome to the Bitcoin > project and thank you for volunteering to contribute. ;-) I'm afraid the only way how I'd contribute would be to run a few nodes once a Debian (amd64) package is there, and report bugs, if any. -- Eugen* Leitl leitl; http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --- Re: [bitcoin-list] New User From: Eugen Leitl - 2010-06-28 12:46:15 On Mon, Jun 28, 2010 at 06:11:28AM -0600, Liberty Standard wrote: > Sorry, I'm not really familiar with email list etiquette. I figured > that since I received the previous messages, that everyone must have > gotten them. That's why I thought it was OK to send to that address. I > would really rather this apology go to everyone, so may I top post it? > > There is not a Debian package yet, but the next release which will be > out soon will include statically linked GUI and CL versions for x86 That is great to hear. So I can run the GUI one one host, connecting to the binary as a daemon on another, right? A lot of servers are headless, so an ssh connection is the only reliable minimal assumption. I could in principle tunnel the GUI over an X tunnel over ssh, but I'd rather not. > 32-bit and 64-bit. Bugs reports are very welcome. I look forward to > your contributions at some point in the future. -- Eugen* Leitl leitl; http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --- Re: [bitcoin-list] New User From: StealthMonger - 2010-06-28 14:44:58 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mmalmi@... writes: > Project communications have mostly moved to the Bitcoin Forum at > http://www.bitcoin.org/smf/. Maybe this list is not needed anymore? An untraceable pseudonym can be a contributing member of a list. How could it be a member of a forum? Untraceability is maintained using chains of anonymizing remailers. Authentication is contained in the message and does not depend on any real-time end-to-end connection. It's "message-based security" rather than "connection-based security". Is there a way for an untraceable pseudonym to join a forum? Don't answer "Tor". Tor is traceable. According to its own documentation ... for low-latency systems like Tor, end-to-end traffic correlation attacks [8, 21, 31] allow an attacker who can observe both ends of a communication to correlate packet timing and volume, quickly linking the initiator to her destination. http://tor.eff.org/cvs/tor/doc/design-paper/challenges.pdf -- StealthMonger -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. mailto:stealthsuite@... Finger for key. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ ; iEYEARECAAYFAkwokhAACgkQDkU5rhlDCl41XQCeKl8g/VT2Hjkl1eyKRHYVWqKx oNIAoJ2luovjJDOjd9gJlGDNgYPNBLTR =Odfe -----END PGP SIGNATURE----- --- Re: [bitcoin-list] New User From: James A. Donald - 2010-06-30 22:29:16 On 2010-06-28 4:57 PM, Dan Mahoney, System Admin wrote: > On Thu, 20 May 2010, Dan Mahoney, System Admin wrote: > >> Hello there, >> >> I'm a new bitcoin user, and plan on accepting bitcoin currency for >> web-hosting that I run, because it sounds cool. >> >> The build requirements for the main bitcoin app look a little painful, >> tho. Is anyone working on CLI tools? At the base, it's just manipulating >> a database, and running a computational program, right -- I don't see the >> need for the list of dependencies ubuntu tried to install when I followed >> the build instructions. >> >> Also, having a native linux package would probably help a lot. Has anyone >> built such a package? > > Wow, not one response in months. Amazing. Yes - bitcoin kind of went dead. The trouble is that bitcoin, to be useful, needs an ecology of users. Long ago, I had an argument with the guy who designed it about scaling. I heard no more of it - of course with no one using it, scaling is not a problem. I do not know if the software is in useable condition, or has been tested for scaleability. Bitcoin is a coordination mechanism between lots of people, and we do not have lots of people - I do not see how to get there from here, and am not altogether sure that the software as written will work if we do get there. In order to be useful, needs to be integrated with a messaging and billing system, so that you can send messages containing bills or money. I am pretty sure that no such system exists, and it is no small amount of work to create it. It is a neat idea, to solve a problem > > -Dan > > --- Re: [bitcoin-list] New User From: James A. Donald - 2010-06-30 19:05:02 On 2010-06-30 1:56 PM, James A. Donald wrote: > Bitcoin is a coordination mechanism between lots of people, and we do > not have lots of people - I do not see how to get there from here, and > am not altogether sure that the software as written will work if we do > get there. > > In order to be useful, needs to be integrated with a messaging and > billing system, so that you can send messages containing bills or money. > I am pretty sure that no such system exists, and it is no small amount > of work to create it.\ I did not mean to sound so negative. If we manage to get there from here, this is a huge win for liberty - but it is a long treck, and I have been busy with another project. --- Re: [bitcoin-list] New User From: Eugen Leitl - 2010-06-30 19:19:50 On Wed, Jun 30, 2010 at 02:31:29PM +1000, James A. Donald wrote: > I did not mean to sound so negative. If we manage to get there from > here, this is a huge win for liberty - but it is a long treck, and I > have been busy with another project. I think bitcoin is sufficiently worthwhile to remove as much friction as possible, and increase number of applications which can use it for online transactions. -- Eugen* Leitl leitl; http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --- [bitcoin-list] Bitcoin 0.3 released! From: Satoshi Nakamoto - 2010-07-06 21:53:53 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, and read the forum to find out more. --- [bitcoin-list] [PATCH] Batch commit blocks to reduce syncs From: Bryan Donlan - 2010-07-13 04:07:46 Previously, committing a block would require as many as four syncs: * A sync to the block file itself * A sync to open the block index database * A sync to commit the block index transaction (+1 for each subtxn) * A sync to close the block index transaction When this is performed for every block, and you have 60k+ to commit, these syncs take a significant amount of time. This patch queues blocks to be committed in a seperate thread, once every second. This commit performs a single commit/sync at the very end of the process, greatly reducing the amount of time spent syncing, without compromising data integrity. Signed-off-by: Bryan Donlan --- For your convenience, a web code-review page is also available here: http://codereview.appspot.com/1820042 db.h | 7 +++- main.cpp | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++----------- main.h | 14 ++---- net.cpp | 8 +++- 4 files changed, 134 insertions(+), 37 deletions(-) diff --git a/db.h b/db.h index 29ff199..68102ad 100644 --- a/db.h +++ b/db.h @@ -223,8 +223,13 @@ public: return false; if (vTxn.empty()) return false; - int ret = vTxn.back()->commit(0); + DbTxn *txn = vTxn.back(); vTxn.pop_back(); + + // Only sync if this is the root transaction; for nested txns + // the root will handle the sync for us + int ret = txn->commit(vTxn.size() ? DB_TXN_NOSYNC : DB_TXN_SYNC); + return (ret == 0); } diff --git a/main.cpp b/main.cpp index 803548e..f9fffb1 100644 --- a/main.cpp +++ b/main.cpp @@ -21,6 +21,7 @@ unsigned int nTransactionsUpdated = 0; map mapNextTx; map mapBlockIndex; +map mapBlockPending; const uint256 hashGenesisBlock("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"); CBlockIndex* pindexGenesisBlock = NULL; int nBestHeight = -1; @@ -1189,7 +1190,7 @@ bool Reorganize(CTxDB& txdb, CBlockIndex* pindexNew) } -bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos) +bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos, CTxDB &txdb) { // Check for duplicate uint256 hash = GetHash(); @@ -1209,7 +1210,6 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos) pindexNew->nHeight = pindexNew->pprev->nHeight + 1; } - CTxDB txdb; txdb.TxnBegin(); txdb.WriteBlockIndex(CDiskBlockIndex(pindexNew)); @@ -1232,7 +1232,6 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos) delete pindexNew; return error("AddToBlockIndex() : ConnectBlock failed"); } - txdb.TxnCommit(); pindexNew->pprev->pnext = pindexNew; // Delete redundant memory transactions @@ -1259,7 +1258,6 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos) } txdb.TxnCommit(); - txdb.Close(); if (pindexNew == pindexBest) { @@ -1322,6 +1320,9 @@ bool CBlock::AcceptBlock() if (mapBlockIndex.count(hash)) return error("AcceptBlock() : block already in mapBlockIndex"); + if (mapBlockPending.count(hash)) + return error("AcceptBlock() : block already in mapBlockPending"); + // Get prev block index map::iterator mi = mapBlockIndex.find(hashPrevBlock); if (mi == mapBlockIndex.end()) @@ -1341,6 +1342,16 @@ bool CBlock::AcceptBlock() if (nBits != GetNextWorkRequired(pindexPrev)) return error("AcceptBlock() : incorrect proof of work"); + mapBlockPending[hash] = this; + return true; +} + +bool CBlock::CommitBlock(CTxDB &txdb) +{ + uint256 hash = GetHash(); + assert(mapBlockPending.count(hash)); + assert(mapBlockPending[hash] == this); + // Write block to history file if (!CheckDiskSpace(::GetSerializeSize(*this, SER_DISK))) return error("AcceptBlock() : out of disk space"); @@ -1348,7 +1359,7 @@ bool CBlock::AcceptBlock() unsigned int nBlockPos; if (!WriteToDisk(!fClient, nFile, nBlockPos)) return error("AcceptBlock() : WriteToDisk failed"); - if (!AddToBlockIndex(nFile, nBlockPos)) + if (!AddToBlockIndex(nFile, nBlockPos, txdb)) return error("AcceptBlock() : AddToBlockIndex failed"); // Relay inventory, but don't relay old inventory during initial block download @@ -1358,6 +1369,22 @@ bool CBlock::AcceptBlock() if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 55000)) pnode->PushInventory(CInv(MSG_BLOCK, hash)); + // Recursively process any orphan blocks that depended on this one + uint256 hashPrev = GetHash(); + for (multimap::iterator mi = mapOrphanBlocksByPrev.lower_bound(hashPrev); + mi != mapOrphanBlocksByPrev.upper_bound(hashPrev); + ++mi) + { + CBlock* pblockOrphan = (*mi).second; + if (pblockOrphan->AcceptBlock()) { + cerr << "Queued orphan: " << pblockOrphan->GetHash().GetHex() << endl; + } + mapOrphanBlocks.erase(pblockOrphan->GetHash()); + } + mapOrphanBlocksByPrev.erase(hashPrev); + + delete this; + return true; } @@ -1396,26 +1423,6 @@ bool ProcessBlock(CNode* pfrom, CBlock* pblock) delete pblock; return error("ProcessBlock() : AcceptBlock FAILED"); } - delete pblock; - - // Recursively process any orphan blocks that depended on this one - vector vWorkQueue; - vWorkQueue.push_back(hash); - for (int i = 0; i < vWorkQueue.size(); i++) - { - uint256 hashPrev = vWorkQueue[i]; - for (multimap::iterator mi = mapOrphanBlocksByPrev.lower_bound(hashPrev); - mi != mapOrphanBlocksByPrev.upper_bound(hashPrev); - ++mi) - { - CBlock* pblockOrphan = (*mi).second; - if (pblockOrphan->AcceptBlock()) - vWorkQueue.push_back(pblockOrphan->GetHash()); - mapOrphanBlocks.erase(pblockOrphan->GetHash()); - delete pblockOrphan; - } - mapOrphanBlocksByPrev.erase(hashPrev); - } printf("ProcessBlock: ACCEPTED\n"); return true; @@ -1523,6 +1530,14 @@ FILE* AppendBlockFile(unsigned int& nFileRet) nFileRet = nCurrentBlockFile; return file; } + // If we need to rotate to a new block file, the commit thread + // may not be able to sync the old file. So sync it now. +#ifdef __WXMSW__ + _commit(_fileno(file)); +#else + fsync(fileno(file)); +#endif + fclose(file); nCurrentBlockFile++; } @@ -1597,8 +1612,13 @@ bool LoadBlockIndex(bool fAllowNew) unsigned int nBlockPos; if (!block.WriteToDisk(!fClient, nFile, nBlockPos)) return error("LoadBlockIndex() : writing genesis block to disk failed"); - if (!block.AddToBlockIndex(nFile, nBlockPos)) + + CTxDB txdb; + + if (!block.AddToBlockIndex(nFile, nBlockPos, txdb)) return error("LoadBlockIndex() : genesis block not accepted"); + + txdb.Close(); } return true; @@ -1688,13 +1708,83 @@ void PrintBlockTree() } +////////////////////////////////////////////////////////////////////////////// +// +// Block writeback thread +// + +void WritebackNow() +{ + CRITICAL_BLOCK(cs_main) + { + map::iterator it; + + if (!mapBlockPending.size()) + return; + + cerr << "WRITEBACK PENDING: " << mapBlockPending.size() << endl; + + CTxDB txdb; + txdb.TxnBegin(); + + int writebackct = 0; + while (mapBlockPending.size()) { + it = mapBlockPending.begin(); + cerr << "TRYING TO COMMIT " << it->first.GetHex() << " (block " << it->second->GetHash().GetHex() << ")\n"; + it->second->CommitBlock(txdb); + mapBlockPending.erase(it); + writebackct++; + } + unsigned int unused; + FILE *fileout = AppendBlockFile(unused); + // Sync the new blocks to disk +#ifdef __WXMSW__ + _commit(_fileno(fileout)); +#else + fsync(fileno(fileout)); +#endif + fclose(fileout); + // Commit the db only once the blocks themselves are safely on-disk + + txdb.TxnCommit(); + txdb.Close(); + } +} +void ThreadWriteback(void* parg) +{ + try + { + while (!fShutdown) + { + WritebackNow(); + Sleep(1000); + } + vnThreadsRunning[5]--; + } + catch (std::exception& e) { + vnThreadsRunning[5]--; + PrintException(&e, "ThreadWriteback()"); + } catch (...) { + vnThreadsRunning[5]--; + PrintException(NULL, "ThreadWriteback()"); + } + printf("Threadwriteback exiting\n"); +} +void StartWriteback() +{ + vnThreadsRunning[5]++; + if (!CreateThread(ThreadWriteback, NULL)) { + printf("FATAL: CreateThread(ThreadWriteback) failed!\n"); + abort(); + } +} ////////////////////////////////////////////////////////////////////////////// // diff --git a/main.h b/main.h index d8f257b..1e9f3c7 100644 --- a/main.h +++ b/main.h @@ -77,7 +77,10 @@ string SendMoneyToBitcoinAddress(string strAddress, int64 nValue, CWalletTx& wtx void GenerateBitcoins(bool fGenerate); void ThreadBitcoinMiner(void* parg); void BitcoinMiner(); +bool ProcessBlock(CNode* pfrom, CBlock* pblock); +void WritebackNow(); +void StartWriteback(); @@ -983,14 +986,6 @@ public: 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; } @@ -1044,9 +1039,10 @@ public: bool DisconnectBlock(CTxDB& txdb, CBlockIndex* pindex); bool ConnectBlock(CTxDB& txdb, CBlockIndex* pindex); bool ReadFromDisk(const CBlockIndex* blockindex, bool fReadTransactions=true); - bool AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos); + bool AddToBlockIndex(unsigned int nFile, unsigned int nBlockPos, CTxDB &txdb); bool CheckBlock() const; bool AcceptBlock(); + bool CommitBlock(CTxDB &txdb); }; diff --git a/net.cpp b/net.cpp index dc1debd..701ac79 100644 --- a/net.cpp +++ b/net.cpp @@ -1320,6 +1320,9 @@ void StartNode(void* parg) if (!CreateThread(ThreadMessageHandler, NULL)) printf("Error: CreateThread(ThreadMessageHandler) failed\n"); + // Writeback blocks + StartWriteback(); + // Generate coins in the background GenerateBitcoins(fGenerateBitcoins); @@ -1381,7 +1384,7 @@ bool StopNode() fShutdown = true; nTransactionsUpdated++; int64 nStart = GetTime(); - while (vnThreadsRunning[0] > 0 || vnThreadsRunning[2] > 0 || vnThreadsRunning[3] > 0 || vnThreadsRunning[4] > 0) + while (vnThreadsRunning[0] > 0 || vnThreadsRunning[2] > 0 || vnThreadsRunning[3] > 0 || vnThreadsRunning[4] > 0 || vnThreadsRunning[5] > 0) { if (GetTime() - nStart > 20) break; @@ -1392,10 +1395,13 @@ bool StopNode() if (vnThreadsRunning[2] > 0) printf("ThreadMessageHandler still running\n"); if (vnThreadsRunning[3] > 0) printf("ThreadBitcoinMiner still running\n"); if (vnThreadsRunning[4] > 0) printf("ThreadRPCServer still running\n"); + if (vnThreadsRunning[5] > 0) printf("ThreadWriteback still running\n"); while (vnThreadsRunning[2] > 0 || vnThreadsRunning[4] > 0) Sleep(20); Sleep(50); + WritebackNow(); + return true; } -- 1.7.0.4 --- [bitcoin-list] [PATCH] create obj and obj/nogui folders before use From: Jack L. - 2010-07-13 06:52:04 akefile.unix | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/makefile.unix b/makefile.unix index f6ca110..e2834b0 100644 --- a/makefile.unix +++ b/makefile.unix @@ -56,14 +56,17 @@ OBJS= \ obj/rpc.o \ obj/init.o -bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha.o +bitcoin: test -d obj || mkdir obj + $(OBJS) obj/ui.o obj/uibase.o obj/sha.o g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS) obj/nogui/%.o: %.cpp $(HEADERS) g++ -c $(CFLAGS) -DwxUSE_GUI=0 -o $@ lt; -bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha.o +bitcoind: test -d obj || mkdir obj + test -d obj/nogui || mkdir obj/nogui + $(OBJS:obj/%=obj/nogui/%) obj/sha.o g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ -l wx_baseud-2.9 $(LIBS) --- Re: [bitcoin-list] [PATCH] create obj and obj/nogui folders before use From: Bryan Donlan - 2010-07-13 13:59:49 On Tue, Jul 13, 2010 at 02:51, Jack L. wrote: > akefile.unix | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) Did you copy and paste this manually? Gmail will munge patches (replacing tabs with spaces, etc, which _will_ break makefiles) if you copypaste them. Use git format-patch and git send-email. > diff --git a/makefile.unix b/makefile.unix > index f6ca110..e2834b0 100644 > --- a/makefile.unix > +++ b/makefile.unix > @@ -56,14 +56,17 @@ OBJS= \ > obj/rpc.o \ > obj/init.o > > -bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha.o > +bitcoin: test -d obj || mkdir obj > + $(OBJS) obj/ui.o obj/uibase.o obj/sha.o > g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS) What kind of a dependency is 'test -d obj || mkdir obj'? I think you have your lines backwards... > obj/nogui/%.o: %.cpp $(HEADERS) > g++ -c $(CFLAGS) -DwxUSE_GUI=0 -o $@ lt; > > -bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha.o > +bitcoind: test -d obj || mkdir obj > + test -d obj/nogui || mkdir obj/nogui > + $(OBJS:obj/%=obj/nogui/%) obj/sha.o Same here. Moreover, creating the obj directory in the bitcoin or bitcoind rule is too late. They need to be created in the compilation rules (perhaps with a mkdir -p `dirname $@`) --- [bitcoin-list] Alert: upgrade to bitcoin 0.3.6 From: Satoshi Nakamoto - 2010-07-30 06:02:38 Please upgrade to 0.3.6 ASAP to get an important bugfix. See the bitcoin.org homepage for download links. --- [bitcoin-list] Patch submissions, bugtracker, development guidelines? From: Linus Lüssing - 2010-07-31 00:21:38 Dear all, I've been having a closer look at this project a couple of days ago and found it very, very interesting indeed. The main principles of bitcoin are well described in your paper, Satoshi, making it easy to get an overview of the concept and neat methods being used. I also liked it very much, that although the theory behind it is rather complex, the gui is very simplistic and easy to use, making it quite easy for a newcomer to get into the project :). Nevertheless, I already had some difficulties with the bitcoin software during those days. So what I wanted to know is, what is the prefered way to report problems? The forum seemed to be a little messy on first site and the irc is most of the time just kindergarten :). I also couldn't find a bugtracker yet, is there one around for this project somewhere by any chance? I also started looking a the code a little and the changelog history, as I guess it wouldn't be such a bad idea for having as many eyes on this code as possible for such an open source project with great potential, where some flaws could have have rather serious problems later because of real money being involved :). However, from time to time I found the changelog a little confusing, as it's not always clear on first sight, what might have been changed exactly or what the problem was before. Would you mind also keeping up the svn tagging (why did you stop tagging after 0.3.0 :)?)? I also can't tell what happened with 0.3.4 and 0.3.5 from the changelog and what happened to them. Finally, I'd like to know if there are any guidelines/rules for patch submissions (couldn't find a "How to contribute" page on the bitcoin.org website). Is there a prefered coding style for ensuring the readability of the code, even if more people were contributing? How is the docmentation being done? Is there a wiki page where other people could contribute to or read about some specifications, methods etc.? Okay guys, bitcoin is pretty awesome already and I'm astonished, that (after 7 months uptime?) bitcoin already works so well and seems to have quite a fanbase already :). It would be great if you could give me some hints about the development procedure here (and maybe publish something about that on the bitcoin.org site?), so that it'd be a little easier for other people to contribute and especially helping to stabilize the software a litte. Cheers, Linus --- [bitcoin-list] ALERT - we are investigating a problem From: Satoshi Nakamoto - 2010-08-15 20:38:33 *** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved. --- [bitcoin-list] Bitcoin 0.3.12 is released From: theymos - 2010-09-08 16:28:44 Someone on IRC said that they'd like to be notified of new versions through a mailing list, so I thought I'd start reposting Satoshi's version announcements here. Hopefully no one finds this annoying... http://www.bitcoin.org/smf/index.php?topic=999.0 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":,"message":}, which is the standard. See this thread: http://www.bitcoin.org/smf/index.php?topic=969.0 Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/ --- [bitcoin-list] Hello From: Mariusz Halnyski - 2010-09-14 11:48:46 Hello , I'm new in BTC. Anybody can tell me where is documentation of authorisation my transaction? I have coin (coin if proof by the creator=man who are operator of irc bitbot ;) ) but who prewent for my paiment. Can I pay 'my' coins several times? --- [bitcoin-list] Bitcoin 0.3.13 is released From: theymos - 2010-10-01 02:01:26 http://www.bitcoin.org/smf/index.php?topic=1327.0 Version 0.3.13 is now available. 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/ --- Re: [bitcoin-list] Bitcoin 0.3.13 is released From: Mariusz Halnyski - 2010-10-01 13:12:59 > Version 0.3.13 is now available. When you are able to add comments to the transaction? --- [bitcoin-list] Bitcoin 0.3.14 is released From: theymos - 2010-10-21 18:02:23 http://www.bitcoin.org/smf/index.php?topic=1528.0 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 --- More info about the key pool feature: http://www.bitcoin.org/smf/index.php?topic=1414.0 Now you only have to back up after every 100 sends, new addresses, generations, or transactions received by IP address. More info about RPC SSL: http://www.bitcoin.org/wiki/doku.php?id=rpcssl --- [bitcoin-list] Bitcoin 0.3.15 is released From: theymos - 2010-11-14 00:54:53 http://www.bitcoin.org/smf/index.php?topic=1780.0 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 --- [bitcoin-list] Bitcoin 0.3.17 is released From: theymos - 2010-11-26 05:36:12 Fixes not mentioned below: - Due to a problem in GetMyExternalIP, it was taking 5-10 extra minutes to connect to the network. - Efficiency in transaction processing while generating has been improved, which will reduce wasted CPU usage, especially for generators using several GPUs/CPUs. Some heavy GPU miners might have found themselves bound by CPU power. 0.3.16 (SVN revision 189) was never officially released. http://www.bitcoin.org/smf/index.php?topic=1946.0 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 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 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/ --- [bitcoin-list] Bitcoin 0.3.18 is released From: Satoshi Nakamoto - 2010-12-08 23:11:55 Version 0.3.18 is now available. 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://www.bitcoin.org/smf/index.php?topic=1886.0). - getaccountaddress - sendfrom - move - getbalance - listtransactions Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/ --- [bitcoin-list] Bitcoin 0.3.19 is released From: Satoshi Nakamoto - 2010-12-13 16:12:09 This is a minor release to add some DoS protection. Changes: - Added some DoS limits, though it's still far from DoS resistant. - Removed "safe mode" alerts. http://www.bitcoin.org/smf/index.php?topic=2228.0 Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/ --- [bitcoin-list] Bitcoin version 0.3.20.01 released From: Gavin Andresen - 2011-02-23 01:22:25 Binaries for Bitcoin version 0.3.20.01 are available at: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.20/ There were several changes and additions to the JSON remote-procedure-call interface; there are no significant user interface changes. See: http://www.bitcoin.org/smf/index.php?topic=3473.msg48839#msg48839 ... for details. This version does fix one significant denial-of-service attack (earlier versions of bitcoin could be caused to crash due to running out of memory by a remote attacker). SHA1-checksums for the binary files are: 7dfbc05b36112f59886a29f044cfd21c6c253169 bitcoin-0.3.20.01-linux.tar.gz 3fe4c5f2a5406322a2f116b30aefbd402b079940 bitcoin-0.3.20.01-win32-setup.exe dffb709a90a7abcff08c2ef1e79d3f9b54751786 bitcoin-0.3.20.01-win32.zip b540825d864e7561cc21465ad072fb299e0d817a bitcoin-0.3.20.01-macosx.zip Gavin Andresen gavinandresen@... --- [bitcoin-list] Bitcoin 0.4.0 released From: Gavin Andresen - 2011-09-23 16:31:38 Bitcoin version 0.4.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/ The main feature in this release is wallet private key encryption; you can set a passphrase that must be entered before sending coins. See below for more information; if you decide to encrypt your wallet, WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you forget or lose your wallet passphrase, you lose your bitcoins. Previous versions of bitcoin are unable to read encrypted wallets, and will crash on startup if the wallet is encrypted. Also note: bitcoin version 0.4 uses a newer version of Berkeley DB (bdb version 4.8) than previous versions (bdb 4.7). If you upgrade to version 0.4 and then revert back to an earlier version of bitcoin the it may be unable to start because bdb 4.7 cannot read bdb 4.8 "log" files. Notable bug fixes from version 0.3.24: -------------------------------------- Fix several bitcoin-becomes-unresponsive bugs due to multithreading deadlocks. Optimize database writes for large (lots of inputs) transactions (fixes a potential denial-of-service attack) Wallet Encryption ----------------- Bitcoin supports native wallet encryption so that people who steal your wallet file don't automatically get access to all of your Bitcoins. In order to enable this feature, chose "Encrypt Wallet" from the Options menu. You will be prompted to enter a passphrase, which will be used as the key to encrypt your wallet and will be needed every time you wish to send Bitcoins. If you lose this passphrase, you will lose access to spend all of the bitcoins in your wallet, no one, not even the Bitcoin developers can recover your Bitcoins. This means you are responsible for your own security, store your passphrase in a secure location and do not forget it. Remember that the encryption built into bitcoin only encrypts the actual keys which are required to send your bitcoins, not the full wallet. This means that someone who steals your wallet file will be able to see all the addresses which belong to you, as well as the relevant transactions, you are only protected from someone spending your coins. It is recommended that you backup your wallet file before you encrypt your wallet. To do this, close the Bitcoin client and copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/ on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on Windows Vista and 7 and /Documents and Settings/(user name)/Application Data/Bitcoin on Windows XP). Once you have copied that file to a safe location, reopen the Bitcoin client and Encrypt your wallet. If everything goes fine, delete the backup and enjoy your encrypted wallet. Note that once you encrypt your wallet, you will never be able to go back to a version of the Bitcoin client older than 0.4. Keep in mind that you are always responsible for your own security. All it takes is a slightly more advanced wallet-stealing trojan which installs a keylogger to steal your wallet passphrase as you enter it in addition to your wallet file and you have lost all your Bitcoins. Wallet encryption cannot keep you safe if you do not practice good security, such as running up-to-date antivirus software, only entering your wallet passphrase in the Bitcoin client and using the same passphrase only as your wallet passphrase. See the doc/README file in the bitcoin source for technical details of wallet encryption. Full changelog ("git shortlog --no-merges v0.3.24..") ----------------------------------------- Abraham Jewowich (1): Fix bug with accessing vchData[0] when vchData is empty. Fix typo in CBase58Data::CompareTo Alex B (2): Romanian translation added Spanish translation update Alex Waters (1): Updated readme file Daniel Folkinshteyn (1): Update the list of seednodes. Dawid Spiechowicz (1): added polish wallet encryption messages Dean Lee (1): Update to the Chinese Simp translation Dev Random (4): Linux gitian config with separate wxWidgets build Mingw gitian with separate wxWidgets and boost Mingw gitian build with deterministic bitcoin.exe by use of faketime Add Gitian Build descriptors for Boost and wxWidgets. Doug Huff (1): Make mlock() and munlock() portable to systems that require the address to be on a page boundary. Dylan Noblesmith (1): mlock() all private keys in memory Eric Hosmer (1): Added crypter to makefile.vc. Fabian H jr. (1): Updated checkpoints, maybe Tx fee should be reduced to 0.0001 from 0.0005 and maximum minimum tx should be 0.0010. Gavin Andresen (24): Do-nothing MapPort() ifndef USE_UPNP. fixes #450 Don't std::advance past beginning of transactions array. Fixes #465 Remove unused ScanMessageStart function Compile with DEBUG_LOCKORDER to detect inconsistent lock orderings that can cause deadlocks CHECKMULTISIG unit tests. Highlight mis-matching locks Fix rpc-hanging deadlocks Fixed potential deadlocks in GUI code. Also changed semantics of CWalletTx::GetTxTime(); now always returns the time the transaction was received by this node, not the average block time. And added information about -DDEBUG_LOCKORDER to coding.txt. Fix typo ("you own security") SetCrypted() obtains keystore lock, to be safe. Logic running with -keypool=0 was wrong (empty keys were being returned). Fixes #445 Fix RPC call name in error message. obtain cs_wallet mutex to protect vchDefaultKey Fixed regression I introduced: wallets with lots of transactions were unusable in GUI. Fix bad merge: getaccountaddress was broken for new accounts Give hard-coded seed nodes a random last-seen time, to randomize order they're tried. Do not try to download blockchain from 0.3.23 nodes If compiled -DDEBUG_LOCKORDER and run with -debug, print out every mutex lock/unlock (helpful for debugging something-is-holding-a-mutex-too-long problems) Stay connected to seed nodes; disconnecting causes problems if you are trying to make the initial blockchain download. Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain downloads; avoid them Bumped version numbers to 0.4.0rc1 Optimize database writes for transactions with lots of TxIns. Patch from ArtForz, who discovered the problem. Fix AddAddress cs_mapaddresses/db transaction deadlock Fix QA email address Giel van Schijndel (15): fix warning on 64bit systems: cast to pointer from integer of different size [-Wint-to-pointer-cast] fix warnings: expression result unused [-Wunused-value] fix warnings: using the result of an assignment as a condition without parentheses [-Wparentheses] fix warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] fix warning: X enumeration values not handled in switch [-Wswitch-enum] fix warning: unused variable 'X' [-Wunused-variable] fix warning: unused function 'SigIllHandlerSSE2' [-Wunused-function] fix warning: variable ‘nMinDepth’ set but not used [-Wunused-but-set-variable] fix warning: control reaches end of non-void function [-Wreturn-type] Make some global variables less-global (static) Cleanup makefiles such that diffs to them are smaller Move func 'REF' from util.h to serialize.h Start moving protocol-specific code to protocol.[ch]pp Move CAddress to protocol.[ch]pp Move CInv to protocol.[ch]pp Han Lin Yap (2): Comment "deprecated" Add a note to only include .po file Jay Weisskopf (4): Add logos/branding currently found on bitcoin.org into NSIS installer. Set default compression for NSIS installer to LZMA. Remove NSIS branding from bottom divider. Increase resolution of Windows icon. Jeff Garzik (8): Update CWallet::LoadWallet for proper return type. Bump version to 0.3.25 doc/README: word wrap into something readable CAddrDB::LoadAddresses: properly initialize CAddress src/makefile.unix: remove -DFOURWAYSSE2 Add reference python miner, in contrib/pyminer/ README.md: word wrap text file Revert "Define MSG_NOSIGNAL to 0 on platforms where it is unavailable." Jeroenz0r (1): Translation from "Open Bitcoin" to "Verstuur Bitcoins" JoelKatz (1): Fix UNIX-specific thread handle leak. Johannes Henninger (1): Identify as "Bitcoin + version number" when mapping UPnP port Luke Dashjr (7): Update nTime after nExtraNonce to avoid potential race (extraNonce being reset due to just-occurred time change after nTime is set) Reset extraNonce only every 15 seconds, just in case some miner is updating time himself and stuff Reset extraNonce only when prevBlock changes, so miners can continue updating the time on their work until it's stale Support for boost filesystem version 3 ignore stuff Save coinbase, not just extraNonce Bugfix: Use timestamp in coinbase rather than "bits", needed to ensure coinbase txn is unique even if address is the same Matt Corallo (35): Add minversion to wallet. Add wallet privkey encryption. Set the number of SHA512 rounds based on the speed of the computer. Push unlocked_until in getinfo. Dynamically remove/insert the Options for encryption in the menus. Add the walletlock RPC method to lock the wallet manually. Add Wallet Encryption section to README Use DB Transactions when encrypting wallet. This speeds up the encryption process significantly. Make an invalid addrIncoming so that old clients crash. Update makefile.linux-mingw to work with crypter and UPnP fix. Fix makefile.linux-mingw Fix crashes when a wallet is locked and GetReservedKey() is called Generate Warning when using default key. Fix Build in GetReservedKey() in wallet.cpp Fix bad return values in LoadWallet. Actually use mapAlreadyAskedFor. Fix EncryptKeys crash introduced by a9ba4710, identified by TD. Check for duplicate txins in CheckTransaction. Make it clear that setting proxy requires restart to fully apply. Don't listen if on TOR (resolves #441). Add missing include to serialize.h Add file for transaction tests. Cleanup test suite output to be more useful. Unify copyright notices. Missed a 'password' should be 'passphrase'. Fix incorrect RPC error messages Add specific wallet encryption details to doc/README Upgrade dependancies and tweak build process. Update binary mos to latest translations. Fix build process to actually work. Add binary mo for new translation. Update gitian build descriptors to produce proper builds. Update bitcoin icon to make nsis setup exe deterministic. Update binary mo to match latest po translation. Restructure gitian files and add download config files. Michael Bemmerl (4): Basically some grammatical fixes of the German translation. Added German wallet encryption messages translation. Changed Russian translation according to comment in issue 395 Updated German translation Michal Zima (1): Updated czech translation Nils Schneider (2): log low-level network messages only when fDebug is set missed printf in AbortMessage(); merged printfs in EndMessage Patrick Varilly (1): Single DB transaction for all addresses in a message Pieter Wuille (11): Prepare codebase for Encrypted Keys. Do not use obsolete CPrivKey for passing keys around Bugfix: add autogenerated addresses to address book get rid of mapPubKeys Use CBitcoinAddress instead of string/uint160 split off CBase58Data from CBitcoinAddress Fix for small change outputs Bugfix: don't overuse limited ExtractAddress avoid strAddress + validity checks SocketHandler thread can be detached Updated dutch translation Stéphane Gimenez (1): Single DB transaction for addresses from DNS seeds Vegard Nossum (6): Add missing includes to key.h Add missing include to script.h Add missing includes to net.h Fix testing setup Add prototype for EvalScript() to script.h Add a file for script tests Venkatesh Srinivas (4): Test for SO_NOSIGPIPE rather than assuming all BSDs support it. Qualify make_tuple with boost:: namespace. Use 'unsigned char' rather than 'char' for pchMessageStart. Define MSG_NOSIGNAL to 0 on platforms where it is unavailable. Wladimir J. van der Laan (2): remove magic number: change threshold for nLockTime to constant make SetHash160 return a value (as specified in the function signature) cjdelisle (1): wxWidgets needs to be at least version 2.9.1 because wallet crypto uses ToStdString() which is not in 2.9.0 ovdeathiam (1): Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub --- [bitcoin-list] Bitcoin-Qt and bitcoind version 0.5 released From: Gavin Andresen - 2011-11-21 23:58:05 Bitcoin version 0.5.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/ The major change for this release is a completely new graphicalinterface that uses the Qt user interface toolkit. This release include German, Spanish, Spanish-Castilian, Norwegianand Dutch translations. More translations are welcome; join theproject at Transifex if you can help: https://www.transifex.net/projects/p/bitcoin/ Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues If you cannot or do not want to run Bitcoin-Qt, a bug-fix-only Bitcoin version 0.4.1 is also available at sourceforge. MAJOR BUG FIX (CVE-2011-4447)------------------------------ The wallet encryption feature introduced in Bitcoin version 0.4.0did not sufficiently secure the private keys. An attacker whomanaged to get a copy of your encrypted wallet.dat file might beable to recover some or all of the unencrypted keys and steal theassociated coins. If you have a previously encrypted wallet.dat, the first time yourun bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin willshut down, and you will be prompted to restart it to run with the new,properly encrypted file. If you had a previously encrypted wallet.dat that might have beencopied or stolen (for example, you backed it up to a publiclocation) you should send all of your bitcoins to yourselfusing a new bitcoin address and stop using any previouslygenerated addresses. Wallets encrypted with this version of Bitcoin are written properly. Technical note: the encrypted wallet's 'keypool' will be regenerated thefirst time you request a new bitcoin address; to be certain that thenew private keys are properly backed up you should: 1. Run Bitcoin and let it rewrite the wallet.dat file 2. Run it again, then ask it for a new bitcoin address. Bitcoin-Qt: Address Book, then New Address... bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet, then run the 'getnewaddress' RPC command. 3. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address. 4. Shut down Bitcoin, then backup the wallet.dat file. IMPORTANT: be sure to request a new bitcoin address before backing up, so that the 'keypool' is regenerated and backed up. "Security in depth" is always a good idea, so choosing a securelocation for the backup and/or encrypting the backup beforeuploading it is recommended. And as in previous releases, if yourmachine is infected by malware there are several ways anattacker might steal your bitcoins. Thanks to Alan Reiner (aka etotheipi) for finding and reportingthis bug. MAJOR GUI CHANGES----------------- "Splash" graphics at startup that show address/wallet/blockchain loadingprogress. "Synchronizing with network" progress bar to show block-chain downloadprogress. Icons at the bottom of the window that show how well connected you areto the network, with tooltips to display details. Drag and drop support for bitcoin: URIs on web pages. Export transactions as a .csv file. Many other GUI improvements, large and small. RPC CHANGES----------- getmemorypool : new RPC command, provides everything needed to constructa block with a custom generation transaction and submit a solution listsinceblock : new RPC command, list transactions since given block signmessage/verifymessage : new RPC commands to sign a message withone of your private keys or verify that a message signed by the privatekey associated with a bitcoin address. GENERAL CHANGES--------------- Faster initial block download. =============================== Thanks to everybody who contributed code or helped test this release: Alan ReinerAlex BAlex WatersAng Iong ChunCelilChris HowieChris MooreDavid Joel SchwartzDavid PerryForrest VoightGavin AndresenJanne PulkkinenJeff GarzikJoelKatzKhalahanLuke DashjrMatt CoralloMisbakh-Soloviev Vadim ANils SchneiderPieter WuilleVictor LeschukWladimir J. van der Laancelil-kjcjdelisleflowerglobalcitizenkwaaakmarkp2k -- -- Gavin Andresen --- [bitcoin-list] BitCoin miner trojans From: David H. Lipman - 2011-11-22 00:45:25 I see that a new GMane group was created concerning BitCoin. I wondering if this community knows the amount of BitCoin miner trojans I am seeing. -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp --- Re: [bitcoin-list] Bitcoin-Qt and bitcoind version 0.5 released From: Martinx - ジェームズ - 2011-11-22 16:13:59 Gavin, The directory within the tarball "bitcoin-0.5.0-linux.tar.gz" is "bitcoin-0.5.0rc7-linux", I guess it should be named just "bitcoin-0.5.0-linux", right!? BTW, I got some errors here, like: ---------- administrativo@...:~$ ./bitcoin-0.5.0rc7-linux/bin/32/bitcoin-qt (bitcoin-qt:2529): Gtk-WARNING **: Não foi possível localizar a ferramenta de temas no module_path: "pixmap", (bitcoin-qt:2529): Gtk-WARNING **: Não foi possível localizar a ferramenta de temas no module_path: "pixmap", (bitcoin-qt:2529): Gtk-WARNING **: Não foi possível localizar a ferramenta de temas no module_path: "pixmap", (bitcoin-qt:2529): Gtk-WARNING **: Não foi possível localizar a ferramenta de temas no module_path: "pixmap", ************************** *EXCEPTION: NSt8ios_base7failureE * *CAutoFile::read : end of file * *bitcoin in Runaway exception * * * *terminate called after throwing an instance of 'std::ios_base::failure'* * what(): CAutoFile::read : end of file* *Aborted* *----------* So, I need to remove my .bitcoin directory to fix this... :-/ Best, Thiago On 21 November 2011 21:57, Gavin Andresen wrote: > Bitcoin version 0.5.0 is now available for download at: > http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/ > The major change for this release is a completely new > graphicalinterface that uses the Qt user interface toolkit. > This release include German, Spanish, Spanish-Castilian, Norwegianand > Dutch translations. More translations are welcome; join theproject at > Transifex if you can help: > https://www.transifex.net/projects/p/bitcoin/ > Please report bugs using the issue tracker at github: > https://github.com/bitcoin/bitcoin/issues > If you cannot or do not want to run Bitcoin-Qt, a bug-fix-only > Bitcoin version 0.4.1 is also available at sourceforge. > > MAJOR BUG FIX (CVE-2011-4447)------------------------------ > The wallet encryption feature introduced in Bitcoin version 0.4.0did > not sufficiently secure the private keys. An attacker whomanaged to > get a copy of your encrypted wallet.dat file might beable to recover > some or all of the unencrypted keys and steal theassociated coins. > If you have a previously encrypted wallet.dat, the first time yourun > bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin willshut > down, and you will be prompted to restart it to run with the > new,properly encrypted file. > If you had a previously encrypted wallet.dat that might have > beencopied or stolen (for example, you backed it up to a > publiclocation) you should send all of your bitcoins to yourselfusing > a new bitcoin address and stop using any previouslygenerated > addresses. > Wallets encrypted with this version of Bitcoin are written properly. > Technical note: the encrypted wallet's 'keypool' will be regenerated > thefirst time you request a new bitcoin address; to be certain that > thenew private keys are properly backed up you should: > 1. Run Bitcoin and let it rewrite the wallet.dat file > 2. Run it again, then ask it for a new bitcoin address. Bitcoin-Qt: > Address Book, then New Address... bitcoind: run the 'walletpassphrase' > RPC command to unlock the wallet, then run the 'getnewaddress' RPC > command. > 3. If your encrypted wallet.dat may have been copied or stolen, send > all of your bitcoins to the new bitcoin address. > 4. Shut down Bitcoin, then backup the wallet.dat file. IMPORTANT: be > sure to request a new bitcoin address before backing up, so that the > 'keypool' is regenerated and backed up. > "Security in depth" is always a good idea, so choosing a > securelocation for the backup and/or encrypting the backup > beforeuploading it is recommended. And as in previous releases, if > yourmachine is infected by malware there are several ways anattacker > might steal your bitcoins. > Thanks to Alan Reiner (aka etotheipi) for finding and reportingthis bug. > MAJOR GUI CHANGES----------------- > "Splash" graphics at startup that show address/wallet/blockchain > loadingprogress. > "Synchronizing with network" progress bar to show block-chain > downloadprogress. > Icons at the bottom of the window that show how well connected you > areto the network, with tooltips to display details. > Drag and drop support for bitcoin: URIs on web pages. > Export transactions as a .csv file. > Many other GUI improvements, large and small. > RPC CHANGES----------- > getmemorypool : new RPC command, provides everything needed to > constructa block with a custom generation transaction and submit a > solution > listsinceblock : new RPC command, list transactions since given block > signmessage/verifymessage : new RPC commands to sign a message withone > of your private keys or verify that a message signed by the privatekey > associated with a bitcoin address. > GENERAL CHANGES--------------- > Faster initial block download. > =============================== > Thanks to everybody who contributed code or helped test this release: > Alan ReinerAlex BAlex WatersAng Iong ChunCelilChris HowieChris > MooreDavid Joel SchwartzDavid PerryForrest VoightGavin AndresenJanne > PulkkinenJeff GarzikJoelKatzKhalahanLuke DashjrMatt > CoralloMisbakh-Soloviev Vadim ANils SchneiderPieter WuilleVictor > LeschukWladimir J. van der > Laancelil-kjcjdelisleflowerglobalcitizenkwaaakmarkp2k > > -- > -- > Gavin Andresen > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- [bitcoin-list] Bitcoin version 0.6.2 available From: Gavin Andresen - 2012-05-08 23:57:21 Bitcoin version 0.6.2 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/ This is a bug-fix and code-cleanup release, with no major new features. NOTABLE CHANGES =============== Much faster shutdowns. However, the blkindex.dat file is no longer portable to different data directories by default. If you need a portable blkindex.dat file then run with the new -detachdb=1 option or the "Detach databases at shutdown" GUI preference. Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that could cause long-running nodes to crash. Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux binaries are dynamically linked to the version of OpenSSL on the system). CHANGE SUMMARY ============== Use 'git shortlog --no-merges v0.6.0..' for a summary of this release. Source codebase changes: - Many source code cleanups and warnings fixes. Close to building with -Wall - Locking overhaul, and several minor locking fixes - Several source code portability fixes, e.g. FreeBSD JSON-RPC interface changes: - addmultisigaddress enabled for mainnet (previously only enabled for testnet) Network protocol changes: - protocol version 60001 - added nonce value to "ping" message (BIP 31) - added new "pong" message (BIP 31) Backend storage changes: - Less redundant database flushing, especially during initial block download - Shutdown improvements (see above) Qt user interface: - minor URI handling improvements - progressbar improvements - error handling improvements (show message box rather than console exception, etc.) - by popular request, make 4th bar of connection icon green Thanks to everybody who contributed to this release: Chris Moore Dwayne C. Litzenberger Gavin Andresen Jeff Garzik Luke Dashjr Matt Corallo Philip Kaufmann Pieter Wuille R E Broadley Timothy Redaelli Wladimir J. van der Laan cardpuncher freewil graingert sje397 --- [bitcoin-list] Critical denial-of-service vulnerability From: Gavin Andresen - 2012-05-14 17:10:02 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 CVE-2012-2459: Critical Vulnerability A denial-of-service vulnerability that affects all versions of bitcoind and Bitcoin-Qt has been reported and fixed. An attacker could isolate a victim's node and cause the creation of blockchain forks. Because this bug could be exploited to severely disrupt the Bitcoin network we consider this a critical vulnerability, and encourage everybody to upgrade to the latest version: 0.6.2. Backports for older releases (0.5.5 and 0.4.6) are also available if you cannot upgrade to version 0.6.2. Full technical details are being withheld to give people the opportunity to upgrade. Thanks to Forrest Voight for discovering and reporting the vulnerability. Questions that might be frequently asked: How would I know if I am the victim of this attack? Your bitcoin process would stop processing blocks and would have a different block count from the rest of the network (you can see the current block count at websites like blockexplorer.com or blockchain.info). Eventually it would display the message: "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." (note that this message is displayed whenever your bitcoin process detects that the rest of the network seems to have a different block count, which can happen for several reasons unrelated to this vulnerability). Could this bug be used to steal my wallet? No. Could this bug be used to install malware on my system? No. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBCgAGBQJPsTpaAAoJECnZ7msfxzDB76cQALBqcEb40dQOtopbsk7vHDuL FL4xd56B1/s3idyHGeCuwJX5bgxGD9b3svayXhDiLo9O+5E3sxsLY1HehTXnU8KV BGpIQ7I+XLDcmarGYrDLMNMDLFOp/1hTipi08X3cr6oHNdYOxGbdtqCQR8xxtdfh Mmo07ReYYWamlF+QbwoXIJQOEka2UVeWWgmk1C+WW1phI3P3Of5EvWvkmOurZsY1 zew7G3sk0Lu8glxSt8qq1SKlDXOaSqTBPxs+2FtgkUplNrAIyufu0vCTsnC44oie ndJD6XZAaG6cYr3adGQKmUjRR+oyZarMtBdDHBvYHkrQI4uQclL1aS7DhkLtH8kp fBRHdqmbBJpmpWOcs+OZeaQCzrArKihuVVZqP4HYbHgGHLV3Ls1bebyWm5eLZH6Z C5l3B4Hz/lp50gJpVsIZI291l3KWfoBW2qGyQv51U4uByLU8tPzgr5bdyo6YCo4N XQZHveNInMDI8jSimGyHg7WNm0YjkSAM8PEIJhQuL+RaHKgN/ghLPR+1K1YZnMjq BPdJZVDpP2bgClyj6P+UkhAplEoenxZUsjyRmcs9EWjHZo3UUI9MLZW96vkR0Wlv UBgq0/jSNQ6s3U3YwKM8CDFJ4OB7Mu1Ln6sn+Tu5sl3xtPyapARA5K67FYSpvqVX GNIME8aiNjICQmtIFiuX =9L8G -----END PGP SIGNATURE----- --- [bitcoin-list] Version 0.8.0 released From: Gavin Andresen - 2013-02-20 20:37:01 Bitcoin-Qt version 0.8.0 are now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/ This is a major release designed to improve performance and handle the increasing volume of transactions on the network. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -------------- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). The first time you run after the upgrade a re-indexing process will be started that will take anywhere from 30 minutes to several hours, depending on the speed of your machine. Incompatible Changes -------------------- This release no longer maintains a full index of historical transaction ids by default, so looking up an arbitrary transaction using the getrawtransaction RPC call will not work. If you need that functionality, you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more details). Improvements ------------ Mac and Windows binaries are signed with certificates owned by the Bitcoin Foundation, to be compatible with the new security features in OSX 10.8 and Windows 8. LevelDB, a fast, open-source, non-relational database from Google, is now used to store transaction and block indices. LevelDB works much better on machines with slow I/O and is faster in general. Berkeley DB is now only used for the wallet.dat file (public and private wallet keys and transactions relevant to you). Pieter Wuille implemented many optimizations to the way transactions are verified, so a running, synchronized node uses less working memory and does much less I/O. He also implemented parallel signature checking, so if you have a multi-CPU machine all CPUs will be used to verify transactions. New Features ------------ "Bloom filter" support in the network protocol for sending only relevant transactions to lightweight clients. contrib/verifysfbinaries is a shell-script to verify that the binary downloads at sourceforge have not been tampered with. If you are able, you can help make everybody's downloads more secure by running this occasionally to check PGP signatures against download file checksums. contrib/spendfrom is a python-language command-line utility that demonstrates how to use the "raw transactions" JSON-RPC api to send coins received from particular addresses (also known as "coin control"). New/changed settings (command-line or bitcoin.conf file) -------------------------------------------------------- dbcache : controls LevelDB memory usage. par : controls how many threads to use to validate transactions. Defaults to the number of CPUs on your machine, use -par=1 to limit to a single CPU. txindex : maintains an extra index of old, spent transaction ids so they will be found by the getrawtransaction JSON-RPC method. reindex : rebuild block and transaction indices from the downloaded block data. New JSON-RPC API Features ------------------------- lockunspent / listlockunspent allow locking transaction outputs for a period of time so they will not be spent by other processes that might be accessing the same wallet. addnode / getaddednodeinfo methods, to connect to specific peers without restarting. importprivkey now takes an optional boolean parameter (default true) to control whether or not to rescan the blockchain for transactions after importing a new private key. Important Bug Fixes ------------------- Privacy leak: the position of the "change" output in most transactions was not being properly randomized, making network analysis of the transaction graph to identify users' wallets easier. Zero-confirmation transaction vulnerability: accepting zero-confirmation transactions (transactions that have not yet been included in a block) from somebody you do not trust is still not recommended, because there will always be ways for attackers to double-spend zero-confirmation transactions. However, this release includes a bug fix that makes it a little bit more difficult for attackers to double-spend a certain type ("lockTime in the future") of zero-confirmation transaction. Dependency Changes ------------------ Qt 4.8.3 (compiling against older versions of Qt 4 should continue to work) Thanks to everybody who contributed to this release: ---------------------------------------------------- Alexander Kjeldaas Andrey Alekseenko Arnav Singh Christian von Roques Eric Lombrozo Forrest Voight Gavin Andresen Gregory Maxwell Jeff Garzik Luke Dashjr Matt Corallo Mike Cassano Mike Hearn Peter Todd Philip Kaufmann Pieter Wuille Richard Schwab Robert Backhaus Rune K. Svendsen Sergio Demian Lerner Wladimir J. van der Laan burger2 default fanquake grimd34th justmoon redshark1802 tucenaber xanatos --- [bitcoin-list] Bitcoin xpm's for Linux and FreeBSD From: Joseph A. Nagy, Jr - 2013-07-01 10:58:24 Hi everyone, For anyone using bitcoin-qt on Linux or FreeBSD I have made some xpm's which I'm distributing. There are two images in every WindowMaker tile size from 24x24 to 96x96. http://www.joseph-a-nagy-jr.us/downloads/xpm-bitcoin-qt.tar.gz All released under the OWL (http://copyfree.org/licenses/owl/license.txt). Enjoy! -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://copyfree.org/licenses/owl/license.txt --- [bitcoin-list] Andrew's semi-technical guide to Bitcoin From: Andrew Moroz - 2013-07-19 02:23:26 Hello, I wrote an intro to Bitcoin for people with a bit of computer science knowledge. I'd be curious for everyone's feedback: https://docs.google.com/document/d/1OeG7QJNuRXbunr-Yw1xmLaogQeqQv81frtJgp-DZogU/ Thank you, Andrew --- [bitcoin-list] BitMail - p2p Email 0.1. beta From: Randolph D. - 2013-07-30 05:01:11 http://bitmail.sourceforge.net/ - Secure P2P Email from Friend to Friend without relying on a central server. - Key- / Repleo-Exchange. - Full decentral Email-Network using the Echo Protocol. - Store Email for Offline-Friends in the P2P Network. - Chat and Instant Messaging is build in. Define & Add your friends. - Strong e2e Multi-Encryption (PGP-kind/AES over SSL: using libgcrypt;). - Libspoton Integration. - Additional Security Layer with the GB-Feature for Emails. - Preventing Data Retention (VDS). WoT-less. - HTTP & HTTPS Connections. - Open Source. BSD License. anyone with a Server? Key? --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Mike Hearn - 2013-07-30 08:40:52 For people who are interested in such technologies, I recommend looking at Pond: https://pond.imperialviolet.org/ It is written by Adam Langley, so it comes with some serious credentials behind it. It provides asynchronous email-like messaging that's forward secure, resistant to traffic analysis and the whole thing runs over Tor. Messages are stored for a week and are strictly limited in size. There's no spam because nobody has an address - instead you have to grant someone the ability to message you by giving them a small file. So, not really intended as an email competitor convenience wise, but it has many interesting ideas and a reasonable GUI. As a testament to the seriousness with which Pond takes forward security, it can use the NVRAM in a TPM chip to reliably destroy keys for data that an SSD device might have otherwise made un-erasable. The main downside - it's written in Go :) On Tue, Jul 30, 2013 at 8:50 AM, Gregory Maxwell wrote: > On Mon, Jul 29, 2013 at 10:01 PM, Randolph D. wrote: > > Secure P2P Email from Friend to Friend without relying on a central > server. > > Key- / Repleo-Exchange. > > Full decentral Email-Network using the Echo Protocol. > > Store Email for Offline-Friends in the P2P Network. > > Chat and Instant Messaging is build in. Define & Add your friends. > > Strong e2e Multi-Encryption (PGP-kind/AES over SSL: using libgcrypt). > > Libspoton Integration. > > Additional Security Layer with the GB-Feature for Emails. > > Preventing Data Retention (VDS). WoT-less. > > HTTP & HTTPS Connections. > > Open Source. BSD License. > > > > anyone with a Server? Key? > > Keep safe everyone: > > A number of apparent sock accounts has been posting about what appears > to be the same software under the name "goldbug" for a couple days > now: > > e.g. > https://lists.torproject.org/pipermail/tor-talk/2013-July/029107.html > https://lists.torproject.org/pipermail/tor-talk/2013-July/029125.html > http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047137.html > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Mike Hearn - 2013-07-30 12:12:57 The TPM is a piece of secure* hardware that provides various cryptographic services to the host system. It is important to understand that it is not a crypto accelerator. It is a place to store keys and small pieces of data (like hashes, counters) where it's difficult for someone to extract them even if they have physical access. The TPM is designed to support trusted computing, a rather splendid set of extensions to the x86 architecture that let you do remote attestation, software sealing and other things. Or at least it would be splendid if it had been really finished off and pushed to completion by the designers. Unfortunately due to various political issues it exists in a quasi-finished, semi-broken state which only experts can use. Without a doubt you have never run any software in a TC environment. As part of that role, the TPM provides some permanent storage in the form of NVRAM. Because the TPM is designed to be as cheap as possible, it has a limited number of write cycles. Normally you're meant to store Intel TXT launch control policies and sealed keys there, but Pond uses it in a different way by storing keys there that it encrypts local data with. By erasing the key in the TPM chips memory area, the data on disk is effectively destroyed too. This is useful because modern "disks" are often SSD drives, or physical metal disks that use log structured file systems. Because flash memory has a limited number of write cycles per cell, internally SSDs have firmware that remap writes from logical addresses to different physical addresses, the goal is to avoid wearing down the drive and extend its useful life. Normally it doesn't matter, but if you want to delete data such that it's really really gone, it obviously poses a problem. Using TPM NVRAM solves it, albiet, at a high usability cost. *note: actual tamper resistance of real-world TPM chips is not something that seems to have been studied much On Tue, Jul 30, 2013 at 1:27 PM, Wendell wrote: > Can you explain this process for those of us not too familiar with TPM > chips? > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: > > > As a testament to the seriousness with which Pond takes forward > security, it can use the NVRAM in a TPM chip to reliably destroy keys for > data that an SSD device might have otherwise made un-erasable. > --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: grarpamp - 2013-07-30 20:43:39 On Tue, Jul 30, 2013 at 8:12 AM, Mike Hearn wrote: > The TPM is a piece of secure* hardware I've seen some motherboards with a TPM module header but none came with it installed. I think the modules themselves might be $50-$100 range. They might come with some API docs. Some of you might have links to ones you've used... > As part of that role, the TPM provides some permanent storage in the form > of NVRAM. Because the TPM is designed to be as cheap as possible, it has a > limited number of write cycles. Normally you're meant to store Intel TXT > launch control policies and sealed keys there > the goal is to avoid wearing down the drive and extend its useful life. > Normally it doesn't matter, but if you want to delete data such that it's > really really gone, it obviously poses a problem. Using TPM NVRAM solves > it, albiet, at a high usability cost. If said TPM storage has a 'limited [but unfixed number of write cycles', that sounds unreliable. It would seem to me that both reliable and 'really gone' are achievable on platters (or lesser, with ssd) provided the disk was also encrypted. Nuke that key and it's reliably gone. --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Mike Hearn - 2013-07-30 22:17:52 TPMs have come as standard with nearly all computers (except Macs, doh) for a long time. They certainly don't cost $100. More like a few dollars at most. That's why they're so slow. On Tue, Jul 30, 2013 at 10:43 PM, grarpamp wrote: > On Tue, Jul 30, 2013 at 8:12 AM, Mike Hearn wrote: > > The TPM is a piece of secure* hardware > > I've seen some motherboards with a TPM module header but none > came with it installed. I think the modules themselves might be > $50-$100 range. They might come with some API docs. > Some of you might have links to ones you've used... > > > As part of that role, the TPM provides some permanent storage in the form > > of NVRAM. Because the TPM is designed to be as cheap as possible, it has > a > > limited number of write cycles. Normally you're meant to store Intel TXT > > launch control policies and sealed keys there > > > the goal is to avoid wearing down the drive and extend its useful life. > > Normally it doesn't matter, but if you want to delete data such that it's > > really really gone, it obviously poses a problem. Using TPM NVRAM solves > > it, albiet, at a high usability cost. > > If said TPM storage has a 'limited [but unfixed number of write cycles', > that > sounds unreliable. It would seem to me that both reliable and 'really gone' > are achievable on platters (or lesser, with ssd) provided the disk was also > encrypted. Nuke that key and it's reliably gone. > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: grarpamp - 2013-07-30 22:59:05 On Tue, Jul 30, 2013 at 6:17 PM, Mike Hearn wrote: > TPMs have come as standard with nearly all computers (except Macs, doh) for > a long time. They certainly don't cost $100. More like a few dollars at > most. That's why they're so slow. I wouldn't go to 'nearly all' considering installed base of non pre-core2 / xeon. And if AMD even has this stuff. Though apparently it's cheaper since last looked. Links... https://en.wikipedia.org/wiki/Trusted_Platform_Module https://encrypted.google.com/search?q=tpm+module http://hardforum.com/showthread.php?t=1607955 https://encrypted.google.com/search?q=gigabyte+tpm+module https://encrypted.google.com/search?tbm=shop&q=tpm+module https://en.wikipedia.org/wiki/Intel_vPro https://en.wikipedia.org/wiki/Intel_Active_Management_Technology https://en.wikipedia.org/wiki/Trusted_Computing https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Blibbet - 2013-07-31 03:37:03 On 7/30/13 3:58 PM, grarpamp wrote: > [...] And if AMD even has this stuff. [...] Yes, AMD does have TPM. Sorry, not sure which models support it. http://www.amd.com/us/products/embedded/das/Pages/security.aspx http://www.amd.com/us/products/desktop/platforms/Pages/desktop-platforms.aspx --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Mike Hearn - 2013-07-31 09:09:00 "Support" for a TPM is a rather tricky thing. By itself the TPM is independent of any CPU. However, it's also not very useful (though for Pond's use case, it works). The TPM gets much more useful when it's integrated with features on the motherboard, BIOS, CPU, northbridge, IOMMU etc. Then you have a full blown TCG-compliant TC environment, which is useful for many things. Actually it was never very useful for DRM - that was only one theoretical possibility that was never implemented and even if it had been, TC is to DRM much as cryptography is to DRM. So the FUD was just that: fear, uncertainty and doubt which probably crippled a highly useful cryptographic security tool for good. One of the more shameful periods of the tech industries history, if you ask me. On Wed, Jul 31, 2013 at 5:39 AM, Blibbet wrote: > On 7/30/13 3:58 PM, grarpamp wrote: > > [...] And if AMD even has this stuff. [...] > > Yes, AMD does have TPM. > > Sorry, not sure which models support it. > > http://www.amd.com/us/products/embedded/das/Pages/security.aspx > > > http://www.amd.com/us/products/desktop/platforms/Pages/desktop-platforms.aspx > > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Eugen Leitl - 2013-07-31 13:47:25 On Wed, Jul 31, 2013 at 11:08:53AM +0200, Mike Hearn wrote: > "Support" for a TPM is a rather tricky thing. > > By itself the TPM is independent of any CPU. However, it's also not very > useful (though for Pond's use case, it works). > > The TPM gets much more useful when it's integrated with features on the > motherboard, BIOS, CPU, northbridge, IOMMU etc. Then you have a full blown > TCG-compliant TC environment, which is useful for many things. Actually it > was never very useful for DRM - that was only one theoretical possibility > that was never implemented and even if it had been, TC is to DRM much as > cryptography is to DRM. So the FUD was just that: fear, uncertainty and > doubt which probably crippled a highly useful cryptographic security tool > for good. One of the more shameful periods of the tech industries history, > if you ask me. The reason why TPM functionality was so much hated upon is because it was pushed by a software/hardware monopoly, not just for DRM but for locking down the system in general. Obviously a real open and verifyable TPM (aka hardened secret compartment with some crypto primitives) could be very useful in practice. However, this is not what was pushed back then. --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Mike Hearn - 2013-07-31 15:53:37 > The reason why TPM functionality was so much hated upon is because > it was pushed by a software/hardware monopoly, not just for DRM but > for locking down the system in general. > Regardless of what some people might have imagined or extrapolated at the time, the actual published specifications and technologies were nothing like that. There has never been a TC/TPM mode that would have generally locked systems down or even been useful for DRM (that'd have required a trusted hardware path which was never specced nor implemented). Locking a system down against tampering or for DRM does not require flexible open specifications with multiple competing implementations. It requires you to do an Xbox 360. --- Re: [bitcoin-list] [Bitcoin-development] BitMail - p2p Email 0.1. beta From: Randolph D. - 2013-07-31 16:11:39 right the original Topic was BitMail here a Server running for the next few days to test BitMail.sf.net 178.83.35.133:4710 --- [bitcoin-list] bitcoin-qt latest git compilation issue (error: conversion from ‘uint64_t {aka long unsigned int}’ to ‘const Value_type {aka const json_spirit::Value_impl > >}’ is ambiguous) From: Dâniel Fraga - 2013-09-06 23:30:13 I always like to compile my software and I've been doing this for a long time, but now with latest git of bitcoin-qt I get those errors with gcc 4.8.2 (20130822): cd /usr/local/src/git/bitcoin/src/leveldb && CC=gcc CXX=g++ make OPT="-m64 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2" libleveldb.a libmemenv.a make[1]: Entering directory `/usr/local/src/git/bitcoin/src/leveldb' make[1]: `libleveldb.a' is up to date. make[1]: `libmemenv.a' is up to date. make[1]: Leaving directory `/usr/local/src/git/bitcoin/src/leveldb' cd /usr/local/src/git/bitcoin; /bin/sh share/genbuild.sh build/build.h g++ -c -m64 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2 -D_REENTRANT -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -Wstack-protector -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_UPNP=1 -DSTATICLIB -DUSE_IPV6=1 -DHAVE_BUILD_INFO -DLINUX -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I../../../Trolltech/Qt-4.8.4/mkspecs/linux-g++-64 -I../../../Trolltech/Qt-4.8.4/include/QtCore -I../../../Trolltech/Qt-4.8.4/include/QtNetwork -I../../../Trolltech/Qt-4.8.4/include/QtGui -I../../../Trolltech/Qt-4.8.4/include -Isrc -Isrc/json -Isrc/qt -Isrc/leveldb/include -Isrc/leveldb/helpers -I../../../BerkeleyDB.5.3/include -I../../../ssl/include -Ibuild -Ibuild -o build/rpcmining.o src/rpcmining.cpp In file included from src/bitcoinrpc.h:17:0, from src/rpcmining.cpp:10: src/json/json_spirit_writer_template.h: In function ‘String_type json_spirit::non_printable_to_string(unsigned int)’: src/json/json_spirit_writer_template.h:31:50: warning: typedef ‘Char_type’ locally defined but not used [-Wunused-local-typedefs] typedef typename String_type::value_type Char_type; ^ src/rpcmining.cpp: In function ‘json_spirit::Value getmininginfo(const Array&, bool)’: src/rpcmining.cpp:89:68: error: conversion from ‘uint64_t {aka long unsigned int}’ to ‘const Value_type {aka const json_spirit::Value_impl > >}’ is ambiguous obj.push_back(Pair("currentblocksize", (uint64_t)nLastBlockSize)); ^ src/rpcmining.cpp:89:68: note: candidates are: In file included from src/json/json_spirit_reader_template.h:9:0, from src/bitcoinrpc.h:16, from src/rpcmining.cpp:10: src/json/json_spirit_value.h:283:5: note: json_spirit::Value_impl::Value_impl(double) [with Config = json_spirit::Config_vector >] Value_impl< Config >::Value_impl( double value ) ^ src/json/json_spirit_value.h:275:5: note: json_spirit::Value_impl::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector >; boost::uint64_t = long long unsigned int] Value_impl< Config >::Value_impl( boost::uint64_t value ) ^ src/json/json_spirit_value.h:267:5: note: json_spirit::Value_impl::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector >; boost::int64_t = long long int] Value_impl< Config >::Value_impl( boost::int64_t value ) ^ src/json/json_spirit_value.h:259:5: note: json_spirit::Value_impl::Value_impl(int) [with Config = json_spirit::Config_vector >] Value_impl< Config >::Value_impl( int value ) ^ src/json/json_spirit_value.h:251:5: note: json_spirit::Value_impl::Value_impl(bool) [with Config = json_spirit::Config_vector >] Value_impl< Config >::Value_impl( bool value ) ^ src/json/json_spirit_value.h:219:5: note: json_spirit::Value_impl::Value_impl(json_spirit::Value_impl::Const_str_ptr) [with Config = json_spirit::Config_vector >; json_spirit::Value_impl::Const_str_ptr = const char*] Value_impl< Config >::Value_impl( const Const_str_ptr value ) ^ src/json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘uint64_t {aka long unsigned int}’ to ‘json_spirit::Value_impl > >::Const_str_ptr {aka const char*}’ src/json/json_spirit_value.h:439:5: error: initializing argument 2 of ‘json_spirit::Pair_impl::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector >; json_spirit::Pair_impl::String_type = std::basic_string; json_spirit::Pair_impl::Value_type = json_spirit::Value_impl > >]’ Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value ) ^ *********************************************** Any hints? Thanks. -- Linux 3.11.0: Linux for Workgroups http://www.youtube.com/DanielFragaBR http://www.libertarios.org.br --- Re: [bitcoin-list] bitcoin-qt latest git compilation issue (error: conversion from ‘uint64_t {aka long unsigned int}’ to ‘const Value_type {aka const json_spirit::Value_impl > >}’ is ambiguous) From: Gavin Andresen - 2013-09-07 00:06:22 Let me know if this fixes the problem: diff --git a/src/rpcmining.cpp b/src/rpcmining.cpp index c7f516c..4cfdcb5 100644 --- a/src/rpcmining.cpp +++ b/src/rpcmining.cpp @@ -86,14 +86,14 @@ Value getmininginfo(const Array& params, bool fHelp) Object obj; obj.push_back(Pair("blocks", (int)nBestHeight)); - obj.push_back(Pair("currentblocksize", (uint64_t)nLastBlockSize)); - obj.push_back(Pair("currentblocktx", (uint64_t)nLastBlockTx)); + obj.push_back(Pair("currentblocksize", (boost::uint64_t)nLastBlockSize)); + obj.push_back(Pair("currentblocktx", (boost::uint64_t)nLastBlockTx)); obj.push_back(Pair("difficulty", (double)GetDifficulty())); obj.push_back(Pair("errors", GetWarnings("statusbar"))); obj.push_back(Pair("generate", GetBoolArg("-gen", false))); obj.push_back(Pair("genproclimit", (int)GetArg("-genproclimit", -1))); obj.push_back(Pair("hashespersec", gethashespersec(params, false))); - obj.push_back(Pair("pooledtx", (uint64_t)mempool.size())); + obj.push_back(Pair("pooledtx", (boost::uint64_t)mempool.size())); obj.push_back(Pair("testnet", TestNet())); return obj; } On Sat, Sep 7, 2013 at 9:24 AM, Dâniel Fraga wrote: > I always like to compile my software and I've been doing this > for a long time, but now with latest git of bitcoin-qt I get those > errors with gcc 4.8.2 (20130822): > > cd /usr/local/src/git/bitcoin/src/leveldb && CC=gcc CXX=g++ make OPT="-m64 > -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2" libleveldb.a > libmemenv.a > make[1]: Entering directory `/usr/local/src/git/bitcoin/src/leveldb' > make[1]: `libleveldb.a' is up to date. > make[1]: `libmemenv.a' is up to date. > make[1]: Leaving directory `/usr/local/src/git/bitcoin/src/leveldb' > cd /usr/local/src/git/bitcoin; /bin/sh share/genbuild.sh build/build.h > g++ -c -m64 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2 > -D_REENTRANT -fdiagnostics-show-option -Wall -Wextra -Wformat > -Wformat-security -Wno-unused-parameter -Wstack-protector > -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_UPNP=1 -DSTATICLIB > -DUSE_IPV6=1 -DHAVE_BUILD_INFO -DLINUX -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG > -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED > -I../../../Trolltech/Qt-4.8.4/mkspecs/linux-g++-64 > -I../../../Trolltech/Qt-4.8.4/include/QtCore > -I../../../Trolltech/Qt-4.8.4/include/QtNetwork > -I../../../Trolltech/Qt-4.8.4/include/QtGui > -I../../../Trolltech/Qt-4.8.4/include -Isrc -Isrc/json -Isrc/qt > -Isrc/leveldb/include -Isrc/leveldb/helpers > -I../../../BerkeleyDB.5.3/include -I../../../ssl/include -Ibuild -Ibuild -o > build/rpcmining.o src/rpcmining.cpp > In file included from src/bitcoinrpc.h:17:0, > from src/rpcmining.cpp:10: > src/json/json_spirit_writer_template.h: In function ‘String_type > json_spirit::non_printable_to_string(unsigned int)’: > src/json/json_spirit_writer_template.h:31:50: warning: typedef ‘Char_type’ > locally defined but not used [-Wunused-local-typedefs] > typedef typename String_type::value_type Char_type; > ^ > src/rpcmining.cpp: In function ‘json_spirit::Value getmininginfo(const > Array&, bool)’: > src/rpcmining.cpp:89:68: error: conversion from ‘uint64_t {aka long > unsigned int}’ to ‘const Value_type {aka const > json_spirit::Value_impl > > >}’ is ambiguous > obj.push_back(Pair("currentblocksize", (uint64_t)nLastBlockSize)); > ^ > src/rpcmining.cpp:89:68: note: candidates are: > In file included from src/json/json_spirit_reader_template.h:9:0, > from src/bitcoinrpc.h:16, > from src/rpcmining.cpp:10: > src/json/json_spirit_value.h:283:5: note: > json_spirit::Value_impl::Value_impl(double) [with Config = > json_spirit::Config_vector >] > Value_impl< Config >::Value_impl( double value ) > ^ > src/json/json_spirit_value.h:275:5: note: > json_spirit::Value_impl::Value_impl(boost::uint64_t) [with Config = > json_spirit::Config_vector >; boost::uint64_t = > long long unsigned int] > Value_impl< Config >::Value_impl( boost::uint64_t value ) > ^ > src/json/json_spirit_value.h:267:5: note: > json_spirit::Value_impl::Value_impl(boost::int64_t) [with Config = > json_spirit::Config_vector >; boost::int64_t = long > long int] > Value_impl< Config >::Value_impl( boost::int64_t value ) > ^ > src/json/json_spirit_value.h:259:5: note: > json_spirit::Value_impl::Value_impl(int) [with Config = > json_spirit::Config_vector >] > Value_impl< Config >::Value_impl( int value ) > ^ > src/json/json_spirit_value.h:251:5: note: > json_spirit::Value_impl::Value_impl(bool) [with Config = > json_spirit::Config_vector >] > Value_impl< Config >::Value_impl( bool value ) > ^ > src/json/json_spirit_value.h:219:5: note: > json_spirit::Value_impl::Value_impl(json_spirit::Value_impl::Const_str_ptr) > [with Config = json_spirit::Config_vector >; > json_spirit::Value_impl::Const_str_ptr = const char*] > Value_impl< Config >::Value_impl( const Const_str_ptr value ) > ^ > src/json/json_spirit_value.h:219:5: note: no known conversion for > argument 1 from ‘uint64_t {aka long unsigned int}’ to > ‘json_spirit::Value_impl > > >::Const_str_ptr {aka const char*}’ > src/json/json_spirit_value.h:439:5: error: initializing argument 2 of > ‘json_spirit::Pair_impl::Pair_impl(const String_type&, const > Value_type&) [with Config = > json_spirit::Config_vector >; > json_spirit::Pair_impl::String_type = std::basic_string; > json_spirit::Pair_impl::Value_type = > json_spirit::Value_impl > > >]’ > Pair_impl< Config >::Pair_impl( const String_type& name, const > Value_type& value ) > ^ > > *********************************************** > > Any hints? Thanks. > > -- > Linux 3.11.0: Linux for Workgroups > http://www.youtube.com/DanielFragaBR > http://www.libertarios.org.br > > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -- -- Gavin Andresen --- Re: [bitcoin-list] bitcoin-qt latest git compilation issue (error: conversion from ‘uint64_t {aka long unsigned int}’ to ‘const Value_type {aka const json_spirit::Value_impl > >}’ is ambiguous) From: Dâniel Fraga - 2013-09-07 07:45:11 Hi Gavin, it fixed the problem. Now I got another one with moc from QT: Making all in qt make[3]: Entering directory `/usr/local/src/git/bitcoin/src/qt' /usr/bin/moc -DQT_SHARED -I/usr/local/Trolltech/Qt-4.8.4/include -I/usr/local/Trolltech/Qt-4.8.4/include/QtCore -I/usr/local/Trolltech/Qt-4.8.4/include/QtGui -I/usr/local/Trolltech/Qt-4.8.4/include/QtNetwork -o moc_addressbookpage.cpp addressbookpage.h Qt meta object compiler moc: Invalid argument Usage: moc [options] -o file Write output to file rather than stdout -f[file] Force #include, optional file name -p path Path prefix for included file -i Do not generate an #include statement -k Do not stop on errors -nw Do not display warnings -v Display version of moc make[3]: *** [moc_addressbookpage.cpp] Error 1 make[3]: Leaving directory `/usr/local/src/git/bitcoin/src/qt' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/git/bitcoin/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/git/bitcoin/src' make: *** [all-recursive] Error 1 On Sat, 7 Sep 2013 10:06:14 +1000 Gavin Andresen wrote: > Let me know if this fixes the problem: > > diff --git a/src/rpcmining.cpp b/src/rpcmining.cpp > index c7f516c..4cfdcb5 100644 > --- a/src/rpcmining.cpp > +++ b/src/rpcmining.cpp > @@ -86,14 +86,14 @@ Value getmininginfo(const Array& params, bool fHelp) > > Object obj; > obj.push_back(Pair("blocks", (int)nBestHeight)); > - obj.push_back(Pair("currentblocksize", (uint64_t)nLastBlockSize)); > - obj.push_back(Pair("currentblocktx", (uint64_t)nLastBlockTx)); > + obj.push_back(Pair("currentblocksize", > (boost::uint64_t)nLastBlockSize)); > + obj.push_back(Pair("currentblocktx", (boost::uint64_t)nLastBlockTx)); > obj.push_back(Pair("difficulty", (double)GetDifficulty())); > obj.push_back(Pair("errors", GetWarnings("statusbar"))); > obj.push_back(Pair("generate", GetBoolArg("-gen", false))); > obj.push_back(Pair("genproclimit", (int)GetArg("-genproclimit", > -1))); > obj.push_back(Pair("hashespersec", gethashespersec(params, > false))); > - obj.push_back(Pair("pooledtx", (uint64_t)mempool.size())); > + obj.push_back(Pair("pooledtx", > (boost::uint64_t)mempool.size())); > obj.push_back(Pair("testnet", TestNet())); > return obj; > } > > > > On Sat, Sep 7, 2013 at 9:24 AM, Dâniel Fraga wrote: > > > I always like to compile my software and I've been doing this > > for a long time, but now with latest git of bitcoin-qt I get those > > errors with gcc 4.8.2 (20130822): > > > > cd /usr/local/src/git/bitcoin/src/leveldb && CC=gcc CXX=g++ make OPT="-m64 > > -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2" libleveldb.a > > libmemenv.a > > make[1]: Entering directory `/usr/local/src/git/bitcoin/src/leveldb' > > make[1]: `libleveldb.a' is up to date. > > make[1]: `libmemenv.a' is up to date. > > make[1]: Leaving directory `/usr/local/src/git/bitcoin/src/leveldb' > > cd /usr/local/src/git/bitcoin; /bin/sh share/genbuild.sh build/build.h > > g++ -c -m64 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -O2 > > -D_REENTRANT -fdiagnostics-show-option -Wall -Wextra -Wformat > > -Wformat-security -Wno-unused-parameter -Wstack-protector > > -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_UPNP=1 -DSTATICLIB > > -DUSE_IPV6=1 -DHAVE_BUILD_INFO -DLINUX -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG > > -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED > > -I../../../Trolltech/Qt-4.8.4/mkspecs/linux-g++-64 > > -I../../../Trolltech/Qt-4.8.4/include/QtCore > > -I../../../Trolltech/Qt-4.8.4/include/QtNetwork > > -I../../../Trolltech/Qt-4.8.4/include/QtGui > > -I../../../Trolltech/Qt-4.8.4/include -Isrc -Isrc/json -Isrc/qt > > -Isrc/leveldb/include -Isrc/leveldb/helpers > > -I../../../BerkeleyDB.5.3/include -I../../../ssl/include -Ibuild -Ibuild -o > > build/rpcmining.o src/rpcmining.cpp > > In file included from src/bitcoinrpc.h:17:0, > > from src/rpcmining.cpp:10: > > src/json/json_spirit_writer_template.h: In function ‘String_type > > json_spirit::non_printable_to_string(unsigned int)’: > > src/json/json_spirit_writer_template.h:31:50: warning: typedef ‘Char_type’ > > locally defined but not used [-Wunused-local-typedefs] > > typedef typename String_type::value_type Char_type; > > ^ > > src/rpcmining.cpp: In function ‘json_spirit::Value getmininginfo(const > > Array&, bool)’: > > src/rpcmining.cpp:89:68: error: conversion from ‘uint64_t {aka long > > unsigned int}’ to ‘const Value_type {aka const > > json_spirit::Value_impl > > > >}’ is ambiguous > > obj.push_back(Pair("currentblocksize", (uint64_t)nLastBlockSize)); > > ^ > > src/rpcmining.cpp:89:68: note: candidates are: > > In file included from src/json/json_spirit_reader_template.h:9:0, > > from src/bitcoinrpc.h:16, > > from src/rpcmining.cpp:10: > > src/json/json_spirit_value.h:283:5: note: > > json_spirit::Value_impl::Value_impl(double) [with Config = > > json_spirit::Config_vector >] > > Value_impl< Config >::Value_impl( double value ) > > ^ > > src/json/json_spirit_value.h:275:5: note: > > json_spirit::Value_impl::Value_impl(boost::uint64_t) [with Config = > > json_spirit::Config_vector >; boost::uint64_t = > > long long unsigned int] > > Value_impl< Config >::Value_impl( boost::uint64_t value ) > > ^ > > src/json/json_spirit_value.h:267:5: note: > > json_spirit::Value_impl::Value_impl(boost::int64_t) [with Config = > > json_spirit::Config_vector >; boost::int64_t = long > > long int] > > Value_impl< Config >::Value_impl( boost::int64_t value ) > > ^ > > src/json/json_spirit_value.h:259:5: note: > > json_spirit::Value_impl::Value_impl(int) [with Config = > > json_spirit::Config_vector >] > > Value_impl< Config >::Value_impl( int value ) > > ^ > > src/json/json_spirit_value.h:251:5: note: > > json_spirit::Value_impl::Value_impl(bool) [with Config = > > json_spirit::Config_vector >] > > Value_impl< Config >::Value_impl( bool value ) > > ^ > > src/json/json_spirit_value.h:219:5: note: > > json_spirit::Value_impl::Value_impl(json_spirit::Value_impl::Const_str_ptr) > > [with Config = json_spirit::Config_vector >; > > json_spirit::Value_impl::Const_str_ptr = const char*] > > Value_impl< Config >::Value_impl( const Const_str_ptr value ) > > ^ > > src/json/json_spirit_value.h:219:5: note: no known conversion for > > argument 1 from ‘uint64_t {aka long unsigned int}’ to > > ‘json_spirit::Value_impl > > > >::Const_str_ptr {aka const char*}’ > > src/json/json_spirit_value.h:439:5: error: initializing argument 2 of > > ‘json_spirit::Pair_impl::Pair_impl(const String_type&, const > > Value_type&) [with Config = > > json_spirit::Config_vector >; > > json_spirit::Pair_impl::String_type = std::basic_string; > > json_spirit::Pair_impl::Value_type = > > json_spirit::Value_impl > > > >]’ > > Pair_impl< Config >::Pair_impl( const String_type& name, const > > Value_type& value ) > > ^ > > > > *********************************************** > > > > Any hints? Thanks. > > > > -- > > Linux 3.11.0: Linux for Workgroups > > http://www.youtube.com/DanielFragaBR > > http://www.libertarios.org.br > > > > > > > > > > ------------------------------------------------------------------------------ > > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > > Discover the easy way to master current and previous Microsoft technologies > > and advance your career. Get an incredible 1,500+ hours of step-by-step > > tutorial videos with LearnDevNow. Subscribe today and save! > > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > > _______________________________________________ > > bitcoin-list mailing list > > bitcoin-list@... > > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > > > -- Linux 3.11.0: Linux for Workgroups http://www.youtube.com/DanielFragaBR http://www.libertarios.org.br --- [bitcoin-list] Stable download URLs From: Tim Lebedkov - 2013-10-03 11:13:40 Hello, would it be possible to *not* move older versions of Bitcoin-Qt to the "Obsolete" directory? Example: the URL http://downloads.sourceforge.net/project/bitcoin/bitcoin-0.8.1/bitcoin-0.8.1-win32-setup.exe is not available anymore Now the right URL is http://downloads.sourceforge.net/project/bitcoin/Obsolete/bitcoin-0.8.1/bitcoin-0.8.1-win32-setup.exe This makes linking to a binary impossible and requires much more work in the default Npackd repository (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) Tim --- Re: [bitcoin-list] Stable download URLs From: Gavin Andresen - 2013-10-04 01:10:03 On Thu, Oct 3, 2013 at 9:13 PM, Tim Lebedkov wrote: > would it be possible to *not* move older versions of Bitcoin-Qt to the > "Obsolete" directory? > No; they are in "obsolete" because they are obsolete, and should not be used. This makes linking to a binary impossible and requires much more work > in the default Npackd repository > (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) > That is a feature, not a bug. -- -- Gavin Andresen --- Re: [bitcoin-list] Stable download URLs From: Tim Lebedkov - 2013-10-04 08:14:35 Hello Gavin, Just to make sure you understand all the implications: once in a month all links over the web to Bitcoin-Qt binaries become invalid. Is this OK? Would it be at least possible to copy the newest version under "Obsolete" too? -- On Fri, Oct 4, 2013 at 3:09 AM, Gavin Andresen wrote: > On Thu, Oct 3, 2013 at 9:13 PM, Tim Lebedkov wrote: >> >> would it be possible to *not* move older versions of Bitcoin-Qt to the >> "Obsolete" directory? > > > No; they are in "obsolete" because they are obsolete, and should not be > used. > >> This makes linking to a binary impossible and requires much more work >> in the default Npackd repository >> (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) > > > That is a feature, not a bug. > > -- > -- > Gavin Andresen --- Re: [bitcoin-list] Stable download URLs From: Mike Hearn - 2013-10-04 08:48:30 What's he's saying is that it's intentional they become invalid, because it's a bad idea for people to download old versions of the app. Your app store needs to be able to keep users on the latest version - old links breaking shouldn't be an issue for that. On Fri, Oct 4, 2013 at 10:14 AM, Tim Lebedkov wrote: > Hello Gavin, > > Just to make sure you understand all the implications: once in a month > all links over the web to Bitcoin-Qt binaries become invalid. Is this > OK? > > Would it be at least possible to copy the newest version under "Obsolete" > too? > > -- > > On Fri, Oct 4, 2013 at 3:09 AM, Gavin Andresen > wrote: > > On Thu, Oct 3, 2013 at 9:13 PM, Tim Lebedkov > wrote: > >> > >> would it be possible to *not* move older versions of Bitcoin-Qt to the > >> "Obsolete" directory? > > > > > > No; they are in "obsolete" because they are obsolete, and should not be > > used. > > > >> This makes linking to a binary impossible and requires much more work > >> in the default Npackd repository > >> (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) > > > > > > That is a feature, not a bug. > > > > -- > > -- > > Gavin Andresen > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] Stable download URLs From: Maciej Trebacz - 2013-10-04 22:47:55 There's probably a very easy solution for that: let's have a link like this: http://downloads.sourceforge.net/project/bitcoin/bitcoin-latest/bitcoin-latest-win32-setup.exe; Of course the downside is that it isn't immediately obvious which version you are downloading, you can be pretty sure then that it's the latest one. Some projects that I know use that notation. On Fri, Oct 4, 2013 at 10:48 AM, Mike Hearn wrote: > What's he's saying is that it's intentional they become invalid, because > it's a bad idea for people to download old versions of the app. Your app > store needs to be able to keep users on the latest version - old links > breaking shouldn't be an issue for that. > > > On Fri, Oct 4, 2013 at 10:14 AM, Tim Lebedkov >wrote: > > > Hello Gavin, > > > > Just to make sure you understand all the implications: once in a month > > all links over the web to Bitcoin-Qt binaries become invalid. Is this > > OK? > > > > Would it be at least possible to copy the newest version under "Obsolete" > > too? > > > > -- > > > > On Fri, Oct 4, 2013 at 3:09 AM, Gavin Andresen > > wrote: > > > On Thu, Oct 3, 2013 at 9:13 PM, Tim Lebedkov > > wrote: > > >> > > >> would it be possible to *not* move older versions of Bitcoin-Qt to the > > >> "Obsolete" directory? > > > > > > > > > No; they are in "obsolete" because they are obsolete, and should not be > > > used. > > > > > >> This makes linking to a binary impossible and requires much more work > > >> in the default Npackd repository > > >> (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) > > > > > > > > > That is a feature, not a bug. > > > > > > -- > > > -- > > > Gavin Andresen > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > > _______________________________________________ > > bitcoin-list mailing list > > bitcoin-list@... > > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] Stable download URLs From: Gunnar Guðvarðarson - 2013-10-04 23:39:56 I like this idea, a simple symlink is enough to do this. I know debian does this, here's an example: http://draupnir.rhnet.is/debian/dists/stable/main/installer-amd64/current/images/netboot/mini.iso I can use "current", or i can pick a certain version: http://draupnir.rhnet.is/debian/dists/stable/main/installer-amd64/20130613/images/netboot/mini.iso ~ Gunnar On 4 October 2013 20:11, Maciej Trebacz wrote: > There's probably a very easy solution for that: let's have a link like this: > > http://downloads.sourceforge.net/project/bitcoin/bitcoin-latest/bitcoin-latest-win32-setup.exe; > > Of course the downside is that it isn't immediately obvious which version > you are downloading, you can be pretty sure then that it's the latest one. > Some projects that I know use that notation. > > > On Fri, Oct 4, 2013 at 10:48 AM, Mike Hearn wrote: > >> What's he's saying is that it's intentional they become invalid, because >> it's a bad idea for people to download old versions of the app. Your app >> store needs to be able to keep users on the latest version - old links >> breaking shouldn't be an issue for that. >> >> >> On Fri, Oct 4, 2013 at 10:14 AM, Tim Lebedkov > >wrote: >> >> > Hello Gavin, >> > >> > Just to make sure you understand all the implications: once in a month >> > all links over the web to Bitcoin-Qt binaries become invalid. Is this >> > OK? >> > >> > Would it be at least possible to copy the newest version under "Obsolete" >> > too? >> > >> > -- >> > >> > On Fri, Oct 4, 2013 at 3:09 AM, Gavin Andresen >> > wrote: >> > > On Thu, Oct 3, 2013 at 9:13 PM, Tim Lebedkov >> > wrote: >> > >> >> > >> would it be possible to *not* move older versions of Bitcoin-Qt to the >> > >> "Obsolete" directory? >> > > >> > > >> > > No; they are in "obsolete" because they are obsolete, and should not be >> > > used. >> > > >> > >> This makes linking to a binary impossible and requires much more work >> > >> in the default Npackd repository >> > >> (https://npackd.appspot.com/p/org.bitcoin.BitcoinQ) >> > > >> > > >> > > That is a feature, not a bug. >> > > >> > > -- >> > > -- >> > > Gavin Andresen >> > >> > >> > >> ------------------------------------------------------------------------------ >> > October Webinars: Code for Performance >> > Free Intel webinars can help you accelerate application performance. >> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> > from >> > the latest Intel processors and coprocessors. See abstracts and register >> > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > bitcoin-list mailing list >> > bitcoin-list@... >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-list >> > >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> bitcoin-list mailing list >> bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >> > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- [bitcoin-list] Noob question about mining pools From: Michael Peek - 2013-11-13 22:23:50 Hi guys, I downloaded bitcoin-0.8.5-linux.tar.gz. Will this software allow me to join a mining pool? Thanks, Michael --- Re: [bitcoin-list] Noob question about mining pools From: Dâniel Fraga - 2013-11-16 00:28:13 On Wed, 13 Nov 2013 16:53:48 -0500 Michael Peek wrote: > I downloaded bitcoin-0.8.5-linux.tar.gz. Will this software allow me to > join a mining pool? No. This is only a client. If you want to mine, you have to use a miner like BFGMiner: http://bfgminer.org/ -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://www.libertarios.org.br Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL --- [bitcoin-list] Beefjerky.com Accepts Bitcoin From: Gregory Nemitz <000mail@be...> - 2013-11-16 01:10:30 Beefjerky.com is accepting Bitcoin for our excellent, fresh beef jerky. We have six premium flavors. Stop by soon to http://www.beefjerky.com and choose some really fine beef jerky. We offer FREE shipping to almost every country in the world. We always send it to you by Priority Mail, so you get your beef jerky fast! Our BTC transactions are processed via Coinbase at the current USD/BTC exchange rate. Cheers! Greg FRESH beef jerky, directly from http://Beefjerky.com Why wait? Order some today. --- [bitcoin-list] Suggestion: easy way to restore wallet.dat backup From: Dâniel Fraga - 2013-11-20 15:54:10 Today, when a user uses bitcoin-qt client, it can make a backup of wallet.dat easily through menu, but when he/she needs to restore this backup, he/she must copy the file to the correct folder and execute "bitcoin-qt -rescan". My suggestion: bitcoin-qt developers could implement an easier way to restore. For example: a option in the File menu "Restore Wallet" or "Recover Wallet" where it would show a dialog asking for the backup file and everything would be done automatically (no need to do it manually). If we want everybody to use bitcoin, these operations should be as easy as possible. What do you think? -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://www.libertarios.org.br Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL --- Re: [bitcoin-list] Suggestion: easy way to restore wallet.dat backup From: Dâniel Fraga - 2013-12-03 19:21:46 On Wed, 20 Nov 2013 13:53:52 -0200 Dâniel Fraga wrote: > Today, when a user uses bitcoin-qt client, it can make a backup > of wallet.dat easily through menu, but when he/she needs to restore > this backup, he/she must copy the file to the correct folder and > execute "bitcoin-qt -rescan". > > My suggestion: bitcoin-qt developers could implement an easier > way to restore. For example: a option in the File menu "Restore Wallet" > or "Recover Wallet" where it would show a dialog asking for the backup > file and everything would be done automatically (no need to do it > manually). > > If we want everybody to use bitcoin, these operations should > be as easy as possible. > > What do you think? Nobody? -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL --- Re: [bitcoin-list] Suggestion: easy way to restore wallet.dat backup From: Carlos Pizarro - 2013-12-03 20:57:26 I haven't seen a lot of activity on this list so maybe they moved to somewhere else ? On Tuesday, December 3, 2013, Dâniel Fraga wrote: > On Wed, 20 Nov 2013 13:53:52 -0200 > Dâniel Fraga > wrote: > > > Today, when a user uses bitcoin-qt client, it can make a backup > > of wallet.dat easily through menu, but when he/she needs to restore > > this backup, he/she must copy the file to the correct folder and > > execute "bitcoin-qt -rescan". > > > > My suggestion: bitcoin-qt developers could implement an easier > > way to restore. For example: a option in the File menu "Restore Wallet" > > or "Recover Wallet" where it would show a dialog asking for the backup > > file and everything would be done automatically (no need to do it > > manually). > > > > If we want everybody to use bitcoin, these operations should > > be as easy as possible. > > > > What do you think? > > Nobody? > > -- > Linux 3.12.0: One Giant Leap for Frogkind > http://www.youtube.com/DanielFragaBR > http://mcxnow.com > Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL > > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -- Atte, *Carlos Pizarro León* --- [bitcoin-list] Meeting place to discuss 'the decentralised internet' projects From: David Irvine - 2014-01-26 16:15:53 Hi sorry for barging in, but with all of the projects now based around decentralisation, I thought a common place to exchange ideas would be good. I have created a subreddit http://www.reddit.com/r/decentralisedinternet/as a place for as many projects to collaborate and share experiences, research and general comments. I am hoping to make this an open environment for discussion and technical debate, but not a place of project wars. This is essential and to that end I would like to engage with you and have you all sign up to the subreddit. I believe as we recodnise more projects then at least one person from each project should be a moderator. This should add stability and ensure that each project is protected as they all have their own path to follow. I suggest each project puts forward an admin and I will add them immediately. I believe there is enough of a push now to decentralise services and working together to achieve all of our goals can only be a good thing. Below is the sidebar text as it stands, this is all open for debate. ######################## This is a reddit of logic and not emotion, please base all debate on logic. We do not want project wars here, so no vim/emacs type debate between projects. Keep focussed and logical if at all possible. Whilst people will prefer one project over another, the point of this subreddit is to find the technically best solutions to the miriad of issues and share technology and discussion between projects. Advertising is not a goal of this subreddit, although new information about projects is encouraged. Submissions that are mostly about some other server based solutions belong elsewhere. Please avoid repetition — /r/decentralisedinternet is a subreddit devoted to new information and discussion about decentralisation of the Internet. New projects are welcome to announce themselves via this reddit, but after those have been announced they are no longer news and should not be re-posted. New news will be accepted. Aside from new project announcements, those interested in advertising to our audience should consider Reddit's self-serve advertising system. Projects so far (please request to be added by posting a link to your project, if it is upvoted and agreed by redditors to be accepted it will be added here) Freenet Tahoe bitcoin MaidSafe bitcloud twister ########################## I am sending this message to each of the projects mentioned and any others that should be included as we progress. -- David Irvine maidsafe.net ; twitter: @metaquestions blog: http://metaquestions.me --- [bitcoin-list] forever lost BTC number is growing dramatically From: s7r - 2014-02-28 01:28:04 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Watching the block chain explorer I saw that there are now over 2,5 MILLION XCP's (Counterparty cryptocurrency). Counterparty is a cryptocurrency to lazy to build its own network and it is using bitcoin's blockchain with the OP_RETURN function. XCP (counterparty) are issued based on a proof-of-burn BTC. Example: sending bitcoincs to an unspendable address, an address to which nobody has the private keys. Clearly, BTCs lost forever - this is how XCP's are issued. Now with over 2.5 million XCP's issued (automatically over 2.5 million BTC's lost forever), plus the coins lost due to accidents, negligence which are estimated to be more than 2.5 million including what mtgox may have lost forever due to their wallet problems and malleability attack - where are we going this cannot be good under any circumstances. Thoughts? U. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJTD+HSAAoJEIN/pSyBJlsRdkwIAKOq2upsZiL+C6yhKvPJ7hby /FZzXLP+VG6v55mKAVvoYPVPSfAEPYyaFrcIn95QMxSP9Ul5TLIZ+XAfOif+HSjo 1no2z4BhsmtzEwDm0YJeVqRG12eBwXRf2fcaicnIIuXQCaZwNZeLZfkFV/ahrRsH feRJILNv3sTx4N5O+DUXAEV31skJqo/AVRU1pc4tL0zvFSHq6nAiNViR11a3Jyme F/RFKkZx2HnEwSohOXPKkWxD3znleMr21PTYcDfSci66p+Vmm4NxvxpOX3GbI6Yc 90cnyozFsXFpBQEcvZAvYrC2IRgpoPHX+7xEFucYc5vALKU1uF25LLs+XGujSNE= =Yc6I -----END PGP SIGNATURE----- --- Re: [bitcoin-list] forever lost BTC number is growing dramatically From: Jameson Lopp - 2014-02-28 01:33:15 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It appears to me that you're completely overlooking the divisibility of bitcoins. - - Jameson On 02/27/2014 08:09 PM, s7r wrote: > Hi, > > Watching the block chain explorer I saw that there are now over 2,5 > MILLION XCP's (Counterparty cryptocurrency). > > Counterparty is a cryptocurrency to lazy to build its own network and > it is using bitcoin's blockchain with the OP_RETURN function. > > XCP (counterparty) are issued based on a proof-of-burn BTC. Example: > sending bitcoincs to an unspendable address, an address to which > nobody has the private keys. Clearly, BTCs lost forever - this is how > XCP's are issued. > > Now with over 2.5 million XCP's issued (automatically over 2.5 million > BTC's lost forever), plus the coins lost due to accidents, negligence > which are estimated to be more than 2.5 million including what mtgox > may have lost forever due to their wallet problems and malleability > attack - where are we going this cannot be good under any circumstances. > > Thoughts? > > U. > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTD+dTAAoJEIch3FSFNiDcGtQH/2G5SiPlnFHUbMtkc3/H7/rN tqmWRxe+oWiRI+mJwnsT87QPnt10uyrexL8/BB0P5pCbAYcrxbbD5VkCtDNSiUZk jG1Mvx+xiryLo+tlaLjvHPfvWuU/Wd7Xi2iWavcnyUq1diklevIKxOpGL5JuhlVi zPevN//pFhKtJk5xXJnGShcWvx+OCARIms6y3v8YdKUfT8D+2PSVxtD1mtdB/wcQ 8Mh8yj3i/2rYg8eYNF+9C98hd3SfA+V5DwP7CgZ0NXDM5dOEmCR9qrGzIIQC32ED Yxh+T/KVRIowFj8d/LoDFSjySSrOwllXuXgbAjcKtqjU16kZV0ZlJvC8I66KAwo= =7P/b -----END PGP SIGNATURE----- --- [bitcoin-list] Bitcoin theft countermeasure From: Stefan George - 2014-02-28 19:50:46 Hello Bitcoin-enthusiasts, I am new to this mailing list and would like to share/discuss an idea that crossed my mind today. To lower the rate of thefts in the future there are 2 possible ways: 1. Increase the security. E.g. use of multi sig wallets. 2. Decrease the value of thefts. For 2. stolen BTC have to be identified and there has to be a penalty for them. There are two problems with it: 1. Who has the responsibility to declare if a BTC is stolen or not and where is the information available? 2. BTC can spread over so many accounts easily and get new owners that it becomes very difficult to actually identify all stolen BTC and the penalty could affect people that didn't stole them. The idea: 1. The big damage can be caused by hacking the biggest exchanges that hold most of the Bitcoins (Coinbase, Kraken etc.). These exchanges should maintain and share a central database, where they mark BTC as stolen. This database can be read by anyone but only big and legally trustworthy services (exchanges) maintain them. 2. To lower the possibility to spread stolen BTC, clients can (optionally) check the database and refuse BTC that are listed here. Of course the theft will try to spread the BTC right after the theft. Therefore it should be possible to REFUSE to receive Bitcoins that have been involved in any transaction within the last 24h/48h (or just send them back). This way, if a big service detects a theft, it can act within 24h/48h to submit this info into the central database and the theft could not benefit from the stolen coins anymore. This is just an idea but it would be great to hear your thoughts! Thanks, Stefan --- Re: [bitcoin-list] Bitcoin theft countermeasure From: Jameson Lopp - 2014-02-28 19:56:17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Your idea is to implement a centralized blacklist whereby we would keep track of 'tainted coins.' This idea has been proposed in the past, and is in fact being made a commercial venture by the Coinvalidation folks. This is, in fact, a terrible idea for multiple reasons, but primarily because it would destroy the fungibility of bitcoins. Here's some relevant reading material on the matter: http://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/ http://www.reddit.com/r/Bitcoin/comments/1qnqn1/a_pledge_i_invite_you_to_help_us_stop_the_threats/ - - Jameson On 02/28/2014 02:32 PM, Stefan George wrote: > Hello Bitcoin-enthusiasts, > > I am new to this mailing list and would like to share/discuss an idea that > crossed my mind today. > > To lower the rate of thefts in the future there are 2 possible ways: > > 1. Increase the security. E.g. use of multi sig wallets. > 2. Decrease the value of thefts. > > For 2. stolen BTC have to be identified and there has to be a penalty for > them. > > There are two problems with it: > > 1. Who has the responsibility to declare if a BTC is stolen or not and where > is the information available? > 2. BTC can spread over so many accounts easily and get new owners that it > becomes very difficult to actually > identify all stolen BTC and the penalty could affect people that didn't > stole them. > > The idea: > 1. The big damage can be caused by hacking the biggest exchanges that hold > most of the Bitcoins (Coinbase, Kraken etc.). > These exchanges should maintain and share a central database, where they > mark BTC as stolen. > This database can be read by anyone but only big and legally trustworthy > services (exchanges) maintain them. > > 2. To lower the possibility to spread stolen BTC, clients can (optionally) > check the database and refuse BTC that are listed here. > Of course the theft will try to spread the BTC right after the theft. > Therefore it should be possible to REFUSE to receive Bitcoins > that have been involved in any transaction within the last 24h/48h (or just > send them back). This way, if a big service detects a theft, it can act > within > 24h/48h to submit this info into the central database and the theft could > not benefit from the stolen coins anymore. > > This is just an idea but it would be great to hear your thoughts! > > Thanks, > > Stefan > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTEOnRAAoJEIch3FSFNiDc9q8IAKzU0860HtlyvluHizwkn/TB /uKexUaA5bRMLqekEmFcS3koBqMPyyXRiPDqmy7aYJTAuLKfRtjkyS7BsgZ501PZ fZajah/cks+9TBZb2MZ8Wy9dVhDIAit6v/WJAxU4pUi/mm/+vPdqjf+RxpaM4Qzs mB9bB/G256WFPX5Zw+awY6N2n5uzrpUwg+V8fMCotrEBME2CD+iFFFX6j1P/RUtQ yWfERK3XwHGfd0dw3bFq+ck/DdPD1L75ePrDjWJ6wzSxhoP1+rBF051srpNHKFc8 ExPQT43SzKcft0q2vwweYROjAEhBa0xaQCXtwQH31UbbLAow6HAAwhl1xK4XF/c= =+BEI -----END PGP SIGNATURE----- --- [bitcoin-list] decentralized exchange user-to-user using contracts/multisig From: - 2014-03-02 01:29:31 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I want to build a marketplace where users can exchange bitcoin for fiat currencies without having to go through a centralized escrow or exchanger (directly user-to-user). This can be done by bitcoin multisign option (contracts) where 2 users can agree on a mediator and proceed with a transaction. The problem is: if the users don't go through a centralized escrow or exchanger and they don't add funds or add bitcoins to their accounts, how can we verify the authenticity of sell or buy postings and build a strong and accurate order book, without users being able to abuse it by posting abusive sell or buy offers which will break the supply and demand calculation for price determination. This is a real possible vulnerability since it's not a centralized system and users do not deposit funds in their accounts, you cannot verify if the user has or doesn't have the bitcoins or the fiat currency. Any suggestions? - -- U. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJTEollAAoJEIN/pSyBJlsRo3UIALEKep1mK1RL5EqftvMVZVTZ b1kUu1kxkznETvgv5da6QqOYMj3LF5QTDSAuuRCxyme98hRTITxpVxnFBWi+agLl hNeJl6wlYqWLINe3oQff1HQDzfcw6BPzy2wRkQFNTjdQla6KjhJ3/lO5Q5Pgdno0 rMpc3DCmhfAxRXl36tcn/4MLo4TeBR8OzxfpZo69K89q1Hd3+Wb3QGj2hf8vVMJP HoRhgrUh78r8d24qAHpTu+qECY1DdhyTx1GPqgNT6lp7tA+2LhkjDlq4tThUtuuc LZaI36ZrbgJv6P6PlmRQIb009sHQKxHBJVwkNXEG0DNbUF8Yw9zK67nEcsEUOIc= =Cl2L -----END PGP SIGNATURE----- --- Re: [bitcoin-list] decentralized exchange user-to-user using contracts/multisig From: Craig B Agricola - 2014-03-02 02:02:54 Only a half solution, but at least the BTC can be verified. Have them provide an address that they own, and have them sign a message with the signing key for that address. Now their BTC balance on the exchange is whatever is in that address. Obviously, that does nothing for fiat accountability, though. -Craig On Sun, Mar 02, 2014 at 03:29:09AM +0200, s7r@... wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I want to build a marketplace where users can exchange bitcoin for > fiat currencies without having to go through a centralized escrow or > exchanger (directly user-to-user). This can be done by bitcoin > multisign option (contracts) where 2 users can agree on a mediator and > proceed with a transaction. > > The problem is: if the users don't go through a centralized escrow or > exchanger and they don't add funds or add bitcoins to their accounts, > how can we verify the authenticity of sell or buy postings and build a > strong and accurate order book, without users being able to abuse it > by posting abusive sell or buy offers which will break the supply and > demand calculation for price determination. This is a real possible > vulnerability since it's not a centralized system and users do not > deposit funds in their accounts, you cannot verify if the user has or > doesn't have the bitcoins or the fiat currency. > > Any suggestions? > > > - -- > U. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > > iQEcBAEBAgAGBQJTEollAAoJEIN/pSyBJlsRo3UIALEKep1mK1RL5EqftvMVZVTZ > b1kUu1kxkznETvgv5da6QqOYMj3LF5QTDSAuuRCxyme98hRTITxpVxnFBWi+agLl > hNeJl6wlYqWLINe3oQff1HQDzfcw6BPzy2wRkQFNTjdQla6KjhJ3/lO5Q5Pgdno0 > rMpc3DCmhfAxRXl36tcn/4MLo4TeBR8OzxfpZo69K89q1Hd3+Wb3QGj2hf8vVMJP > HoRhgrUh78r8d24qAHpTu+qECY1DdhyTx1GPqgNT6lp7tA+2LhkjDlq4tThUtuuc > LZaI36ZrbgJv6P6PlmRQIb009sHQKxHBJVwkNXEG0DNbUF8Yw9zK67nEcsEUOIc= > =Cl2L > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- Re: [bitcoin-list] Bitcoin theft countermeasure From: Mike Hearn - 2014-03-02 11:05:42 You can read a couple of posts I made on the topic here: https://bitcointalk.org/index.php?topic=157130.0 https://bitcoinfoundation.org/forum/index.php?/topic/505-coin-tracking/ --- Re: [bitcoin-list] decentralized exchange user-to-user using contracts/multisig From: - 2014-03-02 12:26:54 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/2/2014 6:05 AM, James A. Donald wrote: > On 2014-03-02 11:29, s7r@... wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Hi, >> >> I want to build a marketplace where users can exchange bitcoin >> for fiat currencies without having to go through a centralized >> escrow or exchanger (directly user-to-user). This can be done by >> bitcoin multisign option (contracts) where 2 users can agree on a >> mediator and proceed with a transaction. >> >> The problem is: if the users don't go through a centralized >> escrow or exchanger and they don't add funds or add bitcoins to >> their accounts, how can we verify the authenticity of sell or buy >> postings and build a strong and accurate order book, without >> users being able to abuse it by posting abusive sell or buy >> offers which will break the supply and demand calculation for >> price determination. This is a real possible vulnerability since >> it's not a centralized system and users do not deposit funds in >> their accounts, you cannot verify if the user has or doesn't have >> the bitcoins or the fiat currency. > > You can verify that the user has the bitcoins. > > For the fiat currency, need a reputation system that looks like > silk road or ebay, but is decentralized. This is a problem, since > what is to stop someone from building reputation by doing a > thousand fake transactions with himself? > > This sybil attack could be defeated by clustering analysis, > identifying groups that give positive ratings to each other, but do > not receive positive ratings from outsiders. > > That sounds about right. So, to repeat, the system will create random groups of N users, chosen randomly by the system (the users cannot choose a group they want to be a part of) and reputation will be built only by people inside that group, nobody from outside will be able to positive or negative feedback? In this case, the chances for an malicious person to create 1000 fake accounts to transact with himself and all of them to be part of the same group are considerably smaller. Not inexistent, though. But in centralized exchangers, what prevents users from doing this? If a malicious person is willing and can afford to lose the exchanger fee of .5 or .7 or whatever, he can transact with himself manipulating the price with just the cost of the exchanger fee? I doubt the current exchangers have any protection against this what do you think? - -- PGP Public key: http://www.sky-ip.org/s7r@... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJTEyNgAAoJEIN/pSyBJlsRzSwIAMDwOJPPRaGxX5NjGDviO3Tu tD9opHU2S6mb820f31D0o+XlwKx+DA2yZ3M8GmGsEjEbESH//kJT2Dcvnpd4TLoC TwS2mfyEZDpWrdZuC/uULj5ZVl6PGDs+KVGvNNJwuuosUa9Ni8PHboyhW/sf5unJ xQGHfLtDnUu2T+w1fklvfOj+73nonf8499ueQCLGGaUSVtG2sTKRmb+RZVKwX588 6o06FvT+TbASTs+9K74gh/S/l9F9lmGlKcqVFFbsdU1124aQy03TiLTbRhrABCY/ E26AWjWW+3aPoK9Y244yi29KmncBcdvuO0A7OteyF6f9h3OcyCsQQd0s+gXUKDA= =PCLW -----END PGP SIGNATURE----- --- Re: [bitcoin-list] decentralized exchange user-to-user using contracts/multisig From: James A. Donald - 2014-03-02 23:13:20 On 3/2/2014 6:05 AM, James A. Donald wrote: >> For the fiat currency, need a reputation system that looks like >> silk road or ebay, but is decentralized. This is a problem, since >> what is to stop someone from building reputation by doing a >> thousand fake transactions with himself? >> >> This sybil attack could be defeated by clustering analysis, >> identifying groups that give positive ratings to each other, but do >> not receive positive ratings from outsiders. On 2014-03-02 22:26, s7r@... wrote: > But in centralized exchangers, what prevents users from doing this? The operator detects spamming, censors it, and penalizes it, just like any blog owner. --- [bitcoin-list] Bitcoin Core version 0.9.0 available From: Gavin Andresen - 2014-03-19 14:12:21 Bitcoin Core version 0.9.0 is now available from: https://bitcoin.org/bin/0.9.0/ This is a release candidate for a new major version. A major version brings both new features and bug fixes. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues How to Upgrade -------------- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), uninstall all earlier versions of Bitcoin, then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. On Windows, do not forget to uninstall all earlier versions of the Bitcoin client first, especially if you are switching to the 64-bit version. Windows 64-bit installer ------------------------- New in 0.9.0 is the Windows 64-bit version of the client. There have been frequent reports of users running out of virtual memory on 32-bit systems during the initial sync. Because of this it is recommended to install the 64-bit version if your system supports it. NOTE: Release candidate 2 Windows binaries are not code-signed; use PGP and the SHA256SUMS.asc file to make sure your binaries are correct. In the final 0.9.0 release, Windows setup.exe binaries will be code-signed. OSX 10.5 / 32-bit no longer supported ------------------------------------- 0.9.0 drops support for older Macs. The minimum requirements are now: * A 64-bit-capable CPU (see http://support.apple.com/kb/ht3696); * Mac OS 10.6 or later (see https://support.apple.com/kb/ht1633). Downgrading warnings -------------------- The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9 and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine). Rebranding to Bitcoin Core --------------------------- To reduce confusion between Bitcoin-the-network and Bitcoin-the-software we have renamed the reference client to Bitcoin Core. Autotools build system ----------------------- For 0.9.0 we switched to an autotools-based build system instead of individual (q)makefiles. Using the standard "./autogen.sh; ./configure; make" to build Bitcoin-Qt and bitcoind makes it easier for experienced open source developers to contribute to the project. Be sure to check doc/build-*.md for your platform before building from source. Bitcoin-cli ------------- Another change in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client. The RPC client functionality ("tell the running bitcoin daemon to do THIS") was split into a separate executable, 'bitcoin-cli'. The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two. `walletpassphrase` RPC ----------------------- The behavior of the `walletpassphrase` RPC when the wallet is already unlocked has changed between 0.8 and 0.9. The 0.8 behavior of `walletpassphrase` is to fail when the wallet is already unlocked: > walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 Error: Wallet is already unlocked (old unlock time stays) The new behavior of `walletpassphrase` is to set a new unlock time overriding the old one: > walletpassphrase 1000 walletunlocktime = now + 1000 > walletpassphrase 10 walletunlocktime = now + 10 (overriding the old unlock time) Transaction malleability-related fixes -------------------------------------- This release contains a few fixes for transaction ID (TXID) malleability issues: - -nospendzeroconfchange command-line option, to avoid spending zero-confirmation change - IsStandard() transaction rules tightened to prevent relaying and mining of mutated transactions - Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they spend the same outputs. - Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions. - New option: -zapwallettxes to rebuild the wallet's transaction information Transaction Fees ---------------- This release drops the default fee required to relay transactions across the network and for miners to consider the transaction in their blocks to 0.01mBTC per kilobyte. Note that getting a transaction relayed across the network does NOT guarantee that the transaction will be accepted by a miner; by default, miners fill their blocks with 50 kilobytes of high-priority transactions, and then with 700 kilobytes of the highest-fee-per-kilobyte transactions. The minimum relay/mining fee-per-kilobyte may be changed with the minrelaytxfee option. Note that previous releases incorrectly used the mintxfee setting to determine which low-priority transactions should be considered for inclusion in blocks. The wallet code still uses a default fee for low-priority transactions of 0.1mBTC per kilobyte. During periods of heavy transaction volume, even this fee may not be enough to get transactions confirmed quickly; the mintxfee option may be used to override the default. 0.9.0 Release notes ======================= RPC: - New notion of 'conflicted' transactions, reported as confirmations: -1 - 'listreceivedbyaddress' now provides tx ids - Add raw transaction hex to 'gettransaction' output - Updated help and tests for 'getreceivedby(account|address)' - In 'getblock', accept 2nd 'verbose' parameter, similar to getrawtransaction, but defaulting to 1 for backward compatibility - Add 'verifychain', to verify chain database at runtime - Add 'dumpwallet' and 'importwallet' RPCs - 'keypoolrefill' gains optional size parameter - Add 'getbestblockhash', to return tip of best chain - Add 'chainwork' (the total work done by all blocks since the genesis block) to 'getblock' output - Make RPC password resistant to timing attacks - Clarify help messages and add examples - Add 'getrawchangeaddress' call for raw transaction change destinations - Reject insanely high fees by default in 'sendrawtransaction' - Add RPC call 'decodescript' to decode a hex-encoded transaction script - Make 'validateaddress' provide redeemScript - Add 'getnetworkhashps' to get the calculated network hashrate - New RPC 'ping' command to request ping, new 'pingtime' and 'pingwait' fields in 'getpeerinfo' output - Adding new 'addrlocal' field to 'getpeerinfo' output - Add verbose boolean to 'getrawmempool' - Add rpc command 'getunconfirmedbalance' to obtain total unconfirmed balance - Explicitly ensure that wallet is unlocked in `importprivkey` - Add check for valid keys in `importprivkey` Command-line options: - New option: -nospendzeroconfchange to never spend unconfirmed change outputs - New option: -zapwallettxes to rebuild the wallet's transaction information - Rename option '-tor' to '-onion' to better reflect what it does - Add '-disablewallet' mode to let bitcoind run entirely without wallet (when built with wallet) - Update default '-rpcsslciphers' to include TLSv1.2 - make '-logtimestamps' default on and rework help-message - RPC client option: '-rpcwait', to wait for server start - Remove '-logtodebugger' - Allow `-noserver` with bitcoind Block-chain handling and storage: - Update leveldb to 1.15 - Check for correct genesis (prevent cases where a datadir from the wrong network is accidentally loaded) - Allow txindex to be removed and add a reindex dialog - Log aborted block database rebuilds - Store orphan blocks in serialized form, to save memory - Limit the number of orphan blocks in memory to 750 - Fix non-standard disconnected transactions causing mempool orphans - Add a new checkpoint at block 279,000 Wallet: - Bug fixes and new regression tests to correctly compute the balance of wallets containing double-spent (or mutated) transactions - Store key creation time. Calculate whole-wallet birthday. - Optimize rescan to skip blocks prior to birthday - Let user select wallet file with -wallet=foo.dat - Consider generated coins mature at 101 instead of 120 blocks - Improve wallet load time - Don't count txins for priority to encourage sweeping - Don't create empty transactions when reading a corrupted wallet - Fix rescan to start from beginning after importprivkey - Only create signatures with low S values Mining: - Increase default -blockmaxsize/prioritysize to 750K/50K - 'getblocktemplate' does not require a key to create a block template - Mining code fee policy now matches relay fee policy Protocol and network: - Drop the fee required to relay a transaction to 0.01mBTC per kilobyte - Send tx relay flag with version - New 'reject' P2P message (BIP 0061, see https://gist.github.com/gavinandresen/7079034 for draft) - Dump addresses every 15 minutes instead of 10 seconds - Relay OP_RETURN data TxOut as standard transaction type - Remove CENT-output free transaction rule when relaying - Lower maximum size for free transaction creation - Send multiple inv messages if mempool.size > MAX_INV_SZ - Split MIN_PROTO_VERSION into INIT_PROTO_VERSION and MIN_PEER_PROTO_VERSION - Do not treat fFromMe transaction differently when broadcasting - Process received messages one at a time without sleeping between messages - Improve logging of failed connections - Bump protocol version to 70002 - Add some additional logging to give extra network insight - Added new DNS seed from bitcoinstats.com Validation: - Log reason for non-standard transaction rejection - Prune provably-unspendable outputs, and adapt consistency check for it. - Detect any sufficiently long fork and add a warning - Call the -alertnotify script when we see a long or invalid fork - Fix multi-block reorg transaction resurrection - Reject non-canonically-encoded serialization sizes - Reject dust amounts during validation - Accept nLockTime transactions that finalize in the next block Build system: - Switch to autotools-based build system - Build without wallet by passing `--disable-wallet` to configure, this removes the BerkeleyDB dependency - Upgrade gitian dependencies (libpng, libz, libupnpc, boost, openssl) to more recent versions - Windows 64-bit build support - Solaris compatibility fixes - Check integrity of gitian input source tarballs - Enable full GCC Stack-smashing protection for all OSes GUI: - Switch to Qt 5.2.0 for Windows build - Add payment request (BIP 0070) support - Improve options dialog - Show transaction fee in new send confirmation dialog - Add total balance in overview page - Allow user to choose data directory on first start, when data directory is missing, or when the -choosedatadir option is passed - Save and restore window positions - Add vout index to transaction id in transactions details dialog - Add network traffic graph in debug window - Add open URI dialog - Add Coin Control Features - Improve receive coins workflow: make the 'Receive' tab into a form to request payments, and move historical address list functionality to File menu. - Rebrand to `Bitcoin Core` - Move initialization/shutdown to a thread. This prevents "Not responding" messages during startup. Also show a window during shutdown. - Don't regenerate autostart link on every client startup - Show and store message of normal bitcoin:URI - Fix richtext detection hang issue on very old Qt versions - OS X: Make use of the 10.8+ user notification center to display Growl-like notifications - OS X: Added NSHighResolutionCapable flag to Info.plist for better font rendering on Retina displays. - OS X: Fix bitcoin-qt startup crash when clicking dock icon - Linux: Fix Gnome bitcoin: URI handler Miscellaneous: - Add Linux script (contrib/qos/tc.sh) to limit outgoing bandwidth - Add '-regtest' mode, similar to testnet but private with instant block generation with 'setgenerate' RPC. - Add 'linearize.py' script to contrib, for creating bootstrap.dat - Add separate bitcoin-cli client Credits -------- Thanks to everyone who contributed to this release: - Andrey - Ashley Holman - b6393ce9-d324-4fe1-996b-acf82dbc3d53 - bitsofproof - Brandon Dahler - Calvin Tam - Christian Decker - Christian von Roques - Christopher Latham - Chuck - coblee - constantined - Cory Fields - Cozz Lovan - daniel - Daniel Larimer - David Hill - Dmitry Smirnov - Drak - Eric Lombrozo - fanquake - fcicq - Florin - frewil - Gavin Andresen - Gregory Maxwell - gubatron - Guillermo Céspedes Tabárez - Haakon Nilsen - HaltingState - Han Lin Yap - harry - Ian Kelling - Jeff Garzik - Johnathan Corgan - Jonas Schnelli - Josh Lehan - Josh Triplett - Julian Langschaedel - Kangmo - Lake Denman - Luke Dashjr - Mark Friedenbach - Matt Corallo - Michael Bauer - Michael Ford - Michagogo - Midnight Magic - Mike Hearn - Nils Schneider - Noel Tiernan - Olivier Langlois - patrick s - Patrick Strateman - paveljanik - Peter Todd - phantomcircuit - phelixbtc - Philip Kaufmann - Pieter Wuille - Rav3nPL - R E Broadley - regergregregerrge - Robert Backhaus - Roman Mindalev - Rune K. Svendsen - Ryan Niebur - Scott Ellis - Scott Willeke - Sergey Kazenyuk - Shawn Wilkinson - Sined - sje - Subo1978 - super3 - Tamas Blummer - theuni - Thomas Holenstein - Timon Rapp - Timothy Stranex - Tom Geller - Torstein Husebø - Vaclav Vobornik - vhf / victor felder - Vinnie Falco - Warren Togami - Wil Bown - Wladimir J. van der Laan --- [bitcoin-list] Difficulty adjustment mechanism From: s7r - 2014-09-13 13:32:06 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I have an contradictory discussion with an altcoin supporter and want to bring some solid arguments in a public talk, so require little help to respond to a question with simplest answer. The problem is within the difficulty adjustment mechanism, that it happens at every 2016 blocks. In case the hash power will suddenly decrease, the 2016 blocks will take a lot of time to solve, therefor freeze the network in a non-operational way. I know by far this is just a joke, because this is very unlikely to happen anytime (people paid for mining equipment and make money) but for the sake of discussion, let's just assume it 'could' happen. Can this really freeze the network for unlimited time and bitcoin has no mechanism to balance it back? A resourceful party with the intent to attack the network in an irrational way, brings lot of hashing power and keeps it for 2016 blocks, then removes it leaving the other 2016 blocks to solve at very high difficulty but with low hash power in the network causing a 'blackout'? Thank you in advance for your answers. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUFEOHAAoJEIN/pSyBJlsR3OgIAL0fvQ6MoftEdqoMZUHpjdYT bRE6pXY52O5YIznaVljfbtQinApdWQUJ50VpiJd7KX3zOWFeo+KoUHyYlXTwoUEw fK1cbrA5KC8IogHfTCcQxP/lE0mxgCSW3/vQda71IWaOyU4MUT2BSZ/4wwMctI4f 8tNVPPmzPo/wpO0+NOejowsGLmuzfzy0RMwCTXSbhPJuXr3yvdOTjzkfgy4TsJSU K4RmBxqDh6LCrMQTpJfvqCUVEyqckG3AITQ2txdnWiMq1Ep94mvXb2L94Galmz00 yQzvo9F+G9HL0KgBAmZMrlFjsm58YDTblMTRKzBipozfuOk113XUecV+jHBvBrU= =tcCa -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Difficulty adjustment mechanism From: Jeff Garzik - 2014-09-13 14:05:11 This is why testnet has a special rule: If 20 minutes passes without a block, you may mine a diff-1 block. On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there, > > I have an contradictory discussion with an altcoin supporter and want > to bring some solid arguments in a public talk, so require little help > to respond to a question with simplest answer. > > The problem is within the difficulty adjustment mechanism, that it > happens at every 2016 blocks. In case the hash power will suddenly > decrease, the 2016 blocks will take a lot of time to solve, therefor > freeze the network in a non-operational way. I know by far this is > just a joke, because this is very unlikely to happen anytime (people > paid for mining equipment and make money) but for the sake of > discussion, let's just assume it 'could' happen. > > Can this really freeze the network for unlimited time and bitcoin has > no mechanism to balance it back? A resourceful party with the intent > to attack the network in an irrational way, brings lot of hashing > power and keeps it for 2016 blocks, then removes it leaving the other > 2016 blocks to solve at very high difficulty but with low hash power > in the network causing a 'blackout'? Thank you in advance for your > answers. > > > - -- > s7r > PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBAgAGBQJUFEOHAAoJEIN/pSyBJlsR3OgIAL0fvQ6MoftEdqoMZUHpjdYT > bRE6pXY52O5YIznaVljfbtQinApdWQUJ50VpiJd7KX3zOWFeo+KoUHyYlXTwoUEw > fK1cbrA5KC8IogHfTCcQxP/lE0mxgCSW3/vQda71IWaOyU4MUT2BSZ/4wwMctI4f > 8tNVPPmzPo/wpO0+NOejowsGLmuzfzy0RMwCTXSbhPJuXr3yvdOTjzkfgy4TsJSU > K4RmBxqDh6LCrMQTpJfvqCUVEyqckG3AITQ2txdnWiMq1Ep94mvXb2L94Galmz00 > yQzvo9F+G9HL0KgBAmZMrlFjsm58YDTblMTRKzBipozfuOk113XUecV+jHBvBrU= > =tcCa > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --- Re: [bitcoin-list] Difficulty adjustment mechanism From: s7r - 2014-09-13 15:54:50 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/2014 4:52 PM, Boussac wrote: > Hello, > > If the hashing power of the attacker is in the order of 50%, then > he can disrupt the network in several ways, including > double-spending and the blackout attack you are describing. > > Bitcoin makes only the assumption that there is a majority of > honest node. If you break the assuption, you disrupt the network > for as long as the assumption is broken. > > Back to your question, If the hashing power of the attacker is in > the order of 10%, the average time interval between blocks is > increased by 10%, i.e 1 minute when he pulls out of mining. > > That is until the next difficulty adjustement, roughly 2 weeks and > 36 hours later. Hardly a "blackout". > Indeed, but the scenario changes if the power is 80% if the hashing power. If immediately after a difficulty adjustment the hashing power drops by 80%, it will take way lot longer until the next difficulty adjustment. The next 2016 blocks will be solved much much slower preventing the correct functionality of the network, regardless if all the remaining peers and miners are honest. This is what matters, an assumption of this type of attack but with > 60% of the hashing power - 10% won't do a lot of damage and hardly create a blackout as you say. > Pierre > > Le 13 sept. 2014 à 15:15, s7r a écrit : > > Hi there, > > I have an contradictory discussion with an altcoin supporter and > want to bring some solid arguments in a public talk, so require > little help to respond to a question with simplest answer. > > The problem is within the difficulty adjustment mechanism, that it > happens at every 2016 blocks. In case the hash power will suddenly > decrease, the 2016 blocks will take a lot of time to solve, > therefor freeze the network in a non-operational way. I know by far > this is just a joke, because this is very unlikely to happen > anytime (people paid for mining equipment and make money) but for > the sake of discussion, let's just assume it 'could' happen. > > Can this really freeze the network for unlimited time and bitcoin > has no mechanism to balance it back? A resourceful party with the > intent to attack the network in an irrational way, brings lot of > hashing power and keeps it for 2016 blocks, then removes it leaving > the other 2016 blocks to solve at very high difficulty but with low > hash power in the network causing a 'blackout'? Thank you in > advance for your answers. > > >> >> ------------------------------------------------------------------------------ >> >> Want excitement? >> Manually upgrade your production database. When you want >> reliability, choose Perforce Perforce version control. >> Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> bitcoin-list mailing list bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUFGiuAAoJEIN/pSyBJlsRDGgH/RMuUUHJw7rMlDzOWF9qNzpQ UgNBzqqwRXkNWsvhGdPbOySnDtqh+yhhohSWn8C7LD6MvcnynqAf5+tSlbWrphAl Zopkj/EZ7TwionXAwV53V3fb6GKxTT5RIatvz16OW2veMPgnIyrH+WCcp7JoXVCr /fHx0ODVAyidGuql/pQtPfNGDoTCT5jFIiJ3t+Q6MqP2SvBNkY7miUybC1tiC82c I8Sw2330O/4Tb2kZCGtz9bAKqxNXoz3Ph8R4d8XbRsZB9k3XXvkG1y+pnHhcwJ4j 5ykFl6oHDp+0xwKMdS6Y9MRHn46FEf0q1gtHg4dw9FpOQ9MQGqa6Fz8KKUB5POg= =BtaY -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Difficulty adjustment mechanism From: s7r - 2014-09-13 16:01:09 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/2014 5:04 PM, Jeff Garzik wrote: > This is why testnet has a special rule: If 20 minutes passes > without a block, you may mine a diff-1 block. > Thanks for your point of view Mr. Garzik. Why aren't we using this in the real bitcoin network too? If it's good for balancing the functionality of the network in the context of sudden hashrate moves? Specially down moves, since if the hash power goes UP, the network will see blocks are created more often than at every 10 minutes and adjust the difficulty directly proportional, correct? > > On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: Hi > there, > > I have an contradictory discussion with an altcoin supporter and > want to bring some solid arguments in a public talk, so require > little help to respond to a question with simplest answer. > > The problem is within the difficulty adjustment mechanism, that it > happens at every 2016 blocks. In case the hash power will suddenly > decrease, the 2016 blocks will take a lot of time to solve, > therefor freeze the network in a non-operational way. I know by far > this is just a joke, because this is very unlikely to happen > anytime (people paid for mining equipment and make money) but for > the sake of discussion, let's just assume it 'could' happen. > > Can this really freeze the network for unlimited time and bitcoin > has no mechanism to balance it back? A resourceful party with the > intent to attack the network in an irrational way, brings lot of > hashing power and keeps it for 2016 blocks, then removes it leaving > the other 2016 blocks to solve at very high difficulty but with low > hash power in the network causing a 'blackout'? Thank you in > advance for your answers. > > >> >> ------------------------------------------------------------------------------ >> >> Want excitement? >> Manually upgrade your production database. When you want >> reliability, choose Perforce Perforce version control. >> Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> bitcoin-list mailing list bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUFGo4AAoJEIN/pSyBJlsR3d0IAISkymj6mxOkifdmp6ujUL4y 7lVoROugxAKTen9Fhg4rtWC10HQkTClJVfmaUYb+3D+oJ6YFjvZeyYT9TxFBrnvC JfKG6m/yc9yp/R1MwSL81ez8TQvBt1UUVZcxApYW1TWXJDH95ua5IakQDkag/dET HUtCAabPTDtQf0UaFqcycVXcXRYjvH73pOOD5j4WBeW1M2kd7pLm9Zdh1Up7nWVK hfISwfq2S39vMBb5474/WP38YymW0izjh9yrxMaNT3MeuxR3PUo5ue9O470+YP5Y 5k03vs+qF3GWYRIy+13x//WeiYPQQxONjxb4+mgcfoYpXjx611VKPpYjZGarTNU= =JCev -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Difficulty adjustment mechanism From: Jeff Garzik - 2014-09-13 16:34:32 Why not on mainnet? It is simply much lower priority for bitcoin today than other problems. It tends not to happen at higher difficulties for a variety of reasons. The difficulty adjustment is capped at a factor of 4, up or down, to address some other attacks that can happen in mining. Personally, I think there needs to be a mainnet safety rule such as "if 24 hours goes by without a block, you may mine a block" etc. But I readily admit I've not thought through all the ramifications of such a policy. On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 9/13/2014 5:04 PM, Jeff Garzik wrote: >> This is why testnet has a special rule: If 20 minutes passes >> without a block, you may mine a diff-1 block. >> > > Thanks for your point of view Mr. Garzik. > Why aren't we using this in the real bitcoin network too? If it's good > for balancing the functionality of the network in the context of > sudden hashrate moves? Specially down moves, since if the hash power > goes UP, the network will see blocks are created more often than at > every 10 minutes and adjust the difficulty directly proportional, correct? > >> >> On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: Hi >> there, >> >> I have an contradictory discussion with an altcoin supporter and >> want to bring some solid arguments in a public talk, so require >> little help to respond to a question with simplest answer. >> >> The problem is within the difficulty adjustment mechanism, that it >> happens at every 2016 blocks. In case the hash power will suddenly >> decrease, the 2016 blocks will take a lot of time to solve, >> therefor freeze the network in a non-operational way. I know by far >> this is just a joke, because this is very unlikely to happen >> anytime (people paid for mining equipment and make money) but for >> the sake of discussion, let's just assume it 'could' happen. >> >> Can this really freeze the network for unlimited time and bitcoin >> has no mechanism to balance it back? A resourceful party with the >> intent to attack the network in an irrational way, brings lot of >> hashing power and keeps it for 2016 blocks, then removes it leaving >> the other 2016 blocks to solve at very high difficulty but with low >> hash power in the network causing a 'blackout'? Thank you in >> advance for your answers. >> >> >>> >>> ------------------------------------------------------------------------------ >>> >>> > Want excitement? >>> Manually upgrade your production database. When you want >>> reliability, choose Perforce Perforce version control. >>> Predictably reliable. >>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>> >>> > _______________________________________________ >>> bitcoin-list mailing list bitcoin-list@... >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >> >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBAgAGBQJUFGo4AAoJEIN/pSyBJlsR3d0IAISkymj6mxOkifdmp6ujUL4y > 7lVoROugxAKTen9Fhg4rtWC10HQkTClJVfmaUYb+3D+oJ6YFjvZeyYT9TxFBrnvC > JfKG6m/yc9yp/R1MwSL81ez8TQvBt1UUVZcxApYW1TWXJDH95ua5IakQDkag/dET > HUtCAabPTDtQf0UaFqcycVXcXRYjvH73pOOD5j4WBeW1M2kd7pLm9Zdh1Up7nWVK > hfISwfq2S39vMBb5474/WP38YymW0izjh9yrxMaNT3MeuxR3PUo5ue9O470+YP5Y > 5k03vs+qF3GWYRIy+13x//WeiYPQQxONjxb4+mgcfoYpXjx611VKPpYjZGarTNU= > =JCev > -----END PGP SIGNATURE----- -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --- Re: [bitcoin-list] Difficulty adjustment mechanism From: s7r - 2014-09-13 16:45:37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/2014 7:34 PM, Jeff Garzik wrote: > Why not on mainnet? It is simply much lower priority for bitcoin > today than other problems. It tends not to happen at higher > difficulties for a variety of reasons. > > The difficulty adjustment is capped at a factor of 4, up or down, > to address some other attacks that can happen in mining. > Capped at a factor of 4, up or down? How exactly in a simple example? > Personally, I think there needs to be a mainnet safety rule such > as "if 24 hours goes by without a block, you may mine a block" etc. > But I readily admit I've not thought through all the ramifications > of such a policy. > > > > On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: > > > On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>>> This is why testnet has a special rule: If 20 minutes >>>> passes without a block, you may mine a diff-1 block. >>>> > > Thanks for your point of view Mr. Garzik. Why aren't we using this > in the real bitcoin network too? If it's good for balancing the > functionality of the network in the context of sudden hashrate > moves? Specially down moves, since if the hash power goes UP, the > network will see blocks are created more often than at every 10 > minutes and adjust the difficulty directly proportional, correct? > >>>> >>>> On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: >>>> Hi there, >>>> >>>> I have an contradictory discussion with an altcoin supporter >>>> and want to bring some solid arguments in a public talk, so >>>> require little help to respond to a question with simplest >>>> answer. >>>> >>>> The problem is within the difficulty adjustment mechanism, >>>> that it happens at every 2016 blocks. In case the hash power >>>> will suddenly decrease, the 2016 blocks will take a lot of >>>> time to solve, therefor freeze the network in a >>>> non-operational way. I know by far this is just a joke, >>>> because this is very unlikely to happen anytime (people paid >>>> for mining equipment and make money) but for the sake of >>>> discussion, let's just assume it 'could' happen. >>>> >>>> Can this really freeze the network for unlimited time and >>>> bitcoin has no mechanism to balance it back? A resourceful >>>> party with the intent to attack the network in an irrational >>>> way, brings lot of hashing power and keeps it for 2016 >>>> blocks, then removes it leaving the other 2016 blocks to >>>> solve at very high difficulty but with low hash power in the >>>> network causing a 'blackout'? Thank you in advance for your >>>> answers. >>>> >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> > >>>>> Want excitement? >>>>> Manually upgrade your production database. When you want >>>>> reliability, choose Perforce Perforce version control. >>>>> Predictably reliable. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>>> >>>>> > >>>>> _______________________________________________ >>>>> bitcoin-list mailing list >>>>> bitcoin-list@... >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>>> >>>> >>>> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUFHSeAAoJEIN/pSyBJlsRQ7gH/3iB0sy4PRi03dbcq5mKiwc4 aBlG2zt8rVRqX6KkCoeijY4lysg3KYzhyBBUna4bwGAhpvBe0jjybEWFAMqM2h6+ 7JzUdcZ9K5HuOtQUY2/4jHAz6jg3LOCBvtJUmLtC1HGSGHSl0tFiRVc2bzWrIOsT zkq87G3ocfSNiQSRSKqhxM1W4tc1BUHBr6T0ZS2EyArZljnIN5WVfw3ueTPZizdM q51+krxBjIW5iEkS4pVNChlsMaMca6JLVOY8jJpEWDf0vTX9zsheMdDg0MyDfMn5 ObywubBmV+tawNsHU7DWwliIiCoMr2h2G7KpV8V/np1iVyaSribaIj1hM/rWvh8= =Q1i9 -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Difficulty adjustment mechanism From: Jeff Garzik - 2014-09-13 17:00:44 If difficulty is X, range for adjustment is X/4 to X*4. On Sat, Sep 13, 2014 at 12:45 PM, s7r wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 9/13/2014 7:34 PM, Jeff Garzik wrote: >> Why not on mainnet? It is simply much lower priority for bitcoin >> today than other problems. It tends not to happen at higher >> difficulties for a variety of reasons. >> >> The difficulty adjustment is capped at a factor of 4, up or down, >> to address some other attacks that can happen in mining. >> > Capped at a factor of 4, up or down? How exactly in a simple example? > >> Personally, I think there needs to be a mainnet safety rule such >> as "if 24 hours goes by without a block, you may mine a block" etc. >> But I readily admit I've not thought through all the ramifications >> of such a policy. >> >> >> >> On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: >> >> >> On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>>>> This is why testnet has a special rule: If 20 minutes >>>>> passes without a block, you may mine a diff-1 block. >>>>> >> >> Thanks for your point of view Mr. Garzik. Why aren't we using this >> in the real bitcoin network too? If it's good for balancing the >> functionality of the network in the context of sudden hashrate >> moves? Specially down moves, since if the hash power goes UP, the >> network will see blocks are created more often than at every 10 >> minutes and adjust the difficulty directly proportional, correct? >> >>>>> >>>>> On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: >>>>> Hi there, >>>>> >>>>> I have an contradictory discussion with an altcoin supporter >>>>> and want to bring some solid arguments in a public talk, so >>>>> require little help to respond to a question with simplest >>>>> answer. >>>>> >>>>> The problem is within the difficulty adjustment mechanism, >>>>> that it happens at every 2016 blocks. In case the hash power >>>>> will suddenly decrease, the 2016 blocks will take a lot of >>>>> time to solve, therefor freeze the network in a >>>>> non-operational way. I know by far this is just a joke, >>>>> because this is very unlikely to happen anytime (people paid >>>>> for mining equipment and make money) but for the sake of >>>>> discussion, let's just assume it 'could' happen. >>>>> >>>>> Can this really freeze the network for unlimited time and >>>>> bitcoin has no mechanism to balance it back? A resourceful >>>>> party with the intent to attack the network in an irrational >>>>> way, brings lot of hashing power and keeps it for 2016 >>>>> blocks, then removes it leaving the other 2016 blocks to >>>>> solve at very high difficulty but with low hash power in the >>>>> network causing a 'blackout'? Thank you in advance for your >>>>> answers. >>>>> >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >> >>>>>> > Want excitement? >>>>>> Manually upgrade your production database. When you want >>>>>> reliability, choose Perforce Perforce version control. >>>>>> Predictably reliable. >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>>>> >>>>>> >> >>>>>> > _______________________________________________ >>>>>> bitcoin-list mailing list >>>>>> bitcoin-list@... >>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>>>> >>>>> >>>>> >> >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBAgAGBQJUFHSeAAoJEIN/pSyBJlsRQ7gH/3iB0sy4PRi03dbcq5mKiwc4 > aBlG2zt8rVRqX6KkCoeijY4lysg3KYzhyBBUna4bwGAhpvBe0jjybEWFAMqM2h6+ > 7JzUdcZ9K5HuOtQUY2/4jHAz6jg3LOCBvtJUmLtC1HGSGHSl0tFiRVc2bzWrIOsT > zkq87G3ocfSNiQSRSKqhxM1W4tc1BUHBr6T0ZS2EyArZljnIN5WVfw3ueTPZizdM > q51+krxBjIW5iEkS4pVNChlsMaMca6JLVOY8jJpEWDf0vTX9zsheMdDg0MyDfMn5 > ObywubBmV+tawNsHU7DWwliIiCoMr2h2G7KpV8V/np1iVyaSribaIj1hM/rWvh8= > =Q1i9 > -----END PGP SIGNATURE----- -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --- Re: [bitcoin-list] Difficulty adjustment mechanism From: Michael Wozniak - 2014-09-13 17:05:34 The biggest problem with a time based rule is that there is no central time to provide a measure of how much time has actually passed. You can see this issue on testnet already because block timestamps are modified. For example, the current time is (according to my server) 1410626564 and the best block on testnet shows a timestamp of 1410628433 (30 minutes in the future). On Sep 13, 2014, at 12:34 PM, Jeff Garzik wrote: > Why not on mainnet? It is simply much lower priority for bitcoin > today than other problems. It tends not to happen at higher > difficulties for a variety of reasons. > > The difficulty adjustment is capped at a factor of 4, up or down, to > address some other attacks that can happen in mining. > > Personally, I think there needs to be a mainnet safety rule such as > "if 24 hours goes by without a block, you may mine a block" etc. But > I readily admit I've not thought through all the ramifications of such > a policy. > > > > On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>> This is why testnet has a special rule: If 20 minutes passes >>> without a block, you may mine a diff-1 block. >>> >> >> Thanks for your point of view Mr. Garzik. >> Why aren't we using this in the real bitcoin network too? If it's good >> for balancing the functionality of the network in the context of >> sudden hashrate moves? Specially down moves, since if the hash power >> goes UP, the network will see blocks are created more often than at >> every 10 minutes and adjust the difficulty directly proportional, correct? >> >>> >>> On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: Hi >>> there, >>> >>> I have an contradictory discussion with an altcoin supporter and >>> want to bring some solid arguments in a public talk, so require >>> little help to respond to a question with simplest answer. >>> >>> The problem is within the difficulty adjustment mechanism, that it >>> happens at every 2016 blocks. In case the hash power will suddenly >>> decrease, the 2016 blocks will take a lot of time to solve, >>> therefor freeze the network in a non-operational way. I know by far >>> this is just a joke, because this is very unlikely to happen >>> anytime (people paid for mining equipment and make money) but for >>> the sake of discussion, let's just assume it 'could' happen. >>> >>> Can this really freeze the network for unlimited time and bitcoin >>> has no mechanism to balance it back? A resourceful party with the >>> intent to attack the network in an irrational way, brings lot of >>> hashing power and keeps it for 2016 blocks, then removes it leaving >>> the other 2016 blocks to solve at very high difficulty but with low >>> hash power in the network causing a 'blackout'? Thank you in >>> advance for your answers. >>> >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >> Want excitement? >>>> Manually upgrade your production database. When you want >>>> reliability, choose Perforce Perforce version control. >>>> Predictably reliable. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>> >>>> >> _______________________________________________ >>>> bitcoin-list mailing list bitcoin-list@... >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>> >>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBAgAGBQJUFGo4AAoJEIN/pSyBJlsR3d0IAISkymj6mxOkifdmp6ujUL4y >> 7lVoROugxAKTen9Fhg4rtWC10HQkTClJVfmaUYb+3D+oJ6YFjvZeyYT9TxFBrnvC >> JfKG6m/yc9yp/R1MwSL81ez8TQvBt1UUVZcxApYW1TWXJDH95ua5IakQDkag/dET >> HUtCAabPTDtQf0UaFqcycVXcXRYjvH73pOOD5j4WBeW1M2kd7pLm9Zdh1Up7nWVK >> hfISwfq2S39vMBb5474/WP38YymW0izjh9yrxMaNT3MeuxR3PUo5ue9O470+YP5Y >> 5k03vs+qF3GWYRIy+13x//WeiYPQQxONjxb4+mgcfoYpXjx611VKPpYjZGarTNU= >> =JCev >> -----END PGP SIGNATURE----- > > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- Re: [bitcoin-list] Difficulty adjustment mechanism From: Jeff Garzik - 2014-09-13 17:09:13 That is conflating two different things. Block timestamps are never "modified." Miners are permitted to mine timestamps within a certain time range (e.g. no more than 2 hours into the future). That is normal for testnet or mainnet. On Sat, Sep 13, 2014 at 12:45 PM, Michael Wozniak wrote: > The biggest problem with a time based rule is that there is no central time to provide a measure of how much time has actually passed. You can see this issue on testnet already because block timestamps are modified. For example, the current time is (according to my server) 1410626564 and the best block on testnet shows a timestamp of 1410628433 (30 minutes in the future). > > > > On Sep 13, 2014, at 12:34 PM, Jeff Garzik wrote: > >> Why not on mainnet? It is simply much lower priority for bitcoin >> today than other problems. It tends not to happen at higher >> difficulties for a variety of reasons. >> >> The difficulty adjustment is capped at a factor of 4, up or down, to >> address some other attacks that can happen in mining. >> >> Personally, I think there needs to be a mainnet safety rule such as >> "if 24 hours goes by without a block, you may mine a block" etc. But >> I readily admit I've not thought through all the ramifications of such >> a policy. >> >> >> >> On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>> On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>>> This is why testnet has a special rule: If 20 minutes passes >>>> without a block, you may mine a diff-1 block. >>>> >>> >>> Thanks for your point of view Mr. Garzik. >>> Why aren't we using this in the real bitcoin network too? If it's good >>> for balancing the functionality of the network in the context of >>> sudden hashrate moves? Specially down moves, since if the hash power >>> goes UP, the network will see blocks are created more often than at >>> every 10 minutes and adjust the difficulty directly proportional, correct? >>> >>>> >>>> On Sat, Sep 13, 2014 at 9:15 AM, s7r wrote: Hi >>>> there, >>>> >>>> I have an contradictory discussion with an altcoin supporter and >>>> want to bring some solid arguments in a public talk, so require >>>> little help to respond to a question with simplest answer. >>>> >>>> The problem is within the difficulty adjustment mechanism, that it >>>> happens at every 2016 blocks. In case the hash power will suddenly >>>> decrease, the 2016 blocks will take a lot of time to solve, >>>> therefor freeze the network in a non-operational way. I know by far >>>> this is just a joke, because this is very unlikely to happen >>>> anytime (people paid for mining equipment and make money) but for >>>> the sake of discussion, let's just assume it 'could' happen. >>>> >>>> Can this really freeze the network for unlimited time and bitcoin >>>> has no mechanism to balance it back? A resourceful party with the >>>> intent to attack the network in an irrational way, brings lot of >>>> hashing power and keeps it for 2016 blocks, then removes it leaving >>>> the other 2016 blocks to solve at very high difficulty but with low >>>> hash power in the network causing a 'blackout'? Thank you in >>>> advance for your answers. >>>> >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>> Want excitement? >>>>> Manually upgrade your production database. When you want >>>>> reliability, choose Perforce Perforce version control. >>>>> Predictably reliable. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>>> >>>>> >>> _______________________________________________ >>>>> bitcoin-list mailing list bitcoin-list@... >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>>> >>>> >>>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> >>> iQEcBAEBAgAGBQJUFGo4AAoJEIN/pSyBJlsR3d0IAISkymj6mxOkifdmp6ujUL4y >>> 7lVoROugxAKTen9Fhg4rtWC10HQkTClJVfmaUYb+3D+oJ6YFjvZeyYT9TxFBrnvC >>> JfKG6m/yc9yp/R1MwSL81ez8TQvBt1UUVZcxApYW1TWXJDH95ua5IakQDkag/dET >>> HUtCAabPTDtQf0UaFqcycVXcXRYjvH73pOOD5j4WBeW1M2kd7pLm9Zdh1Up7nWVK >>> hfISwfq2S39vMBb5474/WP38YymW0izjh9yrxMaNT3MeuxR3PUo5ue9O470+YP5Y >>> 5k03vs+qF3GWYRIy+13x//WeiYPQQxONjxb4+mgcfoYpXjx611VKPpYjZGarTNU= >>> =JCev >>> -----END PGP SIGNATURE----- >> >> >> >> -- >> Jeff Garzik >> Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> bitcoin-list mailing list >> bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- Re: [bitcoin-list] Difficulty adjustment mechanism From: s7r - 2014-09-13 17:40:04 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/2014 7:45 PM, Michael Wozniak wrote: > The biggest problem with a time based rule is that there is no > central time to provide a measure of how much time has actually > passed. You can see this issue on testnet already because block > timestamps are modified. For example, the current time is > (according to my server) 1410626564 and the best block on testnet > shows a timestamp of 1410628433 (30 minutes in the future). > > This problem can be addressed, like the problem of transaction time and order of transactions in blocks. For sure maybe you cannot get 100% time accuracy, but you can know the time with +/- some error margin for time window. And as for the other algorithms used by altcois, i don't have one to give as an example but can't all of them be unstable. And of course, it is not a problem now and most probably will never be, but if it's simple to implement why not take safety precautions and be prepared even for the unexpected / impossible threat? I mean, isn't this what cryptocoin decentralized money is all about? :) > > On Sep 13, 2014, at 12:34 PM, Jeff Garzik > wrote: > >> Why not on mainnet? It is simply much lower priority for >> bitcoin today than other problems. It tends not to happen at >> higher difficulties for a variety of reasons. >> >> The difficulty adjustment is capped at a factor of 4, up or down, >> to address some other attacks that can happen in mining. >> >> Personally, I think there needs to be a mainnet safety rule such >> as "if 24 hours goes by without a block, you may mine a block" >> etc. But I readily admit I've not thought through all the >> ramifications of such a policy. >> >> >> >> On Sat, Sep 13, 2014 at 12:00 PM, s7r wrote: > > > On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>>>> This is why testnet has a special rule: If 20 minutes >>>>> passes without a block, you may mine a diff-1 block. >>>>> > > Thanks for your point of view Mr. Garzik. Why aren't we using this > in the real bitcoin network too? If it's good for balancing the > functionality of the network in the context of sudden hashrate > moves? Specially down moves, since if the hash power goes UP, the > network will see blocks are created more often than at every 10 > minutes and adjust the difficulty directly proportional, correct? > >>>>> >>>>> On Sat, Sep 13, 2014 at 9:15 AM, s7r >>>>> wrote: Hi there, >>>>> >>>>> I have an contradictory discussion with an altcoin >>>>> supporter and want to bring some solid arguments in a >>>>> public talk, so require little help to respond to a >>>>> question with simplest answer. >>>>> >>>>> The problem is within the difficulty adjustment mechanism, >>>>> that it happens at every 2016 blocks. In case the hash >>>>> power will suddenly decrease, the 2016 blocks will take a >>>>> lot of time to solve, therefor freeze the network in a >>>>> non-operational way. I know by far this is just a joke, >>>>> because this is very unlikely to happen anytime (people >>>>> paid for mining equipment and make money) but for the sake >>>>> of discussion, let's just assume it 'could' happen. >>>>> >>>>> Can this really freeze the network for unlimited time and >>>>> bitcoin has no mechanism to balance it back? A resourceful >>>>> party with the intent to attack the network in an >>>>> irrational way, brings lot of hashing power and keeps it >>>>> for 2016 blocks, then removes it leaving the other 2016 >>>>> blocks to solve at very high difficulty but with low hash >>>>> power in the network causing a 'blackout'? Thank you in >>>>> advance for your answers. >>>>> >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> > >>>>>> Want excitement? >>>>>> Manually upgrade your production database. When you want >>>>>> reliability, choose Perforce Perforce version control. >>>>>> Predictably reliable. >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>>>> >>>>>> > >>>>>> _______________________________________________ >>>>>> bitcoin-list mailing list >>>>>> bitcoin-list@... >>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>>>> >>>>> >>>>> >> >> >> >> >>>>>> - -- >> Jeff Garzik Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ >> >> ------------------------------------------------------------------------------ >> >> Want excitement? >> Manually upgrade your production database. When you want >> reliability, choose Perforce Perforce version control. >> Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> bitcoin-list mailing list bitcoin-list@... >> https://lists.sourceforge.net/lists/listinfo/bitcoin-list > > > ------------------------------------------------------------------------------ > > Want excitement? > Manually upgrade your production database. When you want > reliability, choose Perforce Perforce version control. Predictably > reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > > _______________________________________________ > bitcoin-list mailing list bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUFIFUAAoJEIN/pSyBJlsRTsEIAJoblPgleEBE905tyw3ha9So eqbPPmfxJ2bAxFWz9f1BeLs3YbOuxzSbwOtmwGeCGg/cepIPW1z94ECLHfXR68cs 7oY1GXTj7WpSN0XXEvQ4NQcLMPqM9W4eFZoY0FWOVQGzy1M3g8JXGfK4mDC+aTD3 BSLkxfg0Q8fzd7aOObW/vqNYjnO64wK/Me/imGbjX3L24cLBuDwDTpcmXMkCsqtx 2BAZoZHBFzTwTxPH4GFJ44u1Lv0+N8C8GroZUMvXUsxo9MX2aEuFKOZ//xhymttH LqYlIaHPOnByzFBsYG/Wrp0DcQpPpbROOG2s5UP85b3FRIE1HTMx64ckTJYhFXM= =fd3u -----END PGP SIGNATURE----- --- [bitcoin-list] bitcoind node dual stack (tor and clearnet) From: s7r - 2014-09-25 23:28:37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I run some Tor hidden bitcoin nodes, I would like them to be dual stack (connect to clearnet nodes too). But want to use the same directory data (blockchain) and in the same time not exchange the onion address listed at external IP with the clearnet peers and vice versa (to avoid clernet peers knowing there's an onion node on the same machine too and onion noes knowing the clearnet IP address). How can this be done? I currently have in bitcoin.conf, among others, the following entries for network settings: onlynet=tor externalip=foo.onion proxy=127.0.0.1:9050 listen=1 bind=127.0.0.1:8333 Advices? Thanks in advance! - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUJKT7AAoJEIN/pSyBJlsRmlUH/jcG5BNp04A+U2vMw0uECMFZ vQhoXLS9TYmRhimSwxZ6NjXCxeAOFPHszu6wBooSgSZDxjd1L5Q0Un5GSrUJOVtb wAiApad7kbi/a35M6EubYSSXoYeeNMBiCWLBYhAFggLgjlg/p/6mSstZHQ+7pYkE cHmeIUi2ilhezIknWHLE0StMRF+liQuP+sXuCQrSSIcaf4A4f1rv96JOByIbOTCO RF2JJdY0c89kG4/untheOu09ZAYK0+Ds13OrdbwmsPN8GaXLYpKNEJ0rLLu2cGWf WjK/cQoZcCLqdczAJA/69OCWSC+mpHG+Y0AdFrvf20PMGNFc1j4LSvb/zZAl2AQ= =xbT+ -----END PGP SIGNATURE----- --- [bitcoin-list] Bitcoin-QT git compilation error: "libtool: link: unable to infer tagged configuration" From: Dâniel Fraga - 2014-09-27 18:07:09 I always compiled Bitcoin-QT from git, but now I get the following error (I'm using libtool 2.4.2): CXXLD test/test_bitcoin CXX qt/qt_bitcoin_qt-bitcoin.o OBJCXXLD qt/bitcoin-qt libtool: link: unable to infer tagged configuration libtool: link: specify a tag with `--tag' Makefile:2305: recipe for target 'qt/bitcoin-qt' failed make[1]: *** [qt/bitcoin-qt] Error 1 make[1]: Leaving directory '/usr/local/src/git/bitcoin/src' Makefile:551: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 *** Any hints? Thanks. -- Linux 3.16.0-00115-g19583ca: Shuffling Zombie Juror http://www.youtube.com/DanielFragaBR http://exchangewar.info Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL --- Re: [bitcoin-list] Bitcoin-QT git compilation error: "libtool: link: unable to infer tagged configuration" From: Kamil Domański - 2014-09-27 18:11:16 Hi Daniel, are you using ccache? Best regards, Kamil On 09/27/2014 08:06 PM, Dâniel Fraga wrote: > I always compiled Bitcoin-QT from git, but now I get the > following error (I'm using libtool 2.4.2): > > CXXLD test/test_bitcoin > CXX qt/qt_bitcoin_qt-bitcoin.o > OBJCXXLD qt/bitcoin-qt > libtool: link: unable to infer tagged configuration > libtool: link: specify a tag with `--tag' > Makefile:2305: recipe for target 'qt/bitcoin-qt' failed > make[1]: *** [qt/bitcoin-qt] Error 1 > make[1]: Leaving directory '/usr/local/src/git/bitcoin/src' > Makefile:551: recipe for target 'all-recursive' failed > make: *** [all-recursive] Error 1 > > *** > > Any hints? Thanks. --- Re: [bitcoin-list] Bitcoin-QT git compilation error: "libtool: link: unable to infer tagged configuration" From: Dâniel Fraga - 2014-09-27 22:23:09 Hi Kamil. No, I'm not using ccache. Any hints? On Sat, 27 Sep 2014 20:10:59 +0200 Kamil Domański wrote: > Hi Daniel, > are you using ccache? > > Best regards, > Kamil > > On 09/27/2014 08:06 PM, Dâniel Fraga wrote: > > I always compiled Bitcoin-QT from git, but now I get the > > following error (I'm using libtool 2.4.2): > > > > CXXLD test/test_bitcoin > > CXX qt/qt_bitcoin_qt-bitcoin.o > > OBJCXXLD qt/bitcoin-qt > > libtool: link: unable to infer tagged configuration > > libtool: link: specify a tag with `--tag' > > Makefile:2305: recipe for target 'qt/bitcoin-qt' failed > > make[1]: *** [qt/bitcoin-qt] Error 1 > > make[1]: Leaving directory '/usr/local/src/git/bitcoin/src' > > Makefile:551: recipe for target 'all-recursive' failed > > make: *** [all-recursive] Error 1 > > > > *** > > > > Any hints? Thanks. > > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list -- Linux 3.16.0-00115-g19583ca: Shuffling Zombie Juror http://www.youtube.com/DanielFragaBR http://exchangewar.info Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL --- [bitcoin-list] Running a full node From: Francis GASCHET - 2014-11-06 10:53:42 Dear all, I'm currently discovering the Bitcoin's universe. I installedbitcoind on my PC and I'm currently testing different things on testnet. I just read an article saying that the risk for Bitcoin in the future is the decreasing number of full nodes, with appropriate resources. There are only few of them in France ! My company operates a dual homed Internet access and has some capacity to host an HA server in a secured environment. So I'm thinking about setting up a full node. But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Thanks in advance for details. -- Francis --- Re: [bitcoin-list] Running a full node From: David Parrish - 2014-11-09 14:20:03 I run a bitcoin node on a spare laptop at home without any problems along with three other proof of stake coins. Your biggest expense is probably bandwidth. I have Time Warner business class service. Make sure you allow port 8333 through your firewall so other nodes can connect to you. Storage: https://blockchain.info/charts/blocks-size Bandwidth usage: http://bitcoin.stackexchange.com/questions/12224/how-much-memory-and-bandwidth-does-bitcoind-take-up-on-a-centos-linux-system I hope that helps. On Thu, Nov 6, 2014 at 5:53 AM, Francis GASCHET wrote: > Dear all, > > I'm currently discovering the Bitcoin's universe. > I installedbitcoind on my PC and I'm currently testing different things > on testnet. > I just read an article saying that the risk for Bitcoin in the future is > the decreasing number of full nodes, with appropriate resources. There > are only few of them in France ! > > My company operates a dual homed Internet access and has some capacity > to host an HA server in a secured environment. So I'm thinking about > setting up a full node. > But I'd like to know what storage, RAM and bandwidth resources are > needed. I guess that the problem is not the CPU. > > Thanks in advance for details. > -- > Francis > > > ------------------------------------------------------------------------------ > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] Running a full node From: Francis GASCHET - 2014-11-09 15:22:41 Dear all, +1 ! Thanks to those who sent me some details and links. My node is up and running on 5.56.40.1:8333 Techno : Linux HA + dual homed Internet transit. It should be stable as from now. Best regards -- Francis Le 06/11/2014 11:53, Francis GASCHET a écrit : > Dear all, > > I'm currently discovering the Bitcoin's universe. > I installedbitcoind on my PC and I'm currently testing different > things on testnet. > I just read an article saying that the risk for Bitcoin in the future > is the decreasing number of full nodes, with appropriate resources. > There are only few of them in France ! > > My company operates a dual homed Internet access and has some capacity > to host an HA server in a secured environment. So I'm thinking about > setting up a full node. > But I'd like to know what storage, RAM and bandwidth resources are > needed. I guess that the problem is not the CPU. > > Thanks in advance for details. --- Re: [bitcoin-list] Running a full node From: grarpamp - 2014-11-09 17:52:45 You may also wish to consider linking your node into the Tor, I2P, and maybe even CJDNS networks. Details on their respective mailing lists. --- Re: [bitcoin-list] bitcoind node dual stack (tor and clearnet) From: Martinx - ジェームズ - 2014-12-04 14:31:22 Hi! I also need a Bitcoin Daemon with full support for Dual-Stacked node. My bitcoind on Ubuntu have: 1- IPv4 - fake 1- IPv6 - public 1- IPv6 from Hyperboria I prefer Hyperboria, instead of Tor... Currently, I can use only IPv6 or only IPv4, which sucks... With dual-stack, 1 Bitcoind can serve 3 different networks! Best! Thiago On 25 September 2014 at 20:27, s7r wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I run some Tor hidden bitcoin nodes, I would like them to be dual > stack (connect to clearnet nodes too). But want to use the same > directory data (blockchain) and in the same time not exchange the > onion address listed at external IP with the clearnet peers and vice > versa (to avoid clernet peers knowing there's an onion node on the > same machine too and onion noes knowing the clearnet IP address). How > can this be done? I currently have in bitcoin.conf, among others, the > following entries for network settings: > > onlynet=tor > externalip=foo.onion > proxy=127.0.0.1:9050 > listen=1 > bind=127.0.0.1:8333 > > Advices? Thanks in advance! > - -- > s7r > PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQEcBAEBAgAGBQJUJKT7AAoJEIN/pSyBJlsRmlUH/jcG5BNp04A+U2vMw0uECMFZ > vQhoXLS9TYmRhimSwxZ6NjXCxeAOFPHszu6wBooSgSZDxjd1L5Q0Un5GSrUJOVtb > wAiApad7kbi/a35M6EubYSSXoYeeNMBiCWLBYhAFggLgjlg/p/6mSstZHQ+7pYkE > cHmeIUi2ilhezIknWHLE0StMRF+liQuP+sXuCQrSSIcaf4A4f1rv96JOByIbOTCO > RF2JJdY0c89kG4/untheOu09ZAYK0+Ds13OrdbwmsPN8GaXLYpKNEJ0rLLu2cGWf > WjK/cQoZcCLqdczAJA/69OCWSC+mpHG+Y0AdFrvf20PMGNFc1j4LSvb/zZAl2AQ= > =xbT+ > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- Re: [bitcoin-list] Running a full node From: Martinx - ジェームズ - 2014-12-04 14:33:01 Bitcoind|qt needs Dual-Stack support. ;-) Cheers! Thiago On 9 November 2014 at 15:52, grarpamp wrote: > You may also wish to consider linking your node into > the Tor, I2P, and maybe even CJDNS networks. Details > on their respective mailing lists. > > ------------------------------------------------------------------------------ > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list --- [bitcoin-list] Request for Comment: Bitcoin Wallet Privacy Ratings Criteria From: Kristov Atlas - 2015-01-16 20:16:18 The Open Bitcoin Privacy Project is seeking public comment on our ratings criteria for Bitcoin wallet privacy. Please provide your feedback within the next week through Jan 23, 2015 to ensure that it will be considered for version 1.0 of the document. https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/criteria.md In conjunction with a scoring matrix that will determine the weight of each sub-category, this criteria will be used to evaluate and score a variety of Bitcoin wallets, which will be published on our website at openbitcoinprivacyproject.org. Feedback through this mailing list is, of course, welcome; if you have a GitHub account, this is the preferred medium for proposing changes to the document. The current version of the criteria was authored by myself, as well as other OBPP members including Justus Ranvier (Monetas), Chris Pacia (Bitcoin Authenticator), and Samuel Patterson (Open Bazaar). Thank you in advance for your feedback, Kristov Atlas kristovatlas@... author@... --- [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: s7r - 2015-03-10 14:33:55 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I run several bitcoind full nodes, some accessible only via Tor hidden services and some dual-stack (Tor hidden service + clearnet). Since Tails Linux (https://tails.boum.org/) now ships Electrum wallet by default, I also added support for Electrum-Server, so the Tor Electrum wallet users can benefit of some reliable servers accessible via Tor hidden services. Just one of the nodes won't let me complete the setup. When adding electrum-server, there is also the need to add txindex=1 in bitcoin.conf and -reindex the blockchain (in my setups). I did it on the other nodes with no problem. On the current one, I tried to do it 2 times and it freezes at this stage: { "version" : 90300, "protocolversion" : 70002, "blocks" : 322082, "timeoffset" : -1, "connections" : 41, "proxy" : "", "difficulty" : 29829733124.04041672, "testnet" : false, "relayfee" : 0.00001000, "errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues." } At this stage it is not consuming any CPU, while until block 322082 while it was reindexing the previous blocks, the CPU usage was between 90% and 100%. Now it's frozen at block 322082 for over 7 hours. Type: virtual machine OS: Debian Wheezy 64 bit CPU: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz (1 virtual core) RAM: 8 GB Bitcoin: bitcoind 0.9.3 installed via git, from github. What are the possible solutions? One would be to delete all the data and let it sync again from scratch with txindex=1 from starters, but still, I would like to figure out, why is this node behaving like this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJU/vw2AAoJEIN/pSyBJlsR3qMIAJzq0N47eXfR3jcDfHhdYl45 X1oKcJhtfEtn5NIdPffnOSEriS78njA3PQcAftWIChtVDXa/nk6XZt0vDnO5ejDW 1VBckVnfQ9pg7ogxrA+CfRgz0MyGIkZZxfXmXyuwCyqV9elSwR4SXDE3xVMu4A95 Ir/aJQXeSeyIm3PnEthlLc/8T1uszZnhNbKWJIov6+NrnIVJv9adsBxwKUDcIFj6 I2Lrp6vYy5nhTzwV/kQQnlXYni23o72FWfWaj6QKy6Y3SNrr0ljF3ZD5xWlwJPiV LdwOWDkFzoa1tQyawmVd9m9BZ34+0VCI9PArYOiYZfgKs1zc2gyRs6sGIFbXaNs= =tiAW -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: grarpamp - 2015-03-11 06:53:27 On Tue, Mar 10, 2015 at 10:14 AM, s7r wrote: > 90% and 100%. Now it's frozen at block 322082 for over 7 hours. See what the tubes say about this block if anything. Grab a gcore for the devs. Then kill and restart it and see what happens. > Type: virtual machine > OS: Debian Wheezy 64 bit > CPU: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz (1 virtual core) > RAM: 8 GB This is financial data, potentially yours. Assuming you own it, the box should be using ECC RAM and a sha256 checksum ZFS. > Bitcoin: bitcoind 0.9.3 installed via git, from github. Well v0.9.4 tag is long since out and 0.9 branch has 10 subsequent commits. Similar for the 10.x series. > What are the possible solutions? One would be to delete all the data If the restart locks up again you could debug that. Or you could snapshot ZFS and torrent sync the blocks back to whatever the current signed torrent feed is, or just delete some blockfiles, and try from there. Or upgrade bitcoind, and move on. There are scripts in the torrent feed post on bitcointalk that can be used to compare your blocks to theirs if bandwidth from deleting all the blocks is an issue. --- Re: [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: Adam Weiss - 2015-03-11 14:27:10 A recent patch made to OpenSSL is incompatible with 0.9.3. If you're building yourself and not using the dependency system (ie: make depends) you'll get stuck on any block with a non-canonical DER signature. I believe 322082 is the first one. To avoid the problem, either use the 0.9.4 hotfix branch or build with the dependency build system "make depends". If this is a node you care about, I would suggest you use the dependency build system or the release builds to ensure that an external library change doesn't break things, given how delicate consensus type things can be. --adam On Wed, Mar 11, 2015 at 2:53 AM, grarpamp wrote: > On Tue, Mar 10, 2015 at 10:14 AM, s7r wrote: > > 90% and 100%. Now it's frozen at block 322082 for over 7 hours. > > See what the tubes say about this block if anything. Grab a gcore > for the devs. Then kill and restart it and see what happens. > > > Type: virtual machine > > OS: Debian Wheezy 64 bit > > CPU: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz (1 virtual core) > > RAM: 8 GB > > This is financial data, potentially yours. Assuming you own it, > the box should be using ECC RAM and a sha256 checksum ZFS. > > > Bitcoin: bitcoind 0.9.3 installed via git, from github. > > Well v0.9.4 tag is long since out and 0.9 branch has 10 subsequent > commits. Similar for the 10.x series. > > > What are the possible solutions? One would be to delete all the data > > If the restart locks up again you could debug that. > > Or you could snapshot ZFS and torrent sync the blocks back to whatever > the current signed torrent feed is, or just delete some blockfiles, and > try from there. > > Or upgrade bitcoind, and move on. > > There are scripts in the torrent feed post on bitcointalk that can > be used to compare your blocks to theirs if bandwidth from > deleting all the blocks is an issue. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@... > https://lists.sourceforge.net/lists/listinfo/bitcoin-list > --- Re: [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: Thy Shizzle - 2015-03-12 02:13:09 Hey, I read something about 0.9.3 not working properly with the latest OpenSSL. Are you building your own 0.9.3 nodes and pulling in the latest OpenSSL? This might be your problem? They said to get 0.9.4 and then get the latest OpenSSL if you are doing that. Also just found this "Large valid fork found" , stuck at block 322082 · Issue #5645 · bitcoin/bitcoin | | | | | | | | | | | "Large valid fork found" , stuck at block 322082 · Issue...I get this error: 2015-01-12 05:00:27 CheckForkWarningConditions: Warning: Large valid fork found forking the chain at height 322082 (00000000000000001e6da... | | | | View on github.com | Preview by Yahoo | | | | | Hope this helps :) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I run several bitcoind full nodes, some accessible only via Tor hidden services and some dual-stack (Tor hidden service + clearnet). Since Tails Linux (https://tails.boum.org/) now ships Electrum wallet by default, I also added support for Electrum-Server, so the Tor Electrum wallet users can benefit of some reliable servers accessible via Tor hidden services. Just one of the nodes won't let me complete the setup. When adding electrum-server, there is also the need to add txindex=1 in bitcoin.conf and -reindex the blockchain (in my setups). I did it on the other nodes with no problem. On the current one, I tried to do it 2 times and it freezes at this stage: { "version" : 90300, "protocolversion" : 70002, "blocks" : 322082, "timeoffset" : -1, "connections" : 41, "proxy" : "", "difficulty" : 29829733124.04041672, "testnet" : false, "relayfee" : 0.00001000, "errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues." } At this stage it is not consuming any CPU, while until block 322082 while it was reindexing the previous blocks, the CPU usage was between 90% and 100%. Now it's frozen at block 322082 for over 7 hours. Type: virtual machine OS: Debian Wheezy 64 bit CPU: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz (1 virtual core) RAM: 8 GB Bitcoin: bitcoind 0.9.3 installed via git, from github. What are the possible solutions? One would be to delete all the data and let it sync again from scratch with txindex=1 from starters, but still, I would like to figure out, why is this node behaving like this? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJU/vw2AAoJEIN/pSyBJlsR3qMIAJzq0N47eXfR3jcDfHhdYl45 X1oKcJhtfEtn5NIdPffnOSEriS78njA3PQcAftWIChtVDXa/nk6XZt0vDnO5ejDW 1VBckVnfQ9pg7ogxrA+CfRgz0MyGIkZZxfXmXyuwCyqV9elSwR4SXDE3xVMu4A95 Ir/aJQXeSeyIm3PnEthlLc/8T1uszZnhNbKWJIov6+NrnIVJv9adsBxwKUDcIFj6 I2Lrp6vYy5nhTzwV/kQQnlXYni23o72FWfWaj6QKy6Y3SNrr0ljF3ZD5xWlwJPiV LdwOWDkFzoa1tQyawmVd9m9BZ34+0VCI9PArYOiYZfgKs1zc2gyRs6sGIFbXaNs= =tiAW -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ bitcoin-list mailing list bitcoin-list@... bitcoin-list -- | | | | | | | | | bitcoin-list --To see the collection of prior postings to the list, visit the bitcoin-list Archives. | | | | View on lists.sourceforge.net | Preview by Yahoo | | | | | --- Re: [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: s7r - 2015-03-13 22:54:57 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Something is really strange with that particular block. I have cleared the bitcoin data (blocks, peers.dat, everything to start from scratch). I had bitcoind installed from github, v 0.9.3, compiled in folder ~/bitcoinsrc I did a rm -rf ~/bitcoinsrc, cloned again from github, checked out into 0.10 branch, installed the additional required dependencies (libdb++-dev and libtool) and installed the latest bitcoind. I let it to sync again from scratch, and it is blocked again at the same block: { "version" : 90300, "protocolversion" : 70002, "blocks" : 322082, "timeoffset" : -1, "connections" : 35, "proxy" : "", "difficulty" : 29829733124.04041672, "testnet" : false, "relayfee" : 0.00001000, "errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues." } What is curious is that it still sates version : 90300, regardless I have updated. Can someone please write an easy guide to fix this? Maybe I did not uninstall the previous 0.9.3 correctly?. My OpenSSL is up to date. OS is Debian Wheezy 64 bit. I don't know what else to do, everything is up to date, all dependencies are installed and ./autogen.sh and ./configure for v.0.10 did not give any errors and passed just fine. On 3/12/2015 4:13 AM, Thy Shizzle wrote: > Hey, I read something about 0.9.3 not working properly with the > latest OpenSSL. > > Are you building your own 0.9.3 nodes and pulling in the latest > OpenSSL? This might be your problem? They said to get 0.9.4 and > then get the latest OpenSSL if you are doing that. > > Also just found this "Large valid fork found" , stuck at block > 322082 · Issue #5645 · bitcoin/bitcoin > ; > > > image ; > > > > > > > > > > "Large valid fork found" , stuck at block 322082 · Issue... > ; I get this error: > 2015-01-12 05:00:27 CheckForkWarningConditions: Warning: Large > valid fork found forking the chain at height 322082 > (00000000000000001e6da... View on github.com > ; Preview by Yahoo > > > > Hope this helps :) > > Hello, > > I run several bitcoind full nodes, some accessible only via Tor > hidden services and some dual-stack (Tor hidden service + > clearnet). > > Since Tails Linux (https://tails.boum.org/) now ships Electrum > wallet by default, I also added support for Electrum-Server, so > the Tor Electrum wallet users can benefit of some reliable servers > accessible via Tor hidden services. > > Just one of the nodes won't let me complete the setup. When adding > electrum-server, there is also the need to add txindex=1 in > bitcoin.conf and -reindex the blockchain (in my setups). I did it > on the other nodes with no problem. On the current one, I tried to > do it 2 times and it freezes at this stage: > > { "version" : 90300, "protocolversion" : 70002, "blocks" : 322082, > "timeoffset" : -1, "connections" : 41, "proxy" : "", "difficulty" > : 29829733124.04041672, "testnet" : false, "relayfee" : 0.00001000, > "errors" : "Warning: The network does not appear to fully agree! > Some miners appear to be experiencing issues." } > > At this stage it is not consuming any CPU, while until block 322082 > while it was reindexing the previous blocks, the CPU usage was > between 90% and 100%. Now it's frozen at block 322082 for over 7 > hours. > > Type: virtual machine OS: Debian Wheezy 64 bit CPU: Intel(R) > Xeon(R) CPU E5606 @ 2.13GHz (1 virtual core) RAM: 8 GB > Bitcoin: bitcoind 0.9.3 installed via git, from github. > > What are the possible solutions? One would be to delete all the > data and let it sync again from scratch with txindex=1 from > starters, but still, I would like to figure out, why is this node > behaving like this? > > ------------------------------------------------------------------------------ > > > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot > Media, is your hub for all things parallel software development, > from weekly thought leadership blogs to news, videos, case > studies, tutorials and more. Take a look and join the conversation > now. http://goparallel.sourceforge.net/ > _______________________________________________ bitcoin-list > mailing list bitcoin-list@... bitcoin-list -- > ; > > > > > > > > > > > bitcoin-list -- > ; To see > the collection of prior postings to the list, visit the > bitcoin-list Archives. View on lists.sourceforge.net > ; Preview > by Yahoo > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVA2qkAAoJEIN/pSyBJlsRhl8H/2v57czIrEkLcWDbXaxu7Qz5 YhGVrCLXg0r/IqvqIUuvBVetWzF0iThOMHO92ZjJH9wlp5SY3lnLosHLI/eileVP dftMMUavLdwf7Oq0wp4VqZzYCOL8252AB3iBWfeUGGxOBrl3s19Rz0lYp2ajGdx3 qKOF049o67LHNCyOEGlx9ax1avY30cKO4N2wIo4TnqXw7Z8zpefpYPNiBq5OUBqI SkIoHdR+jIDR7lHaMZL9lqwwH54MgWTWb9wMzC7uxKGi9ph5m5DB5ePD/HqPoQVX G6PBYaZJ9LJvXuqzj+SHzEmIg3mLOBRV/yiJUboN1QYBO4ymM765T6z73xv2UmI= =vCGS -----END PGP SIGNATURE----- --- Re: [bitcoin-list] Bitcoind error at block 322082 (The network does not appear to fully agree) From: grarpamp - 2015-03-15 09:39:16 On Fri, Mar 13, 2015 at 6:54 PM, s7r wrote: > What is curious is that it still sates version : 90300, regardless I realpath bitcoind [absolute path] //bitcoind -\? | head -1 [bitcoind version] ldd //bitcoind | grep libssl strings | grep OpenSSL [ssl version] If fully static, strings /.../bitcoind | grep OpenSSL [ssl version] > everything is up to date, all dependencies are installed and Without seeing your complete command history from download through build to exec, these are ambiguous phrases. Brief read of the net says bitcoind 0.10x with openssl 1.0.1l should work. Could be paths to bitcoind/libssl/libcrypto, or mixed up/old versions. Or the bit of net I read is wrong. You probably don't want to subject bitcoind to the randomness of packaging systems. Static build in a private directory should fix that. Today the static part may be something like: CPPFLAGS=-static LDFLAGS=-static ./configure --- [bitcoin-list] solution for a bitcoin contract (maybe with oracle script) From: s7r - 2015-04-10 10:12:12 Hi, been reading the contracts page under bitcoin.it wiki. I find the features available in bitcoin amazing. However, I didn't find something which would allow me to build a custom contract and I think there has to be something in script which can be used for this purpose. If you can think of a solution (using whatever OP_), please let me know. Here is the description of the contract: We have a p2sh (multisig) address 3/3 signatures generated with Alice's pubkey, Bob's pubkey and the John's pubkey. In this address, both Alice and Bob need to send 1 BTC each, but each is afraid the other party will not send if he/she sends first. Let's assume Alice generates a TX to send the coins, but does not broadcast it, and just provides the TXid to Bob and John. Can the other 2 parties which have a pubkey in this address (Bob and John) sign a second TX which spends Alice's TX back to Alice, but will be valid only if Bob doesn't send his 1 BTC? Something like "signature valid only if address balance < 2 BTC (Bob didn't send) and maybe with an nLockTime of 24 hours (time allowed for Bob to send his coin)". The simple goal is for Alice to be able to claim her coin back without trusting anyone if Bob doesn't send his coin, in a way that will not require Alice to depend on either Bob or John (other 2 parties in the p2sh multisig address). At the same time Bob wants to be sure that if he sends his 1 BTC, Alice will not be able to claim her 1 BTC back after that. Note: I know that given the fact that Alice will have a TX signed by Bob and John which spends her first TX only, she will only be able to claim her 1 BTC back and have no control over Bob's 1 BTC (if he sends), but the goal is for Alice not to be able to claim even her 1 BTC back if Bob actually does send within an agreed time frame. Thank you in advance for your suggestions. --- [bitcoin-list] Bitcoin learning material From: Henning Kopp - 2015-05-06 15:36:15 Hi Guys, I am a PhD sudent from Ulm University and I am preparing an exercise for a course about practical IT-security. My idea is to let the students connect to the testnet, get some coins from a faucet, do some transactions and search them in the blockchain. Do you have any other ideas for an exercise for masterstudents? All to best Henning -- Henning Kopp Institute of Distributed Systems University of Ulm, Germany Office: O27 - 3402 Phone: +49 731 50-24138 Web: http://www.uni-ulm.de/in/vs/~kopp --- Re: [bitcoin-list] Bitcoin learning material From: Alejandro Prats Pérez - 2015-05-06 23:36:33 Hi Henning. You can share them Dogecoindark, its like dogecoin meme but with the implementation of wallet into i2p and tor network. And you can bet with them if they can search the transaction, is very funny, jijiji http://www.dogecoindark.net/ Regards, Alejandro. El 06/05/2015 a las 17:35, Henning Kopp escribió: > Hi Guys, > I am a PhD sudent from Ulm University and I am preparing an exercise > for a course about practical IT-security. > My idea is to let the students connect to the testnet, get some coins > from a faucet, do some transactions and search them in the blockchain. > > Do you have any other ideas for an exercise for masterstudents? > > All to best > Henning > --- [bitcoin-list] Participate in Bitcoin survey => get bitcoins From: res.mb.bituse - 2015-07-08 15:37:23 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Bitcoin user, If you are interested in improving Bitcoin and get some mBTC by the way just read on. We are researchers and currently conducting a Bitcoin user study and are therefore seeking for participants. As you are a Bitcoin user, we would kindly invite you to participate. Our survey is anonymous and takes about 15 minutes to complete. As a reward, you can receive 0,0042 BTC and if you spread the word and invite others to participate, you will receive an additional 0,001 BTC per person. Please note that automated answers will not receive compensation and will be excluded from the sample. The goal of this survey is to learn about user perceptions on Bitcoin and will cover aspects such as key management, wallet usage and risk perception. As we believe that these results will be valuable to the entire community, we will publish our results and make them available to everyone. This is the link to the survey: https://www.soscisurvey.de/BTC_study/ More information can be found on the survey website. If you have any questions, please don't hesitate to contact us via bituse@... https://twitter.com/bit_use -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVnT9DAAoJEDf5u87g4GhB+xQP/31O0ETz5aor/WY4f+gSaZj1 vmTd8UIBBWcnk0P4EFlrpbjGyn9cqE/BGTTsGNFU8CAPlQlJsqImckQp9d0+f/bJ gf6ioAuI2vacmgJbnmxPLL2Lp0YLh2Ejx12h+kjovNDq1RbnAQvwMrELXJ9vzERt 1soKO7fMsulGPQ2579Pm4flmJD1kNVmTl43hVrtrG9IN1yRmVLsDH+h5pf2mr5Ky xosofewrIEUe5eKcs2gUpCVX6xubd8iGFdmTAvPkPyUXQhePyC67L8ZxFjnz4sXl MDei43dfGYDWVwmZIValsGTrXrorfn5NduQlD4mOJhTj/J5jaS2mzvptiWH3OR/d lLlHMCrUUJL/ubmvexSrTju0PAuqvEOVOTUaGUuP6rcq/EdkPaOOzT9EqB8ZwA1E 4IhbFJMmAEa5alwVmwZQOrToU8lJUT86JBToj5bEUJHRhCIDm1o2Nqgmlz7qkl/B kQN+fA2zHNvrYnDnRVQ49fO9AOImraqQk9KINFgYT7YnBLR06JBf1qFo9dvSiKqK yVcYVdLvzMd06vPWYTdYeZEM9LhxP7Ur7IDM43BQVjvretuAPlJS45Dl87u8MyM1 yYhJLQQSF/4nHFy1lFb0FDusgv523gx0aoXfrlgAvO/8JpQ809RKIsf/9DHtxFF2 0942QXHkiBECgk1GVdi+ =kOQ5 -----END PGP SIGNATURE-----