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 get a decent rate of success merely by making one transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg, 1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason unconfirmed transactions aren't double spent today is because nobody is seriously *trying*. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
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 outputs every time you open up your wallet. You may go to pay for something in a coffee shop, only to find that you can't spend your bitcoin because the wallet had to create a transaction to pay to sync with the network. Also, users of centralized wallet services like Coinbase would not have to pay that fee; but users of native wallets like breadwallet would have no such option. This incentivizes users to use centralized wallets. So this is kind of imposing a worse user experience on users who want to use bitcoin the right way. That doesn't seem like a good thing to me :/ SPV isn't the right way either ;) If you're running a full node (the real right way), you should be able to earn more bitcoins than you pay out. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
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 designed so. It's also not secure, since the signed messages only prove ownership of the address associated with the private key, and does not prove ownership of UTXOs currently redeemable with the private key, nor prove past UTXOs spent were approved by the owner of the address. A proof of payment for a transaction T, here called PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. This appears to be incompatible with CoinJoin at least. Maybe there's some clean way to avoid that by using https://github.com/Blockstream/contracthashtool ? It has the exact same structure as a bitcoin transaction with the same inputs and outputs as T and in the same order as in T. There is also one OP_RETURN output inserted at index 0, here called the pop output. I also agree with Pieter, that this should *not* be so cleanly compatible with Bitcoin transactions. If you wish to share code, perhaps using an invalid opcode rather than OP_RETURN would be appropriate. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bits proposal
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 client tells the server what the highest block version it supports is, and the server indicates a block version to use in its template, as well as optional instructions for the client to forcefully use this version despite its own maximum version number. Making the version a bitfield contradicts the increment-only assumption of this design, and since GBT clients are not aware of overall network consensus state, reused bits can easily become confused. I suggest, therefore, that GBT clients should indicate (instead of a maximum supported version number) a list of softforks by identifier keyword, and the GBT server respond with a template indicating: - An object of softfork keywords to bit values, that the server will accept. - The version number, as presently conveyed, indicating the preferred softfork flags. Does this sound reasonable, and/or am I missing anything else? Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
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 have a local node or two, though. Might as well to improve propagation, while maintaining the other peers to avoid sybil attacks. Luke -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
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 output per scriptPubKey (and not limiting tx to one output), the alternative is essentially undefined, and creates real problems for Bitcoin today. It's not something we should go out of the way to support or encourage. Therefore, regardless of whatever other options are available, I would like to see a scriptPubKey-only sighash type for strong safety within all malleability situations (including CoinJoin and other sender-respends) that more advanced wallet software could take advantage of in the future (while strictly enforcing no-reuse on its own wallet to avoid known replays). Luke -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
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 malleated. Furthermore, the approach of using a hash of scriptPubKey in the input rather than an outpoint also solves dependencies in the face of intentional malleability (respending with a higher fee, or CoinJoin, for a few examples). These aren't barriers to making the proposal or being assigned a BIP number if you want to go forward with that, but you may wish to reconsider spending time on it. Luke On Wednesday, May 13, 2015 12:48:04 PM Christian Decker wrote: Hi All, I'd like to propose a BIP to normalize transaction IDs in order to address transaction malleability and facilitate higher level protocols. The normalized transaction ID is an alias used in parallel to the current (legacy) transaction IDs to address outputs in transactions. It is calculated by removing (zeroing) the scriptSig before computing the hash, which ensures that only data whose integrity is also guaranteed by the signatures influences the hash. Thus if anything causes the normalized ID to change it automatically invalidates the signature. When validating a client supporting this BIP would use both the normalized tx ID as well as the legacy tx ID when validating transactions. The detailed writeup can be found here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. @gmaxwell: I'd like to request a BIP number, unless there is something really wrong with the proposal. In addition to being a simple alternative that solves transaction malleability it also hugely simplifies higher level protocols. We can now use template transactions upon which sequences of transactions can be built before signing them. I hesitated quite a while to propose it since it does require a hardfork (old clients would not find the prevTx identified by the normalized transaction ID and deem the spending transaction invalid), but it seems that hardforks are no longer the dreaded boogeyman nobody talks about. I left out the details of how the hardfork is to be done, as it does not really matter and we may have a good mechanism to apply a bunch of hardforks concurrently in the future. I'm sure it'll take time to implement and upgrade, but I think it would be a nice addition to the functionality and would solve a long standing problem :-) Please let me know what you think, the proposal is definitely not set in stone at this point and I'm sure we can improve it further. Regards, Christian -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?
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 numbers often imply an offset (eg, negative list indices in Python). Luke -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
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 to propagate throughout the Bitcoin network up to the mining pool operator nodes, then a new block header candidate is created, and this header must be propagated to all the mining pool users, ether by a push or a pull model. Generally the mining server pushes new work units to the individual miners. If done other way around, the server would need to handle a high load of continuous work requests that would be difficult to distinguish from a DDoS attack. So if the server pushes new block header candidates to clients, then the problem boils down to increasing bandwidth of the servers to achieve a tenfold increase in work distribution. Or distributing the servers geographically to achieve a lower latency. Propagating blocks does not require additional CPU resources, so mining pools administrators would need to increase moderately their investment in the server infrastructure to achieve lower latency and higher bandwidth, but I guess the investment would be low. 1. Latency is what matters here, not bandwidth so much. And latency reduction is either expensive or impossible. 2. Mining pools are mostly run at a loss (with exception to only the most centralised pools), and have nothing to invest in increasing infrastructure. 3, It will reduce the security of the network The security of the network is based on two facts: A- The miners are incentivized to extend the best chain B- The probability of a reversal based on a long block competition decreases as more confirmation blocks are appended. C- Renting or buying hardware to perform a 51% attack is costly. A still holds. B holds for the same amount of confirmation blocks, so 6 confirmation blocks in a 10-minute block-chain is approximately equivalent to 6 confirmation blocks in a 1-minute block-chain. Only C changes, as renting the hashing power for 6 minutes is ten times less expensive as renting it for 1 hour. However, there is no shop where one can find 51% of the hashing power to rent right now, nor probably will ever be if Bitcoin succeeds. Last, you can still have a 1 hour confirmation (60 1-minute blocks) if you wish for high-valued payments, so the security decreases only if participant wish to decrease it. You're overlooking at least: 1. The real network has to suffer wasted work as a result of the stale blocks, while an attacker does not. If 20% of blocks are stale, the attacker only needs 40% of the legitimate hashrate to achieve 50%-in-practice. 2. Since blocks are individually weaker, it becomes cheaper to DoS nodes with invalid blocks. (not sure if this is a real concern, but it ought to be considered and addressed) 4. Reducing the block propagation time on the average case is good, but what happen in the worse case? Most methods proposed to reduce the block propagation delay do it only on the average case. Any kind of block compression relies on both parties sharing some previous information. In the worse case it's true that a miner can create and try to broadcast a block that takes too much time to verify or bandwidth to transmit. This is currently true on the Bitcoin network. Nevertheless there is no such incentive for miners, since they will be shooting on their own foots. Peter Todd has argued that the best strategy for miners is actually to reach 51% of the network, but not more. In other words, to exclude the slowest 49% percent. But this strategy of creating bloated blocks is too risky in practice, and surely doomed to fail, as network conditions dynamically change. Also it would be perceived as an attack to the network, and the miner (if it is a public mining pool) would be probably blacklisted. One can probably overcome changing network conditions merely by trying to reach 75% and exclude the slowest 25%. Also, there is no way to identify or blacklist miners. 5. Thousands of SPV wallets running in mobile devices would need to be upgraded (thanks Mike). That depends on the current upgrade rate for SPV wallets like Bitcoin Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we develop the source code for the change now and apply the change in Q2 2016, then most of the nodes will already be upgraded by when the hardfork takes place. Also a public notice telling people to upgrade in web pages, bitcointalk, SPV wallets warnings, coindesk, one year in advance will give plenty of time to SPV wallet users to upgrade. I agree this shouldn't be a real concern. SPV wallets are also more likely and less risky (globally) to be auto-updated. 6. If there are 10x more blocks, then there are 10x more block headers, and that increases the amount of bandwidth SPV wallets
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
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 and RPC server. You can describe 'A' from a group of A, B, C, D, E as the group minus B, C, D, E, sure - but I don't see how this is relevant? UTXO storage is indeed consensus critical, as you say, but it is a lot simpler to get right than the rest combined. Thus, the end goal is to have a libbitcoinconsensus with the rest, and a (as of yet named) libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally, software should use the latter when it is available, but if there is a strong reason to change UTXO storage, one can remain mostly-safe with just the former. I'm not sure why this topic is of relevance, though... Luke -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
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 deriving a canonical pay-to-script-hash address given a set of public keys and the number of signatures required. There have been two or three discussions about it on the mailing list to date, and various services already carry out this process. I hope a BIP to describe this process will allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. BIP: XX Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft Type: Standards Track Created: 8 February 2015 ==Abstract== This BIP describes a method to deterministically generate multi-signature transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. ==Motivation== Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016. Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses. While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this. Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider. ==Implementation== For a set of public keys, ensure that they have been received in compressed form, sort them lexicographically according to their binary representation before using the resulting list of keys in a standard multisig redeem script. Hash the redeem script according to BIP-0016 to get the P2SH address. ==Compatibility== * Uncompressed keys are incompatible with this specificiation. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. * P2SH addressses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. * Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== The required number of signatures in each case is 2. Vector 1 * List ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f * Sorted ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 * Script ** 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102f f12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae * Address ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z Vector 2 (Already sorted, no action required) * List: **
[Bitcoin-development] [SPAM] Re: determining change addresses using the least significant digits
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 calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Another possible approach is to randomize the number of change outputs from transaction to transaction. Doing this, it would be possible to make change outputs that mimic real spends (low number of s.d.) This uses more data. Why not just round change down (effectively rounding fee up)? Luke -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
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 something I've wanted since 2011, but hasn't been a priority. Because sometime in the future (maybe 5-10 years) we may have to deal with problems of securing the blockchain, as the subsidy is lowered. We don't want the number of confirmation blocks to be increased in compensation because Bitcoin won't be able to compete with other payment networks. Then by having this hardfork now, we will be able to soft-fork later to any rule we may came come up with involving deposit bonds, proof-of-stake, and the penalization of double-mining (mining two blocks at the same height) to prevent short-range attacks. I'm not sure this increases the priority of it. If someone feels it's worth the time, I'd suggest coding up a branch that hardforks it in at some far-off block height. Even if it doesn't get merged right away, at least the code will be available for testing and ready to go when/if that time comes. Luke -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP: Voluntary deposit bonds
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 tied to that block alone. Luke -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Serialised P2SH HD chains
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 tokens, each indicating either a HD chain or literal script content. For all HD chains in the data, a child key would be generated based on the payment number, and all tokens concatenated to form the P2SH serialised script. Eg, for a simple 2- of-2, you would do something like this: literal(OP_2) HDChain HDChain literal(OP_2 OP_CHECKMULTISIG) Does this sufficiently cover all reasonable use cases? Luke -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Serialised P2SH HD chains
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 bitcoin:?r=https://payee.com/customer12345/recurring/paymentrequest/new This requires the payee operate a server. My use case is for payment to individuals, who may or may not have a computer powered at the time of the transactions being sent. Furthermore, the users I am targeting (miners, to be specific), wish to remain entirely anonymous, and not hold accounts of any sort. The model that you describe where a payer can, without communication with the payee, generate additional multisig p2sh addresses based on a set of xpubs presumes that the payee would never want to e.g. cycle their own keys or change their cooperating multisig participants’ keys. Is this wise? This depends on the framework. As of present day, miners are limited to only use a single address ever, and cannot change it even to avoid address reuse. One goal is to solve that, without breaking multisig. Luke -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP status changes
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 simple ACKing. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed BIP status changes
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 (URI Scheme) ACK - BIP 22 (getblocktemplate - Fundamentals) ACK - BIP 31 (Pong Message) ACK - BIP 34 (Block v2, Height in coinbase) ACK - BIP 35 (mempool message) ACK - BIP 37 (Bloom filtering) Let me know if you (don't) agree. Shouldn't we be doing this in a GitHub PR rather than spamming up the ML? Luke -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
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 your address is associated with a gmail account. Quite frustrating. Mailman is good enough... I used these guys for awhile to host a small mailman list with absolutely no issues. Just $5/month for 1000 subscribers. https://www.mailmanlist.net/ I've been using http://lists.nongnu.org/ for BFGMiner announce/dev mailing lists for a while. I don't know what software it runs, but it works. Catch is that we'd need to go through Savannah's free software auditing. That might be a good idea anyway? Luke -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core
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 orphan blocks (ones without a known previous/parent block), not stale blocks. Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
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 and also output can ONLY be spent until a certain time, as well as complex logic with alternative key groups with differing time constraints. This cannot be done in a softfork. Furthermore, output can ONLY be spent until a certain time contradict's Bitcoin's present security assumptions: that assuming a honest sender, the transaction will remain valid and simply re-confirm if a reorg kicks it out. Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
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 the target height/time directly, is that miners may choose not to mine the first transaction until they can also take the burn to fee. So, one may prefer to say cannot be spent until 100 blocks after the first transaction is mined, in effect reproducing the generation maturity rule. I propose any stack item under 0x4 be incremented by the height at which the scriptPubKey was mined for comparison. Maybe there is a use case for doing something similar for time too? Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
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/HEIGHT)-EQUALVERIFY operator. scriptPubKey would be: GET-TXIN-BLOCKHEIGHT-EQUALVERIFY (fails unless top stack item is equal to the txin block height) delta height ADD (top stack item is now txin height + delta height) CHECKLOCKTIMEVERIFY This sounds do-able, although it doesn't address using timestamps. A limitation of encoding the target height/time directly, is that miners may choose not to mine the first transaction until they can also take the burn to fee. So, one may prefer to say cannot be spent until 100 blocks after the first transaction is mined, in effect reproducing the generation maturity rule. You'd want these sacrifices to unlock years into the future to thoroughly exceed any reasonable business cycle; that's so far into the future that miners are almost certain to just mine them and collect the fees. For many use cases, short maturity periods are just as appropriate IMO. Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.9.3 release
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 verify a double-spend alert, other than by having access to an actual signed double-spend? #4570 relays the first double-spend AS an alert. Running this branch on mainnet, I have been keeping a live list of relayed double-spend transactions at http://respends.thinlink.com Speaking of, I ported my replace-by-fee branch the recent v0.9.3 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3 I actually ported it a few days ago; that release has been running on a half-dozen or so nodes right now for a few days with no issues. The v0.9.3 release's scriptSig size limit increase adds a new category of double-spending exploit. I'm not going to get time to add that exploit to my replace-by-fee toolkit(1) for at least another week or so though - pull-reqs accepted. 1) https://github.com/petertodd/replace-by-fee-tools Do you have or can you provide a version compatible with CPFP, such that a child paying a higher fee trumps the parent's replacement? Preferably something that will merge cleanly into 0.9.x-ljr :) Luke -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
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 you tell it to an unknown/public peer, it is public information. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
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 thought for GBT2 a while ago was to use simple ECDSA signatures for messages. It'd be nice to use the same as Bitcoin, but then we'd hit problems with RedHat/Fedora legal being stupid. :( Luke -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
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 traffic. The concerning point is that they seem to be having some degree of success in their endeavour and earning profits from it. I do not understand the impact of this (I don't know much about BGP, the mining protocol nor anything else, really), but I thought it might be worth putting it up here. This is old news; both BFGMiner and Eloipool were hardened against it a long time ago (although no Bitcoin pools have deployed it so far). I'm not aware of any actual case of it being used against Bitcoin, though - the target has always been scamcoins. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
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 validation isn't needed unless the attacker can do a direct MITM at connection time, which is a lot harder to maintain than injecting a client.reconnect. This, combined with your concern about up to date certs/revokes/etc, is why BFGMiner defaults to TLS without cert checking for stratum. Luke -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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 don't [permit|confirm] after X [time|block] to the address I suppose. The metadata would not be digitally signed, but it would be hash-sealed. As address is a client-side notion, wallet clients would be the ones enforcing such a rule. I agree this would be useful for the permit case, but not the confirm case - it's important that transactions valid in block X also be equally valid in block X+1 to avoid reorg issues. Bitcoin protocol of course knows about keys, and key expiration is a well known and useful concept in public key cryptography. The best insertion point in the protocol for key expiration is an open question, if it's even a good idea at that level at all. Some flag no more TxOuts exactly like this [after X block?]? This would force every wallet to keep an index of all TXOs ever. I readily admit I don't have good answers, but it does seem valuable IMO to * Prevent users from accidentally sending to an expired TxOut/pkh. This happens in the field. * Discourage address reuse Actually, I think this may make address reuse easier, as with base58 adding data will make it impossible to tell at a glance when someone is reusing a key with just a different expiration... I suppose something other than base58 *could* be used to resolve this, however. * Enable sites that generate lots of keys to rotate ancient keys off their core systems. (HD wallets mitigate this) 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 be race attacks if this is implemented in an immediate fashon (attacker transaction gets mined first to kill a payment), but should be pretty safe after a few blocks. Luke -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
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 be race attacks if this is implemented in an immediate fashon (attacker transaction gets mined first to kill a payment), but should be pretty safe after a few blocks. Sure it's valid. However, few users will appreciate you ignored my deposit as a feature. Payment protocol just doesn't well the use cases of, * an on-going payment stream from, e.g. Eligius to coinbase https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format * deposit addresses and deposit situations There's no reason deposits cannot use a unique payment request or address every time... -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken
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 mining. C) fabricate past blocks entirely. If SHA256d is broken, Bitcoin as it is fails entirely. Luke -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DNS seeds unstable
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 seed reliability is anyway; it's just bootstrapping, and there are multiple servers listed. Luke -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
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 US is currency-symbolamountmodifier, i.e. $63k or $3M. That may not be accepted form everywhere, but in any case it's an informal format, not a formal one. The important point is there should be one base unit that is not modified with SI prefixes. And I think the arguments are strong for that unit being = 100 satoshi. Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M' *are* the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one to admit SI is terrible, but I don't understand your argument here. Luke P.S. Note that SI units haven't actually ever been adopted, except by force of law. Name me ... that uses SI is a silly thing to say, since virtually all naturally-or-freely-adopted units of any measure have been based on a number that factor to twos and threes (not fives, like decimal). -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
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 transactions? TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both parties. After TX0 is signed, but before TX2 is signed, either party could walk away or otherwise hold the funds hostage. The sequence of signing proposed in this BIP is *not possible to perform*. How did you implement and test this? :/ What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use... IMO, there should be separate BIPs for the exchange itself, and the protocol to negotiate the exchange. I would recommend changing the latter from JSON-RPC to some extension of the Payment Protocol, if possible. Perhaps it would be good to only support compressed keys, to discourage use of uncompressed ones.. Luke -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
