Why are you always using such harsh words? Maybe I am an idiot and you are super genius that is always right about everything.
I specifically limited my question to issues unrelated to software versions. just trying to understand things one piece at a time.
Now monsterer is saying it is always the same, you say it is probably going to increase. But I agree with you about the non PoW factors most likely dominating and since I am always wrong, does that mean you are wrong too?
You seem to have an excellent command of English for a non-native speaker. At the same time you seem to lack basic scientific education at the level of high school, where typically the "correlation vs. causation" is explained. In a previous thread you've exhibited 0/10 knowledge of basics of DBMS. I have no idea where you've received your education (home schooling? religious school?) but I haven't used any harsh words. I've used standard sentences that would be said by a teacher to a completely unprepared student face-to-face in any normal school. I'm not going to even delve into further scholastic experience like participating in competitive sports or military training. |
|
|
|
Sure, theoretically, but I dont like to just assume that the theory is precisely followed by reality.
My concern is with the practical. When did the ASIC's come out? That is a nonlinear increase in hashrate per amount of capital.
Yes I know the difficulty adjusts, but that is every 2016 blocks, there is a window of time where a technical leap increases the chance of larger reorg, but as time passes I think this chance is less and less.
Your analysis is bogus. Your are mistaking correlation with causation. The long term changes in the orphan rates are caused not by changes in hash rate but by changes in the number and connectivity of the mining pools. The number of pools decreased and the connectivity of the remaining pools improved. In particular Matt Corallo's Relay Network caused decrease in the orphan races. The probability of reorgs probably going to increase in the future due to the bugs in the competing implementations, due to DDoS attacks on the mining pool's infrastructure and due to Matt Corallo finally abandoning the maintenance of his Relay Network. The difficulty increase is just an innocent bystander. |
|
|
|
what was max depth with the one of 165 branches?
{
"height" : 363736,
"hash" : "000000000000000013fe26675faa8f7dccd55ce5485bb6d0373fa66345901436",
"branchlen" : 6,
"status" : "valid-fork"
},
|
|
|
|
it could be 2112's node is special
The results I posted were from a portable laptop that had seen multiple ISPs but runs only occasionally. On the other laptop that had seen only one ISP but runs more often I had 165 branches instead of 15. You'll need way more nodes to have meaningful statistics. |
|
|
|
very nice! didnt know it listed all reorgs.
so if I read that right since block 395487, the max depth reorg has been: 1
if so, does that mean a node that has been constantly running for 1 year would be needed to run getchaintips, to get the entire year's history of reorgs?
It seems 10 blocks at current hashrate would be very rare
James
More or less. But remember that the reorganizations aren't really globally identical. You'll really want several long-running nodes on several ISPs to have meaningful statistics. Also, testnet has way more and longer reorgs, very good for testing the handling of the reorgs. |
|
|
|
The official Bitcoin client has "getchaintips" command that gives you the output like this: [
{
"height" : 403263,
"hash" : "00000000000000000210fee63635c72da771c6b136a63f20ff9d058ce778618d",
"branchlen" : 0,
"status" : "active"
},
{
"height" : 402922,
"hash" : "00000000000000000692c289cc4a4e9726018d6a030ad10c84f70adc2e920597",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 402751,
"hash" : "00000000000000000180755378324c16847b2f49af428c763b8ff411d51d7767",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 402723,
"hash" : "000000000000000000263e1722b119e2547a4167b2f9d5bfc89f0d9dc28e0e18",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 399879,
"hash" : "0000000000000000005642fd14f92213a8ff68aa5071588f84dd2f1c61e93d0e",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 399706,
"hash" : "000000000000000006aef254935a76c8b321519dcd86d4f5f5092f51ef374251",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 399332,
"hash" : "000000000000000006972f107e48524ce3e01752c24a282beafc7b046f29f221",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 399247,
"hash" : "00000000000000000228b92c2c2c8a91673c45f6aa10fb9acabfb587f73ccc81",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 399138,
"hash" : "00000000000000000382da0f1d9cb0bffc6edbbdd53ba8f87877ffe11263100d",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 399098,
"hash" : "000000000000000001bb9eac7a0684d2d0481b9a7fe74568ada10ada5734c857",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 398487,
"hash" : "0000000000000000008fb4567640f05fddc79d28fcb0601a187b8e5cb46cb84c",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 398217,
"hash" : "0000000000000000078f1ed2154a4db3d7cfa5615c584585c07e3f53ddba6aa8",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 398205,
"hash" : "0000000000000000067886752a9524c8043341b5adc4100fbe11e7e45af1020d",
"branchlen" : 1,
"status" : "valid-headers"
},
{
"height" : 397486,
"hash" : "00000000000000000158e2c73ded7c24f0087514d646ae59ff017347bfff4c15",
"branchlen" : 1,
"status" : "valid-fork"
},
{
"height" : 395487,
"hash" : "000000000000000002782e988a2da3aa252752f3accae8624242527ca99de06e",
"branchlen" : 1,
"status" : "headers-only"
}
]
|
|
|
|
i don't get why would someone choose to call a friend in case of emergency!
emergency services like police, ambulance,... can get there much faster than my friends can. maybe it is good for some country that doesn't have a decent emergency service.
those devs should spend their time and money on something that has practical use.
This app is for ghettos and gangbangers. Like Fergusson, Missouri or the many French immigrant arrondissement. |
|
|
|
Have thermal printers at voting booths that give people SHA-3 hashes of their voter data they can use to lookup public voting records to verify there votes. Also allow SSN lookup(without their other data to avoid ID theft). Beats all possible fraud and costs less than any system used to date.
That is more or less the dream of the European neo-Nazis that would facilitate organized voter intimidation and allow the party bosses to verify that their voters "voted correctly". Mike Hearn proposed a variant of this using Trezor or similar devices, use search. Opps, sorry. I "could of" engaged an illiterate. The nazis could of just as easily used the most recent US voting system. If it can be tallied and has voter identification the nazis could of used it..
Have a OTP per voter with no other personal info? Nazis could of used it..
This sounds as rational and logical as most stuff I hear from left-wing enlightenment though..
Ninja edit: The nazis could of just as easily used the most recent US voting system. If it can be tallied and has voter identification the nazis could of used it..
Have a OTP per voter with no other personal info? Nazis could of used it, or just changed the vote since they control the data.. You won't give us your OTP?[family is killed]
This sounds as rational and logical as most stuff I hear from left-wing enlightenment though.. In the modern world you'll never get away with forcing millions or hundred of millions of people to vote a certain way and if each voter can validate their vote fraud becomes impossible. If a small country tried to force votes it's be extremely apparent to the rest of the world and domestic citizens..
Again people like to hide votes though because nobody wants the public to know this dislike welfare or immigrants, for example.
Another edit: The nazis could of just as easily used the most recent US voting system. If it can be tallied and has voter identification the nazis could of used it..
Have a OTP per voter with no other personal info? Nazis could of used it, or just changed the vote since they control the data.. You won't give us your OTP?[family is killed]
This sounds as rational and logical as most stuff I hear from left-wing enlightenment though.. In the modern world you'll never get away with forcing millions or hundred of millions of people to vote a certain way and if each voter can validate their vote fraud becomes impossible. If a small country tried to force votes it'd be extremely apparent to the rest of the world and domestic citizens..
Again, it's got nothing to do with fraud and security and everything to do with anonymity. Nobody wants an immediate relative to ask them to pull up their vote and see that they voted for higher taxes on farmers because they dislike laborers, for example.
I challenge you to make a system where not even the tally agents can identify the voter and there be no apparent fraud.. Else you're making a nazi system cause you're racist or don't like Starbucks lol..
|
|
|
|
My point, perhaps poorly expressed, was that if you think these problems are 'not hard', you must have solutions in mind, no? I'd be interested in hearing your ideas. I am genuinely interested, not being sarcastic here.
It wasn't only me that had those solutions in mind. In fact they are already included in the "segregated witness" proposal, but without the "segregation" part. The "segregation" just splits the transaction in two parts. In fact one could come up with a deficient "segregated witness" proposal that wouldn't fix the discussed problems. They are orthogonal concepts. Which solutions are you referring to here? The same we discussed less than an hour ago; 9:20am vs. 10:10am. The advantage of segwit is that it elegantly fixes a couple of other hard problems (malleability, O(n^2) sigops issue)
What about fixing those "other problems" (I don't want to say "hard", because IMO they aren't "hard" by themselves) without the segregation? Impossible or just not worth it? |
|
|
|
My point, perhaps poorly expressed, was that if you think these problems are 'not hard', you must have solutions in mind, no? I'd be interested in hearing your ideas. I am genuinely interested, not being sarcastic here.
It wasn't only me that had those solutions in mind. In fact they are already included in the "segregated witness" proposal, but without the "segregation" part. The "segregation" just splits the transaction in two parts. In fact one could come up with a deficient "segregated witness" proposal that wouldn't fix the discussed problems. They are orthogonal concepts. |
|
|
|
I don't claim to know the answer to that question, but your reply begs the question: Have you submitted a pull request with code that fixes these problems that you see as 'not "hard" by themselves'?
Submitting pull request without first discussing the viability of proposed "pull" is only for terminally naïve. Normal programmers do design first then code later, especially on a large financial project. |
|
|
|
The advantage of segwit is that it elegantly fixes a couple of other hard problems (malleability, O(n^2) sigops issue)
What about fixing those "other problems" (I don't want to say "hard", because IMO they aren't "hard" by themselves) without the segregation? Impossible or just not worth it? |
|
|
|
It doesn't matter. The real answer is simple: the storage layer s (plural!) need to be abstracted. No single engine could meet all needs. Of course. I did that for my first task at Ripple. You're telling me that Bitcoin Core still has not abstracted the storage layer? How could I know what they really did? I feel I need to copy-paste something I wrote nearly 4 years ago under "[POLL] Multi-sig or scalability--which is more pressing?". Gentle reminder to the other bitcoin developers: it is generally best not to feed trolls. Use the ignore button.
“If you sit in on a poker game and don’t see a sucker, get up. You’re the sucker.” http://quoteinvestigator.com/2011/07/09/poker-patsy/Anyway, here's the example of how open source poker is being played. A whale of a player spends big bucks developing a secret database engine. After 5 years this player takes one of the earliest branches and open sources it. Lets call that branch LevelDB. Suckers jump on it, spend money and energy to develop some basic tools like statistics gathering and query optimization. Then the whale brings the cold deck to the table, which gives him an instant 5 years of leadtime. It looks like that: Then, a month later, the main devs decided to switch to compressed public keys which requires a whole new wallet format for Armory. I was crushed.
I'm no Google insider or anything like that. But I used to knew the people who played with the current Googlers; and I'm broadly familiar with the level of skill involved. Before you spend to much time at the keyboard and mouse please do see the old David Mamet's movie "House of games". Remember the line: “it was only business … nothing personal.” |
|
|
|
maybe its just me misinterpreting the english as my second language and the above isnt claiming that it will increase the block capacity. I avoid political stuff so maybe I am just not understanding the nuances of the english. recently I found out that "sick" meant "cool", but cool wasnt about the temperature, but something else. So I guess it just matters what the meaning of the words "size increase" means.
Your English is very fine, in fact it is already better than the written word of many native English speakers. The mistake you are making is your avoidance of the "political stuff". There's no way to avoid learning about https://en.wikipedia.org/wiki/Political_economy . "segregated witness" is a neat tool that cleaves not only "big blockists" but also "small blockists" associated around Mircea Popescu's http://thebitcoin.foundation/ which considers 0.5.3 as the "original codebase". The key contribution of Adam Back is his update of https://en.wikipedia.org/wiki/Democratic_centralism vocabulary to the situation in 21st century. If you really try to understand what's going on reread the https://en.wikipedia.org/wiki/Twenty-one_Conditions , but replace "communist" with "bitcoinist" and "proletariat" with "bitcoinariat", "counter-revolutionary element" with "troll", etc. |
|
|
|
I don't think any miner has ever used more than one port out of the micro. Most chips are daisy-chained; ASICMiner used address-decoded chip selects on a common SPI bus (which I really like). It looks like this and the previous generation of Bitfury chips use a comm multiplexer that probably only needs one bus connection to the micro and then breaks out a couple dozen data pairs that would each go to a single chip.
We had this discussion about a half-year ago: 2) Star topology vs daisy-chain topology. On this I prefer star because the ICs need to be running at the edge of failure (thermal or noise), otherwise the project is not competitive.
2) I also prefer star over chain for comms.
I don't know exact circumstances of your decision-making and MCU-selection process. I'm not changing my opinion. To me daisy-chaining mining chips is still "tight" and "skating the edge of failure". Personally, I would never compete with Chinese by out-lame-ing their lame designs. My experience with embedded was writing 8-bit assembler, where I did in about 65 bytes what the C compiler wanted about 1k to accomplish. Most of what this chip will have to do are interrupt-based timer routines, and relaying data packets back and forth. The only limitation might be RAM buffering USB data packets, but the clock is plenty fast and there's probably an order of magnitude more code space than should be needed.
IIRC your experience was 8051. This is not representative with respect to modern architectures like AVR or ARM. With those the difference between hand-coded assembly and C/C++ is about 10%-20% at most. And not always hand-coded assembly wins, especially on ARM. In my experience the C/C++ firmware gets abnormally big only when the programmer doesn't understand the toolchain: pulls needless library routines like malloc() or printf(), does unnecessary exception handling, etc. |
|
|
|
If it has nothing to do with DBMS, then why did you keep doing the database class thing?
Because the title of this thread is about DBMS a.k.a. DB engines. Because of the fact that the data stored is actually about money. You just have zero experience dealing with financial data processing, and actually less-than-zero as far as legally-responsible fiduciary-duty-bound handling of money for other people. Therefore what you are doing are just educational toys. I have nothing against you designing and playing with those toys. But if you thinking that you are making something that will become a real financial product you set yourself for a CIYAM-level disappointment. https://bitcointalk.org/index.php?topic=1375689.msg13995422#msg13995422The CIYAM project has got a lot of criticism about being extremely hard to understand and I'd like to explain exactly why this is.
Initially the project was a closed source one originating from Australia (where I grew up) but once I moved to China in late 2006 I decided that due to the problems of enforcing copyright in China (i.e. no chance) that I would need to make the software "hard to understand" (a sort of security by obscurity approach).
So when I created the initial open source version of CIYAM it inherited years of such development that I had worked on in China (around 6 years).
I no longer actually support the ideas of patent and copyright so I actually don't care too much now about that - what I worked out how to do was to just make a software system so difficult to understand that those things are irrelevant (no-one has even bothered to try and fork my project and modify it).
|
|
|
|
It doesn't matter. The real answer is simple: the storage layer s (plural!) need to be abstracted. No single engine could meet all needs. |
|
|
|
If you think I am ignoring overall system speed, then you are not really reading my posts.
I also like kokoto's requirements and my dataset is designed to get good overall system performance for those, and also to be able to do blockexplorer level queries from the same dataset for lower level blockchain queries.
Not sure what your point is? Maybe you can try to run a DB system written in JS? I dont know of any that is anywhere fast enough.
It is not a choice between DB vs no DB, but rather no-DB vs nothing, as my requirement is for a system that works from a chrome app
James
You are making 2 unrelated mistakes: 1) mixing hardware speed with software speed. On fast hardware it is OK to have slow software. 2) your tests are only including sync speed (both initial and re-sync after getting temporary offline). You don't test continuous operation nor chain reorganization. This has nothing to do with using or not using a DBMS. It is a more fundamental question what your system will be capable of when finished. |
|
|
|
Not sure what you mean by tight. 50MHz with 2k RAM and 32KB code space is huge for what I need it to do.
It looks tight to me. But my experience with embedded systems is mostly related to medical-grade devices or with high reliability demands. Couple of weeks ago we've discussed daisy-chain versus star designs. With only 2 SPIs true star is doable for at most 2 mining chips. I also look at it less from the production system angle and more from testing and qualification system angle. Personally, I would grossly overspec the MCU in first system to make sure that I can do serious reliability testing and essentially reverse-engineering the chip I/O protocol. Then in production I would use some pin-compatible MCU with much lower specs. Or maybe design the board that the MCU could be tri-stated out of the real chip control and provide some pins to hook up external MCU with much better specs. Those pins could be left unpopulated in the shipping version to save costs. |
|
|
|
Otherwise we would still be using the slowest CPU that will eventually complete the tasks.
This is a self-refuting argument. Hardware gets faster therefore people are willing to put up with slower software. Do not confuse hardware speed and software speed when discussing speed of the whole system. Edit: A good example of clear thinking from somebody who isn't professionally doing software development: I think it's very important to be able to browse through all the records in a shortest possible time.
I disagree, the major requirements verify utxo spend verify utxo amount remove used txo add new utxos from block reorganize revert utxo |
|
|
|
|
Show Posts
