Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir laa...@gmail.com wrote: On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote: Yes, as I said in the github topic (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a string-based name space for extensions. Why use textual strings? These fields are not for human consumption. Why not use UUIDs, which are fixed length and will not waste as much bandwidth in the protocol? Or if you'd prefer a hierarchical namespace, you could use OIDs, a la ASN.1. Also it IS useful for these fields to be human readable for statistics, peer list views and such. When encountering a new, unknown extension when connecting to a node it's much more useful to get a google-able string to find out what it is about, than some long hexadecimal or dotted-number identifier. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposals for improving Bitcoin mining decentralization
First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
I have been surprised by the lack of discussion of this topic here! On 6/17/2014 10:57 AM, Raúl Martínez wrote: We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released
Bitcoin Core version 0.9.2 is now available from: https://bitcoin.org/bin/0.9.2/ (or https://bitcoin.org/en/download) This is a new minor version release, bringing mostly bug fixes and some minor improvements. OpenSSL has been updated because of a security issue (CVE-2014-0224). Upgrading to this release is recommended. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Upgrading and downgrading == How to Upgrade -- If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux). If you are upgrading from version 0.7.2 or earlier, the first time you run 0.9.0 your blockchain files will be re-indexed, which will take anywhere from 30 minutes to several hours, depending on the speed of your machine. Downgrading warnings The 'chainstate' for this release is not always compatible with previous releases, so if you run 0.9.x and then decide to switch back to a 0.8.x release you might get a blockchain validation error when starting the old release (due to 'pruned outputs' being omitted from the index of unspent transaction outputs). Running the old release with the -reindex option will rebuild the chainstate data structures and correct the problem. Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan the blockchain for missing spent coins, which will take a long time (tens of minutes on a typical machine). Important changes == Gitian OSX build - The deterministic build system that was already used for Windows and Linux builds is now used for OSX as well. Although the resulting executables have been tested quite a bit, there could be possible regressions. Be sure to report these on the Github bug tracker mentioned above. Compatibility of Linux build - For Linux we now build against Qt 4.6, and filter the symbols for libstdc++ and glibc. This brings back compatibility with - Debian 6+ / Tails - Ubuntu 10.04 - CentOS 6.5 0.9.2 Release notes === The OpenSSL dependency in the gitian builds has been upgraded to 1.0.1h because of CVE-2014-0224. RPC: - Add `getwalletinfo`, `getblockchaininfo` and `getnetworkinfo` calls (will replace hodge-podge `getinfo` at some point) - Add a `relayfee` field to `getnetworkinfo` - Fix RPC related shutdown hangs and leaks - Always show syncnode in `getpeerinfo` - `sendrawtransaction`: report the reject code and reason, and make it possible to re-send transactions that are already in the mempool - `getmininginfo` show right genproclimit Command-line options: - Fix `-printblocktree` output - Show error message if ReadConfigFile fails Block-chain handling and storage: - Fix for GetBlockValue() after block 13,440,000 (BIP42) - Upgrade leveldb to 1.17 Protocol and network code: - Per-peer block download tracking and stalled download detection - Add new DNS seed from bitnodes.io - Prevent socket leak in ThreadSocketHandler and correct some proxy related socket leaks - Use pnode-nLastRecv as sync score (was the wrong way around) Wallet: - Make GetAvailableCredit run GetHash() only once per transaction (performance improvement) - Lower paytxfee warning threshold from 0.25 BTC to 0.01 BTC - Fix importwallet nTimeFirstKey (trigger necessary rescans) - Log BerkeleyDB version at startup - CWallet init fix Build system: - Add OSX build descriptors to gitian - Fix explicit --disable-qt-dbus - Don't require db_cxx.h when compiling with wallet disabled and GUI enabled - Improve missing boost error reporting - Upgrade miniupnpc version to 1.9 - gitian-linux: --enable-glibc-back-compat for binary compatibility with old distributions - gitian: don't export any symbols from executable - gitian: build against Qt 4.6 - devtools: add script to check symbols from Linux gitian executables - Remove build-time no-IPv6 setting GUI: - Fix various coin control visual issues - Show number of in/out connections in debug console - Show weeks as well as years behind for long timespans behind - Enable and disable the Show and Remove buttons for requested payments history based on whether any entry is selected. - Show also value for options overridden on command line in options dialog - Fill in label from address book also for URIs - Fixes feel when resizing the last column on tables (issue #2862) - Fix ESC in disablewallet mode - Add expert section to wallet tab in optionsdialog - Do proper boost::path conversion (fixes unicode in datadir) - Only override -datadir if different from the default (fixes -datadir in config file) - Show rescan progress at start-up - Show importwallet progress - Get required locks upfront in polling functions (avoids hanging on locks) - Catch Windows shutdown
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
In this scenario how do you ensure the miner solving the block cannot reapportion the subsidy to himself rather than the pool? On Jun 17, 2014 2:09 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
Because he cant change the coinbase once the proof of work is done. El 17/06/2014 15:58, Ron Elliott ronaldbelli...@gmail.com escribió: In this scenario how do you ensure the miner solving the block cannot reapportion the subsidy to himself rather than the pool? On Jun 17, 2014 2:09 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
as I understood your proposal the entire block would be created on the miner rather than just the block header. Currently miners do not receive a list of transactions, they receive information required to create the block header, this is how you keep miners honest. if the miner is creating the full block we are right back to where we were. I've only worked with implementing the mining process for a few months now so someone correct me if I have the process wrong On Jun 17, 2014 7:01 AM, Raúl Martínez r...@i-rme.es wrote: Because he cant change the coinbase once the proof of work is done. El 17/06/2014 15:58, Ron Elliott ronaldbelli...@gmail.com escribió: In this scenario how do you ensure the miner solving the block cannot reapportion the subsidy to himself rather than the pool? On Jun 17, 2014 2:09 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: - A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) - A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) - A pool owner cant decide which transactions not to include (but they can configure the minimum fee). - A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released
On 17/06/14 11:46, Wladimir wrote: For Linux we now build against Qt 4.6, and filter the symbols for libstdc++ and glibc. This brings back compatibility with - Debian 6+ / Tails - Ubuntu 10.04 - CentOS 6.5 Under Ubuntu 10.04: jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-qt ./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: _ZN10QTextCodec11validCodecsEv -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz signature.asc Description: OpenPGP digital signature -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [ann] Bitcoin Core version 0.9.2 has been released
On Tue, Jun 17, 2014 at 4:27 PM, Jesus Cea j...@jcea.es wrote: On 17/06/14 11:46, Wladimir wrote: Under Ubuntu 10.04: jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-qt ./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: _ZN10QTextCodec11validCodecsEv Did it work with the release candidate? Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
quote: https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most of the pooling-centralization problems. Unfortunately, it is opt-in, and GHash.io doesn't support it. Also most miners don't care and don't do the work to set it up. To do transaction inclusion themselves, they'd need to run a full node, which is a bit more work and resources than just pointing hashpower at a stratum server. If you figure out a way to make GBT widely used (50% hashpower), kudos to you. Well, as soon as miners learn about the merits of controlling the blocks' contents, this issue may get solved by the market pressure of miners expecting this kind of service from their pool. I mean, the dev community constantly has some level of disagreement about the best policies for what to include in blocks. But seen from the perspective of some Bitcoin business or another, certain policies might be more preferable. So if miners start to understand that they could take a stake for their favourite Bitcoin businesses by choosing a mining pool which employs a preferable transaction inclusion policy, the question would not anymore be which pool gives me the most Bitcoins or the lowest variance, regardless of the technical background, but which pools does the best for my Bitcoin economy needs. And this may be a very economically driven decision by itself, considering that the exchange rates for Bitcoins depend on Bitcoin businesses doing well. If we get to this point with respect to user (miner) education, then it is probably only a matter of time until people start to find it cumbersome to mine on a black-box pool and having to manually verify that they still have an agreeable transaction inclusion policy, when they can just mine on a GBT pool and configure things in their mining software. On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez r...@i-rme.es wrote: [...] We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. Bear with me, but this piece of rhetorics struck me. Why even mention those who think it's not harmful, when your next sentence states that their opinion should be ignored completely? Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
quote: On 6/16/14, Mike Hearn m...@plan99.net wrote: If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they don't collectively lemming us all off a cliff by doing that ;) Replace-by-fee doesn't imply the use of green addresses (there's other solutions to 0 conf transactions in that context, for example, scorched earth). And giving up the non-enforceable first-seen default mining policy doesn't mean giving up on the Bitcoin experiment either. If something means giving up on the Bitcoin experiment, then for sure it's not one mining policy or another, but the assumption that we should have one uniform mining policy. If we had a community where enough miners had their own opinion about the best mining policy, and expressed it by choosing an appropriate mining pool, then we would have better decentralized mining based on selfish motives of the miners, rather than based on an abstract thought of centralization is bad, so I will consider how much mining profit from qualitatively interchangable mining pools I'm willing to sacrifice in order to ease my centralization fears. Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
quote: Mike Hearn, why don't we just have all nodes report attempted double spends through the node network. No need to involve the miners at all really, or do your suggestion but also report the double spend attempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can be more sure that a double spend attack was not tried. Attacker would have to hold back second tx by 10-60 seconds and hope that that second tx (with higher fee) get's into a solved block before the first one. This forced delay time ought to make the attack less successful (but not impossible). What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding reporting double spends, this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an every double spend is a misbehaviour policy? Best regards, Isidor -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca christophe.bio...@gmail.com wrote: https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most of the pooling-centralization problems. This. There is no need to create anything new when GBT already exists. In my opinion. Unfortunately, it is opt-in, and GHash.io doesn't support it. Yep. As pools in general are not a part of the bitcoin protocol itself (nobody cares how the work happened), I am not sure how this can be forced. Also most miners don't care and don't do the work to set it up. To do transaction inclusion themselves, they'd need to run a full node, which is a bit more work and resources than just pointing hashpower at a stratum server. Also, yep. If the miners cared about 51% attack, they wouldn't join ghash in the first place. All the miners willingly accept the risk in joining the big pool. K. B. If you figure out a way to make GBT widely used (50% hashpower), kudos to you. On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) A pool owner cant decide which transactions not to include (but they can configure the minimum fee). A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
But miners dont want to run full nodes, its better to develop some SPV like that connects to some nodes. Also I believe that stratum mining protocol improves some performance things that GBT lacks. If a new protocol that requires blocks created by miners is developed and named in a cool way, miners could ask for protocol support to his favourite pool. El 17/06/2014 20:26, Karel Bílek k...@karelbilek.com escribió: On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca christophe.bio...@gmail.com wrote: https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most of the pooling-centralization problems. This. There is no need to create anything new when GBT already exists. In my opinion. Unfortunately, it is opt-in, and GHash.io doesn't support it. Yep. As pools in general are not a part of the bitcoin protocol itself (nobody cares how the work happened), I am not sure how this can be forced. Also most miners don't care and don't do the work to set it up. To do transaction inclusion themselves, they'd need to run a full node, which is a bit more work and resources than just pointing hashpower at a stratum server. Also, yep. If the miners cared about 51% attack, they wouldn't join ghash in the first place. All the miners willingly accept the risk in joining the big pool. K. B. If you figure out a way to make GBT widely used (50% hashpower), kudos to you. On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez r...@i-rme.es wrote: First of all I apologice due to the possible mistakes in my writing below, I am not a Bitcoin developer but I have some knowledge about it. We all know the recent news, Ghash pool controlling 51% of the hashrate. While some consider it a threat others think that is not harmful. The thing is that we have to do something to stop this from happening again. My proposal is to start thinking about miners that join a pool like independent miners and not slave miners, this includes creating a new mining protocol that does not rely on the pool sending the list of transactions to include in a block. Each individual miner has to collect transactions by his own and mine that, this can be achieved by running a full node or by running a SPV like node that ask other nodes for transactions. Once this protocol is developed and standarised we as a community could require all pools to use it (because its better, because is more trustless...), not by imposing it but by recommending it. Pool owners could send some instructions using this protocol to the miner about how many transactions to include per block (some pools want small blocks), how many 0 fee transactions to include, how much is the minimum fee per Kb to include transactions and some info about the Coinbase field in the block. This way is impossible to perform some of the possible 51% attacks: A pool owner cant mine a new chain (selfish mining) (pool clients have a SPV or full node that has checkpoints and ask other peers about the length of the chain) A pool owner can't perform double spends or reverse transactions (pool clients know all the transactions relayed to the network, they know if they are already included on a block) A pool owner cant decide which transactions not to include (but they can configure the minimum fee). A pool owner cant get all the rewards by avoiding other pools from mining blocks (Because the pool client knows the last block independently that is from his pool or other). The only thing that a 51% pool owner can do is to shut down his pool and drop the hashrate by 51% because he does not control the miners. If the pool owner owns all the hardware in the pool my proposal is not valid, if the pool clients dont use this protocol my proposal is not valid. I want to know if this is possible or its been developed or there is already a working protocol that works like this, also I want to read other people's ways to address this threat, thanks for reading. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data
[Bitcoin-development] Proposal: relax the IsStandard rules for P2SH transactions
Assuming there is rough consensus, I'll make this a pull request (see https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code changes). Now that we are finally starting to see the use of multi-signature and other more complicated transaction forms in applications I think it is time to open up the IsStandard transaction rules on the main Bitcoin network. There are two main risks to doing this: 1. The risk that one of the seldom-used opcodes has a not-yet-discovered chain-forking bug. I believe that risk to be very low; we have never seen such a bug on the test network (where all transaction forms are allowed) and have never found a bug after writing extensive unit tests. 2. The risk of opening up a denial-of-service attack (either bloat the blockchain or use an excessive amount of CPU time) via a very expensive-to-store-or-verify transaction. This proposal does not entirely eliminate IsStandard checks to mitigate the potential for DoS attacks. Proposal Allow any Script containing 15 or fewer signature operations as a pay-to-script-hash (P2SH) Script to be relayed and mined by the reference implementation. This should be a simple change to the AreInputsStandard() method in the reference implementation. Discussion -- P2SH Scripts are limited to 520 bytes, and are currently limited to one of the standard transaction forms on the main network. In practice that means you can currently encode a n-of-15 OP_CHECKMULTISIG which can be redeemed as a 'standard' transaction. Allowing any P2SH Script would allow an attacker to craft a single standard transaction output that requires on the order of 200 ECDSA signature checking operations to validate-- an order of magnitude more than is currently allowed. Therefore I am proposing that we keep the current 15-signature-checking-operations-per-transaction-output limit in place, but allow any combination of enabled Script opcodes. So, for example, you might have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using: ``` OP_IF 2 pubkey1 pubkey2 2 OP_CHECKMULTISIG OP_ELSE 2 pubkey3 pubkey4 pubkey5 3 OP_CHECKMULTISIG OP_ENDIF ``` (this would count as 5 signature operations) Restricting arbitrary Scripts to P2SH transaction types limits unspent transaction output set bloat in two ways: 1. The Scripts are not stored in UTXO set. 2. They are limited to 520 bytes by the Script rule on the amount of data that can be pushed onto the stack. The reference implementation's wallet will still only recognize P2SH transactions that use one of the standard transaction forms. To actually USE a new transaction form will require specialized wallets or specialized applications. -- -- Gavin Andresen Chief Scientist, Bitcoin Foundation https://www.bitcoinfoundation.org/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
Can two signed transactions using the same output as an input (ie, a double spend) be used to trigger a third transaction? It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary address if and only if someone could present proof that I signed more than 1 transaction using the same output. Thus, a merchant could trust that I would not attempt a double spend for a purchase of n m bitcoins. Can this type of transaction be expressed in Bitcoin's scripting language? Chaum had a similar feature in Digicash way back when...a double spend would let the second merchant compute the identity of the double spender and serve as proof of double spending. It didn't automate punishment though! My apologies if this has been discussed previously. - Message: 2 Date: Mon, 16 Jun 2014 16:50:41 -0400 From: Peter Todd p...@petertodd.org Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees To: Daniel Rice dr...@greenmangosystems.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net,Lawrence Nahum lawre...@greenaddress.it Message-ID: 20140616205041.GA21784@savin Content-Type: text/plain; charset=us-ascii On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote: True, that would work, but still how are you going to bootstrap the trust? TREZOR is well known, but in a future where there could be 100 different companies trying to release a similar product to TREZOR it seems like one company could corner the market by being the only one that is an accepted instant provider at most vendors. It seems to encourage monopoly unless there is a standard way to bootstrap trust in your signature. You can always use fidelity bonds, or as I called it at the time(1), Trusted identities: Lets suppose Alice has some bitcoins held at bitcoin address A. She wants to establish trust in the identity associated with the ECC keypair associated with A, for instance for the purpose of having other users trust her not to attempt to double spend. Since the trust she seeks is financial in nature, she can do this by valuing the identity associated with A, by delibrately throwing away resources. A simple way to do this would of course be to transfer coins to a null address, provably incurring a cost to her. A more socially responsible way would be for her to create a series of transactions that happen to have large, and equal, transaction fees. Bitcoin makes the assumption that no one entity controls more than 50% of the network, so if she makes n of these transactions consecutively, each spending m BTC to transaction fees, there is a high probability that she has given up at least n/2 * m BTC of value. This of course is all public knowledge, recorded in the block chain. It also increases the transaction fees for miners, which will be very important for the network in the future. Now Bob can easily examine the block chain, and upon verifying Alice's trust purchase, can decide to accept a zero-confirmation transaction at face value. If Alice breaks that promise, he simply publishes her signed transaction proving that Alice is a fraudster, and future Bob's will distrust Alice's trusted identity, thus destroying the value needed to create it. In effect, we now have a distributed green address system. Note that the second paragraph is seriously obsolete - better to either use announce-commit sacrifices, or much preferably, simple destruction of coins. (sacrifice to fees encourages mining centralization for obvious reasons) 1) [Bitcoin-development] Trusted identities, Apr 26th 2012, Peter Todd, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html Incidentally, my first post to this mailing list! -- 'peter'[:-1]@petertodd.org 58ca7ee3a40438ea5a96e499910638352468c6d69abdb226 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 685 bytes Desc: Digital signature -- End of Bitcoin-development Digest, Vol 37, Issue 27 *** -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] CoinJoin bounty fund question
Hoping that this is the right place for this, I am asking a question as to what happens with what is in the CoinJoin bounty fund address at: http://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk (a P2SH / multisignature address) I encouraged people to donate to it in late 2013 (around mid-November) after seeing some reddit discussions ~ I think the original one I saw was at http://www.reddit.com/r/Bitcoin/comments/1qmhkh/coinjoin_fundraising_drive/ Since that time I know it's been implemented in various places, such as things seen floating about the web with some relation to CoinJoin or another: such as: https://github.com/calafou/coinjoin and blockchain.info https://twitter.com/blockchain/status/402224010492006400/ | https://github.com/blockchain/Sharedcoin etc.. I'm curious what the CoinJoin bounty fund supports at this point and where it's intended to go (I assume, CoinJoin related stuff, but I'm interested to know a bit more detail). And if it will help fund other things I am curious about what those other things are too. Again, hopefully the bitcoin-development list is the right place for this question, I felt it would be better asked here rather than on twitter or similar. Respect, Odinn -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
I wrote a patch for string-based name extensions, circa 2011-2012. I agree that is preferable to unreadable bits, for reasons you cite. However, it was noted that extensions (or UUIDs etc.) would not be propagated around the network in addr messages, as service bits are. On Tue, Jun 17, 2014 at 3:57 AM, Wladimir laa...@gmail.com wrote: On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd p...@petertodd.org wrote: Alternately Wladimir J. van der Laan brought up elsewhere(2) the possibility for a wider notion of an extension namespace. I'm personally not convinced of the short-term need - we've got 64 service bits yet NODE_BLOOM is the first fully fleshed out proposal to use one - but it's worth thinking about for the long term Yes, as I said in the github topic (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a string-based name space for extensions. A new network version could add a command 'getextensions' to query the supported extensions, returning a list of extension strings or (extension,version) pairs. For BIPs some something like 'BIP0064' could be defined, but for an experiment for example 'experimental-getutxo'. This would be easy to implement and specify. Unlike with the 64 service bits it does not require (as much) central coordination to assign as there is no real danger of collisions. It takes the political aspect out of P2P network extensions, and gives more freedom to alternative implementations to experiment with their own extensions. And no more need for bitcoin core to drive what must be supported with increasing network versions. Wladimir -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
Not with current script, but there are mechanisms by which you can do a digital signature where signing two pieces of information reveals the ECDSA k parameter, thereby allowing anyone to recover the private key and steal the coins. Practically speaking, these are not very safe systems to use. For example, imagine accidentally loading up the same wallet on two machines or the wallet software crashing after signing and sending the transaction, and the user recreates sends on recovery. It also invalidates reasonably legitimate use cases for repeating addresses (in the absence of other solutions), and its not really possible to prevent people from sending multiple coins to the same address (which could then be stolen). On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote: Can two signed transactions using the same output as an input (ie, a double spend) be used to trigger a third transaction? It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary address if and only if someone could present proof that I signed more than 1 transaction using the same output. Thus, a merchant could trust that I would not attempt a double spend for a purchase of n m bitcoins. Can this type of transaction be expressed in Bitcoin's scripting language? Chaum had a similar feature in Digicash way back when...a double spend would let the second merchant compute the identity of the double spender and serve as proof of double spending. It didn't automate punishment though! My apologies if this has been discussed previously. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CoinJoin bounty fund question
On Tue, Jun 17, 2014 at 2:14 PM, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: Hoping that this is the right place for this, I am asking a question as to what happens with what is in the CoinJoin bounty fund address at: The correct place for more information is the Bitcointalk forum thread where it was announced: https://bitcointalk.org/index.php?topic=279249.0 cheers, -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] CoinJoin bounty fund question
On 06/17/2014 06:46 PM, Gregory Maxwell wrote: The correct place for more information is the Bitcointalk forum thread where it was announced: https://bitcointalk.org/index.php?topic=279249.0 Can anyone summarize the current status of the bounty? I see nothing definite about the bounty in that thread from the beginning of January 2014, other than that the multisig address continues to accumulate bitcoins. Meanwhile, on other mailing lists, I've seen some talk about paying a portion or the whole of the bounty to the Dark Wallet team. -Kristov -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
On 6/16/2014 8:09 AM, Daniel Rice wrote: What if we solved doublespends like this: If a node receives 2 transactions that use the same input, they can put both of them into the new block as a proof of double spend, but the bitcoins are not sent to the outputs of either transactions. They are instead treated like a fee and given to the block solver node. This gives miners the needed incentive and tools to end doublespends instead of being forced to favor one transaction over the other. Before considering a hard fork with unpredictable effects on the uncertainty window, it would be interesting to look at a soft fork that would directly target the goal of reducing the uncertainty window, like treating locally-detected double-spends aged T as invalid (see earlier message A statistical consensus rule for reducing 0-conf double-spend risk). If anything is worth a soft fork, wouldn't reducing the double-spend uncertainty window by an order of magnitude be in the running? Reducing the reasons that transactions don't get relayed, which actually seems to have a shot of happening pretty soon, would also make this kind of thing work better. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension
On 6/16/2014 8:48 AM, Mike Hearn wrote: In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won't be able to deal with this complexity: if we can't make native Bitcoin work well enough there, we're most likely to just lose that market or watch it become entirely centralised around a handful of payment processing companies. I have trouble seeing how could the real-time anonymous payments market can be cleanly separated from everything else. If trusted third parties become the norm for that market, there will inevitably be a huge overlap effect on other markets that bitcoin can serve best, even today. I don't see how any currency, any cash, can concede this market. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
