Re: [Bitcoin-development] soft-fork block size increase(extensionblocks)
Wow. That email was delayed by the list for quite some time. It was sent on 6/1. From: Raystonn . Sent: Monday, June 01, 2015 12:02 PM To: Mike Hearn ; Adam Back Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] soft-fork block size increase(extensionblocks) I also need to argue for increasing the default block limit to the full 1MB in the next release. We’re already hitting that limit in bursts of transactions, which puts pressure on the average displayed in the below graphs. From: rayst...@hotmail.com Sent: Monday, June 01, 2015 11:39 AM To: Mike Hearn ; Adam Back Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks) And we're not going to get to VISA scale any time soon No, not at these block size limits. The closer we get to the maximum block size, the slower we grow the average block size toward it. Number of transactions per day is of course highly correlated with average block size. Based on these graphs we can expect that hitting 1 million transactions per day will be impossible without raising the maximum block size. https://blockchain.info/charts/avg-block-size?showDataPoints=falseshow_header=truedaysAverageString=7timespan=allscale=1address= https://blockchain.info/charts/n-transactions?showDataPoints=falsetimespan=allshow_header=truedaysAverageString=7scale=1address= From: Mike Hearn Sent: Monday, June 01, 2015 11:01 AM To: Adam Back Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] soft-fork block size increase (extensionblocks) (at reduced security if it has software that doesnt understand it) Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code change. A 1MB client wont even understand the difference between a 1MB and 8MB out payment. Let's say an old client makes a payment that only gets confirmed in an extension block. The wallet will think the payment is unconfirmed and show that to the user forever, no? Can you walk through the UX for each case? If I am not misremembering, I think you've sided typically with the huge block, big data center only end of the spectrum. It would be Satoshi, that argued that. I think there must be a communication issue here somewhere. I'm not sure how this meme has taken hold amongst you guys, as I am the guy who wrote the scalability page back in 2011: https://en.bitcoin.it/wiki/Scalability It says: The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. By much higher rates I meant VISA scale and by high end server I meant high end by today's standards not tomorrows. There's a big difference between a datacenter and a single server! By definition a single server is not a datacenter, although it would be conventional to place it in one. But even with the most wildly optimistic growth imaginable, I couldn't foresee a time when you needed more than a single machine to keep up with the transaction stream. And we're not going to get to VISA scale any time soon: I don't think I've ever argued we will. If it does happen it would presumably be decades away. Again, short of some currently unimagined killer app. So I don't believe I've ever argued this, and honestly I kinda feel people are putting words in my mouth. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
Would SPV wallets have to pay to connect to the network too? The cost to compute and deliver the requested data will be pushed to the users of that node. This is the same way all costs, fees, and taxes of any business are always paid by its customers. The Bitcoin Network will not thrive in a decentralised manner if nodes can only be run on the charity of the wealthy. That said, node operators can set fees to lower impact on SPV wallets if they so desire. Market efficiency will ensure everyone pays only what they cost the Network in the long run. Also, users of centralized wallet services like Coinbase would not have to pay that fee Coinbase would pay to access nodes just like everyone else, to cover the costs they impose on the Network. Those costs would be covered by their customers, as are all costs incurred by any business. On 15 Jun 2015 8:50 pm, Kevin Greene kgree...@gmail.com wrote:On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr luke@dashjr.org wrote:On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote: Would SPV wallets have to pay to connect to the network too? From the users perspective, it would be somewhat upsetting (and confusing) to see your balance slowly draining every time you open your wallet app. It would also tie up outputs every time you open up your wallet. You may go to pay for something in a coffee shop, only to find that you cant spend your bitcoin because the wallet had to create a transaction to pay to sync with the network. Also, users of centralized wallet services like Coinbase would not have to pay that fee; but users of native wallets like breadwallet would have no such option. This incentivizes users to use centralized wallets. So this is kind of imposing a worse user experience on users who want to use bitcoin the right way. That doesnt seem like a good thing to me :/ SPV isnt the right way either ;)Hah, fair enough, there is no such thing as the right way to do anything. But I still think punishing users who use SPV wallets is a less-than-ideal way to incentive people to run full nodes. Right now SPV is the best way that exists for mobile phones to participate in the network in a decentralized way. This proposal makes the user experience for mobile wallets a little more confusing and annoying. If youre running a full node (the real right way), you should be able to earn more bitcoins than you pay out. Luke -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] The Bitcoin Node Market
I have been toying with an idea and figured I'd run it by everyone here before investing further time in it. The goal here is to make it sustainable, and perhaps profitable, to run full nodes on the Bitcoin Network in the long term. - Nodes can participate in a market wherein they are paid by nodes, wallets, and other services to supply Bitcoin Network data. Payment should be based on the cost imposed on the Node to do the work and send the data, but can be set in any way the node operator desires. It's a free market. - Nodes that are mostly leeching data from the Bitcoin Network, such as those that do not receive inbound connections to port 8333, will send payments to the nodes they connect to, but will likely receive no payments from other nodes, wallets, and other services. - Nodes that are providing balanced full service to the Bitcoin Network will tend to have a balance of payments coming in and going out with regards to other balanced full service nodes, leaving them revenue neutral there. But they will receive payments from leech nodes, wallets, and other services. The net effect here is that the cost to run nodes will be shared by those who are using the Bitcoin network but not contributing by running a full node. A market will develop for fees to connect to the Bitcoin Network which should help cover the cost of running the Network. It's still possible to continue offering access to your node for free as there is nothing forcing you to charge a fee. But this isn't very sustainable long-run. Market efficiencies should eventually mean nodes take in only what is required to keep the Network operational. Raystonn -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
http://xtnodes.com/ From: Brian Hoffman Sent: Monday, June 15, 2015 3:56 PM To: Faiz Khan Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer. Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit
That does sound good on the surface, but how do we enforce #1 and #2? They seem to be unenforceable, as a miner can adjust the size of the memory pool in his local source. From: Gavin Andresen Sent: Tuesday, June 09, 2015 6:36 AM To: Loi Luu Cc: Raystonn . ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit How about this for mitigating this potential attack: 1. Limit the memory pool to some reasonable number of blocks-worth of transactions (e.g. 11) 2. If evicting transactions from the memory pool, prefer to evict transactions that are part of long chains of unconfirmed transactions. 3. Allow blocks to grow in size in times of high transaction demand. The combination of (1) and (2) means an attacker needs to prepare lots of confirmed inputs to pull off the attack. By itself that means they MUST pay transaction fees. (3) further mitigates the attack because it allows miners to just absorb fees that the attacker is throwing at miners. On Tue, Jun 9, 2015 at 5:33 AM, Loi Luu loi.luu...@gmail.com wrote: The proposed fix is to add a new rule on how fees are handled. Some amount of every fee should be considered as burned and can never be spent. I will propose 50% of the fee here, but there may be better numbers that can be discovered prior to putting this into place. If we'd like miners to continue to collect the same fees after this change, we can suggest the default fee per transaction to be doubled I would propose another practical rule rather than burning 50% of the fee. For example, you can credit 50% of the transaction fee to the next block. Thus, the attacker cannot perform the attack with 0-fee any more, yet you don't have to double the price of the TX fee for the fix. Thanks, Loi Luu. On Tue, Jun 9, 2015 at 4:07 AM, Raystonn . rayst...@hotmail.com wrote: When implemented, the block size limit was put in place to prevent the potential for a massive block to be used as an attack to benefit the miner of that block. The theory goes that such a massive block would enrich its miner by delaying other miners who are now busy downloading and validating that huge block. The original miner of that large-block would be free to continue hashing the next block, giving it an advantage. Unfortunately, this block size limit opened a different attack. Prior to the limit, any attempt to spam the network by anyone other than someone mining their own transactions would have been economically unfeasible. As every transaction would have a fee, there would have been a real cost for every minute of spam. The end result would have been a transfer of wealth from spammer to Bitcoin miners, which would have harmed the spammers and encouraged further mining of Bitcoin, a very antifragile outcome. But now we have the block size limit. Things are very different with this feature in place. The beginning of a spam attack on the Bitcoin network will incur transaction fees, just like before. But if spam continues at a rate exceeding the block size limit long enough for transactions to be dropped from mempools, the vast majority of spam transaction fees will never have to be paid. In fact, as real users gain in desperation and pay higher fees to get their transactions through in a timely manner, the spammers will adjust their fees to minimize the cost of the attack and maximize effectiveness. Using this method, they keep their fees at a point that causes most of the spam transactions to be dropped without confirmation (free spam), while forcing a floor for transaction fees. Thus, while spam could be used by attackers to disable the network entirely, by paying high-enough fees to actually fill the blocks with spam, it can also be used by a single entity to force a transaction fee floor. Real users will be forced to pay a transaction fee higher than the majority of the spam to get their transactions confirmed. So this is an effective means for a minority of miners to force higher fees through spam attacks, even in the face of benevolent miners who would not support a higher fee floor by policy. Miners would simply have no way to fix this, as they can only put in the transactions that will fit under the block size limit. In the face of such a spam attack, Bitcoin's credibility and usability would be severely undermined. The block size limit enables this attack, and I now argue for its removal. But we can't just remove it and ignore the problem that it was intended to address. We need a new fix for the large-block problem described in the first paragraph that does not suffer from the dropped-transaction spam-attack problem that is enabled by the block size limit today. My proposal
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
Bitcoin is a global consensus system - if you're (sic) bandwidth isn't sufficient to keep up you are not part of the consensus. Bandwidth can be purchased. Infrastructure to handled increasing transaction volume can be purchased. The very fees being paid by a spammer will be used to increase the miners' ability to absorb even more fees. The blocksize limit cannot respond in such a dynamic way to attacks. Miners cannot buy a greater blocksize limit in response to a spammer that is paying high fees to deny transaction confirmation to the rest of the planet in an attempt to destroy the network. The blocksize limit is creating an attack that can be maintained forever by any organization that can afford to fill the blocks. This attack would get incredibly cheaper once the BTCUSD market tanks in response to the lack of usability of the Bitcoin network, meaning it would be a self-reinforcing attack that would likely destroy Bitcoin for as long as an attacker wants to keep it up, or until you patch it to remove the limit after-the-fact, which might be too little too late. If this isn't fixed, I would expect to see it carried out at some point by someone with a large short position in BTCUSD. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 3:18 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. Bitcoin is a global consensus system - if you're bandwidth isn't sufficient to keep up you are not part of the consensus. The blocksize limit *is* what determines the minimum bandwidth required to stay in consensus. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. Again, in your scenario if the bandwidth consumed by those transactions was sufficiently high, the network would collapse because consensus would fail. Why wouldn't that bandwidth be high enough to cause that collapse? Because of the blocksize limit! (combined with an intelligent mempool that increases the minimum fee/KB appropriately - we don't have that yet) The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. I already did the math for you on that: the maximum transaction fee you'd see in that kind of attack is around $2.5 USD/tx. That definitely is not high enough to make Bitcoin non-viable - I personally could easily afford fees like that for about 90% of my transactions this year by value, as I mainly use Bitcoin to get paid by my clients around the world. In fact, just today O'Reilly paid $15 USD to send me a wire transfer for expenses related to a conference I was invited too. A much more realistic transaction flood scenario - one that didn't raise serious questions about whether or not the attacker could afford to 51% attack Bitcoin - would raise tx fees to something more like $0.25/tx -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
Not forgetting, simply deferring discussion on that. We’ve a much smaller limit to deal with right now. But even that limit would have to go to remove this attack. From: Btc Drak Sent: Monday, June 08, 2015 3:07 PM To: Raystonn . Cc: Peter Todd ; Bitcoin Dev ; Patrick Mccorry (PGR) Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote: No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size.-- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. Right. And that results in some transactions with insufficient fees getting dropped today after many hours. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. That's no protection against a well-funded private and/or public entity. Without the block size limit, this attack doesn't exist. It would simply result in a transfer of wealth from spammer to miners, which is a nicely antifragile response for the Bitcoin network. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 2:33 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit there is no memory pool cap currently Real hardware does not have an infinite amount of RAM. Memory pool sizes cannot grow unbounded. Some transactions with insufficient fees do get dropped today after many hours. Actually they don't, which is an unfortunate problem with the existing mempool implementation; the only way a transaction can be removed from a Bitcoin Core mempool is through it getting mined, double-spent, or the node restarting. The protection that we have against that attack is that you need access to a lot of bitcoins to pay enough fees. With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram consumed, and furthermore, actually getting that many transactions to propagate over the network is non-trivial. (no, I'm not going to tell you how) The obvious solution is to cap the size of the mempool and evict transactions lowest fee/KB first, but if you do that they you (further) break zeroconf security. On the other hand, if you don't break zeroconf security an attacker can prevent reasonable fee transactions from propagating. I probably should get around to fixing this... -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in China have different bandwidth and connectivity than miners in the U.S., for example. But the block size limit is dictated for eveyone. They are not comparable. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. Meanwhile, everyone would jump on board trying to mine the blocks to collect the fees from the spammers. It could be one of the greatest transfers of wealth ever. Bitcoin infrastructure would build up to handle the required bandwidth, paid for by the very entity spamming the network. Bitcoin would flourish, growing wildly as long as the fees kept coming. This is antifragility at its best. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. No, at attacker flooding the network with transactions with a blocksize limit can keep their fees high enough that perhaps 1% of transactions coming from real end-users go through. At this point everyone would give up on Bitcoin as it would become completely unusable. The BTCUSD market would tank, making it even easier to pay the transaction fees to keep real transactions out of blocks, as it would continue to become cheaper and eventually cost-free to obtain the bitcoin fees through market purchase. -Original Message- From: Peter Todd Sent: Monday, June 08, 2015 2:44 PM To: Raystonn . Cc: Patrick Mccorry (PGR) ; Bitcoin Dev Subject: Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities the means to destroy Bitcoin if they desire. This is only true after the block size limit was implemented. Without the block size limit, the spam doesn’t harm Bitcoin. It simply enriches miners at the cost of the spammers, which is a nicely antifragile quality. There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. Without a blocksize limit the attacker would just flood the network until the bandwidth usage became so great that consensus would fail, rendering Bitcoin both worthless, and insecure. The worst an attacker flooding the network with transactions with a blocksize limit can do is raise costs, without harming security. Keep in mind, that at some point it'd be cheaper to just 51% attack the network. Based on the current block subsidy of 25BTC/MB that's at the point where transaction fees are 25mBTC/KB, which corresponds to $2/tx fees - not that cheap, but still quite affordable for a large percentage of Bitcoin's users right now. And that's the *absolute worst-case* attack possible. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] We are filling most blocks right now - Let's change the max blocksize default
We seem to be experiencing bursts of high transaction rate right now. https://blockchain.info/ shows nearly all blocks full. We should increase the default max block size to 1MB to give us more space where we see the 731MB blocks, as we don’t want to be limited by those who don’t bother to change the settings from the default, and thus probably aren’t paying attention to this whole discussion. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution. Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners. Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well. From: Tier Nolan Sent: Friday, May 29, 2015 7:22 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote: On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com wrote: But if there is still no consensus among developers but the bigger blocks now movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens. How do you define that the movement is successful? Sorry again, I keep auto-sending from gmail when trying to delete. In theory, using the nuclear option, the block size can be increased via soft fork. Version 4 blocks would contain the hash of the a valid extended block in the coinbase. block height 32 byte extended hash To send coins to the auxiliary block, you send them to some template. OP_P2SH_EXTENDED scriptPubKey hash OP_TRUE This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block. To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig. The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash. This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain. The extended chain could use the updated script language too. This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. My opinion is these things are better left to a decentralized free market anyhow. From: Gavin Andresen Sent: Thursday, May 28, 2015 10:19 AM To: Mike Hearn Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction On Thu, May 28, 2015 at 1:05 PM, Mike Hearn m...@plan99.net wrote: Isn't that a step backwards, then? I see no reason for fee pressure to exist at the moment. All it's doing is turning away users for no purpose: mining isn't supported by fees, and the tiny fees we use right now seem to be good enough to stop penny flooding. Why not set the max size to be 20x the average size? Why 2x, given you just pointed out that'd result in blocks shrinking rather than growing. Twenty is scary. And two is a very neutral number: if 50% of hashpower want the max size to grow as fast as possible and 50% are dead-set opposed to any increase in max size, then half produce blocks 2 times as big, half produce empty blocks, and the max size doesn't change. If it was 20, then a small minority of miners could force a max size increase. (if it is less than 2, then a minority of minors can force the block size down) As for whether there should be fee pressure now or not: I have no opinion, besides we should make block propagation faster so there is no technical reason for miners to produce tiny blocks. I don't think us developers should be deciding things like whether or not fees are too high, too low, . -- -- Gavin Andresen -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Trust, regulation, law, and the threat of force. Are you serious? On 26 May 2015 11:38 am, Allen Piscitello allen.piscite...@gmail.com wrote:What prevents you from writing a bad check using todays systems?On Tue, May 26, 2015 at 1:22 PM, Danny Thorpe danny.thorpe@gmail.com wrote:What prevents RBF from being used for fraudulent payment reversals? Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast a double spend of that transaction to pay Alice nothing? Your only cost is the higher network fee of the 2nd tx.Thanks,-DannyOn Mon, May 25, 2015 at 5:10 PM, Peter Todd pete@petertodd.org wrote:On Tue, May 26, 2015 at 12:03:09AM 0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Lets suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 thats 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 thats 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so Im now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1s change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF Id simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF costs you more than you save -- peter[:-1]@petertodd.org 134ce6577d4122094479f548b997baf84367eaf0c190bc9f -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50 applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50 applications Performance metrics, stats and reports that
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
That policy is included in Bitcoin Core. Miners use it because it is the default. The policy was likely intended to help real transactions get through in the face of spam. But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs. At the very least the amount spent should be removed as a factor, or fees are unlikely to ever be paid by those who can afford them. We can reassess the role age plays later. One change at a time is better. On 9 May 2015 12:52 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:43 PM, Raystonn raystonn@hotmail.com wrote:How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesnt support privacy or a reduction in UTXOs.Before starting this thread, I had completely forgotten that age was even a factor in determining which UTXOs to use. Frankly, I cant think of any reason why miners care how old a particular UTXO is when determining what fees to charge. Im sure there is one, I just dont know what it is. I just tossed it in there as homage to Andreas who pointed out to me that it was still part of the selection criteria. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Lack of privacy is viral. We shouldn't encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network. On 9 May 2015 12:17 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wuille@gmail.com wrote:Its a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. Unless the miner determines that the reduction in UTXO storage requirements is worth the lower fee. Theres no protocol level enforcement of a fee as far as I understand it. Its enforced by the miners and their willingness to include a transaction in a block.In addition, it results in more linkage between coins/addresses used, so lower privacy. Not if you only select all the UTXOs from a single address. A wallet that is geared more towards privacy minded individuals may want to reduce the amount of address linkage, but a wallet geared towards the general masses probably wont have to worry so much about that. The only way you can guarantee an economical reason to keep the UTXO set small is by actually having a consensus rule that punishes increasing its size.Theres an economical reason right now to keeping the UTXO set small. The smaller it is, the easier it is for the individual to run a full node. The easier it is to run a full node, the faster Bitcoin will spread to the masses. The faster it spreads to the masses, the more valuable it becomes. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs. Such policy needs to be defended or removed. It doesn't support privacy or a reduction in UTXOs. On 9 May 2015 12:33 pm, Jim Phillips j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:25 PM, Raystonn raystonn@hotmail.com wrote:Lack of privacy is viral. We shouldnt encourage policy in most wallets that discourages privacy. It adversely affects privacy across the entire network.How about this as a happy medium default policy: Rather than select UTXOs based solely on age and limiting the size of the transaction, we select as many UTXOs as possible from as few addresses as possible, prioritizing which addresses to use based on the number of UTXOs it contains (more being preferable) and how old those UTXOs are (in order to reduce the fee)? -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain -Raystonn On 8 May 2015 1:41 pm, Mark Friedenbach m...@friedenbach.org wrote: Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however. On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote: I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to advertise to the network. Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions. In this manner, transactions are never left hanging for days, and probably not even for hours. -Raystonn On 8 May 2015 1:17 pm, Aaron Voisine vois...@gmail.com wrote: As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal. The best argument I've heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users' experience. When users pay too low a fee, they should: 1) See immediate failure as they do now with fees that fail to propagate. 2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future. The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future. We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach. Aaron Voisine co-founder and CEO breadwallet.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Replace by fee is the better approach. It will ultimately replace zombie transactions (due to insufficient fee) with potentially much higher fees as the feature takes hold in wallets throughout the network, and fee competition increases. However, this does not fix the problem of low tps. In fact, as blocks fill it could make the problem worse. This feature means more transactions after all. So I would expect huge fee spikes, or a return to zombie transactions if fee caps are implemented by wallets. -Raystonn On 8 May 2015 1:55 pm, Mark Friedenbach m...@friedenbach.org wrote:The problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated.On Fri, May 8, 2015 at 1:51 PM, Raystonn raystonn@hotmail.com wrote:Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41
Fail, Damian. Not even a half-good attempt. -Raystonn On 8 May 2015 3:15 pm, Damian Gomez dgomez1...@gmail.com wrote:On Fri, May 8, 2015 at 3:12 PM, Damian Gomez dgomez1092@gmail.com wrote:let me continue my conversation: as the development of this transactions would be indiscated as a ByteArray of On Fri, May 8, 2015 at 3:11 PM, Damian Gomez dgomez1092@gmail.com wrote:Well zombie txns aside, I expect this to be resolved w/ a client side implementation using a Merkle-Winternitz OTS in order to prevent the loss of fee structure theougth the implementation of a this security hash that eill alloow for a one-wya transaction to conitnue, according to the TESLA protocol. We can then tally what is needed to compute tteh number of bit desginated for teh completion og the client-side signature if discussin the construcitons of a a DH key (instead of the BIP X509 protocol) On Fri, May 8, 2015 at 2:08 PM, bitcoin-development-request@lists.sourceforge.net wrote:Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body help to bitcoin-development-request@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-owner@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Todays Topics: 1. Re: Block Size Increase (Mark Friedenbach) 2. Softfork signaling improvements (Douglas Roark) 3. Re: Block Size Increase (Mark Friedenbach) 4. Re: Block Size Increase (Raystonn) (Damian Gomez) 5. Re: Block Size Increase (Raystonn) -- Forwarded message --From: Mark Friedenbach mark@friedenbach.orgTo: Raystonn raystonn@hotmail.comCc: Bitcoin Development bitcoin-development@lists.sourceforge.netDate: Fri, 8 May 2015 13:55:30 -0700Subject: Re: [Bitcoin-development] Block Size IncreaseThe problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated.On Fri, May 8, 2015 at 1:51 PM, Raystonn raystonn@hotmail.com wrote:Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain -- Forwarded message --From: Douglas Roark doug@bitcoinarmory.comTo: Bitcoin Dev bitcoin-development@lists.sourceforge.netCc: Date: Fri, 8 May 2015 15:27:26 -0400Subject: [Bitcoin-development] Softfork signaling improvements-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello. Ive seen Greg make a couple of posts online (https://bitcointalk.org/index.php?topic=1033396.msg11155302#msg11155302 is one such example) where he has mentioned that Pieter has a new proposal for allowing multiple softforks to be deployed at the same time. As discussed in the thread I linked, the idea seems simple enough. Still, Im curious if the actual proposal has been posted anywhere. I spent a few minutes searching the usual suspects (this mailing list, Reddit, Bitcointalk, IRC logs, BIPs) and cant find anything. Thanks. - --- Douglas Roark Senior Developer Armory Technologies, Inc. doug@bitcoinarmory.com PGP key ID: 92ADC0D7 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVTQ4eAAoJEGybVGGSrcDX8eMQAOQiDA7anqZBqDfVIwEzY2C SxOVxswwxAyTtZNM/Nm8MTq77hF83j/C3bUbDW6wCu4QxBYA/uiCGTf44dj6WX 7aiXg1o9C4LfPcuUngcMI0H5ixOUxnbqUdmpNdoIvy4did2dVs9fAmOPEoSVUm72 6dMLGrtlPN0jcLX6pJd12Dy3laKxd0AP72wi6SivH6i8v8rLb940EuBS3hIkuZG0 vnR5MXMIEd0rkWesr8hn6oTs/k8t4zgts7cgIrA7rU3wJq0qaHBa8uASUxwHKDjD KmDwaigvOGN6XqitqokCUlqjoxvwpimCjb3Uv5Pkxn8dwue9F/IggRXUSuifJRn UEZT2F8fwhiluldz3sRaNtLOpCoKfPCYYv7kvGySgqagtNJFHoFhbeQM0S3yjRn Ceh1xK9sOjrxw/my0jwpjJkqlhvQtVG15OsNWDzZeWa56kghnSgLkFOT4G6IxB EUOcAYjJkLbg5ssjgyhvDOvGqft2e4MNlB01e1ZQr4whQH4TdRkd66A4WDNB0g LBqVhAc2C8L3g046mhZmC33SuOSxxm8shlxZvYLHU2HrnUFg9NkkXi1Ub7agMSck TTkLbMx17AvOXkKH0v1L20kWoWAp9LfRGdDqnY8svJkaUuVtgDurpcwEk40WwEZ caYBw8bdLpKZwqbA1DL =ayhE -END PGP SIGNATURE- -- Forwarded message --From: Mark Friedenbach mark@friedenbach.orgTo: Raystonn . raystonn@hotmail.comCc: Bitcoin Development bitcoin-development@lists.sourceforge.netDate: Fri, 8 May 2015 13:40:50 -0700Subject: Re: [Bitcoin-development] Block Size IncreaseTransactions dont expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
It seems to me all this would do is encourage 0-transaction blocks, crippling the network. Individual blocks don't have a maximum block size, they have an actual block size. Rational miners would pick blocks to minimize difficulty, lowering the effective maximum block size as defined by the optimal size for rational miners. This would be a tragedy of the commons. In addition to that, average block cinfirmation time, and hence rate of inflation of the bitcoin currency, would now be subject to manipulation. This undermined a core value of Bitcoin. On Fri, May 8, 2015 at 1:33 PM, Mark Friedenbach m...@friedenbach.org wrote: * For each block, the miner is allowed to select a different difficulty (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, and this miner-selected difficulty is used for the proof of work check. In addition to adjusting the hashcash target, selecting a different difficulty also raises or lowers the maximum block size for that block by a function of the difference in difficulty. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to advertise to the network. Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions. In this manner, transactions are never left hanging for days, and probably not even for hours. -Raystonn On 8 May 2015 1:17 pm, Aaron Voisine vois...@gmail.com wrote:As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavins 20Mb block proposal.The best argument Ive heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users experience.When users pay too low a fee, they should:1) See immediate failure as they do now with fees that fail to propagate.2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future.The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future.We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach.Aaron Voisineco-founder and CEObreadwallet.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
