Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Benjamin
Yeah, but increasing block-size is not a longterm solution. Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a m

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Benjamin
"And I never had a problem with Bitcoin-XT while it was just a patch-set with no consensus changes. But a controversial hard fork of the chain is something else completely." How is that different? The only difference is in who makes the fork and if that group has a chance of actually splitting/ove

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

2015-06-16 Thread Benjamin
"And it allows the minority to hold the majority hostage" The Bitcoin protocol has no definitions about developer consensus . The reference to FOSS is quite arbitrary. The alternative of lobbying companies is equally indeterminate and arbitrary. One of the core problem is that you can't poll users

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-14 Thread Benjamin
"The size limit is an economic policy lever that needs to be transitioned -away- from software and software developers, to the free market." Exactly right. Bitcoin does not have a free market for fee though, and literally all the discussion so far has neglected some fundamental aspect of this, as

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Benjamin
This is a misguided idea, to say the least. If such a mechanism of of user input would be possible, one would use it for transaction verification in the first place. In proof-of-stake outcomes are determined by vote by stake (that vote has very different characteristics than vote by compute power).

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread Benjamin
ing his own transaction that sends it to an > address he controls. It would be irrational to include somebody else's > transaction which spent it. > > If by block 999,900, the transaction hasn't been completed (due to not > enough pledgers), the pledgers can spend th

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread Benjamin
Interesting. 1. How do you know who was first? If one node can figure out where more transactions happen he can gain an advantage by being closer to him. Mining would not be fair. 2. "A merchant wants to cause block number 1 million to effectively have a minting fee of 50BTC." - why should he do

Re: [Bitcoin-development] Bitcoin Cooperative Proof-of-Stake whitpaper

2014-05-21 Thread Benjamin Cordes
I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system. More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will *never* change th

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Benjamin Cordes
luke, you might enjoy the book Topos of Music. It's a complete mathematical music theory by a student of Grothendieck. He advanced Euler's theories of harmony based on advanced category theory. I'm sure there are many applications to Bitcoin. On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr wrote: > On Tu

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-31 Thread Benjamin Cordes
Interesting. I think the original BitDNS discussion was more interesting that what currently is happening with namecoin, see https://bitcointalk.org/index.php?topic=1790.0 Satoshi said there: "1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved,

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-21 Thread Benjamin Cordes
I believe a better solution would to use a github clone such as gitlab, which sits on top of the git repo, and allows for custom code around the BIP process. Potentially one could even build Bitcoin into such a BIP system. If somebody wants to support a BIP he donates Bitcoins to that proposal. Som

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-21 Thread Benjamin Cordes
I believe a better solution would to use a gitlab clone such as gitlab, which sits on top of the git repo, and allows for custom code around the BIP process. Potentially one could even build Bitcoin into such a BIP system. If somebody wants to support a BIP he donates Bitcoins to that proposal. Som

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Benjamin Lindner
On Mar 13, 2013, at 8:18 PM, Cameron Garnham wrote: > For me, everyone signed up to bitcoin thinking that there was a 1MB / > block limit. The lock limits were unexpected, and could be considered > extremely uncontroversial to remove. This. Software behavior which is not described by the source

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Benjamin Lindner
On Mar 11, 2013, at 12:54 PM, Mike Hearn wrote: > With regards to trying to minimize the size of the UTXO set, this > again feels like a solution in search of a problem. Even with SD > abusing micropayments as messages, it's only a few hundred megabytes > today. That fits in RAM, let alone disk.