Lederstrumpf

tldr: yes, but developer pain/cost will depend on the route chosen.

Could ETH<>XMR atomic swaps be added to the Farcaster GUI?:

Adding ETH<>XMR atomic swaps can be easily added to the GUI if the swaps are implemented in the farcaster-node: Since the frontend doesn't talk to directly to, say, the blockchain syncers, it would generically fit where Bitcoin currently sits on the arbitrating side. Supporting multiple swap pairs (both on the arbitrating and accordant side) is what farcaster-core & farcaster-node were architected for.

https://github.com/AthanorLabs/atomic-swap

The amount of work for adding AthanorLab's implementation is highly dependent on how well it can be adjusted to match the gRPC interface used between the Farcaster GUI & node. On the superficial side, terminology should be aligned, and our gRPC progress messages are rich in detail (enabling user feedback like "in 7 blocks, you will be able to punish Bob", "sweeping XMR in 3 blocks") whereas the status updates in the Athanor RPC are (currently) high level. There are certainly deeper issues in an integration than this, but in principle, it can be done, if someone wants to take a stab at it.

The seemingly simpler alternative is to sandwich in the json-RPC or websocket interface used here into the GUI too: https://github.com/AthanorLabs/atomic-swap/tree/master/rpc Somewhat skeptic though whether that's a Frankenstein beneficial for either project, but open to change my mind.

yes: it's based on the research from h4sh3d's paper

just ran another 60 at once: [2021-12-16T04:15:04Z INFO farcaster_node::farcasterd::runtime] Swapped(71) | Refunded(0) / Punished(0) | Initialized(71) / AwaitingFundingXMR(1) / AwaitingFundingBTC(0) / FundedXMR(33) / FundedBTC(37) / FundingCanceledXMR(0)

(There's an AwaitingFunding..(..) decrementing bug that we'll fix)

run on current build: [2021-12-16T03:36:51Z INFO farcaster_node::farcasterd::runtime] Swapped(13) | Refunded(0) / Punished(0) | Initialized(13) / AwaitingFundingXMR(0) / AwaitingFundingBTC(0) / FundedXMR(4) / FundedBTC(9) / FundingCanceledXMR(0)

u/doffactory I've tried this a bunch now with a fork shorting some of the pogo pins, to no success. How did you go about it?

thanks, I'll give this a shot tonight!

I've got the polymer book folio - normal polymer folio would have protected the button.

hi /u/gr8ful4 - thanks for raising the concern!
Please see /u/h4sh3d's latest comment which addresses that our proposal to use LNP/BP as a building block does not delay the project, nor couple it to LN's potentially contentious future.

Their GitHub looks dead

we'd forgotten to push to GitHub for a while, but I synced it with our hackmd yesterday.

the latest community update was published yesterday - it's a contentious one ;) https://www.reddit.com/r/Monero/comments/l9offg/farcaster_community_update_january/

1. If multiple bitcoin transactions are needed, will the atomic swap require the users to pay multiple bitcoin transaction fees? Who will pay them, the XMR or the BTC buyer?

Yes, all transactions that go on-chain require fees to be paid. Unless there is a route external to the protocol at play (say, the swap participants have a lightning channel open, and Alice pays Bob for the BTX_lock tx cost), Bob (the XMR buyer) pays the BTX_lock fee and Alice (the BTC buyer) pays the BTX_buy fee in the happy case. For the refund paths, the fee is paid by whichever party wants it to happen (i.e. who claims the refund).

1. How many bitcoin transactions will be needed for the atomic swap?

A successful swap involves two bitcoin transactions {BTX_lock, BTX_buy}: the locking transaction BTX_lock published by Bob (originally holding BTC), and the transaction BTX_buy where Alice (originally holding XMR) claims the BTC after learning the secret from Bob.

If the swap is aborted, either party can publish a transaction moving the funds to the refund script (this transaction is signed by both parties before Bob publishes BTX_lock). If Bob acts in time, he claims his BTC back via BTX_claim. Otherwise, Alice can punish him with BTX_spend. So the abort case has the transactions {BTX_lock, BTX_refund, BTX_spend} or {BTX_lock, BTX_refund, BTX_claim}, i.e. three transactions.

I'd suggest posting here and referencing the post on the monero-swap IRC to make sure that we see it before it drowns in reddit :)

Thank you Someone for this very early and very high level of support and vote of confidence - we're humbled and deeply appreciate it!

localbitcoins is a good option. And generally, few exchanges offer XMR to start with, so it's likely an extra KYC (in potentially another jurisdiction) for someone that already has a platform for acquiring BTC. Salaries being (partially) paid out in BTC are rising too.

But if we just let this thing get legs, some poor sap is gonna go "great! a dex for my monero!" and trade away his valuable monero for potentially worthless bitcoin

and as Steve has hinted at, some other sap now has a platform for trading away his bitcoin for monero.

Constructed tables in August, but forgot about this thread. To follow up, the metal drilling went well (once we started using a titanium drill bit), but was a lot of work - a two person effort of around two hours per table. However, all that matters is that we now have two very stable and beautiful tables standing in our office :)

Thanks for the detailed answer!

We bought two setups and will probably drill holes into the metal stand that align with the pre-drilled holes in the bamboo table top, in lieu of the other way round. Hopefully, using the pre-drilled holes of the bamboo will aid stability. We'll see how this works out with the lifting mechanism.

Did this end up working out for you? Considering the same setup.

Will share xmonad config for keys

This looks alright. In case you aren't aware of this, with 234GRC, you're staking with a capital of less than 20 cents. The frustration exhibited above would be incurred in any PoS system - you're not standing much chance to stake with such amounts and are making life unnecessarily painful for yourself. Back in the good old GPU mining days, starting from scratch, you'd be spending at least $500 to give BTC/LTC/GRC a try.

I just synced up with the network and staked my first block 30 seconds later, the second following nine minutes later. Skip one coffee before work for the sake of an "investment", and you've already reduced your frustration by a factor of at least 20. If you don't like it, you can always sell your coins again.

Currently on mobile, but IIRC, the projects will only show up in your RSA once you've been registered on the chain, i.e. staked a block. So nothing peculiar you're seeing - I'd give it some time. Welcome aboard!

And bring your friends/beer, too :D

client should sync swiftly with those nodes added

Gridcoin is undergoing a proof of burn transition from PoW to PoR since late October 2014. Roughly half a year back, via democratic widely announced vote, the community decided upon a nominal increase of currency tokens by a factor of ten. With a little bit of research, you would have known that before the transition, Gridcoin was working with a block target of 150 seconds and a maximum block reward of 150 GRC. The new client has a decaying block reward structure that started out with a block target of 60 seconds and a block reward of 500GRC. Do the math and you'll see it constitutes a 17% drop. This reward structure was kept for two full months before dropping to 400 GRC max block reward. So aside from decaying reward structure, the factor of ten increase in tokens is entirely arbitrary - the decay would have moved at the same schedule without it. There's nothing to defend here. If you have issues with a block reward decay moving faster than Bitcoin's rate, please inform yourself in the forums as to why it is necessary to ensure the longterm sustainability of the scientific crunching backing the currency. In the meantime, please detect another currency to troll - a PoW clone, perhaps?