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] The Bitcoin Node Market

2015-06-15 Thread Luke Dashjr
On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote: Would SPV wallets have to pay to connect to the network too? From the user's perspective, it would be somewhat upsetting (and confusing) to see your balance slowly draining every time you open your wallet app. It would also tie up

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

2015-06-06 Thread Luke Dashjr
On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote: Current methods of proving a payment: * Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if

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

2015-06-06 Thread Luke Dashjr
On Saturday, June 06, 2015 9:25:02 PM Kalle Rosenbaum wrote: * The pop output will have value 0. Why not have it be -1 to make it completely invalid as a transaction? Luke --

Re: [Bitcoin-development] Version bits proposal

2015-05-26 Thread Luke Dashjr
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote: Feel free to comment. As the gist does not support notifying participants of new comments, I would suggest using the mailing list instead. I suggest adding a section describing how this interacts with and changes GBT. Currently, the

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Luke Dashjr
On Tuesday, May 26, 2015 4:46:22 AM Kevin Greene wrote: This is something you actually don't want. In order to make it as difficult as possible for an attacker to perform a sybil attack, you want to choose a set of peers that is as diverse, and unpredictable as possible. It doesn't hurt to

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-15 Thread Luke Dashjr
On Friday, May 15, 2015 9:54:55 AM s7r wrote: If you strip both the scriptSig of the parent and the txid, nothing can any longer be mutated but this is not safe against replays. This could work if we were using only one scriptPubKey per tx. But this is not enforced, ... Assuming you mean one

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Luke Dashjr
I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG softforking. Instead of referring to previous transactions by a normalised hash, it makes better sense to simply change the outpoints in the signed data and allow nodes to hotfix dependent transactions when/if they are

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-12 Thread Luke Dashjr
It should actually be straightforward to softfork RCLTV in as a negative CLTV. All nLockTime are = any negative number, so a negative number makes CLTV a no-op always. Therefore, it is clean to define negative numbers as relative later. It's also somewhat obvious to developers, since negative

Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size

2015-05-11 Thread Luke Dashjr
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote: 1. It will encourage centralization, because participants of mining pools will loose more money because of excessive initial block template latency, which leads to higher stale shares When a new block is solved, that information needs

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Luke Dashjr
On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote: We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet

Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-02-12 Thread Luke Dashjr
Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote: Hi all, I have drafted a BIP with Jean Pierre and Ruben after the last discussion, related to a standard for

[Bitcoin-development] [SPAM] Re: determining change addresses using the least significant digits

2015-02-05 Thread Luke Dashjr
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote: On 02/04/2015 02:23 PM, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-29 Thread Luke Dashjr
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote: I propose to allow miners to voluntarily lock funds by letting miners add additional inputs to the coinbase transaction. Currently the coinbase transaction does not allow any real input to be added (only a pseudo-input). This is

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-29 Thread Luke Dashjr
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote: How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? Pay-to-fee transactions can be stolen by another block at the same or greater height. Additional inputs to the generation transaction are

[Bitcoin-development] Serialised P2SH HD chains

2014-12-04 Thread Luke Dashjr
Is anyone working on a serialisation format to convey P2SH HD chains? For example, to give someone who wants to make recurring payments a single token that can be used to generate many P2SH addresses paying to a multisig script. I'm thinking of something along the lines of a simple series of

Re: [Bitcoin-development] Serialised P2SH HD chains

2014-12-04 Thread Luke Dashjr
On Thursday, December 04, 2014 8:02:17 PM Jeffrey Paul wrote: What is the use case for something like this? It’s my impression that a single token that can be used to obtain many P2SH addresses paying to a multisig script looks something like

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Luke Dashjr
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote: The data that can be embedded as part of an OP_RETURN output is currently limited to 40 bytes. It was initially supposed to be 80 bytes, but got reduced to 40 before the 0.9 release to err on the side of caution. After 9 months,

Re: [Bitcoin-development] Proposed BIP status changes

2014-10-16 Thread Luke Dashjr
On Thursday, October 16, 2014 6:22:04 AM Wladimir wrote: Shouldn't we be doing this in a GitHub PR rather than spamming up the ML? Not really. BIP changes should be discussed on the mailing list, that's the way to get community consensus (as specified in BIP1). Wladimir Discussion vs

Re: [Bitcoin-development] Proposed BIP status changes

2014-10-15 Thread Luke Dashjr
On Wednesday, October 15, 2014 8:47:18 AM Wladimir wrote: These BIPs should go to Final state - they are implemented all over the place, and are thus entirely fixed in place now. Any changes would require a new BIP as amandment: - BIP 14 (BIP Protocol Version and User Agent) ACK - BIP 21

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Luke Dashjr
On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote: On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote: * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that

Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-12 Thread Luke Dashjr
On Sunday, October 12, 2014 8:41:29 AM Geir Harald Hansen wrote: On 12.10.2014 01:34, Pieter Wuille wrote: * No orphan blocks stored in memory anymore (reducing memory usage during sync). Will this slow down reorgs after a fork, compared to today? It shouldn't... he's talking about actual

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-03 Thread Luke Dashjr
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote: Is there a reason why we can't have the new opcode simply replace the top stack item with the block height of the txout being redeemed? Then arbitrary logic could be implemented, including output cannot be spent until a certain time

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Luke Dashjr
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote: I've written a reference implementation and BIP draft for a new opcode, CHECKLOCKTIMEVERIFY. Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? A limitation of encoding

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-01 Thread Luke Dashjr
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote: On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr l...@dashjr.org wrote: Thoughts on some way to have the stack item be incremented by the height at which the scriptPubKey was in a block? Better to create a GET-TXIN-BLOCK-(TIME

Re: [Bitcoin-development] replace-by-fee v0.9.3 release

2014-09-28 Thread Luke Dashjr
On Sunday, September 28, 2014 5:15:53 AM Peter Todd wrote: On Sat, Sep 27, 2014 at 07:55:44PM -0700, Tom Harding wrote: On 9/25/2014 7:37 PM, Aaron Voisine wrote: Of course you wouldn't want nodes to propagate alerts without independently verifying them How would a node independently

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-23 Thread Luke Dashjr
On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote: Not to mention encrypting basically non-sensitive inter-node traffic is almost completely worthless in providing anonymity anyway... Recall that P2P connections carry Bloom filters too, which are not public information. As soon as

Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Luke Dashjr
On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote: gmaxwell noted on IRC that enabling TLS could be functionally, if not literally, a DoS on the pool servers. Hence the thought towards a more lightweight method that simply prevents client payout redirection + server impersonation. My

Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread Luke Dashjr
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote: Hi there, I was wondering if you guys have come across this article: http://www.wired.com/2014/08/isp-bitcoin-theft/ The TL;DR is that somebody is abusing the BGP protocol to be in a position where they can intercept the miner

Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread Luke Dashjr
On Friday, August 08, 2014 12:29:31 AM slush wrote: AFAIK the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... Certificate

Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Luke Dashjr
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote: Proxying another's idea, from CoinSummit. The request: It would be useful to limit the lifetime of a bitcoin address. Intentionally prevent (somehow) bitcoins being sent to a pubkey/pkh after the key expires. You could append

Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Luke Dashjr
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote: On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@dashjr.org wrote: They can already do this. It's perfectly valid for wallets/services to ignore (and not consider as payment) transactions using an address more than once. There might

Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken

2014-06-02 Thread Luke Dashjr
On Tuesday, June 03, 2014 4:29:55 AM xor wrote: Hi, I thought a lot about the worst case scenario of SHA256d being broken in a way which could be abused to A) reduce the work of mining a block by some significant amount B) reduce the work of mining a block to zero, i.e. allow instant

Re: [Bitcoin-development] DNS seeds unstable

2014-05-16 Thread Luke Dashjr
On Friday, May 16, 2014 5:17:17 PM Rob Golding wrote: dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs dnsseed.bitcoin.dashjr.org. 60 IN NS jun.dashjr.org. but jun.dashjr.org isn't responding to dns queries (as at 18.10 GMT 2014-05-16) that would be a

Re: [Bitcoin-development] DNS seeds unstable

2014-05-15 Thread Luke Dashjr
On Thursday, May 15, 2014 11:50:29 AM Andreas Schildbach wrote: dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs FWIW, this may be a routing issue: I notice various ISPs have been unable to route to my server over IPv4 today. IPv6 seems to be fine. Not sure how important DNS

Re: [Bitcoin-development] moving the default display to mbtc

2014-05-02 Thread Luke Dashjr
On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote: My only addition is that I think we should all stop trying to attach SI prefixes to the currency unit. Name me another world currency that uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at least in the

Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol

2014-04-30 Thread Luke Dashjr
On Wednesday, April 30, 2014 6:03:59 PM Tier Nolan wrote: Due to popular demand, I have created a BIP for cross chain atomic transfers. https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for these