Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
> How much will that cost me? > The network is hashing at 310PetaHash/sec right now. > Takes 600 seconds to find a block, so 186,000PH per block > 186,000 * 0.00038 = 70 extra PH > > If it takes 186,000 PH to find a block, and a block is worth 25.13 BTC > (reward plus fees), that 70 PH costs: > (25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC > or at $240 / BTC: $2.27 > > ... so average transaction fee will have to be about ten cents ($2.27 > spread across 23 average-sized transactions) for miners to decide to > stay at 600K blocks Surely that's an *extra* $2.27 as you've already included .13BTC ($31.20) in fees in the calculation ? Rob -- 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
Re: [Bitcoin-development] DNS seeds unstable
> > dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs dnsseed.bitcoin.dashjr.org. 60 IN NS jun.dashjr.org. but jun.dashjr.org isn't responding to dns queries (as at 18.10 GMT 2014-05-16) that would be a fundamental problem with the dns infrastructure for that domain (and the sub-hosts/records) , with the authoritive server not replying to the dns query > > testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica Similarly no response from the alias'd aws dns service on 23.21.243.183 (testnet-seed-ns1.bitcoin.petertodd.org) from various test locations in Europe If there's a requirement for a domain & highly redundant dns to hard-code into something, and one of the dev's drops me an email, I can get that organised FoC, but these issues look like 'common' firewall/transit/connectivity issues at first glance. Rob -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "bits": Unit of account
> The average person is not going to be confident that the prefix they > are using is the correct one, The use of any 'prefix' is one of choice and entirely unnecessary, and there are already established 'divisions' in u/mBTC for those that feel they need to use such things. > people WILL send 1000x more or less than > intended if we go down this road, Exceptionally unlikely - I deal every day with currencies with 0, 2 and 3 dp's in amount ranging from 'under 1 whole unit' to tens of thousands - Not once in 20 years has anyone ever 'sent' more or less than intended - oh, they've 'intended' to underpay just fine, but never *unintended*. > 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. I propose that for people unable to understand what a bitcoin is, they can just use satoshi's and drop this entire proposal. Rob -- 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] Getting trusted metrics from the block chain in an untrusted environment ?
> My program should run on lightweight/embedded hardware. The execution > environment provides access to the Bitcoin network but not enough > resources to set up a trusted node along with my program. So you want to 'benefit' from the network without contributing to it ? > I would need a way to ask an untrusted Bitcoin node to compute some > 'metric request' on my behalf and having the result of that metric > request validated by the network. Not going to happen - why would anyone be interested in providing you 'free compute resources' ? > Is there any available or work-in-progress projects that would come > close to this need ? Or should I do it myself ? :-) Setup a node, create an API interface and have your 'app' use your API on yoru node :p Rob -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge mining
> But there's so much 'dry powder' out there (GPUs), I wonder if *not* > supporting merge-mining is any better? At least the attacker has to do > some unique PoW, so you hope it's costing them something. With lots of people having access to 100TH+ there's not really much 'cost' to doing a 51% attack on an alt-coin beyond a short-term diversion away from 'profitable' mining. At least by supporting merged mining, more miners are likely to 'support' multiple coin types, thus making a 51% attack from an individual/group less straightforward. >> The rational decision for a non-scam altcoin, is to take advantage of >> merged mining to get as much security as possible. Exactly. Rob -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Possible Solution To SM Attack
> The Problem: > Say Alice built a block, A1, from previous block 0. She doesn't let > other miners know about it. She then works on A2 with previous block > A1. Bob on the other hand is still working on B1 with previous block > 0. Bob now finds a block and he broadcasts it. The assumption here is > Alice will be the first miner to hear of this block and she will send > her previously mined block, A1, to all other miners. By the time Bobs > block arrives to other miners majority of them will already have > received Block A1 and Bobs block will most likely be orphaned. Alice > revealed her block, A1, only when Bob broadcast his block. This means > she has been mining on block A2 with previous block A1 for longer than > any other miner thus gaining an advantage without increasing her hash > rate. Unless A1 gets orphaned and B1 gets accepted, in which case all the work done on A2 is 'wasted'. The question is whether there is any 'real' advantage over time for A over B. > What We Know: > Alice has gained an advantage with time. She mines longer on the valid > block. She mines longer on *a* block which *may* become the valid block, yes. > In order for this attack to work Alice must reveal her previously > mined block as late as possible, gaining her the most time spent > working on the valid block. Since she has such good view of the > Bitcoin network she can wait until a miner finds a block to release > her previously mined block. Then the simple 'fix' would be for the block-acceptance to take into account either the total transactions or the total fees, and for the the 'accepted' block for mining the next block to be the one with the lowest hash of one of those values if 2 are released to the network at the same time That is of of course assuming there is really a problem to fix, currently I'm not convinced. Rob -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?
> But the regulatory environment in many geographical regions in > uncertain. Do we need to pay capital gains? Do we need to pay a > sales taxs etc. etc. In most regions it's not only 'simple' but trivial - BTC is just 'another currency' and accounted for exactly the same way - it doens't matter if you sell your hose for GBP, USD, EUR, BTC or sacks of Pig Dung, you still have a GBP tax issue ... > So my idea is to voluntarily pre empt legislation by giving donations > to govt (aka taxation) for bitcoin service providers. You want to volunteer to pay tax ? I'd suggest stronger medication ... > However, there is something of a problem with voluntary donations. > Most people are not satisfied with the way they are spent. 80% of 'donations' end up spent on 'adminsitration' and not what they were donated for, this is a 'greed' issue not a 'currency' issue. > In the UK > a recent survey said that only 18% of people thought that tax money > was wisely spent. Tax isn't voluntary or a donation. The 18% who think UK tax is well spent are the 18% of the population who get the tax money, not the 82% that pay it ;) > Can we fix it? First we kill all the politicians ... > So let's say I run a business and I make 1 million euros. I wish to > donate 10% of my profits to society. But let's say I dont want that > money to go to wars of aggression, but rather, to the fire > de[department. So give it to the FD - what you do with your post-tax profits are up to you ;) > At this point everyone wins. The business person is happy to make a > contribution. The govt. is happy that it gets more revenue. The > fire dept. is happy that it has revenue to do its work. And > everything has gone to the right place in a kind of democratic way. Where does gov't come into this ? I think you're confusing 'tax' which you have zero control over and 'donations' which you already have 100% control over. Rob -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blockchain archival
> (there's no way to be completely trust-free without this). Not quite true, as I said balance-at-point-in-time would solve that (and make the storage requirements much lower) >> If going that route, then solutions to the 'consolidate >> addresses/wallets' >> question and formal 'discard' of addresses could get addressed. > > Not sure what you mean here. Addresses and wallets are two completely > different things. Addresses are single-use destinations that point to > a wallet > (which is itself private and unknown to the network). For bitcoin to grow beyond interesting experiment into global everyday use a number of things would have to happen, not least of which is taking 'average punter' into account. Whilst new ideas can filter into the general consciousness over time,sometimes concepts have to go with 'what already works' :) People's concept of money hasn't really changed in over 1,000 years - it remains 'something of known value i can exchange for something else'. No-one outside of bitcoin dev's and early adopters really gets the one-shot concept of addresses - possibly rightly so - keeping issues of it lowering levels of anonymity etc out of the discussion - it doesn't fit with the mindset people have - it's difficult enough getting merchants to setup separate addresses for each client, one per transaction is simply a waste (of addresses, storage, blockchain size, numnber of inputs|outputs when spending etc) I'm sure the wife would love a new handbag everytime she gets some money, but the real-world just isnt like that ;) Addresses are perceived as the equivalent of a jar you stick your coins in. You can have lots of jars. Each jar can be for a specific reason or whatever, but the analogy is there. Wallets are like a box you keep some of your jars in. With the added interesting concept that a jar can be in multiple boxes at the same time. Only the person with the right 'key' can open the jar and take the contents. However unlike the 3 money boxes I have behind me right now - which i can take 1 single penny out of one and put it into another - if I want to move bitcoins from one addresses (jar) to another *of my own* I have to pay a fee. Worse still if the jar doesnt have much in it I'm denied that ability. End user will neither understand why or want to pay the fee, for dealing with their own coins. If a jar breaks I can just tip the contents into a new one - unless I'm very careless, the amount in the new one = the amount in the old one - people will want/need it to work like that. Similarly if you do have all these addresses around, you may want (as good housekeeping) discard some of them (after moving the cash). So having the ability to specify address to send from is essential (and a sadly missing feature of the QT client) 'intra-wallet' transfers with an 'also discard the sending address' would be a way of (once confirmed) stopping any further use of that address (denied any further transactions by miners ?) and when balance-at-point-in-time is implemented, a way of shrinking the storage for all other bitcoin users (who chosse not to have a full transaction set). If i send luke 10, and luke sends me back 3, i have 3, luke has 7. If luke sends me 2, and i send luke 1, i have 4 and luke has 6. To verify my ability to send jeff 4, all that is needed is to know that I have 4, not all the transactions that led to that state - thats how its done now, thats not necessarily efficient as bitcoin grows If luke sends me 4 more, i now have 4 again, luke has 3 If i send 1 to each of the children, they have 1 each (*4) Having a 'family' wallet means when on holiday they can have that rental of quad-bikes - to send the rental company 4 the client only needs to know that those addresses now have 1 each in them, not all the previous transactions - if they didnt exist at the point-in-time balance, then yes, it would need to know about the luke>rob>kids transactions, but thats all I moved to a new netbook recently - it took 140 *hours* to d/load and process the blockchain (yes the wifi was that bad), I heard from one of our clients that (although they only had the client running during working hours) that to their desktop it was over 9 days before it had caught up. If all I was d/loading were the transactions since the last difficulty change (as one example of a fixed point), and the remaining balance on any not-discarded address as at that point it would have been much much quicker, and not be shagging my shiny new hard drive. There's more but it's 4.45 in the morning, and I cant think coherently until after a few hours kip and some good coffee :) Rob -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-ste
Re: [Bitcoin-development] Blockchain archival
> bitcoin protocol needs an archival system so the blockchain doesn't > become too big to download Some people may want it all ... Balance at Point-In-Time summaries (say up to the penultimate difficulty adjustment) would be one simple way. And make new-adopters get up and running in minutes not days, which can only be a good thing. If going that route, then solutions to the 'consolidate addresses/wallets' question and formal 'discard' of addresses could get addressed. Rob -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind
> It appears that we will soon be at a hashrate where all the desktop > CPUs in the world couldn't really make a dent in it... certainly not > desktop cpus using the slow integrated cpu miner, I thought the integrated miner was retired a version or so ago - I dontrecall seeing it for some time in bitcoin-qt Now you can buy a USB stick for $20 which can be pushed to around 500MH/s, and there's no reason the manufacturers couldn't ship those with a miner-program onboard ! Rob -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
