Re: [bitcoin-dev] Bitcoin XT 0.11A
On 08/16/15 23:22, Andrew LeCody via bitcoin-dev wrote: Cam, your scenario makes no sense. 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version string. 2. Encourage all miners to false vote for the Bitcoin XT fork. This would obliterate any confidence in Bitcoin Core. I seriously doubt anyone would actually be ok with a pull request implementing this. Bitcoin Core doesnt have to do this. It is rational if you have 25% of hash power (or if you believe 25% of hash power is doing this) to do this. If a 75% hardfork target is reached, and 25% of the hashpower doesnt allow the hardfork, and the hardfork is strictly more permissive than the original (ie it is essentially a reverse softfork - there are no previously valid blocks which are not still valid), then the miners who voted for the fork would be constantly generating blocks which are soft-forked-out by the 25% and non-supporting miners. I believe this was pointed out to the Bitcoin XT folks weeks ago, but apparently did not sway the decision to use 75% and a (as far as I can tell?) strictly more permissive hardfork. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Incentives to run full nodes
On Aug 17, 2015 5:29 PM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: From the point of view of a wallet, it's not very secure to use Hearn-style SPV mode, and volunteers running full nodes doesn't help things. Sybil attacking the IP address space is pretty easy in comparison to aquiring hashing power sufficient to create false confirmations, so any attacker able to do the former will likely be running the full node you're connecting too anyway. Ultimately, Hearn-style SPV is a close approximation to just trusting anyone with a non-trivial amount of hashing power. (and getting that is surprisingly easy, e.g. w/ SPV mining) Can you explain how the spv node fails against an attacker with a non-trivial amount of hash power where a full node doesn't? To attack an spv wallet that is waiting for 6 or 10 confirmations, you would not only need to Sybil them but also summon a massive amount of hashing power to create a chain of headers (while forgoing the opportunity to mine valid blocks with that hash power). But could someone with that much hash power not Sybil a full node and give them a chain for valid blocks (but on an orphan fork)? The failure model doesn't seem specific to spv to me. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Dave, ³ highly skilled psychological warfare agents ..² Paranoia, much? Or perhaps the ³enemies of Bitcoin are just sitting patiently, waiting for it to collapse in time due to its internal contradictions. From: Dave Scotese via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org Reply-To: Dave Scotese dscot...@litmocracy.com Date: Tuesday, 18 August 2015 12:37 pm To: Bitcoin Dev bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT Three things: 1) Hostility is generally the result of perceived hostility. If you assume the best intentions of another person, you will eventually find yourself in one of two places. Either you will find truth with that person (becuase they are also seeking it), or you will drive them away (because you will ask questions that can't be answered by someone trying to deceive). 2) The Wiki says The current Core developers are Wladimir J. van der Laan, Gavin Andresen, Jeff Garzik, Gregory Maxwell, and Pieter Wuille. I've seen no hostility from any of these people. 3) The people who are threatened by Bitcoin aren't stupid enough to ignore #1. Can anyone imagine that they have not hired highly skilled psychological warfare agnts to do everything they can to help assault what we decentralization enthusiasts have been working for? About #2: I'm actually blind to hostility, and that is an intentional affectation in response to my recognition of #1 and #3 together. If you feel another person has expressed a bad idea, just ignore it. If you feel they might be misleading others, post a reply about what you know to clear up any possible misconceptions. There is no point in identifying individuals who are being hostile, or pointing out hostility, or being divisive. Let the rest of us recognize it on our own. Maybe send something like what I'm writing now. PS: If anyone is interested in conspiracy theories, I had written this into my gmail compose window and (presumably) hit a wrong key which caused the thread to be marked as spam and deleted my whole reply. It hadn't even saved a draft. I've never seen gmail not save a draft before. On Mon, Aug 17, 2015 at 9:55 AM, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I should add that in the interest of peace and goodwill, I extend an offer to both Mike and Gavin to make their grievances heardbut only on the condition that we make a good effort to avoid misrepresentation and misreading of the other side¹s intentions. On Aug 17, 2015, at 9:37 AM, Eric Lombrozo elombr...@gmail.com wrote: On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin? Let users decide what Bitcoin is or isn't. FWIW, I don¹t think what theymos did is very constructive.I understand his positionbut it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike¹s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist. Regardless of the technical merits of XT, the fact that we¹ve never done a hard fork before, not even for things some other devs have wantedand not due to any malice on anyone¹s part but because simply that¹s just the nature of decentralized consensus with well-defined settlement guaranteesthis is the problem - Mike and Gavin think they¹re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin¹s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive. But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike¹s hand, and that¹s the problem. The whole block size thing is too nuanced and too easily spun simplistically. It¹s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as ³obstructionism² and it¹s too easy to spin bigger blocks as ³scalability² because most of the people can¹t tell the fucking difference. The fact is most of the people don¹t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It¹s beyond ironic. If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatmentBitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested
Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining
The traffic between the pool server and individual hashers is far busier than 50kB/30s. If their bandwidth is so limited, hashers would have switched to other pools already. All these data may prove is they have very bad mining codes. For example, their hashers may not be required to update the transaction list regularly. I don't think they are struggling. They are just too lazy or think that's too risky to improve their code. After all, they are generating half million USD per day and a few seconds of downtime would hurt. By the way, vast majority of the full blocks (0.99MB) on the blockchain are generated by Chinese pools. Luv Khemani via bitcoin-dev 於 2015-08-17 04:42 寫到: Hi all, I previously mentioned in a post that i believe that technically nodes are capable of handling blocks an order of magnitude larger than the current blocksize limit, the only missing thing was an incentive to run them. I have been monitoring the blockchain for the past couple of weeks and am seeing that even miners who have all the incentives are for whatever reason struggling to download and validate much smaller blocks. The data actually paints a very grim picture of the current bandwidth/validating capacity of the global mining network. See the following empty blocks mined despite a non-trivial elapsed time from the previous block just from the past couple of days alone (Data from insight.bitpay.com): EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined by 370165 29s 720784 Antpool 370160 31s 50129 BTCChinaPool 370076 49s 469988 F2Pool 370059 34s 110994 Antpool 370057 73s 131603 Antpool We have preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining. The most glaring case is Block 370057 where despite 73s elapsing and the preceding block being a mere 131KB, the miner is unable to download/validate fast enough to include transactions in his block. Unless ofcourse the miner is mining empty blocks on purpose, which does not make sense as all of these pools do mine blocks with transactions when the elapsed time is greater. This is a cause for great concern, because if miners are SPV mining for a whole minute for 750KB blocks, at 8MB blocks, the network will just fall apart as a significant portion of the hashing power SPV mines throughout. All a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. Yes, these pools deserve to lose money in that event, but the impact of reorgs and many block orphans for anyone not running a full node could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes. I simply don't see the XT fork having any chance of surviving if SPV nodes are unreliable. And if these pools go out of business, it will lead to even more mining centralization which is already too centralized today. Can anyone representing these pools comment on why this is happening? Are these pools on Matt's relay network? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Nobody is going to click that... I guess I am nobody. Here's a copy of the text:- *Dynamically Controlled Bitcoin Block Size Max Cap http://upalc.com/maxblocksize.php* *Assumption*: This article is for those, who already understand the bitcoin protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100 http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf. Satoshi's opinion regarding block size can be found here https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366. I will be directly going into the solution without explaining the problem in details. *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 block each full node does a calculation to find the next target. We will do just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size, which is 1 MB for now. If it is found that more than 90% blocks in the last difficulty period is higher than 90% of the maximum block size, then double the maximum block size. If not, then calculate what % of blocks in the last difficulty period is less than 50% of the maximum block size. If it is higher than 90%, then half the maximum block size. If none of the above condition satisfies, keep the maximum block size as it is. Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps to avoid the calculation mistake if some of the last few blocks get orphaned. *Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. *Other Solutions of this Problem*:- Making Decentralized Economic Policy http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf - by Jeff Garzik Elastic block cap with rollover penalties https://bitcointalk.org/index.php?topic=1078521 – by Meni Rosenfeld Increase maximum block size https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki - by Gavin Andresen Block size following technological growth https://gist.github.com/sipa/c65665fc360ca7a176a6 - by Pieter Wuille The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments https://lightning.network/lightning-network-paper.pdf - by Joseph Poon Thaddeus Dryja Please share your opinion regarding this solution below. For mail communication, feel free to write me at bitcoin [at] upalc.com. On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: I have tried to solve the maximum block size debate, depending on the previous block size calculation. Requesting for comment - http://upalc.com/maxblocksize.php ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
Am 15.08.2015 um 19:43 schrieb Satoshi Nakamoto via bitcoin-dev: I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork. The developers of this pretender-Bitcoin claim to be following my original vision, but nothing could be further from the truth. When I designed Bitcoin, I designed it in such a way as to make future modifications to the consensus rules difficult without near unanimous agreement. Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has to agree on a change, and they have to do it without being forced or pressured into it. By doing a fork in this way, these developers are violating the original vision they claim to honour. They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism. If two developers can fork Bitcoin and succeed in redefining what Bitcoin is, in the face of widespread technical criticism and through the use of populist tactics, then I will have no choice but to declare Bitcoin a failed project. Bitcoin was meant to be both technically and socially robust. This present situation has been very disappointing to watch unfold. Satoshi Nakamoto That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. - oliver ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Interesting. I am writing down something similar. Will share soon. Upal Chakraborty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr: I have tried to solve the maximum block size debate, depending on the previous block size calculation. Requesting for comment - http://upalc.com/maxblocksize.php ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Announcing Not-BitcoinXT https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt This version can be used to protect the status quo until real technical consensus is formed about the blocksize. ...real technical consensus... You mean the bunch of self-proclaimed Bitcoin wizards, who decided they have the right to tell everybody what to do, and who never got to grow up and are now angry at the world for not listening to them anymore? That technical consensus? Bitcoin is decentralized, but you are only allowed to do what we tell you to do. It's our pet project, we wrote code for it! That's what it all boils down to, all these dirty games of calling XT an alt-coin and censoring its posts, pretending to be Satoshi, sabotaging XT switch, etc.: How dare they not listen to Us The Smartest anymore?!!! Pathetic. The history will roll over you in a blink. The harder you try, the quicker it will go. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. Why should we block any email address? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
Am 17.08.2015 um 13:44 schrieb Jorge Timón: On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. Why should we block any email address? To avoid such discussions. - oliver ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining
It could be laziness but i doubt it, especially when the business is so competitive and margins ever shrinking.Half a million dollars in revenue mean little if your running costs are also in the same region. Also apologies for the bad formatting, outlook must have screwed it up. EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined by370165 29s 720784 Antpool370160 31s 50129 BTCChinaPool370076 49s 469988 F2Pool370059 34s 110994 Antpool370057 73s 131603 Antpool Date: Mon, 17 Aug 2015 05:15:15 -0400 From: jl2...@xbt.hk To: l...@hotmail.com CC: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining The traffic between the pool server and individual hashers is far busier than 50kB/30s. If their bandwidth is so limited, hashers would have switched to other pools already. All these data may prove is they have very bad mining codes. For example, their hashers may not be required to update the transaction list regularly. I don't think they are struggling. They are just too lazy or think that's too risky to improve their code. After all, they are generating half million USD per day and a few seconds of downtime would hurt. By the way, vast majority of the full blocks (0.99MB) on the blockchain are generated by Chinese pools. Luv Khemani via bitcoin-dev 於 2015-08-17 04:42 ��到: Hi all, I previously mentioned in a post that i believe that technically nodes are capable of handling blocks an order of magnitude larger than the current blocksize limit, the only missing thing was an incentive to run them. I have been monitoring the blockchain for the past couple of weeks and am seeing that even miners who have all the incentives are for whatever reason struggling to download and validate much smaller blocks. The data actually paints a very grim picture of the current bandwidth/validating capacity of the global mining network. See the following empty blocks mined despite a non-trivial elapsed time from the previous block just from the past couple of days alone (Data from insight.bitpay.com): EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined by 370165 29s 720784 Antpool 370160 31s 50129 BTCChinaPool 370076 49s 469988 F2Pool 370059 34s 110994 Antpool 370057 73s 131603 Antpool We have preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining. The most glaring case is Block 370057 where despite 73s elapsing and the preceding block being a mere 131KB, the miner is unable to download/validate fast enough to include transactions in his block. Unless ofcourse the miner is mining empty blocks on purpose, which does not make sense as all of these pools do mine blocks with transactions when the elapsed time is greater. This is a cause for great concern, because if miners are SPV mining for a whole minute for 750KB blocks, at 8MB blocks, the network will just fall apart as a significant portion of the hashing power SPV mines throughout. All a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. Yes, these pools deserve to lose money in that event, but the impact of reorgs and many block orphans for anyone not running a full node could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes. I simply don't see the XT fork having any chance of surviving if SPV nodes are unreliable. And if these pools go out of business, it will lead to even more mining centralization which is already too centralized today. Can anyone representing these pools comment on why this is happening? Are these pools on Matt's relay network? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
I have tried to solve the maximum block size debate, depending on the previous block size calculation. Requesting for comment - http://upalc.com/maxblocksize.php ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Nobody is going to click that... On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote: I have tried to solve the maximum block size debate, depending on the previous block size calculation. Requesting for comment - http://upalc.com/maxblocksize.php ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9
While Peter Todd's public mention on social media was likely meant to be disparaging, I'll take the contribution of adding 'data mining' to the title in future updates of the draft - thank you. It might be ironic that he posted the remark on Twitter, where his message will be aggregated and sold by twitter to data miners. Twitter made $48m last year from selling data to data miners, at a 95% growth rate on year-on-year basis. It has since spent $130m on buying a data mining business who specialise in understanding how to mine data in order to grow this part of their business. It is one of their more profitable sideshows. On Mon, Aug 17, 2015 at 7:40 PM, Btc Drak btcd...@gmail.com wrote: You didnt reply to the list, I had emailed you privately. On Mon, Aug 17, 2015 at 7:22 PM, Ahmed Zsales ahmedzsale...@gmail.com wrote: @btc Drak, noted, thanks. 1. Updated - removed reference to self ascribed [104] https://drive.google.com/file/d/0BwEbhrQ4ELzBX3hCekFRSUVySWs/view?usp=sharing @Angel Leon 2. Privacy issues are clearly covered. On Mon, Aug 17, 2015 at 6:48 PM, Btc Drak btcd...@gmail.com wrote: You cannot assign your own bip numbers. You have to use the form BIP-myproposal On Mon, Aug 17, 2015 at 5:39 PM, Ahmed Zsales via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hello, Here we propose a long-term solution to replace mining rewards and transactions fees. BIP [104] is currently a discussion draft only. https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing Views and feedback welcome. Regards, Ahmed ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
The only bigblock patch you want is actually available here : https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org a écrit : One of the comments made by the mining pools is that they won't run XT because it is experimental. Has there been any consideration to making available a version of XT with only the blocksize changes? The least experimental version would be one that makes the absolute minimum changes to core. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes. This saves creating a new function. Without the consensus measuring code, the patch would be even easier. Satoshi's proposal was just a block height comparison (a year in advance). The state storing code is also another complication. If the standard counting upgrade system was used, then no state would need to be stored in the database. On Wed, Jul 1, 2015 at 11:49 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (My replies below) On 06/26/2015 06:47 AM, Tier Nolan wrote: On Thu, Jun 25, 2015 at 3:07 PM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: The hard-cap serves the purpose of a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case. True. Yep. BIP 100 and 101 could be combined. Would that increase consensus? Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is superior to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam. At least, at this stage the things are in a BIP process. If the BIP 100 and BIP 101 would be combined, what would that look like on paper? - Miner vote threshold reached - Wait notice period or until earliest start time - Block size default target set to 1 MB - Soft limit set to 1MB - Hard limit set to 8MB + double every 2 years - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum) Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks. Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size. Legacy clients would remain in the network until 80% of miners vote to raise the limit and a miner produces a 1MB block. If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it. The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= =rtTH -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT 0.11A
Wouldn't that require a fork that lasts for more than 100 blocks? On Mon, Aug 17, 2015, 01:43 Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There are a few ways: here is my favorite (for the moment). 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT' Even more direct: use coinbase outputs of XT blocks to create those outputs, as they can't by definition be on the Bitcoin chain. If you can't get those, using coinbase outputs of Bitcoin blocks to create definitely Bitcoin-only outputs, and then spend the inputs to those transactions again on the XT chain. This isn't quite as good, as a big reorg on the XT chain could in theory spend them, but it's a close second. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03 cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90= =OD56 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
I've been sharing a similar solution for the past 2 weeks. I think 2016 blocks is too much of a wait, I think we should look at the mean block size during the last 60-120 minutes instead and avert any crisis caused by transactional spikes that could well be caused by organic use of the network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network starts working as imagined, XYZ startup really kicks ass and succeeds in a couple of major cities with major PR push) Pseudo code in Python https://gist.github.com/gubatron/143e431ee01158f27db4 My idea stems from a simple scalability metric that affects real users and the desire to use Bitcoin: Waiting times to get your transactions confirmed on the blockchain. Anything past 45mins-1 hour should be unnacceptable. Initially I wanted to measure the mean time for the transactions in blocks to go from being sent by the user (initial broadcast into mempools) until the transaction was effectively confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins) When blocks get full, people start waiting unnaceptable times for their transactions to come through if they don't adjust their fees. The idea is to avoid that situation at all costs and keep the network churning to the extent of its capabilities, without pretending a certain size will be right at some point in time, nobody can predict the future, nobody can predict real organic usage peaks on an open financial network, not all sustained spikes will come from spammers, they will come from real world use as more and more people think of great uses for Bitcoin. I presented this idea to measure the mean wait time for transactions and I was told there's no way to reliably meassure such a number, there's no consensus when transactions are still in the mempool and wait times could be manipulated. Such an idea would have to include new timestamp fields on the transactions, or include the median wait time on the blockheader (too complex, additional storage costs) This is an iteration on the next thing I believe we can all agree is 100% accurately measured, blocksize. Full blocks are the cause why many transactions would have to be waiting in the mempool, so we should be able to also use the mean size of the blocks to determine if there's a legitimate need to increase or reduce the maximum blocksize. The idea is simple, If blocks are starting to get full past a certain threshold then we double the blocksize limit starting the next block, if blocks remain within a healthy bound, transaction wait times should be as expected for everyone on the network, if blocks are not getting that full and the mean goes below a certain threshold then we half the maximum block size allowed until we reach the level we need. Similar to what we do with hashing difficulty, it's something you can't predict, therefore no fixed limits, or predicted limits should be established. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fees and the block-finding process
On 12.08.15 11.45, Jorge Timón via bitcoin-dev wrote: 1) Potential indirect consequence of rising fees. 2) Software problem independent of a concrete block size that needs to be solved anyway, often specific to Bitcoin Core (ie other implementations, say libbitcoin may not necessarily share these problems). I don't think rising fees is the issue. Imagine that the government is worried because air lines are selling tickets cheaply and may run themselves out of business. So their solution is passing a new law that says only one commercial air plane is allowed to be in the air at any given time. This should help a ticket market to develop and prevent air lines from giving away almost free tickets. In this way the government can protect the air lines from themselves. I would not classify all issues that would come out of this as potential indirect consequences of rising ticket prices. It would just make air travel unusable. That's the problem we may face in the short term. It would be unwise to go all-in on a solution that doesn't exist yet, which may or may not arrive in time, and may or may not do the job that is needed. We need to use the solution we already have so that we can get by in the short term. I don't think mining pools will immediately make blocks as big as possible if the hard limit is raised. Remember that mining pools had to be coaxed into increasing their block size. Mining pools were making small blocks to reduce the rate of orphaned blocks. Block propagation is faster today, but this issue still exists. You need a lot of transaction fees to make up for the danger of losing 25 BTC. Many pools don't even pay out transaction fee income to their miners. -- Regards, Geir H. Hansen, Bitminter mining pool ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so. This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone. We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix. Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!? I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really. Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before. We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk. I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want. Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right. On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect. Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)? From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead. Nobody
Re: [bitcoin-dev] Bitcoin XT 0.11A
Or can’t you create a transaction that’s still within the op count and sig ops limits but is larger than 1MB? On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Wouldn't that require a fork that lasts for more than 100 blocks? On Mon, Aug 17, 2015, 01:43 Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There are a few ways: here is my favorite (for the moment). 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT' Even more direct: use coinbase outputs of XT blocks to create those outputs, as they can't by definition be on the Bitcoin chain. If you can't get those, using coinbase outputs of Bitcoin blocks to create definitely Bitcoin-only outputs, and then spend the inputs to those transactions again on the XT chain. This isn't quite as good, as a big reorg on the XT chain could in theory spend them, but it's a close second. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03 cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90= =OD56 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I haven't run any statistics or simulations, but I'm concerned that the interplay between the random distribution of transaction arrival and the random distribution of block times may lead to false signals. You could just take the average of all the block sizes for the last 2016 window. If average of last 2016 50% of the limit, then increase by 6.25% Otherwise, decrease by 6.25% This means that the average would be around 50% of the limit. This gives margin to create larger blocks when blocks are happening slowly. A majority of miners could force the limit upwards by creating spam but full blocks. It could be coupled with a hard limit that grows at whatever is seen as the maximum reasonable. This would be both a maximum and a minimum. All of these schemes add state to the system. If the schedule is predictable, then you can check determine the maximum block size purely from the header and coinbase. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Hi, If you want to write such baseless acusations and inflamatory phrases, please do it somewhere else. We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect. Nobody should be forced to do anything. People like you will not force me or anyone else to run code for your controversial hard fork just because you think the future will be bright with huge blocks. Just like the developers will not force you to continue running code implementing the current consensus rules. The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities. Valiz În data de L, 17.8.15, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org a scris: Subiect: Re: [bitcoin-dev] Annoucing Not-BitcoinXT Către: jyel...@toothandmail.com, bitcoin-dev@lists.linuxfoundation.org Data: Luni, 17 August 2015, 13:09 Announcing Not-BitcoinXT https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt This version can be used to protect the status quo until real technical consensus is formed about the blocksize. ...real technical consensus... You mean the bunch of self-proclaimed Bitcoin wizards, who decided they have the right to tell everybody what to do, and who never got to grow up and are now angry at the world for not listening to them anymore? That technical consensus? Bitcoin is decentralized, but you are only allowed to do what we tell you to do. It's our pet project, we wrote code for it! That's what it all boils down to, all these dirty games of calling XT an alt-coin and censoring its posts, pretending to be Satoshi, sabotaging XT switch, etc.: How dare they not listen to Us The Smartest anymore?!!! Pathetic. The history will roll over you in a blink. The harder you try, the quicker it will go. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
One of the comments made by the mining pools is that they won't run XT because it is experimental. Has there been any consideration to making available a version of XT with only the blocksize changes? The least experimental version would be one that makes the absolute minimum changes to core. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes. This saves creating a new function. Without the consensus measuring code, the patch would be even easier. Satoshi's proposal was just a block height comparison (a year in advance). The state storing code is also another complication. If the standard counting upgrade system was used, then no state would need to be stored in the database. On Wed, Jul 1, 2015 at 11:49 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (My replies below) On 06/26/2015 06:47 AM, Tier Nolan wrote: On Thu, Jun 25, 2015 at 3:07 PM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: The hard-cap serves the purpose of a safety limit in case our understanding about the economics, incentives or game-theory is wrong worst case. True. Yep. BIP 100 and 101 could be combined. Would that increase consensus? Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100 is a better alternative to Gavin's proposal(s), but that I didn't think that this should be taken to mean that I am saying one thing is superior to Gavin's work, rather, I emphasized that Gavin work with Jeff and Adam. At least, at this stage the things are in a BIP process. If the BIP 100 and BIP 101 would be combined, what would that look like on paper? - Miner vote threshold reached - Wait notice period or until earliest start time - Block size default target set to 1 MB - Soft limit set to 1MB - Hard limit set to 8MB + double every 2 years - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum) Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks. Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size. Legacy clients would remain in the network until 80% of miners vote to raise the limit and a miner produces a 1MB block. If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it. The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog= =rtTH -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
We should have the highest respect for what these people are doing, and we should try to do something constructive, not waste time with anger and disrespect. Why, exactly, should I have any respect for what these people are doing (and supposedly not have any respect for what the other side is doing)? From my point of view, the XT side _does_ something constructive. It's the Core side that resorts to dirty tactics and tries to sabotage community's free choice instead. Nobody should be forced to do anything. Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin? Let users decide what Bitcoin is or isn't. The developers are not telling you what to do, they are trying to do what they consider is best for the ecosystem given their technical abilities. The developers Co are doing their best to stay in power, so they could continue imposing their will on Bitcoin ecosystem. This is the real power grab, not Gavin and Hearn, who merely provided an alternative. And the fear they show is most telling. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Thank you Eric for saying what needs to be said. Starting a fork war is just not constructive and there are multiple proposals being evaluated here. I think that one thing that is not being so much focussed on is Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core SPV nodes that did not opt-in. It exposes those SPV nodes to loss in the likely event that Bitcoin-XT results in a network-split. The recent proposal here to run noXT (patch to falsely claim to mine on XT while actually rejecting it's blocks) could add enough uncertainty about the activation that Bitcoin-XT would probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so. This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone. We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix. Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!? I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really. Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before. We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk. I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief
Re: [bitcoin-dev] Bitcoin XT Fork
At http://media.scmagazine.com/documents/127/virtual_currency_rules_31557.pdf, section 200.3(c)(2) lists consumers that utilize Virtual Currency solely for the purchase or sale of goods or services or for investment purposes as Persons [who] are exempt from the licensing requirements. Who else is left? On Mon, Aug 17, 2015 at 1:24 PM, Theo Chino via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hello, I might have a crazy simple solution. From the literature I read, it seems that Satochi has the keys that would authenticate him using Bitcoin. HBO John Oliver's program might have given me (and hopefully others) the brilliant idea to protect the Bitcoin network from the overzealous reach of the politicians. One need to start a Church, and to start the Church one need funds (121UZ1hDs9MgCHonA8vjXr89D8FuDf5c7t) to start. John Oliver's program on HBO about Churches (and the hypocrisy of some) was epic and such entity could argue that Bitcoin is a belief system (which it is) and would force the issue at a Federal level under the Church and State separation. - John's video : https://www.youtube.com/watch?v=7y1xJAVZxXg At this time, I am waiting for the License issue to walk its course in New York State. Currently: - I am waiting for my License to be denied (to protest) and appeal it. - Waiting to hear from the License process to appeal the law in general. - Meeting Elected officials (in New York City, NY State, and France) and educating them on Bitcoin. Every time we (the community) talk about Bitcoin, it can sound like religion; therefore why not go all the way and do what John Oliver did ? Seed money would help. :) Regarding the Fork, from my perspective of a small company, I see that like it was with IRC with the ICMP node split. The Church thing is not here to take side but to try to protect the Bitcoin. We will need to ordain ministers selected after completing prescribed courses of study setup by the developers. In short I am asking Satochi to help this church with original coins. If it is a troll, I am talking to the Dev Community at large to recruit them to ordain the ministers. Regards, *Theo Chino* *https://www.facebook.com/groups/557495624389384 https://www.facebook.com/groups/557495624389384 (NY State)http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york* *(My position on the fork is still the same as when I ran for a seat of the Foundation; still don't have enough information and thing will move faster than I can devote the time to read about it.)* On Mon, Aug 17, 2015 at 1:30 PM, Btc Drak via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: For the record I would like to share my technical analysis of the Satoshi email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few days ago. 1. The email is the one used by Satoshi to announce Bitcoin in the first place. http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html 2. The email was not spoofed, it actually originated from vistomail's server. The email headers show the email originated from 190.97.163.93 and the SPF records show this as an authorised sender for the email. This does not prove the account wasn't hacked of course, or that the account might have expired and be re-registered by someone else (vistomail is a paid for email provider). 3. While the email is not signed, and there are a number of PGP keys listed on key servers for him (to vary addresses), he didnt sign any emails with any PGP keys. It is therefore not possible to outright dismiss the email's authenticity as the email originates from an authentic source. The only questions is whether the webmail service was hacked or commandeered somehow. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy http://www.litmocracy.com and Meme Racing http://www.memeracing.net (in alpha). I'm the webmaster for The Voluntaryist http://www.voluntaryist.com which now accepts Bitcoin. I also code for The Dollar Vigilante http://dollarvigilante.com/. He ought to find it more profitable to play by the rules - Satoshi Nakamoto ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
On Mon, Aug 17, 2015 at 10:13 PM, GC slashdevn...@hotmail.com wrote: Dave, “ … highly skilled psychological warfare agents ..” Paranoia, much? Well, I respect your characterization of it as paranoia, sure. If you check out the #1 podcast in higher education on podomatic.com, you may find that it's more awareness than paranoia. There are other resources too, like GnosticMedia, SchoolSucksProject, and Corbett Report. These programs are not addressing bitcoin specifically or even generally. They simply show that people with high intelligence do not always have the best interests of the rest of their species in mind when they engineer solutions. For example, taxation is a form of parasitic human cannibalism, not in the eating of flesh, but in the consuming of life force. The methods of farming humans to tolerate such a system are quite advanced. Learning is the answer. Defend yourself for the sake of everyone else. Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Would we discuss his posting if he would not claim to be Satoshi? There are a lot of smart people on this list, which publish occasionally quite useful ideas. I actually learned something important and infulential in my thinking from the post. So I am happy it happened regardless of the other things around it. Because of the _very_ poor SNR on the list right now I'm not sure if I would have seen it if it were sent by JoeBob. (This is a greater issue, and I'm not suggesting that people start posting with fake identities to get over the noise floor... but I'm just presenting the facts of it as I see them here). The rest of the traffic, not so useful, thank heavens for threaded mail user agents. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Dear Eric, thank you for sharing your thoughts. It obviously boils down to political beliefs, not so much technical arguments. I understand that you are in favor of a guided decentralization and you are most happily invited to follow this path. I don't want to be on it. I want total decentralisation of bitcoin and many other parts of the current system. So in the end the hard fork might be perfect, because people like you will not waste so much more energy and time fighting people like me (and others) who are following different dogmata because we are using different coins and talking about different code. Interestingly enough in the end we will probably have a winner - determined by the price - so I am looking forward to the outcome. It is just the time so make some bets, which I embrace. Another interesting thing is, that you actually fear problems arising from this. What do you have to loose? Just stick with the old bitcoin version and weather this storm. Bitcoin is not going to vanish or break from this. It is just forking. One fork will come stronger out of this. You just have to choose a side and live with it, if you loose it all. But that is the story of bitcoin since the beginning. If you ask me, you fear the choice, not the change. Cheers Levin Adam Back via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org schrieb am Mo., 17. Aug. 2015 um 16:37 Uhr: Thank you Eric for saying what needs to be said. Starting a fork war is just not constructive and there are multiple proposals being evaluated here. I think that one thing that is not being so much focussed on is Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core SPV nodes that did not opt-in. It exposes those SPV nodes to loss in the likely event that Bitcoin-XT results in a network-split. The recent proposal here to run noXT (patch to falsely claim to mine on XT while actually rejecting it's blocks) could add enough uncertainty about the activation that Bitcoin-XT would probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so. This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone. We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix. Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!? I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really. Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before. We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan tier.no...@gmail.com wrote: - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum) I don't think is all that interesting to make miners vote on lower limit. Say the community wants to reduce the size to limit mining centralization, it's not unthinkable that the hashrate majority (which may have to face more competition or harvest less transactions after the change) may oppose to that and then the community is forced to deploy an anti-miner's hardfork (maybe even asic-reset hardfork?) instead of a softfork. Yes, uncontroversial sofforks are easier and less risky to deploy than uncontroversial hardforks, but anti-miner hardforks are not. Not only I don't think it's a good idea for miners to vote on the block size (which is there to control them), I don't even buy the assumption that we can always just softfork a smallwer size later. If you give something to miners they may not want to give it back later. We could hardfork to 42 M supply and then just softfork back to 21 M, right? Or what's the same, we could just softfork supply to 15 M. Such a change would be clearly controversial among miners, so it wouldn't be an uncontroversial softfork anymore. Some of these cases are discussed in BIP99. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 7:01 PM, Oliver Egginger bitc...@olivere.de wrote: Am 17.08.2015 um 18:32 schrieb Jorge Timón: On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote: Am 17.08.2015 um 13:44 schrieb Jorge Timón: On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. Why should we block any email address? To avoid such discussions. You mean to avoid discussions about his authenticity? Should that matter at all? Does the content of the post matter less than its author? It just creates confusion. Particularly in the media. I also find it unfair if people abuses Satoshi's name to submit their personal views on an issue. Yes, people have been abusing his name in the block size debate to present their own personal views, almost from the beginning, and that has been very annoying. But I don't remember you proposing to block their emails from the list in those occasions. For all I know this could have been the real Satoshi. But I just maintain what I've said when arguments of authority (an old fallacy) have been used: only the arguments matter, not who makes them (which is also what logic says). Maybe the people using the arguments of authority actually care about whether the author is Satoshi or not to determine what they think about what the content says. But I personally don't care: I can say that I agree with what the post says no matter if it is written by Satoshi or someone else (because the identity of the author doesn't change what I think of the content). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9
so you want us to, (i) at the moment of payment decide wether to pay a tx fee, or to include some data about what the transaction is about... (ii) and (iii) are out of the question as you'd be forcing people to not have privacy, which is one of the main reasons people use bitcoin, just paying like cash. then the rest goes down hill. 1. You want to add more data to a transaction, which would fill blocks even faster. 2. The data will be on the blockchain, why in hell would anybody pay the miners for it when you can just mine it yourself, or pay XYZ online service to give you the tools you mention, and why would XYZ company pay miners for the revenues of such service? because... you want to change the Bitcoin license from MIT to something else? I'm sorry. this is dead on arrival, very unrealistic. Perhaps this will work for some other coin where people accept all these orwellianism from the start. If you think there's much debate about blocksize you've no idea how things would get at the mention of moving away from MIT into some sort of commercial license, that would indeed destroy Bitcoin from being adopted as it would enter into many many conflicts that would render it unusable by lots of organizations. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: To avoid such discussions. You seem to be assuming that there is specific reason to believe the message is unauthentic. This is not the case. Contrary to other poster's claims, if the message had been PGP signed that might, in fact, have arguably been weak evidence that it was unauthentic: no message from the system's creator that I (or apparently anyone) was aware of was ever signed with that key. The headers on the message check out. The mail server in question is also not an open relay. At the moment the only reason I have to doubt the authenticity of it is merely the fact that it exists after so much air silence, but that isn't especially strong. In the presence of doubt, it's better to take it just for its content. And on that front it is more on-topic, civil, and productively directed than a substantial fraction of new messages on the list. I certainly do not see a reason to hide it. A focus on the content is especially relevant because one of the core messages in the content is a request to eschew arguments from authority; which is perhaps the greatest challenge here: How can the founder of a system speak up to ask people to reject that kind of argument without implicitly endorsing that approach through their own act? This whole tangest is a waste of time. If you believe the message is unauthentic or not the best response is the same as if it is authentic. Focus on the content. If its worth responding to, do. If it's not don't. Then move on with life. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
In times of controversy or flamewar on the Linux kernel mailing list, occasionally fake Linus Torvalds or other spoofed posts would appear. It is the nature of email. Just ignore it. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9
By increasing the size of blocks, transaction fees may not be available to supplement mining revenue and so those who do not have access to cheap or free power to mine; why? wouldn't a bigger block size actually allow for more transactions per block, therefore more fees to be collected, and the cost spread out among many more users (thus still keeping tx fees low). If anything, wouldn't bigger blocksizes are needed to suplement the losses of coinbase rewards being halfed. http://twitter.com/gubatron On Mon, Aug 17, 2015 at 12:39 PM, Ahmed Zsales via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hello, Here we propose a long-term solution to replace mining rewards and transactions fees. BIP [104] is currently a discussion draft only. https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing Views and feedback welcome. Regards, Ahmed ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9
Did you self-assigned a bip number? https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki Anyway, from your document: The existing (2015) Big Data analysis market is valued at around $125bn according to market research firm IDC. As the Bitcoin block chain replaces existing payment systems and attracts millions or hundreds of millions of users, the intrinsic value of the data in the block chain will increase and be attractive to data analytics businesses and block chain start-ups. Without even entering about details related to technical feasibility, do you realize that you are proposing Bitcoin to become the most orwellian money ever? That this is the opposite of what many proposals and designs like coinjoin try to achieve? I think (hope?) that this idea doesn't have any chance of being accepted by the Bitcoin community. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
I should add that in the interest of peace and goodwill, I extend an offer to both Mike and Gavin to make their grievances heard…but only on the condition that we make a good effort to avoid misrepresentation and misreading of the other side’s intentions. On Aug 17, 2015, at 9:37 AM, Eric Lombrozo elombr...@gmail.com wrote: On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin? Let users decide what Bitcoin is or isn't. FWIW, I don’t think what theymos did is very constructive.I understand his position…but it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike’s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist. Regardless of the technical merits of XT, the fact that we’ve never done a hard fork before, not even for things some other devs have wanted…and not due to any malice on anyone’s part but because simply that’s just the nature of decentralized consensus with well-defined settlement guarantees…this is the problem - Mike and Gavin think they’re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin’s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive. But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike’s hand, and that’s the problem. The whole block size thing is too nuanced and too easily spun simplistically. It’s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as “obstructionism” and it’s too easy to spin bigger blocks as “scalability” because most of the people can’t tell the fucking difference. The fact is most of the people don’t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It’s beyond ironic. If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatment…Bitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested hard forking mechanism…and a hard fork for such a politically divisive issue will almost certainly lead to a lack of cooperation and refusal to work together out of spite. All of us would like to be able to process more transactions on the network. It’s not a matter of whether we think higher capacity is a bad thing - it’s more that some of us are concerned that Bitcoin is not sufficiently mature to be able to handle such a schism with so much hostility. Let’s face it, folks - from a PR standpoint, the block size issue is irrelevant. Nobody really understands it except for a handful of people - I’ve tried to explain it, I’ve even written articles about it - but most people just don’t get it. Most people don’t really get scalability either - they seem to think that scalability is just doing the same thing you’ve always done manyfold. Block size is an especially dangerous issue politically because it’s one of those that requires deep understanding yet superficially sounds really simple. It’s perfect Dunning-Kruger bait. So let’s be a little smarter about this. signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
Am 17.08.2015 um 18:32 schrieb Jorge Timón: On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote: Am 17.08.2015 um 13:44 schrieb Jorge Timón: On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. Why should we block any email address? To avoid such discussions. You mean to avoid discussions about his authenticity? Should that matter at all? Does the content of the post matter less than its author? It just creates confusion. Particularly in the media. I also find it unfair if people abuses Satoshi's name to submit their personal views on an issue. - oliver ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Eric, In the entire history of Bitcoin we've never attempted anything even closely resembling a hard fork like what's being proposed here. These concerns are understandable. What's hard to understand is why he, he and he get to decide what is more risky - hitting the limit or forking for larger blocks? Many people don't seem to think the upcoming hard fork is such a big risk. --- And why there's so much fear that your side might lose to XT in a honest battle? Why is it suddenly not let the best man win, but we are right, they are enemies of the state, go get them!!!? This is the same fear dictators have of honest elections. If you know you can't win in a honest battle, you start rigging the game. With recent Satoshi post even this list is not immune... I don't know if everybody had a chance to appreciate this quote by theymos yet: If 90% of /r/Bitcoin users find these policies to be intolerable, then I want these 90% of /r/Bitcoin users to leave. (https://www.reddit.com/r/Bitcoin/comments/3h9cq4/its_time_for_a_break_about_the_recent_mess/) This is a quote worthy of Gaddafi. Fortunately, it's hard to be a dictator on the Internet, where you can't shoot people. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
On Mon, Jun 22, 2015 at 11:32 PM, Ross Nicoll j...@jrn.me.uk wrote: Potentially daft question, why not use a minimum height? Yes, it's imprecise, but over an extended period of time they're good enough IMHO. I'd have to do more careful calculations to confirm, but block 388,000 should be about right as a minimum. BIP99 (still a draft too) currently recommends a minimum height plus 95% mining upgrade confirmation (aka miner voting) after that for uncontroversial hardforks: https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Uncontroversial_hardforks http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html But general hardfork activation discussion is still inconclusive in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html The code for the example uncontroversial hardfork proposed in bip99 is at: https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 But I haven't created a PR for either the code or the bip yet. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Great, so how about you go tell theymos to stop censoring XT posts and banning the other side on /r/Bitcoin? Let users decide what Bitcoin is or isn't. FWIW, I don’t think what theymos did is very constructive.I understand his position…but it only hurts the cause, unfortunately - the PR battle is not the same thing as a discussion on technical merits. He hurts the PR battle and plays into Mike’s hand by doing that. The actual underlying issue actually has little to do with block size - it has to do with Mike and Gavin feeling that the core devs are being obstructionist. Regardless of the technical merits of XT, the fact that we’ve never done a hard fork before, not even for things some other devs have wanted…and not due to any malice on anyone’s part but because simply that’s just the nature of decentralized consensus with well-defined settlement guarantees…this is the problem - Mike and Gavin think they’re somehow special and their fork should be pushed while the rest of us resist pushing our own controversial pet ideas because we want civility and understand that at this stage in Bitcoin’s development trying to fork the blockchain over highly divisive issues is counterproductive and destructive. But the fact of the matter is that in the PR battle, arguments against the fork actually play into Mike’s hand, and that’s the problem. The whole block size thing is too nuanced and too easily spun simplistically. It’s too easy to spin resistance to bigger blocks (even though the resistance is actually much more towards untested hardforking mechanisms and serious security concerns) as “obstructionism” and it’s too easy to spin bigger blocks as “scalability” because most of the people can’t tell the fucking difference. The fact is most of the people don’t really understand the fundamental issue and are taking sides based on charismatic leadership and authority which is actually entirely counter to the spirit of decentralized consensus. It’s beyond ironic. If you guys want to win the PR battle, the key is to make it clear that you are not obstructionist and are giving everyone equal treatment…Bitcoin was designed such that changing the rules is *hard* and this is a feature. Bitcoin simply does not have a reliable and tested hard forking mechanism…and a hard fork for such a politically divisive issue will almost certainly lead to a lack of cooperation and refusal to work together out of spite. All of us would like to be able to process more transactions on the network. It’s not a matter of whether we think higher capacity is a bad thing - it’s more that some of us are concerned that Bitcoin is not sufficiently mature to be able to handle such a schism with so much hostility. Let’s face it, folks - from a PR standpoint, the block size issue is irrelevant. Nobody really understands it except for a handful of people - I’ve tried to explain it, I’ve even written articles about it - but most people just don’t get it. Most people don’t really get scalability either - they seem to think that scalability is just doing the same thing you’ve always done manyfold. Block size is an especially dangerous issue politically because it’s one of those that requires deep understanding yet superficially sounds really simple. It’s perfect Dunning-Kruger bait. So let’s be a little smarter about this. signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Adam, While greatly appreciating your prior efforts in crypto-ccy RD and current efforts for Blockstream, its not a plus for your reputation to be using emotive terms like ³attack², ³fork war and throwing so much FUD into the developer email channel directly after Eric¹s email. We would appreciate seeing your well-argued thoughts, not FUD and flaming. There are multitudes of trolls in all forums already. On 17/8/15 10:36 pm, Adam Back via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Thank you Eric for saying what needs to be said. Starting a fork war is just not constructive and there are multiple proposals being evaluated here. I think that one thing that is not being so much focussed on is Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core SPV nodes that did not opt-in. It exposes those SPV nodes to loss in the likely event that Bitcoin-XT results in a network-split. The recent proposal here to run noXT (patch to falsely claim to mine on XT while actually rejecting it's blocks) could add enough uncertainty about the activation that Bitcoin-XT would probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: NxtChg, In the entire history of Bitcoin we¹ve never attempted anything even closely resembling a hard fork like what¹s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocoland have been frustrated because of the inability to do so. This inability is not due to any malice on anyone¹s partit is a feature of Satoshi¹s protocol. For better or worse, it is *very hard* to change the rulesand this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone. We¹ve managed to have a few soft forks in the pastand for the most part these changes have been pretty uncontroversialor at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we¹ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix. Again, we have NEVER attempted anything even remotely like what¹s being proposed - we¹ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!? I can understand that some people would like bigger blocks. Other people might want feature X, others feature Yand we can argue the merits of this or that to deathbut the fact remains that we have NEVER attempted any hard forking changenot even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparisonit could be any controversial change, really. Would you want to send your test pilots on their first flightthe first time an aircraft is ever flowndirectly into combat without having tested the plane? This is what attempting a hard fork mechanism that¹s NEVER been done before in such a politically divisive environment basically amounts tobut it¹s even worse. We¹re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we¹ve never flown before. We¹re talking billlions of dollars¹ worth of other people¹s money that is on the line here. Don¹t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don¹t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that¹s such a petty thing compared to what I¹m talking about here. If we attempt a novel hard-forking mechanism that¹s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spiteand can easily lead to a war, tanking the value of everyone¹s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn¹t even come close to touching big payment processors like Visa. It¹s hard to imagine a protocol improvement that¹s worth the risk. I urge you to at least try to see the bigger picture hereand to understand that nobody is trying to stop anyone from doing anything out of some desire for
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
On Aug 17, 2015, at 8:03 AM, Levin Keller p...@levinkeller.de wrote: Dear Eric, thank you for sharing your thoughts. It obviously boils down to political beliefs, not so much technical arguments. I understand that you are in favor of a guided decentralization and you are most happily invited to follow this path. I don't want to be on it. I want total decentralisation of bitcoin and many other parts of the current system. I specifically asked you to stop misrepresenting - I’m NOT in favor of guided decentralization, I never said anything like that. *THIS* is the problem…you’re reading intentions into others that simply are NOT there. If you don’t really understand something, ask. I want complete decentralization - but for practical reasons, which should be obvious, we cannot start at this point. Bitcoin came into existence because Satoshi wrote a whitepaper and implemented the idea - and it was his rules. There was no voting, no committee, no proof-of-work, no nothing…it was a complete dictatorship in the beginning. So in the end the hard fork might be perfect, because people like you will not waste so much more energy and time fighting people like me (and others) who are following different dogmata because we are using different coins and talking about different code. Interestingly enough in the end we will probably have a winner - determined by the price - so I am looking forward to the outcome. It is just the time so make some bets, which I embrace. Another interesting thing is, that you actually fear problems arising from this. What do you have to loose? Just stick with the old bitcoin version and weather this storm. Bitcoin is not going to vanish or break from this. It is just forking. One fork will come stronger out of this. You just have to choose a side and live with it, if you loose it all. But that is the story of bitcoin since the beginning. If you ask me, you fear the choice, not the change. Again, misrepresentation - “you fear the choice, not the change” - why should anyone ask *you* what I fear? Why don’t you ask *me*? Cheers Levin Adam Back via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org schrieb am Mo., 17. Aug. 2015 um 16:37 Uhr: Thank you Eric for saying what needs to be said. Starting a fork war is just not constructive and there are multiple proposals being evaluated here. I think that one thing that is not being so much focussed on is Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core SPV nodes that did not opt-in. It exposes those SPV nodes to loss in the likely event that Bitcoin-XT results in a network-split. The recent proposal here to run noXT (patch to falsely claim to mine on XT while actually rejecting it's blocks) could add enough uncertainty about the activation that Bitcoin-XT would probably have to be aborted. Adam On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: NxtChg, In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here. Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so. This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone. We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix. Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!? I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk
Re: [bitcoin-dev] That email was almost certainly not the real Satoshi
Dude, while it does appear plausible that the box is insecure, is it truly warranted to jump to any particular conclusion from that alone? What if all the open ports is just because it is a honey pot? On Mon, Aug 17, 2015 at 11:41 AM, Jonathan Wilkins via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I'm sure that most people here were skeptical, but FWIW, the server that hosts vistomail.com is a mess, it's a Plesk box with more than a couple of services with dubious security histories. MailEnable smtpd, MSRPC, RDP, see for yourself: Most likely someone popped the box and is entertaining themselves. Nmap scan report for vistomail.com (190.97.163.93) Host is up (0.10s latency). Not shown: 65521 filtered ports PORT STATE SERVICE VERSION 21/tcpopen ftp Microsoft ftpd | ssl-cert: Subject: commonName=secureanonymoussurfing.com | Not valid before: 2015-05-03T00:00:00+00:00 |_Not valid after: 2018-05-02T23:59:59+00:00 |_ssl-date: 2015-08-16T00:08:25+00:00; +1m09s from local time. 25/tcpopen smtp MailEnable smptd 8.60-- | smtp-commands: vistomail.com [192.241.217.85], this server offers 4 extensions, AUTH LOGIN, SIZE 2048, HELP, AUTH=LOGIN, |_ 211 Help:-Supported Commands: HELO,EHLO,QUIT,HELP,RCPT,MAIL,DATA,RSET,NOOP 53/tcpopen domainMicrosoft DNS 6.1.7601 | dns-nsid: |_ bind.version: Microsoft DNS 6.1.7601 (1DB14556) 80/tcpopen http Microsoft IIS httpd 7.5 |_http-favicon: Parallels Control Panel | http-methods: Potentially risky methods: TRACE |_See http://nmap.org/nsedoc/scripts/http-methods.html | http-ntlm-info: | Target_Name: DS04 | NetBIOS_Domain_Name: DS04 | NetBIOS_Computer_Name: DS04 | DNS_Domain_Name: DS04 | DNS_Computer_Name: DS04 |_ Product_Version: 6.1 (Build 7601) |_http-title: Domain Default page 110/tcp open pop3 MailEnable POP3 Server |_pop3-capabilities: USER TOP UIDL 135/tcp open msrpc Microsoft Windows RPC 143/tcp open imap MailEnable imapd |_imap-capabilities: completed CAPABILITY AUTH=CRAM-MD5 CHILDREN UIDPLUSA0001 AUTH=LOGIN IMAP4rev1 OK IDLE IMAP4 443/tcp open ssl/http Microsoft IIS httpd 7.5 |_http-favicon: Parallels Control Panel | http-methods: Potentially risky methods: TRACE |_See http://nmap.org/nsedoc/scripts/http-methods.html |_http-title: Domain Default page | ssl-cert: Subject: commonName=secureanonymoussurfing.com | Not valid before: 2015-05-03T00:00:00+00:00 |_Not valid after: 2018-05-02T23:59:59+00:00 |_ssl-date: 2015-08-16T00:08:24+00:00; +1m09s from local time. 587/tcp open smtp MailEnable smptd 8.60-- | smtp-commands: vistomail.com [192.241.217.85], this server offers 4 extensions, AUTH LOGIN, SIZE 2048, HELP, AUTH=LOGIN, |_ 211 Help:-Supported Commands: HELO,EHLO,QUIT,HELP,RCPT,MAIL,DATA,RSET,NOOP 3389/tcp open ms-wbt-server Microsoft Terminal Service 8443/tcp open https-alt? | ssl-cert: Subject: commonName=Parallels Panel/organizationName=Parallels, Inc./stateOrProvinceName=Virginia/countryName=US | Not valid before: 2015-03-13T19:40:20+00:00 |_Not valid after: 2016-03-12T19:40:20+00:00 |_ssl-date: 2015-08-16T00:08:24+00:00; +1m09s from local time. 8880/tcp open http Microsoft IIS httpd 7.5 |_http-favicon: Parallels Control Panel |_http-methods: No Allow or Public header in OPTIONS response (status code 500) |_http-title: Site doesn't have a title (text/html; charset=utf-8). 49154/tcp open msrpc Microsoft Windows RPC 49156/tcp open msrpc Microsoft Windows RPC Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|phone Running: Microsoft Windows 2008|7|Phone|Vista OS CPE: cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_7::-:professional cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1 OS details: Windows Server 2008 R2, Microsoft Windows 7 Professional or Windows 8, Microsoft Windows Phone 7.5 or 8.0, Microsoft Windows Vista SP0 or SP1, Windows Server 2008 SP1, or Windows 7, Microsoft Windows Vista SP2, Windows 7 SP1, or Windows Server 2008 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9
@btc Drak, noted, thanks. 1. Updated - removed reference to self ascribed [104] https://drive.google.com/file/d/0BwEbhrQ4ELzBX3hCekFRSUVySWs/view?usp=sharing @Angel Leon 2. Privacy issues are clearly covered. On Mon, Aug 17, 2015 at 6:48 PM, Btc Drak btcd...@gmail.com wrote: You cannot assign your own bip numbers. You have to use the form BIP-myproposal On Mon, Aug 17, 2015 at 5:39 PM, Ahmed Zsales via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hello, Here we propose a long-term solution to replace mining rewards and transactions fees. BIP [104] is currently a discussion draft only. https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing Views and feedback welcome. Regards, Ahmed ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I suspect we need a better incentive for users to run nodes instead of relying solely on altruism. Is he talking about full nodes i.e. validating-only, or nodes in the sense of the original whitepaper (i.e. miners)? Because there is already plenty of incentive for running a node (i.e. the coinbase). One can mine without running a node, unfortunately, thats where the comments about pooled mining come from. Also, this distionction between full nodes that Validate and (presumably) SPV wallets that don't validate isn't consistent with the design of Bitcoin. enter the mining game. A bit like making P2Pool the one and only pool allowed on the network. Thats been suggested, though scalablity reasons make this hard: in the P2Pool design there is a substantial tradeoff in variance reduction vs communicatoin costs. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 9:28 PM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: enter the mining game. A bit like making P2Pool the one and only pool allowed on the network. Thats been suggested, though scalablity reasons make this hard: in the P2Pool design there is a substantial tradeoff in variance reduction vs communicatoin costs. Pools could be somehow required to do p2pool between them, but there would still be pools to further reduce variance, no? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Please note there is now a PR for this BIP[1] and also a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2]. [1] https://github.com/bitcoin/bips/pull/179 [2] https://github.com/bitcoin/bitcoin/pull/6564 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fees and the block-finding process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17 August 2015 07:49:21 GMT-07:00, BitMinter operator via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: I don't think mining pools will immediately make blocks as big as possible if the hard limit is raised. Note that XT includes a patch that sets the soft limit to be the same as the hard limit by default, so if miners did use the defaults as big as possible blocks would be produced. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0fc+ AAoJEMCF8hzn9Lnc47AIAIubfigcCrw3GiPUxsqzNkY2BECj+ACcoNCJaftjtM1b y5GrR0Ud8F9NKVw2iaG67ofgq7ry/s9MpgxhRFTjYrEyF+CCmUuuV4fu9f4zXzLc uHXh781zwa9wZKXls53vlS1v1V3jips5B8k+SWh2IWlaOBqZ0onb2uhojE8xfaqU vIAJIu8bSX1BHX3VnHN6u4VvUJx1EUj4zNpLj1C4fVsbCO+mzvKucNc6KGRXRSWe fde6h7gHJE7A7+K5E/xdXAlpIt1PAO8upE7tPwBiqwLWMEg82leVtMP7ivZ5XZlu Uqh5GKIfCCs11jO189TijwDDUYwlAOXENBtowX+3YbQ= =Emr/ -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote: Am 17.08.2015 um 13:44 schrieb Jorge Timón: On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin-dev@lists.linuxfoundation.org wrote: That made it to the news and is now discussed in various places. Could you please delete Satoshis old email addresses from the list and block them? Sorry to post this to all members but I can't find an owner for this list. Why should we block any email address? To avoid such discussions. You mean to avoid discussions about his authenticity? Should that matter at all? Does the content of the post matter less than its author? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Annoucing Not-BitcoinXT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fun thing about this, is you only need 25% of hashing power running Not-BitcoinXT to screw over the miners running XT, as XT blocks are valid Bitcoin blocks if they're on a valid Bitcoin chain. 75% upgrade thresholds have a lot of issues... On 16 August 2015 15:34:33 GMT-07:00, Julie via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Announcing Not-BitcoinXT https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YdD AAoJEMCF8hzn9Lnc47AH/1xFeDBejXmWjYlloDIq4OY8DypXypWk+J6BI2s5htm/ zBEQ/109u2T+7UYV5hSfh9GUj67NJ5HPbsPOpqoMqGO/yoJglM7ZEypNTKnOUlUf 3Ax+sgx5h5z2a51cshG0ups2liYgT926jzIyoz+Cs/O0g0mp+1Xu2rWm3qfnueXU eqeqZ5SgnVT2JmnHubaYOl3IJvYs0B68TeSzFD0UFQzr7W7bzSFno4dIgpUhr5nP Rd5ZFdYeotiGiPGStPmYshljuy0sbDydKBN29qViGRqXCUDA5QBAFGc/yfOm+82E 9LznXUfeJmsPztS1Wv8OzB7lpHVISKxrNKTCCt9U3oM= =ZaI2 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT 0.11A
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: There are a few ways: here is my favorite (for the moment). 1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet 'BitcoinXT' Even more direct: use coinbase outputs of XT blocks to create those outputs, as they can't by definition be on the Bitcoin chain. If you can't get those, using coinbase outputs of Bitcoin blocks to create definitely Bitcoin-only outputs, and then spend the inputs to those transactions again on the XT chain. This isn't quite as good, as a big reorg on the XT chain could in theory spend them, but it's a close second. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV0YIS AAoJEMCF8hzn9Lnc47AH/R9EaGaa0xmD7qBODGUwX3SsDde7DMgO4t8X5GQ9uoaq qcjdnnvdeXjy5S39QdZFJjlH5bGn+BJy2wIxn0lMciKhEGIFOGeCUsMYEbgnOc03 cLuyYpxdfXe4Amoxf2mqADgBqkAckf4cX6bMm3XXg+v3XAby2llydIGIydTwGWYq 2KwXl9U9zm7UV8b5tJ7WmItCAcZAvTcSoX5SerOmPjjrmLtPTHThj8SfLTGAoWfT EXsSGkDBJ/9rJMms56FjciWsXHlB9pYK0a1sxh88PJluebqh99imDisJvATCVp2Z kZX1keZ1nyfG45jibgt6dlY97wU0n919SmQz0Tg6g90= =OD56 -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin XT Fork
Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.: This bitcoin-dev list restarted with an empty subscriber list on June 21st, 2015. So whoever posted from sato...@vistomail.com mailto:sato...@vistomail.com subscribed and verified the address recently. Do you propose that we manually approve new subscribers to prevent these kind of abuses as you put it? I would simply block the creators old email addresses. Easy with Mailman. I thought that would be a good and easy approach, but maybe I'm wrong. Some believes it is possible that the email could be genuine. Some say that only the content is important. I have closely followed. An interesting discussion. Thank you all so far. But let's say the poster would be the real Satoshi. Would we discuss his posting if he would not claim to be Satoshi? There are a lot of smart people on this list, which publish occasionally quite useful ideas. But much of this is hardly the subject of greater discussion. Especially not when it comes to the blocksize. On this subject almost everything has been already said. But not yet by everyone. Especially not by Satoshi. Satoshi would have a decisive influence on the community. I'm sure. To say it does not matter who's talking is maybe genteelly but a little bit remote from everyday life. Or not? Satoshi is the creator. What he says is in the newspaper and is perceived by all. If he says it's okay to do nothing as long as we stand together, then people have the courage to do maybe something dangerous or something wrong. Then people only follow their hearts. Otherwise they follow their fear. It is a paradox of the human nature that some type of Dictatorship can make you free. I say some type, not any type. Enough said. - oliver ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining
Hi all, I previously mentioned in a post that i believe that technically nodes are capable of handling blocks an order of magnitude larger than the current blocksize limit, the only missing thing was an incentive to run them. I have been monitoring the blockchain for the past couple of weeks and am seeing that even miners who have all the incentives are for whatever reason struggling to download and validate much smaller blocks. The data actually paints a very grim picture of the current bandwidth/validating capacity of the global mining network. See the following empty blocks mined despite a non-trivial elapsed time from the previous block just from the past couple of days alone (Data from insight.bitpay.com): EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined by370165 29s 720784 Antpool370160 31s 50129BTCChinaPool370076 49s 469988 F2Pool370059 34s 110994 Antpool370057 73s 131603 Antpool We have preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining. The most glaring case is Block 370057 where despite 73s elapsing and the preceding block being a mere 131KB, the miner is unable to download/validate fast enough to include transactions in his block. Unless ofcourse the miner is mining empty blocks on purpose, which does not make sense as all of these pools do mine blocks with transactions when the elapsed time is greater. This is a cause for great concern, because if miners are SPV mining for a whole minute for 750KB blocks, at 8MB blocks, the network will just fall apart as a significant portion of the hashing power SPV mines throughout. All a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. Yes, these pools deserve to lose money in that event, but the impact of reorgs and many block orphans for anyone not running a full node could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes. I simply don't see the XT fork having any chance of surviving if SPV nodes are unreliable. And if these pools go out of business, it will lead to even more mining centralization which is already too centralized today. Can anyone representing these pools comment on why this is happening? Are these pools on Matt's relay network? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
