do you think you could also make a powerpc port using the same method?
The reference bitcoin client only supports little endian CPUs, which typically rules out PPC, SPARC, ... |
|
|
|
I have a temporary solution. Currently the satoshi client has hard code of historical block hash (currently at about height 190000). Could we also hard code all the unspent output to the satoshi client up to a certain block height?
Yes. For each output, only the transaction id, output order, script, and the block height are needed.
You just need a hash of the UTXO set at a given height, really. Then later UTXO sets may be provably traced to the checkpoint hash. |
|
|
|
caveden, there have been several other full reimplementations. BitcoinJS is one, I think UfaSoft made one, and actually I just finished merging code from Matt that makes bitcoinj a fully verifying ultra-prune style implementation as well (of course, it can still run in SPV mode too).
I'm aware about the efforts to make BitcoinJ a full node, what I find quite good. I don't know about "UfaSoft", and didn't know BitcoinJS was a full node implementation either, I thought it depended on a bitcoind running on the server. Nice to know all this. is also a full node implementation (sans wallet!). It fully verifies mainnet and testnet3 chains, passing all available applicable conformance tests. It's good to see another implementation though. |
|
|
|
I think the last page of the case study into Bitcoin is quite negative and pretty much scare mongering............
"Bitcoin is a high-risk system
for its users from a financial perspective, and that it could collapse if people try to get out of the
system and are not able to do so because of its illiquidity."
"Further action from other authorities
can reasonably be expected in the near future."
That is not scaremongering, it is 100% accurate. Right now, in its early stages, bitcoin is very high risk compared to many other financial instruments out there. We know the S.E.C. is investigating Pirate and PPT (hopefully cleaning out the swamp), so, indeed, further action from authorities can be reasonably expected. It is important to set expectations properly with bitcoin. This is a high risk experiment; just like any startup business, there is a large chance of failure for any number of reasons. |
|
|
|
bounty still "alive"?
Yes. I'll personally keep it alive, matching the $subject pledge (200 BTC). Updated OP. |
|
|
|
I stopped seeding. There were no leechers for few days now, problem discovered is not fixed, and I'm solo mining (50+ connections).  That may be problem with your client or firewall. I'm seeding only since yesterday evening and now it has > 300M uploaded already, using Deluge 1.3.5 . Under ideal conditions, where you have enough seeders to make each new download saturate the client's download link, that produces a situation where you have several seeders and many periods of idle time, punctuated by short bursts of network activity. I'm definitely seeing daily downloads here, but we could use some more seeders nonetheless. Bittorrent also helps more for unexpected bursts of network traffic -- like those accompanying a new bitcoin version release, for example. |
|
|
|
Only the issuer needs to have any block chain bulk, so the Asset Issuer ID, the Bitcoin Address - are the same thing.
Each smart property token has its own separate block chain storage, just like individual bitcoins. Additionally, if you want a fully auditable system -- we do -- then you need a commonly agreed way to make payments to token holders (asset owners) viewable and traceable in the block chain. That way, you can see which issuers are paying as they claim. |
|
|
|
|
This 2GB bootstrap.dat import problem should be present on all 32-bit systems, as a consequence of using fseek() on a signed 32-bit long internally.
We will work around this in the next release of the bitcoin client. Until then, 32-bit platform will simply cease importing earlier than expected, but still import a fair amount of the block chain.
|
|
|
|
|
At least one C API uses a 32-bit signed integer ("long") on 32-bit platforms, for file offsets and such. It is potentially a limitation due to the seeking that LoadExternalBlockFile() performs in the source code.
|
|
|
|
|
Is this on FAT32 or NTFS also?
|
|
|
|
How could you prevent double spend attack with cross-chain trading?
In general, see Contracts: cross-chain tradingDouble spending is always possible even on a single chain. Adding multiple chains implies you would want to post to the weaker chain first. The largest risk tends to be "holdup risk", where one sender simply refuses to proceed with the transaction. In that case, Party A would be forced to double-spend, to secure the coins it wanted to trade with Party B. |
|
|
|
Atomic coin swapping can be implemented with today-enabled features and it is inherently 100% secure.
Cross-blockchain trade requires support for 'contracts' and non-traditional scripts, and it has different security considerations:
If the bitcoin protocol were modified, we would use atomic coin swapping too. If you make it in another chain, you can make atomic coin swapping with the new hostcoin, which you need anyway to incentive miners and pay them tx fees. I definitely think that a "smart property chain" separate from the main bitcoin chain should be pursued. It helps separate purposes (currency vs. property registry) and keep property registry data out of the mainnet chain. The main practical obstacle is getting the smart property chain into the common merged-mining merkle root that pools obtain from the merged-mining daemon. If people are interested in working on a smart property chain The Right Way, let me know and we can coordinate. My smartcoin (formerly pybond) project will include some cross-chain trading support for precisely this purpose. In fact, I am seriously thinking that cross-chain trading should be prioritized over making a solution that works in the main bitcoin chain. |
|
|
|
Azureus/Vuze
Let it sit for a while to gather nodes via DHT. Since it's trackerless you won't instantaneously get all the available seeds. My torrent client says it knows of 18 seeds and 3 peers. As mentioned upthread, Azureus sadly walls itself off onto "Azureus island", and in my testing, does not find peers as quickly as all other clients tested. Making things worse, Azureus' DHT is separate from the mainline DHT. TheButterZone: try installing the "mlDHT" plugin for Azureus/Vuze. This connects you to the mainline DHT. |
|
|
|
Ooh. Even though I don't use the client, I'm getting this to seed indefinitely (at least when my computer is on and BT is open). Except there's only 1 seed now, no peers. Will it be worth the sectors on my hard drive to keep this going?
What bittorrent client are you using? Seeing 12+ seeds here. |
|
|
|
So is BDB still used at all? (e.g, for peers.dat and wallet.dat? ) Or will that likely be changing with the upcoming release that includes ultraprune?
peers.dat is a flat file with a bitcoin-specific file format, unrelated to any database system. wallet.dat remains BDB, though there are proposals on changing that. |
|
|
|
I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work).
Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat
to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. |
|
|
|
Sigh. In that case, with p2pool being 400 GH of a 20TH network, then GBT is only going to benefit 2% of the miners. It's pretty obvious by now you can't force people to do what you think is best. If anything, GBT with non-p2pool pooled mining will make it more likely that pools will not want to pass on lots of transactions and will be worse than getwork.
How about adding an extension to GBT that has some kind of mode that sends a "suggested merkle root" for pooled mining?
Definitely interested in extensions that broaden the userbase as much as possible. Even for bitcoind (rather than a pool server), extensions like this make sense. The old "getwork" protocol did as much work as possible on the server side, thereby minimizing the miner's work -- notably the miner did not have to care about anything besides the block header itself. No transactions or other parsing to worry about. getblocktemplate is intended to replace getwork. If there are improvements to be made, I'm quite open to that. Ping me on IRC, if you want to rapidly iterate some changes to make bitcoind's GBT work better for a wider selection of mining softwares. I did the final getblocktemplate polish, simplifying and cleaning things up from its original BIP 22/getmemorypool state. If BIP 22 / BIP 23 are currently missing something you want... I want to put it in there. |
|
|
|
|
Show Posts
