Bitcoin Forum
July 12, 2024, 02:08:34 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 [540] 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 ... 800 »
10781  Economy / Trading Discussion / Re: Mt Gox thinks it's the Fed. Freezes acc based on "tainted" coins. on: March 24, 2012, 03:19:27 PM
Dear Mt.Gox,

why do you allow unverified people to trade money for BTC, if you're trying to help the cops with "tainted" coins? I think there are a lot of "tainted" coins....

There are not many tainted coins. Except during big events such as the Linode hack, we rarely see any tainted coin hit us at all.

please define term "tainted coin" exactly!
i would love to have a way to check any deposit beforehand.

It is a secret list.   You will find out when your account is frozen.

What could possibly go wrong with unelected third parties using secret internal list to seize the property of others without oversight or accountability? 
10782  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 03:14:59 PM
Once again making a distinction of paying vs non paying is dubious.

1 satoshi is paying.

If every transaction had a 1 satoshi fee the avg block would contain 0.0000008 in fees.
The entire network annually would produce ~ 0.0292 BTC in fees.

So paying vs non paying is a dubious distinction.

Going forward (once I have modified bitcoind and tested it) I will be excluding ALL transaction with < 0.01 BTC in fees.  I will also share the patch as open source and encourage other miners to adopt similar minimum fee rules (although each miner could choose a different amount).

Do you believe I should not be allowed to exclude fees I consider insufficient?  
More generally:  Do miners have a right to charge that amount they expect in an open and free marketplace for fees?  

People like to use the term boycotting (as in the above post).  If no tx had a fee of 0.01 BTC+ and as a resulted I mined a 1 tx block would that be boycotted.  What if I included a single dummy tx of my own (1 BTC from me to me with 0.01 BTC fee to me)?
10783  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 02:12:44 PM
If those tx are free I am forced to include them or have my block rejected?

If 100% of transactions coming through are free you would be forced to include some, but realistically there are always enough paid transactions that you can meet the 25% quota easily.  If you only include 25% during an "all free transactions" hour, people will have an incentive to include a fee to get their transaction included sooner (4x sooner on average in this case).

25% is just an example; pick a value that will accommodate any reasonable miner's include/exclude policy.

Really have you looked at the last dozen or so blocks?

90%+ are free and 0% have a fee of 0.01 or higher.  So 100% are free or so worthless as to be essentially free.

So you saying "miners can set their own fees" is a blatant lie if the same miner is then forced to include free (and near free) tx.  If clients know miners are forced to include their freeloading tx what is the incentive for them to pay a realistic fee.

Of course that ignores all the timing attacks, orphaned blocks, and network latency issues any such proposal will have.  A hint: there is no unified view of the network.  Propogation delays ensure parts of the network are always out of sync.  So a miner cutting it close risks having some nodes see the block as valid but others (who just picked up new tx) see it as invalid.

Also it makes tx processing less efficient.  Most pools don't update getworks when new tx arrive however to meet the 25% treshold (which is likely 50% threshold just to be safe) they would either need to issue an LP on every tx and include even MORE free tx so that as new tx arrive they stay above the safe limit.

Essentially all that combined means miners have no pricing power (they already have very little).  All this to solve a non-problem.  Sorry no thanks.
10784  Other / Off-topic / Re: Butterfly Labs - Bitforce Single and Rig Box on: March 24, 2012, 02:02:00 PM
Yeah 6ft is way too long for that kind of current.  If you want 6ft cables then they should be 16 (or even better 14) gauge wire.   Also I wish you had a better PSU.  Even with 30W or so lost due to excessive wiring the efficiency seems very low for 80Plus-Gold unit.  You don't by any chance have any xfx, seasonics, antecs or other tier 1 supplier PSU lying around do you?
10785  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 01:58:29 PM
I don't see the need for mandatory tx fees.  What's wrong with simply refusing to relay blocks that don't include at least ( ( n * 0.25 ) - 5 ) transactions, where n is the number of valid transactions broadcast since the last block?  Empty blocks would be allowed during slow times or when a block was recently sent (the -5), and the 0.25 would let you be reasonably selective about what you mine.

If those tx are free I am forced to include them or have my block rejected? 

Where do people get this idea you have the right to have your free or cheap ass (1/10th of a penny) tx forced into the next block.
10786  Economy / Computer hardware / Re: watercooling gear and some ram stuff for sale!(updated) on: March 24, 2012, 01:43:09 PM
Your img is broken.
10787  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 24, 2012, 01:28:59 PM
No blocks are mined until a match is found. Then a miner with 100 BTC fee, would be able to provide his "quality" service, without hampering the flow (event if it's insignificant at this moment). This way there will be competition among high fee miners and low fee miners, without the high fee miners going on strike and milking the network at the same time.

Forget that.  You do understand the logical end game is that miners have no pricing power (they already have very little).

You can set your prices but if nobody agrees to them then you lose the potential block reward.  Thus the one is forced to accept free & no fee tx and clients would be stupid to ever pay a fee (or more than a token fee).

Also not sure if you see the logical fail in your "proposal".
I set my fee to 100 BTC.  I send a tx w/ 100 BTC to myself and include it in my block.  Tada that block is now valid right?  I never mine any tx except my own.  Kinda bypasses any security such an asinine protocol rule would create.
10788  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 24, 2012, 04:41:44 AM
Where all of your nonsense breaks down is that there is no possible fee that would get this guy to include your transaction because he isn't even looking at transactions.

How do you know?  Have you tried?

A more practical example is that in the near future I will be only including tx w/ fee of 0.01 BTC.  Now about 90% of blocks will be empty (looking at past record of tx).  Do you think I shouldn't be allowed to do that?

What if "mystery" simply has an unrealistic min fee (say 100 BTC per tx)?  Is he not allowed to do that.

It comes down to:
Do miners have the right to set the min fee for tx they will include in the next block?
If no then I will fight any proposal you try to cram down the throats of miners.  If yes then that will lead to genuine empty blocks.  How do you penalize "bad" empty blocks from blocks which are empty simply because users are cheap?


I'd be willing to bet $100 of my own real money that this is a botnet.  The evidence so far points seriously towards a botnet that operates by distributing only the bare minimum of information (the previous block's hash) to the nodes, which then generate a valid block themselves and try hashes.  If anyone can provide convincing proof that this is something else, I will mail the first person to do so a check or send them the equivalent in BTC.
[/quote]
10789  Bitcoin / Mining / Re: Wonder who this solominer is? 88.6.216.9 on: March 24, 2012, 04:38:01 AM
The difference between this miner and other miners, is that this miner is a parasite.  It's not providing any services, but reaps the rewards. 

First a service is provided.  It adds nearly 15% hashing power to the network.  The network is harder to attack at 11.5 TH/s vs 10.0 TH/s.

Quote
I agree that miners should be able to set tx fees, but they should be able to mine only containing tx that match their fees, but no empty blocks.

Those two statements are mutually exclusive. 

How do you know the "mystery" miner isn't doing that.  It just happens to be his fee threshold is 100 BTC.

More realisticly say I wanted to only include tx which have a fee of 0.01 BTC or more.  Most blocks would have no tx.  How do you reconcile the statements a miner should be able to set fee BUT not include empty blocks?  What if no tx match the desired fee?
10790  Bitcoin / Pools / Re: [340GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: March 24, 2012, 04:28:53 AM
Need clarification on how p2pool builds a block header.

Does this sound right?
1) p2ool uses RPC call "getmemorypool" to get block components from bitcoind
2) p2pool generates coinbase transaction from current sharechain
3) p2pool generates merkle tree (combining tx from bitcoind w/ coinbase from sharechain).
4) p2pool issues block headers to miners via getwork call (prior block, timestamp, merkle tree root, difficulty)

Right?  Wrong?  Clarifications?
10791  Bitcoin / Bitcoin Discussion / Re: How to make merchants aware of Bitcoins advantages? on: March 24, 2012, 04:16:16 AM
My comment was more a warning.  Bitcoin is 0.x for a reason.  I don't want to discourage adoption but there are significant challenges and not all of them technical.  A major business having coins frozen would be a PR disaster for Bitcoin it would undermine all the claims we make.   The reality is not all businesses are ready for Bitcoin because Bitcoin isn't ready for all businesses.  I think a slow increase in adoption in terms of users, merchants, software, etc is the best path.  

In time I think any challenge can be resolved.  It likely will require a lawsuit when certain exchange freezes the wrong account and a six or seven figure settlement but it will be resolved.

Sorry for the semi-derail.  Just been a hard day with some wanting to force miners to include tx and exchanges up to the iodiocy of freezing accounts based on secret lists.   Angry
10792  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 03:59:17 AM
Whatever list is used by 51% of miners will orphan out any other chain.  

Why?

51% of miners follow a list which says tx A must be included.
49% of miners follow a list which don't.

It is no different than a 51% "attack".

The 49% may solve a block BUT that block will be ignored by the miners in camp "A".  Eventually the A camp will pull ahead and orphan all the blocks of the 49%.

So say current block height #123
Both camp A & camp B work on block #124.
A miner in camp B solves block #124 but it is missing tx from "A" list.
Miners in camp A invalidate block #124 and continue to build off of #123.

Due to variance "camp b" may pull ahead temporarily but just like a 51% attack eventually camp A will pull ahead and orphan the chain supported by the "B" miners.

This means whatever list is used by 51% must be used by all miners.  That gives massive power to those who control a lot of hashing power like the Big 3 pools.  If the Big 3 pools make "list A" they even miner is defacto forced to use it.  To not use it is economic suicide as any block the mine which is not in compliance with the "list A" risks being orphaned.  No miners is going to take that chance.  All miners will be forced to follow the rules set by the Big 3.

The Big 3 then could decide not to share the list with all miners (permanent mining exclusion unless the excluded gain 51% of hashing power), charge fees for inclusion (think of it as a pool fee but they don't even have to provide a pool), or share "hidden tx" between themselves to orphan out miners not paying to mine.  If only those paying for access to the list know of the list and hidden tx then outside miners can't even hope to compete by including all tx (even every free one) blindly hoping to make a compliant block.  Even if they include all tx they know of they will be missing the hidden ones.
10793  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 03:07:39 AM
Currently, it is possible to get a tx pushed with no fee, but the commit times are horrible and there's no guarantee that it will even work. Nothing really changes here, and miners can still do whatever they want, however stupid it may be.

Haplo please learn the protocol before you try to "fix it".

Unless your tx is considered spam (under the 1 day & 1 BTC threshold)  there is no need for a fee and confirmation times are routinely the next block.
10794  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 03:05:21 AM
You're misunderstanding the proposal. Anyone who is verifying the chain can publish a list. Lists can use any fee rules. For example, Bitcoin Block Explorer might publish lists at /q/getValidationProof/minFee, which would only list transactions with a fee above minFee. Under this system, dumb miners would be able to choose essentially arbitrary fee policies; they'd just be forced into mining only properly-verified transactions and blocks.

Of course they would.  Whatever list is used by 51% of miners will orphan out any other chain. 
10795  Economy / Trading Discussion / Re: Mt Gox thinks it's the Fed. Freezes acc based on "tainted" coins. on: March 24, 2012, 02:47:29 AM
Who says the POLICE are not asking for the info? MtGox has repeatedly stated that they will comply with investigations of this sort, and just because they don't come right out and say that the cops are currently asking for the info doesn't mean that it isn't happening. Furthermore, the investigators don't know shit about bitcoin, and it is certain that they would just ask for as much evidence as could be mustered in bulk, instead of doing their own gumshoe work. I expect that this will remain the status quo for quite a while yet.

That is the whole point.  We don't know.

If Mt.Gox policy was "we will freeze account and seek account information when facing court order or legislative requirement" we wouldn't even be having this discussion.

there policy is they will freeze accounts which may seem suspicious based on whatever they feel is suspicious and release funds based on whatever they decide is good enough.

The first is called due process, the second is called bullshit.

Say I sold you a video card and you paid me then I said wait these coins are tainted I need to freeze them based on my internal policy of coins looking suspicious and stuff.  I then demand you provide me say photocpies of your ID, your mothers maiden name, your SSN, full address, phone numbers and everything else I need to commit identity fraud.   When you say no well I guess I need to keep those funds frozen.  They Police might want them.  Sorry.

You would be getting me a scammer tag overnight.  However Mt.Gox does the same thing and people fall in line and say "they have to".  Really?
10796  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 02:41:06 AM
Why would a rational miner want to allow free tx forever?

Thanks for explaining it theymos but I like it less now with the explanation.  

For example in the last block:

http://blockchain.info/block-index/197728/0000000000000628467e112dd0aca3b6e5abbdd12cbd1b79074c446e85a2689d

there was 0 tx with a fee of 0.01 or higher?

So if majority of miners include a list with these tx I am forced:
a) to mine for nothing
b) to risk my block being considered invalid

Horrible idea.  Mining should be an open free market and if I don't want to include any tx without a sufficient fee I should be able to.  

More centralization for nothing.

If DeepBit and Slush built a shared list they could
a) determine pricing of entire bitcoin economy
b) force other pools to pay for access to the list or risk them building invalid blocks
c) to aid in b they could witholding tx from the list and publish them only to subscribers (if you don't pay you can't mine)
10797  Bitcoin / Bitcoin Discussion / Re: the ability to crack current public encryption. on: March 24, 2012, 02:34:52 AM
To support rjk, WWII spawned a whole host of computers to do everything from breaking German codes to designing better bomber targeting scopes.
10798  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 02:30:38 AM
When there are conflicting lists? Sad
When the list contains free tx and I as a miner don't want to include them? Sad

Wouldn't it be in the best interest of free-loader nodes to publish and follow lists which put all free tx into the required list thus ensure free tx on the backs of miners?

It comes down to a fundamental question:
Do miners have a right to set the price for their services and thus indirectly choose which tx are included in the block they are working on?
10799  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 02:19:30 AM
Under gmaxwell's proposal, the miner would need to include exactly the transactions specified by the person who verified that the transactions and the previous block were valid. So if blockchain.info published a set of 10 verified transactions, the miner would have to include all 10 of them.

Specified by whom?  The person who solved the last block?  If so why aren't the transactions in their block?
10800  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 24, 2012, 02:15:04 AM
Well, you wouldn't be doing very good business if you actually had to depend on tx fees, which is mostly the point. Admittedly it's a difficult problem to define an acceptable threshold, but if push comes to shove it could be done. However, unless a lot of miners start purposefully killing their tx throughput that shouldn't be an issue at all. If mystery really is running sans a blockchain, which seems to be the case, then only he would be affected since the stingy miner can still produce the minimum verification, whereas mystery could not.

But it is my choice right?  Or is the choice on what is an acceptable fee decided by the cental agency of bitcoin fees? I have a right to charge whatever amount I want for my hashing power.  Do you agree?  As the subsidies decline the market will be more competitive but it is still my choice.

If tx MUST be included then does that include all free tx.  Am I now forced to include all free tx?  What incentive is there for a user to pay any fee then?

Does it include all tx w/ a fee?  If so then why every pay more than 1 satoshi?
Does it include all tx w/ a "minimum defined" fee?  Say 0.0005 BTC.  If so then why would any user pay more?

If someone says you must include 25% of all pending transactions... well what if those transactions are below my processing cost (because the users are cheap bastards)?  I am forced to include them or lose the block?  Really?
Pages: « 1 ... 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 [540] 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 ... 800 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!