What is the ideal hardware configuration to become a B&C reputed signer?

[Nagalim]

Now that I think about it, we can just stick all the unconfirmed txns in a single block with a huge fee and use CPFP (child pays for parent) if we end up with too big a knot.

[Sentinelrv]

I just wanted to link the previous thread where some of this was discussed already, in case not everybody read it yet…

Solving Blockchain Scalability & Instant Micropayments Through B&C

Can we develope a micropayment system(escrow) after ver 5.0? We can become an important OFF CHAIN service provider for every Satoshi Blockchain tech based aaset such as BTC, ETH, etc. Make other blockchains into settlement network. IMO, the blockchain should NOT and can NOT be used as micropayment platform. Scalability is their cancer. Can B & C become Exchange, Wallet and Payment Processor simultaneously?

[Nagalim]

How about signing on top of an unconfirmed output (only where all the unconfirmed were big multisig txns) costs a higher foreign blockchain fee per unconfirmed output? This would kind of force our own personal fee market to develop for each foreign blockchain. Could be very interesting.

[dysconnect]

In an ideal world I don’t think the money should even need to be transferred before a withdrawal request.

The exchange only has to be able to bookkeep X BTC belongs to trader A, Y BTC belongs to trader B etc. and make sure the orders placed are consistent with these pieces of information. It’s probably not too hard to make sure every client can retrieve and verify this information, on top of usual blockchain indexing.

A large obstacle is that it places a lot of trust on multisig; if the multisig security fails one way or another there will be discrepancies between the book and the keep that will need to be reconciled.

[Sabreiib]

http://opentransactions.org/wiki/index.php/Triple-Signed_Receipts

The idea to use balance agreement combined with transaction numbers in order to eliminate the storage (or need) of any account history (so-called destruction of account history) is inspired by Truledger by Bill St Clair. He has mentioned discussions with Patrick Chkeroff of Loom as his muse in this area. The receipt itself becomes the “account”.

Mr. St. Clair describes his protocol in this document: Truledger in Plain English.

And @Eleven has impleted OFF CHAIN instant transaction machanism for quickwallet. Would you explain it?

[masterOfDisaster]

In an ideal world I don’t think the money should even need to be transferred before a withdrawal request.

Right!

[BETA] Shapeshift "The Safest, Fastest Asset Exchange on Earth"

I wrote that at another place already: unless you want to withdraw funds that were recently traded, I can’t see a reason that prevents recently traded funds from being used for other transactions, like trading them again, before the trade is written in a block.0-confirmation tx should be possible hwen trading (which speed up BCE by far).The necessary information stays in the mempool.It’s only the reputed signers that can mess things up (whi have strong incentives not to do it) and not the users.If anything goes pear-shaped, some trades are reverted and the users have their original funds back. Only withdrawing funds before a sufficient number of confirmations are reached, must be prevented.

I referred to this:

State of NuBits - what are the next steps?

As BCE is used as kind of "settlement network" for the trades, only the confirmation times of the BCE blockchain are limiting the speed of (verified!) transactions - unless you can even speed that up by having a system that allows off-chain trades (how to make that both fast and secure?). I think it might be possible to make 0-confirmation trades, but it will be important to care for edge cases. If withdrawing funds from an account is only possible after the trade, that brought the funds to th…

Btw. time to split the topic? This is no longer dealing with hardware, but with design and possible improvements of BCE.
It shouldn’t be burrowed in a supposedly hardware related thread.

[sigmike]

Could @sigmike tell me what kind of computation occupies the Raspberry’s CPU when minting? The SHA256?

I haven’t done any measurement but I guess it’s indeed the SHA256.

[dysconnect]

It’s essentially a centralized solution and also a rather trivial one. In blockchains you need to deal with forks, which are semantically valid records of history but only one can be chosen. Triple receipts are still a semantic thing and doesn’t help you choose between forks. If you were not talking to me, I rest my case.

[Cybnate]

My hopefully useful takeaways and considerations.

My takeaway from the hardware configuration discussion is that reliability comes over security. It is important to have those keys available for signing in time. The risk that those keys are compromised are relatively low due to multi-sig. Having a few thousand dollars worth of funds in a single-sig account on a home-pc is likely to result in a higher risk profile given the attack vectors than some multi-sig keys on a VPS. So a VPS appears ok to me.

Tor could decrease the traceability assuming the exit node is not compromised. Did someone consider Cloudflare as a way of obfuscating the IP address of the B&C signing wallet? Should be able to use port 80 for the traffic, but I haven’t tried it yet.

Re availability, I think it is important to have recent copies of blockchains readily available in case something corrupts and a time consuming resync from scratch is required. Corruption can be caused by the media or the network. I have only seen that issue by protocol updates myself but older SSD media is also vulnerable as it wears out I’ve heard from others. This might not apply to the latest generation or professional grade SSDs.

Still making up my mind which way to go. Some experimenting is likely to be required. I might just start with 2 or 3 VMs on my highly spec’ed home server as it has plenty of diskspace which comes at a relative premium on a VPS.

[Sabreiib]

Thanks! And as @masterOfDisaster said CPU occupation varies from 80-95% when Rasp minting, I believe this is single thread occupation.

Here is the SHA256 performance for Cortex A7（1.2Ghz） and Apple A9（1.85Ghz） comparison.

http://browser.primatelabs.com/geekbench3/compare/5762981?baseline=5764201

I believe single thread SHA256 comparison of 0.9Ghz Cortex A7 vs 1.85Ghz Apple A9 is around 500 vs 4000, which means a iPhone Nu app minting will lead to 10% occupation of iPhone6/6s/se’ CPU. And the data upload/download per month is around 200-300MB.

@Eleven, in your quick wallet, the instant transactions between accounts demand your server’s computation, what’s kind of it? Also SHA256? How many instant transactions per second can be performed by Intel i5/Xeon 2.4Ghz single core?

I wonder whether our B&C’s one dozen of signers can perform 50,000x per second for global customers, with i5 CPU and 10MB/s network. That is VISA/MASTER level.

Last but not least, B & C don’t need to apply a payment license, LOL.

[masterOfDisaster]

as @masterOfDisaster said CPU occupation varies from 80-95% when Rasp minting, I believe this is single thread occupation.

I reported this CPU occupation for blockchain syncing.
It’s multithreaded, because the CPU load can exceed 100%, which is only possible, if more than one CPU is used by nud.

[mhps]

Cause the 0-conf has the trusted signers, it should be just as good as a confirmed txn and users should be able to trade with the unconfirmed outputs.

That looks like a prime condition for double spending on the same address. How does subsequent B&C tx know there is enough fund on a user’s address if previous tx to the address haven’t been confirmed? The fund could be transfered away by a tx outside B&C.

[masterOfDisaster]

How does subsequent B&C tx know there is enough fund on a user’s address

Because the user’s address is in the BCE context a multisig address controlled by reputed signers?

The fund could be transfered away by a tx outside B&C.

This can only happen, if reputed signers sign that tx, right?

[mhps]

Because the user’s address is in the BCE context a multisig address controlled by reputed signers?

Wen a user place an order, the fund moves from his normal address to a signer multisig address. When the oder is filled, his counterparty’s fund moves from the signer’s address to the user’s normal counter-currency address. It’s the users normal addresses I talked about.

[masterOfDisaster]

I thought we were talking about 0-conf tx within BCE context (multisig addresses of reputed signers).
Funds that get moved from/to user’s singlesig address need to be treated differently.

[mhps]

0-conf tx within BCE context (multisig addresses of reputed signers).

I thought every trade is a pair of txs between normal-adress/signer-address? There is no fund movement within B&C i.e. not involving a normal address. no?

[masterOfDisaster]

How do you interpret the paragraph that starts at end of page 7?

Blocks%20%26%20Chains%20Decentralized%20Exchange.pdf

[cryptog]

In an ideal world I don’t think the money should even need to be transferred before a withdrawal request.

Can you clarify?

[Sabreiib]

When I run “top” command, cpu load sometimes exceeds 100%, so that’s multiple program based on single core/thread occupation load calculation.

On the right top corner of raspberry, the cpu load indicated as 27%, that’s same load, but based on multi core calculation.

4 cores’ 27% = one core’ 110%

But the Nu/B&C is mainly single thread program although occasional exceeds one core’s capability.

Last question, the more NSR I have, the more burden on my raspberry’s cpu in minting?

[Dhume]

Huh? I thought all funds at B&C would be held in multisig, the single sig addresses are only there to account for what B&C account makes which deposit right? So after the funds are deposited they are “credited” to that person’s B&C account and moved to “storage” aka multisig.

So when trading happens all funds stay within B&C multisig and don’t move at all just “messages” on the B&C blockchain as to which funds belong to which trader. How does it work otherwise? Transferring funds on their respective chains after every trade would take way too much time + tx costs.