Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 479. (Read 1276928 times)

I reindexed using the qt wallet and not the daemon, the reindex and sync information can be seen at all times on the status bar.

Think he lost his way

I think its a terrible idea. Two wrongs don't make a right.

This will also encourage hackers to loot what they want knowing that the breach will be filled from thin air by the protocol. It diminishes the value of the protocol and undermines consumer confidence.

We must also wait for the busoni to report back what the hacker has in mind before we formulate the best way forward. If he does not return the BTC, short of raising funds for the Poloniex loss there is nothing else we can do. The bounty people planned for the "benevolent" hacker must go to Poloniex even though it may not fully mitigate Busoni's loss.

Hi wtf is this please?

How willi know re index done

You also need the unspent txouts to be in the appropriate addresses to match the XCP don't you?
The way to go would be a shuffle function, or a configurable min. dust amount that the wallet will keep in each address containing an Counterparty asset.

Both are sufficiently well explained here

http://counterpartyd-build.readthedocs.org/en/latest/SettingUpBitcoind.html

http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

may be it look like a good choice.

Last Price:
0.00000006
 
24 Hour High:
0.00000007
 
24 Hour Low:
0.00000003
 
Trade Volume:
81.675 BTC

Give me an example of both the bitcoin.conf and counterpartyd.conf

This process would be so much easier with a super clear for dummies step by step explanation,  one I'd love to do when this finally all clicks. I figured by now someone would have helped for a donation.

Since this was a bug in the protocol that could have affected anyone, it does not seem fair that Poloniex or its users should take the hit.

Since we are still in "Alpha", why not release a new version of the protocol, that issues another 35K XCP as the solution?

It would essentially be a 1% tax on everyone who holds XCP, through inflation. It seems like a small price to pay for finding out about this huge, show stopping bug (that could have gone unnoticed & exploited for months!)

Sweep functionality is implemented within Counterwallet. Currently it is untested, but it's there (will be doing basic testing of it later this week). With the feature you can sweep BTC, XCP, or any Counterparty asset type. The only hiccup is that for instance to sweep 8 different kinds of assets, the address you are sweeping from will need 8 unspent txouts existing for it (each with at least 1 confirmation... the wallet will detect if you don't have this at the time and will show an error, however). That, or if you only have 1 unspent txout for instance, you can always sweep one asset at a time, and just wait for the txn to confirm before sweeping the next.

Message signing was implemented today as well.

I think this is very much doable and fairly quickly. Given yesterday's security scare, the only problem implementing this at an early stage is if there are any exploits where a node loses some of the XBTC it holds then its a much bigger trouble than yesterday. I can imagine Poloniex trouble would have been of a much higher magnitude if it was not the only exchange in town. If the hacker had deposited XCP in another exchange the problem would have been 10 times bigger. In this scenario the XBTC can be encashed for BTC in any of the nodes. This is not to say that there are more security exploits, merely to suggest that perhaps we must wait for the system to mature and move out of alpha before we implement something like this.

If implemented correctly there would be no single point of failure. Trades wouldn't be as instant as a central exchange but that's the only downside.

1. The web wallet may not have an import but xnova talked about adding a sweeping functionality. This means with your existing private keys XCP can be transferred to an address created by your web wallet. From there on you can consolidate if you like.
2. I had an unusual problem reindexing too, I did it twice and each time after closing and opening qt wallet it prompted that an reindex is required. I deleted my blockchain and restored an older copy, made double sure my bitcoin.conf was correct, reindexed again and everything was fine. Since then I have decided to backup my blockchain at least once a month.
3. I wouln't remote session with anyone I didn't actually know, especially if I had 15 addresses with 1000+ XCP each in them.

Warning - Wall of text ahead

I'd be happy to take this to the official forum...

I headed off to bed and found I came to a similar conclusion. I think it's completely do-able and awesome. I've expanded what you have said into greater detail and some implementation details. There are some limitations that I can think of. I'd be happy to hear comments and how to get around the limitations.

Let's say that each node will be sent a small amount of XBTC by the issuer of XBTC when they start up. Lets say 10 XBTC to begin with (and 0 BTC). Maybe more if the person running the node is well known. The reason to not distribute all 21M XBTC immediately is that the DAC would start with a smaller number of nodes. It would be rather difficult to redistribute the XBTC in an easy way.

For simplicity, the node should run with a new Bitcoin wallet and a single receive address. This address is the payment address for XBTC to receive BTC. It is the same address to send BTC to receive XBTC. The node will listen simultaneously on the Counterpartyd API and Bitcoin API.

The exchange rate is not precisely 1:1 to incentivize operators of nodes to continue to operate or at least recover operating costs.

A customer of the node who wishes to exchange 1.0001 XBTC to 1 BTC:
* Sends 1 XBTC to the receive address of the node. The node will respond by sending 1 BTC to the source address of the Counterparty send.

A customer of the node who wishes to exchange 1.0001 BTC to XBTC:
* Sends 1 BTC to the receive address of the node. The node will wait for a defined number of confirmations and and respond by sending 1 XBTC to the source address of the send. Here's where the some restrictions like as with the Counterparty white paper must be enforced. ie the Bitcoin transaction must have 1 input to ensure no ambiguity of who should be credited with the XBTC.

"Every Counterparty transaction must, moreover, have a unique and unambiguous source address: all of the inputs to a Bitcoin transaction which contains a Counterparty transaction must be the same—the unique source of the funds in the Bitcoin transaction is the source of the Counterparty transaction within."

BTC sent to a node which does not fit within this requirement would be considered ambigious and returned to one of the input addresses of the transaction. Such malformed requests can be limited by having an interface like Counterpartyd which ensures transactions are crafted in the correct manner.

when a node first starts up with a balance of 10 XBTC and 0 BTC, it cannot 'dispense' any BTC. A similar situation may occur during a 'bank run' if many customers are sending XBTC to the same node. The node may fill as much as the order as possible. All unfilled portions of XBTC or BTC are returned to the source address.

Nodes can be uniquely identified by their address. The node can be completely audited by comparison to XCP database and the Bitcoin blockchain. In fact, it would be possible for an independent web site like blockscan or the web wallet to display the 'health' of the DAC and each node. ie perform an audit of each node and ensure that balances and prices are not tampered with.

There is still the risk that an operator of a node could run with the balances. Since BTC is a separate block chain and payments irrevokable, we'd have to live with that.

I think the above is deterministic and possible to implement.

Also, I've been thinking of something that might be nice. Say we could use the Counterparty 'broadcast' for a moment:

Nodes advertise their balances over the Counterparty protocol via 'broadcasts'

Based upon the node's parameters, the node may wish to seek to replenish its balances of XBTC or BTC from other nodes in the DAC. It can use the broadcasts to locate other nodes in the DAC. They can then send an order to purchase the asset they wish to replenish. The thing to be careful is that one node attempting to buy from another node may cause a knock on effect of causing other nodes to be depleted of resources. The broadcasts could also be used by the aforementioned audit page of the health of the DAC.

halfcab123: I Don't Know What The Rush Is To Consolidate The Addresses. Especially With The Amount You Had Burned.. Or IDK. The Counterwallet Should Maybe Have Ability To Sweep The Balance Or Something Xnova Mentioned This On The Counterparty Forum

but the order of the transactions can be different per miner... so its dependent on which miner solves the block?

Can anyone help me understand the reindex thing ? No matter who I ask or what I read it's not working and I burned 15 bitcoin so I'm trying to figure out how to consolidate this and get in a position where I can send and receive as needed ... why is this so difficult for me ? I'm even a developer. Have tried re indexing 5 times over a period of 2 weeks. Counterparty commands throw all kinds of errors idk man I've tried everything and ... now I'm even more discouraged than before because I hear that the Web wallet will not have the ability to import private key -_____- is there really no one willing to help for a donation ? :/

Can I maybe get someone to do a remote session to help me set up all the prereq and then that way all I have to do is import my keys and I'm good to go. I'm desperate at this point. -___-

Can Someone not Host The Block Chain So I can Download It Maybe Or Something .... Would That Work ?

There's no such thing as 'at the same time' in the blockchain: two transactions in the same block are handled in order of appearance within the block.

Trade Volume:
65.979 BTC