Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Without commenting on your proposal at all, the general problem with licensing after the fact is you require the permission of every copyright holder in order to make the change. On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev wrote: > Hello,

Re: [bitcoin-dev] push tx fuzzing

On 2015-09-01 15:50, Kristov Atlas via bitcoin-dev wrote: I am interested in finding or writing a fuzzer for push tx APIs. I did not find one after a brief search. Has anyone found otherwise, or is she in the process of writing one? https://github.com/jonasnick/bitcoinconsensus_testcases

Re: [bitcoin-dev] push tx fuzzing

Interesting project, Kristov. Two more ideas for fuzzing bitcoin txs: - random bit flipping from valid txs - random tx script generators: - from a grammar - from a stochastic grammar - from a random sequence of opcodes I've made some really small experiments on fuzzing in the past [1][2],

Re: [bitcoin-dev] AT has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Another note on this subject to add to the stuff people have already mentioned... If you have the AT landline but don't use AT's standard internet / tv (what they call Uverse) offering - that is, if you prefer to use some local internet provider -

Re: [bitcoin-dev] Short review of previously-proposed exotic SIGHASH types

On Sun, Aug 30, 2015 at 01:56:34PM -0500, Bryan Bishop via bitcoin-dev wrote: > Here is a short review of previously-proposed and exotic SIGHASH types. > > SIGHASH_MULTIPLE > Similarly, petertodd has asked for a SIGHASH_DONT_SIGN_TXID before to > make OP_CODESEPARATOR more useful. There's also

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

I would just like to labour the point that users pay to use the network, but they have no defined rights, anywhere. That is an interesting point. That is a feature of Bitcoin, not a bug. If the user did have rights to sue someone then the system would not be decentralized. User rights =

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

The only reason someone would want to make a license is so they can sue/threaten people for not following the license rules. At best this is pointless since Bitcoin cannot be controlled, and at worst it will result in a group of people using coercion against the community to gain profits.

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

Isn't this all backward? The "authority" component of the URL should identify the chain, and the "path" component should identify the particular block, tx, or address in that chain. So instead of:

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

To avoid repetition, we have actually covered the general points and questions you have raised in the draft BIP, which includes a draft licence to assist discussions: https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing Regards, Ahmed On Tue, Sep 1, 2015 at 11:02 PM,

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Den 2 sep 2015 00:03 skrev "Btc Drak via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > > I think it gets worse. Who are the copyright owners (if this actually > applies). You've got people publishing transaction messages, you've > got miners reproducing them and publishing blocks. Who

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

I have read the proposal. I think you missed my point: every existing transaction author would be required to agree to your proposals for them to be legal, and that's clearly impossible. You'd also need every single miner who published a block. You're much better taking the line that actually, the

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Sun, Aug 30, 2015 at 3:20 AM, Jorge Timón wrote: >> Some altcoins (LTC and FTC for example) have the same genesis block hash. > > That's obviously a design mistake in FTC, but it's not unsolvable. FTC could > move their genesis block to the next block (or

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Wed, Sep 2, 2015 at 12:56 AM, Btc Drak wrote: > When I brought up the issue originally, I deliberately steered away > from altchains choosing to focus on networks like mainnet, testnet > because I think it's easier to repurpose a protocol for an altcoin > than it is to make

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

This is good feedback. Thank you. Very briefly: > "To put a license on something you have to own it in the first place." ## The block chain is a database. There are laws to protect databases. We have suggested who might be best placed to be assigned rights to the block chain and more importantly

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Tue, Sep 1, 2015 at 4:49 PM, Marco Pontello wrote: > > On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón > wrote: >> >> >> I would really prefer chain= over network= >> By chainID I mean the hash of the genesis block, see >> >>

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

Oh, my bad! Right, sounds pretty good to me then. On Tue, Sep 1, 2015 at 11:42 PM, Matt Whitlock wrote: > The authority part in a URI is optional. > > > blockchain:/tx/ca26cedeb9cbc94e030891578e0d2b688a28902114f6ad2f24ecd3918f76c17f > > Notice the lack of a double-slash.

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

On Tue, Sep 01, 2015 at 02:30:17PM +0100, Ahmed Zsales via bitcoin-dev wrote: > Hello, > > We believe the network requires a block chain licence to supplement the > existing MIT Licence which we believe only covers the core reference client > software. As long as it's an open system, one can't

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Tue, Sep 1, 2015 at 5:12 PM, Danny Thorpe via bitcoin-dev wrote: > Rather than using an inhumanly long hex string from the genesis hash to > distinguish between mainnet and testnet, why not use the network magic bytes > instead? Much shorter, just as

Re: [bitcoin-dev] Your Gmaxwell exchange

On 2015-09-01 18:37, Eric Voskuil wrote: Whether intended or otherwise this is an attack on the idea of decentralized bitcoin development. The option to fork or roll your own is open source, not decentralization. Decentralization requires *actually doing so*. One step down that path, even for a

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Russ, The general points and questions you have raised are covered in the draft BIP: https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing Regards, Ahmed On Tue, Sep 1, 2015 at 10:36 PM, Milly Bitcoin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >

Re: [bitcoin-dev] Your Gmaxwell exchange

On Mon, Aug 31, 2015 at 01:55:43PM -0500, Justus Ranvier via bitcoin-dev wrote: > * They should own their bitcoins, meaning that they retain exclusive > control over their balances. Even more precisely, the network must > always honour the conditions of the scripts associated with unspent

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

I see your point. But I personally like that the chain part could be optional, given that the vast majority of the references in the end will be to Bitcoin main net. On Tue, Sep 1, 2015 at 11:16 PM, Matt Whitlock wrote: > Isn't this all backward? The "authority"

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 That would be very wrong and cause a lot of problems and 'political chaos' without solving at least one (technical) problem in exchange. Bitcoin Core is a good quality code. It is open source and free. Anyone can contribute and submit small

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

The general points and questions you have raised are covered in the draft BIP: No, the BIP makes some weird statements that don't really make sense. Number one rule here: To put a license on something you have to own it in the first place. Let's say for the sake of argument that Miners own

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

I think it gets worse. Who are the copyright owners (if this actually applies). You've got people publishing transaction messages, you've got miners reproducing them and publishing blocks. Who are all the parties involved? Then to take pedantry to the next level, does a miner have permission to

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

My paper did show that the advantage decreased with the block reward. However, in that limit, it also seemed to imply that a network state would appear where the revenue per unit hash decreased with increasing hashrate which should be impossible as just discussed. In a followup email, I showed

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

On Sun, Aug 30, 2015 at 10:01:00PM +0200, Daniele Pinna via bitcoin-dev wrote: > Since my longer post seems to be caught in moderator purgatory I will > rehash its results into this much smaller message. I apologize for the > spamming. > > I present a theorem whose thesis is obvious to many. > >

Re: [bitcoin-dev] Your Gmaxwell exchange

On Aug 31, 2015 3:01 PM, "Justus Ranvier via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > You keep using the word "decentralized" without explaining (and most > likely, understanding) what it means. I believe he explained very well what he meant by decentralized, please stop

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

I think the "Kill King Bitcoin - Long Live the King" call is somewhat inevitable, and we should expect this to happen from time-to-time, now that the cat is out of the bag. However, I fully agree with Adam that livenet is probably not the place to play this game, and I'm also not convinced that

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

On 2015-09-01 10:16, Chris D'Costa via bitcoin-dev wrote: However, I fully agree with Adam that livenet is probably not the place to play this game, and I'm also not convinced that testnet is either.  I often wondered if there is any appetite for a no-holds-barred, anything goes, bitcoin fork

Re: [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes

On Tue, Sep 1, 2015 at 4:16 AM, Peter R via bitcoin-dev wrote: > I agree, s7r, that Bitcoin Core represents the most stable code base. To What about the people that like stability, that appreciate bitcoin as a "digital gold", and like all this 'excitement'

Re: [bitcoin-dev] Your Gmaxwell exchange

On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote: I'd be interested to know about these supposed btcd mainnet forks that have occurred due to a consensus failure since it came out of alpha. I'll go ahead and save you some research time - there hasn't been one. I'm not claiming there will

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

That surely make sense. A URI like that perfectly readable, unambiguous and simple enough. And nice to see a Wallet developer showing interest for this! :) On Sat, Aug 29, 2015 at 8:07 PM, Andreas Schildbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 08/29/2015 06:31

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Sat, Aug 29, 2015 at 10:10 PM, Jorge Timón < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I would really prefer chain= over network= > By chainID I mean the hash of the genesis block, see > > https://github.com/jtimon/bitcoin/commit/3191d5e8e75687a27cf466b7a4c70bdc04809d39 > I'm

Re: [bitcoin-dev] RFC - BIP: URI scheme for Blockchain exploration

On Sat, Aug 29, 2015 at 9:28 PM, Richard Moore wrote: > Yes! Good point, network should be encoded. Not sure I like this format > yet, but what if it was part of the authority, like block:testnet. Like > http uses port 80 by default, you could have block by default refer to >

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Thank you. We hadn't seen that before. It is an interesting discussion. We did think about including some references to protections for private keys while they remained in your control and you could prove as much. In theory it should be no different to dropping money on the floor. The money

Re: [bitcoin-dev] AT has effectively banned Bitcoin nodes by closing port 8333 via a hidden firewall in the cable box

Keep in mind... Legal or Not, many ISPs (Comcast for example) prohibit offering up network services (which a full node would supply) from your residence. I checked AT's TOS and they have a carve-out on equipment that is scary http://www.att.com/legal/terms.internetAttTermsOfService.html

[bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

Hello, We believe the network requires a block chain licence to supplement the existing MIT Licence which we believe only covers the core reference client software. Replacing or amending the existing MIT Licence is beyond the scope of this draft BIP. Rationale and details of our draft BIP for

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

On Tue, Sep 1, 2015 at 8:30 AM, Ahmed Zsales via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > We believe the network requires a block chain licence Here is a previous discussion of this topic (2012): https://bitcointalk.org/index.php?topic=117663.0 - Bryan http://heybryan.org/

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

We believe the network requires a block chain licence to supplement the existing MIT Licence which we believe only covers the core reference client software. I suggest talking to a lawyer first. To have a license you need an entity that holds the license. What entity actually holds the MIT

Re: [bitcoin-dev] Your Gmaxwell exchange

On 2015-08-31 23:32, Peter R wrote: On 2015-08-31, at 2:24 PM, Allen Piscitello via bitcoin-dev wrote: It is my opinion, then, that we should support multiple implementations of the Bitcoin protocol, working to reduce the network's dependency on Core.