[Bitcoin-development] Proposal: allocate 8 service bits for experimental use
For my replace-by-fee implementation(1) I used service bit 26 to let preferential peering work so that replace-by-fee nodes could easily find each other. Of course, that's a temporary/experimental usage that can be dropped after wider adoption, so I included the following comment: // Reserve 24-31 for temporary experiments NODE_REPLACE_BY_FEE = (1 << 26) Service bits are never a guaranteed thing anyway, so occasional collisions can and should be tolerated by applications using these experimental service bits. 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. 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1 2) https://github.com/bitcoin/bitcoin/pull/4351#issuecomment-46272958 -- 'peter'[:-1]@petertodd.org 58ca7ee3a40438ea5a96e499910638352468c6d69abdb226 signature.asc Description: 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] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd 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
Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
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. -- 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
On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock 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. Come on, this is only sent over the line at connection time at most once. No need to overdesign a scheme here. Anyhow, if we like to bike-shed so much: - UUIDs are 16 bytes -- most human-recognizable strings are shorter. And they're ugly to use as well. - OIDs need central and hierarchical coordination, just what we're trying to avoid. 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] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir wrote: > On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock > 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 even
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" 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" 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" 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" wrote: > Because he cant change the coinbase once the proof of work is done. > El 17/06/2014 15:58, "Ron Elliott" 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" 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
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. On Tue, Jun 17, 2014 at 4:57 AM, Raúl Martínez 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 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 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 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] Incentivizing the running of full nodes
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/16/2014 07:00 PM, Justus Ranvier wrote: >> There can be multiple independent transport networks for Bitcoin. >> >> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree >> patch). >> >> As long as multihomed hosts that act as bridges then information >> will propagate across all of them. -- Justus Ranvier >> - sent with R2Mail2 >> >> - Original Message - From: Matt Whitlock >> >>> Now another concern: won't this proposal increase the likelihood >>> of a network split? The free-market capitalist nodes will want to >>> charge their peers and will kick and ban peers that don't pay up >>> (and will pay their peers to avoid being kicked and banned >>> themselves), whereas the socialist nodes will want all of their >>> peers to feed them transactions out of the goodness of their >>> hearts and will thus necessarily be relegated to connecting only >>> to other altrustic peers. Thus, the network will comprise two >>> incompatible ideological camps, whose nodes won't interconnect. If the technical development emanating from the proposal follows a design which ensures that the notion of whether or not someone were to donate remains voluntary in nature (there's never any requirement that someone donate to anyone, but incentives can be made), then I don't feel that network split would be an issue, because it's just an issue of choice. Justus Ranvier suggested a system which would naturally include pay-to-play networks, and not just free P2P networks. The question of how to limit the number of entries the system registers in the framework of the proposed 'decentralizing lottery' would be fairly straightforward, there could one entry for a distinct period of time (say 30 days as an example) for anyone who meets the suggested criteria of: "those running full nodes (Bitcoin Core (...)), processing their change and txouts through Core, would be provided incentives in the form of a 'decentralizing lottery' such that all participants who are running nodes and donating no matter how infrequently (and no matter who they donate to) will be entered in the 'decentralizing lottery,'" for a chance to receive "the 'award amounts'" In my mind I imagine that the smart property qualities of Bitcoin may eventually enable people to represent what sort of time and energy they are putting into maintaining the network, so that rather solely a currency aspect, people who have done something collaborative with each other to help advance or develop Bitcoin would be able to show in their donations field that they have a smart property, which could be also expressed in equivalence terms as a value of a certain amount of btc, would also be able to have the smart property representing their voluntary efforts represented and given a voice in the blockchain, whether or not they want to participate in such a 'decentralizing lottery.' In point of fact, I contemplate that all aspects of this, at least ideally (to me) should be voluntary, such that if a person is donating through this system, that is voluntary, if they wish to have their donations result in a chance at winning the 'decentralizing lottery,' that is voluntary / an option, and if they win, they would have the option to accept the winnings or return them (the bitcoin 'award amount') back to the network. > > Also consider that currently there are many people have already > demonstrated a willingness to donate bandwidth and resources to the > public by running nodes, so those people aren't going to disappear. > Those who are already dedicated to running nodes will likely (mostly) remain, but any ideas reaching technical development and reality as a result of this concept would be intended to help grow that base by bringing in persons who might not otherwise be as interested to do so. > They could operate mixed-mode nodes, with a fraction of the allowed > incoming connections reserved for free peer, with free connections > might be limited in terms of time duration. Bitcoin-accepting > brick-and-mortars would probably allow free access to anyone connected > to their internal wifi to facilitate people wanting to pay. That's a great idea. The incentives could certainly go beyond just pointing to Bitcoin Core. Giving is important to everyone. > > Crowdfunded free bridges, assurance contracts, etc are all other ways > to let people get into the network with no upfront cost. > > > - -- > Support online privacy by using email encryption whenever possible. > Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJTn1mwAAoJEMP3uyY4RQ21ePwIALpMV/GDpAyD4SeL6hWi32vQ > 197YD1LPuLWrEbUs/+gl1Sk2gIsWWlq/o86KcP7Cn4fZdBAKEiF5RpQ6iPsO2+bj > JR0W/EbgUyzIhYaxFysCzQ1HPzQx+0a2vHn/6FsB7YMha8gvxviF7InDEwcfxbok > o0QS5SeYWryp5mH7IokC6fLYsAPmiueugPVRSD/l8IRFYWVFS9nB+XAR1PWAdYSQ > Xyzu9oyPwlKAjYKxl4XHYB4DofacS89DpW
Re: [Bitcoin-development] Proposals for improving Bitcoin mining decentralization
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca 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 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
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" escribió: > On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca > 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 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 L
[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 > Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized >instant confirmation guarantees > To: Daniel Rice > Cc: Bitcoin Dev ,Lawrence >Nahum > 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 wrote: > On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd 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 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] Proposal: relax the IsStandard rules for P2SH transactions
On Tue, Jun 17, 2014 at 03:40:36PM -0400, Gavin Andresen wrote: > 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). I'm also working on a very similar patch with some additional protections to ensure forwards compatibility during soft-fork upgrades and provide protections against transaction malleability. > 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. Agreed. > 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. Agreed. The script execution code is probably in the 99.9th percentile of open source code in terms of code review. > 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. 3. The risk that non-upgraded miners produce invalid blocks after a soft-fork due to them mining transactions that are now invalid. 4. Transaction malleability. > 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. In addition to these changes the soft-fork-safe patch I'm working on would do the following: a) Define an opcode whitelist of soft-fork-safe opcodes. This whitelist includes every opcode but the invalid opcodes, and most importantly, the OP_NOPx opcodes that may be redefined in a future soft-fork with new behavior. This rule, along with rejecting transations with unknown nVersion's, ensures that a miner still running an old version of Bitcoin Core will only mine transactions that the new version of Bitcoin Core considers valid. b) Consider scripts that leave extra items on the stack after execution to be non-standard. As per Pieter Wuille's BIP62 "Dealing with malleability" extra scriptSig pushes are a malleability source. If adding extra pushes causes a transaction to be invalid, scriptPubKeys will in most cases be automatically non-malleable. This change I've already submitted as a separate pull-req: https://github.com/bitcoin/bitcoin/pull/4311 I'd be happy to add the above to your existing patch and submit the pull-req for you. -- 'peter'[:-1]@petertodd.org 407e409a626b01bfb275cb88768ca74f3ea9bd87b2e7e1d9 signature.asc Description: 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] 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
Re: [Bitcoin-development] Proposal: allocate 8 service bits for experimental use
On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik wrote: > 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. Thanks for letting me know, I didn't remember your patch. Ugh, yes, propagating all extensions in `addr` messages is not how I imagined this to work. But then there would need to be an alternative way to discover nodes that offer a certain extension. Alas, this moves it from a straightforward and common sense change to a significant change to the protocol. 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
