Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
I've been following the discussion of the block size limit and IMO it is clear that any constant block size limit is, as many have said before, just kicking the can down the road. My problem with the dynamic lower limit solution based on past blocks is that it doesn't account for usage spikes. I would like to propose another dynamic lower limit scheme: Let the block size limit be a function of the number of current transactions in the mempool. This way, bitcoin usage regulates the block size limit. I'm sorry i don't have the knowledge of the code base or time to make simulations on this kind of approach, but nevertheless I would like to leave it here for discussion or foster other ideas. cheers -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
2015-06-01 0:40 GMT+01:00 Pindar Wong : > > > On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe > wrote: >> >> He also said that the equation for miners has many variables, as it >> should. There is no disadvantage if the network speed is the same >> between the miners. > > > Hi, > > Is that an assumption? no, let me rephrase: The disadvantage alex refers to only exists if miners do not have the same network speed. > >> If there is a difference in network speed, the >> miner is incentivized to invest in their network infrastructure. > > > Perhaps it's best not to assume that investing in Internet network > infrastructure's a free or open market everywhere. Just like easy ASIC access, low price electricity, etc are not a free and open market. > > p. > >> >> >> 2015-05-31 23:55 GMT+01:00 Alex Mizrahi : >> >> Yes, if you are on a slow network then you are at a (slight) >> >> disadvantage. >> >> So? >> > >> > >> > Chun mentioned that his pool is on a slow network, and thus bigger >> > blocks >> > give it an disadvantage. (Orphan rate is proportional to block size.) >> > You said that no, on contrary those who make big blocks have a >> > disadvantage. >> > And now you say that yes, this disadvantage exist. >> > >> > Did you just lie to Chun? >> > >> > >> > >> > -- >> > >> > ___ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > >> >> >> -- >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
He also said that the equation for miners has many variables, as it should. There is no disadvantage if the network speed is the same between the miners. If there is a difference in network speed, the miner is incentivized to invest in their network infrastructure. 2015-05-31 23:55 GMT+01:00 Alex Mizrahi : >> Yes, if you are on a slow network then you are at a (slight) disadvantage. >> So? > > > Chun mentioned that his pool is on a slow network, and thus bigger blocks > give it an disadvantage. (Orphan rate is proportional to block size.) > You said that no, on contrary those who make big blocks have a disadvantage. > And now you say that yes, this disadvantage exist. > > Did you just lie to Chun? > > > -- > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Electrum 2.0 has been tagged
i guess you look at the glass half full :) even though what you say is true, we should aim for wallets not to require those instructions, by standardizing these things in BIPs. let's hope bitcoin doesn't fail in standards as our industries have in the past... 2015-03-11 19:04 GMT+00:00 Jim : > The wallet words system isn't perfect for sure but it does help the user in > two main ways: > 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the > user knows they can recover their bitcoins using the same wallet software in > case of a Bad Thing Happening. > 2) To an imperfect degree, they can transfer/ recover their bitcoins that are > stored in Wallet X into Wallet Y. We need to give them guidance on how to do > this. > > I think it is up to each wallet team to explain to their users clearly how > they can do this in their help. It's only good manners to show your guests > where the fire exits are. > > It can be a simple help page saying: > "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do > this, this and this. > If you want to use the Trezor wallet you created in MultiBit HD on > myTrezor.com, do this, this and this." > > That way users have clear instructions on how to recover their bitcoins. > Users don't care about BIP this or BIP that but they REALLY DO CARE about > keeping their bitcoins. > > -- > http://bitcoin-solutions.co.uk > > On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote: >> Sigh. The wallet words system is turning into kind of a mess. >> >> I thought the word list is in fact not a fixed part of the spec, because >> the entropy is a hash of the words. But perhaps I'm misunderstanding >> something. >> >> The main problem regular SPV wallets have with BIP39 is that there is no >> birth time included in the data. Therefore we must ask users to write down >> a timestamp as well, so we know where to start rescanning the chain. It >> sounds like the Electrum version doesn't fix this, so now we have at least >> FIVE incompatible results from a 12 word list: >> >>- Electrum v2 with a version number but no date >>- myTREZOR with no version and no date and BIP44 key derivation. Some >>seeds I believe are now being generated with 24 words instead of 12. >>- MultiBit HD with no version and a date in a custom form that creates >>non-date-like codes you are expected to write down. I think BIP32 and >> BIP44 >>are both supported (sorta). >>- GreenAddress with no version, no date and BIP32 >>- Other bitcoinj based wallets, with no version and a date written down >>in normal human form, BIP32 only. >> >> I really hope we can recover from this somehow because otherwise all >> wallets will have to provide the user with a complicated matrix of >> possibilities and software combinations, and in practice many won't bother >> so these word combinations will actually end up being wallet specific for >> no particularly good reason, just very minor details like the presence or >> absence of single fields. >> >> It feels like we somehow fell flat on our faces just before the finishing >> line. This is deeply unfortunate. Compatibility and UX consistency is >> important! >> >> Currently, I don't have any bright ideas for how to get everyone back onto >> the same page with a fully compatible system that is acceptable to all. If >> anyone else has suggestions, I'm all ears. >> -- >> Dive into the World of Parallel Programming The Go Parallel Website, >> sponsored >> by Intel and developed in partnership with Slashdot Media, is your hub for >> all >> things parallel software development, from weekly thought leadership blogs to >> news, videos, case studies, tutorials and more. Take a look and join the >> conversation now. http://goparallel.sourceforge.net/ >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software deve
Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies
As a researcher in a distributed systems group, it is awesome to see these papers flocking up that help convince the supervisors to pay more attention to blockchain technologies. thanks for keeping us up to speed. 2015-03-02 16:48 GMT+00:00 Andrew Miller : > We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten, > Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have > written a “systemization” paper about Bitcoin-related research. It’s > going to appear in the Oakland security conference later this year > (IEEE Security and Privacy) but we wanted to announce a draft to this > community ahead of time. > > http://www.jbonneau.com/doc/BMCNKF15-IEEESP-bitcoin.pdf > > One of the main goals of our work is to build a bridge between the > computer science research community and the cryptocurrency community. > Many of the most interesting ideas and proposals for Bitcoin come from > this mailing list and forums/wikis/irc channels, where many academic > researchers simply don’t know to look! In fact, we started out by > scraping all the interesting posts/articles we could find and trying > to figure out how we could organize them. We hope our paper helps some > of the best ideas and research questions from the Bitcoin community > bubble up and inspires researchers to build on them. > > We didn’t limit our scope to Bitcoin, but we also decided not to > provide a complete survey of altcoins and other next-generation > cryptocurrency designs. Instead, we tried to explain all the > dimensions along which these designs differ from Bitcoin. > > This effort has roughly been in progress over two years, though it > stopped and restarted several times along the way. > > If anyone has comments or suggestions, we still have a week before the > final version is due, and regardless we plan to continue updating our > online version for the forseeable future. > > -- > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ricardo Filipe GSD/INESC-ID Lisboa -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain pruning
that's what blockchain pruning is all about :) 2014-04-10 17:47 GMT+01:00 Brian Hoffman : > Looks like only about ~30% disk space savings so I see your point. Is there > a critical reason why blocks couldn't be formed into "superblocks" that are > chained together and nodes could serve a specific superblock, which could be > pieced together from different nodes to get the full blockchain? This would > allow participants with limited resources to serve full portions of the > blockchain rather than limited pieces of the entire blockchain. > > > On Thu, Apr 10, 2014 at 12:28 PM, Mike Hearn wrote: >> >> Suggestions always welcome! >> >> The main problem with this is that the block chain is mostly random bytes >> (hashes, keys) so it doesn't compress that well. It compresses a bit, but >> not enough to change the fundamental physics. >> >> However, that does not mean the entire chain has to be stored on expensive >> rotating platters. I've suggested that in some star trek future where the >> chain really is gigantic, it could be stored on tape and spooled off at high >> speed. Literally a direct DMA from tape drive to NIC. But we're not there >> yet :) > > > > -- > 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 > -- 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] Chain pruning
anyway, any kind of compression that comes to the blockchain is orthogonal to pruning. I agree that you will probably want some kind of replication on more recent nodes than on older ones. However, nodes with older blocks don't need to be "static", get the block distribution algorithm to sort it out. 2014-04-10 17:28 GMT+01:00 Mike Hearn : > Suggestions always welcome! > > The main problem with this is that the block chain is mostly random bytes > (hashes, keys) so it doesn't compress that well. It compresses a bit, but > not enough to change the fundamental physics. > > However, that does not mean the entire chain has to be stored on expensive > rotating platters. I've suggested that in some star trek future where the > chain really is gigantic, it could be stored on tape and spooled off at high > speed. Literally a direct DMA from tape drive to NIC. But we're not there > yet :) > > -- > 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 > -- 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] Draft BIP for seamless website authentication using Bitcoin address
2014-04-07 21:08 GMT+01:00 Troy Benjegerdes : > I have to play dissenter here again.. > > Using a bitcoin address as a persistent identity key is the first real-world > use of Bitcoin that I can imagine will make it a 'killer app' that everyone > and their grandma will want to use. > I am of the same opinion, although i understand Gavin's point. Would the multisig seed work for this purpose? I have been toying with this idea and I think that for this BIP to make sense it would require a "root" key as your login. Then if you need to make transfers the system would request you to create and associate a new key to your account for each purchase (signing the new key with the root one for example). -- 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] Why are we bleeding nodes?
Or have blocks distributed through pruned nodes as a DHT. 2014-04-07 20:13 GMT+01:00 Mark Friedenbach : > > > On 04/07/2014 12:20 PM, Tamas Blummer wrote: >> Validation has to be sequantial, but that step can be deferred until the >> blocks before a point are loaded and continous. > > And how do you find those blocks? > > I have a suggestion: have nodes advertise which range of full blocks > they possess, then you can perform synchronization from the adversed ranges! > > -- > 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 -- 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] Why are we bleeding nodes?
phasing out of bitcoinqt into spv wallets? 2014-04-07 12:34 GMT+01:00 Mike Hearn : > At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and > still falling: > >http://getaddr.bitnodes.io/dashboard/chart/?days=60 > > I know all the reasons why people might stop running a node (uses too much > disk space, bandwidth, lost interest etc). But does anyone have any idea how > we might get more insight into what's really going on? It'd be convenient if > the subVer contained the operating system, as then we could tell if the > bleed was mostly from desktops/laptops (Windows/Mac), which would be > expected, or from virtual servers (Linux), which would be more concerning. > > When you set up a Tor node, you can add your email address to the config > file and the Tor project sends you emails from time to time about things you > should know about. If we did the same, we could have a little exit survey: > if your node disappears for long enough, we could email the operator and ask > why they stopped. > > -- > 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_APR > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- 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_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
Kevin, the thing is you gave us a bad link... what is the correct URL of your project? 2014-04-02 16:30 GMT+01:00 Kevin : > On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote: >> Maybe this site serves up exploits selectively? I'm guessing most people >> are getting the 'domain for sale' but whoever is the target probably gets >> something special? >> >> On Apr 2, 2014, at 2:53 PM, Kevin wrote: >> >>> On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin wrote: > I've sat on this for some time after starting this. I have forked this > from bitcoin core and am working on a secure tax "mode" for bitcoin. It > is written in Autoit. I know I know, scripting language alert! I would > like people to look at: > http://www.githubb.com/bitcoin/bitcoin > Look at it, and let's have an open dialog about it. I want to know the > good, the bad, and the ugly! > > -- > Kevin > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> As far as choice of U R L, it may be a poor choice but I did this >>> because I wanted it connected with the core. As far as fishing it >>> certainly is not that! This is a serious project. >>> >>> >>> -- >>> Kevin >>> >>> >>> -- >>> ___ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > I tell you that this is a serious project for bitcoin. You are free to > assume the worst. After all, I did say the good the bad and the ugly > would come out of this. I happen to be a big believer in bitcoin and I > feel this project holds water. If you disagree, that's fine. > > > -- > Kevin > > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
2014-03-25 13:49 GMT+00:00 Peter Todd : > On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote: >> On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd wrote: >> >> > Bitcoin doesn't scale. There's a lot of issues at hand here, but the >> > most fundemental of them is that to create a block you need to update >> > the state of the UTXO set, and the way Bitcoin is designed means that >> > updating that state requires bandwidth equal to all the transaction >> > volume to keep up with the changes to what set. Long story short, we get >> > O(n^2) scaling, which is just plain infeasible. >> > >> >> We have a fundamental disagreement here. >> >> If you go back and read Satoshi's original thoughts on scaling, it is clear >> that he imagined tens of thousands of mining nodes and hundreds of millions >> of lightweight SPV users. > > Yeah, about that... > > https://blockchain.info/pools > On-topic: This argument is quite the fallacy. The only reason we have that few pools is because each of their miners doesn't find it feasible to mine "on their own". if you count the individual miners on those pools you will get to the scale Gavin was trying to point out. Nevertheless i think that is just a minor disagreement, since tree chains help decentralization. > For someone with 'Chief Scientist' as their job title, I'm surprised you > think so little of hard evidence and so much of idol worshipping. > > > P.S. A year or so ago you complained that if I cared so much about > decentralization, I should make P2Pool better. Your homework: What do > tree-chains and Andrew Miller's non-outsourcable puzzles(1) have to do > with that? What about the cube-square law? And why don't I think TXO > commitments solve the blocksize problem? > > 1) https://bitcointalk.org/index.php?topic=309073.0;all > > -- > 'peter'[:-1]@petertodd.org > 20366a15799010ae0432be831c197e06b19133028a9aa6f3 > > -- > 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/13534_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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
so much discussion for a visual update...
make this a user experiment:
-give the user the possibility to use BTC/mBTC/uMTC
-retrieve the results after some time
-make the default the most used option
2014-03-14 16:15 GMT+00:00 Alex Morcos :
> I think Mark makes some good arguments.
> I realize this would only add to the confusion, but...
> What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
> whatever else), with a proper 3 letter code, and then from a user
> standpoint, where people are using mBTC, they could switch to using Kbits
> (ok thats obviously bad, but you get the idea) at the same nominal price.
> But accounting backends and so forth would operate in the "bit" base unit
> with 2 decimals of precision.
>
>
>
>
> On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach wrote:
>>
>> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
>> numbers in both Chinas, Thailand, and other economically important East
>> Asian countries. Expect to pay hundreds of rupees in India, or thousands
>> of rupees in Indonesia.
>>
>> This concept that money should have low, single digits for everyday
>> prices is not just Western-centric, it's English-centric. An expresso in
>> Rome would have cost you a few (tens of?) thousand lira in recent
>> memory. It was pegging of the Euro to the U.S. dollar that brought
>> European states in line with the English-speaking world (who themselves
>> trace lineage to the pound sterling).
>>
>> No, there is no culturally-neutral common standards for currency and
>> pricing. But there are ill-advised, ill-informed "standards" in
>> accounting software that we nevertheless must live with. These software
>> packages do not handle more than two decimal places gracefully. That
>> gives technical justifications for moving to either uBTC or accounting
>> in Satoshis directly. An argument for uBTC is that it retains alignment
>> with the existing kBTC/BTC/mBTC/uBTC conventions.
>>
>> However another limitation of these accounting software practices is
>> that they do not always handle SI notation very well, particularly
>> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
>> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
>> compliant with any software accounting package out there.
>>
>> We are still very, very early in the adoption period. These are changes
>> that could be made now simply by a few big players and/or the bitcoin
>> foundation changing their practice and their users following suit.
>>
>> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
>> > How much do you pay for an Espresso in your local currency?
>> >
>> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>> > people would expect. Certainly more familiar than µBTC 3558 or BTC
>> > 0.003578.
>> >
>> > Anyway, I was just sharing real-world experience: nobody is confused.
>> >
>> >
>> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> >> You give them a hard to interpret thing like mBTC and then wonder
>> >> why they rather look at local currency. Because the choices you
>> >> gave them are bad.
>> >>
>> >> I think Bitcoin would have a better chance to be percieved as a
>> >> currency of its own if it had prices and fractions like currencies
>> >> do.
>> >>
>> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> >> would be.
>> >>
>> >>
>> >> Tamas Blummer Bits of Proof
>> >>
>> >> On 14.03.2014, at 15:05, Andreas Schildbach
>> >> wrote:
>> >>
>> >>> btw. None of Bitcoin Wallet's users complained about confusion
>> >>> because of the mBTC switch. In contrast, I get many mails and
>> >>> questions if exchange rates happen to differ by >10%.
>> >>>
>> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
>> >>> local currency that matters to the users.
>> >>>
>> >>>
>> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>> Indeed. And users were crying for mBTC. Nobody was asking for
>> µBTC.
>>
>> I must admit I was not aware if this thread. I just watched
>> other wallets and at some point decided its time to switch to
>> mBTC.
>>
>>
>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>> > The standard has become mBTC and that's what was adopted.
>> > It's too late to try and sway this on a mailing list thread
>> > now.
>> >
>> >
>> > On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>> > mailto:g.r...@froot.co.uk>> wrote:
>> >
>> > The MultiBit HD view is that this is a locale-sensitive
>> > presentation issue. As a result we offer a simple
>> > configuration panel giving pretty much every possible
>> > combination: icon, m+icon, μ+icon, BTC, mBTC, μBTC, XBT,
>> > mXBT, μXBT, sat along with settings for leading/trailing
>> > symbol, commas, spaces and points. This allows anyone to
>> > customise to meet their own needs beyond the offered default.
>> >
>> >
>> > We apply the NIST gu
Re: [Bitcoin-development] Service bits for pruned nodes
Of course. My proposal was just for the pruned nodes. I.e. You would have a majority (maybe not even a majority required) of nodes storing the whole blockchain and pruned nodes would store "random" parts of the blockchain, according to the resources they have, which would be organized as a DHT. 2013/5/16 Jeff Garzik : > On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe > wrote: >> We would only end up with few copies of the historic data if users >> could choose what parts of the blockchain to store. Simply store >> chunks randomly, according to users available space, and give priority >> to the "N most recent" chunks to have more replicas in the network. >> >> You don't need bittorrent specifically for a DHT, if publicity is a >> problem. There are many DHT proposals and implementations, and i bet >> one of them should be more suitable to the bitcoin network than >> bittorrent's. > > That's just about the worst thing you could do for bitcoin. DoS one > part of the DHT, you DoS the entire blockchain by breaking the chain. > > -- > Jeff Garzik > exMULTI, Inc. > jgar...@exmulti.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Service bits for pruned nodes
We would only end up with few copies of the historic data if users could choose what parts of the blockchain to store. Simply store chunks randomly, according to users available space, and give priority to the "N most recent" chunks to have more replicas in the network. You don't need bittorrent specifically for a DHT, if publicity is a problem. There are many DHT proposals and implementations, and i bet one of them should be more suitable to the bitcoin network than bittorrent's. >On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn wrote: >> I'd imagined that nodes would be able to pick their own ranges to keep >> rather than have fixed chosen intervals. "Everything or two weeks" is rather > >X most recent is special for two reasons: It meshes well with actual demand, >and the data is required for reorganization. > >So whatever we do for historic data, N most recent should be treated specially. > >But I also agree that its important that be splittable into ranges >because otherwise when having to choose between serving historic data >and— say— 40 GB storage, a great many are going to choose not to serve >historic data... and so nodes may be willing to contribute 4-39 GB storage >to the network there will be no good way for them to do so and we may end >up with too few copies of the historic data available. > >As can be seen in the graph, once you get past the most recent 4000 >blocks the probability is fairly uniform... so "N most recent" is not a >good way to divide load for the older blocks. But simple ranges— perhaps >quantized to groups of 100 or 1000 blocks or something— would work fine. > >This doesn't have to come in the first cut, however— and it needs new >addr messages in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
