Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 112. (Read 1061417 times)
September 11, 2014, 09:09:42 PM
Weird. Why would people jump like that?
September 11, 2014, 08:07:42 PM
Somebody added a whole bunch of hashrate to the pool today. Glad to see it. I have been forced to move miners a few times due to pool not growing with the network hashrate and eventually shriveling up and dying. Eligius is still behind the curve on that one overall compared to when I started here, but a 20-30%ish jump in one day is nice to see.
While the jump is nice, I believe it is from the same person/entity who jumps on from time to time... and leaves soon after.
Hopefully they've determined that it would be best to stay this time, since this is the longest I've seen them around.
They left. Bummer.
September 11, 2014, 02:55:30 PM
Somebody added a whole bunch of hashrate to the pool today. Glad to see it. I have been forced to move miners a few times due to pool not growing with the network hashrate and eventually shriveling up and dying. Eligius is still behind the curve on that one overall compared to when I started here, but a 20-30%ish jump in one day is nice to see.
While the jump is nice, I believe it is from the same person/entity who jumps on from time to time... and leaves soon after.
Hopefully they've determined that it would be best to stay this time, since this is the longest I've seen them around.
September 11, 2014, 02:53:59 PM
Somebody added a whole bunch of hashrate to the pool today. Glad to see it. I have been forced to move miners a few times due to pool not growing with the network hashrate and eventually shriveling up and dying. Eligius is still behind the curve on that one overall compared to when I started here, but a 20-30%ish jump in one day is nice to see.
September 10, 2014, 10:51:59 PM
hey Luke-jr, could your spam filter be used on something like p2pool?
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
Sure, it's on my personal git repositories as the "spamfilter" branch - merge it to whatever you're normally running.From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
I'll probably try to do a 0.9-based mining branch sometime soon with that and more miner features...
sorry mate can't see it. could you link me please?
thanks mate, will check it out.
September 10, 2014, 09:56:31 PM
you Heathens need to pray to the True God and his St.Eligius 
September 10, 2014, 09:31:49 PM
hey Luke-jr, could your spam filter be used on something like p2pool?
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
Sure, it's on my personal git repositories as the "spamfilter" branch - merge it to whatever you're normally running.From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
I'll probably try to do a 0.9-based mining branch sometime soon with that and more miner features...
sorry mate can't see it. could you link me please?
September 10, 2014, 08:43:25 PM
hey Luke-jr, could your spam filter be used on something like p2pool?
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
Sure, it's on my personal git repositories as the "spamfilter" branch - merge it to whatever you're normally running.From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
I'll probably try to do a 0.9-based mining branch sometime soon with that and more miner features...
sorry mate can't see it. could you link me please?
September 10, 2014, 08:25:24 PM
hey Luke-jr, could your spam filter be used on something like p2pool?
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
Sure, it's on my personal git repositories as the "spamfilter" branch - merge it to whatever you're normally running.From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
I'll probably try to do a 0.9-based mining branch sometime soon with that and more miner features...
September 10, 2014, 07:43:12 PM
hey Luke-jr, could your spam filter be used on something like p2pool?
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
From my understanding of the ability to inject non-financial data into the blockchain, it would make sense to filter this "junk" out to guarantee the integrity and efficiency of the ledger.
September 10, 2014, 03:28:58 PM
found a block a couple mins ago
September 10, 2014, 03:21:21 PM
Awesome... I live for these long rounds.... 
September 10, 2014, 02:55:30 PM
WOW Eligius is having Terrible luck, over 16 hours and no blocks found. Not good.
happens every once in a while.
September 10, 2014, 02:53:30 PM
WOW Eligius is having Terrible luck, over 16 hours and no blocks found. Not good.
September 10, 2014, 12:52:55 PM
The code forms the entirety of the social contract. "Code" referring to officially sanctioned code that comes out of the official Bitcoin developer team. This code defines a set of rules, which enables trustless transfer of value. While I do agree with the goal (and indeed the necessity) of decentralization, I think that it can be taken too far. Everybody needs to play by the same set of rules. I don't think that some miners choosing to mine X transactions, while other miners reject them, is a good idea. There needs to be consistency between miners in order for the network to perform in a predictable manner, and performing in a predictable manner is the only way that Bitcoin will see greater adoption. (I seriously wanted to punch somebody when I sent like $500 worth of BTC in a straightforward transaction, and it wasn't confirmed for hour after hour due to the QT client not including a mining fee.... having that money out in unconfirmed limbo, when I could have included a 10¢ fee that would have gotten it included in the next block, was infuriating. But no, the fee wasn't even an option in the QT client. This is the kind of thing that makes end-users abandon a platform forever.)
The code is the Constitution, if you will. It defines the rules. There is no judicial branch to interpret the code. Just the code. There is no dicta, no Talmud, no human intervention, no wiggle room. Either a transaction fits the rules of the code, or it doesn't. Pure algorithmic consensus. This is the promise of Bitcoin, the great problem solved by Satoshi.
No, the code is just an implementation. At most, it defines the protocol. That's just part of Bitcoin - and not the part responsible for the spam filtering. Miners are another part, responsible for that.The code is the Constitution, if you will. It defines the rules. There is no judicial branch to interpret the code. Just the code. There is no dicta, no Talmud, no human intervention, no wiggle room. Either a transaction fits the rules of the code, or it doesn't. Pure algorithmic consensus. This is the promise of Bitcoin, the great problem solved by Satoshi.
The code of the reference client (more specifically, bitcoind) IS Bitcoin. It is the DNA that directs the cell. It is the blueprint that defines the house. You could lose everything else -- cgminer, pool management software, whatever -- and Bitcoin could survive on just bitcoind alone.
The reference client implements a fee system. If this fee system is not honored by miners, how is the average user going to be able to trust Bitcoin?
Miners should be running with their own customisations of it.
Bitcoin is trustless regardless of the individual policies of any given relay node or miner.
The Qt client allows you to choose not to include a fee, if you don't want to and it thinks that you should. But, AFAIK, it does NOT allow you to arbitrarily add a fee to a transaction that it thinks should be fee-free.
You have that backward. It does not allow you to send without a fee if it thinks it's necessary, but it does allow you to add a fee when it thinks it is not necessary. 
September 10, 2014, 11:41:38 AM
At first, related to the dust sent to 1EXoDus: while I really don't share some of the actions or decisions that were made related to Mastercoin, I'm very certain that it's purpose is indeed one of a marker (similar to XCP's prefix) and by no means "unjust enrichment of the Mastercoin developers". Even if you combine all the dust, you'd probably end up with something like.. 0.5 BTC? This is absolutely insignificant, given that "thousands" of coins are allocated to fund further developement.
That may be true. I just don't like it as a matter of policy. It may be worthless dust now, but in the future it could be meaningful amounts.
Can you point to non-financial data usage in Counterparty or Mastercoin? They were both created to enable the creation of further tokens, some of which may end up having little value, but all are certainly intended to have some value.
I can:
- A new Mastercoin property with many meta-data fields
- XCP broadcasts (transactions)
In my opinion this stuff shouldn't be stored on chain - and we should actively work on a solution to avoid this. It's questionable, if it makes sense to replace a short piece (let's say "btcusd-650") by an extern reference (say a magnet link). But at least related to Mastercoin I have a pretty strong opinion that most (meta-) data does not even serve a good purpose at all, given that it's content is not verifiable anyway and may in the worst case lead to scam based on name squatting.
I am of course aware of "pure (meta-)data" aspects to both Mastercoin and Counterparty. In the case of Counterparty broadcasts at least, there is a direct tie-in to financial/transactional uses. While there is the possibility of misuse, Counterparty broadcasts are intended to facilitate, and perhaps trigger directly, transactions. (I'm not sure of the exact mechanisms here.)
In the example of sports betting, a broadcaster will establish a feed that will broadcast the result of a game. Bettors may create betting transactions which are essentially held in escrow pending the result broadcast. Once the result is broadcast, the bets are resolved and the winners receive their funds.
While sports-betting may seem to be a frivolous use, the same process is applicable to serious financial uses such as options and hedges. One example that can hopefully be implemented in Counterparty soon is essentially betting on the Bitcoin Difficulty. If you are a miner, you could hedge against your lost profits if the difficulty increases more rapidly than anticipated.
September 10, 2014, 11:11:30 AM
Well, it's up to them to define "spam", isn't it? And so far the transaction fee method of spam mitigation seems to be working out ok, right?
No, it's working out terribly. The majority of spam is not filtered by the fee method.But there would be more of it (both successfully mined into the blockchain, and blocked attempts) if the fees were not there at all. There is a purely-deterrent effect. There is a blocked-by-the-client-software effect. There is a blocked-by-peer-nodes effect. If the fees were non-existent, or orders of magnitude lower, then I think the spam (actualized and attempted) would be orders of magnitude higher.
The code forms the entirety of the social contract. "Code" referring to officially sanctioned code that comes out of the official Bitcoin developer team. This code defines a set of rules, which enables trustless transfer of value. While I do agree with the goal (and indeed the necessity) of decentralization, I think that it can be taken too far. Everybody needs to play by the same set of rules. I don't think that some miners choosing to mine X transactions, while other miners reject them, is a good idea. There needs to be consistency between miners in order for the network to perform in a predictable manner, and performing in a predictable manner is the only way that Bitcoin will see greater adoption. (I seriously wanted to punch somebody when I sent like $500 worth of BTC in a straightforward transaction, and it wasn't confirmed for hour after hour due to the QT client not including a mining fee.... having that money out in unconfirmed limbo, when I could have included a 10¢ fee that would have gotten it included in the next block, was infuriating. But no, the fee wasn't even an option in the QT client. This is the kind of thing that makes end-users abandon a platform forever.)
The code is the Constitution, if you will. It defines the rules. There is no judicial branch to interpret the code. Just the code. There is no dicta, no Talmud, no human intervention, no wiggle room. Either a transaction fits the rules of the code, or it doesn't. Pure algorithmic consensus. This is the promise of Bitcoin, the great problem solved by Satoshi.
No, the code is just an implementation. At most, it defines the protocol. That's just part of Bitcoin - and not the part responsible for the spam filtering. Miners are another part, responsible for that.The code is the Constitution, if you will. It defines the rules. There is no judicial branch to interpret the code. Just the code. There is no dicta, no Talmud, no human intervention, no wiggle room. Either a transaction fits the rules of the code, or it doesn't. Pure algorithmic consensus. This is the promise of Bitcoin, the great problem solved by Satoshi.
The code of the reference client (more specifically, bitcoind) IS Bitcoin. It is the DNA that directs the cell. It is the blueprint that defines the house. You could lose everything else -- cgminer, pool management software, whatever -- and Bitcoin could survive on just bitcoind alone.
The reference client implements a fee system. If this fee system is not honored by miners, how is the average user going to be able to trust Bitcoin?
Quote
There is no need for "consistency" between miners (actually a harmful thing to Bitcoin). If you need your transaction confirmed ASAP, you will just have to make it attractive to all miners and hope they take it. It's not going to be confirmed for 5+ blocks after it's mined anyway, so even if you have to wait a block or two for it to be mined, it's really not that big of a deal.
Transaction fees have always been an option in Bitcoin-Qt.
Transaction fees have always been an option in Bitcoin-Qt.
I know about the 6 blocks confirmation for most reasonable transaction partners. I am talking about literally hours (over 10 hours for sure, when I came back the next day it had finally been included in a block) sitting there at 0/unconfirmed. Checking on blockchain explorers, seeing the transaction there with the note "Expected confirmation in the next block" or something to that effect.
The Qt client allows you to choose not to include a fee, if you don't want to and it thinks that you should. But, AFAIK, it does NOT allow you to arbitrarily add a fee to a transaction that it thinks should be fee-free.
I had sent other similar transactions before and never had a problem. In those transactions, was prompted to include a fee and did so. The one time that Bitcoin-Qt did not prompt me to include a fee (I guess because the coins had aged sufficiently), I waited for many hours before the transaction was included in a block.
September 10, 2014, 10:28:27 AM
my last mined nmc was received at 17-aug-14, is there any problem ? it usually paid every 2 days ?
September 09, 2014, 09:56:30 AM
The Eligius.st server seems to have gone kaput this morning on an Error 500 when it connects at all. Double checked it against downforeveryoneorjustme.com and they see it as down too. Does this affect mining or just the stats?
BEWARE! This was the SN-hjacker!
No, mining still working smoothly here...
Seems like just a short burst of server indigestion or something. It's all good again.
September 09, 2014, 09:08:40 AM
Miners are currently receiving a 25 BTC subsidy to try to encourage Bitcoin adoption.
While it is certainly true that we could all start demanding fees that cover the expense of mining and storing the transaction (probably higher than the 0.01 BTC/kB we originally started with), Bitcoin adoption is likely to suffer from that.
While it is certainly true that we could all start demanding fees that cover the expense of mining and storing the transaction (probably higher than the 0.01 BTC/kB we originally started with), Bitcoin adoption is likely to suffer from that.
I'm in the camp of "if they pay for data, let them", but this is actually a very interesting argument I completely overlooked.
The 80/40 byte OP_RETURN is merely a matter of node-specific relay policy, and should not in any way affect how anyone implements their protocols, which should be done correctly, without regard for others' policies.
If people want to support these new protocol standards, they should adjust their policies accordingly.
If people want to support these new protocol standards, they should adjust their policies accordingly.
Relaying nodes are one part, pools another. In my opinion it would be already a significant limitation, if only 3/4 of pools mine those transactions, but let's look at the facts - right now it's almost none? Your argument is moot and (exaggerated) like saying: "sure, go ahead and build a service which uses OP_CAT. If it turns out to be used by a lot of people, ...".
Hey baddw,
thanks for representing your point of view! In most parts I agree. Here are a few notes nevertheless:
At first, related to the dust sent to 1EXoDus: while I really don't share some of the actions or decisions that were made related to Mastercoin, I'm very certain that it's purpose is indeed one of a marker (similar to XCP's prefix) and by no means "unjust enrichment of the Mastercoin developers". Even if you combine all the dust, you'd probably end up with something like.. 0.5 BTC? This is absolutely insignificant, given that "thousands" of coins are allocated to fund further developement.
Can you point to non-financial data usage in Counterparty or Mastercoin? They were both created to enable the creation of further tokens, some of which may end up having little value, but all are certainly intended to have some value.
I can:
- A new Mastercoin property with many meta-data fields
- XCP broadcasts (transactions)
In my opinion this stuff shouldn't be stored on chain - and we should actively work on a solution to avoid this. It's questionable, if it makes sense to replace a short piece (let's say "btcusd-650") by an extern reference (say a magnet link). But at least related to Mastercoin I have a pretty strong opinion that most (meta-) data does not even serve a good purpose at all, given that it's content is not verifiable anyway and may in the worst case lead to scam based on name squatting.
So do you mean that there is a place in a .conf file or something (i.e., not in compiled code) where node runners can simply "switch on" 80-byte OP_RETURN?
You can do this in the code. But even if you do, in the end the decision is in the hand of the pool operators. My understanding of Luke's POV is something like "if your userbase wants 80 bytes and is big enough, then pools will follow".
In the best case, at some point, all this as well as op codes should be configurable via a config, but the reality is rather this:
https://github.com/bitcoin/bitcoin/commit/8175c790eb12f0b0ca3197895a6d1d479b340b67 (OP_RETURN was cut from 80 byte to 40 byte)
https://github.com/bitcoin/bitcoin/commit/e44fea55ea73f46bc9460597c7001e77acb58db7 (option to disable OP_RETURN)
https://github.com/bitcoin/bitcoin/commit/3da434a2ef9ac76a0ad4a33921773a9ac8f10ab7 (option to disable m-of-n multisig)
Maybe I'm bias due to the sentiment around this topic and the comments made by Luke and jgarzik, but I'm sure one can see a pattern here and the direction where this is going.
One point is brought up quite often: "metacoins enjoy a free ride, do not contribute, fullnode owners suffer, etc. ...".
What is probably overlooked here is the fact that Mastercoin or metacoin users in general have an inceive to contribute to the underlying network as well. Merged mining aside, but for the sake of an example: would you rather prefer MSC friendly miners and node owners to support Bitcoin or an alternative chain which MSC uses exclusively? In my opinion fragmentation should be avoided.
I really enjoy this round of discussion in comparison to the one earlier this year, because it clearly demonstrates that everyone acts with good intentions and at least I gained some valuable insights.
Edit: as a sidenote: the UTXO grew from 9.819.223 somewhere back in March to 12.444.288 in July at block height 312.999 whereby the total amount of all transactions grew from 33.508.561 to 43.442.280. The amount of metacoin transactions grew from 5.176 to 46.948 with a total of 14.954/69.712 spent/unspent outputs. The total amount of metacoin transactions roughly doubled since then while the ratio of spent/unspent outputs is getting much better due to the increased awareness about the topic and cost inceives, but I have no up-to-date data to back this at the moment.