Re: [Bitcoin-development] Block Size Increase
On Wednesday 6. May 2015 21.49.52 Peter Todd wrote: > I'm not sure if you've seen this, but a good paper on this topic was > published recently: "The Economics of Bitcoin Transaction Fees" The obvious flaw in this paper is that it talks about a block size in todays (trivial) data-flow economy and compares it with the zero-reward situation decades from now. Its comparing two things that will never exist at the same time (unless Bitcoin fails). -- Thomas Zander -- 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] Cartographer
On Monday 29. December 2014 11.30.42 Mike Hearn wrote: > With the current DNS protocol you get an all or nothing choice Its a seed. Not the protocol itself. > Firstly, Peter, get help. I'm serious. I think most would agree with me that, Mike, this answer is not just a little over the line, its unacceptable behavior in any collaborative group. Please be respectful and avoid ad-hominem attacks. -- Thomas Zander -- 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] Cartographer
On Sunday 28. December 2014 18.25.29 Mike Hearn wrote: > Lately we have been bumping up against the limitations of DNS as a protocol > for learning about the p2p network. Can you explain further where limitations and problems were hit? -- Thomas Zander -- 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] Running a full node
On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote: > Dear all, > > I'm currently discovering the Bitcoin's universe. > I installed bitcoind on my PC and I'm currently testing different things > on testnet. I just read an article saying that the risk for Bitcoin in the > future is the decreasing number of full nodes, with appropriate resources. > There are only few of them in France ! > > My company operates a dual homed Internet access and has some capacity to > host an HA server in a secured environment. So I'm thinking about setting > up a full node. But I'd like to know what storage, RAM and bandwidth > resources are needed. I guess that the problem is not the CPU. There is a stats script running on this node; http://213.165.91.169/ more peoples opinions; https://bitcointalk.org/index.php?topic=760094.0 -- Thomas Zander -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: death by halving
On Tuesday 28. October 2014 22.44.50 Ferdinando M. Ametrano wrote: > It amazes me that basic economic considerations seems completely lost here, > especially when it comes to mining. Please don't confuse people dismissing your thoughts with dismissing the basic economic considerations. The fact of the matter is that you didn't read the archives where these ideas have been brought forward and discussed, a consensus was reached. (it wasn't so basic afterall) The fact that people don't want to repeat the discussion just for your sake is not the same as people not listening to those arguments. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DS Deprecation Window
On Monday 27. October 2014 19.26.48 Tom Harding wrote: > Miner has to be very careful including a double-spend in his block -- he > hopes: How does it help the zero-confirmation to not include a payment? Doesn't that just mean that if I send a double spend that neither of the payments will be made? So the thief just got an even bigger incentive to double-spent! > - that based on his measured time offset from the first spend he > received, at most a tiny fraction of the network will delay his block > > - that not too many nodes saw an earlier spend that he didn't see, > which could increase that fraction > > - that most other nodes saw his tx. Any who didn't will only learn > about it by receiving his block, and they will assign it the time when > they receive the block. That's likely to be more than T (30 seconds) > after an earlier spend, so they would delay the block. This doesn't addresses the point that Matt brought up. Your proposal essentially has some side effects that would be disastrous to miners. As detailed by the other two replies on this thread. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] death by halving
On Saturday 25. October 2014 13.27.30 Adam Back wrote: > - alternatively you might say why not 1/100th reward reduction per 2 > week period rather than 1/2 every 4 years, a difficulty retarget could > be a convenient point to do that. mining equipment has a much shorter lifetime than 4 years, so the halving makes it easy to base purchases on. Also, divide by two is the cleanest way to get to zero after a specific amount of divisions. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] death by halving
On Saturday 25. October 2014 21.06.32 Alex Mizrahi wrote: > If miner's income margin are less than 50% (which is a healthy situation > when mining hardware is readily available), we might experience > catastrophic loss of hashpower (and, more importantly, catastrophic loss of > security) after reward halving. For the sake of argument, lets assume that somehow (quite unlikely) half the mining equipment gets shut off. The amount of hashes/second is such that it is currently, lets just say, quite secure against any takeover. Your document makes a long series of assumptions about how this can turn out bad with each individually is implausible, together are just fiction. Your research didn't convince me about this being bad somehow. It also completely disregards the equilibriums reached by doing so. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Sunday 19. October 2014 09.17.51 xor wrote: > I joined the list when Bitcoin was already in the 10-billions of market > capitalization, and it actually really surprised me how low the traffic is > here given the importance of Bitcoin. I gather that actual code changes to bitcoin-core and naturally all the other clients are already done in another place. Which is likely the reason for your impression. > So as a random stranger to the project, I would vote against that if I was > allowed to. There really should be *more* discussion here, and splitting > the list up won't help with that. I agree with your stance that more discussion in public is always good. Lets allow people that work on bitcoin java, or completely other bitcoin based stuff to have a simple way to filter out the topics they are interested in. Mailinglist handling is pretty trivial in practically all email software, people can equally trivially subscribe to multiple lists as their interests go. As a long time open source developer, my experience is that more lists has never really caused fragmentation in the way that you fear. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Wednesday 15. October 2014 20.13.11 Mike Hearn wrote: > Plus its moderation features suck, its mail archiving features suck, etc. > It essentially has no redeeming features at all. Other than it being open source, an open platform with no lock-in 'features' and it works with everyone that uses the standards properly. Naturally, if an old version fails to function with Yahoo, I'm all for finding a different provider. Thats what open platforms, like Mailman, are about. -- Thomas Zander -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Wednesday 15. October 2014 11.36.58 Wladimir wrote: > > We're also having problems with people failing to comment on things, > > not even "I looked at this and have no opinion", which is really > > obstructing things. > > Well - the only way to avoid that is to set a reasonable deadline, > after which there is a default decision. You'd hope this would > motivate people to get involved in time. I have been part of both the OSI (NEN) and the OASIS standards committees for a while, working on standards as a technical adviser. There I learned a lot about how to manage this process, maybe some ideas from such committees can be useful. The idea that one person owns a BIP makes total sense, (s)he is the only one that should be putting forward the BIP when its mature enough for making it final. Note that this can be already after its been implemented once or twice. So you have a phase where you have random people propose changes, which should all go in the public mailinglist, and they can be accepted by the owner without discussion. If anyone that sees that change has an objection to the change, (s)he speaks up and you follow group consensus. This means (and this is actually in an ISO standard ;) that consensus is reached when nobody is left objecting to the change. At some point the BIP is mature enough to vote on, at the discretion of the owner, and the owner puts it forward and requests a vote. If the above process was handled cleanly there is a very small chance of it being down-voted so an actual vote may not be needed (its hard to decide who gets a vote..). You obviously need a deadline for this and afterwards you mark the proposal final. Or you close it as "needs more work". -- Thomas Zander -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Malleable booleans
On Tuesday 14. October 2014 04.34.16 Pieter Wuille wrote: > This means that scripts that use booleans as inputs will be inherently > malleable. I've ran into this issue in C++ often enough, a funny example is assigning "2" to a native c++ bool and then you can do a if (myBool == true) else if (myBool == false) and neither of them will hit. > I > would like to change BIP62 to also state that interpreted booleans > must be of minimal encoded size (in addition to numbers). What about rejecting a script where a bool is not explicitly zero or one? -- Thomas Zander -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue
On Friday 10. October 2014 19.26.49 Mike Hearn wrote: > I'm sure this suggestion will go down like a lead balloon, but Bitcoin Core > is not the first project that's had issues with Linux distros silently > modifying their software as they package it. And so far its been near impossible for those others to make distros not modify it. Firefox is actually a good idea, it made debian stop distributing it. Best solution is to build good relations with the packagers of distros. ps. Linux distros distributing GPL licensed apps are required by law to offer the sources of the thing they build and distribute as binary. Which allows you to check the difference with upstream. Most distros therefore have a process in place for this. Even for not FLOSS software like bitcoin core. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
On Monday 15. September 2014 11.51.35 Matt Whitlock wrote: > If you were merely attaching your public key to them, then the email server > could have been systematically replacing your public key with some other > public key, The beauty of publicly archived mailinglists make it impossible to get away with this without detection. I recall reading the awesome book "The inmates are running the asylum" which states that solutions created by software engineers typically suffer from the flaw of absolutes. (find the part where he describes homo-digitalus for more) I think this applies to PGP and your objection; in order to make it absolutely correct, you need to introduce loads of things. Signatures, WoT, etc. PGP&GPG do this. But each change of the normal workflow means you loose about 50% of your audience... So, my silly example is not perfect. But I bet its good enough for most. In the end the value of the imperfect solution is higher than the perfect one. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
The reason it is in fact geek wanking is because pgp tried to solve a problem that can't be solved. It tried to provide distributed trust to a system of identity, while still depending on the local governments (i.e. centralization) for the upstream ID. Its a marriage that has no benefits. What we really want is a (decentralized) identity management that allows me to create a new anonymous ID and use that as something more secure when needed that I have to proof its me. So for instance I start including a bitcoin public key in my email signature. I don't sign the emails or anything like that, just to establish that everyone has my public key many times in their email archives. Then when I need to proof its me, I can provide a signature on the content that the requester wants me to sign. All the overhead of PGP and the WoT is really completely unneeded and just means that less people use it. Consider this; people create accounts on GitHub or Reddit and those have in fact more value than your pgp key! Because they got the anonymous part right. On Monday 15. September 2014 09.32.03 Brian Hoffman wrote: > I would agree that the in person aspect of the WoT is frustrating, but to > dismiss this as "geek wanking" is the pot calling the kettle. > > The value of in person vetting of identity is undeniable. Just because your > risk acceptance is difference doesn't make it wanking. Please go see if you > can get any kind of governmental clearance of credential without in-person > vetting. Ask them if they accept your behavioral signature. > > I know there is a lot of PGP hating these days but this comment doesn't > necessarily apply to every situation. > > On Sep 15, 2014, at 9:08 AM, Jeff Garzik wrote: > >> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander > >> wrote: Any and all PGP related howtos will tell you that you should not > >> trust or sign a formerly-untrusted PGP (or GPG for that matter) key > >> without seeing that person in real life, verifying their identity etc. > > > > Such guidelines are a perfect example of why PGP WoT is useless and > > stupid geek wanking. > > > > A person's behavioural signature is what is relevant. We know how > > Satoshi coded and wrote. It was the online Satoshi with which we > > interacted. The online Satoshi's PGP signature would be fine... > > assuming he established a pattern of use. > > > > As another example, I know the code contributions and PGP key signed > > by the online entity known as "sipa." At a bitcoin conf I met a > > person with photo id labelled "Pieter Wuille" who claimed to be sipa, > > but that could have been an actor. Absent a laborious and boring > > signed challenge process, for all we know, "sipa" is a supercomputing > > cluster of 500 gnomes. > > > > The point is, the "online entity known as Satoshi" is the relevant > > fingerprint. That is easily established without any in-person > > meetings. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?
On Sunday 14. September 2014 08.28.27 Peter Todd wrote: > Do we have any evidence Satoshi ever even had access to that key? Did he > ever use PGP at all for anything? Any and all PGP related howtos will tell you that you should not trust or sign a formerly-untrusted PGP (or GPG for that matter) key without seeing that person in real life, verifying their identity etc. I think that kind of disqualifies pgp for identity purposes wrt Satoshi :-) -- Thomas Zander -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
