The release notes do say "#skipcbcheck", not "#xnsub"... The astonishment in this case is that you're being asked to work on invalid blocks... |
|
|
|
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. 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? git pull git://gitorious.org/bitcoin/luke-jr-bitcoin.git spamfilter |
|
|
|
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. I'll probably try to do a 0.9-based mining branch sometime soon with that and more miner features... |
|
|
|
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 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? The reference policies are merely examples, and have absolutely nothing to do with the Bitcoin protocol. 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. |
|
|
|
2) stratum+tcp://miningpool.com:3333#xnsub
This. Might need a slash too: stratum+tcp://miningpool.com:3333/#xnsub |
|
|
|
NEW VERSION 4.8.0, SEPTEMBER 10 2014Human readable changelog:- New option --benchmark-intense for hardware manufacturers to properly test their miners can perform properly as Bitcoin grows.
- Logic to check validity and optionally benefactors of the generation transaction (GBT and Stratum only). See the new --coinbase-check-* options to configure it, or append #skipcbcheck to pool URIs to disable it.
- cointerra: New driver for the TerraMiner.
- Stratum proxy: Numerous crash conditions fixed.
Full changelog:- Improve precision of total_secs used in (at least) RPC summary Elapsed
- Bump embedded libblkmaker to 0.5.0
- Bump embedded libbase58 to 0.1.1
- Remove now-unused bfg_cond_timedwait which cannot be made portable
- Spawn a new thread for cmd-idle rather than relying on problematic pthread timedwait
- README: --coinbase-check-* options
- Bugfix: Accept actual percentages for --coinbase-check-percent
- Optimise coinbase check logic by using actual script bytes everywhere possible
- Pool option #skipcbcheck to disable new coinbase checks
- pool_check_coinbase: Avoid redisabling an already misbehaving pool
- Bugfix: Keep connection active for rejecting and misbehaving pools so we can detect when they recover
- Share pool coinbase check reaction code
- Initial version of coinbase checking function for GBT and stratum
- cointerra: Ensure devlog messages cannot overflow
- Bugfix: cointerra: Defer setting USB timeout until after initialisation
- cointerra: Set configuration and claim interface
- Bugfix: cointerra: Check ep is open before trying to talk to it (crash at init failure)
- cointerra: Support for --set cta:load=N
- cointerra: Store load setting on struct cointerra_info
- cointerra: Operate within a single thread
- cointerra: Update to minerloop_queue
- cointerra: Split work packet into cointerra_queue_append function
- cointerra: Prepare for splitting work packet into cointerra_queue_append function
- cointerra: Use more fresh code for work packet
- cointerra: Use fresh code for work packet
- Bugfix: cointerra: Use bfg_cond_timedwait to avoid spinning
- cointerra: Claim and release lowlevel device
- cointerra: Propagate per-core temperatures to each processor
- cointerra: Reduce redundant stats information
- cointerra: Correctly divide up individual processors
- cointerra: Update to latest BFGMiner
- work_ntime_range helper function
- work_{get,set}_ntime inline functions
- Store a reference timeval with ntime_roll_limits
- util: min macro
- cointerra: Cleanup debugging
- cointerra: Divide up processors
- cointerra: Wait for info packet on probe
- cointerra: Dirty BFGMiner port
- lowl-usb: Cleanup dead code
- notifier_wait, notifier_wait_us, and notifier_reset functions
- Export the flush_queue function for use by drivers.
- Provide a function to discard queued work based on age.
- Export share_diff function and add flip12 macro
- Provide a copy_work_noffset function for copying a work struct but changing its ntime.
- Add api_add_int16 to API functions.
- cointerra: Remove nodev checks for now
- cointerra: Replace reset semaphore with a simple notifier
- Build cointerra driver
- cointerra: Import driver from cgminer as-is
- Silently ignore shares rejected if they were above target and only got submitted "just in case"
- Abstract put_in_parens function
- Abstract extract_reject_reason function
- Remove dead code
- Bugfix: bfg_cond_timedwait providing semantics expected for --cmd-idle implementation
- Per-processor TUI: Align columns for more-than-one proc letter
- m4/bundled_lib: Workaround bug in autoconf <2.64
- If full version is too long, try truncating it at '-'
- Bugfix: Fix CPU miner benchmarking within benchmark-intense mode
- benchmark: Detect duplicate shares within 5 minutes
- benchmark-intense: benchmark_update_interval constant in code
- benchmark-intense: Detect stale results
- benchmark-intense: Update work every second
- benchmark-intense: Simulate 250 KB generation transaction
- benchmark-intense: Generate individual work items from 2D work (tests host CPU rate of work production)
- Introduce --benchmark-intense option
- Import libbase58 for base58 encoding/decoding
- Cleanup libblkmaker bundling code to mostly live in autoconf macros
- Always check if we should switch pools when enabling one, and always enable pools we want to switch to
Full changelog (4.7.1):- Bugfix: Reorder LDADD and such for priority
- Bugfix: bitforce: Initialise variable to NULL
- Bugfix: SSM: Use client_next member consistently when working with stratumsrv_connlist
- Bugfix: SSM: Check that a username is provided to mining.authorize
- Bugfix: SSM: When n2pad<0, release lock before returning
- Bugfix: SSM: Make buffers long enough to avoid overflows
- Bugfix: Need signed types for ntime min/max offsets
- Bugfix: rockminer: Fix processor disabling
- rockminer: Limit even unsafe frequencies to 640 MHz, since above that overflows frequency bits and triggers fan control
- tq_pop: Remove abstime argument since nothing used it and it wouldn't work anyway (uses CLOCK_REALTIME while we use CLOCK_MONOTONIC[_RAW] when possible)
- Bugfix: Check last solo generation tx against new template rather than most recent
- README: Explicitly mention automatic solo mining configuration, and stress the importance of --coinbase-sig
- Bugfix: Recheck current_pool after calling pool_died
- Bugfix: Stable pool recovery: Only care if the pool is enabled
- README.ASIC: Add a section for Gridseed
- Bugfix: benchmark: Free json_null() after use
- Bugfix: minergate: Claim socket before we initialise a cgpu for it
- Bugfix: avalonmm: Claim device before we initialise a cgpu for it
- Bugfix: switch_pools: Broadcast lp_cond outside of control_lock to avoid deadlocking
- Protect enabled_pools by a mutex in disable_pool function
- Combine reject_pool into disable_pool function, and don't allow it to override a manual disable
- Call disable_pool() at the begin of remove_pool() and combine them when appears together in the code
- Bugfix: Always call enable_pool and disable_pool to ensure consistent handling of the situations
- Remove dead CPU mining code to silence warnings
|
|
|
|
Luke-Jr ,how many old accounts do you have?
1 |
|
|
|
Hey I found a vulnerability. If a cat is left near the pizza then a pie can't be spent/eaten anymore, unless the user is disgusting. Hm, true. But at least then you have a cat to butcher. |
|
|
|
Let me just cut off this train wreck of a thread.
@cloverme The technical problems around storing users' money are by far the easiest --- getting the appropriate legal protection and authorization, security audits, accounting, backup/recovery, etc. systems in place are much much harder. But you seem to be struggling at a very fundamental level with the technical problems. These are also problems with traditional payment mechanisms, but Bitcoin makes them much more serious because it requires the programmer to deal in low-level cryptographic primitives, and its transfers are irreversible. So I implore you to not write code handling other peoples' money.
Managing multiple users by giving them each different wallets is not only a terrible idea from a scalability perspective, it does not make conceptual sense. The money you are holding is in your possession, and that means you need to track all of the keys material, track transactions, etc. Smearing this stuff across hundreds or thousands of files is insane.
Addresses are ephemeral: you generate a new one for each payment you intend to receive, and it identifies that specific payment. It is like an invoice number. Having one per user is also a conceptual confusion.
The correct way to do this involves a proper delegated key management setup (using BIP32, for example) designed and audited by experts in this field. It is possible to use bitcoind to manage keys, though this adds quite a bit of complexity to creating a secure system. The majority of your funds at all times should be "cold", as some other users are saying. This means that no network-connected system is in possession of cryptographic keys required to move them.
Thanks for the help, using a new address for each payment to be received is a good idea as is keeping a majority of the funds in cold storage. I've also received some tips to use Blockchain.info and their API's which doesn't look like a terrible idea since they support JSON RPC too. I'm in the research/design phase so there's no waste of good advice here. Using blockchain.info for anything is insanity and terrible advice. Anyone advising that should be put on a "do not take advice about bitcoin from" list... |
|
|
|
Luke, does BFG Miner support/work with the NEW R-Box 100GH/s ?
I think not yet, but uncertain. Try it and let me know? |
|
|
|
|
Hey Dogie, are you sure the 12V is correct? I also got a 12V adapter with my sample, but the controller itself says 5V so I was concerned it would fry it... :/
|
|
|
|
how to mine (with gpu) x11 algo?
i tried:
bfgminer.exe --X11 -S opencl:all -S zus:noauto -o stratum+tcp://stratum.nicehash.com:3336 -u 1AsLCvR43Yeka6Z8y1kURPQenwdyi7tfBp.1 -p x
but not working..... (when i open it, it's close itself)
maybe it isn't X11 the command?
BFGMiner won't have Crypto11 ("X11") support until someone steps forward to add it. |
|
|
|
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. 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. 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. |
|
|
|
But if somebody wants to waste a good amount of money to have something stored in the blockchain, let 'em. Why? "If somebody wants to waste a good amount of money to steal your heirloom, let 'em." (analogously equivalent) doesn't sound like an appropriate answer. Hmm. Not a good analogy. 1) The "heirloom" is already being freely passed around, 2) the "thief" is paying money to the police who are being charged with protecting/distributing the "heirloom" and thus the "thief" is kind of helping to further protect/distribute the "heirloom", which was the desire of the heirloom owner in the first place. 1) Whether it is or isn't, theft of it is still wrong. 2) The thief is paying a bribe so that the "police" allow the theft, when their job is to prevent it. I don't see how that's a positive thing, let alone justifies it. My point was more to question the concept of "stealing" or "theft" of a digital creation. There is no "taking", there is no "conversion", the "victims" are not left with anything "lesser". Yes, you are appropriating their computer resources, but they are voluntarily giving their computing resources to run Bitcoin software already, and they are doing so with at least some knowledge of the risks and costs of doing so. If you would prefer a propertyless analogy, "If somebody wants to waste a good amount of money to rape you, let 'em." I try to avoid that one as some people are sensitive, but it really is a good fit. The miners are the gatekeepers of Bitcoin and the people who are paid money to secure the blockchain. Which is why their neglect of doing so is bad... If somebody wants to use the blockchain for their own purposes, but they pay appropriate fees to the miners then I really can't complain. Why not? They're bribing the miners to abuse their position to do the opposite of what their job is... How are you in a better position to determine the "job" of the miners than the miners themselves? The code creates incentives and lays down rules. People act within the rules to maximize their share of the incentives. If it's not in the rules, it's not "abuse" or outside the scope of their "job". Well, Bitcoin only works if it is their job... otherwise the system has no counter-measures to spam and it is essentially guaranteed to cease functioning. I realize that disk space, and working memory space, is not free, nor is it unlimited. However, this is a larger problem with Bitcoin that is only being slightly exacerbated/accelerated somewhat with "on-the-blockchain" alts such as Counterparty. Actually, no. Properly using Bitcoin does not create a never-ending growth of the UTXO database - items get added, and are always deleted later. Blockchain spam (except when it uses OP_RETURN) permanently adds database entries which can never be deleted. Even the "proper" use of Bitcoin will generally lead to several orders of magnitude increase in the UTXO database (and, assuming further divisibility is implemented when necessary, it will indeed create "never-ending growth"). In general, larger amounts split to smaller amounts, as the value of 1BTC rises. Assume (as we all hope) that Bitcoin continues to grow in usage, and rises 10x in (fiat denominated) price, but it's still being used for the same stuff it's used for now. That's 10x as many transactions to 10x as many outputs. Now reiterate a few times and we're talking Satoshis being used to buy pizzas. And what is "spam" and "dust" by today's measure becomes the standard transaction size. And the UTXO database will be 10,000 times what it is today. This is a problem that will be faced by Bitcoin regardless of blockchain hangers-on such as Counterparty and Mastercoin. (Assuming a bright future for Bitcoin, which I am of course happy to assume.) Yes, but that's significantly different from "growth" which never goes away/recycled nor provides any purpose or value to Bitcoin. Identification of spam in filtering is an independent matter from whether it is spam.
There are proposals for identification of valid hashes at least (look up P2SH2), but hopefully we won't have to use them... I remember looking at the P2SH^2 stuff a couple of months ago when all of this was going down in the Counterparty thread, and it seems to me that it's a non-solution. It's just a hash of a hash, right? That doesn't prove that the first hash (which will still need to be published) is actually a hash. The only way to prove that a hash(X) is actually a hash, is to provide the (X) that it's hashing. The first hash doesn't need to be stored in the blockchain, only relayed to the miner. Is there anything like this existing in Bitcoin today? Something that is produced alongside a transaction and relayed with the transaction, but not reflected in the blockchain? Wouldn't this lead to a problem where clients would not be able to trust the transactions in the blockchain, because they are not fully self-proving? What if a bad miner decided to include transactions where the inside hashes weren't relayed? Wouldn't this cause consensus problems everywhere? It depends on miners doing their job - consensus always follows the valid blocks, unaffected by P2SH 2. It is only the transaction relay network and miners which verify the hash preimage. "Consensus always follows the valid blocks" -- what about transactions that are included in a block but whose pre-images have not yet propagated to all of the network? Won't this lead to rejection of valid blocks? And again, how about miners that include non-pre-imaged transactions in their blocks? Won't this lead to the acceptance of invalid blocks? IMO, requiring something of a transaction, which something is not included in the blockchain, simply re-introduces the very consensus problem that the blockchain was designed to eliminate. No, the blocks are valid by the same rules as before. Enforcement of P2SH 2 is entirely left to the miners' policies. Except unlike those, the governments can easily stifle/terminate Bitcoin in their jurisdictions.
Currency is inherently something publicly traded, and cannot survive if made illegal itself. Bitcoin cannot be stifled or terminated without stifling or terminating Internet connectivity as a whole. Yes, exchanging from local fiat currency to Bitcoin can probably be stifled quite a bit (although never completely due to the black market). But the use of Bitcoin itself? No. The blockchain cannot be terminated, but Bitcoin use can. Bitcoin use depends on the ability to buy and sell with bitcoins. If accepting bitcoins as payment is illegal, your bitcoins don't work in society, no matter how well the blockchain does. It will still function "underground", but an underground-only currency is vastly less useful and interesting than an "aboveground" one. It is my hope that by the time a case involving crypto-equity comes before a court of law in the US, its use will be widespread enough that shutting it down is simply not an option. That cat's out of the bag. You can't stop the signal. The "cat" could be just as much "out of the bag" on a centralised one too - but I think you underestimate the governments... There is really no rational reason I can think of to think they will treat stock exchange any differently if the records are kept on a blockchain. Because the blockchain does not reside in any identifiable locale, nor is it owned by any identifiable group. It is distributed among many groups in many locales, the laws of which can vary considerably. Can the US government stop me if I want to buy stock in a company traded on an exchange in the Cayman Islands, using Cayman dollars? Or an exchange located on the Isle of Man, using Manx pounds? Or existing solely on a ship in international waters, using scrip? Who's to say that the decentralized exchange isn't "located" there, if there's at least a single machine running a node there? As long as I pay taxes on any profits/proceeds that I repatriate to US soil, what law is there to stop me? I doubt any of the laws care where the exchange is operated. What's relevant is where the stock itself is operated, and where the owners are located. Decentralised stock exchange doesn't change the fact that CompanyX is in the USA and PersonY is in England. And of course the issuers could be prosecuted, but what if a US issuer, who issues legal shares of a legally-incorporated corporation, only markets his securities to non-US shareholders? And what if US shareholders only own securities issued by non-US entities? Who's going to go after who here? Then it's no different than if the stock exchange was operated by the issuer or someone they outsource it to... I'm not saying that any or all of this would work. I am not a lawyer. But I think that some sufficiently-clever version of this could work and could basically lead to the practical impossibility of enforcing any laws against crypto-securities. It's never a practical impossibility. The government can just say dividends won't be paid out unless they recognise the share ownership. |
|
|
|
But if somebody wants to waste a good amount of money to have something stored in the blockchain, let 'em. Why? "If somebody wants to waste a good amount of money to steal your heirloom, let 'em." (analogously equivalent) doesn't sound like an appropriate answer. Hmm. Not a good analogy. 1) The "heirloom" is already being freely passed around, 2) the "thief" is paying money to the police who are being charged with protecting/distributing the "heirloom" and thus the "thief" is kind of helping to further protect/distribute the "heirloom", which was the desire of the heirloom owner in the first place. 1) Whether it is or isn't, theft of it is still wrong. 2) The thief is paying a bribe so that the "police" allow the theft, when their job is to prevent it. I don't see how that's a positive thing, let alone justifies it. Tangible-world (limited resources) analogies often don't really equate to digital-world scenarios (not quite unlimited resources, but close enough to make comparisons very difficult). The blockchain is nowhere near an unlimited resource. The miners are the gatekeepers of Bitcoin and the people who are paid money to secure the blockchain. Which is why their neglect of doing so is bad... If somebody wants to use the blockchain for their own purposes, but they pay appropriate fees to the miners then I really can't complain. Why not? They're bribing the miners to abuse their position to do the opposite of what their job is... I realize that disk space, and working memory space, is not free, nor is it unlimited. However, this is a larger problem with Bitcoin that is only being slightly exacerbated/accelerated somewhat with "on-the-blockchain" alts such as Counterparty. Actually, no. Properly using Bitcoin does not create a never-ending growth of the UTXO database - items get added, and are always deleted later. Blockchain spam (except when it uses OP_RETURN) permanently adds database entries which can never be deleted. The blockchain has always been intended for financial data, and everyone who has it implicitly agrees to store it.
The same cannot be said of any non-financial data. 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. My original longer-post on this subject disclosed 3 in Mastercoin. Identification of spam in filtering is an independent matter from whether it is spam.
There are proposals for identification of valid hashes at least (look up P2SH2), but hopefully we won't have to use them... I remember looking at the P2SH^2 stuff a couple of months ago when all of this was going down in the Counterparty thread, and it seems to me that it's a non-solution. It's just a hash of a hash, right? That doesn't prove that the first hash (which will still need to be published) is actually a hash. The only way to prove that a hash(X) is actually a hash, is to provide the (X) that it's hashing. The first hash doesn't need to be stored in the blockchain, only relayed to the miner. Is there anything like this existing in Bitcoin today? Something that is produced alongside a transaction and relayed with the transaction, but not reflected in the blockchain? Wouldn't this lead to a problem where clients would not be able to trust the transactions in the blockchain, because they are not fully self-proving? What if a bad miner decided to include transactions where the inside hashes weren't relayed? Wouldn't this cause consensus problems everywhere? It depends on miners doing their job - consensus always follows the valid blocks, unaffected by P2SH 2. It is only the transaction relay network and miners which verify the hash preimage. 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. 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? I've had political problems getting that option added, but there definitely should be.  I suspect part of the problem is that securities are highly regulated in some countries, and people have a misconception that decentralisation bypasses the law.
People who seriously want to support Bitcoin shouldn't encourage anything that would lead to illegal use of it, since that is only liable to harm Bitcoin. I don't really think that argument holds water. Technology moves faster than the law can react. There are illegal uses for the Internet, e-mail, text messaging, cryptography, you name it. Except unlike those, the governments can easily stifle/terminate Bitcoin in their jurisdictions. Currency is inherently something publicly traded, and cannot survive if made illegal itself. Personally, I think it would be positive for Bitcoin if it were widely thought of in the same way, as a "platform" upon which people can do good or evil. It is the same with money, banks, guns, cars, electricity, spray paint. You name it, people can find an illegal use for it. That doesn't mean we need to encourage it. Yes, and it could all have been handled by a centralised stock exchange better. And a centralized stock exchange would have required a bunch of fees and legal rigamarole. It never would have even gotten off the ground. GLBSE, IIRC, got quite far beyond "off the ground". Fees and legal rigamarole exist whether it is centralised or not - making a decentralised stock market does not exempt those issuing stocks i The whole thing was over and done in a year or so (sorry for your losses, BTW, if indeed there were any; IIRC, most "shareholders" in the ASIC company ended up making a decent profit); I don't see how my share can just be taken from me. But maybe they had a buyout clause that I just overlooked. It is my hope that by the time a case involving crypto-equity comes before a court of law in the US, its use will be widespread enough that shutting it down is simply not an option. That cat's out of the bag. You can't stop the signal. The "cat" could be just as much "out of the bag" on a centralised one too - but I think you underestimate the governments... There is really no rational reason I can think of to think they will treat stock exchange any differently if the records are kept on a blockchain. Adam Back and Austin Hill recently raised funds to develop it (they're forming a company named Blockstream).
I don't know how much of the company details are public at this time, so I'll just have to simply say they have a competent team to work on it.
(disclosure: I'm planning to do contracting work for Blockstream myself) Well, that's cool, but are they going to be able to have their code integrated into bitcoind? Are miners going to actually mine these daughter chains for the transaction-fee scraps? That's the plan. If necessary, it's always possible to fork Bitcoin Core. I envision a future where individual miners choose which blockchains they support by running a full node, plus merge mine ones they care less about through third-party policy servers. On another/related point, if merged-mining is so attractive and viable, why does Eligius only merge-mine Namecoin and not some of the other coins that you mentioned in the github thread? (Ixcoin, etc.) We don't support scams. So far, Namecoin is the only merge-minable non-scamcoin (besides TBC which is inherent in Bitcoin mining). Long-term plan is to move to a system where the end miner chooses what to merge-mine via GBT. |
|
|
|
Personally, I question the "social agreement/contract" aspect. To me, the software/code is the entirety of the contract. That is kind of the whole point of a decentralized, trustless, electronic currency. The rules are stated in the code, and enforced by the code. Any transaction that meets the rules of the Bitcoin code is a valid Bitcoin transaction, by definition. This is true, but being a valid transaction does not imply a right to be stored by every Bitcoin node forever, be mined by every Bitcoin miner, or be relayed by every p2p node. Every node has the right to decide for himself what he wants to relay. Every miner has the right to decide for himself what he wants to mine. It is also impossible to mine every possible transaction: doing so means inherently unbounded storage requirements by every Bitcoin user. This is why human miners are charged with the responsibility of filtering out spam. Yes, so, how do you filter out spam, given how easy it is to obfuscate arbitrary data using any number of options? The only real way to do this (and the one that has already been chosen) is by implementing a transaction fee to make such spam efforts expensive in relation to the benefit realized. The transaction fee method has proven unreliable so far. Humans are chosen to do the job because we can react to changes in spam methods, unlike fixed algorithms which the humans behind spam will always find a method to bypass or workaround. But if somebody wants to waste a good amount of money to have something stored in the blockchain, let 'em. Why? "If somebody wants to waste a good amount of money to steal your heirloom, let 'em." (analogously equivalent) doesn't sound like an appropriate answer. This solution is both effective and simple. If Eligius wanted to start including only transactions that include 10x the standardized fee, that would certainly block Mastercoin and Counterparty transactions. I know that I have sent BTC transactions that have taken 12+ hours to be confirmed in a block because, even though they supposedly met the coin-age requirements needed to be fee-free according to the QT client (which did not even prompt me to add a fee), miners refused to include them in a block for that length of time. And I was left to sit there and stew, and see my transaction as "unconfirmed" for half a day while I'm trying to send money to somebody. So it seems that a LOT of pools have taken this action of only mining transactions with fees even when technically a fee is not required. 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. It seems to me a much better approach is trying to filter out the abuse and subsidize (only) the transactions that benefit Bitcoin. Ok, so how do you determine who's consented to store XCP data? How do you determine who's consented to store SatoshiDICE data? The reality is that everyone who downloads the QT client (or other client that stores the entire blockchain) and who is concerned about such things and smart enough to understand them, must realize that the blockchain contains some stuff that they don't care about, or is irrelevant or even (to them) immoral. But if they want to use Bitcoin and download the blockchain, they will receive the whole blockchain. The blockchain has always been intended for financial data, and everyone who has it implicitly agrees to store it. The same cannot be said of any non-financial data. Not to mention that, if this is your main issue with Counterparty et al. then you need to implement something in bitcoind itself to block these transactions, because by not mining them in Eligius, they will still be mined by the other 95% of the network and still end up in the blockchain to be stored by all the QT users and full-node runners, including Eligius. Not including them in Eligius blocks might be your way of taking a stand, but it's ineffective if your concern is the transactions showing up in the blockchain and forcing users to store them. Miners are neglecting their job if they run mainline mining code. It is intended to be a (technologically and politically conservative) example only, not used unmodified. Unmodified use puts inappropriate authority in the development team that we do not want and, of course, neglects to perform the quality of filtering the network needs today. Identification of spam in filtering is an independent matter from whether it is spam.
There are proposals for identification of valid hashes at least (look up P2SH2), but hopefully we won't have to use them... I remember looking at the P2SH^2 stuff a couple of months ago when all of this was going down in the Counterparty thread, and it seems to me that it's a non-solution. It's just a hash of a hash, right? That doesn't prove that the first hash (which will still need to be published) is actually a hash. The only way to prove that a hash(X) is actually a hash, is to provide the (X) that it's hashing. The first hash doesn't need to be stored in the blockchain, only relayed to the miner. And the Counterparty developers would certainly prefer for *everything* (except for valid escrow/m-of-n situations) to take place in OP_RETURN instead of being encoded in pubkeys or anywhere else. Unfortunately, that did not seem to be the case in my experience. They were more worried about forcing the transactions on miners by hiding them. If there's been a change of heart since then, great. If Eligius isn't mining these properly-formed transactions, they should get in touch. AFAIK, They were prepared to switch all XCP transactions to use exclusively the 80-byte OP_RETURN at the release of 0.9.0 which was supposed to implement it and which had implemented it in development code until a last-minute change to 40 bytes. They had been following the development, knew about the 80-byte OP_RETURN and had based Counterparty development around using it exclusively. When 0.9.0 was released with only 40 bytes of OP_RETURN, they were forced to continue with other alternatives, as not doing so would mean the end of Counterparty. (Again, this is only AFAIK! I am not affiliated with the Counterparty team in any way, and I have not read the code, and there might be other situations where non-OP_RETURN data storage might have been used, but my recollection is that 80-byte OP_RETURN would have been used for the vast majority of Counterparty transactions.) 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. This is solved by Bitcoin daughter-chain support - you would be able to pay Bitcoin transaction fees on a conceptual Counterparty blockchain and miners could collect on them. That's awesome, is it supported now? I could definitely see them moving to a daughter-chain if/when it is implemented. No, it isn't yet. I wouldn't expect Counterparty to move to another blockchain until it is. Lastly, I have to close with this. As a supporter of Bitcoin, wouldn't you rather have this functionality (decentralized exchange; like a stock market for crypto-currencies and crypto-assets) exist on the Bitcoin blockchain and be a part of the Bitcoin ecosystem instead of having all of this functionality take place in NXT, BTSX, Ethereum, Ripple, etc. and leave Bitcoin in the dust as a simple/stupid currency-only? Does the idea of this not excite you? Think about displacing ALL of the corrupt stock exchanges in the world, with something provably fair and honest and decentralized! This is what is going to happen, and what Counterparty and Mastercoin are trying to make happen on the Bitcoin blockchain, with Bitcoin as the common price denominator. Wouldn't you rather be able to buy a share of Overstock directly with BTC instead of NXT, and to have that transaction immortalized in the Bitcoin blockchain instead of the NXT blockchain? Wouldn't you like to see on the ticker "Shares of Overstock are trading at .05 BTC today" instead of USD, NXT, or some other currency? Woudn't that strengthen and accelerate the growth and acceptance of Bitcoin to an incredible degree? It's coming. One way or another, it's coming. Overstock is already in discussions with multiple crypto-asset projects, including Counterparty. As a Bitcoin supporter, would you rather this future be "Built on Bitcoin" or built on something else? Stocks are inherently centralised, and cannot gain any direct benefit from being traded on a blockchain. The stocks have value only because of recognition by the company (to pay dividends) or government (to enforce payment of dividends) Therefore, the logical place to track the stocks is a centralised registry operated by the company, government, or someone they outsource it to. Remember that centralisation is more efficient than decentralisation, so with the benefits of decentralisation eliminated, it doesn't make sense to incur the costs of decentralisation anymore. That's certainly an interesting take, and one that I hadn't heard before. You're right, of course, but I think you're looking at part of the picture. The bigger part of the picture, to be sure, but a lot of interesting stuff is taking place at the smaller end of the picture. I think a lot of the promise of decentralized stock-markets has to do with smaller companies and the high price of entry into a "real" stock exchange. It's a way of crowd-funding that actually creates equity, unlike Kickstarter where a bunch of people gave money to the Oculus guys and a couple years down the road the Oculus guys sell to Facebook for $2Billion and the original Kickstarter backers get nothing. There needs to be a way for this to happen, to bridge the gap between crowdfunding and equity. Decentralized crypto-exchanges provide a good way to do it. You're right, there's still a large amount of trust involved, but you could say the same thing about Kickstarter (and lots of Kickstarter projects have failed) but Kickstarter still manages to get projects funded. Not to mention the numerous other crowd-funding sites out there. There certainly seems to be a market for a usable "roll your own stock" system or service, but there's no reason to make it inefficient/decentralised. I suspect part of the problem is that securities are highly regulated in some countries, and people have a misconception that decentralisation bypasses the law. People who seriously want to support Bitcoin shouldn't encourage anything that would lead to illegal use of it, since that is only liable to harm Bitcoin. Even within the Bitcoin space we have seen some applications for this. I think it was Bitmain, but I might be wrong. One of the Chinese ASIC makers. The guy took in a bunch of funding, maintained a list of contributors, used the funding to manufacture a bunch of ASICs and sell them, and the original contributors were paid out the profits in BTC. I think he was keeping his list of "shareholders" (in quotes because this was all an ad-hoc, extra-legal situation) on an Excel spreadsheet or something. And if one of these "shareholders" wanted to sell their "shares" to another person, they would have to receive the BTC as payment, e-mail the dude and he would have to change their ownership in the spreadsheet. A bunch of hassle, prone to error, prone to fraud. I may have some of the details wrong, but it was all in a big thread here on bitcointalk. Maybe you are familiar with it. I think the whole thing is defunct now. I hope it isn't defunct, because I am supposed to own some of those shares - just checking now, I notice I haven't received any dividends since 2013 Nov :| In any case, all of this could have been handled in a lovely way by Counterparty. Ownership tracking, dividend payments, a market for the "shares" where any owner/contributor could liquidate at any time. (Of course Counterparty wasn't around at the time that this "shareholder" situation was created.) But this is the kind of thing that a distributed crypto-exchange such as Counterparty is made for... small-ish companies, less than $1M or so in valuation, just "getting things done" and raising money and paying out dividends without a bunch of regulatory hoopla. Of course, as you said, trust is needed. But trust is really never in short supply (just look at all the scams that have been run on this forum) and it also happens that a lot of people are actually worthy of that trust. Yes, and it could all have been handled by a centralised stock exchange better. The real "coloured coin" use case is in smart property.  Honestly it amazes me to hear you suggest that any project should be "on their own blockchain". What, and derail the work and the value that has been put into Bitcoin? To someday possibly eclipse Bitcoin? Of course as a Bitcoin developer, you can't go crazy and implement every weird idea that's come up in every altcoin out there (not that there are that many good ideas in the altcoin world). Can't rock the boat too much, and you don't want to put anything untested into production. Stability is definitely the core concern at this point. But adding new features and value to Bitcoin should also be a priority, and if third-parties are able to do this discretely and "on top of" Bitcoin without disturbing Bitcoin-per-se in any significant way, I think they should be encouraged.
I'm all for experimentation in general, which is why I don't buy into the "X should leave simply on the basis of it being not Bitcoin-unit denominated". Daughter-chains should definitely help the situation by making any innovation possible within the Bitcoin framework. Basically instead of a single blockchain, Bitcoin would now be comprised of any number of multiple blockchains, each with their own possibly-different set of rules. So, when you want to try a new feature by Joe Random Developer, you just sent however many bitcoins you want to his blockchain. If you decide you want to go back, you just send whatever you have left there back to the main blockchain (assuming his blockchain didn't allow you to get robbed of them, of course). In the Counterparty example, you would occasionally fund your wallet on the Counterparty blockchain with bitcoins to spend on fees, and miners would be the ones bringing them back to the main blockchain when they mine your transaction. Again, the daughter-chains idea sounds great, is it on the roadmap? Adam Back and Austin Hill recently raised funds to develop it (they're forming a company named Blockstream). I don't know how much of the company details are public at this time, so I'll just have to simply say they have a competent team to work on it. (disclosure: I'm planning to do contracting work for Blockstream myself) |
|
|
|
Personally, I question the "social agreement/contract" aspect. To me, the software/code is the entirety of the contract. That is kind of the whole point of a decentralized, trustless, electronic currency. The rules are stated in the code, and enforced by the code. Any transaction that meets the rules of the Bitcoin code is a valid Bitcoin transaction, by definition. This is true, but being a valid transaction does not imply a right to be stored by every Bitcoin node forever, be mined by every Bitcoin miner, or be relayed by every p2p node. Every node has the right to decide for himself what he wants to relay. Every miner has the right to decide for himself what he wants to mine. It is also impossible to mine every possible transaction: doing so means inherently unbounded storage requirements by every Bitcoin user. This is why human miners are charged with the responsibility of filtering out spam. All Bitcoin users storing the blockchain have agreed to store the financial data necessary for the Bitcoin consensus network. This agreement was implied by the fact of Bitcoin's design being inherently for such a purpose. Similar implicit agreements are held to be legally and morally binding in other contexts (for example, GPL software that has always linked to GPL-incompatible libraries from the start, is implicitly considered to have an exception in its license terms for those specific libraries). On the contrary, only some Bitcoin users have agreed to store data unnecessary for the financial functioning of the Bitcoin consensus network. Those who willfully mine or attempt to have mined such data, are forcing it on every node against (in many cases) their consent. On the other hand, I do see the validity to the argument that each "miner" has the right to mine only the transactions that he sees fit. However, I do not think that "pool operator" necessarily equates to "miner" and I would be interested to see a poll or something among Eligius miners asking whether or not they support including XCP and MSC transactions in Eligius-mined blocks. Not to do so is leaving money on the table, and miners are notoriously ROI-minded. AFAIK Counterparty is pretty generous with the fees, given the transaction sizes. (Annoyingly so, as an XCP user.) (And I am aware of Eligius' support of GBT and promotion of its use, which would skirt this issue entirely as well as ensure continued decentralization for Bitcoin. Now if only we could get people to actually use it...) GBT is definitely the road forward for this, in my opinion. Even if the pool had some way of selecting which policy to use (for example, picking a policy by name with your miner "password"), there is nothing to stop the pool from lying if it is compromised. We need end miners to do their job and provide the transaction selection themselves, or at least independently from the pool itself (for example, "transaction policy servers"). "Basically anything that isn't a pubkey shouldn't be scripted as a pubkey, anything that isn't a hash shouldn't be scripted as a hash, and anything that isn't financial data (not sure if this exists, but it was implied in this conversation earlier that it did) shouldn't appear directly in the blockchain."
How can you tell whether something is or isn't a pubkey? How can you tell whether something is or isn't a hash? Identification of spam in filtering is an independent matter from whether it is spam. There are proposals for identification of valid hashes at least (look up P2SH 2), but hopefully we won't have to use them... And the Counterparty developers would certainly prefer for *everything* (except for valid escrow/m-of-n situations) to take place in OP_RETURN instead of being encoded in pubkeys or anywhere else. Unfortunately, that did not seem to be the case in my experience. They were more worried about forcing the transactions on miners by hiding them. If there's been a change of heart since then, great. If Eligius isn't mining these properly-formed transactions, they should get in touch. As for moving to a merged-mined separate chain, the number of XCP tokens never increases. It is impossible to create them; they are fixed in number, and to change this would basically destroy Counterparty. Counterparty transaction fees are paid in BTC (except for asset issuance, which requires XCP to be burned forever). Counterparty users must periodically buy BTC if they make a lot of Counterparty transactions. There could therefore be no reward for miners in a Counterparty-only blockchain. This is solved by Bitcoin daughter-chain support - you would be able to pay Bitcoin transaction fees on a conceptual Counterparty blockchain and miners could collect on them. Lastly, I have to close with this. As a supporter of Bitcoin, wouldn't you rather have this functionality (decentralized exchange; like a stock market for crypto-currencies and crypto-assets) exist on the Bitcoin blockchain and be a part of the Bitcoin ecosystem instead of having all of this functionality take place in NXT, BTSX, Ethereum, Ripple, etc. and leave Bitcoin in the dust as a simple/stupid currency-only? Does the idea of this not excite you? Think about displacing ALL of the corrupt stock exchanges in the world, with something provably fair and honest and decentralized! This is what is going to happen, and what Counterparty and Mastercoin are trying to make happen on the Bitcoin blockchain, with Bitcoin as the common price denominator. Wouldn't you rather be able to buy a share of Overstock directly with BTC instead of NXT, and to have that transaction immortalized in the Bitcoin blockchain instead of the NXT blockchain? Wouldn't you like to see on the ticker "Shares of Overstock are trading at .05 BTC today" instead of USD, NXT, or some other currency? Woudn't that strengthen and accelerate the growth and acceptance of Bitcoin to an incredible degree? It's coming. One way or another, it's coming. Overstock is already in discussions with multiple crypto-asset projects, including Counterparty. As a Bitcoin supporter, would you rather this future be "Built on Bitcoin" or built on something else? Stocks are inherently centralised, and cannot gain any direct benefit from being traded on a blockchain. The stocks have value only because of recognition by the company (to pay dividends) or government (to enforce payment of dividends) Therefore, the logical place to track the stocks is a centralised registry operated by the company, government, or someone they outsource it to. Remember that centralisation is more efficient than decentralisation, so with the benefits of decentralisation eliminated, it doesn't make sense to incur the costs of decentralisation anymore. Honestly it amazes me to hear you suggest that any project should be "on their own blockchain". What, and derail the work and the value that has been put into Bitcoin? To someday possibly eclipse Bitcoin? Of course as a Bitcoin developer, you can't go crazy and implement every weird idea that's come up in every altcoin out there (not that there are that many good ideas in the altcoin world). Can't rock the boat too much, and you don't want to put anything untested into production. Stability is definitely the core concern at this point. But adding new features and value to Bitcoin should also be a priority, and if third-parties are able to do this discretely and "on top of" Bitcoin without disturbing Bitcoin-per-se in any significant way, I think they should be encouraged.
I'm all for experimentation in general, which is why I don't buy into the "X should leave simply on the basis of it being not Bitcoin-unit denominated". Daughter-chains should definitely help the situation by making any innovation possible within the Bitcoin framework. Basically instead of a single blockchain, Bitcoin would now be comprised of any number of multiple blockchains, each with their own possibly-different set of rules. So, when you want to try a new feature by Joe Random Developer, you just sent however many bitcoins you want to his blockchain. If you decide you want to go back, you just send whatever you have left there back to the main blockchain (assuming his blockchain didn't allow you to get robbed of them, of course). In the Counterparty example, you would occasionally fund your wallet on the Counterparty blockchain with bitcoins to spend on fees, and miners would be the ones bringing them back to the main blockchain when they mine your transaction. |
|
|
|
 Hi,luke could you help me? I got that strange error only when i mined nicehash  , full of hw and no accept. Looks like your miners aren't SHA256d... its definitely sha256 and i used to mine BTC in Ghash.io with no problem sometimes it shows {"id": X, "result": true, "error": null}\n  Oh, is this the Tube? It's known to not work with anything but Ghash.io - seems to be a serious Tube bug. |
|
|
|
Hi,luke could you help me? I got that strange error only when i mined nicehash , full of hw and no accept. Looks like your miners aren't SHA256d... |
|
|
|
I have no opinion on this, and I'm not ashamed to admit I've no idea what the Mastercoin argument is, do you think you could spare a sentence or two as to why you think it's spam Luke, and perhaps the other guy as to why he doesn't think it's spam? Just something short and sweet to inform the rest of us, not a lengthy troll or anything.
tl;dr: People using Bitcoin have all agreed to store financial data and nothing else, using a scripting system to convey it. But MasterCoin transactions include metadata and unnecessary bloat, and lie about what kind of data it is in a way that makes the entire Bitcoin network less efficient.
From my understanding of MasterCoin, there are two ways I, and probably anyone who considers the blockchain to have a social agreement/contract, consider it spam: 1) The unnecessary 1Exodus output indicating it is a Mastercoin transaction. 2) The abuse of multisig and p2pkh outputs to convey data rather than OP_RETURN. 3) Some of the data may be non-financial/transactional in nature. Basically anything that isn't a pubkey shouldn't be scripted as a pubkey, anything that isn't a hash shouldn't be scripted as a hash, and anything that isn't financial data (not sure if this exists, but it was implied in this conversation earlier that it did) shouldn't appear directly in the blockchain. There is also an argument that MasterCoin is competing in supply (one cannot convert more bitcoins to mastercoins or vice-versa) and many users may not wish to support it when they store/validate the blockchain. Note I don't hold to this argument myself, as it seems to logically rule out any use of the blockchain for things like smart property (note that S.P. does in fact not require using the blockchain at all, but if it did, I don't see how it would violate the social contract of Bitcoin). Not per se related to spam, I think it would also be ideal if Mastercoin migrated to its own blockchain - it really has no inherent need to be inside bitcoin's, and does not benefit from being there either. It does benefit from having bitcoin miners securing it, but that can also be had by supporting some form of merged mining, which is just as safe if those same miners freely support it. |
|
|
|
|
Show Posts
