Re: [bitcoin-dev] A Segwit2x BIP

Well, 40 bytes reduction per input is excessive too :) But 30 bytes reduction will do fine. On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner < sergio.d.ler...@gmail.com> wrote: > Some responses.. > >> >> The proposal adds another gratuitous limit to the system: A maximum >> transaction

Re: [bitcoin-dev] A Segwit2x BIP

Some responses.. > > The proposal adds another gratuitous limit to the system: A maximum > transaction size where none existed before, yet this limit is almost > certainly too small to prevent actual DOS attacks while it is also > technically larger than any transaction that can be included today

Re: [bitcoin-dev] how to disable segwit in my build?

On Tue, Jul 11, 2017 at 11:17:24PM -0700, Dan Libby via bitcoin-dev wrote: > At this time, I would like to have some of the more recent features, but > without the possibility that my node will activate segwit, until I > choose to. I think that terminology isn't quite precise. I think your

Re: [bitcoin-dev] how to disable segwit in my build?

On Wed, Jul 12, 2017 at 6:17 AM, Dan Libby via bitcoin-dev wrote: > Hi! > > Up to now, I have purposefully been running bitcoin releases prior to > 0.13.1 as a way to avoid the (possible) segwit activation, at least > until such time as I personally am

[bitcoin-dev] Fwd: [Lightning-dev] Lightning Developers Biweekly Meeting Announce

-- Forwarded message -- From: Rusty Russell Date: Wed, Jul 12, 2017 at 6:27 PM Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce To: lightning-...@lists.linuxfoundation.org Hi all! Every two weeks we've been running an

[bitcoin-dev] how to disable segwit in my build?

Hi! Up to now, I have purposefully been running bitcoin releases prior to 0.13.1 as a way to avoid the (possible) segwit activation, at least until such time as I personally am comfortable with it. At this time, I would like to have some of the more recent features, but without the possibility

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

The confusion below stems from his conflation of several different ideas. I will try to explicitly clarify a distinction between several types of user (or, "modes" of use if you prefer): [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

In case anyone wants to do this, I added the CSidechainAddress class to the mainchainBMM branch of the Drivechain project a long time ago. The only purpose it serves right now is to show that sidechain deposit addresses can start with a '4'. We could simply add the sha256 hash described by Paul to

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

I still think it may be more inefficient, in equilibrium. (In other words, in the future steady state of Bitcoin that includes LN or something LN-like). Assume there are N sidechains. In the coinbase version: 1. There is some single event, per N, that causes nodes to notice that a new sidechain

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

On 7/12/2017 4:50 AM, ZmnSCPxj wrote: > > >>In my scheme, if you read carefully through the pseudocode, a block > list node is valid only if its block is valid. > > > >It seems this is a contradiction against the "blind" part of blind > merge mining. How can a bitcoin blockchain node enforce this

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

Paul, I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]). For reference, I said: > Isn't it different in the

Re: [bitcoin-dev] Updating the Scaling Roadmap

That's a fair point, I confused anyone-can-spend with anyone-can-pay [1]. Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script? In other words, miners don't have complete control over the coins, full nodes keep a check on them. At least that was my

Re: [bitcoin-dev] Updating the Scaling Roadmap

You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not

Re: [bitcoin-dev] Updating the Scaling Roadmap

> I think Paul has been pretty upfront about the risks of his model. I think he has been rather misleading in his presentation of the risks. He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;). >If so, please leave, you are compromising Bitcoin's security. Ok, let's calm down. >If I design a car that has a button that randomly causes the brakes to give out if

Re: [bitcoin-dev] Updating the Scaling Roadmap

Dear Chris, > I think this is an unfair characterization. You have to opt into using > drivechains. I have heard this nonsense repeated countless times in order to justify adopting Drivechain. This is not how security works. A child can "opt-in" to using a loaded gun, but is it a good idea

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently. If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Hi Russell/ZmnSCPxj, I think you guys are right. The only problem I can see with it is replaceability of the bribe transaction. If the 'Bribe' is the fee on the transaction it isn't clear to me what the best way to replace/remove it is. If we have the amount in the output (instead of the fee) we

Re: [bitcoin-dev] A Segwit2x BIP

On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: > I think anything less than 1 year after release of tested code by some > implementation would be irresponsible for any

Re: [bitcoin-dev] A Segwit2x BIP

Le 12/07/2017 à 03:06, Luke Dashjr via bitcoin-dev a écrit : > Even with Core's support, many people would oppose the hardfork > attempt, and it would fail. Why with or without Core support are you sure that it will fail, what can those that are opposing the hardfork attempt do (with or

Re: [bitcoin-dev] A Segwit2x BIP

> Code to support 2x (the hard fork part of the proposal) has been out and > tested for much longer than that. Tested? Where? However, the hardfork part may be out there for a long time but _is still broken_. /jonas signature.asc Description: Message signed with OpenPGP

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

On Wed, Jul 12, 2017 at 4:50 AM, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: In any case, let me propose actual improvements to the OP_BRIBEVERIFY > proposal: > > 1. Remove the necessity of coinbase commitments. The miner commits to > the sidechain_id and h* in the

Re: [bitcoin-dev] Updating the Scaling Roadmap

On Wednesday, 12 July 2017 03:22:59 CEST Karl Johan Alm via bitcoin-dev wrote: > Bitcoin development differs from Linux kernel development in a number > of obvious ways, such as the fact Bitcoin is being "patched in > flight". I've heard this before and it doesn't make any sense to me. Just like

Re: [bitcoin-dev] Updating the Scaling Roadmap

Just a quick note in favor of an updated roadmap (some may object to that label, but I think it's fine). When you and your friends are planning your weekly movie outing, it's very helpful to have someone who knows the group, knows what films are playing, checks people's preferences, mails around

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

>>In my scheme, if you read carefully through the pseudocode, a block list node >>is valid only if its block is valid. > >It seems this is a contradiction against the "blind" part of blind merge >mining. How can a bitcoin blockchain node enforce this without tracking the >sidechain? From:

Re: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

Good morning mailinglist, I am saddened at the lack of attention to this BIP proposal. I know that it is not as interesting as the debates on where Bitcoin will go in the future and what needs to be prepared for even greater mainstream adoption, but I think my BIP proposal does have at least