Thanks for your replies.


I think my descriptors are precisely "hardened", ie: they have single quotes in them. Does it still mean that if I save that "listdescriptors true" output, I can always get all my coins back from it, change or not?


Do I understand correctly that the best is to use "fundrawtransaction" in between, in order to let the wallet decide on the best UTXO set to use? Might as well just make the effort and ditch "sendtoaddress" alltogether at this point.

Hi all,

So I'm reviving a paused project and it involves receiving bitcoin deposits from users, each user getting assigned a distinct deposit address.

My concern is to be able to safely backup the private keys in case the bitcoin node crashes.

A few years ago, using a vanilla BDB wallet, I implemented it by pre-generating a large list of addresses through "getnewaddress", setting like half of them to the "change" label, using "dumpprivkey" on them all, encrypting the file and saving it somewhere safe. In case of a dramatic crash, I could just import those private keys on the new server, and recover control of all UTXOs.

Enter the descriptor wallets.

While I have no doubt descriptors are vastly superior to whatever we had before (I skipped the hdseed era alltogether), there is an obvious problem - they are a lot trickier to deal with if you're not THAT well versed into bitcoin core. So after a few days of wading through docs, stackexchange, random articles here and there, I came up with a workflow and would appreciate if somebody with a clue could (in)validate it.

My concern is obviously to make sure I never lose an UTXO due to a server/disk disaster. I'll use "test" for the wallet name as I'm working with the testnet. I suppose everything should translate to mainnet seamlessly. Bitcoin core version is 28.0. For the sake of the example, let's pretend that I want to generate 10k deposit addresses.


A. GET A SET OF DESCRIPTORS

• start bitcoind
• bitcoin-cli createwallet test
• bitcoin-cli listdescriptors true
• save the JSON output of the last command somewhere safe, name it descriptors.txt. I can always spend any coin received thanks to it.

B. GENERATE ADDRESSES

• repeat 10,000 times: bitcoin-cli getnewaddress
• save the output of the last command batch - it's the deposit addresses that I can now assign to users as needed

C. DISK CRASH - I HAVE A FRESH BITCOIN CORE SERVER

• grab the descriptors.txt file
• start bitcoind
• bitcoin-cli createwallet test false true (we create an empty wallet with no descriptors)
• use bitcoin-cli importdescriptors with the contents of descriptors.txt
• repeat 10,000 times: bitcoin-cli getnewaddress (this is supposed to give us the exact same 10k addresses)
• all done!

QUESTIONS:

• Does it look reasonable?
• What about change addresses? I couldn't figure out how to deal with them. My app uses sendtoaddress at this time and I'm not planning on implementing raw transactions for a bit. I need to make sure that a deposit address is never used for sending change and also that after descriptors restoring on a new server, I properly get all change UTXOs available and visible in listunspent and whatnot. Should I also "pre-generate" change addresses?
• Is using "getnewaddress" the proper way to do it? Should I use something else, like "derivateaddresses" (but then "listreceivedbyaddress 0 true" doesn't display them)?

RHETORIC QUESTIONS:

• Why oh why is there not an option to set a change address in "sendtoaddress"? I mean, I understand the privacy concern, but it could be disabled by default, so only people who don't care about concealing the payment/change discrimination would use it, on purpose. Maybe only allow it through RPC and disallow in the GUI, etc.[/size]
• Is it me or dealing with crypto daemons only gets more complex as time passes, instead of getting simpler? Last Geth update ditching personal_ namespace commands just made stuff harder too. Sheesh.

Thanks for your comments.

Hey guys,

What do you think, if you are versed in the field, is/are the best jurisdictions for incorporating and/or hosting a new full-fledged crypto exchange (CEX) today?
There will be no service to the USA and the exchange plans on being as legit and compliant with AML/KYC and other relevant regulations as possible. Privacy of the shareholders is a major topic.

The countries of incorporation and hosting do not need to be the same. Seychelles and Cayman Islands immediately pop up into my mind but I hear good things about UAE as well. What about Singapore? Is it still a good option?

Does the hosting jurisdiction actually matter? If yes, how important of a factor is the network latency, if the chosen hosting location is relatively remote, such as the UAE or Asia?

Thank you for your input.

Thanks for your reply.

When I say X has been created before Y, it doesn't mean Y isn't created yet. It's just "younger".

I think you might have missed my actual question. In my scenario, a Limit order L1 is created and happens to match something in the order book. It could have been a Market order, doesn't really matter.

A trade happens, the mark price changes, and it triggers two SL orders (SL1 and SL2).

SL1 gets priority as it is older than SL2.
SL1 gets matched, it again happens to produce a trade, further changing the mark price.
That second mark price change triggers SL3.

Now I have SL2 and SL3 that need to be matched. My question is, which of them should be matched first?

SL3 is an older order than SL2, but SL2 has been triggered before SL3 (by the very first trade).

Obviously they don't have the same stop price (or both would have been triggered by the first trade).

So should I match SL3 first (it's older than SL2), or should I match SL2 first (it has been triggered first)?


I have a gut feeling that there's no dogmatic wisdom there and an exchange may do it one way or the other, but thought I'd ask.
Never thought writing a trading engine would be so freaking hard :p

Mods: please move it somewhere if it does not belong here. Couldn't find a better suited subforum.

I'm writing a trading engine and am right now at the point where I am implementing Stop-limit order logic.

I have a simple question:

Let L1 be a taker limit order that a customer just submitted, and it matches a maker book order.
Let SL1 and SL2 stop-limit orders with a stop price that will be triggered by the execution of L1.
Let SL3 a stop-limit order with a stop price that will be triggered by the execution of SL1

SL3 has been created BEFORE SL2.


The cascade of stop price triggering would look like that.


Question 1: Which one should be executed first, SL2 or SL3 ?  (remember, SL3 is an older order than SL2)

Question 2: If we do not take into account the date of order creation at all, should I execute vertically down first, or fill the orders horizontally first, then go down a level?

Question 3: Forget SL3. Generally speaking, how do we pick the first order to be executed between SL1 and SL2? Creation time, stop price, or a combination of both? Or some other factor?


Thanks!

Sold

Sure.

The ASIC is actually new, after verification.

No idea how much this stuff goes for these days.
Place a bid here (no PMs).
Willing to ship or hand over directly in France (Paris area).

Accepting cash (euro) or crypto.

Must not be a blower.

Accepting escrow.

Payment in cash if in France, possible to pay by wire transfer or crypto.

Perfect condition, always ran in a cool datacenter.

Located in Paris, France.  Will travel if needed, equipment can be tested before the transaction.

Price: 480 euros per ASIC + PSU set.

Looking for 500 euro per ASIC + power supply set.

Still have a few left.

I will ship international.
Price will depend on destination.

A few Z9 mini's still available.  Grab them while they are.

removed

Good work, good communication and reasonable pricing.

Will work with the OP again.

Reminder: the coin is listed and traded at STEX: https://goo.gl/mitPY2



We will fork at block 100,000 which will result in a block reward reduction to 10 coins per block.  This is done in order to combat rampant inflation and dumping.

Please update your wallet to the latest version from the Github repository - otherwise your masternodes and wallets will no longer work after block 100,000.

Download new wallet here: https://github.com/x3c/mirage/releases/tag/2.0.0

Looking to hire GOOD graphic and / or web designers.

Should be able to design original art such as logos, web elements, good looking crypto-related HTML pages.

Send PM here or (preferred) to x3coin@gmail.com

We currently have bounties for graphic and web design.  Please send PM for further information.

The coin is now called MIRAGE.  This is simply a name change (rebranding).  IT IS STILL THE SAME  COIN.  The new wallet and source code are available here: https://github.com/x3c/mirage/releases

PLEASE NOTE: the data directory changes from %appdata%\X3C to %appdata%\MIRAGE on Windows, and from ~/.X3C to ~/.MIRAGE on Linux
Please follow the following guide to migrate from the old wallet to the new one.  Remeber to make extensive backups of everything before attempting anything.   https://docs.google.com/document/d/1VSD0iIyGYy24wQYul2N8HAPnNpAL5hq8cfipMYsBW7s

STEX and other services will change the name from X3C to MIRAGE over the next few days.

New topic: https://bitcointalk.org/index.php?topic=5044673