Bitcoin Forum
December 01, 2015, 11:44:00 PM *
News: Latest stable version of Bitcoin Core: 0.11.2 [Torrent]
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 89 »
1  Bitcoin / Mining speculation / Re: bitcoin computer! on: Today at 07:58:44 PM
I believe it is underclocked to 50gh/s for the cooling mechanism
The underclock is not because of cooling. They have a really complex DRM processor on the mining chip that prevents changing the mining payout address. The heat and electrical noise of the usual mining operating point would prevent DRM from working.
2  Other / Meta / Re: Security bounties on: November 29, 2015, 12:34:17 AM
Are we really in 2015 ?! Tongue
No, we are in a time-loop. We went back to about 1970 when the sales of "time-shared" computer services were at their highest. ....
Some years off in that one...1970 was mostly punched cards.  I'd guess timeshared computer services maxed out in parallel with the first five or ten years of the PC.
Not in the USA and other relatively advanced economies. There the order was approximately:

196x) organization-owned mainframes
197x) shared rented mainframes (provider-owned)
198x) departmental minicomputers (back to organization-owned)
199x) personal computers (both organization-owned and individual-owned)

Also, I'm talking about broad industrial/commercial/academic trends, not about various niches.

Edit: added one more decade and ownership qualification

3  Bitcoin / Development & Technical Discussion / Re: O(1) Block Propagation, IBLT on: November 25, 2015, 02:56:46 AM
But the 'O(1) block propagation time proposal' essentially merges the consensus and networking layer.

Notable problems:

1. Engineering would like to keep the networking layer and consensus layer separate because of architectural decisions for eg; difficult to push networking upgrades

2. The IBLT compression is just a way to check whether a data (transaction) is part of a dataset (transactions in mempool) when collision is low. For this to work, the mempools must be almost same. Syncing unordered data in a trust-less distributed system is a hard problem. Some propose ordering them, but that promotes censorship and centralization.
That would be true only for very lame implementations.

Non-lame implementation will have a smarter choice of the constant(s) size(s) of the bitmaps. The optimal (or near-optimal) size of the bitmaps will be a function of two parameters, either
S = F(number  of public txns , number of private txns)
S = F(number of public txns , cumulative size of private txns)
where "public txns" are the pre-propagated transactions and "private txns" are the ones that were miner-private and weren't seen before on the P2P network.

There can be a doubt whether transaction is public or private for two reasons:

a) miner isn't sure if the transaction was really well-propagated over the P2P network

b) miner isn't sure if the transaction could possibly hit a corner case of the consensus code

it is then always safe to locally reclassify it from 'public' to 'private' before compiling the particular IBLT bitmap.

It is not worth to spend to much time and energy on maintaining the global shared idea of the best mempool. It is only a convoluted way to minimize the size of the IBLT bitmaps.
4  Bitcoin / Alternative clients / Re: Btcd Version 0.12.0 Released - Alternative fullnode bitcoin implementation in Go on: November 23, 2015, 01:59:58 AM
I keep trying to laugh at this. Reading is very much like reading some theological discussions.

Around 2012 was at split between monocoinists and polycoinists.

Right now is undergoing the further split of monocoinists into at least three doctrinal branches:

1) Catholic Bitcoiners
2) Protestant Bitcoiners
3) Eastern Orthodox Bitcoiners (led by Mircea Popescu in Romania)

What we are observing here is the conflict about the "canon" of Bitcoin, roughly equivalent to the 16th century splits in Christianity:

Who are the lead developers of this implementation?

They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes
Maybe there will be already another release of this full node at the time of the 0.12.0 of the core.

Maybe "Alternative fullnode bitcoin implementation in Go" wasn't clear enough Roll Eyes

By my thoughts I think that this should be sticked as the one of the Bitcoin Core, but I know, I'm too old here Roll Eyes
Then you've posted in the wrong section and you know it.

It's kind of a harsh policy, but to be fair, bitcointalk mods are at least consistent: all threads about alternative clients are in their own sub, it was that layout/policy when I joined up 3 years ago.
5  Bitcoin / Alternative clients / Re: Btcd Version 0.12.0 Released - Alternative fullnode bitcoin implementation in Go on: November 22, 2015, 07:21:17 PM
Ha, ha! Too funny! I need to preserve this exchange.

wow, that was fast i was expecting it in a month, at this point it was better to just release this and skip the 0.11.2
Maybe you like to write a lot because of your signature, and this is the reasons that you didn't notice that this isn't Bitcoin Core.
Then you've posted in the wrong section and you know it. This is an alternative client. Who are the lead developers of this implementation? They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes
6  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: November 21, 2015, 12:59:11 AM
Of course the last few pages are filled with dribble, no understanding of the filings being read and very poor conclusions are being drawn from dogie and others.. I am not going to jump in the middle of it since it looks like I'd be trying to tech a Kindergartner finance in the case of dogie.. All I will say if that if folks on the forum are looking for a real assessment of the filings they need to get someone qualified to review them to weigh in...
It is a common problem of the libertarian web sites: they are generally anti-education, because schooling allegedly is brain-washing and destroys creativity. The problem is compounded on the Bitcoin web sites: when somebody tries to post some nontrivial information requiring some minimal self-education in accounting he immediately gets branded as anti-Bitcoin, statist and a tool of the banking establishment.

It is also the reason why reading the Bitcoin web sites is so fascinating: it is like a safari or a dive in a shark cage. But there's no real blood, is just a bloodless transfer of capital.

7  Bitcoin / Development & Technical Discussion / Re: Priority Transactions; What Are The Implications? on: November 20, 2015, 09:54:55 PM
Well, some people didn't learn from the history about cross-subsidizing. So the time to start learning is about now.

Edit: one more Wikipedia link that is relevant both historically and currently:

I wonder if it is possible to produce any theoretical results on the conglomerates:

1) mining pool integrated with an exchanger
2) mining pool integrated with a service provider
3) two or more mining pools (one bitcoin, other alt-chains) joined together through an exchange

Cross-subsidies may be a new frontier. Conglomerates became popular after 1960 to deal with the variance in the dividend income. They still exist in a vastly narrower range, primarily to extract the additional profits from cross-promotion and unified bargaining.

Using your terminology a conglomerate would convert the green line to a green plane: high risk and high variance wouldn't be the opposites but a pair of coordinates on a plane.

Limiting block size creates an inefficiency in the bitcoin system.  Inefficiency = profit.  This is a basic law of economics, though it is usually phrased in such a way as to justify profits by pointing out that they eliminate inefficiencies.  I am taking the other position, that if we want mining to be profitable then there needs to be some artificial inefficiency in the system, to support marginal producers.  Of course that profit will attract more hashing power thus reducing/eliminating the profit, but at a higher equilibrium.  However, I am not too worried about this aspect of large block sizes.  It is a fairly minor problem and one that is a century away.
This is fairly common misconception that the only way to pay for the space in a mined Bitcoin block is with fees denominated in bitcoins. But this is not true when a miner is integrated with an exchange, because an exchange can shave commissions on both sides of the transactions.

Imagine for a moment that Bitfury branches out into Consolidated Furies and spawns Hryvnafury, Roublefury, Eurofury, DollarFury, etc.; all of them being exchanges. It can then easily outcompete pure Bitcoin miners because it can directly funnel fiat commissions into electric utility bills without having to go twice through the fiat<->coin exchange.

Edit: In fact opportunities for integration are not limited to mining + coin exchange. Imagine for example Marijuanafury which does two things demanding lots of electricity: Bitcoin mining and indoor marijuana growing. If only somebody could come up with new optical ASIC technology that is pumped with energy via photons at the same wavelength that stimulate photosynthesis...

8  Bitcoin / Hardware / Re: 21 Bitcoin Computer software teardown on: November 20, 2015, 03:37:48 AM
  • the 21co patent is not wrong, they did literally hard code their mining address into the chip, external work has their coinbase address stuck on the end no matter what you send to the chip

I was expecting a lot more, it's just a few python libraries and a centralized API.
Are they doing ECDSA signing of the coinbase transaction in the hardware? Or do they just perform a bitstring replacement in the coinbase transaction and then re-hash it with SHA-256, also in the hardware?

Could you clarify?

Edit: rephrased my ambiguous question.
9  Bitcoin / Bitcoin Discussion / Re: Blocksize on: November 19, 2015, 01:31:22 AM
My favorite one - the solution that was suggested at the conference: introduce the second type of blocks that contain transactions only and issued 60 times more often, every 10 seconds or so. Those blocks are not for determining winner of reward, so they won't cause orphan problems. This solution will give us 60 times more space for transactions and reduce confirmation time 60-fold!  I think it is the perfect solution, even better than lightning, since it's not hub-based.
This is the solution that came out of people associated with p2ppool: fold p2ppool protocol into core protocol as a proof-of-propagation through proof-of-work. It is at over a year old, I've discussed it on this board in October 2014:
Re: Increasing the block size is a good idea; 50%/year is probably too aggressive

and I don't recall if I haven't seen it elsewhere before.

But then as usual within the Bitcoin milieu: it is more interesting to try to follow who was opposing that type of proposal and with what kind of argumentation; e.g.

a) is vulnerable to sybil attacks
b) smothers the incentive to include any transactions in blocks: why should I (as a miner) include a tx if the fee would go to someone else?

Also it seems both  are too disruptive  to be implemented in bitcoin.
Anything this much different would take an altcoin to be tried.

10  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: November 17, 2015, 03:24:51 AM
I'd say Spondoolies is finished. What a fuck up.
I wouldn't worry too much in advance. If BTCS/Spondoolies goes through a quick bankruptcy it is a perfect opportunity for somebody to pick up their assets for cheap. It all depends on the quality of the legal advice the potential asset stripper is going to buy. The current situation at Spondoolies is very much different from the Hashfast bankruptcy where the bankruptcy lawyers didn't consult the tort lawyers regarding possible tunneling or other fraud.

Hashfast had a lame chip with no valuable intellectual property. If Spondoolies is sitting on a mostly working chip (especially if it passed engineering sampling on a shuttle wafer run) then ordering a set of full-wafer masks would be a perfect turnaround play.

11  Bitcoin / Development & Technical Discussion / Re: O(1) Block Propagation, IBLT on: November 12, 2015, 03:12:52 PM
How big is the constant in the constant time propagation, compared to say, regular propagation models?
I think your question isn't posed properly. The better way would be to observe that IBLT is O(1) in space and somewhere between O(n) and O(n2) (or maybe even O(n3)) in time. Then the proper way of asking the question would be: under what circumstances IBLT produces lower orphan probability than just sending the straight linear list of transactions (O(n) in space and O(n) in time)?
12  Bitcoin / Technical Support / Re: Problem with a lot of hdd writes on big wallet.dat on: November 10, 2015, 11:18:20 PM
Sometimes when I getting exciting challenge, I can not fall asleep for a long time )
Just don't try to drive a car. Take a public transport like bus or metro. I don't want you to kill yourself by falling asleep while driving.

I just realized that my previous advice isn't good for you. I think that you are just one-man-company with programming skills at the level of a beginner. My advice was directed at somebody who is more skilled.

I see that 4 months ago your wallet.dat was half the current size. From the questions you asked in the last message I think the limit of what you could successfully program yourselves is as follows:

Write a BerkeleyDB program that deletes the old inactive accounts and transactions from your online wallet and saves them for a separate not-really-online wallet. This program will not need to work with bitcoind live, it is better to shut it down, run this program, and restart your online wallet. The not-really-online wallet can be run on a separate machine and will not really affect the responsiveness of your web front end.

This board is full of the incorrect advice for the desperate people in your situation. But I'm not going to throw you to sharks.

The English way to describe your situation is: "up shit creek without a paddle". I like the old Russian poet's advice more:
Белеет парус одинокий
В тумане моря голубом!..
Что ищет он в стране далекой?
Что кинул он в краю родном?..
Играют волны - ветер свищет,
И мачта гнется и скрыпит...
Увы, - он счастия не ищет
И не от счастия бежит!

Под ним струя светлей лазури,
Над ним луч солнца золотой...
А он, мятежный, просит бури,
Как будто в бурях есть покой!
A lonely sail is flashing white
Amidst the blue mist of the sea!...
What does it seek in foreign lands?
What did it leave behind at home?..

Waves heave, wind whistles,
The mast, it bends and creaks...
Alas, it seeks not happiness
Nor happiness does it escape!

Below, a current azure bright,
Above, a golden ray of sun...
Rebellious, it seeks out a storm
As if in storms it could find peace!
Edit: corrected formatting with dummy first table column.
13  Bitcoin / Technical Support / Re: Problem with a lot of hdd writes on big wallet.dat on: November 10, 2015, 03:22:38 AM
I did 1 and 2.
What command line arguments need to use for db_stat?
Only this works for me  "db_stat -d wallet.dat" (on shutdown bitcoind)
multiple-databases      Flags
And can you to point me a documentation from that I should read? There is a lot of documents here.
Thank you!
The general online documentation is at:

but Bitcoin Core is using older version (4.8.30?)

The entire older version is in the source archives: e.g.

I don't know the flags to the version of the BerkeleyDB included in your Linux distro. If it isn't exactly the same as your bitcoind then it isn't going to work until you rebuild all the db_* utilities with the exact same flags as used to build bitcoind.

One thing that you obviously missed is that you quoted an output from the "list of databases" inside "wallet.dat". The actual Bitcoin wallet is inside that file within a database named "main".

The other thing that you missed is that if you get all versions and build flags of BerkeleyDB right you will be able to monitor everything inside wallet.dat live, without shutting down bitcoind. That is the whole point of the exercise!

Edit: Oh, and I just noticed one more thing: it is about 5am in Ukraine. Did you actually sleep tonight? This isn't a 5 minute job that any zombie can do, you need to be really awake and conscious.

Edit2: In another past post you've mentioned that you are using the built-in account functionality. The "accounts" in Bitcoin Core never worked right. They are now officially depreciated. Nobody is going to fix any performance bugs in that code. You can't easily fix those bug yourselves because the "accounts" were designed wrong and fixing them would require major rewrite. The only people who ever used built-in accounts were fraudsters and people who have absolutely no understanding of accounting. I presume you were just completely unfamiliar with accounting and that was why you used them.
14  Bitcoin / Technical Support / Re: Problem with a lot of disk writes on big wallet.dat on: November 10, 2015, 12:34:58 AM
I have txindex=0.

I propose that's wallet.dat I/O because I see portions of increasing in "iotop -to -a" output.
And each portion is about 480 Mb. Exactly as wallet.dat size. That's why.
To me it looks like somebody is repeatedly calling "backupwallet" on your server.

Anyway, here's the quickest way to find out:

1) create DB_CONFIG file with one line "set_lg_dir database"
2) start the bitcoind with -privdb=0
3) use db_stat to monitor it live
4) download (and read or at least skim) the documentation from

The easiest way to fix the large wallet.dat problems is by adding two more physical disk drives to your server: one for wallet.dat one for its log directory ("database" by default, but it is best to change it). Adding SSD drives doesn't help much because it uses and this is exactly pessimal application for flash memory: all writes and no reads.
15  Bitcoin / Development & Technical Discussion / Re: What happened on the testnet around block 584474? on: November 09, 2015, 10:36:22 PM
I noticed sudden spikes of the CPU load from the testnet Bitcoin Core instances. High and prolonged enough to turn on the fans in my machines, which is very rare. Unfortunately I don't have time to investigate this myselves. I see nothing out of ordinary in the debug.log, ordinary for the testnet that is. mempool is also somewhat high, again for the testnet.

AFAIK BIP 101 supporters split the testnet. They created a high number of empty blocks. After the split there was a huge fork ~12 hours, difficulty is now reset (1.000) and the usual chaos after a diff reset happens.

At least thats what I picked up durring the day, mainly from here ->

and a thread I cant find atm... here ->
Thanks for your suggestions.

Well, difficulty reset to 1.000 happens all the time since Gavin made that change years ago; when the most recent block is more that 20(?) minutes old. Long forks also happen quite often on testnet, but I don't recall such a CPU-intensive one. I will have to put more computers online with BIP101 compiled in.
16  Bitcoin / Technical Support / Re: Problem with a lot of writes on disk on big wallet.dat on: November 09, 2015, 10:23:25 PM
How do you know this is wallet.dat I/O only? I would've thought that the majority of I/O is related to the LevelDB chain state storage, which frequently does large reorganizations of its internal storage levels, especially with txindex=1.
17  Bitcoin / Development & Technical Discussion / What happened on the testnet around block 584474? on: November 09, 2015, 05:29:57 PM
I noticed sudden spikes of the CPU load from the testnet Bitcoin Core instances. High and prolonged enough to turn on the fans in my machines, which is very rare. Unfortunately I don't have time to investigate this myselves. I see nothing out of ordinary in the debug.log, ordinary for the testnet that is. mempool is also somewhat high, again for the testnet.
18  Bitcoin / Technical Support / Re: Bitcoin Qt wallet (win32 & 64) more and more corruption problems and reindexing on: November 09, 2015, 02:25:48 AM
I don't use antivirus software or malware software, i found it totally unnecessary , I do a full HDD image of every machine I have once a year, so if something goes out of control i got a quick solution.
OK, so actually you are dependent on the 3rd party utility for the integrity of your Windows installations. In that case probably all of them are corrupted in the same way somewhere in registry or low-level disk/controller drivers or other places that don't undergo integrity checking when cloning.
In the past we (my corp.) had site-license customers where the entire corporation was unable to successfully run our software. The thorough investigation had shown that all the failing machines were installed using some imaging software (Norton Ghost/Clone? for desktops, some vendor specific (Samsung Recovery Solution?) for laptops). Doing a clean install from the Microsoft distribution media miraculously cured all the problems.

I'm very suspect of the system maintenance practices in the Windows market segment since I learned the inside scoop about bankruptcy of 3dfx. Near the end all of their official corporate system images were having undetected corruption issues and the only the few developers who could do work were those who bough retail boxed Microsoft media. That was despite having spent literally millions on internal Windows IT management and consulting.

My corp. internally used Acronis and as far as I know they still haven't fixed the bugs I submitted to them years ago regarding imaging NTFS disks with files processed with some old Microsoft consumer photo editing software, which creates complex NTFS alternate streams. Edit: found it:!
19  Bitcoin / Technical Support / Re: Bitcoin Qt wallet (win32 & 64) more and more corruption problems and reindexing on: November 08, 2015, 07:34:28 PM
Are your Windows installations relatively clean (of 3rd party utilities) or are you using e.g. same antivirus on all installations? Bugs in online antivirus programs are the most frequent issue with database-heavy applications, not just Bitcoin Core. Some antivirus engines automatically recognize popular database engines (e.g. MSSQL,Oracle,Sybase,...) and self-disable themselves on database files.

Edit: The most common corruption is in the "chainstate" directory. You can save yourself a lot of reindexing time by doing a backup of those directories using e.g. 7zip in "synchronize files" mode. In case of corruption just restore the known good chainstate and the reindexing will pickup near the end and will finish quicker.

20  Bitcoin / Development & Technical Discussion / Re: bitcoin core RPC compatible lite wallet proxy? on: November 02, 2015, 06:55:02 AM
Ok, we're talking about two completely different things here.  You're talking about large organizations with multiple corporations and bank accounts spread across the globe, who deal with 10s or 100s of millions in funds, and report to the likes of FinCEN, correct?  In that case, I doubt an out of the box solution would even be possible, because every system would have to be customized for that specific business (model).  I'm assuming folks like Bitstamp go with custom solutions, because they have millions in their budget to do so.

And yes, my solutions are meant for the small business owners, the 1 - 5 man shops or similar.  People that make say $100k - $500k/year.  For my target audience, my solutions work beautifully.

If you're looking towards folks like BitStamp, et al, then sounds as though the market is wide open for you, if you can put together even a base system that can be easily customized.  You're basically talking about writing your own node, correct?  That's a fairly adventurous task, and many have failed at trying, including myself.  Could be lucrative if you managed to pull it off though.  Probably wouldn't get too many clients, but when you're signing $1.5mm contracts, you don't really need many.

EDIT:  You mentioned the bitcoind & "accounting" servers must both be online, but that's not true.  If bitcoind goes down, when it comes back online, it'll begin firing all necessary "blocknotify" and "walletnotify" commands as it downloads the blockchain from where it left off.  Then just write a quick JSON API to communicate between the servers, queue the txs / blocks, send JSON request, if a proper response is received remove tx / block from queue.  If proper response not received, leave in queue and retry at regular intervals until proper response is received.

I don't buy your claim that your solutions "work beautifully". You are basically serving the market of "everyone knows the root password of the server". You can't properly provide elementary security like, e.g.

1) the web design subcontractor can't have the passwords to the accounting server
2) the are two independent web store fronts: the production one that is open 24*7 and the staging one for beta testing that is open intermittently and possibly managed by a different webmaster

It is also very telling that in your last paragraph you foresee closing down web front-end while having the accounting open. But the most real businesses operate in an opposite way: the web front end is open 24*7 but accounting is regularly being closed (weekly, monthly, quarterly) for periodic reporting and auditing.

I understand that there is a big market for "fly-by-nights" that essentially operate until the first audit by taxation authorities or first investigation by police/prosecution/regulators. I can't blame you for serving it, but I will stay away and always advise everyone else to stay away too.

There's a big disconnect between the two markets you mentioned: one-password shop with up to five people and multibillion corporation. The best example is what Microsoft targets with Server Essentials (a.k.a.) Small Business Server. The organizations of up to about 50 people who tend to subcontract various non-essential activities to the specialist firms. The people who know how to produce reports using Microsoft Access and why every commercial SQL database engine has some sort of per-column security.

Anyway, returning back to the ideas described in the opening post of this thread: it would be nice to have a Bitcoin engine that works somewhat like any other database engine. In the sense that you can start the engine itself to track the Bitcoin P2P network and then attach and detach wallets like one would attach and detach databases to the SQL engine.

But this isn't going to happen under current Bitcoin Core Development Team. In 2012 I mentioned something similar in the "What's the problem with getting Bitcoin compliant with GAAP???" and Gavin Andresen replied:
When I hear that, I hear "you should stop doing what you're doing for a year or two or three and re-implement the whole thing."

Yeah... no.  As much as that would be a fun project, I don't think that is the job of the team working on the existing reference implementation. Keeping the existing software and network running as smoothly as possible is the highest priority.
I think the current governance situation in the Core team could lead to the change in the general direction of the development. Time will show.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 89 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!