synechist
Legendary
 Offline
Activity: 1190
Merit: 1000
To commodify ethicality is to ethicise the market
|
 |
June 06, 2014, 01:04:56 PM |
|
doesn't the network have to agree on what was the initial transaction? Therefore knowing that a bad xnode didn't do what was supposed to do?
xnode owner can change mind. xnode can suffer Windows crash. xnode can suffer power failure. xnode can suffer network interruption. if any one of this happen, coins are gone, belongs to xnode. Truth or FUD? Say. Chaeplin, thanks for your ongoing work on XC. However you appear to not be aware of some crucial details of how xnodes will work. I posted the following on the official thread: ATCsecure shall we discuss how Gmaxwell's post might apply to XC? I imagine it'd be a matter of whether the multi-path paradigm can be implemented without a dynamic trust system, while still preserving XC's ability to avoid blockchain bloat.
Multi-path has incredible possibilities; how about removing/reducing the need for trust with the following (which in all likelihood you've thought of already):
- your specification includes that each xnode only passes on fragments of transactions; this means each fragment will be a small (non-risky) amount.
- what if xnodes have to compete to relay a given fragment? This builds in redundancy, so that if one node attempts to steal the fragment, the others will pass it on. The fastest node gets the transaction fee.
- what if xnodes also can only pass on a single fragment at a time? This way a node would only ever have one fragment, and therefore could never amass enough money for it to be worth stealing.
- Xnodes would then compete for transaction fees by processing transactions faster than other nodes. This way the network would organically improve its capacity.
- At some cost to network speed, the protocol could also set a maximum fragment size to ensure the incentive to become a bad actor is always low regardless of the size of a given payment.
The effect of the above is that xnodes have two options:
- steal a fragment and (a) derive minimal reward, and (b) get booted off the network via the trust system
- or pass on (a) as many fragments as possible in the shortest time and (b) get multiple tiny rewards.
The second of these is prima facie preferable.
However this idea would still be vulnerable to the following attack:
- set up thousands of xnodes
- find a way to steal fragments (I understand this is only a speculative possibility and that there'll be a way of making this exceedingly difficult... however I can't think further about this without more information)
- steal thousands of fragments, delete nodes, create new ones, build up trust, steal more fragments.
I'm unsure whether this attack will be more profitable than just being an honest node; its feasibility will come down to the details. And, fortunately, you decide what the details are.
The security of the network could well depend on this balance of incentives, which is ok I suppose, but its precariousness is analogous to that of mining competition in bitcoin. A systemic solution to the problem would be preferable.
Any suggestions?
I'd like your opinion on this. Can you think of a way to make XC completely secure? ATCsecure said current design is single-path. What is the meaning of single-path ? One xnode recipient address ? If multiple recipient address is used(one xnode or multiple xnode), I can find who is sender, who is receiver. And possibility of bad actor still exist. I am waiting white paper. Yes, the current design is single-path. But I'm discussing the design as it will be when fully implemented.
Yes, single-path passes through only one xnode, if I'm not mistaken.
If a wallet sends fragments of a payment to multiple xnodes, which are all sending fragments to thousands of wallets, I do not think you will be able to find the receiver. But you are welcome to prove that you can.
Useless, thousands multiplied tx fee. Have to limit. Tx is written to blockchain. Have you heard dust threshold ? You said thousands of wallets, payment to payee should be consolidated. Payee will not tolerate with that. My scenario above implies that a bad actor will have insufficient incentive. This is arguably ok.
I am also awaiting the white paper.
Transaction fees will remain the same if they are a percentage of the amount transferred. However the fees would need to be sufficient to justify the expense of running a node, therefore the code would have to be very fast. Yes, transactions will be written to the blockchain. Bigger transactions will probably be split into more fragments; therefore more blockchain bloat for bigger payments. But the blockchain will still be prunable, and transaction size is much smaller than zerocoin. So XC is still a promising design. I meant thousands of wallets other than the recipient's wallet. Yes I know about the dust threshold. It's important to prevent blockchain bloat. I imagine XC will have a dust threshold. |
Co-Founder, the Blocknet
|
|
|
|
chaeplin
|
|
June 06, 2014, 01:07:55 PM
Last edit: June 06, 2014, 01:20:01 PM by chaeplin |
|
Transaction fees will remain the same if they are a percentage of the amount transferred.
However the fees would need to be sufficient to justify the expense of running a node, therefore the code would have to be very fast.
Yes, transactions will be written to the blockchain. Bigger transactions will probably be split into more fragments; therefore more blockchain bloat for bigger payments. But the blockchain will still be prunable, and transaction size is much smaller than zerocoin. So XC is still a promising design.
I meant thousands of wallets other than the recipient's wallet.
Yes I know about the dust threshold. It's important to prevent blockchain bloat. I imagine XC will have a dust threshold.
Nope. It doesn't work like that. Each tx should pay tx fee. tx fee is not related to xnode fee. There are two type of fees. 1) Transaction fees 2) Xnode fee https://github.com/atcsecure/X11COIN/blob/master/src/main.h#L32-L41static const unsigned int MAX_BLOCK_SIZE = 1000000;
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const unsigned int MAX_ORPHAN_TRANSACTIONS = MAX_BLOCK_SIZE/100;
static const unsigned int MAX_INV_SZ = 30000;
static const int64 MIN_TX_FEE = .00001 * COIN;
static const int64 MIN_RELAY_TX_FEE = .00001 * COIN;
static const int64 MAX_MONEY = 60000000 * COIN;
static const int64 MAX_MONEY2 = 60000000 * COIN; // 60 mil
static const int64 MAX_MINT_PROOF_OF_STAKE = 0.0333 * COIN; // 3.33% annual interest
|
|
|
|
|
synechist
Legendary
Offline
Activity: 1190
Merit: 1000
To commodify ethicality is to ethicise the market
|
|
June 06, 2014, 01:10:54 PM |
|
doesn't the network have to agree on what was the initial transaction? Therefore knowing that a bad xnode didn't do what was supposed to do?
xnode owner can change mind. xnode can suffer Windows crash. xnode can suffer power failure. xnode can suffer network interruption. if any one of this happen, coins are gone, belongs to xnode. Truth or FUD? Say. Chaeplin, thanks for your ongoing work on XC. However you appear to not be aware of some crucial details of how xnodes will work. I posted the following on the official thread: ATCsecure shall we discuss how Gmaxwell's post might apply to XC? I imagine it'd be a matter of whether the multi-path paradigm can be implemented without a dynamic trust system, while still preserving XC's ability to avoid blockchain bloat.
Multi-path has incredible possibilities; how about removing/reducing the need for trust with the following (which in all likelihood you've thought of already):
- your specification includes that each xnode only passes on fragments of transactions; this means each fragment will be a small (non-risky) amount.
- what if xnodes have to compete to relay a given fragment? This builds in redundancy, so that if one node attempts to steal the fragment, the others will pass it on. The fastest node gets the transaction fee.
- what if xnodes also can only pass on a single fragment at a time? This way a node would only ever have one fragment, and therefore could never amass enough money for it to be worth stealing.
- Xnodes would then compete for transaction fees by processing transactions faster than other nodes. This way the network would organically improve its capacity.
- At some cost to network speed, the protocol could also set a maximum fragment size to ensure the incentive to become a bad actor is always low regardless of the size of a given payment.
The effect of the above is that xnodes have two options:
- steal a fragment and (a) derive minimal reward, and (b) get booted off the network via the trust system
- or pass on (a) as many fragments as possible in the shortest time and (b) get multiple tiny rewards.
The second of these is prima facie preferable.
However this idea would still be vulnerable to the following attack:
- set up thousands of xnodes
- find a way to steal fragments (I understand this is only a speculative possibility and that there'll be a way of making this exceedingly difficult... however I can't think further about this without more information)
- steal thousands of fragments, delete nodes, create new ones, build up trust, steal more fragments.
I'm unsure whether this attack will be more profitable than just being an honest node; its feasibility will come down to the details. And, fortunately, you decide what the details are.
The security of the network could well depend on this balance of incentives, which is ok I suppose, but its precariousness is analogous to that of mining competition in bitcoin. A systemic solution to the problem would be preferable.
Any suggestions?
I'd like your opinion on this. Can you think of a way to make XC completely secure? ATCsecure said current design is single-path. What is the meaning of single-path ? One xnode recipient address ? If multiple recipient address is used(one xnode or multiple xnode), I can find who is sender, who is receiver. And possibility of bad actor still exist. I am waiting white paper. Yes, the current design is single-path. But I'm discussing the design as it will be when fully implemented.
Yes, single-path passes through only one xnode, if I'm not mistaken.
If a wallet sends fragments of a payment to multiple xnodes, which are all sending fragments to thousands of wallets, I do not think you will be able to find the receiver. But you are welcome to prove that you can.
Useless, thousands multiplied tx fee. Have to limit. Tx is written to blockchain. Have you heard dust threshold ? You said thousands of wallets, payment to payee should be consolidated. Payee will not tolerate with that. My scenario above implies that a bad actor will have insufficient incentive. This is arguably ok.
I am also awaiting the white paper.
Transaction fees will remain the same if they are a percentage of the amount transferred. However the fees would need to be sufficient to justify the expense of running a node, therefore the code would have to be very fast. Yes, transactions will be written to the blockchain. Bigger transactions will probably be split into more fragments; therefore more blockchain bloat for bigger payments. But the blockchain will still be prunable, and transaction size is much smaller than zerocoin. So XC is still a promising design. I meant thousands of wallets other than the recipient's wallet. Yes I know about the dust threshold. It's important to prevent blockchain bloat. I imagine XC will have a dust threshold. Nope. It don't work like that. Each tx should pay tx fee. tx fee is not related to xnode fee. There are two type of fees. 1) Transaction fees 2) Xnode fee https://github.com/atcsecure/X11COIN/blob/master/src/main.h#L32-L41static const unsigned int MAX_BLOCK_SIZE = 1000000;
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
static const unsigned int MAX_ORPHAN_TRANSACTIONS = MAX_BLOCK_SIZE/100;
static const unsigned int MAX_INV_SZ = 30000;
static const int64 MIN_TX_FEE = .00001 * COIN;
static const int64 MIN_RELAY_TX_FEE = .00001 * COIN;
static const int64 MAX_MONEY = 60000000 * COIN;
static const int64 MAX_MONEY2 = 60000000 * COIN; // 60 mil
static const int64 MAX_MINT_PROOF_OF_STAKE = 0.0333 * COIN; // 3.33% annual interest
Yes you are correct about this. But I am not talking about the current code. I'm talking about the final implementation. There will be changes. To get back to where I started, I asked you if you can think of ways to make XC work perfectly. Can you think of a way to resolve XC's challenges here? |
Co-Founder, the Blocknet
|
|
|
|
chaeplin
|
|
June 06, 2014, 01:13:36 PM |
|
Yes you are correct about this. But I am not talking about the current code. I'm talking about the final implementation. There will be changes.
To get back to where I started, I asked you if you can think of ways to make XC work perfectly. Can you think of a way to resolve XC's challenges here?
Conceal sender : can Xnode : can't Please read this : https://en.bitcoin.it/wiki/Transaction_feesJust numbers are different. A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).
Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.
|
|
|
|
|
synechist
Legendary
Offline
Activity: 1190
Merit: 1000
To commodify ethicality is to ethicise the market
|
|
June 06, 2014, 01:24:07 PM |
|
Yes you are correct about this. But I am not talking about the current code. I'm talking about the final implementation. There will be changes.
To get back to where I started, I asked you if you can think of ways to make XC work perfectly. Can you think of a way to resolve XC's challenges here?
Conceal sender : can Xnode : can't Please read this : https://en.bitcoin.it/wiki/Transaction_feesJust numbers are different. A transaction may be safely sent without fees if these conditions are met:
It is smaller than 1,000 bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)
Otherwise, the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes[1]. As an example, a fee of 0.1 mBTC (0.0001 BTC) would be added to a 746 byte transaction, and a fee of 0.2 mBTC (0.0002 BTC) would be added to a 1001 byte transaction. Users may increase the default 0.0001 BTC/kB fee setting, but cannot control transaction fees for each transaction. Bitcoin-Qt does prompt the user to accept the fee before the transaction is sent (they may cancel the transaction if they are not willing to pay the fee).
Note that a typical transaction is 500 bytes, so the typical transaction fee for low-priority transactions is 0.1 mBTC (0.0001 BTC), regardless of the number of bitcoins sent.
Thanks. Interesting. How would you conceal the sender? |
Co-Founder, the Blocknet
|
|
|
|
chaeplin
|
|
June 07, 2014, 02:43:30 AM
Last edit: June 07, 2014, 02:59:36 AM by chaeplin |
|
https://bitcointalk.org/index.php?topic=618377.0http://cryptco.org/Cryptcoin-CryptCast-Anonymous-Whitepaper.pdfCrypt. Here is catch. 1) Is encrypted msg written to blockchain ? probably not. ==> need to be online both. 2) Mixer without real payee. Xnode announce itself to network, Crypt do reversal. Crypt payer announce to payee, where coins to go ? O ho... Hello.
I was invited to check the implementation of XC compared to FedoraCoin's codebase in order to find possible similarities between them.
First of all, I visited FedoraCoin's repository and checked the specific file mentioned (mixerann.cpp and the header file).
Then, I was invited to Developer's station with a Teamviewer session and saw the code that implements the specific feature.
The code is in no way similar between the two coins.
But, I believe that one must trusts his own eyes (and compiler). Just download the source code from FedoraCoin and create a working wallet that has all the features of XC enabled. That would prove whether the claim is correct or false.
Now, I do not know who claimed that Fedora and XC share the same codebase. If someone claims that some principles are the same, then I'm afraid that someone hasn't heard of Bitcoin and the blockchain concept (or the transaction concept, or the pubkey->wallet address concept, or... the list goes on forever).
Hi everyone. This is my first post in here (actually I should never really have to post  ) but I feel obligated to do so, in order to make some clarifications First of all, excuse my English, as it is not my native. The pdf document that has been published, is just a rough draft to describe the process in a very simple manner so everyone can understand. It was not originally meant to be a "Whitepaper". It is not a protocol description, nor the logic flaw of the application fully detailed. As it has already been mentioned, it is work in progress. For those who are familiar with developing cycles, when a product is designed and hits the development department, the final product from the original design many times have lots of differences. And that's to overcome original design flaws, dead ends in the logic or other problems that are part of the development process and needs to be addressed, so that final product meets original specifications. Saying that, I welcome the comments made to that draft and most of them are valid points and have already been acknowledged and has being or will be addressed. Remember, it's still work in progress. If I may comment regarding the best way to do things (for example hard-to-trace transactions), I do not believe that there is an objective "best" way to do it. If there are more than one ways, there will be preference according to specific needs. Every solution will have pros and cons. Some are affected more and others less. It all depends and it's a matter of which solutions works best for each individual. I respect everyone's work and I am not afraid to admit that I am trying to learn from other ideas and extend them. Isn't that the purpose of open source projects? I do not believe into "I know it all" people and I never said I am one. Nor any of the team members, from my interaction with them. Mistakes will be made and be corrected as fast as they are spotted. So it's good to have more eyes to spot them for me and let me know of any error or flaw in my implementation. It speeds things up and also helps me learn more. So, I always believed that a mixture of ideas can get the best possible result, as long as there's cooperation and good will. That's how this team works and I really believe that we will give the best possible results on each development cycle and on each version release. From my reading of the whitepaper, it appears the recipient wallet must be online (i.e. running the wallet software) in order to receive coins anonymously. If so, this isn't a workable anonymity solution. Can the dev please clarify?
In order for the transaction to take place, in this initial draft, the wallet has to come online and give "directions" to the sender regarding the destination addresses. The "trigger message" will be valid for some time before it times out. I am testing various scenarios on how to make it work with the best possible (to my knowledge) way. Now, whether it's workable or not, I guess one must weight the pros and cons. As another developer said (and he's right all the way): there are no true passwords, nor true encryption. Everything can be broken with enough computational power. So I make myself this question: who do I trust to deliver my coins? As I said previously, it's a matter of preference. Also, I'm sure that more ideas will come from this, as there's always room for improvement to every design
|
|
|
|
|
|
chaeplin
|
|
June 07, 2014, 03:34:05 AM |
|
Update - I just ran a TX through the mixer http://cryptexplorer.com/address/XDNHMSD2Feex8bDHz9yiLtadHz4LGABQWEthe only thing I'm looking for now is proof of direct link from the source wallet address to the destination wallet on block chain Since this is single path at this time (not multi-path) that is the only concern with this release, is there a DIRECT LINK.. thanks, ATCSECURE Didn't we already prove that? Nobody was able to provide a direct link last time either. I was told that there was a lot confusion around this, so I did another test with a minor update to the code. but as REV2 is a priority w/ multi-path, I can't spend time on an issue that isn't an issue.. !_=XMHmvtXiJKG9aa7WcxBLQMcD3pYQ4wK6Ye=_! |
|
|
|
|
|
|
|
chaeplin
|
|
June 07, 2014, 03:52:00 AM |
|
~~~
Random FUD
The problems addressed in this were handled hundreds of pages ago. Darksend isn't finished yet and was never promised to be 100% anonymous unless you use great care. Plus RC4 will have great improvements to the anonymity offered. |
|
|
|
|
|
chaeplin
|
|
June 09, 2014, 04:47:06 AM |
|
i have more than 10 other wallets and none require me to add .conf file.
XC is the first ever coin to require this and it will never work to the mass. it used to work before, no need .conf
Seriously? This is so trivial. This coin is breaking restraint from DRK FUD and moving forward with something great and you are complaining about a fucking .conf file? Instead, you need bat.  |
|
|
|
|
|
|
|
ballzdeep
|
|
June 09, 2014, 04:14:46 PM |
|
Guess this turned into DRK people bashing XC uncensored, haha such a bunch of sad jokers...
Go play in your coinjoin thread and f*** urself !
|
Join the revolution - XC - Decentralized Trustless Multi-Node Private Transactions
|
|
|
|
phosphorush
|
|
June 09, 2014, 05:28:55 PM |
|
If XC was dead there would be no need for these DRK FUDers to be always here... You wouldn't need to kill what is already dead. So the conclusion I must take is that they see XC as strong competition  |
Your account locked, please contact support.
|
|
|
|
JakeThePanda
|
|
June 09, 2014, 06:24:12 PM |
|
You're making yourself and DRK look pathetic at this point. |
|
|
|
|
|
chaeplin
|
|
June 10, 2014, 12:23:01 AM |
|
You're making yourself and DRK look pathetic at this point. Well, txs to XM9Bt9j46JUZ9JMGNVfg7R6mvMePJhMpNs should send to real payee. You can't read block explorer. If this txs was fee, I will stop to posting here. |
|
|
|
|
|
chaeplin
|
|
June 10, 2014, 01:22:07 PM
Last edit: June 10, 2014, 02:30:17 PM by chaeplin |
|
|
|
|
|
|
|
520Bit
|
|
June 10, 2014, 02:54:18 PM |
|
No, the sender address is not correct. |
|
|
|
|
|
chaeplin
|
|
June 10, 2014, 02:56:51 PM |
|
No, the sender address is not correct. Well follow link. XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da == XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC == XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da You sent 0.1 to yourself, isn't ? do validateaddress XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC |
|
|
|
|
dadon
Legendary
Offline
Activity: 1190
Merit: 1002
Pecvniate obedivnt omnia.
|
|
June 10, 2014, 02:57:16 PM |
|
No, the sender address is not correct. lol...bet all u drk boys are shaking in your boots now, well even more then u already were, pretty obvious, you feel very threatened by XC..don't blame you really, if i held drk still, i would too... |
|
|
|
|
|
520Bit
|
|
June 10, 2014, 03:00:39 PM |
|
No, the sender address is not correct. Well follow link. XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da == XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC == XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da You sent 0.1 to yourself, isn't ? do validateaddress XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC No, none of them (XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da == XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC == XBPMEncv8HzCqvjxdF6SbbfpvB4pTC24Da) are the sender address. I can provide the transaction ID to prove if necessary. BTW, XQK2mnjgVxjhcBc5TocS23srVZ3TzddDeC is NOT my address. |
|
|
|
|
|
