Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
Only messages between peers are encrypted, only during transit. Before sending a transaction to Node B you use his public key, so Node B has the key El 19/08/2014 17:05, Richard Moore m...@ricmoo.com escribió: If you encrypt all messages with an asymmetric cipher, how would each node make use of the blockchain in an encrypted form? Each node would be able to encrypt the data, but only the Bitcoin Core Dev could decrypt it? On Aug 19, 2014, at 5:49 AM, Raúl Martínez r...@i-rme.es wrote: Hi, I believe that all comunications should be encrypted by default, no matter that is public information (tx info), the only exception I would make would be block packets (to avoid increasing propagation time). I suggest that Bitcoin Core should generate a public/private key pair and share the public one with peers. This could provide privacy and integrity but not autentication. This way you can impersonate a bitcoin node (active mitm) but you cant just be passive and record all transactions send or recieved by an IP address. Today you can just watch for incoming/outgoing transactions to determine what tx are created in the Node, when you find one you can see the Bitcoin address inputs and outputs and track that person's bitcoins. As an example, SSH provides this kind of encryption, althogh Bitcoin Core should ignore fingerprint changes (caused due to reinstalls). Please feel free to disqus why this is not needed or why you like this idea. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- ___ 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
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
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
Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions
I believe that the Payment Protocol works that way, the merchant broadcast the Tx. El 10/06/2014 13:23, Chris D'Costa chrisjdco...@gmail.com escribió: I wonder if Raul is mistakenly under the impression that the transaction only reaches the Bitcoin network via Alice? In which case the premise of this attack is incorrect. *Chris D'Costa* Follow on Twitter: *@cjdcosta* *---* chris.dco...@meek.io (Meek) chris.dco...@sossee.com (Blog) chrisjdco...@gmail.com chris_dco...@me.com (Personal) chris.dco...@bitcoinassociation.be (Belgian Bitcoin Association) --- On 7 June 2014 00:02, Raúl Martínez r...@i-rme.es wrote: I dont know if this attack is even possible, it came to my mind and I will try to explain it as good as possible. Some transacions keep unconfirmed forever and finally they are purged by Bitcoin nodes, mostly due to the lack of fees. Example: - Alice is selling a pizza to Bob, Bob is now making the payment with Bitcoin. The main goal of this attack is to store a unconfirmed transaction send by Bob for a few days (it will not be included in the blockchain because it has no fee or due to other reason), Bob might resend the payment or might just cancel the deal with Alice. Bob forgets about that failed trade but a couple of days later, Alice, who has stored the signed transacion, relays the transaction to the network (or mines it directly with his own hashpower). Bob does not know what is happening, he believed that that transaction was canceled forever, he even does not remember the failed pizza deal. Alice has now the bitcoins and Bob does not know what happened with his money. - This might also work with the Payment Protocol because when using it Bob does not relay the transaction to the network, its Alices job to do it, Alice stores it and tells Bob to resend the payment, Bob creates another transaction (If has the same inputs as the first TX this does not work) (this one is relayed by Alice to the network). Alice comes back a couple of days later and mines with his hashrate the first transaction (the one she didnt relayed to the network). Alice now has two payments, Bob does not know what happened. --- I hope that I explained well this possible attack, I dont know if there is already a fix for this problem or if it is simply impossible to execute this kind of attack. Thanks for your time. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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] Possible attack: Keeping unconfirmed transactions
I dont know if this attack is even possible, it came to my mind and I will try to explain it as good as possible. Some transacions keep unconfirmed forever and finally they are purged by Bitcoin nodes, mostly due to the lack of fees. Example: - Alice is selling a pizza to Bob, Bob is now making the payment with Bitcoin. The main goal of this attack is to store a unconfirmed transaction send by Bob for a few days (it will not be included in the blockchain because it has no fee or due to other reason), Bob might resend the payment or might just cancel the deal with Alice. Bob forgets about that failed trade but a couple of days later, Alice, who has stored the signed transacion, relays the transaction to the network (or mines it directly with his own hashpower). Bob does not know what is happening, he believed that that transaction was canceled forever, he even does not remember the failed pizza deal. Alice has now the bitcoins and Bob does not know what happened with his money. - This might also work with the Payment Protocol because when using it Bob does not relay the transaction to the network, its Alices job to do it, Alice stores it and tells Bob to resend the payment, Bob creates another transaction (If has the same inputs as the first TX this does not work) (this one is relayed by Alice to the network). Alice comes back a couple of days later and mines with his hashrate the first transaction (the one she didnt relayed to the network). Alice now has two payments, Bob does not know what happened. --- I hope that I explained well this possible attack, I dont know if there is already a fix for this problem or if it is simply impossible to execute this kind of attack. Thanks for your time. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions
Alice does not intercept the transaction, she only saves it and expect that it will not be confirmed (because has 0 fee for example). Also using the Payment Protocol I believe that Alice is the only person that can relay Bob's transaction. Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki *When the merchant's server receives the Payment message, it must determine whether or not the transactions satisfy conditions of payment. If and only if they do, if should broadcast the transaction(s) on the Bitcoin p2p network.* 2014-06-07 0:11 GMT+02:00 Toshi Morita to...@peernova.com: From what I know, Alice does not know to which node Bob will broadcast the transaction. Therefore, Alice cannot intercept the transaction and prevent the rest of the network from seeing it. Toshi On Fri, Jun 6, 2014 at 3:02 PM, Raúl Martínez r...@i-rme.es wrote: I dont know if this attack is even possible, it came to my mind and I will try to explain it as good as possible. Some transacions keep unconfirmed forever and finally they are purged by Bitcoin nodes, mostly due to the lack of fees. Example: - Alice is selling a pizza to Bob, Bob is now making the payment with Bitcoin. The main goal of this attack is to store a unconfirmed transaction send by Bob for a few days (it will not be included in the blockchain because it has no fee or due to other reason), Bob might resend the payment or might just cancel the deal with Alice. Bob forgets about that failed trade but a couple of days later, Alice, who has stored the signed transacion, relays the transaction to the network (or mines it directly with his own hashpower). Bob does not know what is happening, he believed that that transaction was canceled forever, he even does not remember the failed pizza deal. Alice has now the bitcoins and Bob does not know what happened with his money. - This might also work with the Payment Protocol because when using it Bob does not relay the transaction to the network, its Alices job to do it, Alice stores it and tells Bob to resend the payment, Bob creates another transaction (If has the same inputs as the first TX this does not work) (this one is relayed by Alice to the network). Alice comes back a couple of days later and mines with his hashrate the first transaction (the one she didnt relayed to the network). Alice now has two payments, Bob does not know what happened. --- I hope that I explained well this possible attack, I dont know if there is already a fix for this problem or if it is simply impossible to execute this kind of attack. Thanks for your time. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] About the small number of bitcoin nodes
About the small number of bitcoin nodes: Hi, I read the message that Mike Hearn sent to this mailing list some days ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes. As an owner of two Bitcoin Nodes, one in my home computer and one in a dedicated server, I believe I can contribute with some of my thoughts and ideas: - Allow users to view the bandwith used by Bitcoin Core: This is available in the Bitcoin Core GUI (btw, when the computer is restarted the data gets reseted) but I cant find it in the bitcoind commandline, people that run nodes want to see the amount of GB that they have donated to the network. - Educate users about the correct setup of a bitcoin node: Add a page in the bitcoin.org website with a tutorial about running Bitcoin Core with the ports opened, about runing bitcoind, etc. This guide shoud not be for regular users but for advanced ones. - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first start: The first time the software should create a default config file with a random RCP password and username (user can change it later) and the config file should be commented so the user can know how to change configurations. This is very useful in setups without GUI, for example in Ubuntu Server. - bitcoind and Bitcoin Core should be in Linux repos: People want to type yum install bitcoind or apt-get install bitcoind and install bitcoin. No one wants to follow a tutorial made by somewho saying that you have to add external repos to install bitcoin in your server. For example Electrum has been added to Ubuntu software center recently. Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu Server repos. - Create a grafical interface for bitcoind on Linux servers: Create a command, for example bitcoind show that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say grafical interface I mean like top command, an interface made out of characters in ASCII. - Split Bitcoin Wallet from Bitcoin Node: I believe that this is planned, some people want to help the network and others want to keep a wallet, someones want both. With bitcoind you can use the option disablewallet=1 that allows to save some memory. - Inform users if 8333 port is closed: That should be more visible, I dont mean an alert or warning but some icon. - Keep connections if bitcoind is restarted: I noticed that if I restart bitcoind (to apply new config) my reset to 0 and take some hours to rise up to ~40. I believe that my peers should notice that I am down for less than ~15 minutes and try to connect again faster. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] About the small number of bitcoin nodes
About the small number of bitcoin nodes: Hi, I read the message that Mike Hearn sent to this mailing list some days ago (2014-04-07 11:34:43) related to the number of bitcoin full nodes. As an owner of two Bitcoin Nodes, one in my home computer and one in a dedicated server, I believe I can contribute with some of my thoughts and ideas: - Allow users to view the bandwith used by Bitcoin Core: This is available in the Bitcoin Core GUI (btw, when the computer is restarted the data gets reseted) but I cant find it in the bitcoind commandline, people that run nodes want to see the amount of GB that they have donated to the network. - Educate users about the correct setup of a bitcoin node: Add a page in the bitcoin.org website with a tutorial about running Bitcoin Core with the ports opened, about runing bitcoind, etc. This guide shoud not be for regular users but for advanced ones. - bitcoind and Bitcoin Core should create a bitcoin.conf file on the first start: The first time the software should create a default config file with a random RCP password and username (user can change it later) and the config file should be commented so the user can know how to change configurations. This is very useful in setups without GUI, for example in Ubuntu Server. - bitcoind and Bitcoin Core should be in Linux repos: People want to type yum install bitcoind or apt-get install bitcoind and install bitcoin. No one wants to follow a tutorial made by somewho saying that you have to add external repos to install bitcoin in your server. For example Electrum has been added to Ubuntu software center recently. Bitcoin Core an bitcoind should be on CentOS, Debian, Ubuntu and Ubuntu Server repos. - Create a grafical interface for bitcoind on Linux servers: Create a command, for example bitcoind show that shows a nice summary in your Terminal (Console) with all the data that a node administrator wants to know. When I say grafical interface I mean like top command, an interface made out of characters in ASCII. - Split Bitcoin Wallet from Bitcoin Node: I believe that this is planned, some people want to help the network and others want to keep a wallet, someones want both. With bitcoind you can use the option disablewallet=1 that allows to save some memory. - Inform users if 8333 port is closed: That should be more visible, I dont mean an alert or warning but some icon. - Keep connections if bitcoind is restarted: I noticed that if I restart bitcoind (to apply new config) my reset to 0 and take some hours to rise up to ~40. I believe that my peers should notice that I am down for less than ~15 minutes and try to connect again faster. Thanks for reading -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
