 Show Posts
|
|
Pages: [1] 2 »
|
Good, glad to see someone finally being serious about this. I think you'd want to get demo of crosschain p2pt running before asking foundation to fund it, if I see repo with sensible code, I'll even help you. The wording in the paper is a bit unfortunate imho, it sounds a bit like heresy - your altchain is designed to support fragmentation of Bitcoin ecosystem and you're asking Bitcoin foundation to support that? Maybe you want to tweak your wording a bit. There are far more productive use cases for cp2pt than just faciliating BTC x LTC x otherscamltc p2ptrade. |
|
|
|
|
This was discussed briefly in #bitcoin-dev. It's actually possible using game theory.
Use infinite prisonners dilemma of evildoers vs collaborators (basically you need to guess the others strategy mid-game). Whoever is ultimate winner in a round (everyone can replay the game to verify the "proof of game"), mines the block. Generalized poker.
Some notes:
* You need chips to play with - for the sake of simplicity no PoS for now, still use SHA256 pow as base currency. Big miners will have lots of chips to play in the round. However being rich is useless, if you don't know the intricacies of playing poker ... basically even small group of sha256 miners has a chance, if their game algo is much more sophisticated.
* Spiking NNs need massively shared memory, such computing clusters are forced to cooperate, (T=4 will beat all T=2 powerful brains, one by one).
* The fact anyone can be double (to N) agent is part of the game
* There might be problem that you might end-up with megacorp vs secondary megacorp (think Dems vs Reps and the rivalship is just theater), but i doubt it.
|
|
|
|
I thought that bucket shops pay dividends... Can you point out one bucket shop that do not pay dividends?
Then it's not a bucketshop, as far as user is concerned, it's a passthru, regardless of whether it's held or not - there is no difference to be told from the outside. Usually one has to wait for large dividend which the bucketeer cannot cover from his profits, and at that moment they're exposed. They cannot provide voting rights because if they do, they can expose themselves to the regulators.
That's why "even", but don't oversimplify, there are bearer instruments ... |
|
|
|
|
Regarding scam warnings:
If they're paying dividends (or even equity voting rights) for securities they're doing passthru for, it's legit.
Otherwise just another bucketshop.
|
|
|
|
because it's easy to inject code living in an anonymous js closure of setTimeout and delete the tag
How would that work. To me the blockchain checker looks like it would do the job. Start a bounty for MyWallet injection exploit (5BTC to be worth the while). Exploit description: The content script used by My Wallet checker runs in document_idle state, when script tags of document are already executing. if it used run_at: document_end, it would have chance to catch remote script tag, but not inline javascript. if it used run_at: document_start, there is not even DOM constructed, so you have nothing to inspect, though you might have chance to hook early and check DOM as it loads. Unsure if possible to attain reliability here, but certainly not done by the checker now. In short, checking the DOM after it is loaded is harder than naive implementation, because once it loads, code contained there can modify itself (simply setTimeout and remove the script tag). Note that this is only one of MyWallet's unbacked claims of security, there are much more :) |
|
|
|
Using chrome extension is silly, because then you can just have whole wallet in it and not bother with checking. The checker is valuable on mobile devices where extensions (and local static html files) dont work or poorly. Perhaps android app using webview?
You can already download carbonwallet as a chrome extension. So this monitor app would be for people who use the wallet online. I've sent you pull request which merges everything into single html file, so it's not as much broken as MyWallet (which checks script tags - that is actually pretty useless because it's easy to inject code living in an anonymous js closure of setTimeout and delete the tag). Verification is trivial, just xhr the index.html and compute hash for it. |
|
|
|
There is problem with that ajax part - what you really want is cross-domain XHR, with no proxies (YQL). However github will not send the necessary header for that to work - github won't send access-control-allow-origin: *.
YQL handles cross domain see http://ajaxian.com/archives/using-yql-as-a-proxy-for-cross-domain-ajaxI agree it would be better without the proxy. Perhaps when it is packaged as a chrome extension the proxy could be bypassed. I assume you started carbonwallet because you dont want to repeat piuk's mistakes, or am I wrong? Yeah proxies sucks because you can special-case the yahoo ip range. The checker must be indistiguishable from regular browser. Basically, you need to do this: #!/bin/bash
curl -s https://raw.github.com/carbonwallet/carbonwallet.github.io/master/index.html | grep 'src=' | cut -d '"' -f 2 | while read n; do echo "Checking $n"; diff -B <( curl -s http://carbonwallet.com/$n ) <( curl -s https://raw.github.com/carbonwallet/carbonwallet.github.io/master/$n ); done
diff -B <( curl -s http://carbonwallet.com/ ) <( curl -s https://raw.github.com/carbonwallet/carbonwallet.github.io/master/index.html )
But from browser and without referrer (https vs http xhr). Using chrome extension is silly, because then you can just have whole wallet in it and not bother with checking. The checker is valuable on mobile devices where extensions (and local static html files) dont work or poorly. Perhaps android app using webview? |
|
|
|
|
An actually existing p2p exchange demo:
groups.google.com/forum/?hl=cs&fromgroups=#!topic/bitcoinx/i9-OdIxNDfE
|
|
|
|
Since your site is hosted via github pages, what's the point? An attacker who will compromise github will just modify the repo - the site will change along with it  gh-pages lacks ssl support though, so i guess this is (rather strange) way to close the door for evil-hostpot-mitm injection attacks? I'd prefer just old fashioned chrome extension (that is actually strong guarantee) and ssl for mobile devices. Other than that, the wallet looks nice, will try to use it with some pocket change for a while Thanks for the reply. This app would be there to re-assure users that the code loaded from the domain is the same as that on the repository. It's possible to redirect the domain away from the repository and therefore deliver a different set of JS files to the user. This would assure them that this had not happened. I chose a HTML page rather than a chrome extension just because it's easier to use (i.e. not everyone has chrome). To repackage the page as an extension would be rather trivial I think. Also the site is a 1 page app with no server. Therefore SSL is not required as the only communication is retrieving TX information and sending TX which are all public knowledge anyway. I see. There is problem with that ajax part - what you really want is cross-domain XHR, with no proxies (YQL). However github will not send the necessary header for that to work - github won't send access-control-allow-origin: *. What you're saying would make sense if you hosted the site at your server, and you'd send the necessary header. I'll do the checker then for you Another option may be some sort of bookmarklet, but thats rather user-unfriendly :/ |
|
|
|
Since your site is hosted via github pages, what's the point? An attacker who will compromise github will just modify the repo - the site will change along with it gh-pages lacks ssl support though, so i guess this is (rather strange) way to close the door for evil-hostpot-mitm injection attacks? I'd prefer just old fashioned chrome extension (that is actually strong guarantee) and ssl for mobile devices. That being said, the wallet looks nice and the code is nicely clean, very impressive! Will try to use it with some pocket change for a while |
|
|
|
Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.
I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell. In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network. (taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade ) I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin. There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above? I can, however, see how some easy modifications could eliminate some edge conditions. There are no edge cases as long the bitcoin tx is kept private until the right time. I didnt bother implementing such altcoin (just fork bitcoin, add the opcode, track two blockchains) because ultimately there is no use for it yet (stuff i mentioned before must happen first) |
|
|
|
[...] altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.
This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community. Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work. Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?
In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network. (taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade ) Equivalent scheme can be used for OT as well (smart contract which needs bitcoin oracle). |
|
|
|
Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.
This is where something like Marketcoin is very useful, quick trustless exchange of value between chains means altchains only need one function (like a zerocoin altchain or a bitshares altchain) in order to be useful. We should function on creating functional, innovative coins instead of trying to cram everything into Bitcoin. Bitcoin is wonderful, but it is designed as money and I think it would be good to keep it that way. The entire point of open source is that if someone want's to improve or alter Bitcoin they can. Which is why altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain. Crosschain p2ptrade is actually easy problem if your altchain is designed to support it. Only place where you hit the blocks is things like direct LTC x BTC without established altchain proxy supporting cross-chain p2ptrade. Cryptocurrency design is not just code alone, but common market patterns (greed/fear) as well, otherwise you end up with another chicken-egg schizm nobody wants to use because nobody uses it thus cannot be trusted. |
|
|
|
I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is a mess, new code is found here:
git@github.com:bytemaster/bitshares.git
I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.
Yep, checked it out before and was disappointed it's just "draft specification by C++". By bitcoin integration I didn't mean to use bitcoin-qt as shared code base (starting from scratch is probably indeed wiser especially if the ledger is architecturally too far from bitcoin), but to allow markets within bitcoin main blockchain. Sure that is cumbersome (various coloring and sigscript schemes), but the point is to serve existing userbase. That being said, I'm looking forward to functional prototype, altcoins (and ledgers like OT) are still very interesting from research perspective, getting the "adoption" part right is a tough one though. Ask fellowtraveller. |
|
|
|
I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality. What I think the OP is really after is getting everyone on the same page and working together. Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place.
To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change. I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine. This bounty will then serve to help get the project funded and going.
That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is.
Problem is all I can see in your bitshare-bitcoin repo is few few markdown files. Also, this: https://github.com/bytemaster/bitshare_bitcoin_branch/commit/b4bb2acb075181d7e34834763ef6a01cc0483cd0So which is it, do you want to joint-design protocol, or IPO an vaporware you have not written single line of code? At least ripple people have *something*, though they premine too Remember, english text does not count. People reinvent ideas on this forum every second. Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on. |
|
|
|
As I'm one of developers of p2ptrade let me just say that it would be nice if more people would focus on implementation (yes, there are several projects out there - bitcoinx, pybonds, bitsofproof..). Op is, however, just "contributing" useless blabber on forums and reddit. There is vast amount of good and well researched ideas, what's missing is workable implementations with a chance for massive adoption. I'd suggest op to first try lurk more and contact relevant projects, instead of another a`la buttercoin trolling. Thanks. |
|
|
|
Practical reasons - people ramped up difficulty on testnet1-2 and then stopped mining.
Waiting several hours for a single block to confirm interfered with the purpose of testnet. Hence the reset rule.
Not that reset, I mean the new genesis blocks. Testnet is still difficult to mine as long the 20 minute rule is upheld. From that perspective, the value can be derived from the stakes miners have in difficulty not being reset as it would massively devalue the coins they've mined thus far. The "risk" of reset is immense, because all miners would have to tightly cooperate (not to mention external factors such as ddos attacks). |
|
|
|
|
Practical reasons - people ramped up difficulty on testnet1-2 and then stopped mining.
Waiting several hours for a single block to confirm interfered with the purpose of testnet. Hence the reset rule.
|
|
|
|
|
