there is a way to prove that you are running the full node.
there is only one way.
this way is well-known for 6 years.
the answer is: mining.
just create and broadcast new valid block and this would be a proof that you are running full node.
I don't know if you are joking or forgot about SPV mining. It isn't that simple. |
|
|
|
This thread is getting hard to follow. There seem to be various mixups going on. p2pool is an alt chain of its own and it has miners. Bitcoin nodes don't mine though.
Altchain is better terminology than altcoin. It is like subordinate chain or side chain, but ultimately pays in the coin of the mainchain. "nodes don't mine" is more or less temporary. After few more knees on the distribution curve the incentives will align more toward propagating transactions instead of trying to snipe the coinbase with a small block. This is incorrect. Although, you can't incentivize the process of just running a node, you have to incentivize both the speed and volume of the process of tx propagation.
I think that this opinion seems to miss the that there are two p2p protocols within the Bitcoin network: a) real-time transaction and block propagation network b) historical block synchronization network Currently they are awkwardly rolled into a single p2p protocol, with a branch appearing fairly recently "relay network" that concentrates on task (a). The task (b) is currently badly served by the original legacy protocol. Sooner or later the Bitconin developers will understand that they need to import more features from the well developed bulk transfer protocols like Bittorrent and maybe even from paid on-demand streaming. "headers first" isn't a real solution, more of a temporary workaround. Certainly it doesn't subsume the bulk-transfer functionality of a better-engineered protocol like bittorrent. Why altcoin? It is more like p2ppool, but instead of shares for mining one would get shares for proven transaction propagation.
That's a bit hard to do when their are things like pseudonode. Pseudonode cheats only on the task (b) above, I think it does decent job for task (a). Other than this I don't really understand the above comment. The current situation in the Bitcoin brain trust is that almost everyone suffers from some sort of brain constipation about how to change a single line of code static const unsigned int MAX_BLOCK_SIZE = 1000000; Ultimately this problem is going to solve itself in some way and people will again resume working on other long-term issues. |
|
|
|
To prove they're full nodes you'd have to invent some kind of "proof of work" and add it to some kind of blockchain - congratulations you've invented mining and an altcoin blockchain.
Why altcoin? It is more like p2ppool, but instead of shares for mining one would get shares for proven transaction propagation. |
|
|
|
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. |
|
|
|
Are we really in 2015 ?!  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 |
|
|
|
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) or 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. |
|
|
|
I keep trying to laugh at this. Reading bitcointalk.org is very much like reading some theological discussions. Around 2012 bitcointalk.org was at split between monocoinists and polycoinists. https://bitcointalk.org/index.php?topic=56912.0Right now bitcointalk.org 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: https://en.wikipedia.org/wiki/Deuterocanonical_bookshttps://en.wikipedia.org/wiki/Index_Librorum_ProhibitorumWho are the lead developers of this implementation? https://github.com/btcsuite/btcd/graphs/contributorsThey think that they will gain something by releasing the release with the same numbers as the next Core release.  Maybe there will be already another release of this full node at the time of the 0.12.0 of the core. @2112 Maybe "Alternative fullnode bitcoin implementation in Go" wasn't clear enough @Lauda 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 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Well, some people didn't learn from the history about cross-subsidizing. So the time to start learning is about now. https://en.wikipedia.org/wiki/Conglomerate_(company)Edit: one more Wikipedia link that is relevant both historically and currently: https://en.wikipedia.org/wiki/Hong_(business)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... |
|
|
|
- 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. |
|
|
|
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 https://bitcointalk.org/index.php?topic=815712.msg9245823#msg9245823and 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.
|
|
|
|
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. |
|
|
|
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(n 2) (or maybe even O(n 3)) 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)? |
|
|
|
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. |
|
|
|
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 docs.oracle.com that I should read? There is a lot of documents here. Thank you! The general online documentation is at: http://docs.oracle.com/cd/E17076_04/html/index.htmlbut Bitcoin Core is using older version (4.8.30?) http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.htmlThe entire older version is in the source archives: e.g. http://download.oracle.com/berkeley-db/db-4.8.30.zipI 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. |
|
|
|
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 docs.oracle.com 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 https://en.wikipedia.org/wiki/Write-ahead_logging and this is exactly pessimal application for flash memory: all writes and no reads. |
|
|
|
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 -> https://www.blocktrail.com/tBTC/blocks/1and a thread I cant find atm... here -> https://bitcointalk.org/index.php?topic=1241662.0Thanks 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. |
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Show Posts
