The OP is specifically interested in encoding transactions, and those (otherwise useful) pages can't do that. 'createrawtransaction' does but it doesn't accept setting the nlocktime. @OP: anyway, according to the wiki nlocktime is always the last item in the transaction, ie the last four bytes. You'll see that your raw transaction ends with 4 zero bytes. Play with them until you achieve your desired nlocktime. Beware, it's a little endian integer: 01000000 => 1: block 1
0a000000 => 10: block 10
ff000000 => 255: block 255
00010000 => 256: block 256
00020000 => 512: block 512
00100000 => 4096: block 4096
00000001 => 16777216: block 16777216
ff64cd1d => 499999999: block 499999999
0065cd1d => 500000000: Nov 5 1985 00:53:20 UTC, note it isn't a block number anymore!
805ac352 => 1388534400: Jan 1 2014 00:00:00 UTC So if you have this transaction: 01000000010fff030dfce93c3e4457af8ad0cd47c184a9671db28cb3cb1188b4366ce5906800000000473045022100a4b143ff81dd6ab899aef5234a02054354de8a309eff811d654cd21d6e0b536102207100585568dafba3663720a710aa0cafed27e2379292c246cf0b3cb5b21b3579ffffffff01905f0100000000001976a91428d4cb88f005376046ab1fca64ae9c8a4bcfc73a88ac00000000 which decodes to: {
"lock_time":0,
"inputs":[ blah blah ],
"vout_sz":1,
"hash":"72d9c8951e543ce7a370aec3c3007e8f4e6e3d244a770631ae55a23b00457be4",
"vin_sz":1,
"out":[ blah blah ],
"size":156,
"version":1
}and change the last 4 bytes: 01000000010fff030dfce93c3e4457af8ad0cd47c184a9671db28cb3cb1188b4366ce5906800000000473045022100a4b143ff81dd6ab899aef5234a02054354de8a309eff811d654cd21d6e0b536102207100585568dafba3663720a710aa0cafed27e2379292c246cf0b3cb5b21b3579ffffffff01905f0100000000001976a91428d4cb88f005376046ab1fca64ae9c8a4bcfc73a88ac1b787352 you obtain an identical transaction except for the nlocktime (and the hash of course) {
"lock_time":1383299099,
"inputs":[ blah blah ],
"vout_sz":1,
"hash":"ace99d8d6301982e7978997a7c47f8807314eaaca5c3f7b03576b2d036faed2c",
"vin_sz":1,
"out":[ blah blah ],
"size":156,
"version":1
}That value corresponds to Nov 1 2013 09:44:59 UTC (ie right now). great, thanks for the detailed answer! I think should be able to do this now. |
|
|
|
|
re offchain/onchain:
an advantage of onchain games (not mentioned in the OP) is that they are "more provably fair."
An offchain site could just change your balance to any amount. Then you could go
complain on the forums, but it'd be your reputation against theirs. Can't do it with onchain.
but on the otherhand after gambling onchain anyone whom you send your coins
will see that you are a gambler. Unless you launder your coins of course.
|
|
|
|
|
alright, how do I find nlocktime in the hex?
|
|
|
|
you can use bitcoin-qt without the blockchain (just with the wallet.da) to create transactions. Use createrawtransaction for this. Then you can broadcast the transaction using for example http://blockchain.info/pushtx |
|
|
|
can anyone explain me how to make an Nlocktime transaction?
As far as I know you have to createrawtransaction, then edit the raw hexadecimal by hand  . When edited, issue a decoderawtransaction to check that everything's ok, then finally sendrawtransaction. hm. is there at least a tool to convert a raw transaction to a readable form _and back_? |
|
|
|
|
hi,
can anyone explain me how to make an Nlocktime transaction?
I just want to send all my funds to myself to be spendable in a year or so.
Since it's "all my funds" I want to make sure it's safe.
also, will the current version of multibit and bitcoin-qt handle correclty a
already spendable transacion which had an non-0 nlocktime?
thanks
PS Why do I want to do this - to block myself from gambling
|
|
|
|
|
hi all
do you know of any way to reach the btc24 guys?
I want them just to update my account balance
so once (or if) they do get the money they can send me the right amount.
(It incorrectly shows as processed a wire that never came through)
Using the "contact" form and emailing gives no response
|
|
|
|
I really don't understand how this "5x rollover" works.
I won more than 10 on 2 promo and some deposit, still can't withdraw.
can you check my account and say what's wrong with it? account name tun
Hi, You played a lot of No Zero. No Zero doesn't count since it has no house edge. You will need to play some other games in order to clear the requirement. I see, thanks. Now the withdrawl is actually processed and shows as "completed" but there's no transaction on the network. I suppose I just have to wait, right? |
|
|
|
|
I really don't understand how this "5x rollover" works.
I won more than 10 on 2 promo and some deposit, still can't withdraw.
can you check my account and say what's wrong with it? account name
|
|
|
|
Attention Posters: I only have a few more credits to give out to players, so make the feedback good! I'll be back in about 8 hours to credit the remaining accounts. Nice games. I like the "expected return" tab, makes it look fair and transparent,
but I'd like more explanation of what goes on with jack pot.
ALso, I'd recommend getting rid of the referral program: I think I'm not
the only one who detests these.
I kinda like the design but it has some definite 90's flavour to it, which
may not be to everyone's liking.
1PLkKs9XDpvHAMKYH1M5tG4nbH2YfG5psU
Credited. Good eye, we definitely are going after the 80's and 90's vibe of classic machines. We have a soft spot in our heart for dive bar gambling. oops. I think I lost my "account." I thought the browser would remember me through a coockie, and didn't do anything to check it actually did. Oh well. Nevermind, I guess there's nothing that can be done about it. This happens sometimes with new players because our account system can be confusing. I'll use your deposit address to find your account and PM you the address. oh I see. I guess that can work. Thanks |
|
|
|
Attention Posters: I only have a few more credits to give out to players, so make the feedback good! I'll be back in about 8 hours to credit the remaining accounts. Nice games. I like the "expected return" tab, makes it look fair and transparent,
but I'd like more explanation of what goes on with jack pot.
ALso, I'd recommend getting rid of the referral program: I think I'm not
the only one who detests these.
I kinda like the design but it has some definite 90's flavour to it, which
may not be to everyone's liking.
1PLkKs9XDpvHAMKYH1M5tG4nbH2YfG5psU
Credited. Good eye, we definitely are going after the 80's and 90's vibe of classic machines. We have a soft spot in our heart for dive bar gambling. oops. I think I lost my "account." I thought the browser would remember me through a coockie, and didn't do anything to check it actually did. Oh well. Nevermind, I guess there's nothing that can be done about it. |
|
|
|
|
Nice games. I like the "expected return" tab, makes it look fair and transparent,
but I'd like more explanation of what goes on with jack pot.
ALso, I'd recommend getting rid of the referral program: I think I'm not
the only one who detests these.
I kinda like the design but it has some definite 90's flavour to it, which
may not be to everyone's liking.
1PLkKs9XDpvHAMKYH1M5tG4nbH2YfG5psU
|
|
|
|
|
here's a suggestion of how to drastically remove the need of trust for online (collective) wallets.
Why:
Online collective wallets have the following advantages:
- mixing of users' coins
- free or cheap transactions between users, including
- microtransactions,
- off-chain (i.e., not polluting the bitcoin blockchain)
- ease of use
But they have the following big problem:
* You need to trust the operator not to run away with your coins or to get hacked.
The following simple idea can remedy the latter drawback:
Instead of one server handling the user coins, several (say, n) online wallets pool together,
and every withdrawal has to be approved by m out of n of them.
In a bit more detail:
each user is identified by a public key, to which the private key is kept only in his
browser. The public key is sent to n servers.
Every server keeps the ledger of all transactions of each user.
The user may chose one of the online wallets as his primary wallet; this wallet
will provide all the user interface to him, and will take any charges that are applicable.
Any operation the user wants to make is signed with his private key.
The signed request is sent to all the participating servers.
Deposit address for each user are "m of n" addresses.
So each withdrawal has to be signed by m of n servers.
The charges a users' primary server wants to apply follow the same process:
if they are internal, all servers put it in their books. If they are external (withdrawals)
m of n servers must sign the transaction. If the rules for the charges are agreed upon
in advance, keeping the books is straightforward.
Shall the user's primary server go offline/get hacked etc., he can still request
to withdraw his funds from the remaining servers, and they can process it (as long
as the number of online/not compromised servers is <= m)
From simple online wallets/mixers this can be potentially extended
to more advanced services such as banks, casinos, etc. with the same idea:
all participating servers keep the book for all users; withdrawals are m of n.
|
|
|
|
I will do it only if someone is actually interested in implementing it.
That's not how it works, usually. You implement and if people find it interesting, they might use it. that's just one way of making things work. |
|
|
|
hi all, I think I have a solution to the following two problems with current provably fair gambling sites: 1) in off-chain sites, the site can cheat the user trivially in such a way that the user will know immediately he'd been cheated, but will not be able to prove it to third parties. (e.g., the site can just update the balance arbitrarily or pretend the user had bet on a different outcome) ( see this thread, full of flame and troll) 2) For those sites that attract investors for a share of profit/loss (such as just-dice), there is currently no way to prove to the investors that the site is fair; for example, the site owner could play anonimously and win arbitrary large amounts (damaging investors). The solution would require third parties to run an auditing service online. Of course they will not be able to manipulate the game, only to verify fairness. I imagine different gambling sites running an auditing service for each other, or large investors running such a service themselves. The cryptography of the proposed solution is quite different from what is currently used; instead of hashing it would be based on signatures. Since writing up the complete proposal takes considerable time, I will do it only if someone is actually interested in implementing it. COding this will require substantially more work than for any of the current solutions; in particular, user-side JS cryptographic signatures (kind of like on blockchain.info) will have to be implemented. Please let me know here or by PM if you are interested. |
|
|
|
huge flame, but the simple observation I made is largerly missed.
There's a difference between "you know when you've been cheated" and
"when you'be been cheated, you can prove it."
Unfortunately, the off-chain "provably fair" casions provide only the first
type of guarantee, whereas the on-chain ones provide the second type.
I don't think one needs the bitcoin blockchain to solve the problem, but
the current algorithms in off-chain casions do not provide a solution.
There's no need to complicate the situation. Whenever you make a deposit at any place (this goes way beyond off the chain games), that place is able to do anything with that. The only reason such thing does not happen is because there is no interest in doing so. You can sign messages, broadcasts them, and so on, but since you made a deposit then it's just a matter of trusting the place. it doesn't *have* to be this way. for example, in satoshi dice and the rest of them on-chain gambling places, there's no need for trust You must be missing something then. Consider an on the chain game X, and make a deposit to place a bet. If the bet amount is above Y, then you never hear about X again. How can that not require trust ? The transaction is recorded in the blockchain, but that doesn't mean you can't be scammed. yes, you can be scammed on-chain but everybody will know about it, not just you. Everybody will see that there's no return transaction, so you can prove you've been cheated. That's the main difference. |
|
|
|
huge flame, but the simple observation I made is largerly missed.
There's a difference between "you know when you've been cheated" and
"when you'be been cheated, you can prove it."
Unfortunately, the off-chain "provably fair" casions provide only the first
type of guarantee, whereas the on-chain ones provide the second type.
I don't think one needs the bitcoin blockchain to solve the problem, but
the current algorithms in off-chain casions do not provide a solution.
There's no need to complicate the situation. Whenever you make a deposit at any place (this goes way beyond off the chain games), that place is able to do anything with that. The only reason such thing does not happen is because there is no interest in doing so. You can sign messages, broadcasts them, and so on, but since you made a deposit then it's just a matter of trusting the place. it doesn't *have* to be this way. for example, in satoshi dice and the rest of them on-chain gambling places, there's no need for trust |
|
|
|
|
huge flame, but the simple observation I made is largerly missed.
There's a difference between "you know when you've been cheated" and
"when you'be been cheated, you can prove it."
Unfortunately, the off-chain "provably fair" casions provide only the first
type of guarantee, whereas the on-chain ones provide the second type.
I don't think one needs the bitcoin blockchain to solve the problem, but
the current algorithms in off-chain casions do not provide a solution.
|
|
|
|
|
Show Posts
