|
Any input's nSequence that is less than MAX_INT - 2 is sufficient to mark the entire transaction as replaceable.
|
|
|
|
|
MAX_INT (0xFFFFFFFF) indicates a transaction is final, which means that that transaction is a normal transaction. MAX_INT - 1 (0xFFFFFFFE) signals that that transaction is not final and that the transaction can have a locktime. The locktime prevents the transaction from confirming until a specific time or block height. It also indicates that if there is an OP_CLTV in an input script that that script can be evaluated. However it does not signal Opt-in RBF. Anything less than MAX_INT -2 (0xFFFFFFFD) signals that the transaction can be replaced in the mempool (opt-in RBF) and if it has a locktime, that locktime should be evaluated.
|
|
|
|
The best would be to use bitcoind over RPC. You can also use Electrum over RPC
BitcoinJ is fully functional but it only works with using it as part of a program.
Awesome! if I could just use bitcoind rcp that would be amazing!  Can you refer me some resource to look at to get started using bitcoind for micro transactions ? Cheers, Satinder Check out the RPC calls at https://bitcoin.org/en/developer-reference#rpcs. What you want is probably the sendmany command. |
|
|
|
If you're looking for a safe, big transaction escrow Mitchell is the guy , a relatively small but quick escrow ~$100 I'd go for Sebastian and for the safest escrow I'd go for shorena.
Hey! Don't be advertising for others in my thread  @OP there's much competetion already for offering such a high fee
Yeah, I know, but there have been a few escrows who have stopped escrowing so I thought I would come fill in a gap and help escrow stuff. Also, my fees are negotiable (I will add that to the OP) and I can usually be talked into lowering my fees significantly. |
|
|
|
|
The best would be to use bitcoind over RPC. You can also use Electrum over RPC
BitcoinJ is fully functional but it only works with using it as part of a program.
|
|
|
|
Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.
Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.
IIRC RBF is only missing the actual mempool replacement stuff and the ability to create RBF transactions. RBF transactions aren't flagged in the main ledger nor the tx info dialog. No detection of RBF inheritence either. Hm. I thought my PR flagged RBF transactions in the tx info dialog. |
|
|
|
i think it's no but the question is :
it's possible to prune the new blockchain in core 0.12 to work with armory?
thanks
No. Armory reads the block files in order to work and if you prune, then the block files are removed. |
|
|
|
OK, well I don't claim to be a Bitcoin expert, I only came upon Bitcoin in Late 2013.
My understanding comes from what I have read previously.
Maybe the bitcoin wiki page should be made more clear then.
To me, it seems to use the term "double spend" incorrectly at times when trying to define it.
It makes it seem Bitcoin "prevents" double spending, when according to the new definition,
Bitcoin actually allows "double spending", but only one spend will be prevented from being confirmed.
Is there a place online where a glossary of official terms for Bitcoin is available?
Like what a "spend" is actually defined as.
Edit: fixed typo and added the word "official terms"
Here is a glossary: https://bitcoin.org/en/developer-glossary. It defines a double spend as A transaction that spends the same input as spent in another transaction.
|
|
|
|
Added a couple changes. Maybe that will fix the 0.11.x -> 0.12 swapping.
Going over the RBF PR, it's missing some stuff so I'll have to implement that before merging in into dev.
IIRC RBF is only missing the actual mempool replacement stuff and the ability to create RBF transactions. For the clean up ATI stuff, do you want to remove all of the phone home stuff? In my PR, I only have it commented out because you said earlier that it may be brought back in the future. |
|
|
|
In that case there will never be one, because indeed bitcoin was designed to avoid double spends like you define them. The other kind is still a thing, hence people call them "double spend" even though they are not under a stricter definition of the term. Im not entirely sure what your intention here is, but it does not help understanding the issue if you come around the corner with a different definition other than the one that is commonly accepted. OP specifically asked about unconfirmed transactions (note the "between the blocks"). The following is my understanding, the basis for my above statement, and may be incorrect. When Satoshi and other earlier designers of digital currencies worried about "double-spending" in their systems, I was under the assumption they were referring to an actual duplication of the digital currency in a standard transaction. Satoshi overcame this long lasting problem of duping in other systems, by creating the blockchain system. As a result, when an attempt at a double-spend occurs, it can't be considered a true or successful "double-spending" as before because only one of the spends will ever be valid, in the Bitcoin system. Before Bitcoin, there were two valid spends, aka a "double-spend". Prior to the blockchain, a double-spend's definition was the actual duping of the money. Now, you are saying the commonly accepted double-spend's definition seems to be only when anyone pushs the same outputs twice. According to the bitcoin wiki: https://en.bitcoin.it/wiki/Double-spendingBitcoin protects against double spending by verifying each transaction added to the block chain
to ensure that the inputs for the transaction had not previously already been spent. By the above explanation, I assumed when "Bitcoin protects against double spending" it was in regards to my definition. When the explanation uses the term "double spending", I think the context is with my definition. Either I'm very wrong or giving this too much thought. In bitcoin, it is impossible to double spend in the conventional definition of the term. However the new definition of the term in the context of bitcoin is any transaction which spends the same inputs of any transaction that has already been broadcasted. |
|
|
|
An issue switching Core client between 0.12 and 0.11.2: I'm finding that building the Armory db with 0.11.2 initially, then restarting Armory using 0.12 (with all 0.12 validated blocks) renders Armory stuck at the last block the initial build using 0.11.2 had previously reached. Doing the same test, but with 0.12 providing Armory with the initial block data to build the db recognises the latest block when restarted using 0.11.2. Had this problem with builds previous to b24dcb2 also. Not sure what happens when doing 0.12.0 > 0.11.2 > 0.12.0 etc, haven't tried that
Perhaps that has something to do with bitcoin core 0.12 obfuscating the chainstate after syncs and reindexs. See the downgrade warning in the release notes. |
|
|
|
|
Can we sell the bonus tickets we get to other members or back to Betcoin?
|
|
|
|
Thanks Knight,
I got it, I had do a little trial and error to figure out what else I needed to change. Thank You!
No problem! Why can't we just have a script to do this so we don't have to compile each change?
Because c isn't a scripting language. If you want a script, find a program in a scripting language that does this. |
|
|
|
while you can verify sigs a lot of times from the recent blocks, there are many times where you just dont know what the txid the vin refers to is, since you havent seen it yet during a parallel sync.
So you could verify a significant subset as it comes in during the first pass, but until the blockchain is fully there you cant verify all the sigs.
Are you sure that you need to know anything about the input transactions other than the txid and vout in order to verify a signature? I didn't think that was the case. I don't see any reason why you couldn't verify the signatures out of blockchain order. The sigs themselves can be verified out of order, but verifying the entire transaction cannot. The inputs of a transaction reference an output of a previous transaction and to verify that an input correctly spends the output, that output needs to be known so that its script can be combined with the input script to verify that input. |
|
|
|
Thanks for the link. Have posted there for escrow and will be hoping someone comes in here. I can provide escrow for this, although it is understandable if I am not chosen since I am new to escrowing. I charge a 1% fee. Please see my thread: https://bitcointalk.org/index.php?topic=1373968.0 |
|
|
|
Thanks, I am still missing something:
Here is the result:
WIF : KxaZ3DctC1ximsBBcQ37TcaqcRvqxyo9AkvcEpRCtc4zfnD9YXcQ
should be: 5J89cr5WGdvQWeeekN5ZGzuXVsWREbAYku6MDeUgrJTjX1ZHhCX
Your expected result is uncompressed. Uncompressed keys begin with a 5. Compressed begin with a K or L. Follow my instructions in the above post to get uncompressed keys. Also, note that most clients now use compressed keys as the public keys are smaller and thus save space. |
|
|
|
Thanks for the replies Just outa interest how would this sorta thing be done then, is it command line stuff, because a bitcoin wallet wont let you create multiple transactions for bitcoin that you don't own, Some poorly written software will allow you to double spend. Other times a person can write custom software to do double spends. You can also manually create double spends through command line stuff. Or you can trick wallets into creating double spends by making them clear the unconfirmed transactions so that it "forgot" that you already spent an input. |
|
|
|
|
So any dates more specific than q1, q2, q3, and q4? Those are pretty vague and they encompass several months. How about actual months specified like Bitcoin Core did with their roadmap (because this is pretty clear to be fighting back against the Core roadmap).
And how about making the roadmap more specific than just the "2016 roadmap"? A lot of things will happen in 2016, but this discusses specifically just scalability.
|
|
|
|
She can't 'double spend' between blocks. Technically she could but this is really hard to do as soon as the transaction has a single confirmation. Do you mean unconfirmed transactions? You should not generally accept 0-conf transactions unless the amount is negligible or you trust the other party. There are a few known types of attacks in regards to double spends. This image might also be useful for your general understanding. So if she can't double spend between blocks what is stopping her from doing that? is it the wallet that wont allow her to send more than she has? The double spends are spending inputs that are already spent. It is entirely possible for her to create 10 transactions that spend the same input and send the Bitcoin to 10 different people. However, the consensus rules allow only one of those transactions to be confirmed and thus committed to permanent history. Any transaction that spend off of the other rejected transactions would forever remain unconfirmed and thus susceptible to being impermanent. |
|
|
|
|
Show Posts
