He can only "own" the market of his own block. There are a variety of filters that could be used to remove the "noise" of an attacker - signal analysis is a field in itself. For the purpose of explanation, I will give a simple unsophisticated filter: take the median of the last N blocks. That is to say, for each block determine what the average price is of the market you are interested in, and then take the median of those values over the last N blocks. The attacker or cartel of attackers needs >50% of the hashrate in order to reliably affect the median value. Observe that an "attacking" block is one whose inferred pricing deviates substantially from the actual order book known by other miners due to wash trades, and that difference would be observable.
We're talking about network-level sybil attackers; this isn't about hashing power. You can also think of this as a machine learning problem: you use unsupervised learning to group blocks into labeled buckets representing the underlying order book, and then choose the bucket which represents the most work over the last N blocks. You then compare that price structure with the orders you are seeing in the order-publication medium (p2p network, bitmessage, whatever) and decide whether you are being cheated or not.
That's vastly more complex and unreliable than having proof-of-publication available. After all you don't have to use it exclusively, just enough to detect and discourage attackers. Note how if we create a H(prevout) based CHECKSIG mode where the txid is not hashed you can arrange for a completed trade to prevent publishing of the trade itself separately. |
|
|
|
As I pointed out on the mailing list observing the chain for matched orders tells you nothing about whether or not those orders were ever published; that is, whether or not they're entirely fake and don't represent actual market depth.
As I said in the text you quoted, a filtered average over previous block solves this. Unless you are assuming the attacker has majority hashrate, in which case you're screwed anyway. An attacker who wanted to give a false impression of market depthactivity and/or prices could simply publish completed transactions to himself on the blockchain and have nothing to do with the mining process. These transactions would never be propagated as unfilled orders on the network, only as completed transactions. Forcing unfilled orders to propagate through the network, and be published in the blockchain, ensures that these orders are real, as they could be matched and filled by anybody. Exactly! I'm glad you realize this. |
|
|
|
...
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once?
I think you just need to have proof that it's been seen/published before  So P2SH^2 makes it hard to publish data by requiring another hash. If we can't send data directly via P2SH^2, we could still reveal our data in the actual script later on. Once the data is seen elsewhere (like in the script to redeem), we can then look at the previously confirmed P2SH^2 txn for the proof. You're close, but still misunderstanding it. With P2SH^2 when is the data hashed by the script first published? Remember that P2SH^2 is distinct from regular P2SH. |
|
|
|
Peter, I don't think that's fair or accurate. Anyone observing the chain gets proof of publication of matched orders, and a filtered average over the last N blocks gives you a relatively good idea of the current price in a secure way which you can compare with what you're seeing on the wire. Additionally, such a setup does not rule out the possibility of other proof-of-publication systems being used for distributing the orders. It simply recognizes that consensus over matched trades and consensus over open orders are logically distinct, and data from one need not clog up the other.
As I pointed out on the mailing list observing the chain for matched orders tells you nothing about whether or not those orders were ever published; that is, whether or not they're entirely fake and don't represent actual market depth. It's the same logic that came up in the discussion about announce/commit sacrifices. As for "other systems", remember that I did recently publish Tree Chains specifically to act as a general purpose proof-of-publication system for all uses with highly adjustable security/scalability tradeoffs. |
|
|
|
Except that the offer doesn't have to be published on-chain until the trade occurs. You could simply publish the bid and the ask at the same time to get single-step (from the chain's perspective) trades, and use some external mechanism such as the p2p network or bitmessage to move orders. This is what Freimarkets does.
Without a proof-of-publication system where you're guaranteed (with high probability) that your offer either gets to a well-defined audience or you find out you're being jammed you're vulnerable to getting ripped: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html If Freimarkets doesn't have that guarantee then it's insecure against sybil attacks, and worse, such attacks are profitable. |
|
|
|
Thanks Peter! In all honesty, I haven't had the time to look into the timestamping issue yet, thanks for the suggestions! I'm trying to keep the initial release as simple and as "blockchain agnostic" as possible. All it does for now is secure private keys, it has no notion of blockchain/transactions/ECDSA/etc, so it can be easily reapplied to just about any other altcoin that uses private keys (are there any that don't? ). I need to get the marketing materials done so I will probably stop adding features for a few weeks and focus on getting it launched. There's always room for a version 2 . Heh, I certainly do recommend you consider seriously that option! I've got a lot more ideas than there are hours in the day. Regarding the PIN, it's 4 digits / 3 tries. It's sent encrypted together with the private key and stored as an OwnerPIN JavaCard object (those are especially protected by the JavaCard runtime). You get 3 attempts to unlock the key - if you fail, the key is permanently blocked (I should probably make it delete it at that point to save space and prevent further attacks).
Sounds good. You can put me down for a pre-order BTW. |
|
|
|
Thank you Peter, I'll look into those paywords, I wasn't aware of that system. Smartcards do not have an internal clock, so I was initially thinking of using a certified time source (that is a web service that accepts a nonce and returns a signed time+nonce packet indicating the current time), but if this could be done in a distributed fashion it could be interesting. I'm not sure how that would work though, how would you limit the amount being transacted or do you only suggest limiting the number of transactions that a card can do in a given time interval?
Sorry! I must have read your reply and forgotten about it. The blockchain itself can be used as a clock in a few ways. The most obvious way is to process the block headers and just use the latest one lower bound on what time it is. However then you have to ask how does the card get the blockchain? You can add to the protocol an encrypted field that essentially lets anyone feed the card with block headers within any transaction going to it - if I'm sending you money I can inform your card about what time it is against your will. However, all the block headers are kinda large for a Java card, so you really want to only send a subset. When you think about it every header the card gets is essentially making a kind of statement that some amount of work was done claiming the current time at least blockHeader.nTime Every header the card gets pushes the likely current time in some direction, usually forward. Making a bunch of fake block headers with high difficulty is very expensive, so you can probably come up with some rule that makes faking headers to lie to the card about the current time unprofitable. You can be a bit more clever with this by using interactive or non-interactive proofs, but long story short, Bitcoin doesn't support that yet. You can also force the owner of the card to provide recent block headers via timestamping and merkle paths. The card would generate a nonce and and the card owner would be required to timestamp that nonce in the Bitcoin blockchain and provide the card with a merkle path from the nonce to the block header. The user is forced to keep providing the card with new blocks; with a minimum difficulty the cost of compromise is well defined, almost. Unfortunately it is possible for a group of card owners to collude and have some fake block headers generated so as to let them all benefit, driving the per-card cost of faking the time down. (possible without timestamping too I might add) Timestamping infrastructure doesn't exist yet, but creating it isn't hard. I have a project called OpenTimestamps that was doing just that - I'd be happy to put some time into it again. As for centralized time services personally I'd be very hesitant to use any kind of centralized service simply because it'd be temping for a court to order them to either shutdown, change keys, or sign fake timestamps as a way of disrupting OtherCoin users. A quick status update: OtherCoin is progressing nicely, I have cleaned up the protocol a bit and added the ability to send PIN-locked keys. A locked key is transferred just like any other Bitcoin key in the OtherCoin system but it's also protected by a PIN. Without the PIN, the recipient is unable to spend it or transfer it to another user. This allows a primitive type of escrow - once a key is transferred, the sender no longer has it but without the PIN, the recipient cannot do anything with it (other than verify that it exists and has funds on it). So the two parties have to agree in order for the recipient to obtain the necessary PIN to unlock the key.
Good idea! How long will this pin be? What will you do to prevent brute-forcing it? |
|
|
|
The opposite of over-engineering is under-engineering. Creating the least viable product. The most minimal, simple implementation that can do what you want it to do. Counterparty is this solution for the distributed exchange/Bitcoin 2.0 idea. It works, today. It does so by leveraging the existing Bitcoin network and protocol, which allows the developers to devote their time to getting the important parts right. How much would the Counterparty codebase increase in size if it required its own blockchain? I'm betting it would be somewhere in the triple to quadruple range. Counterparty will continue to work for at least the near future. If a day comes when it is made not to work by outside forces, Counterparty will change in order to work.
Actually that's incorrect: Counterparty and Mastercoin both have a significantly larger codebase by not requiring their own blockchain. Of course when I say "larger codebase" I mean the code required above and beyond the Satoshi codebase itself. Freimarkets is an example of a system that took the opposite approach of reusing the Satoshi codebase and requiring its own blockchain, and by doing so it got to reuse blockchain-related code from the Satoshi codebase that Counterparty and Mastercoin had to implement themselves. Of course, what they implemented is more simple than reimplementing blockchain code from scratch, but their approach is definitely not the "least-work" way of doing so; Freimarkets is. But if "what you want it to do" is to be secure against attackers, then the minimum viable product has to be an embedded system as opposed to independent or merge-mined and you're stuck writing embedded-consensus blockchain code. |
|
|
|
Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.
Counterparty does in fact interoperate with Bitcoin scripting in that you can add conditions to a transaction in the form of Bitcoin scripts - the transaction can only go through if the Bitcoin script evaluates true. I know for a fact that this is used in Mastercoin to allow for atomic Mastercoin<->Bitcoin trades in the decentralized marketplace functionality; I'm sure Counterparty works similarly. Further exploring how to exploit this is on my TODO list, as is adding scripting functionality to Mastercoin itself. (though I'm in no particular rush to do so - my TODO list is rather long!) Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.
I've said this over and over: Counterparty gains security from this. Client-side validation means you can't be harmed by malicious miners; merge-mining means you can be at nearly zero cost to those miners. We only have to look at Coiledcoin to see why this matters. As for the inefficiency, yes, currently the global state of the Mastercoin and Counterparty consensus is implemented inefficiently, which is why I'm working on examining how to improve on that with compact proofs of coin validity for Bitcoin. I'm pretty confident that at least linear scaling is possible with simple math using non-interactive proofs, better than linear with "moon-math". There are many ways to apply that research to embedded consensus systems. In the meantime I'm glad Mastercoin and Counterparty are exploring a huge set of other considerations related to the design of "decentralized finance 2.0" systems. |
|
|
|
Peter, could you supply a link to any and all P2SH^2 information? I'm afraid that what I found (a single short thread on the bitcoin devs mailing list) was not terribly complete (or maybe I'm just lacking on background implementation info).
I do appreciate your taking the time to teach.
That thread is the best resource on what P2SH^2 is; the question isn't so much about implementation, but rather understanding why Bitcoin works and what exactly is the role of mining. |
|
|
|
Disclaimer: I have not looked into the details of how P2SH^2 or even P2SH works yet.
I also think it's not possible to prevent embedding data. In baddw's scheme, pre-generating dozens of vanity-like addresses for the "alphabet" addresses should be an easy one time brute-force if we limit the number of bits per address.
Yeah, you're basically limited by how much space you have for that dictionary. For instance a 32-bit brute force dictionary, stored as 32-bit seeds, would be 17GiB. Could you not then embed the data by linking your alphabet addresses to all the vins/vouts of your transactions? Most of it could just be sending coins back and forth between your own "alphabit" addresses.
For the non-brute force solution, embed your bits into all the transaction values. ABCD can just be values in vout[1]vout[2]...etc...to your own addresses.
You guys are still all missing a even deeper implication of P2SH^2. I'll give you another hint: Does data need to be stored forever to prove it was published once? |
|
|
|
LightedLamp, I don't think that person you are quoting understands what we mean by "side-chain." There would be no storing of hashes via OP_RETURN, and no referencing of external transactions. A side-chain is just another block chain, but one which allows transfer of value back and forth between itself and the bitcoin chain (and other chains too). So you can move coins onto the side-chain, do whatever fancy transactions you want (e.g. distributed markets), and then move back when you are done.
Well if we're not going to call what I was talking about as a side-chain, what term do we want to use for the notion of a chain that consists of hashes embedded in one blockchain, that refer to data that we're not storing on that blockchain? Do you want to reserve the term side-chain for only a specific way of moving value from one to the other? Because from the user's point of view handling that by atomic purchases of shares for coins or whatever doesn't look much different from the SPV proofs model. You also have to ask if a side-chain refers to a specific proof-of-work consensus, or things like proof-of-sacrifice apply as well - and as I argued above, if the "hashes that refer to data stored elsewhere" has any hope of being secure you need actual incentives to publish and thus something like proof-of-sacrifice and a chain-style structure. |
|
|
|
I don't know if this meets all of the requirements stated, but based on a quick skimming of P2SH^2 and your Proof-of-Publication paper, here's a rough idea of an "attack" to store arbitrary data. This would require a tiny amount of brute-forcing, and it is not dust/fee-efficient, but I think it would work. I was unable to find the "2.0" discussion.
You missed the part where I said "no-brute-forcing" - I'm talking about something quite different that takes advantage of what P2SH^2 does. However, the rest of your post would work and is actually pretty clever, so sent you a tip all the same. |
|
|
|
No, it's not, it's a silly point.
Bitcoin includes transactions because it validates the data inside them.
Bitcoin clearly does not validate Counterparty data. I am free to include Counterparty data in my own transactions at any time. I am free to spend Counterparty coins to myself at any time, etc. Bitcoin doesn't care.
The level of validation performed by the bitcoin network is the same, whether full counterparty data or a simple hash is in the blockchain.
Long answer: re-read my paper on about proof-of-publication and how Bitcoin mining really works. Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain. Now you can try using something like the zookeyv concept I wrote about in #bitcoin-wizards last summer - I remember you saved a copy of that discussion - but then you run into a simple economics problem: if you can attack an individual system in one go, the cost required for security is going to be very high compared to the cost per transaction. Thus it's best if you spread that cost across multiple systems/uses, and force any attacker to attack them all at once. Anyway, this is all pedantic: Counterparty gains enormously in security by using the Bitcoin blockchain, and there's fuck all that Bitcoin can do about it if the Counterparty devs encode their transactions correctly. In fact, here's a really good test to see if you understand this stuff: Suppose P2SH^2 was implemented and everything other than pay-to-pubkey-hash transactions was disabled. How can embedded consensus systems take advantage of P2SH^2 to survive without resorting to the brute-forcing parts of the hash to encode the data and without resorting to using any data embedded in any part of the transaction other than the scriptPubKey? If you can guess why, you'll be a lot closer to understanding what proof-of-publication actually is; I'll give 50mBTC to the first person with a correct answer.(edit: unless your name is Gregory Maxwell! already told him) I'll give you some further hints: the solution in this scenario ends up creating huge amounts of unspendable outputs in the UTXO set, it is blocked by Gregory Maxwell's "P2SH^2 v2.0" idea where hashes can self-prove their hashes without proving a pre-image explicitly, and finally is actually cheaper for the embedded consensus system modulo the IsDust() rule. |
|
|
|
Hey, thanks for the link. I read a few wikipedia articles, the BitTorrent things and searched the forum + mailing list, nothing really worth to share though. I heard Mike Hearn recommended TomP2P and if you are looking for an easy implementation in Python or C#, there you go. Edit: FreePasteryTutorial might be worth to look at, too. It's worth searching through the #bitcoin-dev and #bitcoin-wizards irc logs for "DHT" - the Bitcoin development community considers them a joke for anything requiring security against adversaries, or even just good reliability in general: #bitcoin-dev/13/03/13-03-10.log:20:00 < Scrat> DHT makes your hair fall
#bitcoin-dev/13/03/13-03-10.log:20:02 < sipa> < gmaxwell> Someday I'm going to get myself invited to some conference with the president, and while he's talking about some middle east conflict thing— I'm going to ask if they've considered using a DHT.
#bitcoin-dev/13/05/13-05-07.log:15:51 < cjd> DHTs are annoying, they are just so pitifully attackable that in general one should avoid using them if at all possible
#bitcoin-dev/13/05/13-05-07.log:15:57 < sipa> gmaxwell: next time some suggests a DHT, tell them this is outdated technology... all the fancy kids on the block now use DH Rainbow Tables
#bitcoin-dev/13/05/13-05-07.log:15:58 <@gmaxwell> cjd: I think people mostly know that "TheCloud" is a ... at least a big vague. But basically every discussion about Bitcoin communications challenges has someone wade in and say "I KNOW GUIS! LETS US A DHT!"
#bitcoin-dev/13/06/13-06-12.log:13:14 <@jgarzik> I need to get on Cafe Press or somewhere that has an online t-shirt shop. Need shirts and coffee mugs with taglines like "DHT will fix it" or "have DHT, will travel"
#bitcoin-dev/13/10/13-10-07.log:17:05 < phantomcircuit> a naive DHT is not even remotely censorship resistant
#bitcoin-dev/13/10/13-10-07.log:17:05 < phantomcircuit> im actually fairly surprised the RIAA/MPAA haven't hired someone to fill the bittorrent DHT with nonsense yet
#
#bitcoin-wizards/13/03/13-03-06.log:23:41 < nanotube> jgarzik: if you want to troll gmaxwell, you have to mention DHTs, at least. #bitcoin-wizards/13/03/13-03-06.log:23:42 < amiller> did someone mention dhts #bitcoin-wizards/13/11/13-11-27.log:05:26 < gmaxwell> nah not you.. sorry, like, I've developed a pratice of reflexively ignoring anyone who says DHT. It's usually invoked by people who encounter a problem they don't understand and it really means "magical distributed thingy". Like early physicists invoking god when they encountered something they couldn't explain. #bitcoin-wizards/13/11/13-11-27.log:05:33 < adam3us> dht's usuall have extremely poor even non-hostile user characteristics, dht in a byzantine threat environment with real money on the line #bitcoin-wizards/13/11/13-11-27.log:05:35 < gmaxwell> yea, dht's basically appear to be unworkable in an adversarial enviroment. #bitcoin-wizards/13/11/13-11-27.log:05:42 < gmaxwell> mappum: bittorrent dht is mostly fail, it works .. kinda.. for very large swarms that can also do peer exchange, but mostly it just ends up helping people find other trackers. For small swarms it'll often spin finding nothing even when its not getting attacked. #bitcoin-wizards/13/11/13-11-27.log:05:43 < midnightmagic> you're never getting away from dhts are you #bitcoin-wizards/13/11/13-11-27.log:05:45 < gmaxwell> But there was a period of time when we couldn't go days without someone joing #bitcoin-dev and responding to the very first thing they heard with USE A DHT. #bitcoin-wizards/13/11/13-11-27.log:05:45 < midnightmagic> mappum: the endless, endless stream of users who come in to #bitcoin and insist we adopt dht rather than dns/irc for initial peer discovery is really astounding. it's jsut a running joke is all. no worries man. #bitcoin-wizards/13/11/13-11-27.log:05:46 < petertodd> mappum: pro-tip: suggest fidelity bonds instead, like a fidelity-bonded DHT #bitcoin-wizards/13/11/13-11-27.log:05:46 < gmaxwell> or instead of *, you name a technical challenge we've had in the bitcoin ecosystem and someone has suggested a DHT to solve it. #bitcoin-wizards/13/11/13-11-27.log:05:46 < gmaxwell> Signature validation slow? Use a DHT. etc. #bitcoin-wizards/13/12/13-12-19.log:22:43 <@gmaxwell> I would certantly be happy if DHTs were the magical tools people often assume they are. The more systems that get built which fail obviously when the DHT doesn't work the more likely people will work out the issues. #bitcoin-wizards/14/02/14-02-23.log:21:57 < gmaxwell> DHT has suffered waves of amazing hype, but generally been an actual engineering failure because of poor performance when not contructed out of spherical cows. By itself this isn't so bad, but because of the use of it in torrent (even where it actually doesn't work much of the time when you'd need it) it's often invoked by people who can't even understand explinations about why it wouldn't apply or wouldn't work for whatever ... #bitcoin-wizards/14/02/14-02-23.log:21:58 < andytoshi> gmaxwell: i actually had a person on PM -today- asking why an alt couldn't just use a DHT to use consensus #bitcoin-wizards/14/03/14-03-11.log:14:46 < gmaxwell> maybe there is indeed a way to use an anonymous consensus to undo some of the traditional DHT failsauce unreliability... but so far I've not seen any serious work. I think perhaps until we have some better language for abstractions about this stuff it will be too complicated to reason about.  #bitcoin-wizards/14/03/14-03-11.log:14:46 < Luke-Jr> much DHT You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability?
Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block?
Availability of all messages to reconstruct the latest state, right? At least that's the problem I see. To a lesser extend: each client must have at least access to the full chain of all transactions that involves one of his wallets to reconstruct his final balance and this is not necessarily given by a DHT. Altering of messages could be avoided, if OP_RETURN hash == key == H(message). Despite that, I'm still fascinated by the idea of on overnet, slightly related: if there were a mechanism of easy communication, people could send around CoinJoin transactions, establish channels for micropayments or open a communication line for multisig signing in general. And not just availability, but guaranteed availability with specific time limits. Basically, in a financial application it's not good enough to just have the message eventually get to the desired recipients - you need it to be guaranteed (with high probability) to either get to them in a certain amount of time or for the message to be considered invalid. (and detectably so) Blockchains due this because they're a genuine proof that messages were published, side-chains don't. That said, if you're just trying to, say, make a decentralized mailing list or something with good anti-censorship properties side-chains are probably just fine as you can always have the user's client handle censorship reactively, e.g. by retrying the message. Having a fallback to insert-in-blockchain available as a last resort is good too, and may discourage censors from trying in the first place. But Counterparty, Mastercoin, and Colored Coins are all financial applications and need much better censorship resistance and time guarantees than that. |
|
|
|
OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.
You know, an interesting question to ask yourself is if it's totally ok to just embed a hash of the actual data in the blockchain, and rely on the data itself being made available by some DHT or something, why can't Bitcoin itself do that to make blocks smaller and improve scalability? Remember that Bitcoin would work just fine if miners didn't validate transactions if clients implemented client-side validation, as is done in Mastercoin and Counterparty, and to a lesser extent, Colored Coins. What's so special about actually putting those tx's in the block? |
|
|
|
Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.
No I haven't. What I have done is (maybe) found ways to make Bitcoin scale by replacing the linear blockchain with alternative designs. (e.g. tree-chains) But without a solution being implemented that changes the underlying O(n^2) scaling my position is unchanged: increasing the blocksize as your scaling solution will centralize Bitcoin and ultimately destroy its value. Incidentally, the fact that such an approach might be possible in the future was something I discussed at the time with gmaxwell as well as the media/PR team I was working with, and we decided that simplifying the message was definitely the right idea. You can always update your message later when non-off-chain alternatives become viable. Meanwhile the "keep bitcoin free" video ensured that the most important messages got out to the community: that there is a tradeoff between decentralization and blocksize, and solutions exist other than simply raising it or eliminating the limit. By that measure the video was a great success and achieved my goals for it. |
|
|
|
Great news! Filter added to block this crap in less than 5 minutes, and 1 line of code. Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse. You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain. Heh, well, I had an interesting discussion about this stuff with one of the core devs, and there's actually kind of a nice advantage to Counterparty and similar moving to a system where careful steganography and similar measures are being taken to keep the system unblocked: if someone does do the "fill the chain with child porn" legal attack on Bitcoin the community can argue that they certainly didn't support it in any way. It also goes back to things like trying to ban or discourage address reuse: if your protocol can be censored, changing it to be harder to censor tends to be actually good for the ecosystem as a whole. An interesting thing to do might be to change Bitcoin to validate that 33 byte PUSHDATA's are valid pubkeys in the IsStandard() rules. The easiest way to co-erce arbitrary data to look like a pubkey is via something like Mastercoin's encoding scheme, and that has the nice property of being easiest to implement with steganography that hides the data and gives everyone in the ecosystem good plausible deniability. Anyway, I'm gonna write more about this in the coming weeks as a semi-formal paper, as well as talk about when you can get away with the lesser security of hash-linked side-chain schemes. Some best practices libraries implementing both would be useful for everyone in this ecosystem. Also, congrats on BitcoinTangibleTrust for doing something with this tech. |
|
|
|
Can somebody post some credible sources about the coiledcoin event? I currently mine via Eligius and would like to reconsider if this is being accurately portrayed.
More generally, I think pools should be a lot more aggressive about differentiating themselves politically, so small-time miners can 'vote' to support the kind of bitcoin we want. (Though I also understand Adam Back's point, that the miners aren't all that important in comparison to the 'political' clout of the people simply running a node, I still think there's some signal in supporting certain pools over others).
The credible source is Luke-Jr himself: https://bitcointalk.org/index.php?topic=56675.msg678006#msg678006Personally I find it disgusting how he keeps on saying I'm "slandering" him to bringing up coiledcoin yet refuses to answer to his actions. I've got no personal issue myself with the Coiledcoin attack - it's a decentralized "might is right" system - but he sure seems to find it inconvenient that his own actions prove so clearly my point that merge-mining is dangerous and embedded consensus systems are a much safer design. |
|
|
|
Please don't get me wrong, I do not say that we don't contribute to a higher utxo set and a general statement about the usage of multisig transactions is more difficult to make, because I have no idea how to evaluate the other 99.999%. My above used criteria were: "has an standard output to Exodus address and multisig output" and "has an multisig output with XCP magic bytes". If you have any idea, go ahead. Even with multisig neither Counterparty or Mastecoin need to be contributing to the UTXO set: just have one of the pubkeys be valid, with a secret key known to the user, and have their wallet software spend that txout the next time it needs to spend some money. You're transactions will be cheaper overall too. Again, this is another reason why you want to do an arbitrary encoding strategy. I'm rather solidly booked for the next two weeks, but we can talk about implementing that later as an upgrade. |
|
|
|
|
Show Posts
