It's called open source  The community is already guaranteed to continue. It would be useful if somebody else had commit access to the SVN and there was an explicit plan in place to continue in Satoshi's absence. Why? There isn't any reason why the project will suddenly collapse if Satoshi becomes absent. Eventually patches to the source would accumulate, someone will become a patch collector, and if enough people download the source&binaries from The Patch Collector, that person winds up (often reluctantly) the new de facto maintainer. People worry an awful lot about rules and rule-making. But there is no driving need for any Continuity of Government plan, here As long as the source code remains open, that is sufficient. If there is a need, and enough interest, the community will provide. Trust in the community |
|
|
|
Maybe you can setup a 2Gb "8.04.4 LTS" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use.
Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support. Constantly reformatting your main dev machine is for the birds I have to support OpenSolaris and FreeBSD in my cloud computing project, in addition to the primary target, Linux. Virtual machines are a life-saver (and cost-saver). |
|
|
|
What is the procedure for someone who borrows and does not return the currency? If there is to be any procedure at all then identity will have to be verified (presumably by some special authority).
The same procedure that is followed when someone borrows hard currency, and does not return it... Up to the lender to set the level of security. |
|
|
|
Suppose, god forbid, you were no longer able to program or were unavailable due to unknown circumstances. Do you have a procedure in mind to continue bitcoin in your absence?
It's called open source The community is already guaranteed to continue. |
|
|
|
Could you make count=0 return all transactions?
Returning all transactions is pretty easy, sure. I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your "count=0" the default. |
|
|
|
Very nice! Send Satoshi an email and ask him to add it to trunk.
He is welcome to pick it up now. But I didn't want to push the patch to him until the two FIXME's are resolved. Those FIXMEs are for 0.01% cases, but still... |
|
|
|
Just another reason to get working on over-the-wire encryption.
+1 agreed |
|
|
|
Something lightweight like this would be nice on a low powered device I call a "transaction computer".You could transfer your coin to your ultra secure "transaction computer" and know there is an extremely small chance any trading is trackable or logged.Maybe such a device would only connect to the network to send and receive your coins and then close up tighter than a fish's bum otherwise lol.
The transaction database isn't really lightweight in terms of disk space, especially if bitcoins become popular. So, if a transaction computer needs disk space, why not install a normal distro with better support? Any micro-distribution is going to be under-audited, and suffer a lag time on security patches to the base OS -- not exactly the ideal target for a "locked up tight" transaction computer. |
|
|
|
0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)
If you (and others) are willing, please post your OS + OS version, when posting success/failure reports. I will echo a recommendation to satoshi from another forum member: build linux binaries on an older Linux OS, to ensure wider compatibility. Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds). |
|
|
|
Added a couple small cleanups, and verified it still works under 0.3.6 / SVN r119. Version 5 of listtransactions: http://pastebin.ca/1911295Raw patch: http://pastebin.ca/raw/1911295FAQ: Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations? A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly. |
|
|
|
|
SVN r119 seems to work fine here. No BDB explosion.
|
|
|
|
BTW, an important feature of these mailing lists is that anyone can post... but only the "vendor security" group can read the posts. Thus, it is easy for an outsider with a real security issue to provide detailed information to vendor-sec@myopensourceproject.org, while preventing unscrupulous people from reading the sensitive information. I suppose a PM to <somebody>, plus discussion on a closed forum, is the best this forum software can handle. |
|
|
|
Is it too early to discuss what happened until more users upgrade?
I am interested in the meta-discussion, about security policy. In other open source projects, representatives of "key parties" tend to gather on a "vendor security" mailing list that is closed to the public. Vulnerabilities that might have real world consequences are discussed there, and then a coordinated release occurs, where all key players publish the security fixes at the same time. |
|
|
|
I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release  Double-ACK older version (SVN 117 + listtransactions + getinfo KHPS) works fine, all bitcoins there. And yes, I should back up before following "please upgrade" instructions... |
|
|
|
With the official Linux-64bit build, run on Fedora 13, I see it failing badly:
Same result on another machine. BDB errors, and death. 0.3.5 on 64bit Linux is questionable. You didn't mix up the builds with 32-bit Linux, did you? debug.log says: Bitcoin version 0.3.5 beta
Default data directory /g/g/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=/garz/bitcoin/data/database strErrorFile=/garz/bitcoin/data/db.log
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
|
|
|
|
With the official Linux-64bit build, run on Fedora 13, I see it failing badly: ************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
Praying my bitcoins aren't eaten... |
|
|
|
Please upgrade to 0.3.5 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.5!
Like Olipro, got a lot of people doing custom builds out there -- in fact, I must use a custom build on several machines. May we assume SVN has all necessary updates? |
|
|
|
OK, here's version 4. Output now matches what you see in the UI, and gives you information on debits/credit/generated/etc. The 'count' and 'includegenerated' parameters are now honored. Patch: http://pastebin.ca/1910623Raw patch: http://pastebin.ca/raw/1910623Here's sample output from my dev box: $ /usr/local/src/bitcoin/bitcoind -datadir=/usr/local/bitcoin/data listtransactions
[
{
"address" : "15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5",
"label" : "",
"class" : "credit",
"amount" : 0.02000000000000000,
"confirmations" : 160
},
{
"address" : "15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5",
"label" : "",
"class" : "credit",
"amount" : 0.01000000000000000,
"confirmations" : 162
},
{
"address" : "1GKgKYtV79jYHR2mr1SSDp9EjXQuLTmUTw",
"label" : "",
"class" : "debit",
"amount" : 0.02000000000000000,
"confirmations" : 1525
},
{
"address" : "191ALqREPdXCGE6mhfS7HqRZCeQB2AHT6y",
"label" : "",
"class" : "credit",
"amount" : 0.02000000000000000,
"confirmations" : 1531
},
{
"address" : "1HVYQQ5K489fMx5Aqt48M5oTJPsmUhrpkx",
"label" : "",
"class" : "debit",
"amount" : 0.01000000000000000,
"confirmations" : 1572
},
{
"address" : "1KTpPjGWyhTBC5NNYFwNzkyjW6UDL9jKPG",
"label" : "Your Address",
"class" : "credit",
"amount" : 0.01000000000000000,
"confirmations" : 1587
}
]
|
|
|
|
|
Show Posts
