[Bitcoin-development] Membership disabled due to bounces

Hi all, I got a message saying that my membership in the list was disabled due to excessive bounces. As far as I can remember, I've only ever sent out one e-mail on the list (not including this one) and that was a few weeks ago. Has anyone else seen this problem? Could this be related in some w

[Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

Hi all, When a transaction with N_LOCKTIME>0 is created, does that transaction get stored in a block on the blockchain or is it stored in the mempool until the actual time (or block number) exceeds the current value? If it is stored on the blockchain, how does that affect the concept of pruning t

[Bitcoin-development] Fwd: Re: [RFC] Canonical input and output ordering in transactions

-- Forwarded message -- From: "Jorge Timón" Date: Jun 17, 2015 6:59 PM Subject: Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions To: "Rusty Russell" Cc: On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell wrote: > Jorge Timón writes: >> On Jun 15,

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

> On Jun 20, 2015, at 11:45 PM, Jeff Garzik wrote: > > On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo > wrote: > but we NEED to be applying some kind of pressure on the merchant end to > upgrade their stuff to be more resilient > > Can you be specific? What preci

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

> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo wrote: > > >> On Jun 20, 2015, at 11:45 PM, Jeff Garzik > > wrote: >> >> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo > > wrote: >> but we NEED to be applying some kind of pressure on the me

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

Eric, BitPay clearly do understand the risks of 0-conf. In case you were not aware BitPay does not particularly "accept zero confirm transactions". When a payment is seen on the network the payment screen reports the invoice has been paid, but that's front-end user facing. On the back end it's mar

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

Hi I don't think that a transaction with nLockTime>0 will be accepted by nodes / relayed in the Bitcoin network, until its time expires (e.g. nLockTime==now). This means it obviously cannot be stored in a block, before its locktime expires. nLockTime is designed in a way that you, need to keep it

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

> On Jun 21, 2015, at 1:41 AM, Btc Drak wrote: > > Eric, > > BitPay clearly do understand the risks of 0-conf. In case you were not aware > BitPay does not particularly "accept zero confirm transactions". When a > payment is seen on the network the payment screen reports the invoice has > be

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

On Sun, Jun 21, 2015 at 12:08 AM, Tier Nolan wrote: > The off by 1 bug could be fixed by a soft fork. Since the point is to show > how a non-controversial hard fork works, it doesn't matter much. You mean the timewarp fix can be coded as a softfork instead of a hardfork? How so? If that's the ca

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

On Sun, Jun 21, 2015 at 11:31 AM, Jorge Timón wrote: > You mean the timewarp fix can be coded as a softfork instead of a > hardfork? How so? > The easiest would be a rule requiring that all blocks are within 1 day of the median of the previous 11 blocks. At the moment, you need to be greater th

Re: [Bitcoin-development] Membership disabled due to bounces

I too got this message and had to re-enable my membership on the list. There's no reason why messages sent by the list to my address would be bouncing. On Sunday, 21 June 2015, at 9:06 am, Braun Brelin wrote: > Hi all, > > I got a message saying that my membership in the list was disabled due t

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

So, basically it sounds as though the wallet generating the transaction is what is responsible for holding on to the transaction and then only releasing it to the network when the NLOCKTIME value is less than or equal to the current time. Does that sound right? Braun On Sun, Jun 21, 2015 at 10:

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

Hi, Well, depends on your model and what you want to achieve. That would depend on each wallet, I couldn't confirm nor deny that this is or isn't true. You have to check with your wallet how it handles transactions with nLockTime. Maybe you are the one who generates the nLockTime transaction, but

Re: [Bitcoin-development] confirm 1e595b258d48a8badd07523cbd8a8d74c150803c

I just got this mail ... unclear how mail with my gmail account would be causing bounces with this list. On Sat, Jun 20, 2015 at 8:56 PM, < bitcoin-development-requ...@lists.sourceforge.net> wrote: > Your membership in the mailing list Bitcoin-development has been > disabled due to excessive boun

Re: [Bitcoin-development] BIP for Proof of Payment

Hi Greg! After a lot of constructive discussion, feedback and updating, I'm requesting that you please assign these proposals BIP numbers. It's both the "Proof of Payment" proposal and the "Proof of Payment URI scheme" proposal that I'm referring to. The wikimedia source is available here: https:

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

On 06/19/2015 07:48 AM, Brooks Boyd wrote: > Has there been any talk about reducing the time between blocks? If > blocks were allowed to come twice as fast, they would be able to clear > pending transactions in the mempool the same as if the block size > doubled, but would allow mining to stay more

Re: [Bitcoin-development] Membership disabled due to bounces

I got ~500 uncaught bounce notifications, so it seems like something broke. On Jun 21, 2015, at 11:00 AM, Matt Whitlock wrote: > I too got this message and had to re-enable my membership on the list. > There's no reason why messages sent by the list to my address would be > bouncing. > > > O

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

Yes, that is correct. The network will not relay until locktime reaches "maturity", i.e. it can be confirmed into a block. The wallet holds onto the transaction -- or simply does not generate -- until it can be confirmed. On Sun, Jun 21, 2015 at 5:11 AM, Braun Brelin wrote: > So, basically it

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

We should use relay and default tx selection rules to raise the cost of double spend attacks as far as it is easy and practical to do so. This increases the value of the bitcoin network by making it practical to use in more situations for more people. Merchants of course can't rely on them being cr

Re: [Bitcoin-development] Membership disabled due to bounces

I set that password back in 2013 ... shortly after a fun debate that was largely responsible for my decision to fix up Litecoin. Thanks Gavin! On Sun, Jun 21, 2015 at 2:59 AM, Warren Togami Jr. wrote: > I just got this mail ... unclear how mail with my gmail account would be > causing bounces w

Re: [Bitcoin-development] Membership disabled due to bounces

Was literally *everyone* unsubscribed? Sigh. As much as this is good reason to move the list ASAP, we need both the LF sysadmin and an existing SF list admin to be online simultaneously to effect an orderly transition. We have a scheduled time for this on Tuesday at 8pm UTC. I can ask if they a

Re: [Bitcoin-development] Membership disabled due to bounces

I also received this message and re-enabled membership. On Jun 21, 2015 4:06 AM, "Matt Whitlock" wrote: > I too got this message and had to re-enable my membership on the list. > There's no reason why messages sent by the list to my address would be > bouncing. > > > On Sunday, 21 June 2015, at 9

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

On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo wrote: > Thanks for asking *the* question, Jeff. We often get caught up in these > philosophical debates…but at the end of the day we need something concrete. > > Even more important than the specific software you’re using is the > security policy.

[Bitcoin-development] Emergency List Move: Sunday, June 21st, 2015 at 9pm UTC

Given the Sourceforge list server exploded and unsubscribed the majority of the old list, we decided to move forward with the planned list move in roughly 50 minutes from now. 9pm UTC or 2pm PDT this list will be permanently shut down with auto-reject on all posts. https://lists.linuxfoundation.o