kurumiimari / shakedex Goto Github PK

Problem: unique views-panel on shakedex showing null or empty.

— and some parts of domain info show N/A (owner, value, highest)

Would be nice for shakedex.com (and the CLI) to have a calculator to show what values the strategy will generate.

With shakedex in Bob Wallet, the app (Bob wallet) fails to start because names.json is missing in hsd's published package.

To use shakedex with Bob, it should reference the hsd's GitHub repo directly, like how Bob Wallet does now: https://github.com/kyokan/bob-wallet/blob/master/package.json#L150

If the file doesn't exist, the app doesn't open:

Module not found: Error: Can't resolve './names.json' in '/media/data/Projects/handshake/bob-wallet/node_modules/shakedex/node_modules/hsd/lib/covenants'

I know there's some progress already in deriving Shakedex keys from the BIP32 wallet in Bob or hsd, but currently we generate a raw private key, encode it as JSON and insert into levelDB. I think Shakedex should prompt user for a password and encrypt that private key.

Currently the calculation of price decrements for an auction is a bit off since the lowest price accepted is never part of the auction. I recommend following formula for deduction per step: (highest price - lowest price) / (steps - 1)

Example:
Highest price: 200
Lowest price: 20
Duration: 7 days
Steps: 7 (once per day)

Deduction = (200 - 20) / (7 - 1) = 30 => 200, 170, 140, 110, 80, 50, 20

...or updating to latest:

[email protected]

[email protected]

This is just to avoid duplicates with all their native node addons n shit when installing Bob Wallet

Actually, since we dont use semver in Bob any version you set in Shakedex will trigger a duplicate download. So I think peer dep is probably best? I don't know if matching the commit hash would work the same way:

    "hs-client": "https://github.com/handshake-org/hs-client/tarball/61aaf060a473b496b85501d795e586b9217d3306",
    "hsd": "https://github.com/handshake-org/hsd/tarball/27745128b3d8f5dd72b4cfbc933e14a1029dbe18",

Your script is actually a bit long:

... you might be able to just do:

OP_TYPE
<int transfer>
OP_EQUAL
OP_IF
  <pubkey>
  OP_CHECKSIG
OP_ELSE
  OP_TYPE
  <int finalize>
  OP_EQUAL
OP_ENDIF

I think because you are calling nodeClient.getTX() here you should enforce in the docs that the local hsd full node must be run with --index-tx.

There might be other ways to do this, for example working with the hsd wallet maybe creating a new watch-only wallet that watches the p2sh address you create. Or instead of checking the TX, you could just check for the UTXO: https://hsd-dev.org/api-docs/#get-coin-by-outpoint

$ bin/shakedex list-auctions
An error occurred. Stack trace:
TypeError: Cannot read property 'height' of null
    at NameLockTransfer.getConfirmationDetails (/Users/matthewzipkin/Desktop/work/shakedex/src/nameLock.js:42:25)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async listAuctions (/Users/matthewzipkin/Desktop/work/shakedex/src/cli/main.js:283:23)
    at async Command.<anonymous> (/Users/matthewzipkin/Desktop/work/shakedex/src/cli/main.js:66:7)

Please report this as an issue by visiting https://github.com/kurumiimari/shakedex/issues/new.

I ran through both sides of the auction process locally on regtest, I was only asked for my wallet passphrase for two steps, fulfill-auction and finalize-auction (the two buyer-side actions).

1. The CLI wouldn't accept empty passphrase (I just entered (space) and it worked -- this is an unencrypted wallet)
2. Feels like the passphrase should have been required to create the auction TXs because they are signed, why wasn't this required?

cli-table3 is backwards compatible with the unmaintained cli-table.
You can just swap it out and everything should work the same (but slightly better).

But, if you want to really impress people (AND make your work easier) check out:

@blessed/neo-blessed.

Blessed can do a lot. But the basic building blocks are even easier than cli-table.
(There's even a blessed-cli for designing the basic structure of a blessed app visually. It doesn't get much easier than that.)

But wait, there's more-- blessed-contrib

Blessed-Contrib adds:

• an easier to create and simply better table implementation
• Easy handling of streaming data visualizations
• Lots more, and all surprisingly simple to work with
  

Don't be intimidated by how fancy these animations look

Building with blessed-contrib is even easier than cli-table, while also looking great.

Edit: It's also highly performant. Looks and works just as great on the lowest of low-end hardware.
Edit 2: (It's also MIT licensed.) If you don't try it out I will probably eventually get around to making a fork. But I encourage you to give it a try, because cli-table is a pain to work with.