06:42:42 utils/python-rpc has node and wallet python bindings. 11:07:45 Hi! If I have a private spend key, is it possible to read incoming transactions, or do I really need 2 pairs of keys? 11:11:06 You need the secret view key to see incoming outputs. You do not need two pairs. 11:11:49 I mean, I wonder if when I have a secret spend key, could I view both incoming and outgoing transactions? 12:13:29 is it possible to implement a currency that allows for double spending to happen, but puts the catch: if anyone discovers a double spending, then the violator is fined? 12:17:56 There's a logical problem in that, unless they stake those and intend on taking the tokens back, they can exploit that easily 12:19:48 * that easily., * So unless there's a period that the transactions don't take effect (which I guess you want this to be asynchronous and that's why you suggested that), and that means reconstructing blocks, it won't work really 12:22:57 i'm thinking of the following: introduce a mechanisms to allow 'security guarantees'. this security guarantee could be deposited long enough into the network. or, it may not be deposited in the network, but, instead, hinged on the truster's reputation. 12:22:57 * that easily., * So unless there's a period that the transactions don't take effect (which I guess you want this to be asynchronous and that's why you suggested that), and that means reconstructing blocks, it won't work really (in that way, there might be another way that would work) 12:23:01 e.g. if a wallet declared its trust on an individual for some transactions, but that individual double-spent, then that truster's reputation will be harmed. 12:23:26 "I mean, I wonder if when I..." <- You can use same secret view key view all incoming transations 12:40:36 Yes, it is possible, but you have to be careful about allowing negative balances (which typically means someone will not be able to spend all their coins, since they might be needed for a fine). 12:41:10 Alternatively, allow negative balances. But the person with one ain't likely to fund the account again. 12:51:10 the reason i like this delayed punishment approach is that it can work without being online. 13:18:16 i have a separate concern: how to make payments scalable? it is not wise to broadcast all transactions to everyone. yet, we want to eventually detect all double-spent payments. any solution without requiring confirmations as a prerequisite? 13:18:43 "Alternatively, allow negative..." <- Yea but then if they want to they'd just make another keypair 13:20:19 ghostway[m]: the new keypair may not have the reputation to let people trust them 13:22:53 Well this doesn't make sense for new users though. This might be fixed by having a small computation every time you have a new keypair, but I still feel it's not the best, but possible? 13:24:49 new users may be required to deposit a large-enough security deposit that freezes for long enough as a guarantee. this guarantee will be used to deduct from his/her double spendings. 13:44:38 But where do you get this security deposit from? It's a circular problem 13:44:57 Also: where would you deposit it? Who/what would control it? 13:45:50 Also also: spent outputs don't have a "name" associated with them; you don't actually know who spent it, you just see that it is spent 13:47:24 Any kind of active fraud detection requires a trusted intermediary who knows and sees everything, and decides "this is legitimate" or "this is fraud" 13:49:52 The question did not have "has to be anonymous" nor "has to be txo based" in its requirements. 13:50:11 True that 13:50:52 But without those requirements you just fall back into the current banking system 14:07:00 merope: money is mined/minted somewhere. a security deposit is different in that it was declared long-enough in the past so that people can a strong-enough guarantee that this deposit announcement has reached everyone. 14:07:02 so, if i want to deposit a security guarantee, in order to start paying people, i'll have to deposit the security for a long enough period, then wait for long enough until enough people hear about it. because, when i want to buy an item, the seller will require that my deposit's announcement is old enough to be known by people around the world, and the locking/freezing time to be long enough 14:07:04 into the future. 18:19:48 Hi! Is there a daemon endpoint like getblock, which would not only return a list of tx_hashes, but instead return full transaction info for each transaction too? 18:50:52 mrnaif[m] Maybe check `/get_blocks_by_height.bin` 18:51:39 (Or `/get_blocks.bin`, though the description of the input seems very confusing) 18:52:33 Alternatively, you could just take that list of tx hashes and pass it straight to `get_transactions`