961500+ entries in 0.683s
dub: don't forget
the $1000 ripples
Bugpowdr: "At
this point, bitcoins could go
to $0 without any regrets" I seriously doubt
that
this statement is
true.
jurov: doing
things over ssh = not working? strange
deadweasel: i'm closing
this ssh session.
these people want
to offer me a permament position, I should pretend
to work
the last 10 minutes i'm here.
kakobrekla: all good, been a long day which is just about
to start really
DeadWeasel: fucking jobs and
the money
they pay me.
mod6: 7.62x39
to
the ball bag != good day
swhitt: I bet BFL won't ship until
the end of march
gribble: BTCUSD
ticker | Best bid: 30.96001, Best ask: 30.99000, Bid-ask spread: 0.02999, Last
trade: 30.88007, 24 hour volume: 42692.62675683, 24 hour low: 30.11000, 24 hour high: 31.69900, 24 hour vwap: 30.92679
jurov: how likely is
the diff
to go up by 50% around March 14?
jurov: i decided
to dampen
things in coinbr by asking monthly fee... after several months i can say i did it right
jurov: whatever. i'm used
to doing
things in
this fashion.
jurov: even if i paint him in rosy colors,
then
they come around
trilema blog and MPOE-PR haha
jurov: can't expect any investor in
this situation "okay, now
tell me more about
this mircea popescu" lol
jurov: bootstrapping it completely, has
to do
things as lean as possible
jurov: i prefer
to have frontend and backed physically separated
topace: and
they're locked in my own cage at
the data center
jurov: i don't have
to
trust
the filthy bitvps machine,
that's all
topace: heh you must not
trust your own security
then :p
jurov: so
that neither coinbr's core addy gets known nor successful attack of frontend enable attacker
to push stuff onto his account
jurov: and accepting incoming
transfers likewise on other direction
jurov: and
then in separate step move it out
jurov: maybe i'll have
to use extra account for
that, move
the user's stuff
there
jurov: but
the
thought of supporting automatic
transfers
to anywhere makes my hair stand up
jurov: if
there's only one fixed address involved it's doable
topace: i like residual income, not income i have
to work for!
topace: and im always in favour of automating
things
topace: the 'automatic' is going
to have a final approval button for me
to click for
the first little while
jurov: if
there's a know proprietor, ofc
pigeons: you'll have
to sue
the proprieotr in his own court if you make an error
jurov: not easy
to fix afterwards, you know
jurov: but i'm very wary of any automatic moving of stuff
to/from mpex
jurov: anyway i did it only once so far... with your offering
this may get requested more and be
the impetus do do it better
topace: well, let me get automatic mpex<-->havelock setup first,
then lets
talk about setting up coinbr<-->havelock :)
topace: do users get
the receipt?
jurov: coinbr does push completely manually, i can give you
the receipt if needed
topace: if coinbr gives you PUSH receipts from mpex,
then it would work
topace: not sure about integrating with coinbr, anything is possible
though
topace: ^
there, i actually LOST bitcoins doing
that arbigrage, just
to move another 5000 shares
to havelock
ThickAsThieves: would
this be something
that could be integrated with coinbr
topace: yea, im amazed at
the demand for sdice on havelock
ThickAsThieves: several us have had urges
to cream into your bids for sdice in recent weeks
topace: but im not here 24/7, and often when
the good arbitrage opportunities come up, you have
to act quickly
topace: yea.. i'd do
that for havelock users
too, if im around
topace: or, had someone with an mpex account willing
to purchase/push on you rbehalf (others here have made
that offer
to people before i've seen)
ThickAsThieves: but
this would only be for people who have an mpex account right
topace: instead of having
to manually process push requests
topace: thus, why i want
to setup
this automatic push system
topace: but
the more liquid
the better, so if its easier for others
to do
the arbitrage as well, im all for
that
topace: just
to get more units onto havelock
topace: i move
things at break-even often, so no profit from
the arbitrage at all
topace: ThickAsThieves: i dont mind hogging all
the arbitrage at all, but its kind of a conflict of interest since i run
the site... if my goal is simply arbitrage at least... which it hasnt been since we launched.. my goal has been
to grow
the sdice holdings on havelock, and
the only way
to do
that is
to buy on mpex and sell
the units on havelcok, so
the arbitrage is a added side-benifit
to me.
topace: and we allow users
to push existing holdings from mpex
to havelock, or from havelock back
to mpex
topace: ThickAsThieves: yea havelock launched
teh SDICE passthru beginning of January
ThickAsThieves: why wouldn't you just hog all
the arbitrage if you have
the ability?
ThickAsThieves: but
to be fair, I didn't know anyone did it
til Deadterra
mod6: ALL YOUR BASE ARE BELONG
TO US
mod6: topace: yeah, seems like it would be some good arbitrage oppertunities -- im sure with
this automated demand would pick up over
time.
topace: but for
the naysayers
that
think im "hogging all
the arbitrage" as i add more units
to havelock.. it'll satisfy
them at least (give
them
the opportunity
to do
the same arbitrage)
topace: not sure how much demand
there would be... its possible now, for free, just manaually processed, and nobody has
taken advantage of it yet
mod6: this seems like it could work pretty good with some
testing
topace: its just checking
the values from
the returned array (esp
the "validity" field)
that i need
to be 100% sure about
topace: unless
the function itself completely fails for some reason
mod6: If verification fails,
the gnupg_verify() returns
the key's id instead of fingerprint . It does not return FALSE as stated above (PHP4, have not
tested PHP5). You can compare it with result of keyinfo:
mod6: i'd be nice
to know what {1,2,3,4...} are for! lol
mod6: back
to
the first statement: On success,
this function returns information about
the signature. On failure,
this function returns FALSE.
mod6: its shitty when neat-o libraries don't define
their return statements, nor can
they be correlated
to a given spec.
mod6: yeah it seems like it could work out decent. doing it manually in
tandom for a while would be good
to ensure
that
the correct values get
to
the correct accounts, etc.
topace: but from my understanding, it should work just fine, i ran it by mp
too and he seemed
to
think it should work well
topace: when i launch it, it'll go
through a manual approval step for
the first little while, just
to make sure :)
mod6: yeah, seems like if you could know for certain about 1-6 it could work pretty good. could reek havoc
though if
there was any problems.
topace: as long as one can
trust and properly interpret
the result from gnupg_verify()
mod6: yeah,
this could get hairy dude.
topace: //6
that
the quantity if what was pushed is ok
topace: //5
that we recognize what was pushed
topace: //4
that its a push receipt
to havelock account
topace: //3
that its a receipt we have not processed already
topace: //2
that its actually from mpex (fingerprint?)
mod6: ok... so with
the receipt you just parse
that on
the remote end and use
that
to verify.
topace: then paste
the push receipt into
the havelock website, which would verify 6
things:
topace: yes, you would push it from your mpex account
to
the havelock mpex account
mod6: i would
think
that i'd have
to be different
to discern who person A is on
the remote system and just dump
the 1 XYZ in
there, while keeping
the 1 XYZ in holdings on MPEx
mod6: i don't know how one does
that. In my mind, person A owns 1 share of XYZ and he can push
to another key on
the MPEx keyring (weather it exists on
the keyring or not) ... but how does one push
this
to a remote keyring?
mod6: i remember you saying
this before.
topace: im making a way
to automatically push assets from MPEX
to Havelock, simply by pasting in a PUSH receipt
topace: thats what i'd like
to really be sure of.. not really something i can ASSUME