Re: [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.

On Monday 26 Sep 2016 14:41:36 Peter Todd via bitcoin-dev wrote: > Note how the OPL is significantly more restrictive than the Bitcoin Core > license; not good if we can't ship documentation with the code. Documentation and code can have different licenses, the sole existence of various

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

the UTXO 1-B double-spend. > > Luke > > On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote: > > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote: > > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the > > > Bitcoi

Re: [bitcoin-dev] BIP 2 revival and rework

On Saturday, 24 September 2016 06:36:00 CEST Luke Dashjr via bitcoin-dev wrote: > * OPL will no longer be an acceptable license. Many in the community feel > that prohibiting publication is unacceptable for BIPs, and I haven't > heard any arguments in favour of allowing it. My suggestion would

Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT

On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote: > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin > scripting system to address reissuing bitcoin transactions when the coins > they spend have been conflicted/double-spent. > >

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Friday, 23 September 2016 13:42:36 CEST Christian Decker via bitcoin-dev wrote: > > I have to disagree. That is not malleability. Creating a new document > > and re- signing it is not changing anything. Its re-creating. > > Something that the owner of the coin has every right to do. > Same

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev wrote: > Not sure if the comparison to XML and HTML holds: the lack of closing > tags makes the meaning of individual tokens ambiguous, like I pointed > out before. The use of segments gives at most two levels of

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Thursday, 22 September 2016 21:59:12 CEST Jonas Schnelli via bitcoin-dev wrote: > Hi Tom > > > I think you misunderstand tagged systems at a very basic level. You > > think that html can only use a bold tag once in a document? Thats > > equivalent to what you are saying. > > Would the

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote: > > «The way towards that flexibility is to use a generic concept made > > popular various decades ago with the XML format. The idea is that we > > give each field a name and this means that new fields can be added or > > optional

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Thursday, 22 September 2016 14:27:29 CEST Peter Todd wrote: > CSV uses per-input sequence numbers; you only have a per-tx equivalent. I think you misunderstand tagged systems at a very basic level. You think that html can only use a bold tag once in a document? Thats equivalent to what you

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Wednesday 21 Sep 2016 18:45:55 adiabat via bitcoin-dev wrote: > Hi- > > One concern is that this doesn't seem compatible with Lightning as > currently written. Most relevant is that non-cooperative channel close > transactions in Lightning use OP_CHECKSEQUENCEVERIFY, which references the >

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Wednesday 21 Sep 2016 14:00:23 Andreas Schildbach via bitcoin-dev wrote: > Just glancing over your BIP, I wonder if we should use Protobuf. It uses > this "flexible" format already and is quite compact/binary. We use > Protobuf already for the payment protocol, and there is very good tool >

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

Thanks for your email Peter! On Tuesday 20 Sep 2016 17:56:44 Peter Todd wrote: > On Tue, Sep 20, 2016 at 07:15:45PM +0200, Tom via bitcoin-dev wrote: > > === Serialization order=== > > > > The tokens defined above have to be serialized in a certain order for the >

Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

On Tuesday 20 Sep 2016 21:31:47 Luke Dashjr wrote: > On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote: > > As the title suggests, I would like to formally request the assignment of > > a > > BIP number for my FT spec. > > Please open a pull reque

[bitcoin-dev] Requesting BIP assignment; Flexible Transactions.

As the title suggests, I would like to formally request the assignment of a BIP number for my FT spec. Thank you! Source; https://github.com/zander/bips/blob/FlexTrans/bip-.mediawiki BIP: ?? Title: Flexible Transactions Author: Tom Zander Status: Draft

[bitcoin-dev] Introducing Flexible Transactions.

I've been asked one question quite regularly and recently with more force. The question is about Segregated Witness and specifically what a hard fork based version would look like. This is available online at my blog; http://zander.github.io/posts/Flexible_Transactions/ But I'll publish the

Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin

> #Basic idea: > > Ideally, all miners would begin hashing the next block at exactly the same > time. Miners with a head start are more profitable, and the techniques that > help miners receive and validate blocks quickly create centralization > pressure. > > What if there was something that

Re: [bitcoin-dev] Compact Block Relay BIP

On Monday 09 May 2016 13:40:55 Peter Todd wrote: > >> [It's a little disconcerting that you appear to be maintaining a fork > >> and are unaware of this.] > > > >ehm... > > Can you please explain why you moved the above part of gmaxwell's reply to > here, A personal attack had no place in the

Re: [bitcoin-dev] Compact Block Relay BIP

On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote: > On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev > > wrote: > > You misunderstand the networking effects. > > The fact that your node is required to choose which one to set the > > announce >

Re: [bitcoin-dev] p2p authentication and encryption BIPs

On Friday 25 Mar 2016 19:43:00 Jonas Schnelli via bitcoin-dev wrote: > An encrypted channel together with a trusted full node would finally > allow to have a secure and save SPV communication. I guess my question didn't get across. Why would you want to make your usecase do connections over the

Re: [bitcoin-dev] p2p authentication and encryption BIPs

On Thursday 24 Mar 2016 13:20:48 Chris via bitcoin-dev wrote: > As far as the use cases others mentioned, connecting and SPV wallet to > your full node is certainly one. It would make it easy to, say, connect > the android bitcoin-wallet to your own node. I've hacked on that wallet > to make it

Re: [bitcoin-dev] p2p authentication and encryption BIPs

On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > Hi > > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 I suggest running a spellchecker ;) Some questions; * why would you not allow encryption on

Re: [bitcoin-dev] BIP 2 promotion to Final

On Wednesday 16 Mar 2016 22:24:30 Luke Dashjr via bitcoin-dev wrote: > It is important that the forum for comments have a low barrier of use. The > Bitcoin Wiki requires only a request for editing privileges, whereas GitHub > wiki would require reading and agreeing to a lengthy Terms of Service