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

2015-06-19 Thread Frank Flores
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 b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote: If full-RBF sees any

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

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 12:47 PM, Adam Weiss a...@signal11.com 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

Re: [Bitcoin-development] Remove Us Please

2015-06-19 Thread Jameson Lopp
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 brianchoff...@gmail.com wrote: damn he was just on the verge of solving the underlaying problem with

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

2015-06-19 Thread Jeffrey Paul
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?

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

2015-06-19 Thread Matt Whitlock
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

2015-06-19 Thread Brian Hoffman
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 john-bod...@uiowa.edu wrote: from their website, humorous bits highlighted October 14, 2014 In latest Hiatus new, the company has taken

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

2015-06-19 Thread Matt Smith
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

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

2015-06-19 Thread Aaron Voisine
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,

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

2015-06-19 Thread Luke Dashjr
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 get

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

2015-06-19 Thread Mark Friedenbach
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 andr...@petersson.at wrote: I have

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

2015-06-19 Thread Eric Lombrozo
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

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

2015-06-19 Thread Andreas Petersson
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

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

2015-06-19 Thread Andreas Petersson
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 should

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

2015-06-19 Thread Matt @ Envrin Group
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

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

2015-06-19 Thread Tom Harding
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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Eric Lombrozo
I don’t think the issue is between larger blocks on the one hand and things like lightning on the other - these two ideas are quite orthogonal. Larger blocks aren’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and

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

2015-06-19 Thread Peter Todd
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

2015-06-19 Thread Peter Todd
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

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

2015-06-19 Thread Chun Wang
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] Mailman incompatibility with DKIM ...

2015-06-19 Thread Warren Togami Jr.
On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn m...@plan99.net 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

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

2015-06-19 Thread Mike Hearn
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 hardware

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

2015-06-19 Thread Adrian Macneil
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 doublespends by

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

2015-06-19 Thread Peter Todd
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. Did

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

2015-06-19 Thread Mike Hearn
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

2015-06-19 Thread Adrian Macneil
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

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

2015-06-19 Thread Chun Wang
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse stephencalebmo...@gmail.com wrote: It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since

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

2015-06-19 Thread Stephen Morse
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

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

2015-06-19 Thread Peter Todd
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 transactions

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

2015-06-19 Thread Lawrence Nahum
Chun Wang 1240902 at 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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Eric Lombrozo
IPv4 came before IPv6…you pick up on things quickly :) On Jun 19, 2015, at 5:48 AM, Marcel Jamin mar...@jamin.net 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...

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

2015-06-19 Thread Dr Adam Back
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

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

2015-06-19 Thread Bryan Bishop
On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back a...@cypherspace.org 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

[Bitcoin-development] Fee Market Effects

2015-06-19 Thread Tim Witters
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

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

2015-06-19 Thread GC
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 claim

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

2015-06-19 Thread Warren Togami Jr.
On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn m...@plan99.net 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

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

2015-06-19 Thread Eric Lombrozo
On Jun 19, 2015, at 2:37 AM, Mike Hearn m...@plan99.net 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

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

2015-06-19 Thread Eric Lombrozo
On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org mailto:a...@cypherspace.org 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

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

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

2015-06-19 Thread GC
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 requirement

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

2015-06-19 Thread Peter Todd
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

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

2015-06-19 Thread Jorge Timón
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net 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

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

2015-06-19 Thread Brooks Boyd
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net 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

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

2015-06-19 Thread Mike Hearn
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' of

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

2015-06-19 Thread Warren Togami Jr.
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

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

2015-06-19 Thread Dr Adam Back
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

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

2015-06-19 Thread Mike Hearn
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

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

2015-06-19 Thread Mike Hearn
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

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

2015-06-19 Thread Mike Hearn
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] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Chun Wang
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com 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

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

2015-06-19 Thread justusranvier
-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 not

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

2015-06-19 Thread Jeff Garzik
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 know

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

2015-06-19 Thread Eric Lombrozo
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

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

2015-06-19 Thread Peter Todd
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 that

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

2015-06-19 Thread Adrian Macneil
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

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

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org 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

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

2015-06-19 Thread justusranvier
-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

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

2015-06-19 Thread Peter Todd
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 possible to

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

2015-06-19 Thread Adrian Macneil
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 adr...@coinbase.com wrote: However, we do rely pretty heavily on zeroconf transactions for merchant processing, so if any significant

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

2015-06-19 Thread Jeff Garzik
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

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

2015-06-19 Thread Adrian Macneil
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 look into

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

2015-06-19 Thread Peter Todd
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 by

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

2015-06-19 Thread justusranvier
-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. Why

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

2015-06-19 Thread Milly Bitcoin
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

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

2015-06-19 Thread Matt Whitlock
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 default?

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

2015-06-19 Thread justusranvier
-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

2015-06-19 Thread justusranvier
-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…and

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

2015-06-19 Thread Peter Todd
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, and Gregory

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

2015-06-19 Thread Peter Todd
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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Milly Bitcoin
- 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 above

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

2015-06-19 Thread Adrian Macneil
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

2015-06-19 Thread Eric Lombrozo
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

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

2015-06-19 Thread Matt Whitlock
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

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

2015-06-19 Thread Tier Nolan
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo elombr...@gmail.com 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

[Bitcoin-development] Remove Us Please

2015-06-19 Thread Gigas Gaming Inc.
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 -- ___

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

2015-06-19 Thread justusranvier
-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

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net 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

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

2015-06-19 Thread Jeff Garzik
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net 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

Re: [Bitcoin-development] Remove Us Please

2015-06-19 Thread John Bodeen
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 for

Re: [Bitcoin-development] Remove Us Please

2015-06-19 Thread Jameson Lopp
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 remove