{"id":"84855718-82de-4c3c-8888-d7ee433e2d14","arxiv_id":"1908.04613","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"A design for a permissioned blockchain tree with per-patient subchains for medical data and access logs, proposed as an eHealth audit system.","lead":"This paper proposes a blockchain tree: one main chain for patient identity, plus separate subchains for each patient's medical records and access logs. The authors claim this design makes healthcare data tamper-evident and provides a trustworthy audit trail.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Majority-rule replacement makes insider collusion a feature, not a bug: in a permissioned PoA network of hospital nodes, any coalition >51% can rewrite PHRs and logs and the remaining nodes are instructed to accept the majority version.","rationale":"I agree with the reader's REJECT verdict and its identification of the permissioned-PoA majority-collusion assumption as the weak point. My reading of the full text strengthens rather than softens the concern, because the paper's own Section II replacement rule ('automatically replaced by the right that exists on at least 51% other nodes') makes majority acceptance the definition of correctness. In a private permissioned blockchain with a fixed list of verified nodes, this means an insider coalition of just over half the hospitals can rewrite both the yellow PHR subchain and the red access-log subchain, rebuild all hashes, and have the rewritten tree adopted by the remaining nodes. The tree's cross-linking does not prevent this; it only forces the attacker to recompute more hashes, which is trivial when there is no proof-of-work and the attacker controls the validation nodes. The paper presents no adversarial model, no formal security argument, no implementation, and no evaluation, despite making categorical claims about impossibility. The stated GDPR deferral and recognition that the work is a first step support a reading of the paper as a design sketch rather than a substantiated security mechanism. Therefore the central immutability claim is not established, and the verdict REJECT remains appropriate; no change in verdict is needed.","tokens_in":11018,"tokens_out":4305,"duration_ms":44851,"concrete_test":"Implement a small discrete-event simulation of the protocol described in Sections II and III with N=5 approved nodes. Let an honest minority (nodes 1 and 2) hold the original tree: main block B0, yellow PHR block Y1, and red log block R1. Let nodes 3-5 (60%) collude to replace Y1's diagnosis and the corresponding R1 log entry, then rebuild all descendant blocks in both subchains and the main chain, following the stated 51% confirmation/replacement rule. Check whether nodes 1 and 2, upon receiving the rewritten chain, replace their local copy because it is now held by 51% of nodes. If the simulation shows acceptance, the paper's immutability claim is false in exactly the insider-coalition case it claims to prevent.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that the blockchain tree makes access logs and PHR changes 'impossible to change or delete' (Section III). The load-bearing assumption is that the permissioned PoA network, whose nodes are hospitals and medical staff, will never contain a coalition of more than 51% of approved nodes willing to rewrite history. Section II states the replacement rule: if a block is detected as changed, it is 'automatically replaced by the right that exists on at least 51% other nodes network.' This is not a protection against a majority coalition; it is an instruction to accept the majority version. Three of five hospital nodes can rewrite a PHR block in Subchain 1, the corresponding access-log block in Subchain 2, and all descendant blocks, broadcast the rewritten tree, and the honest minority will be required by the stated rule to treat the rewritten chain as correct. The cross-hash tree structure increases the number of hashes to recompute but adds no cost or difficulty for a coalition that controls the consensus majority, and the paper provides no node-admission controls, fork-resolution policy, or penalty mechanism that would deter collusion. Section IV concedes the work is only a first step and that legal compliance and network issues are deferred, but the Section II rule is not a mere implementation detail: it makes the security claim true only if no 51% insider coalition exists, which contradicts the insider-threat motivation the paper opens with.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a \"Blockchain Tree\" architecture for eHealth: a main blockchain with one block per patient serves as the anchor for two subchains, one holding medical history (diagnoses, prescriptions, test results) and one holding access logs. The authors argue that the tree structure, combined with cross-hashes among the three chains and a permissioned Proof of Authority consensus, prevents insiders from altering PHRs or access logs after the fact. The manuscript describes the intended workflow (patient onboarding, writing and reading health data), discusses edge cases such as fiscal-code changes and closing a patient's subchain, and compares the proposal with several commercial healthcare-blockchain projects. It contains no formal security model, no implementation, and no experimental evaluation; the security argument rests on informal statements about hash chaining and the consensus rule that a block must be confirmed by more than 51% of verified nodes.","tokens_in":11237,"tokens_out":3910,"duration_ms":41790,"significance":"If the central security claim were established, the paper would address a real and well-documented problem: insider abuse of access to healthcare records. The proposed design has some merits: it separates patient-identity data, clinical data, and audit logs into distinct chains; it uses cross-hash references to couple those chains; and it explicitly targets the insider threat, which is a sensible motivation. The paper also gives credit for adopting a permissioned model with free transactions, appropriate for healthcare deployments. However, the contribution as presented is not yet a security result. The claims that logs and PHRs are \"impossible to change or delete\" are asserted rather than proven, and, more seriously, the stated majority-replacement rule appears to contradict the claimed guarantee in the very permissioned setting the paper assumes. The cross-chain structure is an interesting design intuition, but no formal adversary model, no rigorous integrity argument, and no implementation evidence are supplied, so the paper currently does not meet the evidentiary bar for a security venue.","major_comments":[{"comment":"The paper's own replacement rule undermines the stated immutability guarantee. Section II says that if a change is detected in an existing block, that block is \"automatically replaced by the 'right' that exists on at least 51% other nodes network.\" The network described in Section III.A consists of approved nodes operated by hospitals, ambulatories, and other medical organizations, and Section I identifies insiders as the primary threat. A coalition of more than 51% of these approved nodes can rewrite a block in Subchain 1, the corresponding log block in Subchain 2, and all descendant blocks, rebroadcast the rewritten tree, and the remaining nodes are instructed by the Section II rule to accept the majority version. The cross-hash tree structure forces the coalition to recompute a larger set of hashes, but this adds no cryptographic difficulty for a coalition that already controls the consensus majority. The manuscript needs either an explicit adversarial threshold with a mechanism that prevents majority collusion (for example, accountable admission and slashing), or a carefully qualified statement of what property is actually guaranteed.","section":"Section II (confirmation rule) vs. Section III.A (permissioned network)"},{"comment":"The central claims that logs and stored PHR data will be \"impossible to change or delete\" are absolute, but the paper provides no formal threat model or security proof. It does not define the adversary's capabilities, the precise security properties to be established (e.g., persistence, liveness, or auditability), or the cryptographic assumptions (e.g., collision resistance of the hash function, authenticity of the approved-node list). The argument that triple hash cross-referencing \"significantly complicates the possibility of tampering\" is a heuristic, not a security analysis. A rigorous treatment would define the hash-chain invariants connecting blocks across the three chains and prove that any modification is detected unless the adversary controls more than a stated fraction of the consensus participants. Without such a model, the paper's main contribution is not established.","section":"Section III.A and Section IV"},{"comment":"The manuscript lacks a complete protocol specification and any implementation or measurement. There is no block format, no description of how blocks are proposed and ordered under Proof of Authority, no fork-resolution policy beyond the 51% rule, no identification of cryptographic primitives, and no analysis of communication or storage overhead. For a claim about deployability in healthcare and about deterring insider abuse, experimental validation or at least a detailed protocol-level design is necessary. The paper's own Section IV concedes that this is \"only the first step\" and that network delays and legal compliance are deferred, but the missing specification directly affects the credibility of the security and usability claims made earlier.","section":"Sections II–IV (protocol specification and evaluation)"}],"minor_comments":[{"comment":"The acronym POA is used inconsistently: Section I introduces \"Proof of Authority (POA),\" while Section II lists \"Proof of Activity (POA)\" among consensus algorithms. Please disambiguate these as distinct mechanisms and avoid reusing the abbreviation.","section":"Section I and Section II"},{"comment":"The threshold wording is inconsistent: \"more than 51%\" and \"at least 51%\" are used interchangeably. The exact quorum condition should be stated precisely and used consistently.","section":"Section II and Section III"},{"comment":"There are several typographical and wording errors, including \"Blokchein\" in Section I-A, \"Sabchain 1 Closing\" in the numbered workflow, and \"tamping\" instead of \"tampering\" near the end of Section III.A. These should be corrected.","section":"Throughout"}],"recommendation":"reject","confidential_remarks":"The manuscript does not currently meet the standard for a security paper: the main security claim is unsupported and is in direct tension with the paper's own 51% replacement rule in the permissioned setting. Repairing this would require a substantially new formalization and evaluation, not a local revision. I recommend rejection, but the cross-linked subchain idea may be worth developing further in a future submission with a proper adversary model and implementation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a clearly written design sketch for a blockchain tree in healthcare. The arrangement is genuinely new: a main chain carrying patient identity, with each block acting as a genesis block for two subchains—one for medical data, one for access logs—and cross-hashes linking all three. The per-patient genesis blocks and the triple cross-hash are not in the cited related work. The paper also gives a concrete sequence of operations for patient onboarding, writing, and reading, which helps make the idea concrete, and it is honest in Section IV that the work is a first step with GDPR and networking details left open.\n\nWhat does not hold is the central security claim. The introduction and Section III assert that insiders cannot change logs and that stored information is 'impossible to change or delete.' But the only mechanism described in Section II is that a changed block is automatically replaced by the version held by at least 51% of nodes. In a permissioned Proof-of-Authority network whose nodes are hospitals and medical staff—exactly the insiders the paper opens by worrying about—a coalition of more than half of the approved nodes can rewrite the main chain, both subchains, recompute the cross-hashes, and broadcast the result. The stated rule tells the honest minority to accept the majority version. The cross-hash structure raises the cost for an attacker without majority control, but it adds nothing against a coalition that holds the consensus majority. The paper never states a threat model that excludes collusion among node operators, and no node-admission, fork-resolution, or penalty mechanism is proposed.\n\nThis is a load-bearing gap, not a minor omission. The architecture might still be useful if paired with explicit trust assumptions—say, an external authority that signs blocks, or a governance structure that makes a 51% coalition infeasible—but that is not in the paper. There is no implementation, no formal security argument, and no evaluation, so the 'impossible to change' language is simply unsupported.\n\nThe paper is a reasonable early-stage vision. I would send it to a workshop or a venue that accepts design proposals, but it needs a serious referee who will require the authors to either fix the threat model or soften the claims. The tree composition is worth discussing; the security conclusion, as stated, is not.","headline":"The tree-of-subchains composition is a fresh idea, but the paper's 'impossible to change' claim is undone by its own 51% replacement rule in a permissioned network of the very insiders it is supposed to police.","tokens_in":11794,"tokens_out":2485,"would_cite":false,"duration_ms":27606,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that a Blockchain Tree of three cross-linked chains makes patient records and their access logs impossible to alter or delete.","keywords":["blockchain","eHealth","personal health records","access logs","audit logging","Proof of Authority","permissioned blockchain","blockchain tree"],"falsifier":"Deploy the proposed three-chain structure on a permissioned network of, say, nine nodes; have five of them collude to delete one access-log block and rewrite the corresponding medical and main blocks, then check whether the remaining four honest nodes detect and revert the change. If the rewritten chain is accepted as canonical, the immutability claim fails.","tokens_in":10786,"feed_emoji":"🏥","tokens_out":8119,"duration_ms":79264,"temperature":0.7,"pith_summary":"The paper proposes a Blockchain Tree for healthcare: a main chain whose blocks identify individual patients, with two subchains attached to each patient block, one holding medical history and the other holding access logs. The central claim is that because each new log block cross-hashes the patient's main block, the newly written medical block, and the previous log block, an insider cannot change or delete logs to hide privilege abuse, and stored diagnoses cannot be rewritten for fraud. The authors argue this structure, run on a private permissioned network with Proof of Authority consensus and no transaction fees, is better suited to medicine than existing blockchain designs. A sympathetic reader cares because the design targets the insider threat that drives most healthcare data breaches by turning every access attempt into an immutable record.","feed_headline":"Tree of three blockchains targets tamper-proof medical logs","feed_subtitle":"Cross-linked chains put every patient record and access attempt into an auditable, hard-to-rewrite record.","key_machinery":"The load-bearing mechanism is the cross-hash that links the three chains. In the paper's design, every block of the log subchain contains the hash of the corresponding main identity block, the hash of the newest block of the medical subchain, and the hash of the previous log block, so the chains cannot be modified independently without visible inconsistency. The design is completed by Proof of Authority consensus on a fixed list of verified network nodes, which keeps block creation cheap and transactions free, and by the standard Merkle-tree hashing used to build block hashes.","core_discovery":"The core proposal is structural: use one block per patient in a main chain and make that block the genesis of two per-patient subchains, one for the clinical record and one for the audit log. When a medical professional writes a new diagnosis, test result, or prescription, a block is appended to the clinical subchain, and simultaneously a block is appended to the audit subchain; that audit block carries three hashes: the hash of the patient's main block, the hash of the new clinical block, and the hash of the previous audit block. The authors claim this triple cross-reference binds the three chains together so that changing or deleting any record would require rewriting several chains at once, which they argue is detectable and uneconomical. They also propose closing the clinical subchain after death or loss of citizenship while letting the audit subchain continue to record access attempts.","pith_inferences":["The paper leaves the tamper-resistance property unproven; a natural extension is to formulate the cross-hash invariant and verify by model checking that modifying any one chain is detected unless all three linked chains are rewritten consistently.","Because the node operators are the hospitals and medical staff being audited, the 51% threshold is effectively an assumption that insiders will not collude; adding independent external auditors as nodes would strengthen the guarantee.","Regulatory rights such as erasure under data-protection law conflict with on-chain immutability, so a deployable system would likely store raw medical data off-chain and keep only hashes and access logs on-chain."],"forward_implications":["Every successful or failed access attempt to a patient's records automatically creates a log block, yielding a non-repudiable audit trail for investigations.","Hiding an access event or changing a diagnosis would require rewriting the log block, the linked medical block, and the patient's main block together, and getting the rewritten version confirmed by more than 51% of the verified nodes.","Closing the medical subchain after death or loss of citizenship prevents retrospective additions of diagnoses while the audit subchain still logs all future access attempts.","The same three-chain structure can be applied to other identity-linked documents such as ID cards, driver's licenses, diplomas, and insurance records, as the paper notes."],"supporting_citations":[{"why":"Cited for the statistic that 58% of healthcare data incidents involve insiders, which motivates the audit-log requirement.","marker":"[1]"},{"why":"Defines the enterprise permissioned blockchain platform the proposal assumes as its private-network substrate.","marker":"[2]"},{"why":"Provides the formal blockchain security analysis cited for the immutability and coherence of hash-linked chains.","marker":"[4]"},{"why":"Describes an existing blockchain-based healthcare information exchange that the proposed tree structure is meant to improve upon.","marker":"[13]"},{"why":"Defines Proof of Work, which the paper rejects as too expensive for healthcare and thus motivates the choice of Proof of Authority.","marker":"[14]"},{"why":"Illustrates the Merkle tree construction used to hash and verify the transactions inside blocks.","marker":"[28]"}],"fun_headline_variants":["Blockchain tree binds patient records to audit logs","Per-patient tree chains lock medical records and audit logs","Triple-hash tree makes medical logs tamper-evident","Tree of blockchains secures health records and access logs","Main chain per patient, subchains for records and audit"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire tamper-resistance guarantee rests on the assumption that no group of node operators controlling more than half of the approved permissioned network will collude to rewrite the chains, and those operators are the same hospital insiders the audit logs are meant to police.","fun_headline_variants_meta":{"raw":{"variants":["Blockchain tree binds patient records to audit logs","Per-patient tree chains lock medical records and audit logs","Triple-hash tree makes medical logs tamper-evident","Tree of blockchains secures health records and access logs","Main chain per patient, subchains for records and audit"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000491,"raw_usage":{"total_tokens":2330,"prompt_tokens":780,"completion_tokens":1550,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":396,"completion_tokens_details":{"reasoning_tokens":1471}},"tokens_in":396,"tokens_out":1550,"duration_ms":10913,"temperature":1.0,"reasoning_tokens":1471,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:36:04.109548+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy the proposed three-chain structure on a permissioned network of, say, nine nodes; have five of them collude to delete one access-log block and rewrite the corresponding medical and main blocks, then check whether the remaining four honest nodes detect and revert the change. If the rewritten chain is accepted as canonical, the immutability claim fails.","supporting_citations":[{"cited_title":"V erizon","cited_arxiv_id":null,"evidence_quote":"Cited for the statistic that 58% of healthcare data incidents involve insiders, which motivates the audit-log requirement."},{"cited_title":"Hyperledger Fabric","cited_arxiv_id":null,"evidence_quote":"Defines the enterprise permissioned blockchain platform the proposal assumes as its private-network substrate."},{"cited_title":"The bitcoin ba ckbone protocol: Analysis and applications,","cited_arxiv_id":null,"evidence_quote":"Provides the formal blockchain security analysis cited for the immutability and coherence of hash-linked chains."},{"cited_title":"Blochie : A blockchain-based platform for healthcare information exc hange,","cited_arxiv_id":null,"evidence_quote":"Describes an existing blockchain-based healthcare information exchange that the proposed tree structure is meant to improve upon."},{"cited_title":"Jakobsson and A","cited_arxiv_id":null,"evidence_quote":"Defines Proof of Work, which the paper rejects as too expensive for healthcare and thus motivates the choice of Proof of Authority."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Illustrates the Merkle tree construction used to hash and verify the transactions inside blocks."}],"review_version":1}