[Bitcoin-development] GBT 2.0 wishlist
Let's try to get GBT 2.0 off the ground finally.. :) Here's some wishlist items/ideas: - Extremely low bandwidth use (binary protocol, with compression support) - UDP-based transport protocol? (so message order need not be preserved at the expense of latency) - Ability to instruct miners to insert (username,hash-of-username,hash-of- options-array,hash-of-both,etc) in coinbase at a given position (this enables cheaper proof-of-work auditing of a pool's rewards; it can just save/publish shares meeting higher targets and anyone can verify the shares were found by a given username/hash) - Always encrypted (once by the server), with optional authentication via CA/namecoin/URI - Incrementing precommit id so miners can precommit to settings without needing a new/custom coinbase - Multiple clients should share bandwidth on a LAN (similar to slush's stratum proxy) - Convey prevblock as block header so we can follow blockchains securely. - Fee logic: pools can claim as much coinbase distribution as they require (with hint from miner); miners are expected to ensure subsidy + transaction fees tally up to the required total; any fees beyond requires total may be distributed as the miner wishes. Potentially, pools could allow 50% (or similar) participation allowing a miner to use multiple pools at the same time. Rather than polluting the main development mailing list with what is sure to have quite a bit of discussion, I have asked kinlo (who hosts the poolowners mailing list) to provide a dedicated list for this purpose. Interested parties should please subscribe via http://list.pfoe.be/mailman/listinfo/gbt2 and send replies to g...@list.pfoe.be (once a draft BIP is ready, the main dev mailing list will be once again CC'd). 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] BIP - Hash Locked Transaction
This one looks entirely useless (it cannot be made secure), and the assertion that it is necessary for atomic cross-chain transfers seems unfounded and probably wrong... Luke On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote: As part of the atomic cross chain system, outputs need to be hash locked. https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 A user needs to provide x corresponding to hash(x) in order to spend an output. Under the protocol, one of the participants is required to provide the secret number in order to spend an output. Once they do that, the other participant can use the secret number to spend an output on the other chain. This provides a mechanism to link the 2 chains together (in addition to lock times). Once the first output is spent, that commits the transfer. This is half of the scripting operations required to implement the protocol. The proposal is to make this an adder on to the other standard transactions. It does a check that the hash matches, and then runs the standard transaction as normal. Adding the prefix to a P2SH transactions wouldn't work, since the template wouldn't match. A script of this form could be embedded into a P2SH output. I think that is ok, since embedding the password in the hashed script gets all the benefits. If there is agreement, I can code up the reference implementation as a PR. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
I believe you meant to link here instead? https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki This looks reasonable from a brief skim over, but does not define any use cases (it mentions necessary for atomic cross chain transfers, but does not explain how it is useful for that - perhaps that belongs in another BIP you haven't written yet, though). IMO, it should also require P2SH. Luke On Friday, April 25, 2014 6:49:35 PM Tier Nolan wrote: This is a BIP to allow the spender to choose one of multiple standard scripts to use for spending the output. https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki This is required as part of the atomic cross chain transfer protocol. It is required so that outputs can be retrieved, if the process ends before being committed. https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 The script allows multiple standard scripts to be included in the scriptPubKey. When redeeming the script the spender indicates which of the standard scripts to use. Only one standard script is actually executed, so the only cost is the extra storage required. A more ambitious change would be a soft fork like P2SH, except the spender is allowed to select from multiple hashes. Effectively, it would be Multi-P2SH. This gets much of the benefits of MAST, but it requires a formal soft fork to implement. If there is agreement, I can code up the reference implementation as a PR. The multi-P2SH might actually be easier. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote: I don't think the cross chain system needs a BIP (except to justify this one). If cross chain transfer become popular, then it would be useful to ensure that clients are interoperable, but first things first. If the transactions aren't accepted in any chains, then everything stalls. I think you may be misunderstanding what BIPs are. They do not force nodes to take on any given relay/mining policy (thus, BIPs should never talk about IsStandard at all). They define standard for interoperability between software. So, if you want nodes to relay these transactions, you need to convince them, not merely write a BIP for the transaction format. Defining a BIP for cross-chain trading would be one way to do that. Secure transfers require that the malleability issue is fixed, but that is a separate issue. I am assuming that will be fixed at some point in the future, since micro-payment channels also requires that it is fixed. The malleability issue has been known for years. I wouldn't expect any special effort made to fix it... A soft fork that expands P2SH functionality would be even better, but I would rather not let the best be the enemy of the good. There is some ongoing discussion of a softfork to basically redo the Script language entirely, but it will take quite a bit of time and development before we'll see it in the wild. Luke P.S. Did the BIP editor assign these numbers? If not, best to keep them numberless until assigned, to avoid confusion when people Google the real BIP 44 and 45... -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote: On 04/23/2014 09:00 PM, Tier Nolan wrote: The point is to have a single system that is compatible over a large number of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of restrictions and rules on top of BIP32. There will always be some special usecases where BIP64 is not a good fit and there's no reason why you cannot use BIP32 in a different manner using a different purpose field. Examples: Electrum does not want to use accounts and they start to use scheme m/65'/change/address (where change = 0 or 1). Or Andreas Schildbach wants to have refunds chain so he uses m/66'/chain/address (where chain = 0, 1 or 2). We wanted to find one good solution that fits all, but unfortunately it turned out everyone wants something a little bit different. Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, then it can just use account 0 for everything. Refund chains are definitely a third case that should be added to the external and internal/change address division... and a wallet not implementing refund addresses would simply not use that chain. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote: On 04/23/2014 09:44 PM, Luke-Jr wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, then it can just use account 0 for everything. Refund chains are As Andreas wrote earlier in this thread: There is no bare minimum. Either you implement the BIP fully or not. What you suggest does not follow the principle of least surprise. Suppose user imports his BIP64 compatible wallet into Electrum, which claims it is BIP64 compatible, but actually implements just a subset of the spec (sticking account index to 0). The user now sees just a fraction of his coins and is puzzled. Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 7:57:46 PM slush wrote: On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. Wallet don't see UTXO until it scans all branches/accounts on HD node import. Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address or any other details of how they were received. This is a bit idealistic. The wallet has to know how it got the UTXO in order to be able to spend it. No it doesn't... Just the assigned scriptPubKey and secret(s) required to satisfy it. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote: On 04/23/2014 10:01 PM, Luke-Jr wrote: Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. So you suggest to scan for accounts, show balances but don't allow user to spend them? Does not seem right to me. Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you must define some more detailed wallet file format (which could be built on top of this). On Wednesday, April 23, 2014 8:04:35 PM you wrote: On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: The wallet has to know how it got the UTXO in order to be able to spend it. No it doesn't... Just the assigned scriptPubKey and secret(s) required to satisfy it. To know the secret it needs to know which key coordinate to use that is logically the same as knowing the address it used to receive it. Sure, it *knows* what address was used to receive it. But at the point it's a UTXO, that address is no longer relevant. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote: On 04/23/2014 10:09 PM, Luke-Jr wrote: Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you must define some more detailed wallet file format (which could be built on top of this). I think one of the following is happening: a) you have not read the document b) you don't understand what accounts are, because you have not read the document c) you don't understand how restoring accounts work, because you have not read the document d) you don't understand that accounts funds are not meant to be mixed together, because you have not read the document e) I got your emails wrong because I am not a native speaker, but please read the the document ;-) You missed one: f) I missed the part where BIP 32 redefined account to mean subwallet instead of what has traditionally been called account in Bitcoin. :) In that case, single-subwallet wallet software probably needs to have the user provide a subwallet number in addition to the seed. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote: On 04/23/2014 10:32 PM, Luke-Jr wrote: f) I missed the part where BIP 32 redefined account to mean subwallet instead of what has traditionally been called account in Bitcoin. Ah, okay. The last time I saw Bitcoin-qt it was still using independent addresses. It is. Accounts have been a bitcoind feature since before 0.4. In that case, single-subwallet wallet software probably needs to have the user provide a subwallet number in addition to the seed. Which brings us back to my original complaint that the user can be confused because he doesn't see all his funds. I don't see how. The user knows he has money in different subwallets. As long as he has a way to specify which subwallet he is accessing in single-subwallet clients, there shouldn't be a problem. Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote: On 04/23/2014 10:41 PM, Luke-Jr wrote: I don't see how. The user knows he has money in different subwallets. As long as he has a way to specify which subwallet he is accessing in single-subwallet clients, there shouldn't be a problem. Right. But these clients have no right to call themselves BIP64 compatible then. Then BIP 64 is pretty restrictive. Most end users really have no need for subwallet support. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New BIP32 structure
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote: On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :) That is a subjective matter. To me it makes PERFECT SENSE that funds across accounts NEVER MIX. One can still send funds from one account to another and then perform another spend. Only by crossing the blockchain unnecessarily. That's what I consider a consistent and thus GOOD user experience. What's the purpose of Accounts if wallet mixes coins among them anyway? To keep balances separated. For example, I might have an account for each of my children, move their allowance money to it every day/week (off-chain), and they can spend only what they have in their account. Or an exchange might have an account for each user's deposits. In neither case, would it make sense to pay special attention to which UTXOs are consumed in transactions from any of the account. The only use case that requires tracking UTXOs per-account is when you want to have multiple uncoordinated copies of the wallet in use at the same time, and therefore need to immediately identify which account a transaction came from based on the UTXOs it consumed - although even then, you could still mix funds as long as you use only the first UTXO for tracking, so maybe there isn't even a niche use case! In any case, Trezor, being a hardware wallet, should never overlap with this niche...? I know it's not good to use classic bank accounts as analogy, but that's exactly how they work. Or have you every done ONE transaction from two bank accounts simultaneously? Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use exactly the specific dollar bills you deposited, do you?? Luke -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Ubuntu LTS Packaging?
On Saturday, April 12, 2014 2:26:07 PM Oliver Egginger wrote: Hello, so far, nothing yet? See: https://launchpad.net/~bitcoin/ I'm developing currently a LiveCD for hot/cold wallet management on Ubuntu LTS basis. For critical vulnerabilities I have to provide timely updates. I have now decided to maintain my own repository for this project. If there are better alternatives, let me know. This mailing list is for development, not support. The PPA you linked has 0.9.0, which is the latest relevant version for packaging. Luke -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! I cleaned it up a bit. By 2214, we should be using tonal numbers after all: https://gist.github.com/luke-jr/9920788 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Finite monetary supply for Bitcoin
Please, *music* is obsolete, but inline replies *are not*! On Tuesday, April 01, 2014 7:16:42 PM Benjamin Cordes wrote: luke, you might enjoy the book Topos of Music. It's a complete mathematical music theory by a student of Grothendieck. He advanced Euler's theories of harmony based on advanced category theory. I'm sure there are many applications to Bitcoin. On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored. The text can be found here: https://gist.github.com/sipa/9920696 Please comment! I cleaned it up a bit. By 2214, we should be using tonal numbers after all: https://gist.github.com/luke-jr/9920788 - - ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Saturday, March 22, 2014 8:47:02 AM Peter Todd wrote: To make a long story short, it was soon suggested that Bitcoin Core be forked - the software, not the protocol - and miners encouraged to support it. There's been at least one public miner-oriented fork of Bitcoin Core since 0.7 or earlier. Miners still running vanilla Bitcoin Core are neglecting their duty to the community. That being said, the more forks, the better for decentralisation. 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/13534_NeoTech ___ 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 Thursday, March 13, 2014 4:37:02 PM slush wrote: Display based on locale. Please don't bring locale into this. Bitcoin has always been intentionally locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales which swap the commas and periods). Localising display makes different locales more or less incompatible at a human level, even if they use the same blockchain. 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/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote: How can we patch this issue? No need, it is not an issue for Bitcoin. Properly used, there is only ever one signature per public key. Luke -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Procedure for non-tech contributions
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote: Peter writes: MtGox does host the bitcoin wiki, so yes, the funds probably do go to a wallet held by MtGox in some fashion. The foolishness of sending a payment to a Mt. Gox-held wallet -- which is required to edit the wiki -- strikes me as a pressing issue. If I understand it correctly, this is a hard blocker that'll stop *all* new contributors. Further, I registered for the wiki and never got my confirmation email. Methinks the whole thing is broken. :( We've been working on moving the wiki to new hosting, but it isn't a very high priority (at least for MtGox). PM SomeoneWeird on IRC, as he is currently handling manually approving new accounts for editing. Luke -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New to this list
On Monday, March 03, 2014 3:34:27 AM Kevin wrote: Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? Unit tests. This will be valuable to the projects and also help you learn how things work. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote: Regarding 80 bytes vs smaller: The objectives should be that if you are determined to put some extra data in the blockchain, OP_RETURN should be the superior alternative. if a user can include more data with less fees using a multisig TX, then this will happen. eventually dust-limit rules will not be the deciding factor here, since i suspect block propagation times will have a stronger effect on effective fees. therefore a slightly larger payload than the biggest multisig TX is the right answer. - that would be = 64x3 bytes = 192 bytes. (this is my understanding of how large a 3-of-3 multisig tx can be, plus 1.5 bits encoded in the n parameter) Perhaps I ought to redo my data carrier configuration option as a max size? Luke -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote: On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very insecure to have consensus depend on data (scriptSigs) which are not hashed in the Merkle structure of a block. Not that anyone on this list has suggested such a change, but I've seen it raised multiple times on the forum This would be a problem if it was used in the merkle tree, but I'm pretty sure using it for input selection would be pretty safe. One could even avoid the index by simply using the hashScript as the sole input value; then even CoinJoins would be safe without breaking chains of transactions (although this would break address reuse entirely - but I don't see that as a problem in a theoretical world). One of those things that an altcoin could improve upon Bitcoin with... ;) -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Embedded consensus system upgrade procedures
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: We have an embedded consensus system and we want to be able to upgrade it with new rules. This asserts a central authority and gives developers too much power. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote: The proposed document is here: https://gist.github.com/sipa/8907691 Rule 3 4 are already enforced. AFAIK nVersion==3 transactions are not currently considered non-standard? Luke -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
On Monday, January 20, 2014 5:42:37 PM slush wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. How are they compatible if they could be using entirely different word lists?? Because we're quickly moving towards release of Trezor firmware and we need to finalize this part of the firmware, we're asking for the last comments to current BIP39 draft. Maybe I'm missing something, but shouldn't this be a client-side thing, not implemented in the Trezor firmware at all?? O.o;; Luke -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote: vendor hat: on BitPay sure would like to see CPFP in upstream. I think the main hurdle to merging was that various people disagreed on various edge case handling and implementation details, but no fundamental objections. Heck, even I disagree with implementation details, but it's still better than nothing. We can always merge major reorganisations/reimplementations later when they're written: merging this one doesn't mean we're stuck with it forever... Luke -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
On Thursday, January 16, 2014 9:09:52 AM Wladimir wrote: Hello all, It has been way to long since last major release. Many improvements and new features have been added to master since, so we'd like to do a 0.9rc1 release soon. The current aim is next month, February 2014. Of course there are still some open issues that need to be resolved before release https://github.com/bitcoin/bitcoin/issues?milestone=12state=open If there is something else that you're working on and needs to end up in 0.9, or know of some nasty bug in master that should absolutely be solved first, please tell. Wladimir https://github.com/bitcoin/bitcoin/pulls/luke-jr These are pretty much all well-tested and stable for months now. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
On Friday, January 17, 2014 2:39:31 AM Christophe Biocca wrote: To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-larg e-miners-running-child-pays-for-parent-patch Right now if you were to try it likely wouldn't result in inclusion. But this is on the radar, and I suspect it'll eventually get merged into mainline. If you did it and relayed directly to Eligius, it'd probably get mined.. the hard part is creating the transaction - once that's done it's smooth sailing ;) Side note: mining nodes should *not* be running mainline. In fact, they should be setting up their own customised transaction policies. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker can 51% attack your altcoin at negligible cost by re-using existing hashing power. I strongly disagree on this isolated point. Using the same logic, Bitcoin is vulnerable to an attacker at negligible cost by re-using existing hashing power from mining Namecoin. Any non-scam altcoin is pretty safe using merged mining, since any would-be attacker is going to have it in their interests to invest in the altcoin instead of attacking it. It's only the scam ones that want to pump dump with no improvements, that are really at risk here. The rational decision for a non-scam altcoin, is to take advantage of merged mining to get as much security as possible. There are also some possible tricks to get the full security of the bitcoin miners even when not all participate in your altcoin (but this area probably needs some studying to get right). You assume the value of a crypto-currency is equal to all miners, it's not. Suppose I create a merge-mined Zerocoin implementation with a 1:1 BTC/ZTC exchange rate enforced by the software. You can't argue this is a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the only thing you can do with the coin is get some privacy. But inevitably some miners won't agree that enabling better privacy is a good thing, or their local governments won't. Either way, they can attack the Zerocoin merge-mined chain with a marginal cost of nearly zero. Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the worst they could do is not-participate by mining empty blocks. OTOH if the Zerocoin scheme was implemented by embedding ZTC transactions within standard Bitcoin transactions - even without any attempt at hiding them - the attackers would need a 50% majority of hashing power to succeed. Of course potentially slow confirmations is a trade-off, but that's likely a perfectly OK trade-off in this case. Potentially slow confirmation is also the only shortcoming of using Bitcoin's proof-of-work directly. Luke -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space
On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker can 51% attack your altcoin at negligible cost by re-using existing hashing power. I strongly disagree on this isolated point. Using the same logic, Bitcoin is vulnerable to an attacker at negligible cost by re-using existing hashing power from mining Namecoin. Any non-scam altcoin is pretty safe using merged mining, since any would-be attacker is going to have it in their interests to invest in the altcoin instead of attacking it. It's only the scam ones that want to pump dump with no improvements, that are really at risk here. The rational decision for a non-scam altcoin, is to take advantage of merged mining to get as much security as possible. There are also some possible tricks to get the full security of the bitcoin miners even when not all participate in your altcoin (but this area probably needs some studying to get right). Luke -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
On Tuesday, December 17, 2013 10:41:30 PM Troy Benjegerdes wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other crypto-currencies? Let's suppose that me and my friends get 'islanded' from the rest of the internet for a week, but we still want to trade bitcoin. It would work if there are local miners, until we reconnect. Suppose we have the main chain (Alice), while bob is on a boat, trading with some friends, but has no network connectivity. When bob reconnects with Alice, a 'Merge' transaction happens where a miner looks at bob's forked blockchain, sees no double-spends, and includes BOTH chains. Now suppose someone on bob's boat has a buggy client, or sent a transaction before disconnect that results in a double-spend on the merge. So we have a merge conflict, which generally requires human interaction, so bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, AND incentivize a miner to do some extra work to merge. Thoughts everyone? This is interesting, but I'm not sure it has the right incentives. First, it adds more reason for miners to *avoid* including transactions (they might turn out to be double-spends and make merging costly). Second, it gives people reason to double-spend (the miner might cover the cost of it). Finally, you don't appear to address how to deal with the subsidy - do both miners get it? Luke -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sunday, December 08, 2013 8:51:07 PM Drak wrote: Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Can someone explain how Sirius has proven the least bit untrustworthy? Luke -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote: 1) Who pays for it? Most obvious answer: Foundation. However there's currently a fairly clear line between the foundation website and the bitcoin.org http://bitcoin.org website. I personally am fine with the bitcoin foundation funding the website, it's a lot closer to the bitcoin community than github. But some people might care. So next step would be to contact the Foundation board and see if they're willing to fund it. Actually I might find way to fund it. But I needed to have ACK comments from developers before anything. ... 4) Who admins it? Obviously, I thought it would be important that the server is owned by someone who can be trusted, with ssh access for all core developers. 5) Who controls DNS for it? I'm not sure we'll get any change on this level. I have no idea if the domain is in good hands, except for the fact that nothing bad happened thus far. If anything, moving it to core developers (as intended when the domain was registered) would make more sense IMO. But again, is it possible, I don't know. I don't think core developers should be directly in control here any more than the Foundation should. Developers are good for development, not necessarily web or server admin tasks. Only those directly involved in the needed roles should have access IMO. Luke -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Move authorative source for BIPs to git repository
On Thursday, December 05, 2013 1:37:10 PM Wladimir wrote: Hello all, A while ago after discussion on the mailing list a repository was set up to store the BIP documents, as this is deemed a more secure solution than having them on the wiki: https://github.com/bitcoin/bips To prevent confusion the next step should probably be to replace the BIPs on the wiki with links to the github documents, with a notice that changes should be proposed on github or mailed to the BIP editor (gmaxwell). Agreed? I think this would stifle active BIP draft editing. We're already having a hard time getting some developers to write BIPs for their proposals - I don't think we should be putting up bigger hurdles. Luke -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ 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, November 16, 2013 12:41:56 AM Drak wrote: So a payment clears after one confirmation, but you might want to wait until the payment has been confirmed n times. Then at least you are not using the same word for two different meanings and you're using stuff more familiar in popular lexicon. I dont think it's helpful for users if we use the word blocks. Confirmations in a numeric context isn't correct, though. We're using to it because we've been using Bitcoin so long, but to the average person they would expect it to mean something more than it is. If not referring to blocks, then perhaps witnessed N times? For years, people had a problem with email address, instead using email number but they got there eventually. Most people nowadays use email address So payment address or bitcoin address make better sense here when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. I think you might be demonstrating my point with regard to user confusion here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. Bitcoin addresses aren't the destination - they're point to a destination (an account in a wallet), but they also represent information such as who is paying and what for - in other words, a specific invoice. Luke -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ 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 Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote: Would now be a good time to start thinking about changing the default display in the software. Perhaps initially it could be a dropdown display option, then at some point mbtc becomes the default? There's already a dropdown display option... -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ 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 Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote: Obviously the answer is to just display all fees and trading rates as BTC or MBTC (.005 MBTC fee? how cheap!). On a more serious note, the transition should definitely be thought out well as it could be very damaging to have this confusion, but I would prefer to do it only once rather than twice. I wonder if it might make sense to bundle some other terminology fixups at the same time. Right now, Bitcoin-Qt has been using the term confirmations (plural) to refer to how many blocks deep a transaction is buried. We also use the term confirmation to refer to the point where a transaction is accepted as paid. IMO, the latter use makes sense, but the former leads to confusion especially in light of scamcoins which abuse this confusion to claim they have faster confirmations, implying that the actual confirmation occurs faster when it really doesn't. 5 blocks deep may not be more clear to laymen, but at least it makes it harder for people to confuse with actual confirmation. I think we all know the problems with the term address. People naturally compare it to postal addresses, email addresses, etc, which operate fundamentally different. I suggest that we switch to using invoice id to refer to what is now known as addresses, as that seems to get the more natural understanding to people. On the other hand, with the advent of the payment protocol, perhaps address/invoice id use will die out soon? Thoughts? Luke -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ 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 Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote: I really like the XBT idea. It makes a lot of sense to match the ISO currency symbol (though the ISO guys will have to adjust the way they've defined the XBT). And I do agree that going right to uBTC and skipping mBTC makes sense, too. I'd prefer them not be called micro bitcoins. I really want to call them microbes ... but I'm not sure that has the right flavor for money transfer :) Please give me 872 microbes. Perhaps we just call them bits. Or even micros or microbits. As I write this, I realize there's probably 872 threads on the forums about this already... But we would want to promote a consistent term, to avoid further confusion when people use different names for the new unit. It's not guaranteed to be successful, but if we pick a good name, and build it into the interface on the first release pushing the new unit, we have a chance to make the transition even easier. As long as we're using SI units, IMO we should stick to SI. That means micro- bitcoins. *Informally/spoken*, an abbreviation like mibicoins might make sense. Luke -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] idea
On Saturday, November 09, 2013 8:16:07 PM Chris Evans wrote: maybe add an optional note field to transaction so the receiver knows who sent the btc This mailing list is for development discussion, NOT bug reports nor feature requests. Bitcoin does not currently support any built-in mechanism for conveying the sender of a transaction nor notes. It is advised to collect any such information you need before giving someone a payment address. Luke -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Message Signing based authentication
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote: I actually had a use case in my case where it was possible, and that was the check I used to get around it, just configured it so that I always generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx. It was either that or making sure I had no unspent outputs. The use case of doing it was laziness in just creating a single key. Use cases mean an actual use, not mere laziness. Bitcoin as a system has always required a unique EC key (and address) for each transaction. Luke -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Message Signing based authentication
On Saturday, November 02, 2013 5:01:43 AM bitcoingr...@gmx.com wrote: In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are delighted to introduce the Message Signing based authentication method. In brief, the authentication work as follows: Server provides a token for the client to sign. client passes the signed message and the bitcoin address back to the server. server validates the message and honors the alias (optional) and bitcoin address as identification. http://forums.bitcoingrant.org/ Above is a proof of concept forum that utilize this authentication method. Congratulations! You've reinvented what Eligius and Bitcoin-OTC have been doing for years! :) There's no reason to ask the user to provide the address every time, though... Luke -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote: Currently bitcoinj gets a small but steady stream of bug reports of the form my transaction did not propagate. It's flaky because the library picks one peer to send the transaction to, and then watches it propagate across the network. But if that selected peer refuses the tx for whatever reason, that propagation never comes, and there's currently no timeout to make it retry with a different node. Sounds like the real bug is BitcoinJ relies on good/servant behaviour from other nodes. Don't assume your random node isn't hostile. Handling a peer that doesn't relay your transaction for any reason (including if they lie to you about having done so) should be expected behaviour. Luke -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote: If anybody has strong feelings about what the reject categories should be, then please take the time to write a specific list, I can't read your mind It might make sense to use the rejection reasons from BIP 22 where applicable. https://en.bitcoin.it/wiki/BIP_0022#Appendix:_Example_Rejection_Reasons Luke -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden service (onion site) is controlled by an RSA key. It would be trivial to pack a tor HS pubkey into a self-signed x509 certificate with the cn set to f.onion. ... Thoughts? Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? It'd be nice to have a way to support namecoin-provided keys too... Luke -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal to replace BIP0039
On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote: I would like to propose a new BIP, that replaces BIP0039. BIP 39 is still a draft. Just suggest revisions to the author(s)... -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote: 1) Should the protocol specification page also be codified into BIP(s)? Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and formal form. 2) Should the current wiki pages be taken down / forwarded to the git repo or be auto updated from the git repo? Since it's the same format, I'd keep it up there, maybe with a link to the git repo on the main BIP index wiki page. 3) Even though the information in BIP 50 is valuable, should it really be considered a BIP? It's a hardforking protocol change, so IMO yes. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A critique of bitcoin open source community
On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote: I have a question regarding this part. I wrote a BIP for base 58 encoding / encryption of BIP 32 root keys. The BIP page states that we shouldn't add to this list ourselves, but should contact you for a BIP number. I have contacted you a couple times on bitcointalk for a BIP number, but haven't received a response (or do those requests explicitly have to go to your email address)? See BIP 1 for the process.. proposals go to this mailing list first. Luke -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making bitcoin traceability harder
Faré, Let me start out by noting that there are plenty of good ideas which could be implemented, but haven't been yet, and might take a long time to get to. There are only a couple handfuls of Bitcoin developers, and even fewer of us who are able to work full-time on Bitcoin development. Perhaps surprisingly, even this often isn't the bottleneck to new functionality: we have a terrible shortage of testers, needed to make sure improvements don't break things in subtle ways. So, while your ideas are appreciated, please keep in mind that it may take time to add them, and you can help Bitcoin development much more by aiding in testing currently-written-but-untested features. With regard to your points made specifically, please note that addresses are intended to be single-use only. Thus, the recurrent user of address A/B are not using Bitcoin correctly already, which is why they are so easy to trace. As far as keeping change amounts as powers of two, while I would personally love to find a justification for power-of-two amounts, I don't see how this would help privacy. I think it would actually hurt privacy, as change would now be clearly identifiable. Furthermore, it would necessarily have to throw away excess as a transaction fee - some users would be very upset with this. As you suggest, it is of course already best practice for merchants (and individuals!) to use a unique payment address for every transaction. Gavin's payment protocol work has been making some great progress toward improving usability for this. There is also a general consensus that Bitcoin-Qt's Receive coins tab could be significantly improved to discourage address reuse further. I don't believe it has been discussed to have merchants use multiple addresses/coins for a single payment; that might be worth some further discussion here as a privacy extension, but I don't think many would consider it an urgent issue (it may help, but probably not enough to make it worthwhile). Luke On Wednesday, August 21, 2013 3:39:12 AM Faré wrote: Dear bitcoin developers, trading arbitrary amounts of bitcoins makes it easier to trace who does what just by observing the amounts being traded, and where the residual money ends up: e.g. you can identify that obviously, the recurrent user of address A sent 2.5 bitcoins to the recurrent user of address B, keeping the rest of his money in A. If instead bitcoin users practice the discipline, enforced by the client software by default, of only keeping a power-of-two amount of satoshis in use-once wallets except where public donation addresses are meant, then tracing suddenly becomes much harder. Whether this particular discipline is the best to implement or not, shouldn't bitcoin clients enforce SOME discipline that makes tracing harder? After all we know that uniformed goons are eager to watch who's trading with whom and to crack down on users. We shouldn't be making it easy for them, though this will mean slightly higher transaction cost. Merchants would then generate not one but a series of new addresses at each transaction, and the customer would send appropriately sized buckets of satoshis to each of the addresses. There should just be a standard way to specify an amount and a list of addresses as a target for payment, that merchants can communicate to customers (though that might require e.g. higher resolution QR codes). Has this idea already been considered before? Accepted or rejected? —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Of course, Third World leaders love you. By ascribing third world ills to First World sins, you absolve them of blame for their countries' failure to advance. — John McCarthy --- --- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] LevelDB in master
Now-merged pull request #2702 appears to have put the master branch on an unofficial Ripple fork of LevelDB, rather than merely updating us to LevelDB 1.12.0. While Vinnie did somewhat disclose this, I don't see any evidence the nature of this was fully understood by others. As I understood the pull request, the Ripple and Bitcoin fork was just LevelDB with the changes we had already made. Mike's comments on the pull request (his audit) suggest that this may have been the case in an earlier revision of it. But in fact, there appear to be a number of other changes included in what was finally merged a few weeks ago. Furthermore, Ripple's fork did not do a proper git merge of upstream, thus there is a break in git history, and, more importantly, a number of upstream fixes (including some we have had reported to the Bitcoin issue tracker) were not included in this merge. I've pushed three branches to https://github.com/luke-jr/leveldb : bitcoin-1.5 Our old/unreleased LevelDB 1.5 fork, for reference bitcoin Our LevelDB 1.7 fork, included in 0.8.x bitcoin-upOur LevelDB 1.7 fork, merged with upstream LevelDB 1.12 A diff from current master (Ripple LevelDB 1.12 fork) to bitcoin-up: https://gist.github.com/luke-jr/6248543 Thoughts? Luke signature.asc Description: This is a digitally signed message part. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] btc name server
Chris, First, an important point: addresses are not wallet ids. They are single-use destinations for a single transaction. It isn't intended that anyone should remember them, just that they should send them electronically (or with eg, QR- Codes). Bitcoin does not (yet?) have a person/wallet identity system, but there are other mechanisms for this already (eg, PGP). With regard to your idea, I believe it is satisfied by the new Payment Protocol that Gavin has been working on. You will be able to publish a URI for a website which people can reuse to pay you more than once. Luke On Friday, August 02, 2013 8:40:27 PM Chris Evans wrote: wonder if it would be good idea to have a alias to wallet id nameserver in the client software where a person can use a english name to describe a wallet public key address? and the software can use it to look up the wallet id. wallet ids are hard to remember/recall. -chris http://tawhakisoft.com/ -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Opcode whitelist for P2SH?
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: What are your thoughts on creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, retaining the existing standard whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set) This would be reasonable for miners, but for interoperability between wallets, some specific standard forms would still be necessary without a much smarter solver (which would then expand the code required to implement a wallet, which is unfortunate if not entirely necessary). -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Linux packaging letter
On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote: 1) It appears that the consensus of upstream developers is that any distributed binary should only be linked against libraries that the bitcoin developers have tested and audited since any compatibility bug is a risk to both the user and the network. Response: Is there a way to certify the Debian libraries? Debian bitcoind/bitcoin-qt runs the compile test during all architectures. It doesn't need to be audited by any given person or team, just someone who understands the issues and can dedicate the time to doing a competent audit. Testing bitcoind/bitcoin-qt is not sufficient: you must guarantee that your libraries (especially LevelDB) are bug-for-bug compatible with the ones used by everyone else. And not only the current versions, but every future version to ever hit the repository. This means a lot of additional work for the maintainers of the library packages, and the security team; for example, the security team must understand that they *cannot* deploy a critical security bugfix to LevelDB until someone competent has reviewed that it is behaviourally (including bug behaviours!) compatible with the versions in use everywhere else/previously. I think it is likely all this additional work/delays will be considered unacceptable to your library/security teams, thus using the bundled/embedded LevelDB is probably the best solution. MIPS has been failing recently, but no one has looked into it yet. Perhaps it's not worth developers efforts yet, but at some point the technology should reach a point it can be redistributed. MIPS (and any other big endian architecture) has *always* failed on the Satoshi codebase, and will not be supported until someone has time to dedicate to fixing the numerous little-endian assumptions in the code. I have an incomplete port, but it isn't very high on my priority list to figure out what else it's missing. 2) Bitcoin is new technology, so any patches have the ability of harming both the network and user. Response: I, and I'm sure everyone else working on it, totally agrees. All patches are public [1], you can see that the patches are only to the build system (except for one adding a debug message). Is there a specific patch or bug that is problematic? This seems to be reiterating (1) above: don't patch the build system to use libraries that were not audited by the developers. The two solutions are: (1) no one besides the upstream developers compiles and distributes binaries, ever, or (2) upstream comes up with a system where someone besides them can compile working binaries for distribution. Most likely the best solution is to do (1) until upstream sets up a system to allow (2). Debian could probably get away with packaging Bitcoin-Qt and bitcoind as-is with no modifications, and not have any problems. It's only when you begin making modifications that it becomes a problem. There are also some concerns that it puts a much larger price on compromising Debian's build servers and/or repositories (suddenly the attacker can steal a LOT of money). The official binaries are not simply built by upstream developers: using Gitian, *anyone* can produce bit-for-bit identical binaries. Official releases are only published after 3 or more people have done an independent compile and signed the output. It would be excellent if the whole of Debian could work toward achieving this level of security eventually, which would make distributing Bitcoin node software much safer as well. Luke signature.asc Description: This is a digitally signed message part. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Endianness (was: Linux packaging letter)
On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote:
Is there a substantial barrier to endian independence in the Bitcoin
codebase?
I got the obvious stuff ('endian' branch in my repo), but it still didn't work
when I moved on. I haven't had time to try to figure out why not yet.
Luke
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote: Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how is mined. And if the price rises it will make sense to spend more on mining. Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. But the total reward is what mining will tend toward equalizing in costs. In any case, the cryptocurrencies are neutral to cost of mining, or perhaps even benefit from it being as cheap as possible: if it's cheaper to mine, you can get an even higher difficulty/security out of it. The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. I suspect you may mean a block that doesn't include transactions you want confirmed. In that case, you must not be paying sufficient fees for the miner to consider it worth their time, or must be doing something the miner considers fundamentally objectionable (in which case they won't be satisfied by any fee). But these miners, unless they are able to acquire over 50% of the hashrate (in which case the cryptocoin is compromised), are not the only ones mining blocks, and if another miner accepts your transactions there is no issue. Luke signature.asc Description: This is a digitally signed message part. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either because it's market value is low or the worth is negative to the malicious miner, your theories of value have nothing to do with the issue. Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means. If you have hash power for the parent chain, mining invalid blocks for the merge-mined chain costs you nothing. Yes, they will be invalid, but you've lost nothing. Nor gained anything. So the lesser chain maybe can't trust SPV. But trusting SPV was already a bad idea anyway. Note that the parent chain is not in any privileged position here either: a merged-mined chain could provide the value to the miner he is interested in, while he sees nothing of the parent chain. In short, merged mining is pretty much unavoidable in any case. The basic assumption underlying mining security is that it is more profitable to collaborate with mining a chain (and profit from the block payout) than to attack it. In the case of merged mining, this assumption is not valid. The basic assumption of SPV is that more people will be assisting rather than making invalid blocks. That motive doesn't necessarily need to be economic, nor do proper validating clients rely on it. The only real assumption behind mining is that the majority will not be aiming to reverse transactions with valid blocks. P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) signature.asc Description: This is a digitally signed message part. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote: On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote: P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) Your ideas about making an alt-coin have anything to do with hashing power might be a lot more convincing if you hadn't 51% attacks alt-coins in the past. Slander like this does not belong on the dev ML. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? I'm sure others can come up with a few more. Possibly against: Does MultiBit still promote Bitcoin misunderstandings with misinformation like from addresses? (my apologies if I am remembering a different client) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote: On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote: Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change) for any number of shares. That's a good point - the current practice most pools seem to follow of about a share per second seems very excessive to me. On the other hand, it does have good user optics. The right solution might be something akin to P2Pool where the UI level is telling the user shares are being found so it's clear stuff is happening, but under the hood only a small subset are ever sent to the pool. Share rate is relevant to more than user information - it also affects the variance of reward/payout. I disagree with claiming shares are found when they're not sent to the pool - this makes auditing and troubleshooting more difficult; for example, see the GUIMiner bug where it reports shares despite misinterpreting the pool's target and submitting nothing at all (this happens when the pool uses pdiff 1). # Pool work So does eliopool already accept arbitrary shares like this and do the correct accounting already? (IE adjust share amount based on fees?) What happens when the pool doesn't get the share directly, but does see the new block? + possible protocol extensions I don't follow. What part don't you follow? I don't understand the first two questions here at all. Luke -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] is there a way to do bitcoin-staging?
Note that the earn a mixture of BTC and TBC, but not both in full volume only works for TBC because the price is by definition fixed with BTC. I'm not sure how you could implement something like this for an altcoin where the price is floating independently of Bitcoin.. that is, how you would know the right amount of Bitcoin to require sacrificed. Luke On Friday, June 14, 2013 8:50:31 PM Adam Back wrote: Agreed. What I mean is a coinbase for parity-priced alt-coin would be intentionally considered (and required by the alt-coin to be considered) an invalid bitcoin address, and vice versa. The difference is for this purpose it is both valid alt-coin coinbase (as well as unspendable bitcoin coinbase). Adam On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote: On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote: I had one thought towards this which is a different kind of merged mining. I think a fair merged mining aiming for price parity would be done by the miner having to choose the altcoin or btc at mine time, and altcoin chain considering btc mine unspendable and bitcoin considering ac unspendable. One way to look at what you are describing is to say you want to prove your sacrifice of potential BTC earnings. That goes back to the PoW hashcash stuff I mentioned earlier, and is accomplished by simply mining shares with an unspendable coinbase to prove you did work that could have resulted in Bitcoins, but didn't. --- --- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin addresses -- opaque or not
On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote: For the sake of argument let's say that opaque means that you can tell nothing about the address by examining the characters. This is true or false based on CONTEXT. Obviously, an implementation of transaction handling (eg, wallets) needs to be able to translate addresses to and from what they represent. On the other hand, things like URI handlers do not (and should not) try to interpret the address as anything other than an arbitrary word (\w+). My understanding was that they are NOT opaque, and that if that has changed, it will invalidate much at least some wiki page, for examples at least some of the following would now be false: The wiki goes into much detail on how addresses work, which is not the concern of most software in the Bitcoin ecosystem, but may be of interest to humans and developers working on the one component that operates the black box that addresses are. snip These aren't FALSE, they are true at the moment, but subject to revision by newer standards. I also here that there is a LIKELY change from the base58 encoding ... when was this established? I stated (on IRC) that it was likely Bitcoin would change from the base58 encoding for addresses ... at some unspecified time in the future, to some unspecified new encoding that addressed known limitations of base58. What those changes will be, or when, are not all established at this time. The only currently-planned change to addresses (very loosely defined) is inclusion of the Payment Protocol URIs. But the point is that software developers shouldn't assume that addresses will remain base58 forever. Luke -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralizing mining
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote: # Protocol Work This is basically done. Basic idea is the miner makes two connections, their pool, and a local bitcoind. They always (usually?) work on the subset of transactions common to both the pool's getblocktemplate and their local one. When they find a share if it doesn't meet difficulty they just hand it to the pool. Currently that is done by handing the whole block over, correct? I know the BIP says otherwise, but we should optimize this to just hand over tx hashes where possible. The plan was to tell the pool it doesn't need to send transactions at all, and only work on the ones from bitcoind. Currently, share submissions are just the block header and coinbase transaction; in this case, however, the miner will need to send merkle links also, possibly just once via a block proposal in advance. If the share does meet difficulty, hand it to both the pool and the local bitcoind. Should hand it to the pool first though, because the pool likely has the fastest block propagation, then hand it to local bitcoind. An optimized version may want to have some record of measured bandwidth - this applies Bitcoin in general too, although also has other issues. Currently, BFGMiner is doing submission to the pool, waiting for a response, then submitting to a local bitcoind. This is because the pool might need to receive/record the share before it processes the block on bitcoind, or you could lose credit for it. The response from the pool is rather small (a single TCP packet), so this shouldn't delay much longer. ## Reducing bandwidth How about for normal shares we just pass the block header, and have the pool randomly pick a subset of transactions to audit? Any fraud cancels the users shares. This will work best in conjunction with a UTXO proof tree to prove fees, or by just picking whole shares randomly to audit. Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change) for any number of shares. IF bandwidth becomes a real problem, I have a draft of a GBT 2.0 that does some more improvement in this area. # Pool work So does eliopool already accept arbitrary shares like this and do the correct accounting already? (IE adjust share amount based on fees?) What happens when the pool doesn't get the share directly, but does see the new block? + possible protocol extensions I don't follow. # Miner work Basically we need code to merge the two block templates together to find commonality. I guess you probably want to implement this in bfgminer first, so add the code to libblkmaker first, then maybe python-blkmaker. libblkmaker's API was designed for this from the start, so it should be fairly easily implemented. We also want an automatic fallback to local solo mining if the pool can't be contacted. + possible protocol extensions Failover already functions, but probably could use a rewrite... Luke -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Thursday, June 06, 2013 7:59:16 PM Andreas M. Antonopoulos wrote: Is there any consideration given to the fact that bitcoin can operate as a platform for many other services, if it is able to be neutral to payload, as long as the fee is paid for the transaction size? This doesn't work like you might think: first of all, the fees today are greatly subsidized - the actual cost to store data in the blockchain is much higher than most storage solutions. Secondly, only the miner receives the fees, not the majority of nodes which have to bear the burden of the data. That is, the fee system is setup as an antispam/deterrant, not as payment for storage. Unless I have misunderstood this discussion, it seems to me that this is a bit like saying in 1990 IP Is only for email, the majority of users want email, we shouldn't allow video, voice or images. Ooops, there goes the web. Not the same thing at all; nobody is forced to store/relay video/voice/images without reimbursement. On the other hand, any full Bitcoin node is required to at least download the entire blockchain once. And the network as a whole suffers if nodes decide to start not-storing parts of the blockchain they don't want to deal with. Is it possible to solve this by solving the issue of provably un-spendable outputs without foreclosing on the possibility of other types of transaction payloads (ie, not money), that would open the possibility for a myriad of layered apps above? For example, hashes of content that is external to bitcoin, that people want to pay to have timestamped in the blockchain, as provably unspendable outputs. This is how merged mining solves the problem. A single extra hash in the coinbase can link the bitcoin blockchain up with unlimited other data. The social compact is to accept transaction for fee. I think it is a major mistake to make decisions that discriminate on the content of the transaction, saying that some uses are not appropriate. If the fee is paid and it covers the size of the transaction, why would it matter if it is not a payment? See above. I could be totally misreading this thread, too, so please allow me some slack if I have! On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: scriptPubKey: data OP_TRUE ... Along with that change anyone-can-spend outputs should be make IsStandard() so they will be relayed. Data does not belong in the blockchain. People running nodes have all implicitly agreed to store the blocks for financial purposes, and storing data is a violation of that social contract. Proof-of-stake may be arguably financial, but I'm sure there must be a way to do it without spamming people against their consent. The alternative is sacrifices to unspendable outputs, which is very undesirable compared to sending the money to miners to further strengthen the security of the network. The alternative is to make other standard outputs unable to store data as well. Luke - - How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote: This doesn't work like you might think: first of all, the fees today are greatly subsidized - the actual cost to store data in the blockchain is much higher than most storage solutions. Secondly, only the miner receives the fees, not the majority of nodes which have to bear the burden of the data. That is, the fee system is setup as an antispam/deterrant, not as payment for storage. There's a difference between storing the content itself, and storing just a hash to content (which however is not spendable payment). I undertand why content itself doesn't belong. But it goes too far to say that only payments should be allowed. Because payments are the only thing everyone using Bitcoin has agreed to use the blockchain for. Furthermore, there is no *reason* to store non-payments in the blockchain. If there was in fact such a use case, things might be arguable - but there isn't any I'm aware of. If the fees are not enough, fix the fee structure, don't stop incredibly innovative and promising uses of the distributed timestamping database. That is definitely throwing the baby out with the bathwater. If the issue is size, then address that, rather than the content itself. The issue is using other peoples' resources for something they did not agree to use it for. The fees aren't merely not enough, they were never *intended* to be cost of storage. They are cost of security and prevent spamming. Discriminating based on transaction content violates neutrality of the protocol and in my mind removes a very very large possibility of future innovation. If bitcoin is a *platform* and not just a payment system, then it needs to be neutral to content, like TCP/IP so that other protocols can be layered. Solve the size problem itself, without picking and chosing which uses of bitcoin are good and which are bad or spam. I think it risks killing a tremendous amount of innovation just as it is starting. The concepts behind Bitcoin are applicable to future innovation, but this can all be accomplished without spamming Bitcoin itself. Not the same thing at all; nobody is forced to store/relay video/voice/images without reimbursement. On the other hand, any full Bitcoin node is required to at least download the entire blockchain once. And the network as a whole suffers if nodes decide to start not-storing parts of the blockchain they don't want to deal with. So don't store content, but allow hashes of content. Again, I think it is extreme and extremely restrictive to say that ONLY payments are allowed. Non-payments are quite possible without the Bitcoin blockchain itself. If you're worried that not enough people will store the alternative-non-payment data, then you are essentially saying that voluntary participation is not enough and that forced storage is your solution. I don't think this is what you intend... This is how merged mining solves the problem. A single extra hash in the coinbase can link the bitcoin blockchain up with unlimited other data. Can you explain this part or refer me to some docs? What do you mean by coinbase, I assume not the company. The Bitcoin blockchain protocol has 95 bytes per block reserved for miners to put extra data. Currently, this is used for extranonces, political or other short messages (such as in the Genesis block), miner signatures, and also, as I mentioned, merged mining. Merged mining works by tying a non- transactional merkle tree to the blockchain. The block coinbase stores the hash of the top of this merkle tree, so any data within the merkle tree can prove it is associated to the block. The merged mining merkle tree then stores hashes of multiple other data sets: for example, a Namecoin block can be referenced in a merged mining merkle tree, to use the Bitcoin block's proof- of-work for itself (so, miners can mine both Bitcoin and Namecoin using the same hashing effort). You could also add other non-transactional blocks to the merged mining merkle tree, for generic timestamping or really anything at all. Luke -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.2 branch
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote: Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2) in which the like of release build stoppers or critfixes such as d315eb0 are included... for those tracking that level of defect without wishing to track all the growing post release slush in HEAD? I'll branch 0.8.x sometime in the next few weeks. Stable branches are maintained on Gitorious for now: http://gitorious.org/bitcoin/bitcoind Luke -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Modularizing Bitcoin
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote: One of the main goals will be to separate the wallet from the node, as we have already done with mining. How is this different from what Electrum has already done? Luke -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Modularizing Bitcoin
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote: Is the number representing the count for the client nodes? I was curious of the count myself earlier this week and started to traverse down the network using getaddr message starting from seed nodes and found upward to 57k nodes running protocol = 70001 with timestamp no older than 24 hours. This sounds accurate for listening nodes, and similar to what my own system counts: http://luke.dashjr.org/programs/bitcoin/files/charts/security.html Of course, it doesn't include the (many?) connect-only nodes (eg, mobile or firewall/NAT'd) or non-p2p nodes (eg, Electrum). Luke -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] (no subject)
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote: It might be an idea to have 'rule change' fixes and 'bug fix' releases go out separately Bitcoin is a consensus system. You can't run clients with different rules on the same blockchain/network - it just won't work! Maybe we're now talking about mere client default policies? In which case, you should be able to configure previous behaviour... If you want just bug fixes and rule changes, without policy default changes, new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised these are short-term solutions and won't be maintained forever - so you really should try to get the behaviour you want from the current release. If you can't for some reason, please do report a bug explaining what it is the older version was capable of that the new one isn't! Luke -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tentitive port for FreeBSD
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote: Here is the link to the FreeBSD build system 'port' that I am planning to get committed when 0.8.2 is released. Any comments appreciated. The Makefile mostly just applies the users request for GIU/QR/UPNP. The major change is using the external port for leveldb. The files directory contains 5 patches - 2 that add boost-crypto to LIBS because we still need that until boost is updated, one that patches the build to use that external leveldb, and 2 minor fixes that are needed to build. I have got branches ready for pullreqs on those minor fixes - I'll double check them and make pullreqs this evening. Again, any comments very welcome. Would be nice if you could help test (and use?) the pull request for system LevelDB support: https://github.com/bitcoin/bitcoin/pull/2241 Note that you should be careful to tie your port to the specific LevelDB version bundled, to avoid any risk of unexpected hardforking bugs or fixes in upstream LevelDB. For the other patches, please try to find a portable solution (if they aren't already) and open pull requests on github. Thanks, Luke -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote: On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@gmail.com wrote: Some out of band algo/hash could work so long as there was a one to one relationship between the described object and the UUID. In this case the gensis block may not uniquely identify a coin. What does this mean? It seems extremely unlikely that two different genesis blocks will have the same hash. Two coin ecosystems could have the same genesis block That has really, really bad side effects. The whole point of the bitcoin consensus algorithm is to avoid situations like this. We don't want to encourage that behavior with code. In some cases, multiple currencies can use the same blockchain (not just the singular genesis block). This use case *is* something we want to encourage - no reason for people to make an entirely new blockchain if their altcoin fits within the scope of Bitcoin or another existing altchain. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote: Currently signmessage/verifymessage only supports messages signed by a single key. We should extend that to messages signed by n-of-m keys, or from the users point of view, P2SH multisig addresses. I think it would be wise to figure out HD wallet changes before trying to extend message signing. For privacy/safety, it would be a good idea to avoid signing with the same private key twice under any circumstances, so it might make sense to create a new address format the represent a chain of keys instead of one key or combination of keys. Luke -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: Introducing super-nodes with thousands of connected peers can greatly help here. UDP is connectionless. I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Upcoming network event: block v2 lock-in
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind 0.7 or later? slush, BTC Guild, ozcoin too I think, several others. Not for producing coinbases (where BIP 34 is implemented). -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Upcoming network event: block v2 lock-in
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind 0.7 or later? slush, BTC Guild, ozcoin too I think, several others. Not for producing coinbases (where BIP 34 is implemented). Sure, that is largely the pool server layer. But it is misleading to imply that bitcoind is nowhere in the stack. Context is everything. bitcoind is nowhere in the implementation of the miner end of BIP 34. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Upcoming network event: block v2 lock-in
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote: bitcoind is nowhere in the implementation of the miner end of BIP 34. Again, not strictly true. bitcoind's 'getblocktemplate' RPC call used by some supplies the block version, selects transactions for the miner, and other tasks integral to the implementation of the miner and BIP 34. Transaction selection and everything else bitcoind does, is irrelevant to BIP 34. It is incompatible with getblocktemplate for coinbase-creating software to produce v2 blocks without implementing BIP 34 themselves, even if the upstream GBT server specifies it. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote: On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote: For me, everyone signed up to bitcoin thinking that there was a 1MB / block limit. The lock limits were unexpected, and could be considered extremely uncontroversial to remove. This. Software behavior which is not described by the source code should not be considered an integral part of the rule set. Any influence of external libraries on the consensus mechanism is unacceptable. Note that the lock limits were explicitly set in the bitcoind source code. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote: On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. I figured 2 MB in 2-3 years was fairly uncontroversial. If not, let's scrap that idea for now. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? It was a one-time start the conversation proposal. I expect what we end up going with may be substantially different. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 5:41:29 PM you wrote: I'm not sure I understand the need for hard forks. We can get through this crisis by mining pool collusion to prevent forking blocks until there is widespread adoption of patched clients. Anything requiring widespread adoption of patched clients *is by definition* a hard fork. Proposal: 1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). This is a hard fork. The only way to avoid a hard fork is to apply the existing lock limit to all clients forever. That would be fine, except that pre-0.8 clients cannot reorg N blocks without dividing that limit by (N * 2) + 1; that leaves us with the limit of around 1000 locks per block on average. Each transaction uses at least 3 locks on average (many times more). So about 300 transactions per block. This is a much smaller limit than the 1 MB we've been assuming is the bottleneck so far, and the need to increase it is much more urgent - as Pieter noted on IRC, we are probably already using more than that even ignoring DP spam. The only reason pre-0.8 clients have survived as well as they have thus far is because the blockchain has managed to avoid very deep reorgs. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blocksize and off-chain transactions
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). While 0.7 and earlier do have issues, they also define the Bitcoin protocol. 0.8's failure to comply with the protocol is an issue. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.1 ideas
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote: Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8 does and what every other verifying implementation does), and through miner collusion buy ourselves enough time for people to update their own installations. Curiously enough, at least MtGox's custom implementation stuck with the canonical blockchain despite 0.8's accidental rule change. I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? How do you resolve that without being arbitrary? And regardless, we are moving very quickly towards a multi-client future. This problem is very clearly a *bug* in the old codebase. So let's be forward thinking and do what we would do in any other situation: fix the bug, responsibly notify people and give them time to react, then move on. Let's not codify the bug in the protocol. No, if any other client released diverged from the consensus of all past/existing clients, we would do the same thing: call it a formerly unknown protocol rule, that this new client has a bug implementing, and be done with it. The only reason this particular issue needs special treatment is because the implications of the new rule mean that we're up against a hard limit in the protocol today rather than 2 years from now. Luke -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Some PR preparation
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote: I'm sure it won't be long before Slashdot and a variety of sources start reporting on this event. Bitcoin has been in the media a lot lately, so this story is likely to get some attention. The blowback of this event is mostly psychological, so I think it would be exceptionally wise to start preparing PR comments that can be posted on articles immediately after they go public. This event is likely draw much more negative attention than it deserves, and getting some positiveinformed comments posted up front will potentially make a difference in the way the story is received. Undoubtedly, many articles (and especially commenters) will shape this into the end of Bitcoin. I would describe it as there was a short and mostly-harmless lapse in the ability of the network to reach a consensus, causing transactions to get delayed by a few hours. It *really* needs to be emphasized that coins are safe, and nothing anyone has/could do will change that. And that it would've been extremely difficult to exploit for gain. Transactions got delayed while a bug was fixed. End of story. I think we should be careful not to downplay the reality either. For a number of hours, transactions could have received up to N confirmations and then still been reversed. While we could contact the bigger payment processors, I saw people still trying to buy/sell on OTC, whom could have been scammed even by taking standard precautions. Luke -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote: From: Rune K. Svendsen runesv...@gmail.com On the Main tab in the Options dialog, it previously said a minimum fee of 0.01 is recommended. This amounts to about $0.50 at today's price. Change this to 0.001 to be more sensible. We could even go lower, perhaps. Please use GitHub pull requests (or at least publish a git repository) rather than mailing patches.. I'd suggest two commits for this: 1. Move the recommended fee outside the translatable string (bonus points to format it using the user's preferred unit) 2. Change the recommended fee in one place Whether the recommended fee *should* be changed or not, I have no opinion on. Eligius uses a lower minimum fee, but I believe most pools/miners will treat anything under 0.01 BTC as if it were no fee at all... Luke -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote: On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should be doable to do string substitution for both the value and the unit. Side note: I imagine you'd be substituting a formatted string, and using some other function to format the string (which already exists to decide how to display units elsewhere). I'm not entirely sure what you mean by this. I plan on using the method described on this page http://doc.qt.digia.com/3.1/i18n.html under Use QString::arg() for Simple Arguments and then just putting a %1 and %2 in the translation strings and substituting for value and unit, respectively. Haven't tested it yet, but that's what I plan to do. eg, use a single %1 with BitcoinUnits::format(walletModel-getOptionsModel()-getDisplayUnit(), amount) Where do you want the constant defined? In main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE? Sounds reasonable. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Blockchain as root CA for payment protocol
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: Why don't you use namecoin or another alt-chain for this? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. What is the technical difference here? Namecoin ties names to data; DNS is a specific namespace in it. There is no reason I know of that this identity stuff cannot be a new namespace. You can argue that alt-chains _can_ be as strong as bitcoin, but they don't _have to_ be. There is no guarantee how many people will cross-mine. This is true of namecoin, but it does not have to be true of new merged-mined data. You could very well require the Bitcoin proof-of-work to be valid and the master header to be in the Bitcoin blockchain. The alt-chain could even disappear at some point. If at some point your alt- chain is no longer being worked on, then how do you prove that some old bitcoin transaction went to an address for which there was a valid id/certificate at the time of sending? If the certificate is based inside bitcoin's blockchain then you will have a proof for the correct destinations of all your old transactions as long as bitcoin exists. Yes, if people stop using your system, it won't work. Consider that a this idea failed scenario, where it doesn't matter. Luke -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.0rc1 status
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote: Windows builds are varying with every compile, and I think I finally figured out why: we are not passing the -frandom-seed flag down into the leveldb build (I used objdump to dump two different binaries, and they differed only in the names of some leveldb objects). That should be an easy makefile fix. FWIW, this should be already mostly-fixed in pull #2243 I submitted 9 days ago... only thing not in that pull is changing gitian to use the standard CXXFLAGS rather than our non-standard DEBUGFLAGS (whether DEBUGFLAGS should be propagated to LevelDB or not is another conversation I guess). Luke -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client had their own list, you'd be back to the original problem of not being sure your CA is on all lists. Would you find it acceptable if something supported a static whitelist plus a OS provided list minus a user configured blacklist and the ability for sophisticated users to disable the whitelist? How is this whitelist any different from the list of CAs included by default with every OS? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote: Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. I'd like to talk about: o Can we put together a TODO list to get to a 0.8 release candidate ? o Is it time to feature-freeze 0.8 and work on just testing the new features and fixing existing bugs (the issues list keeps getting longer and longer ... )? Not much has changed besides internal workings, right? Though perhaps that's still significant enough for 0.8. o BIP process: are we happy with how it is working? What can we do to improve it? Amir seems to be more and more absent these days, so it might be nice to setup a successor failsafe in the event that he cannot be reached. It would be a shame for the BIP process to fall apart merely because we can't get numbers assigned. But more important to the success of BIP today, I think, is encouraging wider community participation. The stratum mining mess seems to be a direct result of lack of participation in the GBT BIP process (resulting in it not being as ideal as some pools desire) and lack of any peer review/contribution toward the stratum protocol. What can we do to increase awareness of BIP and encourage more collaboration? Luke -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday
On Tuesday, November 06, 2012 7:56:23 PM slush wrote: On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote: But more important to the success of BIP today, I think, is encouraging wider community participation. It's not about BIP process, it's possibly about content of particular proposals. ... I promised to write BIP draft for Stratum, I proposed and implemented get_transactions method to allow Stratum jobs inspection. What more do you want, seriously? I'm soo tired by you, Luke. Perhaps the problem lies in misunderstanding of the BIP process, then, rather than awareness of it. BIP isn't just write a document; that's just the first step. The main thing is that it gets peer review, changed to meet the community's needs, and when done should result in a common standard suitable to the needs of the whole community. Whatever the reason, there was a failure of key members of the community to participate in the GBT BIP process and ensure it addressed their needs/wants; identifying and addressing that is something that would improve the BIP process. get_transactions is a step in the right direction, and I don't think anyone expects Stratum to reach the same level as GBT overnight considering it took months for GBT (though I have no doubt now that the GBT discussions have taken place, that some dedicated individual could probably combine the two if they dedicated a few days to it). My comments, however, were not intended to bash stratum or mere complain about the past (it can't be changed), but an attempt to learn from the past and figure out how we can improve things the next time around. Luke -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Hosting of compiled bitcoin client
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote: Given that sourceforge has shown to restrict access to a number of countries at the request of the USA This needs some clarification. If the USA has requested it, then presumably there's some legality involved, and our US developers shouldn't be made liable for it. The specific reason SourceForge has restricted access should be made known so non-US developers (or gitian builders) can evaluate their own laws and hopefully at least one will be in a jurisdiction that allows it. But GitHub is also US-located, so hosting it there may be a problem too. Luke -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are. https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal Most of the problem with block propagation lies in implementation, not protocol... Distributing missing transaction on an as-needed basis is a possible improvement at the protocol level, but there hasn't (AFAIK) been any research into whether the little benefit outweighs the cost yet. In any case, I don't see why 6 new messages are needed instead of simply adding a single new type to getinv? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.7 release planning
On Thursday, August 02, 2012 4:43:25 PM Jeff Garzik wrote:
Opening the floor... What do we collectively want to happen, before
0.7 release? What is the todo list for 0.7?
Based on pull-capable dev comments, I've personally noted these branches as
accepted for 0.7:
7) HOPEFULLY: Addnode optimization and addnode access via RPC
BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
8) MAYBE: Transition to requiring block height in block coinbases
gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
10) I THINK WE WANT THIS? Make IPv6 support optional again (defaults
to enabled)
luke-jr https://github.com/bitcoin/bitcoin/pull/1431
11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor transaction/accounting time
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1393
I also personally feel these are appropriate and ready for 0.7:
4) Add 'mempool' P2P command, and extend 'getdata' behavior
jgarzik https://github.com/bitcoin/bitcoin/pull/1641
6) JSON-RPC method: prioritisetransaction txid priority delta
luke-jr https://github.com/bitcoin/bitcoin/pull/1583
9) RPC: add facility to enable RPCs to run outside cs_main, wallet locks
jgarzik https://github.com/bitcoin/bitcoin/pull/1493
+
+ m) Treat generation (mined) transactions less different from receive
+ transactions
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1409
Also these, but they need testing:
1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
luke-jr https://github.com/bitcoin/bitcoin/pull/1647
5) PROBABLY NOT, BUT MAYBE: Relay blocks as a preview before
checking the transactions in them
luke-jr https://github.com/bitcoin/bitcoin/pull/1586
+
+ m) Bitcoin-Qt (Windows only): enable DEP for bitcoin-qt.exe
+ diapolo https://github.com/bitcoin/bitcoin/pull/1614
I also feel it is very important that Wumpus/laanwj decide on a name for his
client (formerly known as Bitcoin-Qt) and add it to the software instead of
simply claiming it is Bitcoin as it has for a week or so now - that change
is anticompetitive and will confuse new users into thinking Bitcoin is the
software too easily.
Luke
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 22 - getmemorypool
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote: https://en.bitcoin.it/wiki/BIP_0022 Note that the Pooled Mining parts have already been moved to: https://en.bitcoin.it/wiki/BIP_GMPPM It just needs a number assigned (as the last part). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Signing release binaries
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote: I guess Gavin would be the final signer. Considering that Gavin is not interested in participating in any way in the stable versions, I would prefer to see someone else responsible for OS-vendor signing. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote: I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync the chain, but it was less than two days as that was the span between when I checked on it. It's staying current Well, are you running bitcoin on, say, an FS with sha256 integrity trees for all bits and AES-128-XTS/CBC disk encryption? Trying to run state-of-the-art encryption on EVERYTHING on an ancient computer is fairly ill-advised. I encourage you to continue with the plan to go shopping. Someone suggested I investigate turning off the above features. Since I'd find their loss undesirable [1], and there's not much to be tuned there anyways, I've given up and am investigating what more GHz and cores will do. [1] Keeping data both intact and private is a good thing. Does your checkbook deserve any less? Sounds reasonable... but why do you also need to encrypt 2+ GB of public record? Luke -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org - remove hackathon
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote: Vladimir does raise a fair point, though. Hackathon seems appropriate for bitcoin.org as it is focused on dev-related activities. (full disclosure: speaking at bitcoin2012.com) The conference might or might not be. The conference does seem community focused, so I don't object to it being on bitcoin.org... But if consensus prefers otherwise, that's OK too. IMO, bitcoin.org is more community-focussed anyway. How often do devs use the site, compared to GitHub etc? Someone else made a pullreq for Bitcoin Magazine; I suggest(ed) that for-profit organizations should be asked to pitch in some way or another. Who should organize that, I don't know. If Bitcoin Consultancy/Amir is behind the conference, I suggest their/his development contributions should be sufficient in that respect. PS. This seems like material for pull requests, which is preferred over mailing list email + git push. When working on the satoshi client, we all ACK each other's pull req for anything beyond the trivial. I concur, this should be discussed in a pullreq. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
FWIW, all this argumenting is why my original suggestion for a Clients list focussed on objective information in alphabetical order. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.6.x - detachdb in wrong place
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote: https://github.com/bitcoin/bitcoin https://git.gitorious.org/bitcoin/bitcoind-stable The latter is Luke's backports of security and stability fixes to otherwise unmaintained old versions. Ah ok, coming from cvs/svn, it's a bit different to find things. There's something to be said for maintenance of pior branches. Though I see some things I can use in github and my work would be more useful there, so maybe I'll stwitch to that from gitorius/0.6.x. Presumably the github/0.6.2 branch is safe for production? No, that was a temporary branch of what became the stable 0.6.x branch. GitHub/master is bleeding edge. For production, you usually want the stable branches/releases (which are on Gitorious). The fix to -detachdb's position in -help was just merged to master, and should be backported sometime in the next few days. Luke -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote: On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote: RE: 0x06/0x07 'hybrid' public keys: Any opinions? Forbidding it certainly makes alternative implementation slightly easier in the future, but I'm not sure the hassle of a network rule change is worth it. I say treat any transactions that use them as 'non-standard' -- don't relay/mine them by default, but accept blocks that happen to contain them. I agree that a rule change isn't worth it right now, but making them non-standard now is easy and should make a rule change in the future easier. ACK. Hopefully no one will mine these before we can merge denying them into another rule change. But if they do, oh well. I'm willing to make Eligius reject these as well, if someone provides a patch that doesn't depend on IsStandard being enforced... Same goes for rejecting OP_NOPn - I can't see any legitimate reason we'd want these on mainnet right now. Luke -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP16 backport bug (0.4.x and 0.5.x stuck on block 177617)
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these versions also enforced the 200-byte is standard rule, they were effectively treating it as a network rule. This was not a problem in 0.6 because the original OP_EVAL commit (e679ec9) moved the check outside of IsPushOnly. This problem could have been avoided if either IsPushOnly was renamed when its semantics/behaviour changed significantly, or I inspected the OP_EVAL commit in detail instead of skipping it over as a new feature and not bugfixes. Additionally, it might have helped, if the commit message mentioned the change, but I'd probably have still missed it as it wasn't relevant until months later. I will be releasing 0.4.7 and 0.5.6 hopefully in the next 24 hours to address this bug, along with instructions to get unstuck: 1. Ensure you have the minimum required 1280 MB memory available 2. Create a new file in your bitcoin directory (the same one with wallet.dat) called DB_CONFIG with the following two lines: set_lk_max_locks 100 set_lk_max_objects 100 3. Start bitcoind or Bitcoin-Qt 4. WAIT AT LEAST SIX HOURS Your client will NOT show any signs of making progress during this time 5. When complete, your client should be up-to-date on block count 6. At this time, you may wish to delete the DB_CONFIG file and restart your client, to use less memory Luke -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Defeating the block withholding attack
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote: Does it have asymmetric payoff for an attacker, that is, over time does it pay them more to spend their hashes attacking than just mining? That depends on the pool's reward scheme. Some complicated forms are capable of getting bonus earnings out of the pool. Under all systems, the attacker at least gains the hurt the pool benefit. Given the frequency of DDoS attacks on pools, it is clear there are people who will even pay for attacks that provide no other benefit than harming pools. Under all systems, the attacker doesn't lose out in any significant way. My gut is that it pays less well than mining, meaning I think this is likely a small problem in the aggregate, and certainly not something we should try and fork the blockchain for until there's real pain. If we wait until there's real pain, it will be a painful fork. If we plan it 1-2 years out, people have time to upgrade on their own before it breaks. Consider, for instance, whether it pays better than just mining bitcoins and spending those on 'bonuses' for getting users to switch from a pool you hate. With this attack, attackers can hurt the pool's luck factor *and* spend the bitcoins they earn to bribe users away. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
