Re: [Bitcoin-development] Why are we bleeding nodes?
> The bottleneck is not bulk disk space, but rather IOPS. Exactly. I stopped running a full node on both of my desktops machines in the last month. Both systems were simply becoming very noticeable (=unbearably) sluggish. I am also running dedicated nodes, which are fine, but on a desktop latency is a major issue (or, let's say, a different issue than on a server). I didn't notice any network latency, but that's hard to judge as our internet is pants anyway. Arne PS: my machines aren't the newest, but still do a stellar job (without bitcoind running ;) -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
Hello, > While SI units are great for people well versed in them, there is a > very good reason people aren't asking for 100 micro dollars in change. > The average person is not going to be confident that the prefix they > are using is the correct one, people WILL send 1000x more or less than > intended if we go down this road, and these mistakes will happen > frequently. Labeling should be easy enough for kindergarten kids. Agree - but why do you propose not only a new label but also a different subunit? Also, everybody in the metric world is used to the milli- prefix due to meters and millimeters. It's not such a stretch to expect people to master that; but I agree that most people would struggle with microbitcoins. > I propose that users are offered a preference to denominate the > Bitcoin currency in a unit called a bit. Where one bitcoin (BTC) > equals one million bits (bits) and one bit equals 100 satoshis. There have been many proposals for more or less arbitrary subunits. What would be the merit of your proposal? I don't really follow the reasoning that it's better if it's uncommon for everyone rather than just uncommon for people not used to metric units. Regarding the label of a "bit": I have to agree with the others that bit is heavily overused as a unit, but I am a computer scientist, so I don't have the "average joe's" perspective on this. I find it weird to use as it's already in use in English - "a bit of work" etc I don't really see the advantage of a "bit" - it is part of "bitcoin" and it's short, but that's about it. I think we are free to pick anything we want for a label, so why not avoid ambiguities? See this thread for many creative ideas for labels (and another arbitrary subunit proposal: https://bitcointalk.org/index.php?topic=396522.0 Arne -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
I agree that overloading isn't an issue when necessary, but my point was that the necessity is lacking. If we're free to pick anything, why pick something that is overloaded? Moreover, "bit" is an abbreviation of bitcoin and might be confused with it. Most currencies use a work that is phonetically very different and short, so why not do the same? Pluk, or cred, or finney (as proposed the thread I posted), or whichever. We could call it "unsp" for unspent ;) Arne On 20/04/14 20:11, Mike Caldwell wrote: > It is a paradigm that is easy to explain and grasp for neurotypical > people. > > The average mind has no problem overloading words and distinguishing > the intended meaning from context. For most people, overloading a > single syllable word with a new meaning is much less complicated than > using a unique 3+ syllable word like satoshi or micro-anything. > > Doing software development warps our minds to demand fully qualified > names for everything. We know our compilers would say "bit? Fatal > error 0xaaawtf, can't continue, not sure if you mean a Boolean or > a dog bite". But this peculiarity should not be projected onto the > people we are trying to get bitcoin to appeal to, not if we want them > to feel like we think about their experience. > > If I were to say "a Bitcoin can be divided into a million bits", less > than 0.1% of average joes would think I was talking about German > beers or the thing that goes in horses mouths. Really, most people > are good at using context to relate this to "a dollar can be divided > into 100 cents" and accepting it. This requires much less of their > mind resources than using SI prefixes correctly or learning 3 > syllable words that (to them) have no instantly apparent relationship > to Bitcoin. > > Mike > > Sent from my iPhone > > On Apr 20, 2014, at 11:44 AM, "Arne Brutschy" > wrote: > >>> I propose that users are offered a preference to denominate the >>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC) >>> equals one million bits (bits) and one bit equals 100 satoshis. >> >> There have been many proposals for more or less arbitrary subunits. >> What would be the merit of your proposal? I don't really follow the >> reasoning that it's better if it's uncommon for everyone rather >> than just uncommon for people not used to metric units. >> >> Regarding the label of a "bit": I have to agree with the others >> that bit is heavily overused as a unit, but I am a computer >> scientist, so I don't have the "average joe's" perspective on this. >> I find it weird to use as it's already in use in English - "a bit >> of work" etc > > -- > > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > ___ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Removing transaction data from blocks
Hello, At DevCore London, Gavin mentioned the idea that we could get rid of sending full blocks. Instead, newly minted blocks would only be distributed as block headers plus all hashes of the transactions included in the block. The assumption would be that nodes have already the majority of these transactions in their mempool. The advantages are clear: it's more efficient, as we would send transactions only once over the network, and it's fast as the resulting blocks would be small. Moreover, we would get rid of the blocksize limit for a long time. Unfortunately, I am too ignorant of bitcoin core's internals to judge the changes required to make this happen. (I guess we'd require a new block format and a way to bulk-request missing transactions.) However, I'm curious to hear what others with a better grasp of bitcoin core's internals have to say about it. Regards, Arne -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
