 Show Posts
|
|
Pages: « 1 2 [3]
|
diff --git a/src/main.cpp b/src/main.cpp
index 9a06dbf..d3fba73 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -384,8 +384,16 @@ bool CTransaction::IsStandard() const
BOOST_FOREACH(const CTxOut& txout, vout) {
if (!::IsStandard(txout.scriptPubKey))
return false;
+ if (txout.scriptPubKey.size() > 6
+ && txout.scriptPubKey[0] == OP_DUP
+ && txout.scriptPubKey[3] == 0x06
+ && txout.scriptPubKey[4] == 0xf1
+ && txout.scriptPubKey[5] == 0xb6)
+ return error("CTransaction::IsStandard : ignoring transaction with 1dice output");
if (txout.nValue == 0)
- return false;
+ return error("CTransaction::IsStandard : ignoring transaction with 0 value output");
+ if (txout.nValue <= 10000)
+ return error("CTransaction::IsStandard : ignoring transaction with dust output");
}
return true;
}
You may not be interested in the if (txout.nValue <= 10000) test, though it also gets the dice you-lost transactions and other UXTO set bloating flood. This will make the node not relay or mine these transactions. It will, of course, still accept them in blocks. Is that what I asked? If so, can I send the 1 BTC to the address on your sig or do you prefer to PM me a new address? That rule you mentioned, it drops all tx's which are less than 10k satoshis, right? I tried this patch. It seems to have an unintended consequence. My test setup is: Full client "bitnode1" is well-connected to the internet, with something like 70 connections to other nodes. The patch was applied to this node. Full client "bitnode2" is behind a firewall and is connected *only* to "bitnode1". This client was unpatched. Good results: bitnode1 drops a ton of tx packets. The poolsz doesn't build up like it was doing before the patch. bitnode2 never receives an SD tx packet. The poolsz remains small. Not great results: There are a lot of orphan transactions, because the simplistic logic can't reject all of the response transaction packets from SD. Unintended result: When a block comes in from a miner that has included SD transactions, it appears to take my nodes longer to process the block. Bitnode1 takes several seconds longer to perform its validation, so bitnode2 gets the validated block several seconds later. Then bitnode2 takes several seconds longer to perform its validation. This *could* be my imagination, because the content of blocks are so widely varied. And I haven't examined the code carefully. My hunch is that by throwing away the SD tx packets, bitnode1 denies itself the opportunity to validate those tx packets in advance. Bitnode1 also denies bitnode2 the opportunity to validate those tx packets in advance. This patch *does* reduce main memory requirements for the nodes that toss out SD transactions. And it does reduce the node's outgoing bandwidth. However, as long as *any* miner is including the SD packets, the validation still has to get done by every full node in the world. And the SD transactions still have to be stored in the blockchain on every full node in the world. If a mining pool were to use this simple patch, it may cost themselves and their contributors more stale shares. |
|
|
|
Changing the hash algorithm every 6 months would tend to thwart those (governments, large corporations, or large syndicates) who can afford to invest in ASIC technology. Software that can adapt (almost) instantly (to a change of the constant used in Round 37 of the SHA1 algorithm, for example), puts the mining back in the hands of the regular people who operate the nodes...
You would have been a load of fun after the invention of the Gutenberg printing press: Changing the fontsize every few days would tend to thwart those who can afford to invest in Gutenberg printing technology. Scribes who can adapt (almost) instantly (to a change of the lettering size, for example), puts publishing back in the hands of the regular people who operate the quills...
Do you disagree with the goal of reducing the ability of a large entity from controlling Bitcoin. Or do you disagree with my (admittedly novel) approach? |
|
|
|
|
Where to begin??? Yes, I'm new to this forum. But, I have been observing Bitcoin as an outsider for quite a while.
By and large, I agree with LukeJr. SD is spam. Imagine a real-world Las Vegas style casino sending a transaction to every other casino around the world (and perhaps to every gambler (and perhaps to every person with money in their pocket)) every time a customer pulls the handle on a slot machine. The SD model is insane and completely unsustainable.
Those who equate Bitcoin with Gold are also rather extremists. Perhaps in the old west you could buy a whiskey for some gold dust. But I've never bought a latte with a shaving off a gold coin.
Those who demand higher fees are ignoring the reality. As it stands now, those who operate full nodes bear the burden of the SD-like spam. Yet, there is no fee or reward paid to run such a node. [Back when bitcoin started, any full node who wanted compensation was occasionally rewarded by solving a block. Now that is infeasible.] If things aren't changed, the only people who will run full nodes are the mega-miners. And consolidated centralized control is only a few mergers away.
As has been discussed elsewhere, the receiver of funds (not the sender) should specify the level of certainty they want in assuring their received funds are valid.
Clearly a 1 Satoshi speck of dust doesn't require the level of confirmation as a 10,000 BTC transaction. Without a change to the protocol, there is no distinction. But all such protocol changes I've seen discussed have flaws. Some research effort should be extended to figure this out. Meanwhile...
In block 224588, someone paid a 94 BTC fee. I presume this was a mistake. On the other hand, as I suggested in another thread, perhaps this is intended as a means of laundering tainted money into clean money. If I had the resources to operate a mining pool, I think I would *only* include transactions with *no fee*. [How else do you guarantee you are receiving non-stolen money in your block reward?] [How else do you avoid the moral conundrum and substantial effort of "returning" the (obviously erroneous) transaction fee of US$4000 to the rightful party?]
In my view, the only realistic long-term solution is one that eliminates centralized control of mining pools.
Changing the hash algorithm every 6 months would tend to thwart those (governments, large corporations, or large syndicates) who can afford to invest in ASIC technology. Software that can adapt (almost) instantly (to a change of the constant used in Round 37 of the SHA1 algorithm, for example), puts the mining back in the hands of the regular people who operate the nodes and suffer the burden of ever-increasing block-chain bloat. With 10,000 people deciding what they will include or exclude from their mined blocks, Bitcoin might again become a decentralized currency.
Furthermore, if it is in the *system's* best interest to pass transactions, even as their number and size increases, then the inherent reward created by generating a block should be *increasing*, not decreasing by half every four years.
|
|
|
|
Transaction with 94.35425882 BTC paid in fees. Just a hypothetical question: If the 94.35425882 were stolen, is the entire output of the generation transaction now "clean money" or is everything, including the virgin 25BTC, now "dirty money". And could miners deliberately use this technique to launder dirty money? And if a miner wanted to ensure he mined perfectly virgin, untainted, clean money, does the miner have to reject all transactions that include a fee? What's the consensus? |
|
|
|
I'm sorry about that. Send me your address and I will pay you for that solution. Thank you, ThePiachu! I am satisfied with the resolution. [ThePiachu paid 2.5 x the value of one solution.] I expect to try some work on other (harder) vanity addresses. |
|
|
|
The server has been updated ... and has finished updating / reindexing / synching. I am still getting the message "Problem sending payment. Please try again later" when I attempt to upload a solution. Has anyone had any success in the last 4 days? Hmm, it appears that it was a small glitch in my pool that thought the payment was already sent. I sent some extra money to that address so it should be claimable once everything confirms (the bounty should update when that happens). I see your transaction has 3 confirmations. So, I resubmit my solution. Now, I get "Database error - can't find the requested work. Please try again later". And I don't get paid. I've sent you five PM's over the last for 4 days. And I've gotten five very prompt responses, which I appreciate.  But I guess you didn't actually investigate the problem until I posted on the Forum, today.  The solution that appears on your "solved work" page resolves to a vanity address of: 1FreedomXf1bkjBHtpWVBqvyTkXXXXXXXX But *my* solution, which I attempted to submit 4 days ago has a vanity address of: 1FreedomWhKGsz6GBJxSQHdFpCXXXXXXXX Meanwhile, my computer wastes its time computing another: 1FreedomdZ9WCyf7sEvkagr6MHXXXXXXXX So, I guess your server has been wonked for at least 4 days. Which caused me and my server to waste our time. Are other "available work" addresses also wonked? You seem to have a good reputation on this Forum, but my first experience with your vanity server and your "little glitch" has been a lot of trouble for no pay. If I choose to work on any other solutions, how can I have any confidence I will be paid for my solutions? |
|
|
|
The server has been updated ... and has finished updating / reindexing / synching. I am still getting the message "Problem sending payment. Please try again later" when I attempt to upload a solution. Has anyone had any success in the last 4 days? |
|
|
|
|
1ThxRzma8Eazactw2m3xaEN1YihYst1ZC
Thank you.
|
|
|
|
Very generous, Gareth! So generous, in fact, I clicked the link in your signature to learn about your company. But, I'm sure you know your entire Web Site is down, as my attempt to visit yielded a page saying, essentially "We'll be back up on Monday". So, I guess I'll try again on Monday. Cheers! |
|
|
|
|
Thank you for the advice.
|
|
|
|
|
LeozTt1vYHiVk88L8tjLqzqZg8DDg5Q7ke
|
|
|
|
|
Hi. I am Blowfeld. Some think I am the nemesis of James Bond.
|
|
|
|
|
I have been viewing this Web Site for weeks, if not months. Never found a need to post, until now. The author of vanitypool.appspot.com only lists this forum as a means of contact. Perhaps posting this message will unlock my account so I can send a PM. [Do I really have to spam the Newbies area with five messages? Seems like it sets a bad precedent for users who would otherwise behave nicely. Oh well.]
|
|
|
|
|
