Search content
Sort by
Showing 20 of 213 results by porqupine
Topic moved out of Bitcoin Development & Technical Disccussion thread
https://bitcointalk.org/index.php?topic=848283.0
Would like to know why before I repost it, since some arbitrary mod might ban me. Thanks.
Edit: NOTE the absolute lack of relevance to an alt-coin in any of the posts in the topic.
Quote
(Eliminating Nothing-is-at-Stake using Shamir's Secret Sharing)
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block), all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance, but with cryptocurrencies identity is already established with ECDSA, since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
Reward calculation can just be something like sum (stake/total_signing_stake * (coin_days modifier) * (fees_collected in block)).
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block), all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance, but with cryptocurrencies identity is already established with ECDSA, since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
Reward calculation can just be something like sum (stake/total_signing_stake * (coin_days modifier) * (fees_collected in block)).
Would like to know why before I repost it, since some arbitrary mod might ban me. Thanks.
Edit: NOTE the absolute lack of relevance to an alt-coin in any of the posts in the topic.
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block),
ECDSA is not deterministic (and can't be made deterministic in a publicly verifiable way). Also I'm not sure what the relationship between determinism and verifiability is? Also in your example can you clarify which key is used for signing, and how this is determined. (If the key does not need to be deterministic, you can us a unique signature scheme; there are efficient ones out there.)
Quote
all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance,
Can you clarify "cheater resistance"? Do you mean collusion, parties changing the secret after the fact, parties publishing invalid shares, ... ? What is the specific attack you are trying to block?
Quote
but with cryptocurrencies identity is already established with ECDSA,
Can you clarify this? ECDSA is a signature scheme and can't be used directly to establish identity.
Quote
since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.
"immediate" is a time-related word. Can you argue that you are not begging the question by assuming a consensus time-ordering? (In this case I think you are not, but I'm reading more than you've written so I want to make sure you're on the same page.)
Quote
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
How is this different from having them sign (n-1) blocks with the same key, and have a consensus rule that this is the condition for reward distribution?
As mentioned the idea is to prevent double signing - simple enough. In practice it's difficult because in i.e. Proof of Work there is an external input cost (electricity) which is the 'cost' of signing if you will, whereas with Proof of Stake there is no cost, since blockchain's are not conscious of 'each other' it's impossible to tell from blockchain A that someone is also signing blocks in blockchain B.
So the question is how do we limit someone's ability to make multiple signatures? My suggestion for doing it is having them give away information about deterministic secret S (known only to them) each time they sign. Suppose a hypothetical PoS implementation where one can collect a block reward after they have had the opportunity to sign 100 blocks. There aren't any limits to how or which blocks they sign, but if they sign one more block past 100 (or whatefer N is) would enable anyone to calculate S by polynomial interpolation.
"Cheater resistance" refers to the idea that in Shamir's secret sharing the dealer and the holders are assumed to be honest. There are no holders in this implementation (or everyone with a blockchain copy if want) and the dealer would be the signer. Cheating would be if for example the signer used S1 for Blockchain A and S2 for Blockchain B, they would still generate (Xi, Yi) pairs that would look correct, but interpolation using a combination of those points would not yield S correctly. Since signer or stakeholder is also signing with ECDSA when signing a block and giving a point pair, when they reveal S (or point N+1 would work as well), and reference the blocks which they signed to collect their block reward (fees), anyone can verify with interpolation that they provided valid points in all the referenced blocks.
(Eliminating Nothing-is-at-Stake using Shamir's Secret Sharing)
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block), all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance, but with cryptocurrencies identity is already established with ECDSA, since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
Reward calculation can just be something like sum (stake/total_signing_stake * (coin_days modifier) * (fees_collected in block)).
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block), all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance, but with cryptocurrencies identity is already established with ECDSA, since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
Reward calculation can just be something like sum (stake/total_signing_stake * (coin_days modifier) * (fees_collected in block)).
Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
It has been requested that I should clarify my post. As I initial disclosed 'cfd camper' is a bot for exploiting a bug which I had found in the CFD implementation. The bug and the associated attack are limited entirely to 'CFD' type bets, no other protocol functionality is, or ever was at risk.
I have written a technical analysis of the bug and the associated attack, which can be found here: https://xcpfeeds.info/cfd_attack/
I have written a technical analysis of the bug and the associated attack, which can be found here: https://xcpfeeds.info/cfd_attack/
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
I wrote up a Technical Analysis of the exploit: https://xcpfeeds.info/cfd_exploit/
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
Quote
There's more going on behind the scene if you're interested:
https://bitcointalk.org/index.php?topic=395761.msg8016900#msg8016900
https://bitcointalk.org/index.php?topic=395761.msg8016900#msg8016900
The only thing is going on is PhantomPhreak lying to cover up his gross negligence of an Exploit, and deleting any post I make.
And now that I've accidentally bumped this thread I hope the people that read the whole thing can see that the problem isn't an "exploit" so much as a coding flaw.
It's an exploitable coding flaw. Any unmatched CFD can be stolen - see https://github.com/porqup1ne/cfd_camper
I will be posting a technical paper with descriptions of the exploit and the original bug later as promised.
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
Sorry for the dumb question but how is the BEAR allowed to bet 1,000 on 10 escrow while the BULL isn't?
Wouldn't the BULL want to employ the same leverage as the BEAR?
If they did, then the calculation would add up to 20.
delta = (initial_value - value) * leverage * config.UNIT
bear_credit = bear_escrow + (delta * Fraction(bear_escrow,
bear_wager_quantity))
bull_credit = (escrow_less_fee - bear_escrow) - (delta *
Fraction(bull_escrow, bull_wager_quantity))
delta= 1
bear_escrow(10) + ( delta(1) * (bear_escrow(10)/bear_wager_quantity(1000))
10.01
bull_credit = (escrow(20) - bear_escrow(10)) - (delta(1) *
(bull_escrow(10)/bull_wager(1000)) = 9.99
9.99 + 10.01 = 20
Wouldn't the BULL want to employ the same leverage as the BEAR?
If they did, then the calculation would add up to 20.
delta = (initial_value - value) * leverage * config.UNIT
bear_credit = bear_escrow + (delta * Fraction(bear_escrow,
bear_wager_quantity))
bull_credit = (escrow_less_fee - bear_escrow) - (delta *
Fraction(bull_escrow, bull_wager_quantity))
delta= 1
bear_escrow(10) + ( delta(1) * (bear_escrow(10)/bear_wager_quantity(1000))
10.01
bull_credit = (escrow(20) - bear_escrow(10)) - (delta(1) *
(bull_escrow(10)/bull_wager(1000)) = 9.99
9.99 + 10.01 = 20
It's like an order on an Exchange that can be split into smaller blocks - so that someone betting 1000 XCP - should be able to split to match with 10XCP, 100XCP etc. so they can get filled - if they needed to get matched exactly it would probably make the entire system useless.
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
Here is the Reddit thread.
http://www.reddit.com/r/counterparty/comments/2bmlg6/ann_counterparty_exploit_public_disclosure/
http://www.reddit.com/r/counterparty/comments/2bmlg6/ann_counterparty_exploit_public_disclosure/
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
One of my many issues opened (closed instantly):
https://github.com/CounterpartyXCP/counterpartyd/issues/189
PhantomPhreak opens an issue:
https://github.com/CounterpartyXCP/counterpartyd/issues/191
With a proposed fix:
https://github.com/CounterpartyXCP/counterpartyd/commit/0229f63008fdbdd2d363d96646136e16a1006bd4
Here is my email writing out the basic arithmetic. The funny thing is I basically wrote it out before he posted that issue with a broken "fix".
Notice it was a total of 20 (the wager) - but out of escrow comes only 19.01 - .99 just disappear!
https://github.com/CounterpartyXCP/counterpartyd/issues/189
PhantomPhreak opens an issue:
https://github.com/CounterpartyXCP/counterpartyd/issues/191
With a proposed fix:
https://github.com/CounterpartyXCP/counterpartyd/commit/0229f63008fdbdd2d363d96646136e16a1006bd4
Here is my email writing out the basic arithmetic. The funny thing is I basically wrote it out before he posted that issue with a broken "fix".
Quote
If you're not going to listen to my explanations than please test your
solutions yourself - before posting them.
One more time though - the math is not working again:
delta = (initial_value - value) * leverage * config.UNIT
bear_credit = bear_escrow + (delta * Fraction(bear_escrow,
bear_wager_quantity))
bull_credit = (escrow_less_fee - bear_escrow) - (delta *
Fraction(bull_escrow, bull_wager_quantity))
delta= 1
bear_escrow(10) + ( delta(1) * (bear_escrow(10)/bear_wager_quantity(1000))
10.01
bull_credit = (escrow(20) - bear_escrow(10)) - (delta(1) *
(bull_escrow(10)/bull_wager(10)) = 9
solutions yourself - before posting them.
One more time though - the math is not working again:
delta = (initial_value - value) * leverage * config.UNIT
bear_credit = bear_escrow + (delta * Fraction(bear_escrow,
bear_wager_quantity))
bull_credit = (escrow_less_fee - bear_escrow) - (delta *
Fraction(bull_escrow, bull_wager_quantity))
delta= 1
bear_escrow(10) + ( delta(1) * (bear_escrow(10)/bear_wager_quantity(1000))
10.01
bull_credit = (escrow(20) - bear_escrow(10)) - (delta(1) *
(bull_escrow(10)/bull_wager(10)) = 9
Notice it was a total of 20 (the wager) - but out of escrow comes only 19.01 - .99 just disappear!
Quote
What I'm saying is overall is leverages don't match - more so let's assume
you always take the first leverage (or Fraction ratio) and default the
bull to the second one (to fix the sanity error).
I make a bet:
10/10 (wager-counterwager)
if matched with 10/10 (wager-counterwager):
movement per price delta = 1:1
if matched with a 10 from 1000/1000 (wager-countergwager):
movement per price delta = 1/100
result: No user control over the bet movement.
And it's not like this is the only problem with CFD's, this whole business
of monkey patching, and ignoring the what's happening and the purpose of
these instruments is just absurd.
you always take the first leverage (or Fraction ratio) and default the
bull to the second one (to fix the sanity error).
I make a bet:
10/10 (wager-counterwager)
if matched with 10/10 (wager-counterwager):
movement per price delta = 1:1
if matched with a 10 from 1000/1000 (wager-countergwager):
movement per price delta = 1/100
result: No user control over the bet movement.
And it's not like this is the only problem with CFD's, this whole business
of monkey patching, and ignoring the what's happening and the purpose of
these instruments is just absurd.
Re: [ANN] Counterparty Protocol Exploit - Cash out any CFD's
Did you try to approach him privately? Not publicly ?
Maybe he felt attacker, or something?
Maybe he felt attacker, or something?
I have indeed messaged him in private, to the point of being blocked on skype, than spent a week attempting to email and make him aware of this, I have also CCed all the other devs and they know the issue has been raised. Also on Github. I can post screenshots / Chatlogs to prove this if anyone has doubts.
[ANN] Counterparty Protocol CFD Exploit - Cash out any CFD's
*Updated*
Technical Analysis: https://xcpfeeds.info/cfd_exploit/
Note as of earlier today Counterparty CFDs are disabled
Here is the Bot to exploit said vulnerability: https://github.com/porqup1ne/cfd_camper
I've made multiple attempts to disclose this. Also I have offered to prove the exploit on a CFD made by PhantomPhreak - he has refused to do so, but has deleted my posts from the official thread.
Hi everyone, I'm known as Porqupine on Bitcointalk and Porqup1ne on reddit,
My github is here https://github.com/porqup1ne -
I am the sole developer/maintainer of https://xcpfeeds.info
I have also contributed consistently to bug fixing the Counterpartyd reference client and it's development.
I am announcing publicly because over a week ago I discovered a bug in the Counterparty CFD implementation which could be exploited to cause anyone making CFD's to loose their entire wager. I have spent the entire week in attempting to make a reasonable disclosure of this issue and to implement a fix. I have been blocked on Skype by Phantomphreak, my emails have been ignored, he has denied that there is any kind of exploit or vulnerability, and my requests have been closed on Github.
I have made sure to keep Evan, Ouziel and Robby (the other team members) aware of this issue as well, and have CCed them in all of my correspondence with PhantomPhreak (Adam). I have proposed a working fix - which anyone can verify is working. PhantomPhreak (Adam) claims he has done work on this issue - he has opened a ticket specifically ignoring my discussion of why that ticket will not work, his 'example fix' causes Sanity Errors in the protocol, he has demonstrated consistent disregard for the exploit by denying it exists or any such thing is possible.
After my initial private communications were shut off I open sourced a bot 'CFD Camper' (https://github.com/porqup1ne/cfd_camper) in an attempt to disclose this issue without getting jerked around again by these internal communications. These have had no effect. I cannot in good faith continue to develop or promote XCPfeeds.info or Counterparty while this remains unfixed. Those users who have lost their funds to CFD Camper (it has only been around 80 XCP worth of bets) will be reimbursed directly to their addresses.
I will now proceed to publicly demonstrate the nature of this exploit, shortly after I will post an article explaining how CFD Camper works, the nature of the exploit, the technical details of the code that led to it, and so forth, for those technically interested.
P.S. PhantomPhreak will obviously try to delete my posts and otherwise Ban me. Please believe me when I say I am making this public because this is a fundamental issue for anyone invested in Counterparty or interested in open-source finance. Protocol development I am convinced cannot be in the hands of a maniac with various eccentricties that prevent him from taking responsiblity and given considerations to opinions other than his own, Especially when it leaves users vulnerable to loss of funds.
TL:DR I am an open-source developer working on the Counterparty platform, I have spent over a week getting jerked around by Adam (PhantomPhreak) while trying to disclose and fix a security issue. I am now publicly disclosing the issue, I will prove it is an issue by exploiting it to steal an arbitrary amount of funds from any open CFD. I am selling all my stake and I am done developing on Counterparty.
Technical Analysis: https://xcpfeeds.info/cfd_exploit/
Note as of earlier today Counterparty CFDs are disabled
Here is the Bot to exploit said vulnerability: https://github.com/porqup1ne/cfd_camper
I've made multiple attempts to disclose this. Also I have offered to prove the exploit on a CFD made by PhantomPhreak - he has refused to do so, but has deleted my posts from the official thread.
Hi everyone, I'm known as Porqupine on Bitcointalk and Porqup1ne on reddit,
My github is here https://github.com/porqup1ne -
I am the sole developer/maintainer of https://xcpfeeds.info
I have also contributed consistently to bug fixing the Counterpartyd reference client and it's development.
I am announcing publicly because over a week ago I discovered a bug in the Counterparty CFD implementation which could be exploited to cause anyone making CFD's to loose their entire wager. I have spent the entire week in attempting to make a reasonable disclosure of this issue and to implement a fix. I have been blocked on Skype by Phantomphreak, my emails have been ignored, he has denied that there is any kind of exploit or vulnerability, and my requests have been closed on Github.
I have made sure to keep Evan, Ouziel and Robby (the other team members) aware of this issue as well, and have CCed them in all of my correspondence with PhantomPhreak (Adam). I have proposed a working fix - which anyone can verify is working. PhantomPhreak (Adam) claims he has done work on this issue - he has opened a ticket specifically ignoring my discussion of why that ticket will not work, his 'example fix' causes Sanity Errors in the protocol, he has demonstrated consistent disregard for the exploit by denying it exists or any such thing is possible.
After my initial private communications were shut off I open sourced a bot 'CFD Camper' (https://github.com/porqup1ne/cfd_camper) in an attempt to disclose this issue without getting jerked around again by these internal communications. These have had no effect. I cannot in good faith continue to develop or promote XCPfeeds.info or Counterparty while this remains unfixed. Those users who have lost their funds to CFD Camper (it has only been around 80 XCP worth of bets) will be reimbursed directly to their addresses.
I will now proceed to publicly demonstrate the nature of this exploit, shortly after I will post an article explaining how CFD Camper works, the nature of the exploit, the technical details of the code that led to it, and so forth, for those technically interested.
P.S. PhantomPhreak will obviously try to delete my posts and otherwise Ban me. Please believe me when I say I am making this public because this is a fundamental issue for anyone invested in Counterparty or interested in open-source finance. Protocol development I am convinced cannot be in the hands of a maniac with various eccentricties that prevent him from taking responsiblity and given considerations to opinions other than his own, Especially when it leaves users vulnerable to loss of funds.
TL:DR I am an open-source developer working on the Counterparty platform, I have spent over a week getting jerked around by Adam (PhantomPhreak) while trying to disclose and fix a security issue. I am now publicly disclosing the issue, I will prove it is an issue by exploiting it to steal an arbitrary amount of funds from any open CFD. I am selling all my stake and I am done developing on Counterparty.
Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
Well, I clicked the green button to "Create New Wallet" and it generated a passphrase which I copied over to the Passphrase text box. Then what ? The "Wallet Open" blue button was still grey.
My bad, one tries to introduce improvements (and I think it is) but unfortunately it is also wont to cause some unintended difficulties. Note:
Quote
In an effort to encourage good security practices the passphrase login cannot be pasted but must be typed word by word.
If you have any further issues feel free to report them at: https://github.com/porqup1ne/xcpfeeds.info-issues
wow ! that's great innovation, but maybe it should try to detect / prevent "copy over", as it is what we're used to from counterwalelt.
I'm somewhat worried that encourages people to do the next "logical" step in that chain, which is copy over to Desktop/password.txt, ctrl+v, click save.
Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
Well, I clicked the green button to "Create New Wallet" and it generated a passphrase which I copied over to the Passphrase text box. Then what ? The "Wallet Open" blue button was still grey.
My bad, one tries to introduce improvements (and I think it is) but unfortunately it is also wont to cause some unintended difficulties. Note:
Quote
In an effort to encourage good security practices the passphrase login cannot be pasted but must be typed word by word.
If you have any further issues feel free to report them at: https://github.com/porqup1ne/xcpfeeds.info-issues
Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
Quote
Yo what up - it be B-Party in the house. I'm goin to be doin sum of the public announcin 4 XCPfeeds.info. Today we has got sum terrific content goin up. It has got to be called an XCPfeeds.info double release. So dig this - first of all we got those CFD's you all been waitin 4 - right on front page: http://xcpfeeds.info/
And then even bettar becuz you know, we has thought maybe it be not enough to bring you the first GUI for CFDs, becuz you want be sure you makin money with them CFDs, you kno what i'm sayin' so we got the one and only, CFD Camper 'cfd bot'. And not only do it make you money, you can get it 4 free. Thas rite, free and open source, rite here: https://github.com/porqup1ne/cfd_camper
So if you making them CFDs and you ain' using CFD Camper your money be as good as gone, foo'.
Dis be all for today. Check you later homies. B-Party.
And then even bettar becuz you know, we has thought maybe it be not enough to bring you the first GUI for CFDs, becuz you want be sure you makin money with them CFDs, you kno what i'm sayin' so we got the one and only, CFD Camper 'cfd bot'. And not only do it make you money, you can get it 4 free. Thas rite, free and open source, rite here: https://github.com/porqup1ne/cfd_camper
So if you making them CFDs and you ain' using CFD Camper your money be as good as gone, foo'.
Dis be all for today. Check you later homies. B-Party.
I has got a X-post from reddit with sum dope news indeed. Check it. http://www.reddit.com/r/counterparty_xcp/comments/2bbigf/xcpfeedsinfo_double_release_yo/
B-Party
Just checked out to xcpfeed. Is it having a wallet service separating from the main counterwallet that works with on-site xcpfeed betting or something ? The wallet did not work at the time I tried. (unable to create new wallet)
Yes there is a separate wallet. Note the login is the same as for Counterwallet - but you are by no means required to use it, just pasting a wallet public address (that has had at least 1 sent transaction) will produce a raw transaction which can be signed in any Bitcoin wallet.
As for your wallet not working - trying it now and works fine for me? Can you be any more specific? What have you done and what exactly happened?
Re: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread
Re: [ANN] Crypti | Release July | 100% POS | New Source | IPO Started
I'm offering a bet of any amount up to 1000 XCP to any participants that Crypti does not have a working reference client and is Vaporware.
A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
Stas Oskin: "The source code of the complete project and following updates will be provided in quarterly releases. This will protect buyers against early clones."
Method of Proof: A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
bitcoiner (xbet.io): if what we need to do to decide the bet is check that hash, this is something that is possible. we cannot however check the insides of the code and assess their difference from nxt
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
There's a BETA client available....
Then don't go spamming your Vaporware outside of the forum thread, and I won't be here. Also if you actually do have a product thats up to 4.5 free BTC for you at 0 cost, so feel free to step up.
Don't spam your vaporware outside of your forum thread and I wouldn't be on here. And if you actually do have a product that bet is up to 4BTC at 0 cost for any of you. So feel free to step up.
I don't see any BETA client, I see a closed Source Wallet which might be running on an SQL server or directly on NXT testnet for all I know.
Ok, it's vaporware. Now go
I wouldn't be here if you weren't spamming your Vaporware outside your thread. Also if you really do have a product, that's up to 1000 Free XCP on the table, so feel free to step up.
P.S. I'm not a troll, I'm the http://xcpfeeds.info developer. One of the persons involved in the development of Cryptsi Pump and Dump project was advertising it in Counterparty Chat. I responded by asking him to advertise his Vaporware somewhere else, and he insisted it is not Vaporware - Hence I'm offering Public Terms for someone to prove me wrong.
BTW Counterparty was an original protocol with the code Open Source on Day #1.
If you read the other 70 pages here, you will see that I am one of the biggest critics of this coin, and I have not been shy about posting my comments, but...........
1) I dont see this as vaporware. It is obvious that the devs ARE trying to launch a coin
2) they are developing a unique algo using java nodes, mainly because the dev is a java programer
3) they are really really trying to get this going
However:
4) they are attempting to get their money upfront, rather than waiting to see if the coin is a success, thus transferring the risk of failure from the devs to the investors
5) they offer a coin into a very crowded market, without a marketable niche feature
6) their coin cannot be mined, only purchased in the pre-sale or exchange
7) all 100 million coins will be available on the first day of the launch, with maybe 40-60million hitting the exchange first day
there is nothing to prevent them from walking away from the coin later.The obvious point is that NXT doesn't have a real non-exploitable PoS algorithm. And Cryptsi is here claiming they are going to deliver 3 more on top of that. If they as much as had a solution for the nothing-at-stake problem that was non-exploitable of course it would be huge, but do they have a solution for that and these other algorithms they are claiming they can have? I'd give it a .1%, but unfortunately that's not something I can bet on directly.
Re: [ANN] Crypti | Release July | 100% POS | New Source | IPO Started
I'm offering a bet of any amount up to 1000 XCP to any participants that Crypti does not have a working reference client and is Vaporware.
A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
Stas Oskin: "The source code of the complete project and following updates will be provided in quarterly releases. This will protect buyers against early clones."
Method of Proof: A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
bitcoiner (xbet.io): if what we need to do to decide the bet is check that hash, this is something that is possible. we cannot however check the insides of the code and assess their difference from nxt
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
There's a BETA client available....
Then don't go spamming your Vaporware outside of the forum thread, and I won't be here. Also if you actually do have a product thats up to 4.5 free BTC for you at 0 cost, so feel free to step up.
Don't spam your vaporware outside of your forum thread and I wouldn't be on here. And if you actually do have a product that bet is up to 4BTC at 0 cost for any of you. So feel free to step up.
I don't see any BETA client, I see a closed Source Wallet which might be running on an SQL server or directly on NXT testnet for all I know.
Ok, it's vaporware. Now go
I wouldn't be here if you weren't spamming your Vaporware outside your thread. Also if you really do have a product, that's up to 1000 Free XCP on the table, so feel free to step up.
P.S. I'm not a troll, I'm the http://xcpfeeds.info developer. One of the persons involved in the development of Cryptsi Pump and Dump project was advertising it in Counterparty Chat. I responded by asking him to advertise his Vaporware somewhere else, and he insisted it is not Vaporware - Hence I'm offering Public Terms for someone to prove me wrong.
BTW Counterparty was an original protocol with the code Open Source on Day #1.
Re: [ANN] Crypti | Release July | 100% POS | New Source | IPO Started
I'm offering a bet of any amount up to 1000 XCP to any participants that Crypti does not have a working reference client and is Vaporware.
A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
Stas Oskin: "The source code of the complete project and following updates will be provided in quarterly releases. This will protect buyers against early clones."
Method of Proof: A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
bitcoiner (xbet.io): if what we need to do to decide the bet is check that hash, this is something that is possible. we cannot however check the insides of the code and assess their difference from nxt
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
There's a BETA client available....
I don't see any BETA client, I see a closed Source Wallet which might be running on an SQL server or directly on NXT testnet for all I know.
Re: [ANN] Crypti | Release July | 100% POS | New Source | IPO Started
I'm offering a bet of any amount up to 1000 XCP to any participants that Crypti does not have a working reference client and is Vaporware.
A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
Stas Oskin: "The source code of the complete project and following updates will be provided in quarterly releases. This will protect buyers against early clones."
Method of Proof: A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
bitcoiner (xbet.io): if what we need to do to decide the bet is check that hash, this is something that is possible. we cannot however check the insides of the code and assess their difference from nxt
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
Nobody said the source will be published within 3 months. it might take 6-12 months.
It might take enough time to Pump & Dump your Vaporware?
Re: [ANN] Crypti | Release July | 100% POS | New Source | IPO Started
I'm offering a bet of any amount up to 1000 XCP to any participants that Crypti does not have a working reference client and is Vaporware.
A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
Stas Oskin: "The source code of the complete project and following updates will be provided in quarterly releases. This will protect buyers against early clones."
Method of Proof: A hash of the current Working Private Code is embedded into the Blockchain with Multisig or OP Return. A Counterparty Binary Bet is made on a Broadcast of a trusted-third-party with a deadline three Months from now when their code goes public the trusted-third-party broadcasts the outcome.
Bitcoiner from Xbet.io has agreed to facilitate this Broadcast (though I am open to other trusted-third-parties) - with the following match conditions:
Quote
bitcoiner (xbet.io): if what we need to do to decide the bet is check that hash, this is something that is possible. we cannot however check the insides of the code and assess their difference from nxt
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win
bitcoiner (xbet.io): i think we can do something like this - we will download the code, run it, if we are able to perform a send from one client to another, and the source is in node.js like stas said, we will decide that stas wins. if we cant run it or we cant send from one client to the other or if the code is the same language as nxt (what is that btw?) you win