Bitcoin Forum
January 17, 2017, 01:15:05 AM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 232 »
481  Bitcoin / Development & Technical Discussion / Re: What is the status of BIP62? on: August 31, 2015, 07:03:10 AM
BIP62 is neither necessary or sufficient for micropayment channels;  CLTV is sufficient and nearly necessary.   Thats next in the pipeline;  unfortunately BitcoinXT has screwed up the soft-fork pipeline by getting a bunch of nodes deployed that produce super high version numberss, breaking the existing CLTV code... so people are working on revising those proposals now.
482  Bitcoin / Bitcoin Discussion / Re: Please list arguments against the idea of taking away Gavins' alert keys on: August 30, 2015, 08:04:30 PM
The alert functionality is nearly useless, and the usefulness it had has been outlived. No one ought to have the alert key.

At the same time, is also nearly riskless now that its already there-- anyone with the key can instantly terminate any announcement made with it and, if needed, permanently disable the alert system. Which is why when we proposed removing it, is wasn't hard for someone to argue otherwise.  In the next release of Bitcoin Core any participation at all in it will at least be optional (though default on):

In the elements alpha sidechain, alerts were replaced with multisignature... but I still hope in Bitcoin we remove the system entirely.  Theymos case of wanting to warn people about serious software issues could be accomplished by things like a transaction sending a specific (high vauled) coin to fees triggering a static message to tell users to check for notices.

The functionality creates inequality, it creates attack surface, its very infrequently used-- and when used appears to do very little good. But the biggest reason I'd like to remove it is that it promotes centeralized misunderstanding of the system. It is an incredibly weak functionliaty: a small collection of people can send a little text message to a (sadly) tiny portion of Bitcoin's users. Thats it. But many people can't help but believe that every system has someone in charge of it, and the alerts give them something to latch onto. As a result of alerts we've had to deal with frequent worthless suggestions like the alerts should be able to control system parameters (like fee settings and block size limits)... people who can't see shade of grey and think that because we'll tolerate a very mild messaging functionality that all sorts of other ill conceieved centeralization is okay.

In the altcoin space this has gone further-- e.g. there are several altcoins that use code based on the alert system to allow (or in peer coin's case-- require) the developer to use their single trusted private key to pin the identity of the chain, overriding the network's consensus process. It's an ugly path, and while the first step down centeralization road is easily argued to be harmless it would certantly save a lot of misunderstanding to clearly not be going down it.

483  Bitcoin / Development & Technical Discussion / Re: New Proposal to reduce space requirements for full nodes on: August 29, 2015, 07:50:55 PM
This is just the problem of the 0.11 implementation. Not a protocol issue. They will fix it in future version
Not even a problem-- the wallet support was just untested so it was disabled to avoid delaying the feature. It more or less worked from the very first patch (as 0.8 radically change the design of the software to accomidate that-- we've been working towards it for a long time).
484  Bitcoin / Development & Technical Discussion / Re: Miners should donate to Nodes on: August 29, 2015, 07:48:43 PM
Miners should send a little % of the fees of the block to all connected peers. Independently of the protocol.
Why would they choose to do that?

This has some MIM attack problems isn'it?
Yes, but even if that was resolved --- All that would seemingly do is incentivize people to sybil attack the network.
485  Bitcoin / Bitcoin Discussion / Re: Jeff Garzik chose BIP100 block size voting because Blockstream recommended it on: August 28, 2015, 09:08:28 PM
Perhaps not. But I'd say it is quite naive to think that technological advancements will continue to exponentially grow to infinity, as many seem to believe around here. In fact, Moore's Law seems to be unraveling as we speak. Just ask Intel what just happened to their tick-tock model.....

When I expressed the same concern to Gavin,  his response to me was:

I really, really don't understand this attitude-- I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.

My response was:

I'm confident that technology will improve. But it can improve nicely
but still be _utterly_ blown away by any particular pre-perscribed
growth formula (especially an exponential one). If the limit is some
multiple of what nodes can comfortably handle or real demand on the
network then its more or less equivalent to unlimited; so it doesn't
even have to be off by much.  I'm also experienced enough with large
scale systems to know that massive increases in scale expose new
behaviors and effects that were not visible in other regimes.  So, for
example in 1990 one might have correctly predicted the grown in raw
ALU throughput we've seen, but if you also assumed memory bandwidth
would have kept up you would be massively misplaced (factor of 100x+
off by now), and many problems become more memory bandwidth limited as
they scale.

This is especially a factor when you're talking about improvement of
the, say, 10th percentile rather than the best available technology--
which is very much a consideration.

There are also serious confounding trends. Computers are getting
better but more computing is moving onto battery powered tablet
devices which move backwards a decade in technology and on to cloud
hosted infrastructure which adds little decentralization in to
ecosystem. Sometimes the improvement in technology is rolled into
power, space, and cost savings and doesn't become readily available in
the forum of throughput. Sometimes the improvements show up in
specialized processors which may not be useful to us (e.g. most of the
multiply throughput and memory bandwidth in a high end desktop is in
the GPU right now). It wouldn't be an unreasonable guess that
computing power available at low cost to the general public may
increase slower even if raw technology improvement speeds up because
the improvements are going into other areas, esp. if applications
which need massive increases in local computing power don't
486  Bitcoin / Bitcoin Discussion / Re: Jeff Garzik chose BIP100 block size voting because Blockstream recommended it on: August 28, 2015, 09:05:22 PM
A misunderstanding can travel halfway around the world while the truth is putting on its shoes.

Here is the response I wrote on reddit:
Limitation of the twitter medium I assume there. I don't know why he's invoking "blockstream" there.

I asked Jeff on IRC what specifically the 75% that was in his document meant:

13:44 <gmaxwell> Technical question, it's unclear to the writeup how exactly you suggest miners signal their new size preference?  are you thinking that mine
rs express a preferred size in their blocks, and then the 75-th percentile size is used? (subject to the 2x limit) ?

13:50 <gmaxwell> What made you go for 75%?


13:52 <jgarzik> 75% = political science.  3/4 majority.


14:09 <gmaxwell> as far as the actual mechenism (which I don't see in the BIP); what I'd guess is that each block would express a preferred limit in the coinbase, next to the height,  and then at the update period those limits would get processed? e.g. taking the n-th percentile?  

14:10 <gmaxwell> (if that detail is in the bip, I'm missing it)  


14:14 <jgarzik> Anyway, on the BIP 100, basically the floor (least) of the range of most popular miner suggested sizes  

14:14 <jgarzik> "we all agree on this floor"  

14:15 <gmaxwell> jgarzik yea, if it took all the sizs, sorted, and then discarded 25% of the smallest ones, then took the smallest remaining size, it would accomplish that.

14:16 <jgarzik> size can decrease too, with 1MB absolute minimum.  

14:16 <gmaxwell> though maybe a number different than 75/25 would be good, I should talk to petertodd and see if his position would be changed if, say, it were 90%/10%.   Basically if you're below 5% hashpower you're not even getting a block per day on average, and so you couldn't even be doing much to prevent censorship.  

14:18 <gmaxwell> But e.g. should be we changing how the limit works slightly, e.g. making the 'size' include the change in the utxo size as I'd proposed before? so that the limit actually reflects the real costs in the network; .. absent something like that fees will never peanlize costly behavior there.

14:18 <jgarzik> nod - IMV tweaking those constants are easy while getting us past the 1MB hard fork

14:18 <jgarzik> & addressing governance are the hard parts

14:19 <jgarzik> agree RE UTXO - economically signaling those costs is important

I believe this is the entirety of my conversion with Jeff on the subject.  (I've removed many interspersed comments because IRC usually bifurcates into multiple threads of discussion due to latency; but I believe they are unrelated to this topic).  AFAICT, I never suggested 20%  but rather suggested a sensible meaning for what a 75% threshold might mean in his scheme, which to my eyes was under-defined but might have already meant that.

I don't think there is anything wrong with 20% as things go; though the main limitation in BIP100 (assuming any of the under-specified parts are filled in with things I find unobjectionable) is that it addresses only miner-vs-miner incentives issues, and even then only under assumptions about hashrate distribution which are currently untrue (e.g. right now less than one percent of the miners have >>50% of the hashrate, so BIP100 is basically a blank check to those few parties up to the 32MB limit).

Jeff's stated view is that users can be protected by exiting Bitcoin if miners are not acting perfectly, but there is incredible friction around markets (e.g. solution via exodus guarantees losers)-- "sell all your bitcoins and go use something else, is a really weak threat, in general. Because of the weakness of the threat I don't think this is a reasonable first-resort mechanism for assuring the security of the system-- I think we've already seen it disproved in practice, and under that argument, e.g. we could just give miners the ability to print infinite bitcoin, steal arbitrary coins, etc.
487  Alternate cryptocurrencies / Altcoin Discussion / Re: Fundamental flaw in consensus algorithms? on: August 24, 2015, 07:58:51 AM
Section 4.4 of

Seperately, selfish mining is basically orthorgonal. And as you note, it only works when a miner has a very high proportion of the hashrate. A system where any participant has anywhere near one quarter of the authority isn't all that decenteralized.
488  Bitcoin / Development & Technical Discussion / Re: How will XT be good with regards to the packet frame? on: August 24, 2015, 07:53:27 AM
A block never fit into a single packet.
The relay network protocol fits a significant fraction of all blocks into a single packet (about a third, ... about 60% fit in two packets), in fact.

489  Bitcoin / Bitcoin Discussion / Re: Szabo just tweeted this on: August 21, 2015, 10:32:13 AM
whats interesting is Peercoin Achieves the second, now by design.
By, by design, requring the blockchain to be periodically signed by a trusted authority... you have a weird notion of resistance to state attacks.
490  Bitcoin / Bitcoin Discussion / Re: Szabo just tweeted this on: August 21, 2015, 07:44:04 AM
That being so, would it make sense for Core to make a pre-emptive
strike by releasing a fork that switches to use another IP port
Someone would just bridge it. Switching proof of work algorithims might be much more effective and would have a potentially beneficial effect of resetting the currently highly centeralized mining climate... if one really did want to go the total war route. I don't currently believe it will be an issue.

The end result being that we would have a semi-centralized payment
network for "ordinary folks" and a plethora of more anonymous alt
Freedom that is only availble to people who dedicate their lives to it isn't really freedom. To be free you have to be free to do as you will, not forced to be nothing but a freedom fighter.

With few exceptions there has seldom in history been a kind of freedom that wasn't available to those few who really worked to achieve it at any cost. What fighting for peoples rights is fundimentally about is fighting for rights to be reconized by default or at least at a reasonable cost to people-- so that they are pratically available rather than merely theoretically available.

Only the myopic fixation on One True Coin prevents people realizing that
this is the most likely outcome for crypto in the long run.
Money gains its value from network effect. For a pure money, like Bitcoin, virtually all its value comes from network effect. Money is probably the worlds greatest natural monopoly. Oh just have seperate things is not a cheap and easy choice.
491  Bitcoin / Bitcoin Discussion / Re: Szabo just tweeted this on: August 21, 2015, 06:22:11 AM
ethereum ??!?!
Even that slopply designed mess of bugs has effective blocksize and resource usage controls. Try something more like "Liquidcoin" if you want to see what a system looks like with no thought given to the incentives and stability of the system.
492  Bitcoin / Bitcoin Discussion / Re: Szabo just tweeted this on: August 21, 2015, 06:20:10 AM
If it seems like the limit is getting hit persistently, and confirmation times are becoming a problem, an emergency limit increase is something that the core devs can patch very simply and quickly.  They can execute such an emergency block size QE if you will, at a moments notice.  They have demonstratively done this kind of deployment before, during the one previous hard fork, and with the F2Pool bug.  So what is the rush?
That's my question:
This is correct, and it was a point I made previously and was pretty agressively attacked for being "against planning" (though what I suggest is precisely the opposite: having a planned contingency that you use when you have a strong consensus that its the right choice is good planning)-- clearly people promoting this stuff with the massive uncertanty created by XT and the irritation of "stress tests" can't honestly be concerned with there being a bit of turbulance.
493  Bitcoin / Bitcoin Discussion / Re: Szabo just tweeted this on: August 21, 2015, 06:18:00 AM
Do we want it to handle all world daily transactions,
or do we want protection from current monetary systems and government involvement?
If we achieve the second, we can have both.  But if we only achieve the first, we likely cannot have the second (and wouldn't find it to be a substantial improvement over the fiat systems we have now, even if).

The reason for this is that if Bitcoin is secure and trustworthy, trustless decenteralized micropayment facilities can be built on top of it and extend Bitcoin's transaction security with arbritary speed or scale.  But if the system is fragle and underminable by attackers (government or otherwise) then it won't be robust enough to underpin these things.

(and things like micropayment channels were't my invention, they were recommended by the system's creator-- thats part of why Bitcoin has smart contracts to begin with.)
494  Bitcoin / Development & Technical Discussion / Re: Why not increase the block size limit by 1MB whenever it needs to be increased? on: August 19, 2015, 03:25:54 PM
Wouldn't doing it this way increase the block size whenever the market needs it to?

Needs to be increased is tricky. The natural and necessary state for blocks is nearly full; defining need is hard.  "Near-universally agreed to be good to increase" would be better, but people are sensibly worried that it would be held back by unreasonable people and so they are unwilling to take that risk.

Ex, when it reaches 0.5MB, raise it to 2MB. When it reaches 1.5MB, raise it to 3MB.
That sounds like something that would completely undermine the existance of transactions fees-- which are the only long term security arguement we have (what will pay for adequate POW security as the subsidy declines). It would also allow the system to slip into arbritary amounts of centeralization if those increases were really guarenteed... because it could get to a point where no one but a few api providers bothered to run nodes. Sad
495  Bitcoin / Development & Technical Discussion / Re: I suspect we need a better incentive for users to run nodes (c) on: August 18, 2015, 07:34:13 PM
Have I misrepresented? He seems to be clearly stating that distributed nodes are a small scale solution with consolidation at scale. That I find depressing and stand by what I said. If I have misinterpreted, then please correct me. The only other interpretation that I can see is he is agreeing with me, that unless clients do the block processing and miners only "generate" coins, then the result will be big server farms as we are seeing now. I think that is a rather wistful reading of the words, however.

Yes, you have, though it's not your fault.  What a client in Bitcoin is has been subverted into something that can't enforce the rules at all and is utterly dependant on trusting miners.  That was never the design of the system.
496  Bitcoin / Development & Technical Discussion / Re: I suspect we need a better incentive for users to run nodes (c) on: August 16, 2015, 01:46:57 AM
I was quite disappointed to read that Satoshi envisioned huge centralised farms and users just being users paying fees. That means the end game is a cartel of infrastructure rich companies - back to square one for the proles.
Thats a misrepresentation in any case.

That response was to specific questions about the system being able to work at all.  My understanding of it at the time was simply what it said at face value.  Proof the system can work, the users get to choose the trade-offs; which is something classical centeralized systems couldn't offer.  ::shrugs::  Keep in mind that anything written in 2009-2011 was written in a very different world, not one where people just take for granted that Bitcoin works _at all_.

It's sad that people feel the need to put words in other people's mouths in any case. The whole appeal to authority hugely undermines the principles of the system.  If you want something that lives and dies on the whim of some authority: centeralized systems can have much better performance and security properties.

The node incentives thing doesn't seem technically feasable. Or rather, the system had that built in but it was undermined by pooled mining.  We now know how to avoid any _need_ to run pooled mining now, but it's always less costly to do so (due to the costs of running a node).

SPV could work in a way that more or less obviates the need for almost anyone to run a node at all; but the existing software never implemented that-- and those working on SPV right now are okay with fairly centeralized trust models and so they seem to not care. (Or even view the low security as a virtue).
497  Bitcoin / Development & Technical Discussion / Re: How would you prove that you own >= X BTC without disclosing addresses ? (ZKP) on: August 15, 2015, 11:06:13 AM
Using an AOS ring signature only works when you know the pubkeys, which you don't for most coins in the Bitcoin UTXO set.

In any case, the ring signature used to construct the CT range proof is just the AOS scheme when not used with any AND,  so thats implement in secp256k1-zkp.

To avoid the proof size-- you're off in snark land-- e.g. the statement you prove "I know a private key for an adequate coin belonging to a utxo set with this hashroot". I previously suggested a scheme that lets you avoid doing 99% of the EC math inside a snark, so this could get a small under 400 byte proof and be implementable. I think it was in a forum post... I'll have to look. But the basic process have the snark instead prove "Pubkey P is a blinding of a pubkey that is member of this tree", and then you also prove you know P's discrete log externally to the snark. The verification of the blinding can be done with a single point addition in the prover.
498  Alternate cryptocurrencies / Altcoin Discussion / Re: [VNL] Vanillacoin, a quiet word of warning. on: August 13, 2015, 07:51:39 PM
Everyone should read this article (especially the under the hood part):

John Connor warned the BTC devs about this issue:

Who are the idiots?

I'm afraid you failed to actually understand the discussion.  First, there has been no Bitcoin hard fork; the article you're linking to is simply flat out wrong.

Secondly, John Connor didn't warn about anything there-- in fact, he copied the code he was complaining about into his own codebase, after reformatting and with incorrect attribution in violation of the very minimal software license, and then lied about the functionality being in his forware all along. (See also:

I find it remarkable that people will continue to use software written by someone who has been caught outright lying about the content of the binaries they distribute.  It reduces my faith in the potential for the success of cryptocurrency at all. What greater warning sign could you ask for?
499  Bitcoin / Bitcoin Discussion / Re: What is soft folk and hard folk? on: August 13, 2015, 05:40:54 AM
That article is unfortunately pretty misleading.  Based on the commentary on reddit I think it actively harmed some people's understanding,  you should read the responses there-- including mine.
500  Bitcoin / Development & Technical Discussion / Re: Some blocks have earlier block times than their predecessing block, how/why? on: August 11, 2015, 11:20:56 PM
Who says what the altcoins do actually works-- many have just had spontanious failures due to ill advised changes like twiddling how retargeting works... and there is no reason to expect that most have ever been analyized from an adversarial perspective (much less  actually attacked). ... but thats a question for another subforum.

As you note, it works fine in Bitcoin as is... and, in fact, requiring the time to be monotonic would open up new attacks.  If you want a monotonic time out of bitcoin you can extract one by simply running a rolling maximum over the timestamps, forcing miners to conceal more information won't help anything.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 232 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!