ore-cli
ore-cli copied to clipboard
many and varied send_and_confirm experiments (NO MERGE EXPECTED)
Experiment that introduces tpu_client.send_and_confirm_messages_with_spinner. Also uses one and only one rpc_client and a connection_cache.
The UX looks like this now:
Searching for valid hash...
1112i44tLJehFB15XVzJpEsdQAKvv5snM1Z7fL9JrnxA
Submitting hash for validation...
"Sim failed"
"Sim failed"
Blockhash expired. 4 retries remaining
Blockhash expired. 3 retries remaining
Blockhash expired. 2 retries remaining
Blockhash expired. 1 retries remaining
Blockhash expired. 0 retries remaining
thread 'main' panicked at src/send_and_confirm.rs:129:11:
send and confirm to win: Custom("Max retries exceeded")
stack backtrace:
[redacted]
ore-cli: working hard. solano: hardly working.
$ cargo run -q --release -- --rpc $RPC --keypair $KEYPAIR claim
Blockhash expired. 4 retries remaining
Blockhash expired. 3 retries remaining
Blockhash expired. 2 retries remaining
Claimed 0.007172972 ORE to account 5TGRXSB6nKq8vreVdwQTjM4DWdxLf9iMdZAL7nwV8Hon
5xN4J3kn6PfbASrvyJb5UseozAH7tEsx8ocLZfKQJyRQaHby8nnfeW5k2R1yr87VjxPi95an1AneviigtLraFnMC
Interesting approach. Have this crate also: solana-quic-client
Seems like contains the udp client and the cache too, would be better to use to have 1 new dependency instead of 2? Not sure make much sense. All these solana crates and when to use which is very confusing anyway.
Edit: I've tested this implementation and even its more elegant way, in my example felt like less tx going trough than with the orginal spam it until make ut approach. But the less failed also saved on fees. But generally couldn't achieve to more valid tx go trough.
I tried to run the 6a8f117e97cfcd6b5932608aac66e803174a09ec version for 1 hour. It passed 10 tx successfully for me, 25 sent errored out. Always instruction 3 failed. So the performance kinda close to the orginal client now, that was able to pass trough 15-16 tx in one hour period.
I tried to run the 6a8f117 version for 1 hour. It passed 10 tx successfully for me, 25 sent errored out. Always instruction 3 failed. So the performance kinda close to the orginal client now, that was able to pass trough 15-16 tx in one hour period.
Good to know. And so I'm clear, "instruction 3 failed" was a transaction that got include in a block?
Good to know. And so I'm clear, "instruction 3 failed" was a transaction that got include in a block?
Yes Solscan wrote me Program Error: "Instruction #3 Failed" and also
Program ComputeBudget111111111111111111111111111111 invoke [1]
Program ComputeBudget111111111111111111111111111111 success
Program ComputeBudget111111111111111111111111111111 invoke [1]
Program ComputeBudget111111111111111111111111111111 success
Program mineRHF5r6S7HyD9SppBfVMXMavDkJsxwGesEvxZr2A invoke [1]
Program mineRHF5r6S7HyD9SppBfVMXMavDkJsxwGesEvxZr2A consumed 1899 of 2900 compute units
Program mineRHF5r6S7HyD9SppBfVMXMavDkJsxwGesEvxZr2A failed: custom program error: 0x5
I should note that I haven't paid much attention to maintaining the original programs correctness. eg: I ripped out simulation because I wanted to focus on landing transactions. It's possible this version burns gas where the prior version didn't for eg.
I should note that I haven't paid much attention to maintaining the original programs correctness. eg: I ripped out simulation because I wanted to focus on landing transactions. It's possible this version burns gas where the prior version didn't for eg.
Ahhh the orginal also posted more failed tx than successful. So the behavior kinda same in that manner.
Hello, when I use this fork to mine, sometimes it will lead
thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-quic-client-1.18.5/src/nonblocking/quic_client.rs:111:14:
QuicLazyInitializedEndpoint::create_endpoint bind_in_range: Custom { kind: Other, error: "No available UDP ports in (8000, 10000)" }
hwo to fix this?
Hello, when I use this fork to mine, sometimes it will lead
thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-quic-client-1.18.5/src/nonblocking/quic_client.rs:111:14: QuicLazyInitializedEndpoint::create_endpoint bind_in_range: Custom { kind: Other, error: "No available UDP ports in (8000, 10000)" }
hwo to fix this?
you're probably, actually, running out of UDP ports. are you running multiple instances of the program on the same machine at the same time? each one is using up ports.
Hello, when I use this fork to mine, sometimes it will lead
thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/solana-quic-client-1.18.5/src/nonblocking/quic_client.rs:111:14: QuicLazyInitializedEndpoint::create_endpoint bind_in_range: Custom { kind: Other, error: "No available UDP ports in (8000, 10000)" }
hwo to fix this?
you're probably, actually, running out of UDP ports. are you running multiple instances of the program on the same machine at the same time? each one is using up ports.
yep, but i only run 10 instances on the same machine at same time? I think the program should not use so many port?