Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> On Jun 19, 2015, at 8:48 PM, Luke Dashjr wrote: > > On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote: >> They don't need to be made cryptographically safe, they just have to be >> safer than, for instance, credit card payments that can be charged back. As >> long as it's reasonably go

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

I disagree that 11 is a reasonable value. That's less than 2 hours, which probably wouldn't even last peak trading hours. You want the mempool to be big enough that low-fee transactions introduced during peak hours are still around when there's much less activity (it maximizes miner profit and prev

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote: > They don't need to be made cryptographically safe, they just have to be > safer than, for instance, credit card payments that can be charged back. As > long as it's reasonably good in practice, that's fine. They never will be. You can ge

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

It all comes down to managing risk. If you’ve got a decent risk model with capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine. But most payment processors and merchants right now probably don’t have particularly good risk models and are making many dangerous assumptio

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

On 6/19/2015 6:43 AM, Mike Hearn wrote: > No surprise, the position of Blockstream employees is that hard forks > must never happen and that everyone's ordinary transactions should go > via some new network that doesn't yet exist. If my company were working on spiffy new ideas that required a hard

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

> to avoid having an internal mapping from 9'-> 0' to find out what > blockchain to query, this sounds like it should be trivial for any wallet. Trivial to implement, a headache to *maintain* But if a new platform is released on an existing blockchain, my wallet doesn't need to know about the new

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which is what your proposed path structure would be, and it results in the address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w. When the wallet notices a transaction in the blockchain that has 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an out

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. They don't need to be made cryptographically safe, they just have to be safer than, fo

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson wrote: > I have some experience her

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

>m/##'/0'/99'/0' > >where 99 is the identifier for, say, counterparty What is stopping you from using m/44'/9'/a'/c/i as descibed here: http://doc.satoshilabs.com/slips/slip-0044.html to avoid having an internal mapping from 9'-> 0' to find out what blockchain to query, this sounds like it shoul

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

I'm not sure I understand your question about the need to store paths in the wallet database -- there's no way to infer the path of an address inside an HD wallet from the address alone (short of an exhaustive search), and HD wallets need to store either the paths, addresses, or both that have been

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

Hi Matt, I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers. I'm a little uncertain as to the relevance though. All those variables (purpose, network, asset_type, account, change, index) need to be stor

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Double spend detection is by definition best-effort. The purpose of bitcoin is to provide security (confirmations) to otherwise insecure, possibly double spent transactions. On Fri, Jun 19, 2015 at 2:05 PM, Frank Flores wrote: > Has anyone from Mycelium weighed in on this? Is their doublespe

[Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

Hey guys, The crew at Gem is considering a new HD wallet path structure for our wallets, which are coin-agnostic, that separates the coin_type field into two fields as such: m / purpose' / network' / asset_type' / account' / change / index where network refers to the blockchain (0 - bitcoin, 1 -

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Has anyone from Mycelium weighed in on this? Is their doublespend attack detection broken with this kind of irresponsible behavior? On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock wrote: > On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: > > If full-RBF sees any significant adoption by

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

On Fri, Jun 19, 2015 at 12:47 PM, Adam Weiss wrote: > Hi Warren, > > If you set dmarc_moderation_action to "Munge from", the list will detect > when someone posts from a domain that publishes a request for strict > signature checking for all mails originating from it (in DNS) and rewrite > the en

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: > If full-RBF sees any significant adoption by miners, then it will actively > harm bitcoin adoption by reducing or removing the ability for online or POS > merchants to accept bitcoin payments at all. Retail POS merchants probably should

Re: [Bitcoin-development] Remove Us Please

You're only strengthening Gigas' point about the mailing list by posting derisive emails. Take your nonconstructive comments elsewhere. - Jameson On Fri, Jun 19, 2015 at 4:01 PM, Brian Hoffman wrote: > damn he was just on the verge of solving the underlaying problem with > Bitcoin and you inter

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain. Is there a canonical implementation of FSS RBF around somewhere I can review? Best

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

Hi Warren, If you set dmarc_moderation_action to "Munge from", the list will detect when someone posts from a domain that publishes a request for strict signature checking for all mails originating from it (in DNS) and rewrite the envelope-from to the list's address. Reply-to will be added and se

Re: [Bitcoin-development] Remove Us Please

damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus. > On Jun 19, 2015, at 3:55 PM, John Bodeen wrote: > > from their website, humorous bits highlighted > > October 14, 2014 > In latest Hiatus new, the company has taken on yet another cr

Re: [Bitcoin-development] Remove Us Please

from their website, humorous bits highlighted > *October 14, 2014 *In latest Hiatus new, the company has taken on yet > another crazy project but this one is going to benefit the world in which > it entered not long ago. The company had done a lot of research on crypto > currencies, built one fo

Re: [Bitcoin-development] Remove Us Please

You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. < corpor...@gigasgaming.com> wrote: > This is no longer a mailing list, this is a chatroom. > Please remov

[Bitcoin-development] Remove Us Please

This is no longer a mailing list, this is a chatroom. Please remove this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-dev

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 17:50, Jeff Garzik wrote: > No. You cannot know which is the 'right' or wrong transaction. One tx > has > obvious nSequence adjustments, the other - the refund transaction - may > not. I'm still not seeing a case where a node could

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 10:48 AM, wrote: > On 2015-06-19 17:40, Jeff Garzik wrote: > >> Making multiple incompatible versions of a spend is a -requirement- of >> various refund contract protocols. >> > > Is there not a dedicated field in a transaction (nSequence) for express > purpose of indicati

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 17:40, Jeff Garzik wrote: > Making multiple incompatible versions of a spend is a -requirement- of > various refund contract protocols. Is there not a dedicated field in a transaction (nSequence) for express purpose of indicating when

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 9:44 AM, wrote: > If we have ECDSA proof that an entity intentionally made and publicly > announced incompatible promises regarding the disposition of particular > Bitcoins under their control, then why shouldn't that be assumed to be a > fraud attempt unless shown otherwi

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo wrote: > If we want a non-repudiation mechanism in the protocol, we should > explicitly define one rather than relying on “prima facie” assumptions. > Otherwise, I would recommend not relying on the existence of a signed > transaction as proof of int

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 16:42, Eric Lombrozo wrote: > If we want a non-repudiation mechanism in the protocol, we should > explicitly define one rather than relying on “prima facie” > assumptions. Otherwise, I would recommend not relying on the existence > of a

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote: > If we want a non-repudiation mechanism in the protocol, we should explicitly > define one rather than relying on “prima facie” assumptions. Otherwise, I > would recommend not relying on the existence of a signed transaction as proof

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

"prima facie" generally means that in a court case the burden of proof shifts from one party to another. For instance, if you have a federal trademark registration that is prima fascia evidence of those rights even though they could still be challenged. To say a prosecutor would have prima fas

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Even if you could prove "intent to pay," this would be almost useless. I can sincerely intend to do a lot of things, but this doesn't mean I'll ever actually do them. I am in favor of more zero-confirmation transactions being reversed / double-spent. Bitcoin users largely still believe that acc

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 16:36, Matt Whitlock wrote: > On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: >> I'd also like to note that "prima facie" doesn't mean "always", it >> means >> that "the default assumption, unless proven otherwise.

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… > On Jun 19, 2015, at 9:36 AM, Matt Whitlock w

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote: > > > > > So connecting to many nodes just because we can and it's not technically > > > prevented is bad for the network and creating systemic risks of failure, > > > > Well it is actually; that's why myself, Wladimir van der Laan, an

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: > I'd also like to note that "prima facie" doesn't mean "always", it means > that "the default assumption, unless proven otherwise." Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the defau

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> > > So connecting to many nodes just because we can and it's not technically > > prevented is bad for the network and creating systemic risks of failure, > > Well it is actually; that's why myself, Wladimir van der Laan, and > Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd wrote: > On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote: > > It is disappointing that F2Pool would enable full RBF when the safe > > alternative, first-seen-safe RBF, is also available, especially since the > > fees they would gain

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

>- Did you accept payment from companies to lobby for 20MB blocks? Do you consider that something appropriate to publicly disclose if so? Do you consider that user rights should come above or below company interests in Bitcoin? FWIW on pondering that last question "should user rights come abov

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 15:37, Eric Lombrozo wrote: > OK, a few things here: > > The Bitcoin network was designed (or should be designed) with the > requirement that it can withstand deliberate double-spend attacks that > can come from anywhere at any time…an

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Yes, FSS RBF is far better. On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang <1240...@gmail.com> wrote: > Before F2Pool's launch, I performed probably the only successful > bitcoin double spend in the March 2013 fork without any mining power. > [ https://bitcointalk.org/index.php?topic=152348.0 ] I kn

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd wrote: > Having said that... honestly, zeroconf is pretty broken already. Only > with pretty heroic measures like connecting to a significant fraction of > the Bitcoin network at once, as well as connecting to getblocktemplate > supporting miners to fig

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote: > > > > Unless you're sybil attacking the network and miners, consuming valuable > > resources and creating systemic risks of failure like we saw with > > Chainalysis, I don't see how you're getting "very small" double-spend > > probab

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

This is very disappointing. "scorched earth" replace-by-fee implemented first at a pool, without updating wallets and merchants, is very anti-social and increases the ability to perform Finney attacks and double-spends. The community is progressing more towards a safer replace-by-fee model, as in

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 15:11, Peter Todd wrote: > If you ask me to pay you 1BTC at address A and I create tx1 that pays > 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 > that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm no

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

OK, a few things here: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked befo

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Great. Thank you for this! Adrian On Fri, Jun 19, 2015 at 7:40 AM, Chun Wang <1240...@gmail.com> wrote: > On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil > wrote: > > However, we do rely pretty heavily on zeroconf transactions for merchant > > processing, so if any significant portion of the m

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> > Unless you're sybil attacking the network and miners, consuming valuable > resources and creating systemic risks of failure like we saw with > Chainalysis, I don't see how you're getting "very small" double-spend > probabilities. > So connecting to many nodes just because we can and it's not t

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote: > On 2015-06-19 10:39, Peter Todd wrote: > > Yesterday F2Pool, currently the largest pool with 21% of the hashing > power, enabled full replace-by-fee (RBF) support after discussions > with > me. This means t

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-19 10:39, Peter Todd wrote: Yesterday F2Pool, currently the largest pool with 21% of the hashing power, enabled full replace-by-fee (RBF) support after discussions with me. This means that transactions that F2Pool has will

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote: > > In that case would you enter into such contracts? > > > > We take it as it comes. > > Currently, it's perfectly possible to accept zeroconf transactions with > only a very small chance of double spend. As long as it's only possib

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil wrote: > However, we do rely pretty heavily on zeroconf transactions for merchant > processing, so if any significant portion of the mining pools started > running your unsafe RBF patch, then we would probably need to look into this > as a way to pr

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> > > We have no contracts in place or plans to do this that I am aware of. > > > > However, we do rely pretty heavily on zeroconf transactions for merchant > > processing, so if any significant portion of the mining pools started > > running your unsafe RBF patch, then we would probably need to lo

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Chun Wang <1240902 gmail.com> writes: > Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. FSS RBF is better than no RBF but we think it is better to use full RBF. We think Full RBF is better for a number of reasons: -user experience -efficiency -cost -code complexity We

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote: > > > > For instance, if Coinbase had > > contracts with 80% of the Bitcoin hashing power to guarantee their > > transactions would get mined, but 20% of the hashing power didn't sign > > up, then the only way to guarantee their transa

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Extremely disappointed to hear this. This change turns double spending from a calculable (and affordable) risk for merchant payment processors into certain profit for scammers, and provides no useful benefit for consumers. I sincerely hope that F2Pool reconsider, given that RBF will decrease the o

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

> > For instance, if Coinbase had > contracts with 80% of the Bitcoin hashing power to guarantee their > transactions would get mined, but 20% of the hashing power didn't sign > up, then the only way to guarantee their transactions could be for the > 80% to not build on blocks containing doublespen

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Before F2Pool's launch, I performed probably the only successful bitcoin double spend in the March 2013 fork without any mining power. [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad the full RBF is. We are going to switch to FSS RBF in a few hours. Sorry. On Fri, Jun 19, 2015

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote: > I just sent the following email to F2Pool: > > > I was disappointed to see Peter Todd claiming that you have (or will?) run > his replace-by-fee patch. > > I strongly encourage you to wait until most wallet software supports > rep

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote: > Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. No worries, let me know if you have any issues. You have my phone number. While my own preference - and a number of other devs - is full-RBF, either one is a good

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote: > It is disappointing that F2Pool would enable full RBF when the safe > alternative, first-seen-safe RBF, is also available, especially since the > fees they would gain by supporting full RBF over FSS RBF would likely be > negligible. D

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

Hi Adam, I am still confused about whether you actually support an increase in the block size limit to happen right now. As you agree that this "layer 2" you speak of doesn't exist yet, and won't within the next 10-12 months (do you agree that actually?), can you please state clearly that you will

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse wrote: > It is disappointing that F2Pool would enable full RBF when the safe > alternative, first-seen-safe RBF, is also available, especially since the > fees they would gain b

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

I just sent the following email to F2Pool: I was disappointed to see Peter Todd claiming that you have (or will?) run his replace-by-fee patch. I strongly encourage you to wait until most wallet software supports replace-by-fee before doing that, because until that happens replace-by-fee just ma

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since the fees they would gain by supporting full RBF over FSS RBF would likely be negligible. Did they consider using FSS RBF instead? Best, Stephen On Fri, Jun 19,

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

> At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook… And TCP/IP came before... oh wait... 2015-06-19 14:02 GMT+02:00 Eric Lombrozo : > > On Jun 19, 2015, at 3:45 AM, Dr Adam Back wrote: > > That wont be good for the compani

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

IPv4 came before IPv6…you pick up on things quickly :) > On Jun 19, 2015, at 5:48 AM, Marcel Jamin wrote: > > > At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! > > came before Google…MySpace came before Facebook… > > And TCP/IP came before... oh wait... > > 2015-06-1

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

>When is the right time to allow space pressure to rise that ratio? >When the subsidy is at 1.5625, for example, it may be too late to I don¹t believe we have to decide, the miners will do that and are doing that already. >start a non-catastrophic transition from subsidies to fees. >I don't clai

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

On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn wrote: > Or alternatively, fix the reasons why users would have negative >> experiences with full blocks >> > > It's impossible, Mark. *By definition* if Bitcoin does not have > sufficient capacity for everyone's transactions, some users who were using

[Bitcoin-development] Fee Market Effects

A lot of standpoints for keeping the current block size are focused on creating a healthy fee market. I have some open questions for this list in regards to the user incentives of using bitcoin, when such a strong fee market is in place. In my scenario the average fee for a normal transactions w

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

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back wrote: > > That wont be good for the companies either, but they may not see that > until they've killed it, many companies operate on a1 or 2 year > time-horizon. They may say screw layer2, I have a runway and I need > micropayments to the wazoo and I

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

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back > wrote: > > That wont be good for the companies either, but they may not see that > until they've killed it, many companies operate on a1 or 2 year > time-horizon. They may say screw layer2, I have a runway and I need > m

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

On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back wrote: > payment protocol layer in my view. (If thats not obvious to some > lurkers I elaborate on that argument amongst other things here: > https://www.youtube.com/watch?v=3dAdI3Gzodo ) > Someone might find it more convenient to consume that in t

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

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn wrote: >> Or alternatively, fix the reasons why users would have negative >> experiences with full blocks > > > It's impossible, Mark. By definition if Bitcoin does not have sufficient > capacity for everyone's transactions, some users who were using it

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

> On Jun 19, 2015, at 2:37 AM, Mike Hearn wrote: > > Or alternatively, fix the reasons why users would have negative experiences > with full blocks > > It's impossible, Mark. By definition if Bitcoin does not have sufficient > capacity for everyone's transactions, some users who were using it

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

> > Mailman isn't resigning it. Should it be? Does other mailing list > software? > Mailman must take responsibility for the mail itself. It doesn't have to actually sign with DKIM to do so: for backwards compatibility, spam filters fall back to other heuristics to try and figure out the 'owner'

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

A lot of people think a layer2 is needed, that has a higher (algorithmic) scale in use of layer1 block-space but preserves functionality and uplifts security from layer1. An example would be lightning or similar. But there are many things that could be done. Pure offchain is a weak form of layer

[Bitcoin-development] F2Pool has enabled full replace-by-fee

Yesterday F2Pool, currently the largest pool with 21% of the hashing power, enabled full replace-by-fee (RBF) support after discussions with me. This means that transactions that F2Pool has will be replaced if a conflicting transaction pays a higher fee. There are no requirements for the replacemen

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn wrote: > The new list currently has footers removed during testing. I am not >> pleased with the need to remove the subject tag and footer to be more >> compatible with DKIM users. >> > > Lists can do what are effectively MITM attacks on people's mess

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

> > The new list currently has footers removed during testing. I am not > pleased with the need to remove the subject tag and footer to be more > compatible with DKIM users. > Lists can do what are effectively MITM attacks on people's messages in any way they like, if they resign for the messages

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

> > Yeah, but increasing block-size is not a longterm solution. Are you sure? That sort of statement is hard to answer because it doesn't say what you think long term is, or how much you expect Bitcoin to grow. Satoshi thought it was a perfectly fine long term solution because he thought hardwar

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn wrote: > We already removed the footer because it was incompatible with DKIM >> signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible >> with DKIM header signing only if the poster manually prepends it in their >> subject header.

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

Benjamin, Timeframe for network congestion and users experiencing service degradation => between now and middle of next year. Timeframe for transaction fees topping block reward fees => many years in the future, based on current ratio of block reward to fees. What is the more pressing requiremen

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

> > We already removed the footer because it was incompatible with DKIM > signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible > with DKIM header signing only if the poster manually prepends it in their > subject header. > I still see footers being added to this list by Sour

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

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

[Bitcoin-development] Mailman incompatibility with DKIM ...

Both you and jgarzik experienced mail getting tossed into gmail's spam folder thanks to DKIM... I am concerned that DKIM is too fragile and not very compatible with mailing lists. We already removed the footer because it was incompatible with DKIM signing. Keeping the "[Bitcoin-dev] " prepend tag

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

> > Or alternatively, fix the reasons why users would have negative > experiences with full blocks > It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether

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

Nicely put Eric. Relatedly my initial experience with Bitcoin in trying to improve bitcoin in fungibility, privacy & decentralisation, I found some interesting things, like Confidential Transactions (that Greg Maxwell has now optimised via a new generalisation of the hash-ring signature construct