Surely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?
Then it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.
The wallet is a key/value db4 database (and a key/value map in RAM). Neither data structure is ordered by time. |
|
|
|
The current IRC channel #bitcoin-dev on freenode is increasingly becoming a user support channel. I propose that we recommend (and list on http://www.bitcoin.org/contact ) using #bitcoin for everything not related to development and highly technical issues. #bitcoin on freenode is largely dead, and appears quite usable for new purposes. a few (older? modified?) clients use #bitcoin for IRC seeding, but these clients get less frequent over time. The "gribble" bot recommends using #bitcoin-discussion, but using #bitcoin seems simpler and more direct (and less to type). |
|
|
|
The alternative is for the payment to be made in coins from the alternate system. Here there are two possibilities.
Either these coins won't be perceived as valuable, in which case they won't be of much use for payments. Or else, those alternate coins will gain value, and will be used for payment. In this case the risk to Bitcoin is that the alternate coins have enough added utility that they eclipse Bitcoin and become used as a general purpose digital currency.
Their value is directly derived from the services offered on the "generalized proof-of-work (PoW)" chain. And it is obviously quite trivial to set up a site that exchanges GenCoins for bitcoins. |
|
|
|
I agree with jgarzik, the chain should not be used as storage.
If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain "dependent" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.
I think I've asked this question a number of times getting the run around. Perhaps I'll be more clear with this example as proposed by Caveden: If you create this alternate "proof of work" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain? If simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins. It becomes a parallel currency. Hence "DomainCredits" or "GenCoins" or whatever. Unrelated to this DNS project, you should expect many bitcoin clones to appear as time goes on, and people experiment. We already have one parallel currency: testcoins. |
|
|
|
As it stands now there are 5 cards available.
The website shows zero. I guess this is the BTC sell-off problem you just mentioned? |
|
|
|
It would be great to have a JSON-RPC method for listing new transactions that are newer than a particular transaction id. This would enable developpers to watch new transactions easily, by just keeping track of the latest known txid and polling that method at the rate of their choice.
If we're adding code to watch for new transactions, then we should be including gavin's monitor patches: https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived |
|
|
|
What's the status of bitcoin2cc.com?
I was wondering same. I went there and the buttons are greyed out, with zero available numbers. bitcoin2cc is an important service for the bitcoin community, IMO. |
|
|
|
|
+1 good stuff
Further suggestion: return pairs of Objects, listing balance alongside each account.
|
|
|
|
It is working with jgarzik's cpuminer, m0mchil's python miner and Diablo's java miner pretty well. But I found one problem in comparing targets. As I understand their codes well, they don't fully compare found hashes with target. So if I set difficulty pretty low, because I want many low-difficulty blocks for fair accounting, miners simply does not return correct hashes (hashes corresponding current target).
It's too slow to do a full 256-bit comparison for each hash generated. Taking the lead from mainline bitcoin, miners tend to "cheat" and simply look for a certain number of zero bits in the area that, when byte-swapped, holds the high-order bits of a 256-bit number. My cpuminer stops if the top 32 bits are all zero. Mainline bitcoin stops scanning for hashes if 16 bits are zero: if (((unsigned short*)phash)[14] == 0)
return nNonce;
Ideally, the miners would all do something like if (test for certain number of zero bits)
if (perform full target comparison)
// found a solution
return nNonce;
but we programmers can be a lazy bunch sometimes.  |
|
|
|
OP_DROP transactions can be ineligible for free space in blocks.
So OP_DROP transaction might require a fee.... which would elevate the priority of BitDNS transactions above normal currency transactions. That's disappointing. |
|
|
|
I agree with jgarzik, the chain should not be used as storage. Me too. But I'm not sure whether removing scripting support is a good idea. Oh I agree that removing scripting is both a radical proposal, and probably not realistic due to backward compatibility. Although I would support such a change, it was mainly to illustrate how little we use the script engine. There have been so many limitations placed upon it for security / anti-spam / anti-bloat reasons in recent months that, IMO, if bitcoin were redesigned from scratch today, it might not have a script engine. But don't let that distract from the main point: we should avoid larding the block chain with non-currency data. |
|
|
|
|
This problem has now been fixed in upstream binutils, and trickled down to Fedora.
|
|
|
|
This will have the effect of raising the cost of bitcoin transactions for everyone.
Why? If I am interested in hurting the network, I can more easily send some 0.01 transactions and never spend them. OP_DROP transactions can be ineligible for free space in blocks. It will raise costs because it will establish the precedent that the current bitcoin blockchain is simply a generic, pay-for-storage distributed database, where the payment (the currency) is tightly coupled with the storage. That opens bitcoin up to a wide array of uses that seem likely to dwarf the bytes used for storing and using the bitcoin currency itself. My strong preference is to move in the opposite direction: drop scripts completely. Admit that scripts are a mistake. Sign simple transactions of in's and out's. Rigorously standardize on a greatly simplified, basic functionality -- which is what we are doing, de facto, with changes like IsStandard. bitcoin is not generalized distributed storage. bitcoin is more likely to be successful if we do not try to cram all proof-of-work systems into the main block chain. Satoshi has come up with something wonderful and useful: a distributed, cryptographically signed agreement protocol based on proof-of-work (PoW). This excites the imagination with all the possibilities of non-currency projects that one could based on this PoW concept. Satoshi has also spent a serious amount of time hammering out a decent first implementation of this proof-of-work system. As a side effect, this implies that it is much easier to add Jeff Garzik's Proof Of Work Idea to the bitcoin codebase, than to create my own PoW system. We must resist this temptation. In order for this first, wonderful distributed currency experiment to be as successful as possible, it must not be larded down with exciting PoW ideas unrelated to digital cash. Testnet has provided a clear example of how to start your own block chain. So I suggest people take Linus Torvalds' advice: forking is good. Fork the project. Fork your own block chain. Call them DomainCredits. If it's a good idea, surely there are miner "investors" who would be willing to back your new network with a few ATI HD 5970's to provide the nascent network the ability to resist early attacks. What about a fork that permits OP_DROP style transactions of up to 64k? You have a PoW-based distributed storage / distributed messaging network, that can pay for itself. It sounds like a great idea to me... but it's not bitcoin, and that capability and others like it should not be shoehorned into the existing P2P network and "mainline" block chain. |
|
|
|
Let's allow transactions with a single "<constant> OP_DROP" to be included. The maximum 520 bytes that can be added with an OP_DROP is equivalent to just ~4 transactions, but it is enough to include hashes and other useful data.
This will have the effect of raising the cost of bitcoin transactions for everyone. |
|
|
|
Hi jgarzik, getting problem with configure on pretty old CentOS 5. Any idea, please?  ./configure: line 4516: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
Scroll up to this post, in the current thread. Your libcurl devel pkg is missing, or your libcurl devel pkg is missing autoconf macros. |
|
|
|
If you just need a cryptographically secure chain, store your data in git. |
|
|
|
This is another reason to have a more modularized bitcoin software... someone could make a wallet-management module that uses a database instead of a file, to better scale...
Is the wallet.dat file indexed?
wallet.dat is a db4 key/value database. |
|
|
|
In theory there is the potential to put in additional message types beyond transaction and block messages to the whole getblocks/inv/getdata sequence. Some of these blocks could in theory be other kinds of data such as a stock exchange purchase or the DNS data that has been talked about.
Where I see a problem is coming up with the algorithms to be able to process these extra kinds of data and getting them accepted into Bitcoin directly. Bitcoin simply isn't that flexible at the moment. There certainly are no hooks for processing those extra kind of data and verifying if they conform to some sort of standard or not or even identifying who might be involved in establishing those verification standards.
c.f. theymos' first sentence, which you elided: "The block chain is made for timestamping, not storage." It is good there are no hooks for processing and verifying arbitrary third party data, such as DNS data. A digital currency does not need to be loaded down with such crapola. |
|
|
|
Hey, < MT`AwAy> genjix: http://pastecoin.com/ <- you're generating a new bitcoin address at each page load, don't you fear wallet.dat will grow to astronomical size? Is this correct? Does my wallet save every single address? That you generate? If I understand correctly, it's a public/private keypair, and you have to store the private key. |
|
|
|
|
Show Posts
