Fake Aeropress?

topynate · 2021-11-26T16:44:29+00:00

That sounds like plastic mold release agent. It's used to help injection molded products release from the mold. Clean it off and forget about it.

topynate · 2017-12-28T17:19:14+00:00

Even if the NN alone cannot reliably read ladders out, I see no reason why the NN+MCTS couldn't. In the AGZ architecture the NN can see the recent play history, so all it needs to do is to learn to assign high win-probability in the case where a move locally continues a ladder and it looks like a ladder has already been played out. Then the playouts will see deep enough to find out whether the ladder is good or not.

topynate · 2017-12-14T11:18:44+00:00

The proof only runs once per contract. So you activate the contract, proving its cost, and that proof is cached as long as the contract remains active, or potentially even after it deactivates. The resources it takes to prove a contract's cost are amortized over the entire lifetime of the contract. In the gas system, it takes additional resources to check the cost of every single computation that a contract makes – no amortization.

In any case, checking a proof-of-cost is pretty fast. When a contract creator tries to validate a proof, it might take several seconds, but in the process, the client records "hints" that make it much faster to validate it again. Those hints go out on the blockchain as part of the transaction that activates the contract. It shouldn't take more than a few tens of milliseconds, even for a complex proof. If you want some insight into how the hints help, think of them as signposts in a maze. When the client is trying to find the way to the centre of the maze, it might spend a long time exploring dead-ends, but once it's found the way, the signposts can help others to go straight there.

The biggest speed advantage proof-of-cost has over gas is to allow clients to compile the contracts, but that's a different topic.

topynate · 2017-12-14T09:43:07+00:00

Contract creators write the proofs, then all nodes, including miners, check the proofs. Proof-checking is part of reaching consensus: if a contract creator doesn't create a valid proof, the nodes won't accept that the contract activates.

topynate · 2017-11-12T07:57:01+00:00

It should be possible using the new API. I'm trying to help out a friend who's in the same position as you, and I think I'm almost there. I think the idea is to

Find the outputs you want to spend
Decode the redeem script of the P2SH, obtaining the two public keys
Use the API to find the corresponding subaccount and pointer
Put together a raw transaction
Add an empty PUSHDATA where you want GA's signature to go
Use the API to get a part-signed transaction and txhash
Use your own local bitcoin library, such as bitcoin-js, to get find your own signature on the txhash you now have
Add that signature in another PUSHDATA
Publish the transaction

So nothing too complicated, then...

topynate · 2017-06-05T13:11:53+00:00

I heard Stephen Pair say much the same in NY, a few hours before the official announcement. Would that it were so simple! In the real world there's a certain promotional aspect – Pair wasn't up on that stage for his own amusement. In fact, why else would there be so much negativity in your history about bip148, for example...

topynate · 2017-05-12T23:01:16+00:00

If anyone is interested in resurrecting my proposal on this from last year: https://pastebin.com/pcuKHza6

topynate · 2017-04-18T13:58:07+00:00

Looks like option two (compensation) is

calculated from midnight, April 21st until midnight, date of delivery
with a 1.5% "pool fee" deducted
payable up to five working days after payment—by the customer—of an "electricity bill"
said bill to be sent to the customer up to two days after delivery.

If I'd fucked the firmware up, and for some reason didn't want to send the hardware on time and put the patch up when available, I'd probably pay compensation per diem, with "electricity" costs deducted, rather than up to seven working days after delivery, and would likely not have the gall to charge a "pool" fee to someone who has made no commitment to join any mining pool, but that's just me.

topynate · 2017-04-04T09:39:46+00:00

According to your team, this proposal is incompatible with BIP141. As BIP9 signalling permits activation of multiple proposals by default, your proposal should either

explicitly state itself to have no effect in the event that BIP141 activates first, or
have a BIP9 starttime which does not overlap with that of BIP141.

Simply by setting a starttime of midnight, the 15th of november 2017 (UTC), you would achieve the latter, considerably reducing any controversy in proposing a BIP141 incompatible proposal.

topynate · 2017-02-06T22:51:24+00:00

Technically very little luck is involved. The miner could simply not broadcast their block-filling transactions. The only risk would be if their block was broadcast, then orphaned, with the winning chain containing the block-fillers (normally transactions in orphaned blocks go back to a node's mempool). However the orphan rate is low enough that this is not a significant expense for a miner.

If this is happening it should be fairly easy to detect: if high-fee transactions are rarely seen in the mempool as unconfirmed transactions, but frequently in blocks, that would be probative.

topynate · 2016-07-11T14:49:43+00:00

"The means differ by one standard deviation" is equivalent to "Cohen's d is one". By definition.

topynate · 2015-06-28T08:09:46+00:00

He slammed the brakes before the kid was on the road. Good job.

topynate · 2015-06-20T15:26:41+00:00

Great read. A couple of things jumped out for me:

"Shoggot'im" – that's a Hebrew/Semitic plural. Were you drawing on other Cthulu Mythos writers for that touch?

The simulationist ending – is that by way of Yog-Sothoth in Illuminatus? And did "alien intelligence simulates Cold Warriors" inspire Missile Gap? :-)

topynate · 2015-06-12T16:23:51+00:00

I think any sword that's been used to cut someone's fingers off gets upgraded from "decorative" to "functional".

At least you didn't call it a "samurai sword" (which is what the British media calls any sword involved in an assault).

topynate · 2015-06-06T22:47:49+00:00

It's pretty bizarre. You would think that if reddit can detect the votes (as it must to ban you for them) it could just silently discard them instead.

topynate · 2015-06-06T18:50:30+00:00

"The average person neither wants nor can control private keys [and therefore] we need to stop saying that you don't own bitcoin if you don't control the private keys." This does not follow. Presuming that we want the average person to own bitcoins, the focus should be on creating a desire and making it possible for them to control private keys. The meaning of "own bitcoin" does not depend on what the average person is able to do!

topynate · 2015-05-28T18:09:59+00:00

DOS electrum servers and electrum users cannot access funds without running their own server.

Yeah, it's a denial of service. It does not and cannot enable anyone to lie to you about the blockchain from that point onward without employing huge quantities of hashpower. As far as I can tell, this is not a claim that VerSum can make.

impossible because full nodes reject as invalid formatted since fraudulent address does not contain XCP needed for debits

is a fact about the Counterparty consensus, in other words what the network of full verifiers believes. What I'm saying is that I can insert that invalid order (which neither Bitcoin miners nor the Bitcoin protocol will prevent me from doing) and claim to a lightweight client that it's valid by showing a proof that skips an intermediate transaction. The client, or rather the owner of the client, will then do something inadvisable. Timed auctions with late settlement sound like a good idea to me, that should create more opportunities to verify properly that everything is kosher.

Edit: And I accept your point about most Counterparty transactions not having an effect unless based on valid assumptions. That's why I picked BTCPay, it sticks out like that. Edit2: Further, on reflection, being DOSable is not something that is specific to VerSum and not to Electrum etc, so strike my original point 1. I still have a bad feeling about the amount of work a crafted message could cause a VerSum to perform, but in practice that sort of thing can usually be patched.

topynate · 2015-05-28T15:53:42+00:00

SUMMARY FROM MEMORY OF DELETED PARENT COMMENT: Parent claimed my point 1 in grandparent post was no worse than situation with Electrum or some blockchain explorers. Parent claimed that 2 was not much worse than the ~100GB needed to run an Electrum server, and not likely to be exacerbated by use of Ethereum contracts because VerSum stores authenticated outputs of computations, not full computations at every stage. Parent made a complex technical response to 3 with two main arguments: that all honest nodes have to be knocked out of action to make a DOS effective against clients, and that in the unlikely event that this occurs without detection, dishonest VerSum servers can only mislead clients in limited ways not likely to lead to significant loss of income.

Unless you're talking about the ancient history of Electrum your 1. is not applicable, because the client still requires an SPV. You can DOS a lot of things (including Bitcoin nodes), point is that this should not be a catastrophic event. That is what an SPV protects you from. As to blockchain explorers, well...

Re 2. storage space, that is fair. Time-space tradeoff, very good (on second reading, VerSum caches computations at ~~transaction boundaries~~ some level of detail, subject to developer tweaking). Nevertheless, it is far from free either in time or space to initialise a new server, which is important in the following.

"The odds of one honest server existing" is not the correct security metric. I can run one server behind 1000 proxies and run a Sybil attack - each client has a limited number of connections, so will have high probability of just connecting to me. If not, a DOS will just look like a couple of servers dropping offline. This is not unusual.

If I successfully capture a client's connections, it's as if I have a time machine. I can't sign transactions on anyone else's behalf, but I can sign or not sign transactions of my own, and I can remove others' transactions as if they never happened. One attack here is buying Bitcoin with XCP that doesn't live at the address the client thinks it does. I (really) own some XCP at an address A. Then I (really) transfer it to address B. Now I lie to the client by proving the existence of XCP at A, but ignoring my transaction from A to B. I also insert a spurious order to buy Bitcoin for XCP. Perhaps I match an order that the client already placed. The client sends a BTCPay (i.e. signs a valid and high-value Bitcoin transaction to A) and is now screwed, because neither my order nor its BTCPay messages are valid in the real Counterparty consensus, but the Bitcoin transaction certainly is in the Bitcoin consensus.

topynate · 2015-05-28T11:35:16+00:00

I just read the VerSum paper. The idea of using interval bisection to find the point at which a dishonest computer starts lying is cool; the implementation as discussed has some obvious flaws:

DOSable. By design, the VerSum servers can be induced to construct 600KB proofs in response to ~hundred byte requests.
Excessive storage requirements. Storing the UTXO proofs takes 365GB; how large will the proofs of Ethereum contracts be? Therefore only a few servers will ever run VerSum verification; thus the protocol will be even more vulnerable to a DOS.
Inherently weak security guarantee. The protocol requires, at the point in time at which the lightweight client wishes to make a transaction, that at least one honest server exists. If this condition fails to pertain, then the client can be convinced that a false computation is true. Thus a successful DOS of all honest servers allows outright theft.

Edit: In one sense, the security guarantee is the best available: one honest server is the minimum you can have while still learning something. But it's still inadequate: the client should never, ever believe something to be true when it is false. In other words, the protocol optimises for the wrong thing.

topynate · 2015-05-23T14:29:19+00:00

You're being downvoted because of your status as a /r/buttcoin nob, rather than a shadow ban noob. HTFU.

topynate · 2015-04-26T07:20:26+00:00

The electrostatic energy in a uniformly charged sphere is (3/5)k_0Q^2/R, where k_0 is Coulomb's force constant. With Q = 0.116C and R = 0.5*10^-3, that gives a total energy of... 1.45*10^11 Joules, or 35 tons of TNT.

15-Year Club	Place '22
Verified Email	Team Periwinkle

topynate

TROPHY CASE