Tree: 5d861a4b16

acspeed

beta

beta_season3

blackjok3r

dPoW

dPoW2

dev

etomic

fix-mm-build

fix-mnotary_arg

jl777

master

olddPoW

pass-iguana-arg

patch-1

patch-10

patch-11

patch-12

patch-13

patch-14

patch-2

patch-3

patch-4

patch-5

patch-6

patch-7

patch-8

patch-9

quote-mnotaryrun-args

release/v0.1

win-cross

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '5d861a4b16'

${ noResults }

Commit Graph

5441 Commits (5d861a4b16b7b0cad1e8fdd0082a79f4a6071c59)

Author	SHA1	Message	Date
jl777	99af2665fc	test	8 years ago
jl777	edc6851d42	test	8 years ago
jl777	47df72db0b	test	8 years ago
jl777	5fc784db5c	test	8 years ago
jl777	202abedb40	test	8 years ago
jl777	afa3b28f29	speed test	8 years ago
jl777	458173a8a6	vs compat	8 years ago
jl777	7bee16ffa8	test	8 years ago
jl777	25660ec88e	debug version	8 years ago
jl777	421314f16d	sendtoaddress fixed reworked internals for basilisk/history api by using iguana/balance api and sendtoaddress uses this data. tested finding and using utxo in completed bundles, and also in the RT bundle. Left to test are detecting a spend of RT bundle in the RT bundle. also amounts and txfees are a bit off, but basic sendtoaddress should work in all cases other than bugs left to do is to lock utxo after being used so multiple tx per block can be sent, otherwise the same utxo could be selected and that is invalid	8 years ago
jl777	834769e4ca	test	8 years ago
jl777	d011f378af	debug	8 years ago
jl777	ff090aaab1	fixes	8 years ago
jl777	f15c6881af	fixed history	8 years ago
jl777	cf67a62391	new history	8 years ago
jl777	fd1771c3f9	debug	8 years ago
jl777	e2e4caebd4	debugging	8 years ago
jl777	2151f932a2	test fix for reorg loop off-by-one	8 years ago
jl777	20be996e69	fix spurious unmappable file error	8 years ago
jl777	69b9f76760	fix for no spends in basilisk history API	8 years ago
jl777	36a31f0e0a	fix default value of is mine	8 years ago
jl777	cc0a30764c	Revert "Revert "txdetails and helper functions, proposed fix for #59"" This reverts commit 02ae9881ae.	8 years ago
jl777	02ae9881ae	Revert "txdetails and helper functions, proposed fix for #59" This reverts commit d4f19ce7eb.	8 years ago
jl777	d4f19ce7eb	txdetails and helper functions, proposed fix for #59 https://github.com/jl777/SuperNET/issues/59 required retrieving additional details from transaction info RPC. both getrawtransaction and get transaction use the same code path and list transactions also uses the get transaction path, so all paths should now have the txdetails fields: "category": "receive", "amount": 0.50000000, "confirmations": 24466, "blockhash": "00000000000000000517ce625737579f91162c46ad9eaccad0f52ca13715b156", "blocktime": 1448045745, "blockindex": 78, "label": "", the block index and label fields are currently not supported. Also since iguana has data for all addresses, not just wallet addresses and including ‘push’ addresses, the ‘category’ field has additional return possibilities: ‘isp2sh’ is returned for any ‘p2sh’ address, regardless of whether some or all of the required privkeys to spend the ‘p2sh’ address are in the wallet. to determine partial or full signature capability would require interpreting the script in place, and the returned information would need to indicate conditional states, i.e. cltv, multisig, if/else, etc. so this part is a won’t fix for non-p2sh addresses, if it is in the wallet it will return “receive” or “send” depending on whether the txid/vout outpoint has been spent or not. for addresses no in the wallet, it will return “unspent” or “spent”. Note that a locked wallet might or might not get as far as calling this txdetails, but if it did, it would return “unspent”/“spent” even for an address in the wallet as it has no way to know if it is indeed a wallet address	8 years ago
jl777	8595854a08	jsonQ separated into global and coin specific queues using a mutex to serialize all API requests causes unacceptable latency in some cases. Not serialized can lead to queries into a dataset with unstable state. To fix this, all JSON requests are split into coin specific queues whenever possible and the global queue is only used when the coin can’t be determined from the JSON request. Each coin’s main thread calls the iguana_jsonQ to process that coin’s queue of requests only after all the dataset updates are complete to assure only valid data is returned. Since any previous large latencies were when a specific coin was updating its dataset and the dataset can’t be safely accessed during that time, the delay in processing that coin’s request doesn’t create any additional latency this bug fix is in response to @pbca26 report of “iguana_pkhashbalance: unexpected non-ptr lastpt” which is an error that is most likely caused by accessing the dataset at the wrong time.	8 years ago
jl777	4dd39bcd89	test	8 years ago
jl777	ba8a9f8474	test	8 years ago
jl777	6442e379c8	test	8 years ago
jl777	fa7dec90b7	test	8 years ago
jl777	5f0ff799a5	test	8 years ago
jl777	7ab5539749	test	8 years ago
jl777	d1f670ffef	test	8 years ago
jl777	0769e75fa3	test	8 years ago
jl777	361af6eec9	test	8 years ago
jl777	d3997bf561	test	8 years ago
jl777	1803f24a08	test	8 years ago
jl777	1af3de0ec0	test	8 years ago
jl777	87a6678eda	test	8 years ago
jl777	12173a5395	test	8 years ago
jl777	e2a8388b5c	test	8 years ago
jl777	c00b7cd0de	test	8 years ago
jl777	3cc77768aa	test	8 years ago
jl777	549e5456b7	test	8 years ago
jl777	fc902306e8	test	8 years ago
jl777	0f5869e846	test	8 years ago
jl777	ff0e3fc64d	test	8 years ago
jl777	40964a8efe	test	8 years ago
jl777	816db495f6	test	8 years ago
jl777	62f1dff8e3	test	8 years ago
jl777	6b6c1d2ff4	test	8 years ago