Bitcoin Forum
September 24, 2018, 02:42:03 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 »  All
  Print  
Author Topic: Soft block size limit reached, action required by YOU  (Read 63661 times)
SRoulette
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250



View Profile WWW
March 07, 2013, 03:12:47 AM
 #21

how about no? because I don't want encourage some gambling website to fill up my hard drive with their bets.

Then don't let sdice transactions into your solved blocks, and encourage others to do the same.  Mike didn't say you have to increase the soft limit.  Luke-Jr posted about your other options.

Personally, banning sdice outright seems like the kind of scummy meddling bitcoin is supposed to solve.  I would rather make them pay transaction fees somewhat proportional to the cost they incur on the network.  If they pay them, miners get more money for their trouble, if not, they stop spamming the chain.

It does seem like the decent thing to do, for our casino we simply pay the network requested fees on all out payouts and adjust our margins and payouts to compensate. We even modified our dice game to make losing payouts an option for the players.

We like satoshidice (we kind of have to, we modelled some of our games after them) but we would like to see them take a more active involvement in resolving this issue that affects us all.

Make a difference with your Ether.
Donate Ether for the greater good.
SPRING.WETRUST.IO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537756923
Hero Member
*
Offline Offline

Posts: 1537756923

View Profile Personal Message (Offline)

Ignore
1537756923
Reply with quote  #2

1537756923
Report to moderator
1537756923
Hero Member
*
Offline Offline

Posts: 1537756923

View Profile Personal Message (Offline)

Ignore
1537756923
Reply with quote  #2

1537756923
Report to moderator
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1013


View Profile WWW
March 07, 2013, 03:30:38 AM
 #22

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

What do you mean you have modified the fee settings? Were you not doing what the Bitcoin client has always been doing? In other words: 27kB for storing high-priority transactions (regardless of the fee), and the remainder of the block always preferring fee-based transactions.

And I don't care for satoshi dice. Let them move to litecoin or ban them from spamming the network and my harddrives.

Well. I am partaged on what to think about satoshidice. On one hand they pollute the block chain, but on the other hand they do help stress-test bitcoin's technical limits in the real world relatively early in its history.
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
March 07, 2013, 03:56:09 AM
 #23

Add an additional .001 optional fee in your client and your transaction will be in the next block. The blockchain flooders are cheapskates. Transactions are not supposed to be cheap enough that you can blast hundreds of them out an hour with your gambling bot.

This.

I'm running a timestamping service that's been making about two or three transactions an hour for the past few days, each with 0.0005BTC fees. Looks like about 90% to 95% of my transactions are confirming in the next block, and the rest within another block.

Seriously, if you can't spend a 0.001BTC - a bit less than 5 cents - to publish a transaction that thousands of computers have to verify and store for eternity in the one rock-solid high value decentralized currency known to man, stop complaining. I'm surprised the large-blocks/low-fees group hasn't been compared to the usual socialists wanting to centralize profit and decentralized costs yet... or maybe they have - following the forums with this crap is a full-time job.

You know, my timestamping thing, OpenTimestamps if you want to know,(1) has been called blockchain spam by some. For the technically inclined, no it doesn't bloat the UTXO space, but it does add blockchain space. However, it and other abuses like storing files in the blockchain will naturally be crowded out as transactions become more expensive, so the total damage will always be limited without centralized enforcement efforts like Mike's pleadings for miner's to "stop the satoshidice spam". Already TX fees would cost me $100USD/month to run the timestamper if every block had a timestamp transaction in it, so I'll soon have plenty of reasons to change the way it works, just like the price of gas gives people incentives not to waste it.

On the other hand, if we go ahead and let the maximum block size get as large as miners want, there's no reason not to use it for all sorts of BS things, and little we can do to stop abuse without centralization. Sadly, I suspect as it becomes more and more expensive to participate as a full-fledged miner, instead we'll just see the number of pools decrease, and P2Pool die off from lack of miners, until central efforts to "stop spam transactiosn" start happening, and then you're one step away from "stop silk road" being possible.

1) FWIW, it's not quite ready to be called production yet, but if you can find the software on github, go ahead and try it out.

eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1001



View Profile
March 07, 2013, 04:13:14 AM
 #24

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

What do you mean you have modified the fee settings? Were you not doing what the Bitcoin client has always been doing? In other words: 27kB for storing high-priority transactions (regardless of the fee), and the remainder of the block always preferring fee-based transactions.

The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.

RIP BTC Guild, April 2011 - June 2015
optimator
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile WWW
March 07, 2013, 04:23:41 AM
 #25

I lost a lot of money today because of this shit. And I don't care for satoshi dice. Let them move to litecoin or ban them from spamming the network and my harddrives.

Sorry to hear about your financial loss. That sucks.

But, I must say, it rubs me wrong when I hear complaints about "spamming the blockchain" and the evil of satoshi dice. Where do you see bitcoin going? Do you want to keep it as a little pet or do you want it to become a global currency beyond the borders of governments?

Clearly, the way bitcoin was designed was to encourage the gradual adoption of transaction fees, as those fees will replace the revenue lost from the block reward halvings. However, those transaction fees will go to the miners and the nodes will still need to store the transactions.

I see the "solution" to these problems as designing ways to creatively solve the "problem". For example, implementing a parsed version of the blockchain to remove older transactions.

We shouldn't run from or discourage satoshi dice, we need to embrace it as a precursor of what is to come.

Cheers!

Smoovious
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500

Scattering my bits around the net since 1980


View Profile
March 07, 2013, 06:51:27 AM
 #26

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov
phelix
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000


nmc:id/phelix


View Profile
March 07, 2013, 07:42:40 AM
 #27

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.
this is very interesting and might actually be a good thing that leads to a balanced blocksize. Transactions actually do come at a cost for miners!

[...]
The old settings were default, with the 250,000 byte limit, 27k for high-priority (regardless of fee).  The new settings we're trying (subject to change, and not on all servers yet) is 500kB block max size, no reserved space for no-fee transactions with high priority, and a minimum size set to 50 kB to grab high priority/no-fee transactions if there aren't that many unconfirmed paid transactions.
hmmm...

https://bitcointalk.org/index.php?topic=148211   Can anybody stall Bitcoin for 72BTC per hour?

blockchained.com ■ bitcointalk top posts
johnyj
Legendary
*
Offline Offline

Activity: 1848
Merit: 1000


Beyond Imagination


View Profile
March 07, 2013, 07:50:31 AM
 #28

I don't understand why gaming has to use the blockchain, feels like using armored money transport vehicles to transfer casino chips  Wink

TradeFortress
https://bitcointalk.org/index.php?topic=4589356.0
VIP
Legendary
*
Offline Offline

Activity: 1008
Merit: 1023


View Profile
March 07, 2013, 08:53:27 AM
 #29

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.
Yes, this is a problem because 50% of TXes would never confirm.

✳️✳️Did you lose money in CoinLenders or Inputs.io? Please contact me by Dec 31st, 2018 for a reimbursement | Hashie refunds ✳️✳️
Beware of impersonators! I will ONLY ever email you from admin+g [at] glados.cc or THIS bitcointalk account.
📈Trade on BitMEX with 100x leverage. Get 10% off fees with this link!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
March 07, 2013, 09:38:23 AM
 #30

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.
SatoshiDice does not follow the rules:
The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.
Nor is the system supposed to hold up to flooding. If you go back to even the original paper by Satoshi, miners are expected to filter out flooding attacks like this. The proposed transaction fee solution works in most cases, but not SatoshiDice because they have social-engineered gamblers into covering the fees for them, and to make it worse the gamblers are willing to pay a higher fee than real users. If Bitcoin had achieved critical mass already, we might have been able to just say "too bad, deal with higher fees", but at this pre-adoption stage the response to that would almost certainly be "screw you, I'll stick with VISA".

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.
Yes, this is a problem because 50% of TXes would never confirm.
No, filtering out flooding attacks responsibly improves confirmation time of transactions.

K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
March 07, 2013, 09:49:48 AM
 #31

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.
is there a simple patchfile available to exclude SD?

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
March 07, 2013, 09:56:32 AM
 #32

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.
is there a simple patchfile available to exclude SD?
$ git diff 5b98972..block_dice | wgetpaste
Your paste can be seen here: http://codepad.org/7RQZIkhd

Akka
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000



View Profile
March 07, 2013, 10:03:31 AM
 #33

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov


I agree this is a point.

I know mining is a (mostly) free marked. But this guys are basically hurting the bitcoin users.

Wouldn't it be possible to thread this behavior as an attack on bitcoin, therefor not accepting this blocks, when there is a significant amount of transactions required?

Something like: if unconfirmedtransaktions >= 1000kb and blocksize <= 150kb then
reject block

Of course at least 51% of all miners would have to agree to this, otherwise miners that agree would only hurt them self.

All previous versions of currency will no longer be supported as of this update
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
March 07, 2013, 10:08:14 AM
 #34

Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.

As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.

Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.

That is the big problem.

-- Smoov


I agree this is a point.

I know mining is a (mostly) free marked. But this guys are basically hurting the bitcoin users.

Wouldn't it be possible to thread this behavior as an attack on bitcoin, therefor not accepting this blocks, when there is a significant amount of transactions required?

Something like: if unconfirmedtransaktions >= 1000kb and blocksize <= 150kb then
reject block

Of course at least 51% of all miners would have to agree to this, otherwise miners that agree would only hurt them self.
It's not that simple. For example, it's pretty common for SD's flooding to fill more than 1000kb, so your rule would reject blocks from only the responsible miners.

K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
March 07, 2013, 10:10:21 AM
 #35

Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.
My git repository contains a "block_dice" branch to do just that.
The 0.8.0.eligius branch designed specifically for miners and pools also includes this.
Gavin also wrote up some more advanced configuration option examples here.
is there a simple patchfile available to exclude SD?
$ git diff 5b98972..block_dice | wgetpaste
Your paste can be seen here: http://codepad.org/7RQZIkhd

thanks Smiley

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
dustintrammell
VIP
Full Member
*
Offline Offline

Activity: 153
Merit: 100



View Profile
March 07, 2013, 10:37:46 AM
 #36

I don't understand why gaming has to use the blockchain, feels like using armored money transport vehicles to transfer casino chips  Wink

It doesn't, and in my opinion is the wrong thing to do.  My site, BitDraw (provably fair features coming soon!) of course uses the blockchain to process deposits and withdrawals, as it must, but all other transactions between players, or between the players and the site, are handled within our system and are not exposed to the blockchain.

Further, games, applications, and other sites that are integrated directly into the Bitcoin network have increased attack surface.  By being integrated, they necessarily must have direct access (or a more intricate abstraction layer) to either bitcoind or the Bitcoin network directly.  This means that they have access to one or more wallets, which increases the risk of funds in those wallets being stolen by an attacker that compromises that system.  BitDraw avoids this entirely by using an offline wallet, not having any access to it from the web application or server itself, and handling withdrawals via manual processing.  The latter won't scale, but we'll address that when it actually becomes an issue.
dustintrammell
VIP
Full Member
*
Offline Offline

Activity: 153
Merit: 100



View Profile
March 07, 2013, 10:44:05 AM
 #37

The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.

Would the latter two of those "messages" not represent a transfer of value, of which you just stated that Bitcoin is a system for?  I presume (I haven't looked at exactly how Satoshi Dice works) that when you place a wager, the player is transferring value to Satoshi Dice.  Then, if they win, Satoshi Dice is transferring value back.  I see no transfer of value in the "You Lose" message as I would assume Satoshi Dice keeps the value, so I completely agree with you there, that would be a completely informational message.
hazek
Legendary
*
Offline Offline

Activity: 1078
Merit: 1001


View Profile
March 07, 2013, 10:54:26 AM
 #38

Where is the foundation during the only moment we need it?

Where it should be - silent.

My personality type: INTJ - please forgive my weaknesses (Not naturally in tune with others feelings; may be insensitive at times, tend to respond to conflict with logic and reason, tend to believe I'm always right)

If however you enjoyed my post: 15j781DjuJeVsZgYbDVt2NZsGrWKRWFHpp
Luke-Jr
Legendary
*
Offline Offline

Activity: 2422
Merit: 1011



View Profile
March 07, 2013, 10:56:44 AM
 #39

The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.

Would the latter two of those "messages" not represent a transfer of value, of which you just stated that Bitcoin is a system for?  I presume (I haven't looked at exactly how Satoshi Dice works) that when you place a wager, the player is transferring value to Satoshi Dice.  Then, if they win, Satoshi Dice is transferring value back.  I see no transfer of value in the "You Lose" message as I would assume Satoshi Dice keeps the value, so I completely agree with you there, that would be a completely informational message.
While there is a value attached to the latter two, it is primarily a message. Otherwise, a gamer would just transfer a deposit, play, and withdraw (as I notice your site does) - no message passing involved.

For an easy analogy, this would be like WalMart charging your credit card for every item you pick up off the shelf, and refunding you if you put it back (actually worse, since SD uses 2 transactions for every action).
Not even VISA/MC could handle that kind of abuse, and their system (being centralised) is far more efficient than Bitcoin.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526
Merit: 1006


View Profile
March 07, 2013, 11:05:57 AM
 #40

BTC Guild started setting up a new server this morning running modified block rules.  Currently trying out a 500,000 byte maxblocksize.  The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more.  I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.

I'm actually hopeful that you won't notice much difference in propagation times.

We're talking about 500kb data structures here. Any mining pool worth its salt is running out of decent colo facilities in the USA or Europe with good connectivity. Transmission time is negligible at current sizes. The slow part is validation and disk IO. However Bitcoin 0.8 has two features that should make acceptance of a new block fast:

1) The signature cache means that when you see a transaction appear in a block, you are very likely to have already checked its signatures when it was previously broadcast through the memory pool (your node is "warm"), so there's little or no ECDSA computations required.
2) LevelDB means the difficult parts of managing the disk is done on a separate thread. In theory you should need only a handful of disk IOPs to accept a new block because all the compaction is done on a separate core in the background.

I think it should be quite feasible to accept and announce a new block in something like 30-40 msec.

So I'll be very interested to see if practice matches theory - if it does then you should not see a 2x propagation time, certainly not more than 2x. And if you do then we just need to fix it Smiley
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!