Does anyone here know how I could do something like: SELECT sum(value)
FROM outputs
WHERE script LIKE decode('76a91412ab8dc588ca9', 'hex') + '%'; Where script is a bytea object in order for me to support firstbits? I think bytea supports BETWEEN, so this could be (UNTESTED) "script BETWEEN decode('76a91412ab8dc588ca9', 'hex') AND decode('76a91412ab8dc588caa', 'hex')". Abe does something like this: lo = abe.store.binin_hex(q + '0' * (40 - len(q)))
hi = abe.store.binin_hex(q + 'f' * (40 - len(q)))
That way I could add a fetch_balance_partial(...) method to support this.
Keep in mind that firstbits is case-insensitive. 1a matches 1a* and 1A*. You seem willing to implement a new, firstbits-like algorithm, and that's okay, but if it doesn't agree with firstbits.com, you shouldn't call it "firstbits". |
|
|
|
my god... version concatenated with the RIPEMD SHA256 of it, then concatenated with 4 bytes of SHA256 of SHA256 of the RIPEMD stuff... just so it could finally be base58 encoded....  The 20 bytes are already RIPEMD-of-SHA256ed. You "just" need a double-SHA256. It couldn't be more complicated, could it?  It was... shall we say... optimised for time-to-market. Satoshi had double-SHA256 handy and chose to devote time to other things than perfecting the address format. |
|
|
|
It's so difficult to produce fake blockheaders, that, unless you are handling huge amounts of BTC, it is perfectly fine to trust any headers you receive on a lightweight node (as long as its hash has the leading zeros).
True, with a caveat. Your untrusted block chain must have "pretty good" total difficulty, and you must acquire a recent estimate of "pretty good" from somewhere. A lightweight client could produce a graph like http://bitcoin.sipa.be/speed-ever.png and let you compare it to a version of the graph obtained from a trusted source. Perhaps newspapers will publish the graph, or you could go with your recollection of its shape. Maybe various organisations will sign and publish statistics, and your lightweight client can ship with their public keys, fetch the signed messages, and tell you who agrees with your data as of N hours ago. If your untrusted chain's implied hash rate starts to underperform the "real" one at some point in the past, you can be sure you have fake blocks from that point on. |
|
|
|
If anyone wants I also made a simple tool for myself that dumps the content of the transaction file. http://pastebin.com/jyBG3SUj(use it only with files you made yourself!) Though, I did not know how to show the destination addresses so it's probably not so much useful Any hint about that welcome. Hint: you will need the SHA256 hash function and bigints for base-58 encoding, so it will complicate your nice little C program a bit. The OpenSSL library provides both. Line 86: doczytaj(buf, sl); (I guess "doczytaj" means "discard".) If those discarded bytes are 76 a9 14 {20 bytes} 88 ac then you have a standard script, and the bitcoin address is found by this function where those {20 bytes} are the "RIPEMD-160(SHA-256(public key))" part. Thanks for the nice work, I look forward to trying it! |
|
|
|
Is this code stable?
Sorry, I overlooked this question. I hope to have a test suite one day and won't release a 1.0 without one. Numbered versions 0.4, 0.5, and 0.6 all have git branches for bugfixes, and I intend to backport any critical fixes to these. As for the latest commit, it may contain untested code and disruptive changes. |
|
|
|
A footnote to this old topic: I've proposed an improved(?) version here in the context of Ixcoin, but applicable to any new or experimental chain. Not for BTC unless hashrate falls to 2010 levels.  |
|
|
|
Can anyone point me to a fix for in the code of other alt coins where this [time travel exploit] was fixed please? Thanks.
I still think merged mining has more potential though.
It is not either/or. You have to fix the exploit regardless of whether you do merged mining. I've seen the "fix" (sorry, no link handy) but am left wondering, Why not update difficulty continuously? Pseudocode: # Constants set by chain designer
B=2016
N=600*second
DIFFICULTY[0] = 512
DIFFICULTYmin = 512
# Current difficulty as function of last block difficulty and time elapsed since last block
DIFFICULTY[i] = MAX(DIFFICULTYmin, DIFFICULTY[i-1] * B * N / ((B-1) * N + TIME[i] - TIME[i-1]))
TIME i would be the "current" time as stored in the block header. Validation would require that "now" >= TIME i >= TIME i-1. (If a block appears with time in the future, the client would hold onto it in case it is part of the best chain when it becomes valid.) Let's see how this fares in some pathological cases. 1. Difficulty too low. A long sequence of blocks with little change in time: TIME i-TIME i-1 is close to zero, so difficulty increases by a factor of approx. B/(B-1) with each block. Difficulty doubles every 1397 blocks (approx. B*log(2)). 2. Pool dumps coin. Difficulty too high. A long stretch of time without any blocks. Current algorithms suffer. This one decreases difficulty with the passage of time, not just the solving of blocks. Difficulty halves in 2 weeks (approx. B*N) even with zero blocks solved. 3. Miners leave block time unchanged despite passage of real time. They may gain from higher chain difficulty, but they will have to mine at an increasingly higher difficulty than the rest of us, and eventually that advantage will get us mining a block with updated time. 4. Time traveller visits. Can't do much as far as I can see. Blocks in past (before previous block) fail validation. Blocks in future must wait for their time (and hope the chain doesn't pass them) before clients recognize them. The lack of discreet difficulty jumps moderates profit. Exploit thwarted by appeal to external authority (the stars, crystal oscillations, Naval Observatory, etc.) yet without requiring absolute, network-wide agreement. 5. Computer clocks all wrong. As far as I can tell, the incentives are for accuracy. I'm curious whether this has been proposed and discussed. Edit: proposed in mid-2010 here, though in a simpler form suffering from use of floating-point arithmetic. To clarify: the pseudocode is not meant to suggest use of floating point or incompletely specified operations. No arguments against my form, but of course for the established chains there is inertia. |
|
|
|
Right, I didn't think Lukes proposal through properly. It is simpler so I updated the wiki page to say that.
As I would have done, had not Luke himself preferred the other way. No biggie, I think they're both fine, and the wiki page links here for the truly interested. |
|
|
|
Thanks for linking to Abe. I am impressed. Might you be releasing source code as per Abe's license, Section 13? |
|
|
|
Yeah, that solution does look better. It'd be good to put that on the Alternative Chains wiki page too.
Done. New section; created merged mining page as redirect to Alternative Chains. |
|
|
|
Why is the number of outstanding bitcoins not a multiple of 50?
At block 149439 it say 7471999.91789992 outstanding.
The number is below the expected value. Sometimes (just once?) a miner claims less than the allowed amount in coinbase transaction outputs. Abe adjusts the outstanding amount by subtracting a block's inputs from its outputs, not by assuming 50 per block. This is convenient for multi-chain support, since alternative chains have their own inflation formulas, which Abe knows nothing about. Also, sometimes people send coins to pseudo-addresses, which have the form of an address but are not generated in the normal way as the public part of a key pair. These are lost coins. Abe recognizes one pseudo-address (pubkey_hash zero) and uses it internally as the destination of namecoin network fees. A few bitcoins have gone there, and as a side-effect of namecoin accounting, Abe subtracts them from the outstanding value. There are other ways coins can be proven lost, which Abe may someday implement, driving the reported outstanding amount even lower. But it will stay close to the maximum as long as people follow the incentives to save bitcoins. |
|
|
|
Yeah, that solution does look better. It'd be good to put that on the Alternative Chains wiki page too.
Thanks, will update in my Copious Spare Time.  (off-topic, sorry) I think also Luke-Jr's proposal Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/ could use elaboration. I take it to mean, have the aux chain software enforce uniqueness of its work-proving hashes. I think that would work too and is a bit more elegant than sticking the value in the aux chain. |
|
|
|
Still breathing, thanks.  Any special requests? |
|
|
|
Maybe there's something I missed, after all I haven't actually implemented this.
This thread touches on it. I'm curious what you'd think of it. Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/ Mhmm, If I understand it correctly this might be undesirable because it might be (and is common) that you solve several AUX chain blocks and have one master-block vouching for them, right? This problem would only be solved if the difficulty of both blockchains draw levels. This was solved in the current code by requiring each chain to appear in a specific (pseudo-random) spot in the aux chain merkle tree, based on the chain ID. So for a specific chain ID, you would only be able to "solve" one aux chain block per parent block. It's good to see you all evaluating the details of the implementation and I appreciate the feedback. The more eyes on this the better. There is a more flexible solution to the problem. The problem is that, with MM as first implemented, a miner could cheat the proof-of-work system by putting more than one Namecoin block header into one Bitcoin block. This "cheating" would not cause a problem if the Namecoin blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network. The problem would arise if a linked series of Namecoin blocks all existed in one Bitcoin block's aux Merkle trees. The miner could work on them all at once, getting more from his hashes than difficulty warrants. Vince's solution is to constrain the paths by which Namecoin blocks may be embedded in Bitcoin blocks. This works, but it complicates the picture for miners and chain designers in a future with many merged-mining chains. A better solution for new chains is to prevent the existence of linked series of aux chain blocks which lack proof of work. You might do that by requiring each aux chain block to refer (perhaps via its own coinbase or a new header field) to the "solution" (target-meeting hash of parent chain block) as well as the hash of the previous block in the aux chain. In Bitcoin, these two are the same, namely hashPrevBlock. Force blocks to refer not just to the previous block in the chain but to the proof of work on that block. A series of aux blocks all being worked on would not make sense, because the second block in the series would have to reference the first block's solution, so the first block would have to have been solved. |
|
|
|
|
Yum! Looking forward to a new class of entrepreneurs: chain aggregators who provide aux work Merkle trees to pools and will include anyone's new chain for a small fee. Vires in numeris!
|
|
|
|
Why it is not possible to use bitcoins
to pay for records in .bit distributed dns database ?
I ask because I want to track something else in the distributed database
and don't want to have separate currency
The bitcoin software does not accept transactions with name records, nor does it enforce rules for their transfer the way Namecoin is designed to do. Bitcoin developers want to exclude this functionality, I imagine because it would complicate the software and increase the block chain size for all users, and some users care only about the money function. Namecoin supports arbitrary name-value mappings, not just DNS records. I suggest you consider Namecoin for whatever you want to track. |
|
|
|
|
Six blocks in the last hour, five of them merged. Namecoin is back to more or less its peak hash rate.
|
|
|
|
A few different coins is ok for diversity, but I would dread the thought of thousands of different types of coins. Just exchanging them will be a logistic nightmare.
You see and ignore thousands of ads when you browse the web. If someday there are thousands of cryptocurrencies, you will ignore most of them, too. Whoever cares enough to promote one over the others will have the burden of catching the market's attention, the same as with any product. |
|
|
|
The chain is Tenebrix. It seems that block 7177 and 7320 have dupe coinbases and the second transaction in block 9971 spends one of those. It's while trying to insert this when it fails.
Good sleuthing! Indeed, this is a bug. While I think about the right fix, you might get past it with this: diff --git a/Abe/DataStore.py b/Abe/DataStore.py
index a04333c..5eec013 100644
--- a/Abe/DataStore.py
+++ b/Abe/DataStore.py
@@ -1426,12 +1426,13 @@ store._ddl['txout_approx'],
# Create rows in block_txin.
for row in store.selectall("""
- SELECT txin.txin_id, obt.block_id
+ SELECT txin.txin_id, MAX(obt.block_id)
FROM block_tx bt
JOIN txin ON (txin.tx_id = bt.tx_id)
JOIN txout ON (txin.txout_id = txout.txout_id)
JOIN block_tx obt ON (txout.tx_id = obt.tx_id)
- WHERE bt.block_id = ?""", (block_id,)):
+ WHERE bt.block_id = ?
+ GROUP BY txin.txin_id""", (block_id,)):
(txin_id, oblock_id) = row
if store.is_descended_from(block_id, oblock_id):
store.sql("""
|
|
|
|
Don't listen to Lolcust, he created new *coins (sorry... *Gelds) using the best available create-your-own-*coin tool (MultiCoin) and has an interest in its not getting easier for his potential competitors. I would like to see what EskimoBob proposes and more. Anyone with an economic theory, not just programmers, should be able to start a coin with features chosen from off-the-shelf software modules and custom configuration. The way to improvement lies through unfettered experiment. I wrote about this a while back: https://bitcointalk.org/index.php?topic=29135.msg444863#msg444863 |
|
|
|
|
Show Posts
