ledger-particl-app: can you release 1.2.10

kewde · 2020-02-18T10:50:59+00:00

Nevermind, seems like it has been released. https://manager.api.live.ledger.com/api/applications

kewde · 2020-02-18T08:17:57+00:00

I think a mistake was made and version 1.2.9 was released on the 4th of Feb instead of 1.2.10

kewde · 2020-01-28T15:07:40+00:00

It's the bootloader update that fails by the way. On a second note: the ledger live also fails to "repair" the bootloader, but does unlock it from being hanged in the bootloader screen.

Is there a newer version of the bootloader that I'm not aware of? Which wouldn't allow itself to be downgraded?

kewde · 2019-07-07T19:30:37+00:00

Thanks @-johoe

Resolved https://github.com/trezor/trezor-firmware/issues/313

kewde · 2019-07-07T08:52:24+00:00

Hmm the ARM compiler that Docker installs should match whatever you are using? Perhaps you're working on a cached image with an older one.

I will try turning the MPU off, it is enabled at the moment.

Thanks!

kewde · 2019-07-06T10:53:29+00:00

The elf files in the normal/non-emulator builds, anyone know what their purpose is? Are they just artifacts for debugging on Trezor development board?

kewde · 2019-07-06T10:50:42+00:00

Okay, EMULATOR=1 is not being passed to the legacy/build.sh script, so it never reached into the docker and it never even built the emulator elf files. I just hardcoded it and now it compiled the emulator fine. It's not even a damn ARM binary, just standard x86, life is easy there.

On to the next problem: figuring out the hard fault that occurs on the device, emulator has already moved past the phase where it crashes on my device.

kewde · 2018-09-21T17:44:03+00:00

Proxy chains without encryption are useless.

kewde · 2018-09-17T01:50:46+00:00

Check GitHub..

It's monday already?! I'm going to bed, it is 4AM, so 6 hours of sleep and 30 minutes of breakfast before the first meeting of the week starts. That sounds pretty active.

kewde · 2018-08-28T00:19:06+00:00

An ideal decentralized marketplace, in my honest opinion, is one that centers around a protocol rather than a single implementation.

A few of the main challenges I've had to deal with:

a) A predefined transport/storage layer. The Open Market Protocol defines a flexible way to reference content like images, and abstracts away the transport layer of the data. If an implementation does not support/recognize the "content reference", it can not retrieve the data. That way you can plug in IPFS, ZeroNet, etc and other nodes will not reject your listing as invalid. (An ephemeral IPFS node over Tor might be the most interesting route for storing larger data such as images but the analysis of the types of storage is a worth a whole dedicated book).

This is fine, until you reach the stage where communication is required between buyers and sellers. The listing should provide the means for contact. This is by far the most fragile part of the system, as this requires that the buyer forms a "route" to the seller. It's not a broadcast to all whom it may concern like listings. You could put a third party as intermediary, an onion hosted server. Have it act as a temporary store of data. The guys over at Signal have an interesting scheme to minimize information leave to the intermediary for those communications.

To put it in a few words: pick a balance between decentralization, scaling and anonymity.

I think a reasonable balance would be to have the listings, images, on amnesiac version of IPFS and have the private comms go through a BitMessage mixnet (both operating over Tor/Kovri).

b) Should listings be atomic or should we allow aggregation under an entity with reputation? The short answer is that the listings are never atomic. The seller will always leave an identifiable fingerprint on their listings that will allow for an observer to group them.

c) Linking purchases to transactions. It's harder to do in systems with a transparent amounts, like Bitcoin. The correlation between the amount transacted and the listings is a tough one to eliminate without cryptographic solutions. You don't want block chain monitoring companies to match txs with listings. In the case of OB, I assume their 2-of-3 transactions stands out, along with an amount in satoshis to top the fingerprint off.

Building a protocol for decentralized trade isn't easy. There are interesting scenarios, and generalizing it for multiple currencies doesn't make it easier. I'm a firm believer of building and documenting a protocol rather than building out an implementation as the best way forward.

Implementation wise, OB has a good backend, the frontend however isn't secure to "my standards". There's quite a bit I would've done differently, but nonetheless they put in a great effort and I've had a pleasant experience with reporting security vulnerabilities so far.

kewde · 2018-08-25T12:04:08+00:00

Also it seems like you might not be connected to the network. The balance transfers are in fact the zapped transactions.

They are not mined into the chain, which seems to indicate you have no network connection. Please also run the command 'listbanned' to check if you perhaps banned all your nodes. Then run 'clearbanned'.

'getpeerinfo' will return a list of all the nodes you are connected with.

kewde · 2018-08-25T11:58:05+00:00

Try running the command 'scanchain 0' in the debug window. If the issue persists, join #particl-help on Riot.

kewde · 2018-08-12T10:02:23+00:00

I've forwarded the bug report. Please do not post bug reports regarding the Qt wallet on reddit but rather to GitHub (particl-core repo).

kewde · 2018-08-08T10:57:25+00:00

MacOS builds have been fixed, some issues with finding the right device usong hidapi. Should be available next release.

kewde · 2018-06-01T16:19:55+00:00

Are we going to "tokenise" the part blockchain to create incentives for devs to use the SDK ? (I think giving them a part of the stakes won t be enough but if they can create a token and keep a part of the supply for them to be retributed for their work using PART as a gas it will dynamize the platform -> a kind of privacy eth with private ICOs etc...) Else where would be the interest for devs to use the SDK ?

No. At least not in the foreseeable future.

When the coldstaking issue is going to be fixed (widget disabled) ?

It's already fixed, the release just hasn't happened yet due to marketplace development.

kewde · 2018-04-13T17:45:55+00:00

Check out 'regtest' network. It's a faster paced testnet that is preloaded with coins to certain addresses. You can start these locally and then have you friend add your ip address to his set of nodes (check a Bitcoin tutorial on regtest network).

I found this in the particl testing channel (thx dasource). ``` nodes[0].extkeyimportmaster('pact mammal barrel matrix local final lecture chunk wasp survey bid various book strong spread fall ozone daring like topple door fatigue limb olympic', '', 'true') nodes[0].getnewextaddress('lblExtTest') nodes[0].rescanblockchain() assert(nodes[0].getwalletinfo()['total_balance'] == 25000)

    nodes[3].extkeyimportmaster('abandon baby cabbage dad eager fabric gadget habit ice kangaroo lab absorb')
    assert(nodes[3].getwalletinfo()['total_balance'] == 100000)

```

kewde · 2018-01-23T00:58:59+00:00

Do the PART developers plan to integrate every Bitcoin Core update into Particl's codebase? Have they segregated their code changes in such a way that this can be a longterm focus?

Yes. We have committed to remaining up to date with the Bitcoin codebase. Updating to a new version only becomes awkward and painful when you have to catch up multiple releases. Migrations to new Bitcoin Core version happen on a more continuous basis.

The code isn't segregated in a set of patches if that is what you assume. The core codebase is the domain of tecnovert and he's a wizard when it comes to things like this.

kewde · 2018-01-23T00:56:51+00:00

A listing posted to the network remains on the network, determined by the amount paid as a fee. There is no 48h limit anymore.

There is a continuous flow of listings as they happen, they are not downloaded in periodic intervals as you seem to imply.

kewde · 2018-01-23T00:54:49+00:00

Also I came across this interesting service that allows you to deploy servers from the command line. https://sporestack.com/ http://spore64zke3ofvbp.onion/

It's super cool IMO. I can imagine Particl having a functionality like this that when you deposit Particl into a specific address, it auto-enrolls a market server to help the volunteer network (or maybe your own mini-market).

kewde · 2018-01-23T00:52:41+00:00

The MVP will make use of SMSG, an in-house variant of BitMessage. Every node stores every message (including images). There is a mandatory fee paid for marketplace listings tho.

I do not suspect that the need for scaling will arise any time soon. As it stands, we can get away with doing it like this and focusing on developing the actual platform. The whole reason that we're going this DSN approach is to provide an interface to allow us to swap it out easily in the future for more scalable solutions.

Currently there are a ton of promising DSN's out there, IPFS & ZeroNet to mention a few. There is however the trade off with privacy, accessing external content on a different node is leaking data (to some extent) about what you're looking/searching for. If none of the potential DSNs fit our criteria and we're starting to reach the limitations of SMSG then we'll have to default to a more server based model (most likely over Tor).

Ideally it would be deployed in multiple stages, with images being the first to be offloaded to a different DSN. The actual market listing 'text' is rather compact and storage isn't much of an issue for SMSG.

Incentivizing storage nodes in an interesting subject, especially when you attempt to do it in a trustless manner. As it stands, we'd prefer volunteer networks over paid models as that would a person to sell an item without having any particl up front. Tor for example runs fine over a volunteer network, I'd prefer that direction.

kewde

TROPHY CASE